La ronda de entrevistas del ingeniero de staff: qué hacen mal las rondas de senior

Por qué la mayoría de rondas de staff generan ofertas de senior

El error más común en la contratación de ingenieros de staff es ejecutar la ronda de senior con una fase de diseño de sistemas más larga y llamarla ronda de staff. Cada entrevistador evalúa al candidato según los estándares de senior. El debriefing discute si el candidato es un "senior fuerte". El gestor de contratación presiona para staff porque la plaza está abierta a ese nivel. La oferta termina siendo downleveled o se emite a nivel staff para alguien que luchará dentro de seis meses.

La razón por la que esto sigue ocurriendo es que la rúbrica para "senior" está bien definida — programación sólida, responsable de un servicio, mentoriza juniors, diseña funcionalidades de extremo a extremo — y la rúbrica para "staff" no lo está. La ingeniería de staff es la disciplina de elegir el problema correcto, alinear a un grupo de equipos detrás de una solución y ser correcto sobre los trade-offs técnicos a una escala donde equivocarse es caro. Nada de eso es visible en una ronda de programación de 45 minutos.

Este post es un diseño de ronda para staff y superior. Asume que ya ejecutas una ronda de senior competente y quieres evaluar las dimensiones adicionales que distinguen a staff de un senior rápido. No asume ningún tamaño de empresa en particular.

Las cuatro dimensiones que realmente distinguen a staff

Una rúbrica útil para staff evalúa contra estas, con anclas explícitas en senior, staff y senior staff:

1. Amplitud del juicio. ¿Puede el candidato identificar el problema correcto en el que trabajar, en un dominio que no ha visto antes, dada información parcial y restricciones en competencia? Los ingenieros senior resuelven el problema que les das. Los ingenieros de staff te dicen cuál es el problema que debes resolver.
2. Calidad de la decisión arquitectónica. ¿Pueden razonar sobre un sistema a una granularidad donde los trade-offs son reales — coste, latencia, radio de explosión, acoplamiento organizacional — y defender una elección por escrito? Esto no es lo mismo que recordar un diseño de libro de texto.
3. Influencia entre equipos. ¿Pueden describir una vez que cambiaron la dirección del trabajo fuera de su equipo directo, y articular los mecanismos — el documento, la reunión, el prototipo — que lo hicieron posible? "Dar feedback en una revisión" no es nivel staff. "Escribir el documento de diseño que consolidó tres propuestas competidoras en una" sí lo es.
4. Mentoría técnica a distancia. ¿Pueden elevar el nivel de ingenieros que no manejan directamente, en temas donde no son los expertos del equipo? Este es el estándar que separa staff de un ingeniero senior con años extra.

Cada fase de la ronda debe diseñarse para probar una o dos de estas, no para re-evaluar el estándar de senior.

La ronda, fase a fase

Total: ~6 horas de tiempo del candidato, ~10 horas de tiempo del entrevistador. Seis fases:

Fase 1: Entrevista con el gestor de contratación (60 min)

No es un chat de encaje. Una conversación de trabajo sobre un problema real en tu stack, enmarcado lo suficientemente laxo para que el candidato tenga que hacer preguntas antes de proponer nada. El gestor de contratación escucha para: ¿reducen el problema antes de resolverlo? ¿Preguntan sobre restricciones que un senior saltaría — estructura org, coste de on-call, riesgo de migración?

Esta fase reemplaza la ronda "cuéntame sobre ti" dirigida por el reclutador. Guarda la logística para una llamada de programación separada de 20 minutos.

Fase 2: Un documento de diseño escrito (4–8 horas, asincrónico)

La fase de mayor señal en una ronda de staff, y la que más empresas saltan porque preocupa que sea demasiado trabajo pedir a un candidato. No lo es. Los candidatos de senior completan rutinariamente ejercicios para casa de 2 horas; un candidato de staff completa un ejercicio de diseño enfocado porque el artefacto también es una manera para que evalúen el papel.

El prompt: un problema un poco realista, intencionalmente poco especificado de tu dominio. "Queremos introducir un motor de workflows para orquestar lo que actualmente nuestro equipo de pagos hace ad-hoc en Lambdas. Escribe un documento de 3–8 páginas que argumente un enfoque, nombre las alternativas que consideraste e identifica los tres riesgos principales."

Lo que el documento te dice que una pizarra de 60 minutos no puede:

• Cómo el candidato estructura un argumento cuando tiene tiempo para pensar.
• Si citan trade-offs que se corresponden con tus restricciones reales, o dan explicaciones vagas sobre principios generales.
• Si identifican modos de fallo que el equipo aún no ha discutido.
• Cómo escriben para una audiencia de otros ingenieros de staff, que es la mayoría del trabajo.

Evalúa el documento con su propia rúbrica, antes de la siguiente ronda. Un documento débil no se rescata con una fuerte pizarra.

Fase 3: Análisis profundo del documento de diseño (75 min)

Un panel de dos — el gestor de contratación y un ingeniero de staff o principal — trabaja a través del documento con el candidato. El candidato no presenta; el panel lee el documento de antemano y el tiempo se dedica al seguimiento. El formato:

• Primeros 15 minutos: las alternativas. "Descartaste un enfoque con step-functions. ¿Por qué? ¿Qué cambiaría si nuestro presupuesto de latencia fuera 50 ms en lugar de 5 s?"
• Siguientes 30 minutos: los modos de fallo. Camina a través de cómo el sistema falla bajo tres condiciones específicas que suministras. Observa cómo el candidato actualiza su diseño en tiempo real.
• Últimos 30 minutos: la migración. "Tenemos 47 Lambdas existentes que necesitan migrar a esto. Recórrela conmigo durante los primeros 90 días."

Esta fase prueba las dimensiones 1 y 2 conjuntamente: ¿identificó el candidato el problema correcto, y es realmente defendible su diseño cuando cambian las restricciones?

Fase 4: Ronda de programación (60 min)

Aún requerida, incluso para staff. Dos razones: un ingeniero de staff que no puede escribir código es raro y malo, y la ronda te dice si aún pueden emparejar con ingenieros senior en el trabajo que realmente necesitan hacer.

Salta LeetCode. Usa una ronda de debugging o refactorización en código un poco realista — 200–400 líneas, un bug no trivial, una petición explícita de dejar la base de código en mejor estado de como la encontraron. Evalúa según la rúbrica de programación que usas para candidatos de senior, pero pondera el pensamiento diagnóstico y la calidad de revisión de código más alto que el rendimiento.

Un candidato de staff que fluidamente identifica el bug, nombra dos problemas más que no solucionará, y explica el refactor más pequeño y seguro está haciendo exactamente lo que el trabajo requiere. Uno que programa más rápido que un candidato senior no lo está.

Fase 5: Entrevista de influencia entre equipos (60 min)

Esta es la ronda que la mayoría de rondas de staff no ejecutan, y es la que con mayor fiabilidad atrapa el falso positivo — el ingeniero senior que resuelve problemas brillantemente pero no puede mover a un grupo de equipos.

Una entrevista conductual estructurada, cuatro preguntas profundas, cada una profundizando en un mecanismo diferente:

1. "Cuéntame sobre una posición técnica que sostuviste que fue impopular con el equipo. ¿Qué cambió de opinión a alguien?"
2. "Describe una vez que paraste un proyecto que no debería haber sido enviado. ¿Cómo lo hiciste sin perder la confianza de la gente trabajando en él?"
3. "Recórrela a través del último documento técnico que escribiste que otro equipo adoptó como base para su trabajo."
4. "Cuéntame sobre una vez que mentorizaste a un ingeniero fuera de tu cadena de reporting en algo donde un año después eran mejores que tú. ¿Qué hiciste?"

Las respuestas del candidato deben nombrar personas, documentos, reuniones y resultados. Respuestas vagas — "nos alineamos, construimos consenso, enviamos" — fallan esta ronda. El trabajo es rico en mecanismos; la entrevista debe serlo también.

Fase 6: Bar raiser (45 min)

Un ingeniero de staff o principal desde fuera del equipo, evaluando al candidato contra el estándar de staff de la compañía, no la necesidad del equipo. Su pregunta para sí mismo al final: "¿Querría trabajar con esta persona en un problema que me importara?"

Sostén un debriefing el mismo día con scorecards bloqueadas — el formato importa más en staff porque los desacuerdos son sobre alcance y juicio, no si alguien puede programar, y esos son exactamente los desacuerdos que se disuelven por un entrevistador carismático en la sala.

Qué dejar fuera

Algunas cosas que la ronda de staff no debe incluir, y las razones por las que cada una es una trampa:

• Dos rondas de programación. Una es suficiente. Una segunda no te dice nada nuevo y señala al candidato que no sabes para qué estás contratando.
• Una ronda de diseño de sistemas que es solo "diseña Twitter". Los prompts genéricos prueban memorización. Usa un problema de tu dominio real así el candidato realmente tiene que pensar.
• Una entrevista de "principios de liderazgo" que es la ronda conductual con un nombre diferente. Si ya ejecutas una ronda conductual estructurada, doblarla en una ronda bien diseñada entre equipos es más fuerte que ejecutar dos delgadas.
• Una ronda de presentación, a menos que presentar sea parte del trabajo. Pedir al candidato presentar 30 minutos de trabajo pasado está bien si el papel requiere presentaciones públicas a ingeniería. En caso contrario, prueba la habilidad equivocada.

Calibración de entrevistadores al estándar de staff

La parte más difícil de ejecutar una ronda de staff no es el diseño de la ronda — es asegurar que los entrevistadores saben qué están evaluando. Tres pasos concretos:

1. Escribe guías de puntuación ancladas para cada dimensión. Un 3 de 4 en "calidad de decisión arquitectónica" debe significar algo específico — por ejemplo, "identifica el trade-off de balanceo de carga sin sugerencia y explica el coste de equivocarse". Un 4 debe significar "plantea una restricción que el prompt no contenía y reencuadra el problema". Esta es la misma disciplina de scorecard que funciona a nivel senior, con diferentes anclas.
2. Ejecuta dos debriefings de práctica antes del primero real. Toma dos ofertas de staff recientes (una aceptada, una rechazada) y haz que los entrevistadores de la ronda las evalúen a ciegas, luego debriefing. El punto es superficializar dónde el panel está en desacuerdo sobre qué significa staff, antes de que un candidato real esté en la línea. Esta es exactamente la calibración que la mayoría de equipos saltan y la mayoría se arrepienten de saltarse.
3. Rastrea la tasa de downlevel. Si tu ronda produce una oferta de staff 30% del tiempo y una oferta de senior 50% del tiempo para candidatos que aplicaron a staff, tu entrevista con el gestor de contratación está dejando pasar demasiados candidatos de senior. Si produce un no-hire 60% del tiempo, tu fuente de entrada está equivocada. De cualquier forma, la métrica te dice dónde arreglarlo.

Qué hacer a continuación

Si estás configurando o arreglando una ronda de ingeniero de staff:

1. Escribe la rúbrica de cuatro dimensiones esta semana. Incluso una v1 con anclas aproximadas es mejor que ninguna rúbrica.
2. Añade el documento de diseño escrito si no tienes uno ya. Es la ronda de mayor señal y la más barata de introducir.
3. Reemplaza una de tus rondas de programación con una entrevista de influencia entre equipos. El trade es casi siempre vale la pena.
4. Ejecuta dos debriefings de calibración en candidatos pasados antes de la próxima ronda en vivo.
5. Audita las últimas tres contrataciones de staff contra la rúbrica retrospectivamente. Si dos de ellas puntúan débilmente en una dimensión que no evaluaste, esa es la ronda que te estás perdiendo.

La contratación de staff no es contratación de senior con un diseño de sistemas más largo. Es una rúbrica diferente, una ronda diferente, y un debriefing diferente. Los equipos que se dan cuenta de eso contratan ingenieros de staff que realmente hacen el trabajo. Los que no contratan ingenieros de senior con un título diferente y se preguntan por qué su deuda arquitectónica sigue creciendo.