Cómo contratar a un Site Reliability Engineer (SRE) en 2026

Para contratar a un Site Reliability Engineer, define la superficie de SLO que el puesto va a asumir, redacta una descripción de puesto centrada en la fiabilidad (no una oferta de operaciones con otro título), evalúa el criterio ante incidentes en lugar de la velocidad programando, plantea una entrevista basada en un escenario de producción construido alrededor de una decisión sobre el presupuesto de error y cierra en menos de 48 horas, porque los buenos candidatos llevan varios procesos a la vez. Un SRE aplica la ingeniería de software a las operaciones: asume los objetivos de nivel de servicio, los defiende con presupuestos de error y carga con el busca. Esa última frase es todo el listón de contratación. Si una persona candidata no sabe razonar sobre el consumo de un presupuesto de error, estás entrevistando para el puesto equivocado.

¿Qué hace un Site Reliability Engineer?

Un Site Reliability Engineer mantiene fiables los sistemas en producción tratando las operaciones como un problema de software. El puesto se apoya en cuatro conceptos que nacieron en Google, donde se inventó el rol de SRE, y que sirven a la vez como tu checklist de evaluación.

La referencia canónica es el libro de SRE de Google, y todo candidato serio a SRE habla con fluidez su vocabulario:

• SLI (Service Level Indicator): una medida cuantitativa de un aspecto del servicio, como la latencia de las peticiones, la tasa de errores o la disponibilidad.
• SLO (Service Level Objective): un valor objetivo o un rango para un SLI, por ejemplo “el 99 % de las peticiones GET se completan en menos de 100 ms”. El SLO es la promesa que hace el sistema.
• Presupuesto de error: la tasa admisible a la que se puede incumplir un SLO. Si tu SLO de disponibilidad es del 99,9 %, ese 0,1 % restante es el presupuesto. Mientras el presupuesto tiene margen, el equipo lanza funciones más rápido. Cuando se agota, los lanzamientos se ralentizan y el trabajo de fiabilidad pasa a ser prioritario. El presupuesto de error es el mecanismo de control que equilibra la velocidad frente a la estabilidad, y es el tema que más señal aporta en cualquier entrevista de SRE.
• Toil: trabajo manual y repetitivo que escala de forma lineal con el sistema y no genera ningún valor duradero. El mandato del SRE es eliminar el toil con ingeniería, no absorberlo. Una persona que reinicia un servicio a mano cada noche está haciendo toil; un SRE escribe la automatización que hace innecesario ese reinicio.

Por encima se sitúan las cuatro señales doradas: latencia, tráfico, errores y saturación. Un buen SRE instrumenta la latencia en p50, p95 y p99, y alerta sobre la cola de p99 frente al SLO, no sobre la mediana, porque alertar en p50 entierra al equipo bajo el ruido mientras el dolor real del usuario se esconde en la cola.

El puesto va sobre una curva de demanda saludable. SRE se incluye dentro del grupo de la Oficina de Estadísticas Laborales de EE. UU. para desarrolladores de software, analistas de QA y testers, que la BLS proyecta que crecerá un 15 % entre 2024 y 2034, mucho más rápido que la media de todas las ocupaciones, sumando alrededor de 288 000 empleos de desarrollo de software. No existe un código BLS específico para “Site Reliability Engineer”; el puesto se reporta bajo desarrolladores de software (SOC 15-1252), con un salario medio de desarrollador de software de 133 080 dólares a fecha de mayo de 2024. La demanda se concentra allá donde la caída del servicio tiene un coste en dólares.

SRE, DevOps o ingeniería de plataforma: ¿qué puesto necesitas en realidad?

Estos tres puestos se anuncian de forma intercambiable, y esa confusión es el error más caro de la contratación en fiabilidad. DevOps es una cultura, la ingeniería de plataforma construye el camino pavimentado y el SRE asume si el sistema sigue en pie. No son sinónimos.

La prueba práctica es la responsabilidad. Si necesitas a alguien que asuma formalmente los SLO, defienda un presupuesto de error y cargue con el busca, necesitas un SRE. Si lo que quieres son herramientas internas y una experiencia de autoservicio para quien programa, quieres un ingeniero de plataforma. Si lo que buscas es una cultura de lanzamientos más ágil en toda la organización, eso es una práctica DevOps, no una sola contratación. Etiquetar mal aquí produce una descripción de puesto que atrae a los candidatos equivocados y una contratación que renuncia cuando el trabajo real no es el que se anunció. (Distinciones sintetizadas a partir de Splunk, InfoWorld y FireHydrant.)

¿Cuándo deberías contratar a tu primer SRE?

Contrata a un SRE cuando la fiabilidad se ha convertido en el segundo trabajo accidental de alguien y nadie la asume de forma formal. El detonante rara vez es una decisión limpia; suele llegar como un patrón de dolor.

Vigila estas señales:

• Los incidentes aumentan y nadie asume la fiabilidad. Las caídas las apaga quien las nota primero, y los postmortems o no se hacen o no cambian nada.
• Tienes SLA con clientes, pero ningún SLO interno. Has prometido disponibilidad por contrato sin ningún objetivo ni presupuesto interno para defender esa promesa. En ese hueco viven las caídas que cuestan ingresos.
• Las guardias son informales, no remuneradas y están quemando a tu gente sénior. Tus mejores ingenieros responden al busca a las 2 de la madrugada en una rotación de dos personas sin estructura de compensación. Esto es un riesgo de rotación de personal antes que un riesgo de fiabilidad.
• Acabas de cruzar un umbral de escala. Una ronda de financiación, un cliente enterprise firmado o un hito de tráfico han encarecido la caída lo suficiente como para justificar a alguien dedicado.

Una advertencia: no contrates a un SRE para absorber un dolor que no te has comprometido a arreglar. Si los SLO, la salud de las guardias y el trabajo de fiabilidad no van a ser prioridades reales, contratarás a un ingeniero de fiabilidad y le entregarás una cola de tickets. Los buenos candidatos lo percibirán en la entrevista y declinarán.

¿Cuánto cuesta un SRE en 2026?

Los salarios base a nivel nacional para Site Reliability Engineers se agrupan en torno a los 130 000 a 150 000 dólares, y los SRE sénior en los grandes hubs alcanzan con frecuencia entre 180 000 y 280 000 dólares de compensación total. Las cifras varían mucho según la fuente, porque algunas reportan solo el salario base y otras incluyen acciones y bonus, así que comprueba siempre qué mide una cifra antes de anclarte en ella.

Los agregadores autorreportados como Indeed van altos, así que toma cualquier “media de 170K” como teñida de compensación total, no como base. La antigüedad es la palanca más grande:

• SRE de entrada / júnior: aproximadamente de 110K a 135K de base.
• SRE intermedio (de 3 a 6 años): de 140K a 165K de base; con siete años o más, la media ronda los 162 756 (Built In).
• SRE sénior: habitualmente de 160K a 200K+ de base; en San Francisco y Nueva York se reportan entre 180K y 280K de compensación total.
• SRE principal / staff: de 200K a 308K, según la guía salarial 2026 de KORE1.

La geografía lo amplifica. Built In sitúa San Francisco en torno a los 183 286, alrededor de un 31 % por encima de la media nacional, con Austin cerca de 158 681 y los puestos en remoto alrededor de 163 969. Dos factores de coste honestos que la gente olvida: la compensación por guardias forma parte del paquete hoy, y la compensación del SRE se solapa mucho con la de un ingeniero de software sénior porque el trabajo es ingeniería de software. Presupuesta en consecuencia o perderás candidatos frente a equipos de producto que pagan lo mismo con menos avisos del busca.

¿Cómo redactas una descripción de puesto de SRE que atraiga a la gente adecuada?

Una buena descripción de puesto de SRE describe la superficie de fiabilidad, no una lista de herramientas. Las ofertas genéricas atraen a generalistas; las específicas atraen a ingenieros que quieren asumir la producción. La forma más rápida de espantar a un buen candidato es una descripción que se lee como una oferta de sysadmin con “SRE” pegado encima.

Concreta esto en la oferta:

• El marco de SLO. ¿Qué significa fiabilidad aquí, y cuál es hoy la relación del equipo con los SLO y los presupuestos de error? “Establecer nuestros primeros SLO” y “madurar un programa de SLO de 30 servicios” atraen a personas distintas.
• El stack principal. Nombra la nube (AWS, GCP, Azure), la capa de orquestación (Kubernetes está casi en el mínimo de base) y las herramientas de observabilidad e incidentes.
• El foco real. Sé honesto sobre si los primeros seis meses son reducción de toil, estabilización de guardias o trabajo cercano a la plataforma. Los candidatos eligen en función de esto.
• La realidad de las guardias. Tamaño de la rotación, cadencia y compensación. Una rotación saludable suele ser de seis personas o más. Declararlo señala madurez; omitirlo señala que no lo has pensado.

La señal más potente que puedes enviar es que entiendes la diferencia entre un SRE y un ingeniero de operaciones. Redacta los requisitos en torno al criterio sobre fiabilidad (diseño de SLO, mando de incidentes, automatización que elimina toil) y no como una lista de certificaciones y sistemas de tickets.

¿Cómo entrevistas a un SRE para evaluar su criterio sobre fiabilidad?

Entrevista a un SRE en torno a escenarios de producción, no a LeetCode. El trabajo consiste en razonar sobre el fallo bajo presión, así que la entrevista debería hacer que la persona candidata razone sobre el fallo. Los puzzles de velocidad programando se pierden toda la señal.

Limita el proceso a tres rondas incluyendo la final, porque los SRE sénior llevan procesos en paralelo y se descuelgan tras la tercera entrevista. Dentro de ese proceso, evalúa lo siguiente más o menos en este orden de prioridad:

1. Toma de decisiones sobre el presupuesto de error. Plantea un escenario de consumo del presupuesto: un lanzamiento se está comiendo el presupuesto a mitad de trimestre. ¿Razona entre congelar, hacer rollback, usar un feature flag o aplicar un arreglo dirigido, y menciona las alertas de tasa de consumo? Esta es la pregunta que más señal aporta, sin competencia. Una persona que salta directamente a “hacer rollback de todo” sin considerar el estado del presupuesto no está pensando como un SRE.
2. Diseño de SLI/SLO. ¿Sabe definir un SLI con sentido para un servicio dado y fijar un SLO defendible, y distingue correctamente el SLI del SLO y del SLA?
3. Señales doradas y observabilidad. Sondea su razonamiento sobre latencia p50/p95/p99, las alertas sobre la cola y cómo evita la fatiga de alertas.
4. Identificación de toil. Dale una tarea operativa repetitiva y observa si por instinto tira de automatizarla en lugar de programarla.
5. Mando de incidentes y postmortems sin culpa. ¿Ha dirigido de verdad una respuesta a incidentes y asumido un postmortem que cambió el sistema?
6. Profundidad en ingeniería de software. Un SRE es habilidad de sysadmin más ingeniería de software de verdad, normalmente en Python o Go. Pídele código que haya escrito y que eliminara trabajo operativo. Si la respuesta son solo scripts de shell, sopésalo frente a la antigüedad que estás pagando.

Fíjate en las preguntas que te hace la persona candidata. Los buenos SRE entrevistan tu madurez en fiabilidad: preguntan por el tamaño de la rotación, las expectativas de tiempo de respuesta al busca, la compensación de las guardias y la proporción entre alertas accionables y no accionables. Esas preguntas son una señal de retención, no de arrogancia. (Conjunto de preguntas adaptado de la guía de entrevistas de SRE de KORE1.)

La parte difícil es la consistencia. Cuando seis personas entrevistadoras improvisan cada una sus propias preguntas, no puedes comparar candidatos, y el criterio sobre fiabilidad se diluye en sensaciones. Justo por eso Kit te permite codificar las señales específicas del SRE (razonamiento sobre el presupuesto de error, diseño de SLO, responsabilidad sobre incidentes, reducción de toil) en una tarjeta de evaluación estructurada, de modo que cada entrevistador puntúe las mismas dimensiones y puedas ver, lado a lado, quién piensa de verdad como un SRE. Para la prueba técnica en sí, los ejercicios de código de Kit están integrados con GitHub, así que puedes entregar a los candidatos una tarea realista de automatización o instrumentación en lugar de un puzzle de algoritmos que no te dice nada sobre su criterio en producción.

¿Y qué pasa con las certificaciones y las credenciales?

No hay una licencia para SRE, y las certificaciones son un factor de desempate, nunca una barrera de entrada. A diferencia de la medicina o el derecho, la ingeniería de fiabilidad no tiene ninguna credencial obligatoria. En palabras de la responsable de formación de SRE en Google, Jennifer Petoff: “a los grandes SRE no se les contrata, en realidad se les forma”. La experiencia gana al papel.

Las certificaciones señalan una competencia de base y autonomía, no demuestran capacidad:

• CKA (Certified Kubernetes Administrator): la certificación de infraestructura más relevante, ya que Kubernetes está casi en el mínimo de base para el puesto.
• Google Cloud Professional DevOps Engineer: cubre explícitamente los principios de SRE y es la certificación de nube con más “sabor a SRE”.
• AWS Certified DevOps Engineer (Professional) o equivalentes de Azure: relevantes cuando el stack coincide.

Existen certificados de “SRE Foundation” de proveedores, pero son pruebas de conocimiento más que demostraciones de habilidad. Pondera el trabajo demostrado en incidentes y automatización muy por encima de cualquier insignia. Una persona que sepa guiarte por un postmortem que asumió y la automatización que salió de él te dice más que un muro de certificaciones.

¿Cuáles son los errores más comunes al contratar SRE?

Los modos de fallo son predecibles, y la mayoría se remontan a la confusión de títulos o a entrevistar para lo que no es. Evitarlos es la mayor parte de la batalla.

1. Etiquetar un puesto de operaciones como “SRE”. El fallo más citado. Si las guardias, los SLO y la fiabilidad no son prioridades reales, no necesitas un SRE, y los buenos candidatos verán a través de la descripción.
2. Redactar una descripción de puesto vaga. Las ofertas genéricas atraen a generalistas. Las específicas de fiabilidad atraen a SRE de verdad.
3. Entrevistar por la velocidad programando en lugar de por el criterio sobre fiabilidad. LeetCode se pierde el razonamiento sobre el presupuesto de error, la higiene de alertas y el mando de incidentes, que son el trabajo real.
4. Demasiadas rondas y ofertas lentas. Los SRE sénior llevan procesos en paralelo y esperan una ventana de oferta de 24 a 48 horas. Los mejores candidatos se descuelgan tras la tercera entrevista. Limita el proceso y muévete rápido.
5. Sin compensación por guardias o con una rotación insana. Contratar a un SRE para una rotación de dos personas, sin remuneración y con tormenta de alertas garantiza la rotación de personal.
6. Confundir SRE con ingeniería de plataforma. Si lo que quieres es a alguien que construya el camino pavimentado, contrata a un ingeniero de plataforma. El SRE asume la fiabilidad y los incidentes.

El error cuatro es el que pierde en silencio a las mejores personas. Un proceso lento y disperso es invisible para ti y evidente para un candidato que está manejando tres ofertas. Esto conecta con un patrón más amplio sobre el que hemos escrito en por qué demasiadas rondas de entrevista te hacen perder a tus mejores candidatos: el coste de un proceso cuidadoso son los candidatos de los que nunca vuelves a saber. La solución es un proceso ajustado y defendible donde todos puntúan lo mismo y la decisión se toma rápido.

Preguntas frecuentes sobre la contratación de un SRE

Respuestas breves a las preguntas que más se hacen los responsables de contratación cuando arrancan una búsqueda de SRE.

¿Cuál es la diferencia entre un SRE y un ingeniero de DevOps? DevOps es una cultura para derribar el muro entre dev y ops y lanzar más rápido, mientras que un SRE asume formalmente la fiabilidad: define los SLO, defiende un presupuesto de error y carga con el busca. Si necesitas a alguien responsable de si el sistema sigue en pie, necesitas un SRE, no una práctica DevOps.

¿Cuánto cuesta un Site Reliability Engineer en 2026? Los salarios base a nivel nacional se agrupan en torno a los 130 000 a 150 000 dólares, y los SRE sénior en los grandes hubs alcanzan con frecuencia entre 180 000 y 280 000 dólares de compensación total. La retribución del SRE se solapa mucho con la de un ingeniero de software sénior porque el trabajo es ingeniería de software, y la compensación por guardias ya forma parte del paquete.

¿Los SRE necesitan certificaciones? No. No hay una licencia para SRE, y certificaciones como la CKA o la de Google Cloud Professional DevOps Engineer son factores de desempate, no barreras de entrada. El trabajo demostrado en respuesta a incidentes y automatización pesa más que cualquier insignia.

¿Qué preguntas de entrevista debería hacerle a un SRE? Empieza con un escenario de consumo del presupuesto de error (congelar, hacer rollback o usar un feature flag), luego el diseño de SLI/SLO, el razonamiento sobre las señales doradas y las alertas, la identificación de toil y un postmortem real que haya asumido. El criterio sobre fiabilidad importa mucho más que la velocidad programando.

¿Cuánto debería durar el proceso de entrevistas de un SRE? Limita el proceso a tres rondas y apunta a una ventana de oferta de 24 a 48 horas. Los SRE sénior llevan procesos en paralelo y se descuelgan tras la tercera entrevista, así que un proceso lento pierde en silencio a tus candidatos más fuertes.

Contrata SRE más rápido con Kit

Contratar a un Site Reliability Engineer se reduce a dos disciplinas que tiran en sentidos opuestos: evaluar con rigor el criterio sobre fiabilidad y moverte lo bastante rápido como para cerrar a un candidato que tiene otras ofertas. La mayoría de los equipos son buenos en una y malos en la otra. Los equipos lentos pierden candidatos; los rápidos contratan a sysadmins con otro título.

Kit es un sistema de seguimiento de candidaturas nativo de IA, construido para startups que necesitan ambas cosas. Las plantillas de puesto centradas en la fiabilidad te dan un pipeline preconfigurado con la tarjeta de evaluación específica del SRE ya lista, de modo que el panel evalúa el razonamiento sobre SLO y el criterio ante incidentes en lugar de improvisar. Los ejercicios de código están integrados con GitHub para tareas realistas de automatización, la programación de entrevistas y la votación en equipo mantienen el proceso ajustado y, como Kit expone su pipeline a través de MCP, puedes pedir a un asistente de IA que redacte mensajes de contacto, resuma candidatos y saque a la luz la decisión pendiente que está frenando tu oferta de 48 horas. Con su precio por asiento, todo el equipo de contratación puede participar sin un impuesto por reclutador.

La estructura es la clave. Define la superficie de SLO, redacta la descripción de puesto de verdad, evalúa con el escenario del presupuesto de error y cierra antes que tu competencia. Si quieres ver cómo encaja el pipeline centrado en la fiabilidad, empieza una prueba gratis y construye la tarjeta de evaluación antes de que tu próxima caída tome la decisión por ti.

Para más manuales de contratación específicos por puesto, consulta nuestras guías sobre cómo contratar a un ingeniero backend y cómo contratar a un forward-deployed engineer.