Entrevista técnica senior: preguntas y red flags que importan

La mayoría de las listas de “preguntas para ingenieros senior” son trivia — invierte una linked list, explica un closure. La trivia te dice que alguien estudió; no te dice que puede ser dueño de un sistema en producción. Esta es la lista opuesta: las señales que realmente probamos, las preguntas que las sacan a flote, y las red flags que reprueban a un candidato aunque el código compile.

Mapea a las tres etapas de cómo validamos ingenieros senior — porque el punto de una entrevista no es la dificultad, es señal por hora. Las tres las hace un fundador.

El principio de fondo no es nuestro. La entrevista estructurada —las mismas preguntas y la misma rúbrica para cada candidato, calificadas de forma independiente— es la práctica de contratación con más evidencia detrás. La mayoría de los loops senior rinden mal no porque las preguntas sean fáciles, sino porque cada entrevistador improvisa una distinta y los puntajes dejan de ser comparables.

Etapa 1 — Live coding: mira el debugging, no la respuesta

Corremos una sesión en pareja de 90 minutos sobre un problema representativo del dominio del candidato — no un puzzle. Que el código pase es lo mínimo. Lo que en realidad estás leyendo es cómo llega ahí.

Preguntas/prompts que funcionan:

• “Acá hay una función que falla intermitentemente en producción. Guíame por cómo encontrarías la causa.” (Mira: ¿forma una hipótesis, o va a los golpes?)
• “Esto funciona. Ahora haz que maneje que el input sea null / la API haga timeout / la lista esté vacía.” (Mira: ¿va a los edge cases sin que se lo pidan?)
• “Cuéntame qué estás pensando antes de teclear.” (Mira: ¿hay un plan, o prueba y error?)

Red flags:

• Se lanza directo a codear sin re-plantear el problema ni las suposiciones.
• Silencios largos — un senior narra los trade-offs; el silencio suele ser adivinar.
• No puede debuggear su propio código cuando le metes una falla pequeña — memorizó el patrón, no lo entiende.
• Trata los edge cases como una ocurrencia tardía, solo cuando se lo piden.

Etapa 2 — Diseño de sistemas: trade-offs y failure modes

Una conversación de arquitectura de 60 minutos. Los juniors describen el happy path; los seniors hablan de qué se rompe y cuánto cuesta. Escuchas cicatrices de producción hands-on, no diagramas de libro.

Preguntas que funcionan:

• “Diseña un sistema para X. Ahora — ¿dónde falla primero bajo 10× de carga, y cómo lo sabrías antes que tus usuarios?”
• “Elegiste una cola / un cache / una segunda base de datos acá. ¿Qué te costó eso? ¿Qué resignaste?”
• “Esto lleva dos años en producción. ¿Cuál es el dolor operativo que el diagrama no muestra?”
• “Un junior de tu equipo propone la versión simple sin el cache. ¿Está equivocado?”

Red flags:

• Solo describe el happy path; nunca ofrece un failure mode.
• Agrega componentes (microservicios, un message bus, sharding) sin nombrar un trade-off — complejidad como reflejo, no como decisión.
• No puede explicar por qué se tomó una decisión pasada, solo qué fue.
• Cada respuesta es un patrón de un blog post, ninguna de algo que realmente operó.

Etapa 3 — Comunicación y ownership: la parte que reprueba a los “buenos coders”

Una conversación no-técnica de 45 minutos, y la que elimina a más ingenieros capaces que cualquiera de las dos etapas técnicas — sobre todo para quien se suma a un equipo de EE. UU. cruzando una zona horaria. Pruebas claridad escrita, hábitos async, y cómo se comporta cuando no está de acuerdo.

Preguntas que funcionan:

• “Cuéntame de algo que shippeaste y luego lamentaste. ¿Qué hiciste al respecto?” (Mira: ownership vs echar culpas.)
• “Tu lead está decidido por un approach que crees equivocado. Guíame por lo que realmente le dices.” (Mira: ¿puede hacer pushback diplomáticamente? Los seniors que no pueden estar en desacuerdo con el liderazgo no son senior.)
• “Escríbeme un status update de dos párrafos para un proyecto que va dos semanas tarde.” (Mira: claridad, accountability, sin enterrar la información clave. Si no puede escribir un update async claro, va a sufrir con un cliente remoto en EE. UU.)
• “¿Qué pieza de código en producción ahora mismo desearías haber escrito diferente?”

Red flags:

• Culpa a equipos/managers pasados por cada falla; no es dueño de ninguna.
• No puede articular un desacuerdo sin ceder al instante o ponerse a la defensiva.
• El inglés escrito colapsa ante cualquier complejidad — sirve para chat, inusable para un design doc.
• Necesita un ticket totalmente especificado para avanzar; se congela ante la ambigüedad en vez de hacer la pregunta correcta.

La lista consolidada de red flags

Si solo recuerdas un screen, cuida estas a lo largo de las tres etapas:

1. Codea antes de entender el problema.
2. Describe solo el happy path.
3. Agrega complejidad sin nombrar un trade-off.
4. Explica qué construyó pero nunca por qué.
5. Culpa, nunca es dueño.
6. No puede estar en desacuerdo sin ceder o ponerse a la defensiva.
7. Comunicación escrita que no sobrevive a la complejidad.
8. Se congela ante la ambigüedad en vez de acotarla.

Por qué es difícil correrlo tú mismo

Nada de esto es secreto — lo difícil es correrlo de forma consistente, en cada candidato, con entrevistadores lo bastante senior para leer las señales. Eso es buena parte de por qué contratar a escala deriva hacia la trivia (es barata de calificar) y por qué los marketplaces optimizan tamaño de catálogo sobre profundidad. Nuestra versión es el trade opuesto: los fundadores corren este mismo screen en cada colocación, lo que pone un techo a cuánta gente podemos colocar y es la razón por la que los ingenieros que colocamos se quedan.

Si prefieres no correr tres etapas por candidato en cada hire, cuéntanos el rol y te presentamos ingenieros que ya lo pasaron.