Me doy cuenta de que ha habido muchas discusiones sobre este tipo de cosas y a menudo se convierten en dogmas sobre si haces las preguntas del tipo "100 piratas lógicos" o si haces que escriban "fizz buzz".
Estoy interesado en qué técnicas y preguntas han sido efectivas para usted al entrevistar a posibles desarrolladores para trabajos.
Una técnica por respuesta para que podamos votar sobre ellas, por favor.
Además de las preguntas técnicas reales, y típicamente al final de la entrevista, trato de comprender su nivel de interés en la industria y su cultura con preguntas como:
¿Has visto algo recientemente relacionado con la programación que te haya parecido interesante y que quieras recomendar a otros programadores? ¿Un nuevo lenguaje, herramienta, plataforma, técnica, sitio web?
¿Puedes nombrar a alguna persona conocida en nuestra industria cuyo trabajo te guste o te parezca inspirador y por qué? (desarrollador, fundador del sitio web, autor, orador, etc.)
¿Qué estás leyendo ahora o cuál fue el último libro relacionado con el software que leíste?
¿Qué sitios relacionados con la programación frecuentas?
Si bien no responder a estas preguntas (lamentablemente, sucede con mucha frecuencia) no significa "no contratar" para mí, dicen mucho sobre la forma en que una persona se acerca a la profesión de desarrollo de software.
Haz que escriban código, código real.
El entrevistador puede permitirle elegir el lenguaje de programación con el que se sienta más cómodo, ya sea C ++, Java, C # o lo que sea, y pedirle que resuelva un problema simple, por ejemplo, hacer un trabajo con una cadena o una lista doblemente vinculada o lo que sea. Si tiene problemas para usar su mejor idioma para resolver un problema simple, entonces hay un problema. Consulte la publicación de blog de Steve Yegge y especialmente la sección "Preparación mental".
fuente
Haga que varias personas de su equipo los entrevisten de forma independiente. Comparta sus pensamientos después, no hable entre ellos antes de entrevistarlos. Hablar en el medio influirá en su juicio y no tendrá evaluaciones independientes.
Para las personas técnicas que los entrevistan, hágales escribir código. Para los no técnicos, no intentes preguntar cosas con las que no tienes experiencia. Sin embargo, asegúrese de tener al menos algunas personas técnicas entrevistando.
Las entrevistas no deben ser realizadas solo por gerentes, sino que deben ser extremadamente importantes para cada trabajador con el que trabajarán en el futuro.
fuente
Me gusta que un entrevistado explique sus proyectos anteriores y lo que hicieron. De esta respuesta puedo tener preguntas de seguimiento: por qué hicieron las cosas de cierta manera, cómo resolvieron un problema en particular si mencionaron uno, pero lo más importante fue cuál fue el propósito del proyecto y qué problema comercial resolvió.
Hago esto para ver si pueden articular de una manera que me haga comprender lo que estaban haciendo, y ver si también entendieron lo que estaban haciendo.
Es sorprendente que la última pregunta sobre el propósito del proyecto y el problema comercial resolvió que hace tropezar a mucha gente. No tienen idea de POR QUÉ se estaba haciendo el proyecto en el que estaban trabajando. Si no sabe por qué su proyecto existe en primer lugar, me hace preguntarme si está aportando soluciones o simplemente haciendo lo que se le dice.
(Supuse que arrojaría esta respuesta allí, ya que todas las otras respuestas tienden a ser técnicas. Quiero que las personas sepan por qué están resolviendo los problemas que están resolviendo también, de lo contrario, tienden a resolver los problemas incorrectos que el usuario final no hace). no me importa :)
fuente
Pregunte su opinión sobre una importante decisión arquitectónica.
Por ejemplo. Aquí está el programa x que ejecuta y número de subtareas simultáneamente. ¿Cuál elegirías, una estructura multiproceso o de subprocesos?
¿Cuáles son los beneficios / desventajas de ambos? ¿Qué tan bien funcionarían y cómo se podrían utilizar para aprovechar una plataforma multiprocesador y multiprocesador, cuál es su preferencia personal? Los prejuicios personales pueden ayudar a identificar si alguna vez tuvieron que aplicar el conocimiento y darles un punto de partida para compartir sus experiencias.
Hay un montón de preguntas que un entrevistador podría formular de la siguiente manera:
La mayoría de estos temas son los tipos que implican un conocimiento íntimo de cómo / por qué un sistema informático funciona de la manera que lo hace. Todos son problemas / soluciones a problemas que no tienen una respuesta definitiva, por lo que dan una idea de qué tan bien esa persona es capaz de adaptarse o superar los desafíos en cuestión. No es el tipo de conceptos que se pueden recoger fácilmente sin alguna experiencia práctica real.
Nota: También es imprescindible que el solicitante escriba algún código de pesudo, pero esa respuesta ya está tomada.
fuente
Simplemente deles un código básico para hacer en la pizarra, por ejemplo, implementación de listas vinculadas, clasificación o algo similar.
Puede juzgar qué tan cómodos están con su lenguaje sin la ayuda del compilador y puede juzgar su proceso de pensamiento (especialmente si nunca implementaron tal cosa, la mayoría de los programadores "nuevos" nunca lo hicieron).
fuente
Ten una conversación, déjala ir a la deriva y deambule por la ruta técnica y profesional y busca comentarios perspicaces o estúpidos en el camino. Esto le proporciona 3/4 de lo que necesita de una entrevista, una evaluación de: habilidades y personalidad de las personas, inteligencia general y una evaluación aproximada de las habilidades técnicas.
Use las "preguntas" de su entrevista como iniciadores de temas y para mantener la conversación acorralada a temas técnicos; es posible que deba restablecer la conversación de vez en cuando (como hacer un ejercicio de codificación) para investigar adecuadamente las áreas de preocupación / interés.
El verdadero truco para esta técnica es asegurarse de que hacen todo el hablar, de lo contrario se corre el riesgo de una evaluación favorable, ya que hacen que se sienta inteligente escuchando / estar de acuerdo con todo lo que dijo.
fuente