Iniciar sesión Registrarse Panel

Todas las fichas de puesto

España Informática y tecnologías de la información Intermedio

DevOps Engineer

Descripción de puesto, salario, sourcing, 15 preguntas de entrevista y plan 30/60/90 para contratar un·a DevOps Engineer en pymes españolas.

Compilado por el equipo de Join a partir de datos públicos y de nuestra experiencia en contratación.

Actualizado

De un vistazo

  • Salario mediano 48.000 € 38.000 € – 62.000 €
  • Plazo de contratación 45–70 días
  • Experiencia 3–7 años

Cómo contratar a un·a DevOps Engineer para su pyme

Antes de redactar la oferta, plantéese tres preguntas de encuadre. Determinan qué perfil busca realmente y evitan las confusiones de puesto frecuentes en pyme tech española.

Pregunta 1: ¿DevOps, SRE, Sysadmin o Platform Engineer? Los cuatro roles se tocan pero no se sustituyen. La persona DevOps en pyme vive en el conjunto del ciclo: CI/CD, IaC, observabilidad, guardia y mejora continua de la plataforma. La persona SRE pone el foco en la fiabilidad a escala (SLO, error budgets, capacity planning) y aporta cuando ya hay 30 o más microservicios en producción. La persona Sysadmin tradicional opera sistemas existentes sin necesariamente codificarlos. La persona Platform Engineer construye plataforma autoservicio para las personas desarrolladoras y aporta cuando el equipo ya supera las 20 personas. Si su necesidad real es SRE pero llama al puesto DevOps, los perfiles SRE no le verán; si es lo contrario, atraerá perfiles que se aburrirán a los 6 meses. Sea explícito·a en la oferta sobre el alcance real del puesto.

Pregunta 2: ¿Cuál es su stack y su nivel de madurez operativa? Un·a DevOps sólido·a en una stack AWS y Terraform no se vuelve productivo·a de inmediato en una stack GCP y Pulumi, ni en un cluster Kubernetes mantenido a mano sin IaC. La fit de stack y la madurez operativa pesan más que la seniority absoluta para un·a mid-level. Indique con precisión su stack en la oferta (cloud, orquestador, IaC, observabilidad, gestión de secrets, pipelines), y sea honesto·a sobre el estado real (deuda operativa identificada, alertas en proceso de saneamiento, primera persona DevOps de la empresa). Filtrará de forma natural los perfiles mal encajados, y los perfiles buenos sabrán a qué se apuntan.

Pregunta 3: ¿En qué estado está su guardia y su on-call? Un·a DevOps en pyme participa de forma casi sistemática en la guardia u on-call, y en muchos casos lo lidera. Una rotación mal encuadrada (frecuencia demasiado alta sobre 1 o 2 personas, alertas ruidosas que el equipo ignora, ausencia de runbooks, sin compensación visible) provoca burnout en 6-12 meses y rotación. Encuadre con honestidad cuáles son sus restricciones reales en la oferta y la entrevista: ritmo de guardia, número de personas que rotan, compensación económica o en descansos, estado real de la observabilidad y de los runbooks. Las personas candidatas con experiencia preguntan por este tema; quien descubre la realidad después de incorporarse se marcha en los primeros 12 meses.

Si las tres respuestas convergen hacia un·a DevOps a jornada completa (y no a un·a SRE, Sysadmin o Platform Engineer), pase al modelo de oferta a continuación.

Modelo de descripción de puesto

Descargar .docx

DevOps Engineer: plataforma y fiabilidad en pyme

[Nombre de empresa], pyme B2B del sector [sector] con sede en [ciudad], [X] personas en plantilla y [X] M€ de facturación, busca incorporar un·a DevOps Engineer al equipo técnico de [X] personas.

Misión

Diseñar, operar y hacer evolucionar la plataforma de la empresa (cloud, CI/CD, IaC, observabilidad, gestión de secrets, fiabilidad y seguridad de infraestructura), en autonomía sobre los temas familiares y en colaboración sobre las decisiones estructurantes. La persona reporta a la [Tech Lead / CTO / Dirección Técnica].

Responsabilidades

  • Operar, mantener y hacer evolucionar la infraestructura cloud ([AWS / GCP / Azure]) y su orquestador ([Kubernetes / ECS / Nomad]) con foco en fiabilidad, seguridad y coste.
  • Mantener y mejorar los pipelines CI/CD multi-entorno, con promoción controlada, escaneo de vulnerabilidades, firma de imágenes y estrategia de rollback rápida.
  • Codificar la infraestructura en IaC (Terraform, Pulumi o equivalente) y aplicar el principio GitOps cuando proceda.
  • Diseñar y mantener la observabilidad de plataforma: métricas, logs estructurados, trazas distribuidas, SLI y SLO, dashboards y alertas con sentido (sin ruido).
  • Participar de forma activa en la guardia y el on-call: diagnóstico de incidentes, mitigación, post-mortem blameless, acción sistémica de prevención.
  • Aplicar y mejorar las prácticas de seguridad de infraestructura: principio de menor privilegio en IAM, gestión segura de secrets, escaneo de imágenes y dependencias, parcheo periódico, segmentación de red.
  • Colaborar con las personas desarrolladoras y producto en los briefs: cuestionar de forma constructiva las restricciones inviables o contraproducentes, proponer alternativas operativas viables.
  • Documentar las decisiones técnicas importantes (ADR), los runbooks y las guías de uso interno de la plataforma.

Perfil

  • Imprescindible: [3 a 7] años de experiencia profesional en un puesto DevOps, SRE o equivalente; dominio sólido de al menos una cloud pública (AWS, GCP o Azure) y de un orquestador (Kubernetes, ECS, Nomad); experiencia real de IaC (Terraform o Pulumi); ownership de una plataforma en producción con participación en la guardia.
  • Valorable: familiaridad con nuestra stack [cloud, orquestador, IaC, observabilidad, gestión de secrets]; experiencia en pyme o scale-up (alta autonomía); expertise en un tema concreto (seguridad de infraestructura, fiabilidad a escala, gestión de coste cloud, plataforma autoservicio); contribuciones a open source en el ecosistema cloud-native.
  • Excluyente: ninguna experiencia de ownership en producción en autonomía; rechazo a participar en la guardia o a tocar la observabilidad; ausencia total de práctica de IaC.

Qué ofrecemos

  • Retribución bruta anual: fijo [38-62] mil euros según experiencia. Sin variable estructural; eventualmente phantom shares o stock options según la fase de la sociedad.
  • Modalidad: [jornada completa, híbrido 2-3 días por semana en oficina, base en [ciudad] / remote-friendly].
  • Guardia: [ritmo, número de personas que rotan, compensación económica o en descansos, runbooks y observabilidad existente].
  • Beneficios: [seguro médico, ticket restaurante, cheque transporte, días adicionales de vacaciones, política de teletrabajo, presupuesto de material, presupuesto de formación, conferencias y certificaciones cloud].
  • Stack: [a completar: cloud, orquestador, IaC, observabilidad, gestión de secrets, CI/CD].

Banda salarial

Salario fijo bruto anual

Percentil 25
38.000 €
Mediana
48.000 €
Percentil 75
62.000 €

Salario bruto anual de referencia para un·a DevOps Engineer de nivel intermedio (3 a 7 años de experiencia profesional) en pymes españolas. Madrid y Barcelona en entorno SaaS B2B, fintech o scale-up tiran hacia arriba (58-75 mil euros), sobre todo con expertise sólida en Kubernetes, Terraform y observabilidad de plataforma. Resto del territorio y sectores tradicionales tiran hacia abajo (32-42 mil euros). Los perfiles con experiencia demostrable en SRE, fiabilidad de plataforma a escala o seguridad de infraestructura suman entre 5 y 10 mil euros sobre la mediana. El componente variable es prácticamente inexistente en este puesto en pyme española; algunas scale-ups ofrecen phantom shares o stock options.

Fuentes: INE, Encuesta de Estructura Salarial 2024 (CNO 271, Analistas y diseñadores de software) ; InfoJobs, Estado del Mercado Laboral en España 2025 ; Glassdoor, salarios DevOps España 2025

Dónde captar este perfil

  1. LinkedIn

    Recruiter Lite desde 170 € al mes; 200-400 € al mes adicionales para Job Slots

    Canal con mayor profundidad para perfiles DevOps en España, sobre todo en Madrid y Barcelona. El sourcing activo (Recruiter Lite más InMails personalizados) supera con claridad a las ofertas pasivas: los buenos perfiles DevOps con 3-7 años de experiencia están casi siempre en puesto y no consultan el feed de empleo. Filtre con precisión por tooling concreto (Kubernetes más Terraform más AWS o GCP rinde mucho mejor que DevOps senior), seniority y tamaño de empresa previa. Personalice el primer mensaje citando una plataforma o un reto concreto; los InMails genéricos se quedan por debajo del 5 por ciento de tasa de respuesta para este perfil.

  2. InfoJobs

    Oferta destacada desde 199 € por publicación; packs multioferta desde 450 €

    El portal con mayor volumen de candidaturas activas en España, especialmente fuerte fuera de Madrid y Barcelona (Valencia, Sevilla, Málaga, Bilbao, Zaragoza) y en pyme tradicional con stack mainstream (AWS o Azure, Jenkins, Ansible). Genera volumen, no siempre señal en perfiles DevOps: filtre con un CV semiestructurado y una prueba técnica corta antes de invertir tiempo de cribado. Menos eficaz para perfiles SRE de alta escala o para entornos cloud-native modernos (GitOps, eBPF, service mesh). Útil como complemento de LinkedIn cuando se busca cubrir un puesto rápido y la stack es estándar.

  3. Tecnoempleo

    Desde 250 € por oferta, packs multioferta desde 600 €

    Concentra una audiencia tech española muy específica (sobre todo backend, devops, datos, cloud), con tráfico orgánico recurrente sobre stacks AWS, GCP, Azure, Kubernetes y Terraform. Útil para huir del ruido de los portales generalistas cuando se busca encaje fino de stack o seniority real en infraestructura. La calidad media por candidatura suele ser superior a InfoJobs para el puesto DevOps, con volumen menor pero más relevante.

  4. Referrals internos y comunidades técnicas

    Bonus de referral visible de 1.500 a 3.000 € por contratación cerrada

    El sourcing por referrals es el canal con mayor tasa de cierre para los puestos DevOps en pyme española: la comunidad local es pequeña, muy interconectada (meetups Madrid DevOps, Barcelona Kubernetes, Cloud Native Madrid, Commit Conf) y los buenos perfiles cambian a través del boca a boca. Active de forma explícita el programa de referrals interno (bonus visible, proceso rápido); patrocine o asista a meetups y conferencias de nicho. Espere de 6 a 10 semanas entre la activación del canal y el primer cierre, pero con una tasa de aceptación de oferta mucho más alta que la de los portales.

Comparar todos los portales en este mercado →

Manual de evaluación

El puesto de DevOps Engineer se evalúa en cuatro etapas. El ejercicio de diseño de plataforma (etapa 3) es el más predictivo para este puesto: es donde se revela la capacidad de razonar sobre fiabilidad, observabilidad, seguridad y coste operativo a la vez, que una pyme necesita para no acumular deuda de plataforma durante 18-24 meses.

  1. Etapa 1: Lectura del CV

    Busque coherencia y profundidad real en infraestructura: un·a perfil DevOps que solo ha tocado pipelines CI sin operar nada en producción no es el·la candidato·a buscado·a. Indicios fuertes: ownership de una plataforma en producción (despliegue, monitoring, on-call, incidentes), exposición seria a una cloud pública (AWS, GCP o Azure) y a un orquestador (Kubernetes, ECS, Nomad), presencia de palabras clave concretas (Terraform, Ansible, Prometheus, Grafana, OpenTelemetry, GitOps, IaC). Estabilidad mínima de 18-24 meses por puesto. Un·a autodidacta con 4 años de ownership real de plataforma vale más que un·a recién certificado·a con 2 años de tickets cerrados sin contexto operativo.

  2. Etapa 2: Phone screen (30 min)

    Tres preguntas dirigidas: (1) Describa la plataforma más compleja de la que ha sido responsable; servicios, escala, restricciones operativas, (2) Describa un incidente serio que pilotó; síntoma, diagnóstico, mitigación, post-mortem, acción sistémica, (3) ¿Por qué un cambio ahora? Salida: go o no-go en 5 minutos de debrief, no más. En esta fase evite las preguntas trampa sobre tooling específico; busque la solidez del recorrido operativo y la capacidad de explicar restricciones reales.

  3. Etapa 3: Ejercicio de diseño de plataforma (60-90 min)

    Discusión de arquitectura sobre un caso concreto próximo a su contexto: diseño del pipeline CI/CD multi-entorno con promoción controlada, despliegue de un servicio crítico nuevo con cero downtime, observabilidad y respuesta a incidentes para una plataforma de 30 microservicios, hardening de un cluster Kubernetes para una auditoría de seguridad. Evalúe la clarificación de restricciones (escala, criticidad, presupuesto, cumplimiento), los arbitrajes explícitos (managed frente a self-hosted, push frente a pull, single-tenant frente a multi-tenant), la mentalidad de observabilidad y seguridad desde el diseño, y el reconocimiento honesto de las zonas de incertidumbre. Es la etapa más predictiva para este puesto.

  4. Etapa 4: Referencias estructuradas

    Llame a dos referencias: un·a antiguo·a tech lead o manager directo y un·a antiguo·a compañero·a de plataforma o backend. Plantee a ambas las mismas cuatro preguntas: ¿En qué destaca más?, ¿Para qué contrataría a una persona complementaria?, ¿Volvería a contratarle mañana y por qué?, ¿Un ejemplo concreto de decisión técnica difícil tomada en autonomía? La cuarta pregunta es la que revela el verdadero indicio de autonomía y de juicio operativo, crítico en un puesto DevOps en pyme.

Preguntas de entrevista estructuradas

  1. Conductual Gestión de incidencias

    Describa el incidente de producción más serio que pilotó. ¿Cuál fue el síntoma, el diagnóstico, la mitigación, el post-mortem y la acción sistémica aplicada después?

    Lo que revela una buena respuesta

    Método estructurado: detección (alerta o reporte), triaje, formulación de hipótesis, validación con logs, métricas, trazas o experimentación dirigida en caliente. Honestidad sobre la duración total, las falsas pistas y el coste real para el negocio. Bonus: la persona candidata cita la causa raíz (no solo el hotfix) y la medida sistémica preventiva aplicada después (alerta añadida con SLO, runbook actualizado, automatización de la mitigación, cambio de diseño). Las respuestas tipo reinicié los nodos y todo volvió a la normalidad sin diagnóstico revelan debilidad en investigación operativa.

  2. Conductual Pensamiento sistémico

    Describa una decisión de plataforma importante que tomó en su último puesto (elección de orquestador, paso a IaC, introducción de service mesh, migración de cloud). ¿Por qué era difícil y cómo la resolvió?

    Lo que revela una buena respuesta

    Capacidad de estructurar una decisión bajo incertidumbre: clarificación de restricciones (escala actual y prevista, equipo, presupuesto, calendario), alternativas evaluadas, arbitrajes explícitos entre simplicidad operativa y flexibilidad futura, consulta a las partes implicadas (backend, seguridad, finanzas), validación posterior. Bonus: la persona candidata menciona una decisión sobre la que cambiaría hoy o un ADR escrito para el equipo. Quienes describen una decisión obvia con perspectiva nunca llegaron a arbitrar de verdad.

  3. Conductual Pragmatismo y priorización

    Cuénteme una vez en la que tuvo que reducir el coste cloud de forma significativa sin degradar la fiabilidad. ¿Cómo lo abordó?

    Lo que revela una buena respuesta

    Diagnóstico primero, optimización después: análisis del gasto por servicio o por equipo (tagging, cost explorer), identificación del top 3 o 5 de cost drivers, hipótesis priorizadas (rightsizing, spot, reserved, eliminación de recursos huérfanos, optimización de transferencia de datos), validación del impacto antes de generalizar. Bonus: la persona candidata menciona una métrica concreta de ahorro (porcentaje o valor absoluto) y el efecto colateral en fiabilidad (mantenido o mejorado). Quienes responden migramos a spot y ya está sin matizar el riesgo muestran juicio operativo débil.

Cómo reconocer a un·a excelente Sales Manager

Competencia Por debajo En el nivel Por encima
Infraestructura cloud Domina una cloud a un nivel superficial (consola, despliegues manuales). Tropieza con redes (VPC, subnets, NAT, peering), IAM y los modelos de gestión de coste. No es autónomo·a en Terraform o Pulumi. Autónomo·a sobre una cloud principal (AWS, GCP o Azure) y Kubernetes. Diseña y opera VPC, IAM, balanceadores, almacenamiento, certificados, DNS. IaC sólida en Terraform con módulos reutilizables. Sabe arbitrar entre managed y self-hosted según el contexto. Referente cloud del equipo: anticipa límites de cuotas, optimiza coste sin degradar fiabilidad, conoce los gotchas regionales y multi-cuenta. Sabe diseñar landing zones, organizaciones AWS o GCP, modelos de gestión de identidad federada. Capaz de pasar de una cloud a otra en pocas semanas.
Pensamiento sistémico Mira los componentes en aislamiento sin entender las interacciones. Aplica recetas vistas en blogs sin adaptar al contexto. Sobre-diseña (service mesh en un MVP de 3 servicios) o infra-diseña (todo en una sola VM porque funciona). Razona sobre el sistema completo: dependencias, fronteras, modos de fallo, modos de degradación. Pragmático·a en los arbitrajes (managed frente a self-hosted, simplicidad frente a flexibilidad futura). Reconoce sus zonas de incertidumbre y propone un POC dirigido cuando es pertinente. Piensa la plataforma como un producto con clientes internos: API clara para las personas desarrolladoras, autoservicio donde es posible, observabilidad y SLO desde el diseño. Forma al equipo en pensamiento sistémico y escribe ADRs legibles por las nuevas incorporaciones.
Gestión de incidencias Diagnostica por prueba y error sin modelo mental. Reacciona al incidente sin método. Sin runbooks, sin post-mortem o post-mortem culpabilizador. Alertas ruidosas que el equipo ignora. Método de respuesta estructurado: triaje, hipótesis, validación, mitigación, comunicación. Pilota un incidente sin pánico. Escribe post-mortems blameless con acciones sistémicas reales. Mantiene runbooks utilizables por el equipo. Referencia operativa del equipo: define SLI y SLO, reduce de forma activa el MTTR mediante automatización, anticipa modos de fallo en game days regulares. Reconstruye un incidente complejo a partir de logs o trazas. Forma a las nuevas incorporaciones en la práctica del on-call.
Mentalidad de automatización Resuelve los problemas a mano cada vez que surgen. ClickOps sobre consolas cloud. Scripts dispersos sin versionar. No considera la automatización como parte del trabajo, sino como un lujo. Automatiza lo recurrente y lo riesgoso: IaC para toda nueva infraestructura, pipelines CI/CD para los despliegues, runbooks ejecutables para las operaciones repetidas. Sabe escoger qué automatizar y qué dejar manual a corto plazo. Construye plataforma autoservicio: las personas desarrolladoras provisionan recursos y despliegan sin intermediación. Mantiene una toolchain coherente y documentada. Mide DORA metrics y mejora de forma continua el ciclo de despliegue.
Seguridad de infraestructura Sin conciencia clara de los riesgos comunes (IAM abierto, secrets en repos, redes planas, imágenes obsoletas). Considera la seguridad como problema del equipo de seguridad. Aplica los principios básicos: principio de menor privilegio en IAM, gestión segura de secrets (Vault, External Secrets Operator), escaneo de imágenes en CI, parcheo periódico, segmentación de red. Sabe señalar una vulnerabilidad en una PR de infraestructura. Referencia de seguridad de plataforma en el equipo: modelos de amenazas regulares, hardening de clusters Kubernetes, gestión de identidad federada, auditoría de accesos, respuesta a incidentes de seguridad. Coordina con el equipo de seguridad o la persona DPO en temas sensibles.
Colaboración dev y ops Postura de gatekeeper: bloquea peticiones sin explicación, no documenta, hace de la plataforma una caja negra. Comunica mal plazos y restricciones a las personas desarrolladoras y a producto. Postura de partenariado: clarifica las necesidades, propone alternativas viables, documenta runbooks y guías de uso de la plataforma. Comunica restricciones de manera transparente y pedagógica. Puente entre la plataforma y las demás funciones. Diseña interfaces autoservicio que reducen la necesidad de mediar, forma a las personas desarrolladoras en buenas prácticas operativas, divulga arbitrajes y restricciones a producto y dirección en lenguaje accesible.

Plan de 30/60/90 días

Día 30

  • Setup completo del entorno local y primer cambio (PR trivial sobre Terraform o un pipeline) validado en staging
  • Mapeo y comprensión de la plataforma existente: clouds, clusters, pipelines, observabilidad, gestión de secrets, deuda operativa identificada
  • Primer 1:1 documentado con la persona tech lead sobre convenciones, prioridades de plataforma y estado real de la guardia
  • Primera PR sustantiva (mejora de alerta, corrección de pipeline, módulo Terraform pequeño) revisada y mergeada

Día 60

  • Entrega en autonomía de una mejora estructural completa (refactor de un pipeline crítico, introducción de IaC sobre una zona huérfana, mejora de observabilidad de un servicio clave)
  • Primera review de PR de un·a compañero·a sobre infraestructura con feedback estructurado, no solo clic en aprobar
  • Primera guardia con gestión efectiva de al menos un incidente (diagnóstico, mitigación, post-mortem compartido, acción sistémica)
  • Documentación o ADR redactado sobre una zona tocada recientemente (decisión de tooling, runbook, guía de uso interna)

Día 90

  • Entrega regular (1 a 2 PRs por semana) con calidad validada por el equipo en review
  • Primera decisión técnica de plataforma en autonomía sobre un tema ambiguo (elección de tooling, diseño de un componente nuevo, política de gestión de secrets o de imágenes)
  • Mentoría informal de un·a junior o nueva incorporación (pair sobre infraestructura, reviews pedagógicas, documentación accesible)
  • Balance formal con la persona tech lead: rampa validada, plan de progresión sobre 1-2 ejes prioritarios (por ejemplo seguridad de plataforma o SRE)

Errores comunes al contratar para este puesto

Estos errores son los que más han devuelto a la pyme española una mala contratación DevOps en los últimos 24 meses. La mayoría se evitan en la fase de brief, antes incluso de publicar la oferta.

  1. Confundir DevOps, SRE, Sysadmin y Platform Engineer en el brief inicial

    Los cuatro perfiles se tocan pero no se sustituyen. Un·a DevOps clásico·a en pyme cubre el conjunto: CI/CD, IaC, observabilidad, guardia, mejora continua de la plataforma. Un·a SRE pone el foco en la fiabilidad a escala (SLO, error budgets, capacity planning) y aporta más cuando ya hay 30 o más microservicios. Un·a Sysadmin tradicional opera sistemas existentes sin necesariamente codificarlos. Un·a Platform Engineer construye plataforma autoservicio para las personas desarrolladoras y aporta cuando el equipo ya supera las 20 personas. Si su necesidad real es SRE pero llama al puesto DevOps, los perfiles SRE no le verán; si es lo contrario, atraerá perfiles que se aburrirán a los 6 meses.

  2. Sobrevalorar las certificaciones cloud frente al ownership operativo real

    Una colección de certificaciones AWS, Azure o Google Cloud no es señal de capacidad operativa. Un·a candidato·a con 4 años de ownership real sobre una plataforma en producción (despliegue, monitoring, guardia, incidentes) vale más que un·a profesional con 6 certificaciones y solo experiencia en proyectos cortos de consultoría sin operación. Evalúe sobre incidentes pilotados, decisiones técnicas tomadas en autonomía y la calidad del diagnóstico, no sobre el contador de badges.

  3. Saltarse el ejercicio de diseño de plataforma para ahorrar tiempo

    Para un puesto DevOps mid-level, el diseño de plataforma es la etapa más predictiva del rendimiento futuro. Una pyme que se salta esta etapa para ganar una semana en el plazo de contratación suele incorporar a alguien que sabe operar lo que ya existe pero no sabe diseñar lo siguiente, y acumula deuda de plataforma durante 18-24 meses. El coste de una mala contratación DevOps en pyme es muy superior a 60-90 minutos de diseño en entrevista.

  4. Subestimar el coste real del on-call y la cobertura de la guardia

    Un·a DevOps en pyme es la primera línea del on-call para toda la plataforma. Una rotación mal encuadrada (frecuencia demasiado alta sobre 1-2 personas, alertas ruidosas, ausencia de runbooks, sin compensación visible) provoca burnout en 6-12 meses y rotación. Anuncie con claridad en la oferta: ritmo de guardia, número de personas que rotan, compensación (económica o en descansos), estado real de la observabilidad y de los runbooks. Las personas candidatas con experiencia preguntan por este tema en entrevista; prepárese para responder con honestidad o perderá al perfil bueno.

Preguntas frecuentes

  • ¿Cuál es el salario de un·a DevOps Engineer en una pyme española?

    La horquilla de referencia para un·a DevOps Engineer de nivel intermedio (3 a 7 años de experiencia) en pyme española se sitúa entre 38 y 62 mil euros brutos anuales (mediana en torno a 48 mil). Madrid y Barcelona en entorno SaaS B2B, fintech o scale-up tiran hacia arriba (58-75 mil), sobre todo con expertise sólida en Kubernetes, Terraform y observabilidad de plataforma. El resto del territorio y los sectores tradicionales tiran hacia abajo. Los perfiles con experiencia demostrable en SRE, fiabilidad a escala o seguridad de infraestructura suman entre 5 y 10 mil euros sobre la mediana. Este puesto rara vez tiene variable estructural en pyme; algunas scale-ups ofrecen phantom shares o stock options como complemento.

  • ¿Cuál es la diferencia entre DevOps, SRE, Sysadmin y Platform Engineer?

    La persona DevOps en pyme cubre el conjunto del ciclo: CI/CD, IaC, observabilidad, guardia y mejora continua de la plataforma. La persona SRE pone el foco en la fiabilidad a escala (SLO, error budgets, capacity planning) y aporta más cuando ya hay 30 o más microservicios. La persona Sysadmin opera sistemas existentes sin necesariamente codificarlos. La persona Platform Engineer construye plataforma autoservicio para las personas desarrolladoras y aporta cuando el equipo ya supera las 20 personas. Para una pyme de menos de 30 desarrolladores·as, el arbitraje típico: 1 o 2 DevOps generalistas antes del primer·a SRE o Platform Engineer especialista, que llega cuando la complejidad o la escala lo justifican.

  • ¿Cuánto tiempo lleva contratar a un·a DevOps Engineer en España?

    Cuente con 45 a 70 días entre la publicación de la oferta y la firma para un perfil mid-level. El mercado DevOps español sigue tenso en 2025-2026, sobre todo para stacks cloud-native modernas (Kubernetes a escala, GitOps, eBPF, service mesh) y para perfiles con experiencia operacional real. Los plazos se alargan en agosto y en torno a las navidades. Reducir el plazo por debajo de los 45 días suele implicar sacrificar la etapa de diseño de plataforma o las referencias, lo que degrada considerablemente la calidad de la contratación para este puesto.

  • ¿Es necesaria una certificación cloud para contratar a un·a DevOps Engineer?

    No. Las certificaciones AWS, Azure o Google Cloud son una señal débil de capacidad operativa real. Un·a candidato·a con 4 años de ownership real sobre una plataforma en producción vale más que un·a profesional con 6 certificaciones y solo experiencia en proyectos cortos de consultoría. Evalúe sobre incidentes pilotados, decisiones técnicas tomadas en autonomía y la calidad del diagnóstico de incidentes, no sobre el contador de badges. La certificación puede ser útil como complemento en perfiles junior o como prueba de aprendizaje activo, pero no debe ser un requisito de cribado.

  • ¿Hay que organizar una prueba técnica para un puesto DevOps?

    Sí, pero el ejercicio de diseño de plataforma vivo en entrevista (60-90 minutos) es más predictivo que una prueba para llevar a casa. La discusión de arquitectura sobre un caso concreto próximo a su contexto revela la capacidad de razonar bajo restricciones, de clarificar antes de proponer, de arbitrar entre managed y self-hosted, y de reconocer las zonas de incertidumbre. Si decide añadir una prueba para llevar a casa, acótela a 2-3 horas como máximo y haga que se parezca al día a día (debuggear un manifiesto Kubernetes roto, mejorar un módulo Terraform con feedback, escribir un runbook); evite las preguntas trampa sin relación con el oficio.

Cubra este puesto con Join Sourcing, filtrado y entrevistas en un solo lugar.
Empezar a contratar

Hablar con Join