Dónde se publican realmente los puestos de ingeniero DevOps

Por qué los portales generalistas fallan para este puesto

Publica una oferta de ingeniero DevOps en un portal generalista y te inunda una avalancha de candidatos inadecuados: desarrolladores Java que tocaron un Dockerfile una vez, personal de soporte IT que lista "AWS" porque creó un bucket S3 en un tutorial. Los responsables de contratación que han pasado por esto dejan de usar portales generalistas para cualquier cosa más allá de puestos junior o títulos genéricos de "ingeniero". Lo que lo reemplaza no es secretismo, sino filtrado: se mueven a canales donde la audiencia ya se ha autoseleccionado por el stack específico.

Esto importa más para DevOps que para muchos roles técnicos porque el título en sí es vago. "Ingeniero DevOps" abarca personas haciendo operaciones de clusters Terraform y Kubernetes, personas manteniendo pipelines CI/CD en Jenkins o GitLab, y personas que son realmente SREs con guardia de disponibilidad y conversaciones sobre error-budget con producto. Una publicación vaga en Indeed o LinkedIn atrae a los tres; una publicación en un Slack específico de Kubernetes atrae principalmente al correcto. Así que el puesto sí llega a portales públicos, pero a menudo como canal de baja prioridad y etapa tardía, después de que el reclutador o responsable de contratación ya haya probado los más específicos.

Dónde surgen realmente las ofertas

Canales de comunidad CNCF y Kubernetes. El Slack de la Cloud Native Computing Foundation, y el canal #kubernetes-jobs del Slack de Kubernetes, llevan puestos que necesitan específicamente experiencia operacional en Kubernetes, no solo "contenedores" en un CV. Estas publicaciones suelen nombrar el CNI exacto, service mesh (Istio, Linkerd) o herramienta GitOps (ArgoCD, Flux) que ejecuta el equipo, porque quien publica sabe que la audiencia filtrará por eso.

El foro de comunidad y grupos de usuarios de HashiCorp, para empresas intensivas en Terraform y Vault. Misma lógica: una empresa ejecutando Terraform Enterprise o Vault a escala prefiere publicar donde el candidato ya sepa qué es un state file.

r/devops y r/sre en Reddit, y el newsletter DevOpsish, ambos llevan hilos de empleos intermitentemente. Menor señal que las comunidades de Slack pero vale la pena revisarlos, particularmente para empresas remote-first.

Redes de partners y certificación de proveedores cloud. AWS, Azure y Google Cloud ejecutan programas de partners, y tener un AWS Certified DevOps Engineer – Professional, una certificación Azure Administrator/DevOps Engineer Expert, o la credencial Professional Cloud DevOps Engineer de Google a veces te pone en la propia lista de talento del proveedor o pipeline de referidos de partners; esto varía por región y tier de partner, así que trátalo como algo que vale la pena investigar en lugar de garantizado.

Hilos "Who's Hiring" de Hacker News (mensuales, primer día laborable del mes) todavía llevan roles de infraestructura y plataforma de empresas que no quieren lidiar con una capa de reclutadores en absoluto, a menudo con un email directo al ingeniero contratante en lugar de un enlace a ATS.

DevOpsDays y grupos locales de meetup. Estos son eventos presenciales o híbridos, y los puestos se mencionan desde el escenario o en el canal secundario de Slack antes de publicarse formalmente en cualquier lugar. Esto no es lo mismo que "haz más networking" como consejo vago: es un formato de evento específico y recurrente con una audiencia específica de ingenieros de plataforma e infraestructura, y los organizadores usualmente publican puestos abiertos en el propio canal del evento.

Blogs de ingeniería y páginas de estado de empresas. Si una empresa escribe públicamente sobre su proceso de respuesta a incidentes, su estructura de módulos Terraform, o su migración a un nuevo orquestador, eso usualmente señala que el equipo de plataforma está creciendo, y vale la pena revisar su página de careers directamente en lugar de esperar a que el puesto aparezca en un portal.

Agencias, y la división específica que importa aquí

El reclutamiento DevOps se divide en una línea que no se mapea claramente con otras contrataciones de ingeniería: las contrataciones permanentes pasan por reclutadores tech generalistas o equipos de talento internos, pero una gran parte del trabajo —particularmente proyectos de migración cloud, construcciones de plataforma y cobertura SRE— pasa en cambio por reclutadores de contratos e interinos.

El lado de contratos funciona con tarifas diarias y, en el Reino Unido, con estatus IR35. Un puesto anunciado como "outside IR35" a través de un umbrella o tu propia limited company es una negociación diferente y una posición fiscal diferente de un contrato PAYE o un puesto permanente, y los reclutadores especializados en infraestructura usualmente liderarán con ese estatus en el primer mensaje porque determina si siquiera mirarás la tarifa. Si un reclutador no puede decirte la determinación IR35 cuando te contacta por primera vez, vale la pena preguntar antes de ir más lejos, no después.

Los reclutadores boutique que se enfocan específicamente en infraestructura cloud, SRE e ingeniería de plataforma (a diferencia de agencias generales de "reclutamiento IT") tienden a tener briefs más estrechos pero más precisos: usualmente han hablado con el responsable de contratación, no solo con RRHH, y pueden decirte qué orquestador, qué cloud, y si hay guardia de disponibilidad adjunta. Las agencias generalistas trabajando un req DevOps desde una lista de keywords son las que te envían puestos que resultan ser trabajos de sysadmin con título rebautizado.

Un número significativo de roles DevOps y de plataforma nunca van a ninguna agencia externa en absoluto: se cubren a través del propio reclutador de la empresa contactando directamente en LinkedIn a personas cuyo perfil lista herramientas específicas (Terraform, Kubernetes, Prometheus, Grafana) en lugar de solo el título del puesto. Mantener esa sección de un perfil actualizada y específica, no solo el titular, está haciendo trabajo real aquí.

Movimiento interno y el problema del equipo de plataforma

Una gran cantidad de contratación DevOps en empresas establecidas no es contratación en absoluto: es transferencia interna. Sysadmins y desarrolladores backend se mueven a un equipo de plataforma o SRE a medida que la empresa adopta prácticas de infrastructure-as-code y CI/CD, a menudo sin que el puesto se anuncie externamente jamás. Las empresas pasando por una reorganización de ingeniería de plataforma —dividiendo un "equipo DevOps" monolítico en un equipo de plataforma central más ingenieros embebidos en equipos de producto— usualmente cubren la nueva estructura desde empleados existentes primero, y solo abren reqs externos para los puestos que nadie interno quiere o tiene la habilidad específica (a menudo las posiciones SRE intensivas en guardias).

Esto tiene una consecuencia práctica: si estás tratando de moverte de sysadmin o trabajo backend hacia DevOps, la ruta interna dentro de tu empleador actual puede ser más rápida y realista que el mercado laboral externo, porque compites contra nadie en lugar de contra especialistas contratados externamente. Si ya eres un ingeniero DevOps tratando de cambiar de empleador, significa que el headcount que persigues puede ya tener un candidato interno informal en mente, y la publicación externa —si la hay— es parcialmente una formalidad requerida por la propia política de contratación de la empresa.

Temporalidad y estacionalidad específica de este mercado

La contratación DevOps y de plataforma sigue dos calendarios que no siempre se alinean: el propio año fiscal de la empresa, y los hitos de proyectos de gasto o migración cloud.

La contratación impulsada por presupuesto tiende a abrir en dos ventanas: poco después de que comience un nuevo año fiscal (enero para empresas de año calendario, abril para empresas del Reino Unido alineadas al año fiscal), cuando se aprueba nuevo headcount, y en el trimestre final antes de fin de año, cuando el presupuesto no gastado se usa antes de perderse; este es un patrón comúnmente citado en contratación tech generalmente, no algo único de DevOps, pero se aplica aquí tanto como en cualquier lugar.

La contratación impulsada por proyectos es más específica de este campo. Una migración cloud, una construcción de plataforma Kubernetes, o una renovación de infraestructura impulsada por cumplimiento (preparación SOC 2, ISO 27001) crea un estallido definido de contratación DevOps de contrato y permanente atado al inicio del proyecto, y una caída correspondiente en renovaciones de contratos a medida que el proyecto alcanza estado estable. Los ingenieros DevOps de contrato que entienden esta línea de tiempo a veces rastrean deliberadamente qué empresas acaban de cerrar rondas de financiación o anunciado migraciones cloud, porque eso es un indicador adelantado de contratación de infraestructura seis a doce semanas después.

El verano del hemisferio norte y el período alrededor de las vacaciones de diciembre son ampliamente reportados como más lentos para contratación generalmente en tech, incluyendo DevOps: menos nuevos reqs abiertos, más puestos sentados en limbo de entrevistas porque un miembro del panel está de vacaciones. Esto no es razón para dejar de aplicar, pero es razón para no leer el silencio en agosto como señal de rechazo.

Qué hacer con esto

Únete al Slack de Kubernetes y al Slack de CNCF esta semana si no lo has hecho, y revisa los canales de empleos directamente en lugar de esperar un digest. Mira directamente los blogs de ingeniería y páginas de careers de tus empresas objetivo: si han escrito sobre una migración o una reconstrucción de plataforma en los últimos seis meses, esa es mejor señal que una búsqueda genérica en portales de empleo. Si estás haciendo trabajo de contrato, pregunta sobre el estatus IR35 en la primera conversación, no en la tercera. Y si ya estás dentro de una empresa, pregunta a tu propio líder de plataforma o SRE directamente si la transferencia interna es realista antes de asumir que tienes que irte para hacer el movimiento.

Lo que estás haciendo en esta etapa es mayormente leer y emparejar: averiguar cuáles de los puestos que encuentras realmente encajan con tu stack y experiencia específicos, y cuáles no. jobmarket.pro hace esa lectura y emparejamiento por ti: busca a través de estos canales, lee cada anuncio completo, y prepara una aplicación desde tu experiencia real en lugar de un CV reescrito.