Introducción

Uno de los muchos aspectos de LinkedIn que me molesta es el 'cómo entrevistar a los desarrolladores' posts. Hay una TON de ellos y están en tres campos:

1. Los ¿Cómo moverías el monte Fuji? aproximación con rompecabezas de lógica y teasers del cerebro.
2. El enfoque de 'Veamos cuánto puedes recordar de tu título en Ciencias de la Computación' con preguntas algorítmicas.
3. El enfoque de 'vigilar mientras escribe código' con ejercicios de codificación.

A lo largo de los años he entrevistado docenas de veces y contratado cientos de Desarrolladores para varias compañías, desde Microsoft hasta Dell, hasta pequeñas startups. También he sido extrañamente un Psicólogo de Investigación especializado en psicometría (la ciencia de la medición de capacidades mentales) y un Desarrollador de Software. Así que he visto el proceso por todos lados.

El problema

La codificación a menudo no es una actividad social. Las 'habilidades suaves' son de vital importancia, pero a menudo son ortogonales a la práctica de escribir código para resolver problemas de usuario. Entonces, ¿cómo entrevistas a alguien para un trabajo que es sobre todo sobre escribir código?

Nuestra profesión también está llena de síndrome impostor. Lo he visto en mí mismo y en muchos otros. Es algo real. ¿Cómo entrevista a alguien que ya se siente como un fraude?

Nuestra profesión está llena de lo socialmente incómodo (y sí como yo ligeramente autista); una entrevista que es estresante y requiere interacción social mientras que la solución de problemas de codificación es una receta para el desastre. Entonces, ¿cómo entrevista a alguien que es socialmente incómodo?

La solución

Primero lea su currículum; ni siquiera hable con ellos si su currículum no deja claro que tienen experiencia suficiente para el trabajo para el que está contratando. Esto no sólo es respetuoso de su tiempo, sino también el tuyo.

En segundo lugar, establecer la entrevista (o entrevistas) debe ser lo más libre de estrés posible para los participantes. Esto significa:

1. Dar aviso adecuado. No hagas una entrevista con alguien con 24 horas de antelación (o peor el mismo día).
2. Deja claro cuál será el formato de la entrevista, quién estará allí y los resultados esperados (es la final, una pantalla técnica, etc.).
3. Lee la respuesta de la persona. No puedo enfatizar esto lo suficiente. Si estás entrevistando a alguien deberías conocer su currículum de adentro hacia afuera. Esto no sólo es respetuoso, sino que también le da la oportunidad de hacer preguntas sobre su experiencia.
4. Asegúrese de tener los detalles EN EL MAIL; si se trata de Equipos / Zoom asegúrese de que tienen el enlace. Si es en persona, asegúrese de que saben a dónde ir.

La entrevista

SER A TIEMPO; nada hace a una persona más ansiosa que esperar a que comience una entrevista. Si llegas tarde ya estás empezando con el pie equivocado. Si llegan tarde, dales unos minutos; es probable que no hayan estado en reuniones consecutivas, así que su configuración podría ser una locura.

¿Parecen alguien que encajaría con el equipo en términos de temperamento; son un buen ajuste para el equipo? Esto es importante; puedes tener el mejor codificador del mundo pero si son un idiota no valen la pena.

Un consejo que se me ocurrió (después de años de preguntas de secuencia de Fibonacci, versiones inversas, listas enlazadas, etc) es.

A los CODERS les gusta hablar del código que conocen.

Esto significa que si usted está haciendo una evaluación técnica la persona que hace la entrevista tiene que ser capaz de hablar sobre el código que están viendo. Si es un marco que no conoces (como yo entrevistando a Devs Angular) no te preocupes demasiado.

Así que antes de la entrevista con suficiente aviso (5 días es generalmente bueno) diles que les pedirás que hablen sobre un código que han escrito. Generalmente no pido un enlace GitHub (muchas personas incluso en los niveles superiores podrían no tener esto; he trabajado en muchos proyectos que son propietarios y no pueden ser compartidos).

Deja claro que no estás pidiendo un gran proyecto / algún código innovador increíble. Es sólo código del que pueden hablar. MUCHAS personas tienen estas cosas de 'familia', lo más probable es que no hayan contribuido durante 365 días a un importante proyecto de código abierto.

No estás contratando basándote en cuánto tiempo libre tiene alguien.

¿Por qué?

Entonces, ¿por qué prefiero este enfoque? ¿Por qué creo que esta es una mejor manera de entrevistar a los desarrolladores?

1. Es menos estresante. La persona que está siendo entrevistada está hablando de algo que saben. No están tratando de resolver un problema que nunca han visto antes; realmente la mayoría de las veces cuando codificas te preocupa cómo escriben código cuando se les da tiempo para escribirlo. La mayoría de nosotros no estamos preparando algoritmos locos para hacer cosas que nuestro marco de elección ya hace por nosotros.
2. Se puede medir si están mintiendo sobre su experiencia. Si no pueden hablar de un código que han escrito, probablemente no lo hayan escrito.
3. Puedes indagar en el código de maneras más naturales; por qué eligieron ese enfoque frente a otro diferente, por qué no usaron una biblioteca, etc.
4. Estás viendo el código que quieren mostrarte. Este es uno grande. Si les estás pidiendo que escriban código en el lugar en el que estás viendo código, están escribiendo bajo presión. Si les estás pidiendo que hablen de código que han escrito, estás viendo código que han escrito cuando no están bajo presión. De nuevo, a menos que tu lugar de trabajo sea un caso perdido la mayor parte del tiempo no estás escribiendo código bajo presión.

Excepciones a la regla

Así que hay excepciones aquí, los programadores super junior a veces necesitan un poco de ejercicio de codificación, pero tómalo con calma. Pedirles que analicen y refactoricen / arreglen una gran base de código es cruel. Para ellos puedes preguntar sobre conceptos básicos como bucles, condicionales, etc (mantenerlo enfocado al trabajo para el que estás contratando). ¿ Patrones? Bueno, he visto a mucha gente que no puede nombrar un patrón pero puede decirte cuando lo han usado. Así que no te metas demasiado en esto.

¿Puzles lógicos? Nunca he visto el punto de esto. Nunca he visto un trabajo donde necesites mover el monte Fuji. Nunca he visto un trabajo donde necesites saber cuántas pelotas de golf caben en un 747. Nunca he visto un trabajo donde necesites saber cuántos afinadores de piano hay en Nueva York.

Seguimiento

Después de la entrevista asegúrese de hacer un seguimiento con el candidato. Si no consiguieron el trabajo, díganles por qué (no me mostraron suficiente de su experiencia, no fueron claros al explicar su código, etc.). Esto no sólo es respetuoso, sino que también les ayuda a mejorar para la próxima entrevista. Si consiguen el trabajo, asegúrense de saber qué esperar a continuación.