¿Cómo determinar las habilidades de un desarrollador de software en una entrevista de trabajo?

Esto puede ser un desafío, siempre es posible que alguien haga una buena prueba pero no pueda desempeñarse en el "mundo real". En el pasado, cuando entrevisté a candidatos, prioricé lo siguiente:

1. Personalidad. Siempre puede capacitar a un nuevo empleado para que sea técnicamente competente. Nunca puedes entrenarlos para que sean un ser humano decente si no lo son ya. Bajo este encabezado general incluyo rasgos como honestidad, discreción, franqueza, coraje, etc. Todas las "habilidades blandas" que hacen que sea fácil trabajar con alguien... pero que son notoriamente difíciles de medir.
2. Agudeza mental. Si está buscando una contratación a largo plazo, es mejor contratar a alguien que pueda analizar un problema, pensarlo detenidamente y luego ejecutar el plan que desarrollan en lugar de alguien que realmente no puede pensar. Podría usar algún tipo de acertijo lógico para probarlos en esto.
3. Habilidad de aprender. No contrataría a alguien que no tuviera ni idea de lo que se necesitaba hacer en el puesto en el que se colocó, pero la tecnología cambia y si no pueden seguir aprendiendo, se quedará con alguien que hace excelentes tarjetas perforadas. cuando realmente necesitas a alguien que pueda codificar en JAVA.

En primer lugar, la entrevista como predictor del desempeño futuro tiene una validez muy baja. Incluso estructurado, no es útil o muy útil. Las pruebas de capacidad cognitiva y la realización de "pruebas de trabajo" son dos de los principales indicadores de desempeño, con una validez cercana o alrededor de r0.5 ( Hunter & Hunter 1984 ).

Entonces, crear tareas o preguntas de prueba es el lugar al que desea ir. Sin embargo, los predictores de prueba deben probarse ellos mismos. Es que esto no es una tarea fácil. Aquellos que crean herramientas de selección invierten una tonelada de tiempo y dinero y la confiabilidad y validez de estas herramientas aún son cuestionables. Podría ser mejor comprar lo que ya ha sido desarrollado y probado, pero prepárate para gastar.

Si no puede, siéntase realmente cómodo con una probabilidad del 50/50 de seleccionar correctamente.

Sobre la base de la respuesta de Marcin.

La guía Guerrilla para entrevistar (¡la última versión es la mejor!) es muy útil.

Me ayudó mucho cuando tuve que evaluar al personal técnico para contratarlo hace unos años durante un período de expansión (estaba contratando desarrollo electrónico y programación integrada, no solo codificadores de propósito general para software empresarial)

No estoy 100% seguro de todas sus afirmaciones: no creo que tener siempre a 6 personas entrevistando a una persona una tras otra sea una forma valiosa de pasar el tiempo de 6 personas cuando también tienen una carga de trabajo del proyecto, pero tengo que estar de acuerdo en que "inteligente y que hace las cosas" es prácticamente el mejor resumen de cualquier buen empleado que pueda tener, y si tiene en cuenta esos dos indicadores, además de una pizca de "cultura técnica", estará en camino de obtener el aspecto técnico de las cosas evaluadas.

Además, no hay nada más cierto que esto:

"Nunca digas "Tal vez, no puedo decirlo". Si no puede decirlo, eso significa No contratar. Es realmente más fácil de lo que piensa. ¿No lo sabe? ¡Solo diga que no! Si está indeciso, eso significa No contratar. Nunca diga: "Bueno, contratar, Supongo, pero estoy un poco preocupado por..." Eso también es No contratar. Traduce mecánicamente todas las palabrerías a "no" y estarás bien".

Como alguien que una vez dio el visto bueno a un tal vez que resultó mal (estaba poniendo excusas por el mal desempeño en la prueba de aptitud y las malas explicaciones en la entrevista porque parecían confiados, pero ahora sé que no debería haberlo hecho) puedo decir que es el tipo de cosa que causa mucho daño y angustia a un equipo de desarrollo....

Además de la información de Joel, debe usar cualquier herramienta que tenga disponible para obtener nuevos miembros del equipo sin ocupar todo su tiempo productivo.

Tuve un agente de contratación que utiliza nuestra empresa, que tiene pruebas básicas de matemáticas y lógica, y en algunas sesiones de contratación diferentes resultaron ser un gran indicador para las personas a las que les fue bien en las entrevistas técnicas y en el trabajo real después. Por lo que he visto, debe esperar que cualquier candidato viable para un trabajo técnico obtenga una puntuación en el 5% superior de la población para estas cosas, incluso en un día realmente malo... El reclutador también hizo un análisis psicológico "DISC" informe que siempre fue interesante de leer, pero creo que podría vivir sin eso si estuviera pagando la factura de reclutamiento de mi propio bolsillo...

Para el lado de la programación de mis evaluaciones, también usé un par de preguntas de Softball C, como se describe en ese artículo. Los consideraría discusiones dirigidas en lugar de pruebas reales: no es solo que puedan hacerlo, sino qué tan rápidos son y qué tan seguros son, y las discusiones que tienen en el camino. Para obtener puntos de bonificación, los míos estaban hechos de partes simplificadas de nuestra base de código existente, por lo que también me dieron una idea de cómo funcionaba su proceso de pensamiento con nuestra "cultura de código" existente, y me dieron una idea de cómo manejaban las cosas que son importantes para nosotros, como máquinas de estado.

Curiosamente, incluso evalué a un miembro subalterno del personal al que le fue muy bien en las pruebas de aptitud básicas pero que no tenía experiencia real en C. Le proporcioné los "detalles de conocimiento general de C" necesarios para una de estas pruebas y me concentré en su lógica para explicar el funcionamiento. y, a continuación, agregue la funcionalidad. Resultó muy bueno.

La técnica de entrevista más efectiva que he encontrado para entrevistar a programadores es una sesión de pizarra en la que trabajamos a través de un estudio de caso de la vida real seguido de una prueba de programación.

La sesión de pizarra da una buena idea de qué tan bien el candidato puede articular y compartir su comprensión del problema y cómo abordaría su solución.

La prueba de programación da una indicación, solo una indicación, de qué tan buenas son sus habilidades en el idioma que necesitarán usar en el trabajo. Me gusta usar algo específico del lenguaje, como el problema 'Elastic Racetrack' en Flash y un ejercicio en el que el candidato tiene que escribir algunas pruebas unitarias para probar el comportamiento de una API, como un método de clasificación simple.

Por lo general, hago entrevistas a programadores como un par formado por un desarrollador senior y yo, el gerente del proyecto.

El tiempo durante la entrevista es demasiado pequeño para aprender sobre las habilidades de codificación de un desarrollador, sin embargo, es importante saber más sobre su personalidad, así que tenga una discusión cara a cara .

Cuando recibo el CV de un nuevo candidato , inmediatamente empiezo a buscar el código de él o ella en github para ver cómo él o ella hace la codificación . Si no encuentro ninguno le doy un ejercicio para ver cómo le va. Estoy enviando un enlace a este repositorio con una breve descripción del ejercicio. No explico demasiado, porque quiero saber cómo puede resolver los problemas por su cuenta. Como puede ver, un chico hizo la tarea y lo hizo muy bien. Si no sé mucho sobre el dominio, pido ayuda a un desarrollador experimentado. Con este enfoque sé qué tipo de desarrollador es el candidato. El trabajo en equipo y otras habilidades sociales se pueden comprobar durante la entrevista cara a cara .

Hubo un tiempo en que la empresa spotify no pedía CV, pedía enlaces al repositorio de github.

Ejercicios de codificación:

Escuchará mucho "ejercicios de codificación" como respuesta a esta pregunta. Y si bien estos ejercicios ciertamente tienen algún valor (ciertamente ponen a prueba el deseo de una persona por el puesto, ya que tienen que hacer hasta 20 horas de trabajo no remunerado), debe usarlos con cuidado.

Un problema es que, en la mayoría de los casos, estos ejercicios no están relacionados con el proyecto/rollo. Lo cual me parece una locura. Si usa ejercicios con un candidato, asegúrese de que estén diseñados para evaluar su capacidad para hacer el trabajo.

Hay muchas otras formas de descubrir si un programador es un buen candidato, ¡sin mirar una sola línea de código!

Consiga un tiempo cara a cara:

Puedes saber mucho simplemente hablando con alguien. Desde la inflexión y el tono de su voz hasta su lenguaje corporal. Restringirse a un intercambio de audio o correo electrónico le niega esa valiosa percepción del personaje.

Muchas plataformas de freelancers intentan protegerse de la desintermediación desalentando fuertemente el contacto telefónico directo. En cambio, se basan en pruebas simples en línea y sistemas de calificación de pares jugables. Si bien ninguno de los métodos tiene nada de malo, deben combinarse con técnicas más personales para crear una imagen más completa y precisa de un candidato.

Pida su opinión:

Pregúnteles acerca de su lenguaje de programación favorito y por qué. La forma en que respondan revelará mucho. Si alguien tiene una opinión sólida sobre un tema, es un buen indicador de que le apasiona.

Échales un vistazo en GitHub:

¿Cuánto aportan a la industria en general y proyectos de código abierto? Además de brindarle una idea de su codificación, esto le brinda una gran idea de su mentalidad y pasión. Los proyectos de código abierto son una forma en que las personas retribuyen a la industria al ayudar a arreglar las cosas para un bien mayor. Ahora eso suena como alguien que me gustaría en mi equipo

¿Con qué frecuencia entregan lo que codifican?

Jugar con el código es una cosa. Ser capaz de enviar un producto completo es otra. Infórmese sobre los proyectos que han terminado, cuáles no y qué pasó

¿Qué tan bien hablan?

¿Son buenos comunicadores? Si se comportan como una caja negra, tendrá dificultades para trabajar con ellos y contratar un equipo a su alrededor.

¿Qué tan bien escriben?

Esto es similar al punto anterior pero lo suficientemente distinto como para importar. Un gran escritor a menudo será mejor en su trabajo, ya sea en marketing o programación. Mi consejo aquí es simple: cuando se encuentre atrapado entre candidatos de apariencia similar, siempre contrate al mejor escritor.

Utilice un período de prueba:

Es una manera segura y justa de probarlos en un proyecto sin pagarles por su tiempo. En Scalable Path, damos a los clientes un mes para evaluar a un desarrollador. Si es un buen o mal ajuste, será obvio. Y si no, ambas partes se ahorran muchos problemas y riesgos probando primero la situación.

Además de los ejercicios de codificación, estos métodos pueden ser utilizados por personas que no son programadores y, por lo tanto, son muy útiles para los gerentes de proyectos cuando realizan entrevistas.

¿Contratarías a un mago sin pedirle que te muestre algunos trucos de magia? - Joel Spolski.

Lea la guía de Jole: The Guerrilla Guide to Interviewing

La entrevista es sólo una parte del proceso de contratación. Hablar con referencias y empleadores anteriores es otro aspecto importante. Utilice la entrevista para obtener más información sobre el candidato, sus experiencias y la pericia reclamada. Luego, hable con referencias y empleadores anteriores para validar/obtener otra perspectiva sobre las mismas experiencias y habilidades reclamadas.

Para mí, la mejor manera es hacer una breve sesión de programación en pareja con SMB del equipo. Aquí hay un ejemplo de uso de Cyber-dojo en una entrevista de trabajo (video).

Toma de 20 minutos a 1 hora y muestra el verdadero nivel de habilidades.

Si usted es un gerente de proyecto, puede considerar dejar los aspectos técnicos de la entrevista al equipo oa los gerentes funcionales. Como gerente de proyecto, incluso si tiene habilidades técnicas, los detalles técnicos y tácticos realmente no son su responsabilidad.

Dedicar tiempo a las entrevistas también puede quitarle sus deberes de hacer el trabajo de gestión de proyectos.

Sin embargo, si participa en entrevistas, concéntrese en las habilidades interpersonales. Como gerente de proyecto, tendrá que trabajar con esta persona, y querrá estar seguro de que esta persona será un jugador de equipo y será alguien con quien podrá trabajar y comunicarse.

En este caso, parece que querrá participar como observador en la entrevista, principalmente en la entrevista de recursos humanos, y posiblemente como observador en la entrevista técnica.