Qué evaluar antes de entrevistar a un desarrollador de software
En desarrollo, el razonamiento y la forma de resolver importan más que la lista de tecnologías del CV
Abres el CV de un candidato a desarrollador y ahí está todo lo que esperabas: lenguajes, frameworks, una nube de siglas que parece cubrir cada casilla de la vacante. Pero esa lista no responde lo único que de verdad importa cuando el código entra a producción: ¿cómo razona esta persona frente a un problema que nunca vio? ¿Cómo se mueve cuando el requisito está mal escrito, el bug no se reproduce y el resto del equipo espera una respuesta?
En desarrollo, el stack se aprende; la forma de pensar y de colaborar, mucho menos. Contratas a alguien que domina la tecnología de moda y descubres tarde que escribe código que nadie más puede mantener, que no pregunta cuando algo no cuadra, o que se traba ante un problema que no estaba en el tutorial. Por eso conviene evaluar antes de entrevistar: llegar a la conversación sabiendo dónde están las dudas reales, no acumulando siglas.
Por qué el CV no alcanza para este cargo
El CV de un desarrollador es engañosamente sólido. Las tecnologías se listan fácil y casi todas se aprenden con documentación y práctica. Lo difícil de adquirir —y lo que el CV nunca muestra— es cómo razona la persona: cómo descompone un problema ambiguo, qué hace cuando una solución no funciona, cómo decide entre lo rápido y lo mantenible.
Tampoco verás en el CV cómo colabora. Un desarrollador técnicamente fuerte que no explica sus decisiones, no lee el código de otros con apertura o no pregunta a tiempo termina costando más de lo que aporta. El código vive en equipo. El CV te da insumos sobre lo que esa persona declara haber tocado; necesitas evidencia más allá del CV para saber cómo piensa y cómo trabaja con otros.
Qué señales observar más allá del stack
Más que confirmar lenguajes, te conviene mirar señales de razonamiento y de oficio, comparables entre todos los candidatos. Tres que suelen marcar la diferencia:
- Razonamiento para resolver problemas: cómo enfrenta un escenario que no conoce, qué hipótesis prueba y cómo reacciona cuando la primera idea falla.
- Pensamiento estructurado: cómo parte un problema grande en piezas manejables, en vez de atacarlo entero o copiar la primera solución que encuentra.
- Colaboración y comunicación técnica: si explica sus decisiones con claridad y deja el código y el contexto listos para que otro continúe sin adivinar.
Estas señales son comparables cuando las observas con el mismo criterio para todos, no según la impresión que deja una sola entrevista. Ahí es donde una evaluación previa te da un punto de partida común para todo el panel.
Cómo combinar competencias según el cargo
Un desarrollador no se define por una sola competencia. El perfil útil combina razonamiento para resolver problemas, pensamiento estructurado y colaboración, con pesos que cambian según el cargo: un perfil de backend cercano a la arquitectura pide más rigor estructural, mientras que uno que toca producto y conversa con negocio valora más la comunicación. Combinar competencias según el cargo evita el error de evaluar a todos con la misma vara.
Desarrollador
~45 min- Wonderlic (inteligencia)Siempre primero: el razonamiento predice la capacidad de resolver problemas nuevos, no solo de repetir lo conocido. En tecnología, aprender rápido es el activo central.
- Habilidades digitalesMide la fluidez técnica transversal al stack.
- Aprendizaje continuoLas tecnologías cambian; importa más cómo aprende que lo que ya sabe.
- Resolución de problemas complejosDiseñar y depurar exige descomponer problemas con rigor.
- Flexibilidad cognitivaEncontrar soluciones no obvias diferencia a un buen desarrollador.
- Trabajo en equipoEl código se construye en equipo; la colaboración cuenta.
Mira cómo se combinan las competencias para este perfil y ajústalas a tu vacante.
Ver combinación por cargoQué mirar en el reporte antes de la entrevista
Cuando revisas un reporte, el objetivo no es un número que decida por ti, sino una lectura que te prepare. Fíjate en la señal de ajuste al cargo como punto de partida para priorizar a quién entrevistar primero, y luego baja al detalle por competencia. Si alguien muestra razonamiento fuerte pero comunicación más débil, no se descarta: se entrevista con foco en esa brecha.
El reporte también incluye controles de integridad, para que la evidencia que comparas sea confiable entre candidatos. Eso te da un criterio común dentro del equipo de selección, en vez de tres opiniones que no se pueden contrastar. Si trabajas en un entorno técnico, en soluciones para tecnología verás cómo encaja esto en perfiles de desarrollo. El reporte apoya la decisión; el equipo mantiene la decisión final.
Preguntas de entrevista basadas en evidencia
La entrevista rinde mucho más cuando llegas con la evaluación leída. En lugar de repreguntar lo que ya sabes, profundizas donde el reporte mostró dudas. Algunas líneas que funcionan para desarrollo:
- “En la prueba resolviste el caso por un camino directo. Cuéntame cómo lo cambiarías si el sistema tuviera que escalar a diez veces el tráfico.”
- “Describe una vez en que tu primera solución no funcionó. ¿Cómo te diste cuenta y qué hiciste después?”
- “¿Cómo le explicas una decisión técnica a alguien de producto que no programa?”
- “Tu resultado fue alto en razonamiento y más bajo en colaboración. ¿Cómo trabajas cuando heredas código de otra persona?”
Cada pregunta nace de una señal observada. Así decides con respaldo, y contrastas las respuestas con un criterio común en vez de depender de la química del momento. En la biblioteca de recursos encontrarás más guías por cargo para armar estas conversaciones.
En resumen
El CV de un desarrollador te dice qué tecnologías tocó, no cómo razona ni cómo colabora frente a un problema que aún no tiene respuesta. Antes de entrevistar, observa resolución de problemas, pensamiento estructurado y comunicación con señales comparables; combina las competencias según el tipo de desarrollador que necesitas; usa el reporte para priorizar y para preparar preguntas concretas; y entra a la entrevista con evidencia, no con corazonadas. Así inviertes tus horas de entrevista en los candidatos correctos. Puedes empezar viendo la combinación de competencias para desarrollador.
Preguntas frecuentes
¿Qué es más importante en un desarrollador: el stack o la forma de razonar?
Los lenguajes y frameworks se aprenden con documentación y práctica; la forma de razonar frente a un problema nuevo y de colaborar en equipo son mucho más difíciles de desarrollar. Un buen desarrollador descompone problemas ambiguos, reacciona bien cuando su primera solución falla y escribe código que otros pueden mantener. Por eso conviene observar cómo piensa, no solo qué tecnologías lista el CV.
¿Cómo evalúo a un desarrollador antes de entrevistarlo?
Mira señales comparables de resolución de problemas, pensamiento estructurado y comunicación técnica, observadas con el mismo criterio para todos los candidatos. Una evaluación previa te da un punto de partida común y te permite llegar a la entrevista sabiendo dónde profundizar, en vez de apoyarte solo en la impresión que deja el CV.
¿Qué competencias conviene combinar al evaluar a un desarrollador?
Depende del cargo, pero suele combinarse razonamiento para resolver problemas, pensamiento estructurado y colaboración. Un perfil de backend cercano a la arquitectura pide más rigor estructural; uno que conversa con producto y negocio valora más la comunicación. Definir esa mezcla antes evita evaluar a todos con la misma vara cuando los cargos no son iguales.
¿Kokoro decide a quién contratar como desarrollador?
No. Kokoro te ayuda a evaluar antes de entrevistar con señales comparables y controles de integridad, para que priorices a quién entrevistar y prepares preguntas basadas en evidencia. No sustituye la entrevista; la enfoca. El equipo mantiene la decisión final; Kokoro apoya la decisión, no la toma por ti.
¿Cómo uso el reporte para preparar la entrevista de un desarrollador?
Usa la señal de ajuste al cargo para priorizar candidatos y luego baja al detalle de dónde mostró fortaleza y dónde flaqueó. A partir de esas brechas formulas preguntas concretas, como pedir cómo escalaría una solución o cómo trabaja con código heredado, en vez de un interrogatorio genérico. Así decides con respaldo y el equipo mantiene la decisión final.