¿Qué técnicas utilizas al entrevistar a los desarrolladores? [cerrado]


28

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.

Respuestas:


21

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.


44
Probablemente iría tan lejos como para decir que esto es lo más importante para evaluar en cualquier entrevista de software. Se podría argumentar que escribir código es más importante, pero las personas que cubrieron algo similar recientemente o en la universidad pueden adivinar su camino, mientras que es muy difícil fingir un interés real y genuino.
Mike B

55
No me sorprende que esta sea una respuesta popular en este sitio web. La audiencia aquí es, por definición, una que valora la "cultura del programador". (Estoy de acuerdo con la respuesta, pero me he encontrado con varios programadores excelentes que reprobarían esta prueba, especialmente los de más de 40 personas)
AShelly

2
@ AShelly: Sí, estoy de acuerdo. Es por eso que no considero que esta pregunta sea esencial para rechazar o aceptar un programador. Es solo otra técnica que puede usar durante las entrevistas.
Sergio Acosta

16

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".


66
Sí, pero no demasiado.
Damovisa

Escribir código real lo ayudará a llegar a las puertas de las compañías de software de élite (Google, Amazon, Microsoft, ...) y no dude en elegir el resto.
grokus

3
Por favor, explique su respuesta. ¿Qué quieres decir con código "real"? ¿Qué código no es "real"?
MAK

+1 @MAK: De acuerdo, ¿qué es el código real? Si es un código que desea utilizar en su software de producción ...
Steven Evers

1
Consideraría 'código real' algo como pedirle al entrevistado que escriba una función 'strdup ()'. Tiene un uso real y expone su experiencia y actitudes a cosas como la gestión de la memoria y el manejo de errores.
JBRWilkinson

11

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.


2
+1 para "las entrevistas no deben ser realizadas solo por gerentes". Si el nuevo empleado no puede cortar el código tan bien como sus colegas, habrá disturbios entre el equipo.
JBRWilkinson

7

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 :)


6

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:

  • TCP o UDP?
  • Lenguaje dinámico o estáticamente escrito?
  • ¿Aplicación monolítica o múltiples aplicaciones más pequeñas?
  • ¿Qué utilizarías para la comunicación entre procesos?
  • Procedimientos almacenados o ORM?

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.


La única advertencia que agregaría a esto es asegurarme de que la pregunta no sea específica del dominio de la empresa que realiza la entrevista.
JBRWilkinson

1

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).


8
Estoy en desacuerdo. Las listas vinculadas y la clasificación son problemas enlatados bastante conocidos para un problema común. Cualquiera que haya escrito uno sabe cómo funciona, pero la mayoría de las personas no se molestan en escribir el suyo porque la mayoría de los idiomas ya lo hacen bien.
Evan Plaice

Estoy de acuerdo con Evan. En la práctica, a menudo es suficiente conocer el rendimiento de diferentes algoritmos de clasificación / búsqueda y estructuras de datos básicas. Saber cómo implementarlos es bueno, pero en última instancia inútil. Además, en la mayoría de los trabajos de programación es más importante saber cómo elegir el marco / biblioteca adecuado para la tarea que cómo implementar QuickSort en menos de tres líneas.
Alan Plum

0

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.