Cómo evaluar a desarrolladores senior: competencia, evidencia y un proceso justo

Para evaluar bien a un ingeniero de software senior, pruebe el trabajo, no el currículum. Defina las competencias que necesita el puesto, haga a todos los candidatos las mismas preguntas estructuradas, puntuadas con criterios escritos, y obsérvelos haciendo una parte realista del trabajo: escribir y probar código, diseñar un sistema, revisar el cambio de otra persona. Décadas de investigación muestran que las entrevistas estructuradas y las pruebas específicas del puesto predicen el rendimiento mucho mejor que las conversaciones libres, mientras que los años de experiencia apenas lo predicen.

Esta guía es para CTO, responsables de ingeniería y fundadores que contratan ingenieros senior, ya sea en plantilla o a través de un socio. Explica qué es la competencia, qué dice la evidencia, un proceso de cinco fases que cabe en una semana, qué evitar, qué cambia en los equipos de habla alemana y cómo mantener el nivel una vez que la persona ha empezado.

#Qué es la competencia más allá de los años de experiencia

«Senior» en un currículum suele significar un número de años. En un equipo significa otra cosa: la persona a la que puede dar un problema ambiguo y que vuelve con una solución que funciona, probada y mantenible, tras hacer por el camino las preguntas adecuadas. Ocho competencias describen a esa persona. Anote cuáles importan más para su puesto antes de leer un solo currículum: esa lista se convierte en su plan de entrevistas y en su hoja de evaluación.

Fíjese en lo que falta: años con un framework, certificaciones, un título. Pueden ser un contexto útil, pero ninguno indica si la persona sabe hacer el trabajo para el que contrata. Exigir un número cerrado de años («siete años de Kotlin») además descarta a ingenieros sólidos que aprendieron el lenguaje el año pasado sobre una década de buen trabajo de backend.

#Qué dice la investigación sobre los métodos de selección

El resumen más citado de la investigación sobre selección es el de Schmidt y Hunter (1998), que reunió 85 años de estudios sobre la capacidad de los métodos de selección para predecir el rendimiento laboral. En 2022, Sackett, Zhang, Berry y Lievens revisaron esas estimaciones en el Journal of Applied Psychology. Concluyeron que las correcciones anteriores sobrestimaban la validez, rebajaron la mayoría de los valores entre 0,10 y 0,20 y situaron las entrevistas estructuradas en primer lugar.

De ahí salen tres lecciones para contratar ingenieros. Primera, la estructura duplica aproximadamente el valor de una entrevista: la misma hora, con las mismas preguntas para todos y respuestas puntuadas con criterios escritos, se correlaciona con el rendimiento posterior más o menos el doble que una conversación libre. Segunda, los mejores predictores son todos específicos del puesto: entrevistas sobre el trabajo real, pruebas de los conocimientos necesarios, muestras del propio trabajo. Sackett y sus colegas lo señalan expresamente. Tercera, los años de experiencia casi no sirven como predictor por sí solos, y por eso no deberían ser el primer filtro de su proceso.

#Un proceso de evaluación justo para ingenieros senior

El proceso siguiente cubre las ocho competencias en cinco fases y le lleva al candidato entre cuatro y seis horas en total, repartidas en aproximadamente una semana. Cada fase tiene un propósito claro, preguntas o tareas fijas y una hoja de evaluación que el entrevistador rellena antes de hablar con nadie.

1. Entrevista estructurada (60 minutos)

Haga a todos los candidatos las mismas cinco o seis preguntas sobre trabajo real anterior, con repreguntas planificadas. «Hábleme de un incidente en producción del que se ocupó desde la alerta hasta la solución. ¿Qué cambió después?» mide la responsabilidad. «Describa una decisión técnica contra la que argumentó y perdió. ¿Qué pasó?» mide la comunicación y el criterio. Puntúe cada respuesta en una escala de 1 a 4 con ejemplos escritos de cómo suena un 2 y un 4, para que dos entrevistadores entiendan lo mismo por «sólido».

2. Prueba de trabajo realista o sesión de pair programming (90 a 120 minutos)

Proponga una tarea pequeña y acotada de su dominio real: añadir una funcionalidad a un repositorio preparado, arreglar un test que falla, ampliar un endpoint de una API. Hágala en directo como sesión de pair programming con uno de sus ingenieros, en el editor del candidato si lo prefiere. Verá cómo lee código desconocido, pregunta, prueba y explica. El candidato, a su vez, ve cómo trabaja su equipo, y eso también forma parte de un proceso justo.

3. Conversación de diseño de sistemas (60 minutos)

Elija un sistema cercano a lo que la persona va a construir: un servicio de reservas, un flujo de facturación, un sistema de notificaciones. Empiece por los requisitos y deje que el candidato pregunte por la carga, los datos y los fallos. Los buenos perfiles senior hablan de concesiones, de modelos de datos, de qué ocurre cuando cae una dependencia y de cómo lanzarían una primera versión y la harían evolucionar. Puntúe el razonamiento, no que dibuje su arquitectura.

4. Ejercicio de revisión de código (45 minutos)

Muestre un pull request realista de 150 a 300 líneas con problemas sembrados: una comprobación de autorización ausente, un caso límite sin test, un nombre confuso, una consulta dentro de un bucle. Pida al candidato que lo revise como lo haría para un compañero. Este único ejercicio muestra calidad del código, testing, conciencia de seguridad y tono. Quien encuentra el fallo de control de acceso y redacta sus comentarios con amabilidad es escaso y valioso.

5. Referencias (dos llamadas de 20 minutos)

Hable con dos personas que el candidato indique, idealmente un antiguo responsable y un compañero, y siempre con su consentimiento. Haga cada vez las mismas preguntas estructuradas: de qué se responsabilizaba, cómo gestionaba un desacuerdo, si volvería a trabajar con esa persona y en qué papel. Las referencias rara vez cambian una decisión por sí solas, pero pueden confirmar o despejar una duda de las otras fases.

#Puntuación y decisión de contratación

La mayoría de las malas contrataciones no nacen de malas entrevistas, sino de una mala reunión de decisión, en la que la voz más fuerte o de mayor rango marca el resultado. Tres hábitos lo evitan. Los entrevistadores entregan su hoja de evaluación antes de la reunión y no hablan del candidato antes. La reunión repasa las competencias una a una, con evidencias («no vio la comprobación de autorización, la encontró tras una pista») y no con adjetivos («parecía brillante»). Y el responsable de la contratación decide frente al nivel fijado antes de la búsqueda, no frente a los otros candidatos de esa semana.

Mantenga el nivel aunque tenga prisa. Una vacante abierta un mes más cuesta menos que un ingeniero senior del que tenga que prescindir a los seis. Si nadie alcanza el nivel, lo siguiente es comprobar si el nivel se ajusta al puesto, no rebajarlo para el próximo candidato.

#Qué evitar

• Acertijos y preguntas de ingenio. «¿Cuántas ventanas hay en Nueva York?» dice poco sobre ingeniería. El entonces responsable de personas de Google calificó estos acertijos de «a complete waste of time» (ABC News, 2013), y Highhouse, Nye y Zhang (2018) los describen como carentes de pruebas de validez e inquietantes para los candidatos.
• Pruebas largas sin remunerar para hacer en casa. Una prueba de más de dos o tres horas selecciona por tiempo libre, no por capacidad, y muchos ingenieros senior con trabajo y familia la rechazan. Manténgalas breves y acotadas, pague el trabajo más largo o sustitúyalas por una sesión de pair programming en directo.
• Algoritmos sin relación con el puesto. Invertir un árbol binario en una pizarra mide el entrenamiento para entrevistas. Salvo que el puesto implique de verdad ese tipo de trabajo, evalúe los problemas que la persona va a resolver.
• Charlas sin estructura sobre el «encaje cultural». Una conversación agradable sin preguntas fijas es la forma más débil de entrevista y la puerta de entrada de los sesgos. Evalúe la colaboración y los valores con preguntas estructuradas, como todo lo demás.
• Un proceso lento. Los buenos perfiles senior suelen tener varias opciones. Mantenga todo el proceso en unas dos semanas y explique al principio qué incluye cada fase.

#Idioma, colaboración y equidad en equipos DACH

Muchos equipos de ingeniería en Alemania, Austria y Suiza trabajan en inglés mientras el negocio que los rodea habla alemán. Decida qué idioma necesita de verdad cada parte del puesto y descríbalo con los niveles del Marco Común Europeo de Referencia (MCER) en lugar de «fluido». Quien trabaja en un equipo de habla inglesa quizá necesite el alemán solo para el día a día; quien dirige talleres con usuarios germanohablantes o lee especificaciones en alemán necesita mucho más. Evalúe el idioma donde importa, por ejemplo haciendo en alemán la conversación de diseño de sistemas.

Los hábitos de trabajo importan tanto como el idioma. En los equipos DACH se suele esperar que las decisiones se pongan por escrito, se acuerden y luego se respeten, y la crítica directa en la revisión de código es normal. Pregunte en la entrevista estructurada cómo gestiona el candidato a un revisor que no está de acuerdo y cómo documenta una decisión.

En Alemania, un proceso estructurado es además su mejor protección. Según la Ley General de Igualdad de Trato (AGG), si un candidato rechazado aporta indicios de discriminación por un motivo protegido, es el empleador quien debe demostrar que no la hubo (§ 22 AGG). Las preguntas escritas, las hojas de evaluación y las decisiones basadas en evidencias lo hacen posible. Las reclamaciones deben presentarse por escrito en los dos meses siguientes a la recepción del rechazo, y la indemnización para quien no habría sido contratado de todos modos tiene un tope de tres mensualidades (§ 15 AGG).

Dos costumbres locales afectan a las referencias. En Alemania, los empleados tienen derecho a un certificado de trabajo escrito al marcharse (Arbeitszeugnis), que por ley debe ser claro y no puede contener mensajes en clave (§ 109 GewO); en la práctica sus fórmulas habituales se siguen leyendo como una escala de notas, así que tómelo como contexto, no como prueba. Y contacte con las referencias solo con el consentimiento del candidato, preferiblemente con personas que él mismo haya indicado, porque está recogiendo datos personales sobre él.

#Mantener el nivel después del primer día

La entrevista fija un mínimo; los hábitos diarios del equipo fijan el nivel real. Un buen ingeniero en un equipo sin revisiones, tests ni documentación acabará escribiendo código como los demás. Cuatro hábitos mantienen el nivel donde usted contrató.

• Revisión de código en cada cambio. La guía pública de Google dice que un revisor debe aprobar un cambio en cuanto mejora claramente la salud general del código, aunque no sea perfecto, y que los comentarios que ayudan a aprender son siempre bienvenidos. Ese equilibrio mantiene la revisión ágil y la convierte en una herramienta de aprendizaje.
• Pair programming en las primeras semanas. Ponga a la persona nueva a trabajar con alguien experimentado en tickets reales. Transmite el conocimiento no escrito de un código más rápido que cualquier documento y le muestra pronto si la contratación funciona.
• Los tests como parte de «terminado». Un cambio sin tests del comportamiento que añade no está terminado. Las comprobaciones automáticas en el pipeline lo convierten en una regla del equipo y no en una discusión personal.
• Documentación al día. Una visión general breve de la arquitectura, registros de decisiones para lo que es caro de revertir y runbooks para producción. Los ingenieros nuevos deberían actualizarlos durante su incorporación, lo que además es la mejor prueba de lo buenos que son.

Revise la contratación con honestidad al cabo del primer mes y del tercero, con las mismas competencias que evaluó. Si algo no funciona, dígalo pronto: es más justo para la persona y para el equipo.

#Lista de control para contratar a un ingeniero senior

#Cómo elegimos a los ingenieros en Bespoke IT

En Bespoke IT, los ingenieros que construyen nuestros propios productos revisan cada perfil que proponemos, en lugar de un reclutador que busca palabras clave en el currículum. Antes de firmar nada, usted conoce al ingeniero en una sesión de trabajo sobre su propio problema y, si el encaje no es el adecuado, traemos al siguiente. Trabaja en su repositorio, con sus herramientas y sus rutinas. Vea cómo funciona nuestro servicio de talento, calcule el coste de un equipo o díganos a quién necesita. Si está comparando un equipo junior más grande con uno senior más pequeño, nuestro artículo sobre por qué un equipo de desarrollo senior analiza las ventajas y los inconvenientes.