Cómo diseñar un proceso de entrevistas técnicas justo y eficaz

Seguro que te suena. Un candidato que en la primera llamada parecía perfecto desaparece en cuanto recibe la prueba técnica para casa. O pasa lo contrario: contratas a alguien que resolvió de maravilla un ejercicio de algoritmos y a los pocos meses ves que le cuesta justo lo que el puesto le pide cada día.

Las dos situaciones suelen tener el mismo origen, un proceso de entrevistas que mide lo que no toca o que lo mide de forma distinta según quién entreviste. Cuando una empresa nos pide ayuda para revisar su proceso técnico, casi todo lo que tocamos tiene que ver con la claridad. Qué se mide, con qué prueba y con qué criterio.

Decide qué quieres medir antes de elegir la prueba

El error más común es montar las entrevistas por costumbre (“aquí siempre hacemos una prueba de algoritmos”) en lugar de partir del puesto. Antes de pensar en formatos, haz una lista de lo que de verdad marca la diferencia en ese rol. Para un backend senior, por ejemplo, podría ser el diseño de sistemas y el criterio para elegir entre alternativas, la calidad del código que deja (legibilidad, tests, mantenimiento), cómo depura un problema en producción, cómo se entiende con producto y con otros equipos, y hasta dónde llega por su cuenta antes de pedir ayuda.

Luego asigna cada competencia a una fase. Si alguna no aparece en ninguna, acabarás decidiendo por intuición. Si aparece en tres, estás haciendo perder el tiempo al candidato y a tu equipo.

Cuanto más se parezca al día a día, mejor

Ningún formato es perfecto, y conviene saber qué te da cada uno.

El ejercicio para casa deja trabajar con calma, pero penaliza a quien tiene menos tiempo libre, que muchas veces es justo quien más responsabilidades tiene. Si lo usas, limítalo a unas pocas horas y dilo claramente al enviarlo.

El pair programming en directo enseña cómo piensa y colabora la persona, siempre que el problema sea realista y no un acertijo. La revisión de código, en la que el candidato comenta un fragmento con errores, dice mucho de su criterio y de cómo da feedback. En perfiles senior, una sesión de diseño de sistemas es casi obligatoria, y ahí lo que cuenta es el razonamiento más que llegar a una respuesta concreta. Hablar de un proyecto propio funciona muy bien cuando la persona puede enseñar trabajo real, aunque por confidencialidad no todo el mundo puede.

Nuestra regla es sencilla: la prueba que más se parece al trabajo es la que mejor información te da.

Poneos de acuerdo en cómo puntuar

Sin criterios previos, cada entrevistador valora cosas distintas y el resultado depende de con quién le toque hablar al candidato. Un par de hábitos lo arreglan casi todo. Una rúbrica sencilla por competencia, que describa cómo es una respuesta floja, una adecuada y una excelente. Las mismas preguntas base para todos los candidatos del proceso. Y que cada entrevistador escriba su puntuación antes de comentarla con los demás, para que la primera opinión que se oiga no arrastre al resto.

Los sesgos no desaparecen del todo, pero se pueden reducir bastante. Cambia la pregunta “¿encajaría en el equipo?” por los comportamientos concretos que valoras. Procura que el panel sea variado. Revisa si alguna prueba premia algo que no tiene que ver con el puesto, como recordar de memoria detalles que cualquiera consultaría en la documentación. Y pregunta abiertamente al inicio si alguien necesita alguna adaptación.

El candidato también te está evaluando

Es fácil olvidarlo cuando el proceso se diseña desde dentro. Un proceso técnico razonable cabe en tres o cuatro fases, y a partir de ahí cada fase extra debería justificar qué aporta que no hayas visto ya. Hay cosas que la gente agradece mucho:

• Conocer desde el principio todas las fases, cuánto duran y quién participa.
• Saber con antelación el formato de cada prueba, porque no estás midiendo cómo reacciona a una sorpresa.
• Tener respuesta en pocos días después de cada fase.

Prepara también a quien entrevista. Un buen ingeniero no es automáticamente un buen entrevistador. Dedica un rato a explicar qué evalúa cada fase y cómo usar la rúbrica, cómo dar pistas sin resolver el problema, qué preguntas no se pueden hacer (vida personal, planes familiares, edad, origen) y cómo presentar la empresa y el equipo.

Una estructura que suele funcionar

Para un perfil de ingeniería con experiencia solemos proponer algo así: una conversación inicial sobre trayectoria, motivación y condiciones; una prueba práctica acotada y relacionada con el trabajo; una sesión de diseño de sistemas o de revisión de esa prueba con el equipo; y una entrevista final con el responsable sobre colaboración, valores y expectativas.

Al terminar, una reunión corta en la que cada persona presenta sus puntuaciones y sus argumentos. Antes de empezar, deja claro quién tiene la última palabra y qué pasa si hay desacuerdo. Y de vez en cuando mira hacia atrás. ¿La gente que contrataste está rindiendo bien? ¿Los candidatos que abandonan lo hacen siempre en la misma fase?

Cuando alguien no pasa

Es la parte que más se descuida. Si alguien ha dedicado varias horas a tu prueba y le descartas, mándale un feedback breve y concreto sobre lo que estuvo bien y lo que faltó. Cuesta poco, y es lo que hace que esa persona hable bien de tu empresa aunque no haya entrado (y quizá vuelva a presentarse dentro de un par de años).

En Mimmic Talent evaluamos a los candidatos antes de presentártelos, y nos gusta repasar el proceso técnico con quienes van a entrevistar. Si te apetece contrastar el tuyo, cuéntanoslo.