Una de las muchas cosas que me molestan en LinkedIn es el post de "cómo entrevistar a los desarrolladores". Hay toneladas de ellas, y casi todas caen en tres campos:
A lo largo de los años he entrevistado docenas de veces y contratado cientos de desarrolladores para varias empresas - desde Microsoft y Dell a pequeñas startups. También tuve una vida anterior como un psicólogo investigador especializado en psicometría (la ciencia de la medición de las capacidades mentales). Así que he visto el proceso desde cada Side.
El código de escritura a menudo no es una actividad social. Claro - las habilidades blandas importan. Pero a menudo son ortogonales a la práctica real de escribir código para resolver problemas reales del usuario.
¿Cómo entrevistar a alguien para un trabajo que es mayormente sobre escribir código?
Nuestra profesión también está llena de síndrome impostor - Lo he visto en mí mismo y en innumerables otros. ¿Cómo entrevista a alguien que ya ¿Se siente como un fraude?
Y a menudo somos un socialmente incómodo grupo Una entrevista que es a la vez estresante y requiere que la solución de problemas en vivo sea una receta para el desastre.
¿Cómo entrevista a alguien que está nervioso, incómodo o que ya duda de sí mismo?
Ni lo sueñes. iniciar a menos que su experiencia se alinee. Eso respeta su tiempo y La tuya.
Que el proceso sea claro y humano, lo que significa:
Ser a tiempoSi llegan tarde, dales unos minutos, es probable que no estén en reuniones consecutivas como tú.
Pregúntate: ¿Encajarían al equipo temperamentalmente? Un codificador brillante que es un idiota es una pérdida neta.
Después de años de preguntas de Fibonacci y maratones de listas enlazadas, aprendí una verdad central:
A los codificadores les encanta hablar de código que conocen.
Ese es el secreto, y sólo funciona si el entrevistador realmente entiende lo que se muestra, si no conoces el marco (Angular, React, lo que sea) sigue bien, concéntrate en la estructura, la claridad, el nombre, la intención.
Así que diles por adelantado (5 días es justo) que usted querrá discutir el código que han escrito. Sin presión. Sin truco. Sólo: Muéstrame algo de lo que puedas hablar.
Es posible que no tengan GitHub – eso está bien. Un fragmento personal o de trabajo está bien. El objetivo no es encontrar el genio. Es encontrar propiedad.
No estás contratando basándote en cuánto tiempo libre tiene alguien.
I Personalmente deja entrevistas de codificación en estos días. Me hace más ansioso - aunque he construido cientos de sistemas.
He aquí por qué este enfoque es mejor:
Candidatos jóvenes puede necesita una pequeña prueba práctica - pero mantenerlo humano. No los haga refactorizar un archivo heredado de 4.000 líneas.
Pregunta sobre bucles, condiciones, lo básico del mundo real, mantenlo atado al trabajo.
Muchas personas los usan diariamente sin saber el nombre. No se cuelguen en las etiquetas.
¿Acertijos lógicos? Nunca los necesitó en un trabajo real. Nunca vio un uso real para saber cuántos afinadores de piano existen en Nueva York.
Si el candidato consigue el papel o no - Seguimiento.
Si no lo consiguieron: Explíqueme por qué. Dales algo útil para que se lo lleven.
Si lo consiguieron: Diles qué esperar a continuación. Deja que respiren.
Porque en última instancia:
Una entrevista debe revelar la habilidad - no proteger el ego. Debe agregar valor - incluso cuando la respuesta es no.
La entrevista más precisa que he encontrado es simple: Deje que los candidatos hablen del código del que están orgullosos. Porque en código, la honestidad se muestra. La presión lo oculta.
Cuando la gente deja su entrevista se siente respetada incluso cuando se deniega — Ya has construido algo que vale la pena unirte.
© 2026 Scott Galloway — Unlicense — All content and source code on this site is free to use, copy, modify, and sell.
