Casi todas las listas de “preguntas para entrevistar a un ingeniero senior” son de trivia: invierte una lista enlazada, explica qué es un closure, diferencia entre proceso e hilo. La trivia mide cuánto estudió alguien. Un candidato que repasó el fin de semana le gana a otro que lleva cuatro años sosteniendo un sistema de pagos y ya no recuerda la definición de manual. Ninguno de los dos resultados te dice a quién le puedes confiar un sistema en producción.
Escribe cómo se ve una buena respuesta antes de hablar con nadie y reparte las preguntas en tres entrevistas. En la programación en vivo, califica cómo trabaja el candidato más que si las pruebas pasan. En diseño de sistemas, pregunta cuánto costó cada decisión. En la entrevista de comunicación, pídele un reporte de avance por escrito. Las señales de alerta que importan en un senior son de criterio y responsabilidad, no de trivia.
Estas son las preguntas que uso cuando valido ingenieros antes de colocarlos en equipos de clientes. Siguen las tres entrevistas de cómo valido a los ingenieros senior, donde explico el proceso, la prueba pagada y la evidencia detrás de las entrevistas estructuradas. Aquí, en cada pregunta, anoté qué busco oír y qué señales de alerta dejan fuera a un candidato aunque su código funcione. Úsalas y adáptalas, pero lee primero la sección que sigue.
La rúbrica se escribe antes de la entrevista
Una pregunta es la mitad de la herramienta. La otra mitad es decidir de antemano qué tiene que tener una buena respuesta. La guía de re:Work de Google sobre entrevistas estructuradas (en inglés) recomienda documentar para cada pregunta ejemplos de respuesta mala, dudosa, sólida y sobresaliente, y que todos los entrevistadores califiquen con esa misma escala.
En la práctica, junto a cada pregunta tengo unas pocas líneas: qué menciona una respuesta senior, qué suele faltarle a una de nivel medio y qué descalifica. Pongo mis notas antes de comentar al candidato con nadie. Apenas alguien dice “a mí me cayó muy bien”, las notas de todos empiezan a parecerse.
¿Qué preguntar en una prueba de programación en vivo para un senior?
Noventa minutos, en pareja, sobre un problema con la forma del trabajo real. Que las pruebas pasen se da por hecho, así que la nota sale de cómo llegó ahí. Estas cuatro consignas son donde miro, con cómo suena una respuesta fuerte y una señal de alerta:
| Consigna | Candidato fuerte | Señal de alerta |
|---|---|---|
| “Esta función falla de forma intermitente en producción. ¿Cómo averiguas por qué?” | Plantea una hipótesis, elige la forma más barata de probarla y va acotando | Cambia código al azar hasta que algo pasa |
| “Ya funciona. Ahora la entrada llega en null, la API no responde, la lista está vacía.” | Ya había pensado en al menos uno de esos casos | Cada caso lo sorprende y los va parcheando uno por uno |
| “Antes de escribir, cuéntame tu plan.” | Reformula el problema y dice qué está suponiendo | Se pone a teclear de inmediato y explica después |
| Le rompes algo pequeño en su código sin avisar | Lee el error y lo encuentra rápido | No puede depurar lo que escribió hace diez minutos |
La última fila es mi favorita. Quien memorizó un patrón lo puede repetir. Si lo entiende o no, se ve cuando se rompe y tiene que arreglarlo.
Fíjate también en los silencios largos. Hay gente que piensa callada, y un minuto está bien. Pero un ingeniero senior en un equipo remoto se pasa buena parte del tiempo explicando su razonamiento a personas que no ven su pantalla. Cuando un candidato no logra narrar mientras programa, muchas veces es porque está adivinando.
Sobre los asistentes de código con IA: define tu regla antes de la entrevista y escríbela en la rúbrica. Si tu equipo los usa todos los días, prohibirlos mide algo que la persona no va a hacer en el trabajo. Si los permites, califica si el candidato lee y cuestiona lo que la herramienta le da. Aceptar una función generada sin revisarla ya es una señal de alerta.
¿Qué preguntas de diseño de sistemas muestran experiencia real?
Sesenta minutos de arquitectura. La forma más rápida de distinguir a quien operó sistemas de quien leyó mucho sobre ellos es dejar de pedir el diseño y empezar a preguntar por las consecuencias.
- “Diseña X. Ahora dime dónde falla primero con diez veces la carga, y cómo te enterarías antes que tus usuarios.”
- “Aquí agregaste una cola. ¿Qué te costó? ¿Qué se volvió más difícil?”
- “Esto lleva dos años en producción. ¿Qué dolor operativo no aparece en el diagrama?”
- “Un junior de tu equipo propone la versión sin caché. ¿Está equivocado?”
La cuarta pregunta atrapa a mucha gente. Una buena respuesta suele ser “puede que no”, seguida de las condiciones en las que la caché vale lo que cuesta. Un candidato que defiende cada componente que dibujó, sin poder decir el precio de cada uno, tiende a agregar complejidad por reflejo.
Lo que reprueba:
- Solo describe el caso ideal. Ningún modo de falla aparece si no lo sacas tú.
- Aparecen microservicios, un bus de mensajes o sharding sin que diga qué se sacrifica.
- Puede contarte qué hacía un sistema anterior, pero no por qué se construyó así.
- Todas las respuestas suenan a charla de conferencia, y ninguna a algo por lo que lo despertaron a las 3 de la mañana.
Comunicación y responsabilidad: donde fallan los buenos programadores
Cuarenta y cinco minutos, sin código. En mi experiencia es aquí donde se caen más candidatos técnicamente fuertes, y por eso tiene su propia entrevista en lugar de dos preguntas al final de una técnica. Pesa todavía más si la persona va a entrar de forma remota a un equipo en EE. UU., donde casi todo el día es por escrito.
“Cuéntame de algo que pusiste en producción y después lamentaste. ¿Qué hiciste?” Escucha quién es el sujeto de las oraciones. “Yo” cuando algo salió mal es buena señal. “Ellos”, todas las veces, no.
“Tu líder se decidió por un enfoque que te parece equivocado. ¿Qué le dices, concretamente?” Buscas un desacuerdo específico y respetuoso, con una razón y una alternativa. Ceder al instante y ponerse a la defensiva reprueban igual.
“Escríbeme un reporte de avance de dos párrafos para un proyecto que va dos semanas atrasado.” Dale diez minutos y un documento compartido. El atraso va en la primera oración, con la causa y el siguiente paso. Si queda enterrado bajo el contexto, vas a leer reportes así todas las semanas.
“¿Qué código que está hoy en producción te habría gustado escribir distinto?” Cualquiera con experiencia real tiene una respuesta. “No se me ocurre nada” es raro de oír en un senior.
Señales de alerta de esta etapa: culpar a los equipos anteriores de cada falla, necesitar un ticket completamente especificado para arrancar, y un inglés escrito que sirve para chatear pero se desarma en un documento de diseño. Para un puesto remoto, eso último importa más que el acento.
Las ocho señales de alerta que vigilo en las tres etapas
Estas atraviesan todas las entrevistas. Cada una la tomo en serio por sí sola, por limpio que haya salido el código.
- Empieza a programar antes de entender el problema.
- Solo describe el caso ideal.
- Agrega complejidad sin decir qué sacrifica.
- Explica qué construyó, nunca por qué.
- Culpa a otros y nunca asume su parte.
- No sabe discrepar sin ceder o ponerse a la defensiva.
- Su escritura se desarma cuando el tema se complica.
- Se paraliza ante la ambigüedad en vez de hacer preguntas para acotarla.
Empieza con tres preguntas
No necesitas todo lo anterior para mejorar tu proceso de selección. Elige tres preguntas, una por etapa. Para cada una, escribe dos o tres líneas sobre qué incluye una respuesta fuerte y qué la descalifica. Hazles esas mismas tres a todos los candidatos del puesto, y pide que cada entrevistador califique por su cuenta antes de la reunión de cierre. Solo con eso tu proceso ya va a ser más consistente que la mayoría.
Las preguntas son lo fácil. Lo que cuesta es aplicarlas igual a cada candidato, con entrevistadores con la experiencia suficiente para leer las respuestas. Si prefieres no llevar este proceso en cada contratación, cuéntame qué rol necesitas y te presento ingenieros que ya pasaron por él.