Cuando una empresa me pide un ingeniero senior, casi siempre la primera pregunta es de dónde es. A mí me parece más útil otra: quién decidió que era senior. En muchas agencias de staff augmentation esa decisión la toma un reclutador con una lista de verificación: años de experiencia, los frameworks que aparecen en el CV y una llamada corta para confirmar que habla bien inglés. Nada de eso te dice si la persona puede hacerse cargo de un sistema en producción cuando nadie la está supervisando.
Así lo hago yo. Cada ingeniero que Softronic coloca pasa por tres entrevistas que conduzco personalmente: 90 minutos de programación en vivo con el stack del cliente, 60 minutos sobre un sistema que haya mantenido en producción y 45 minutos sobre comunicación y responsabilidad. Después vienen dos semanas de prueba pagada con trabajo real, antes de entrar al equipo de un cliente. Ningún reclutador los filtra antes que yo.
Es más lento y limita cuánta gente puedo colocar. Lo acepto. Aquí explico para qué sirve cada etapa y por qué existe. Las preguntas en sí, con las respuestas que califico como fuertes o flojas, están en otro artículo: entrevista técnica senior: preguntas y señales de alerta.
| Etapa | Duración | Qué califico | Quién la conduce |
|---|---|---|---|
| 1. Programación en vivo con el stack del cliente | 90 minutos | Cómo depura, si pregunta antes de suponer, cómo razona las decisiones técnicas | Yo |
| 2. Un sistema que mantuvo en producción | 60 minutos | Si puede nombrar una decisión que desharía, cómo piensa la carga y las fallas | Yo |
| 3. Comunicación y responsabilidad | 45 minutos | Claridad por escrito, discrepar con respeto, asumir sus errores | Yo |
| 4. Prueba pagada | 2 semanas | Si lo que vi en las entrevistas se sostiene con trabajo real | Softronic, con trabajo que paga, antes de entrar al equipo del cliente |
¿Por qué todos los candidatos reciben las mismas preguntas?
En 2022, Sackett y sus colegas reanalizaron décadas de estudios de selección de personal y las entrevistas estructuradas quedaron en el primer lugar como predictor del desempeño laboral, con una validez media de 0,42, por encima de las pruebas de capacidad cognitiva general (0,31). Hay un buen resumen del estudio en la revista de SIOP (en inglés). En una entrevista estructurada, todos los candidatos a un mismo puesto reciben las mismas preguntas y cada respuesta se califica con la misma rúbrica. La guía de re:Work de Google sobre entrevistas estructuradas aterriza la parte práctica: antes de hablar con nadie, escribe cómo se ve una respuesta mala, dudosa, sólida y sobresaliente.
La mayoría de los procesos técnicos que he visto se saltan esto. Cada entrevistador improvisa, las preguntas cambian de un candidato a otro y al final gana quien defiende su opinión con más fuerza en la reunión de cierre. La consistencia corrige eso mucho mejor que unas preguntas más difíciles.
Mi rúbrica es corta. Antes de cada llamada anoto qué debería incluir una respuesta senior en cada pregunta, y apenas termina califico contra esas notas. Todos los que se postulan a un mismo tipo de puesto reciben las mismas preguntas.
Etapa 1: programación en vivo con el stack del cliente (90 minutos)
No uso acertijos de algoritmos. Saber invertir un árbol binario en una pizarra dice muy poco sobre si alguien va a descubrir por qué el endpoint de pagos se cae una vez por semana.
Lo que hacemos es trabajar en pareja durante 90 minutos sobre un problema parecido al trabajo real del cliente. Si el equipo usa Next.js y Postgres, el ejercicio es en Next.js y Postgres. Si son servicios en Go, es en Go. El problema se puede terminar en el tiempo, y tiene huecos a propósito: un requisito que no mencioné, un caso de entrada que la descripción no cubre. Las tareas del cliente también van a tener huecos así, y quiero ver si el candidato los nota y pregunta, o si elige una interpretación en silencio y construye encima.
Que el código funcione es lo mínimo. Dos candidatos pueden terminar el ejercicio y solo uno haber explicado su plan antes de escribir, haber cubierto la lista vacía sin que se lo pidiera y haber dicho qué probaría después. Ese es el que busco. Las consignas que uso y cómo califico cada una están en el banco de preguntas.
Un CV largo en una empresa conocida predice esta etapa menos de lo que uno pensaría. Quien siempre recibió especificaciones detalladas a veces se traba cuando el problema está incompleto. Quien trabajó en equipos pequeños, tomando decisiones de producto por su cuenta, suele moverse cómodo ahí.
Etapa 2: un sistema que haya mantenido (60 minutos)
La segunda entrevista es de arquitectura, pero no parto de un diseño hipotético. Le pido al candidato que me explique un sistema que haya sostenido en producción: el modelo de datos, dónde se puso lento, qué se rompió, qué cambiaría si empezara de cero. Parto de un sistema real porque un diseño hipotético mide sobre todo cuánto ha leído alguien, y el cliente está pagando por alguien que ha operado sistemas.
La mejor señal de esa hora es el arrepentimiento. Alguien que puede nombrar una decisión concreta que desharía, explicar cuánto le costó y describir la alternativa convivió con ese sistema el tiempo suficiente para ver las consecuencias. Alguien que se queda en “lo escalamos a millones de usuarios” y no sabe decir dónde estaba el cuello de botella, por lo general leyó más sobre ese sistema de lo que lo operó.
La última parte de la hora es sobre carga y fallas: dónde se rompe primero el sistema cuando crece el tráfico y cómo se enteraría antes que sus usuarios. Las buenas respuestas casi siempre empiezan con “depende” y enseguida dicen de qué, en concreto.
Etapa 3: comunicación y responsabilidad (45 minutos)
Es la entrevista más corta y la que deja fuera a más gente que venía bien en las dos primeras. No tiene código.
Un ingeniero latinoamericano dentro de un equipo en EE. UU. pasa buena parte del día escribiendo: descripciones de pull requests, hilos de Slack, documentos de diseño, reportes para un gerente con el que quizá habla en vivo una vez al día. Si esa escritura es confusa, el cliente lo nota en la primera semana, por bueno que sea el código.
El ejercicio que más me enseña es un reporte de avance corto, por escrito, sobre un proyecto que va atrasado. Uno bueno dice en la primera oración que el proyecto va tarde, explica por qué sin culpar a nadie y propone el siguiente paso. Uno flojo esconde el atraso debajo de tres párrafos de contexto. El resto de la hora es conversación sobre desacuerdos y errores pasados, y ahí escucho si el candidato sabe discrepar con respeto. Un ingeniero que le da la razón en todo al líder le está vendiendo al cliente horas de senior sin el criterio de un senior.
Después, dos semanas de prueba pagada
Una entrevista es una muestra, y hasta la más cuidadosa se equivoca. Antes de que alguien entre al equipo de un cliente, pasa dos semanas haciendo trabajo real que paga Softronic. Si lo que vi en las entrevistas no se sostiene, ese costo lo asumo yo y no el cliente. De todo el proceso, es el paso que menos estaría dispuesto a quitar, y creo que tiene mucho que ver con por qué las colocaciones duran.
Lo que ve el cliente
Casi todo esto pasa antes de que conozcas a nadie. Me cuentas el rol y el stack, conduzco las entrevistas sobre ese stack y te presento candidatos en 14 días desde la primera llamada. Nadie entra a tu equipo antes de terminar la prueba pagada, y esa prueba no se te factura. Si más adelante el encaje no funciona, nos das 30 días de aviso y la relación termina, sin penalidades.
¿Cómo revisar la validación de un proveedor?
No publico una tasa de aprobación, porque no llevo un registro de postulantes lo bastante riguroso como para defender un “solo el 3% pasa”. Lo que sí te puedo decir es que trabajar así significa que coloco pocos ingenieros.
Trabajes conmigo o con otro proveedor, dos preguntas sobre la validación te dicen mucho:
- ¿Quién conduce la entrevista técnica, y ha trabajado con el stack que está evaluando?
- ¿Hay una rúbrica escrita? ¿La puedo ver?
Una respuesta vaga a cualquiera de las dos ya dice bastante. El resto de lo que yo le preguntaría a un proveedor, desde de quién es el código hasta cuánto te cuesta terminar la relación, está en mi lista para evaluar un proveedor nearshore. Si estás comparando las grandes plataformas con un estudio pequeño, escribí sobre Toptal, Andela y las alternativas más pequeñas.
Y si prefieres delegar todo el proceso, cuéntame qué rol necesitas.