Según mi experiencia en mi empresa, donde hice muchas entrevistas, hay muchas posibilidades de que la persona entrevistada no tenga idea de cómo hacerlo correctamente. Así que prepararon un conjunto de preguntas técnicas y calcularon un puntaje de eso y lo convirtieron en su currículum. Sin embargo, esto tiene muchos inconvenientes y no debe hacerse por los siguientes motivos:
Pides conocimiento puntual. Si el programador nunca ha hecho algo en esa área, podría ser un excelente compañero de trabajo, pero simplemente no sabe esa respuesta en particular. Por el contrario: si alguien se preparó para la entrevista y encontró la respuesta a esa pregunta en particular en la red, obtendrá la respuesta correcta, pero esa persona podría no tener idea sobre el tema real.
La gente está nerviosa en las entrevistas de trabajo. El cerebro tiene esta gran característica para cerrar muchas áreas de nivel superior (como la lógica) si está en pánico, lo que significa: si está nervioso, es posible que no brinde la calidad de las respuestas que lo haría en una situación cotidiana. Algunas personas pueden lidiar con una situación estresante como una entrevista, muchas no pueden.
Con una sola respuesta correcta, prueba la habilidad de esa persona para encontrar esa respuesta en particular. Esta es una de las muchas habilidades que necesita un compañero de trabajo, pero no es la única que se requiere. Por lo tanto, una o dos de esas preguntas deberían ser suficientes para evaluar esa área de conocimiento, y luego se deberían consultar otras habilidades. Una entrevista que solo contiene preguntas para resolver problemas evalúa la misma habilidad una y otra vez.
¿Cuáles son buenas preguntas de tareas de programación?
Las famosas preguntas "¿Puedes escribir un programa corto?" Tienen el gran problema de que la mayoría de los programadores no pueden escribir una sola línea de código sin que su IDE les ayude. Pero eso no es un problema en el día a día, porque el programador siempre tiene su IDE que lo ayuda. Entonces, preguntar cosas como "Encontrar el error", "Escribir 50 líneas de código que sí ..." o incluso preguntas simples deben tenerse en cuenta, que el solicitante no tiene sus herramientas (IDE, Google) disponibles.
Por ejemplo, puedo responderle básicamente cualquier pregunta dentro de 1 minuto si tengo Google ayudándome, pero sin conexión a Internet, parezco indefenso. Llamo a eso memoria subcontratada y, en lugar de obstaculizarme, me ayuda mucho a concentrarme en lo que es realmente importante: comprender la mecánica subyacente, porque todo lo demás se puede buscar. Pero no me pregunte sobre los detalles de ninguna API aleatoria, porque no los conozco, tengo Google para eso.
Dicho esto, una buena pregunta de tarea de programación no debe centrarse en conocer API o habilidades especiales de codificación a menos que sea un requisito absoluto para el trabajo. Se puede obtener conocimiento, por lo que es mejor descubrir qué tan buena es esa persona para obtener conocimiento que preguntar qué es lo que ya sabe.
Una buena pregunta para una tarea de programación debe ser corta, simple, capaz de codificarse en todos los idiomas con solo unas pocas líneas de código y, especialmente, debe informarle lo más posible sobre cómo trabaja la persona y encuentra las respuestas. Ejemplo:
"Escriba una función en el idioma de su elección que tome una serie de enteros y los reordene de manera que el primer entero sea el último, y todos los demás cambien en consecuencia".
Lo primero que cualquier solicitante debe preguntar en este punto es: "Lo siento ... ¿puede explicar la tarea?". Porque ningún programador ha recibido una descripción clara sobre qué hacer. Esto es seguido por la explicación, que el código en las preguntas debe hacer un desplazamiento hacia la izquierda del contenido de la matriz con el desbordamiento que se agrega a la derecha.
Esta tarea es tan simple que cualquier persona que se haya graduado de cualquier forma de nivel de programación debería poder responder correctamente. Esto tiene en cuenta que el programador tiene que trabajar sin sus herramientas y que estar nervioso reduce la capacidad de pensar lógicamente. Sin embargo, todavía le dice cómo las personas resuelven los problemas solo por la forma en que está formulada la pregunta y por la forma en que las personas la abordan, simplemente porque un desplazamiento a la izquierda está en contra del instinto común de 'izquierda a derecha' y obliga a las personas a pensar por un segundo.
Hay muchas respuestas posibles a esta pregunta, por lo que echar un vistazo de cerca a la forma en que se desarrolla el código es la parte importante, no si la solución realmente funciona. ¿El solicitante prueba nulo? ¿Cómo se almacena el desbordamiento? ¿Se utiliza un bucle o un conjunto de memoria? ¿Cómo verifica el solicitante la corrección del código? Esta simple pregunta te dice una biografía completa sobre cómo funciona esa persona.
¿Cuáles son buenas preguntas de conocimiento general?
Las buenas preguntas son fáciles de responder, permiten una gran cantidad de respuestas (llamadas 'preguntas abiertas') y le permiten aprender tanto como sea posible sobre el solicitante en el poco tiempo que tenga.
Ejemplos:
(Preguntar a un programador de C ++): "¿Qué otros lenguajes además de C ++ conoces?"
Esta es una pregunta de nivel de entrada, que le da al solicitante una oportunidad justa de rescatar en este momento si no sabe nada sobre el tema que se le preguntó. Un "no" en este punto es mejor que atormentarlo con varias preguntas más con las que él / ella tiene que responder: "Lo siento, no sé nada de eso".
Además, le dice, en primer lugar, qué otros idiomas conoce esa persona, además, aprende qué tan interesada está esa persona para obtener una visión más amplia del mundo de la programación, o si tiene a alguien con solo un lenguaje singular (y, por lo tanto, características / técnicas ) vista.
(A continuación, digamos que conoce Java): ¿Cuáles son las tres principales diferencias entre C ++ y Java en su opinión?
Esta es una pregunta abierta que permite muchas respuestas, por lo que el solicitante tiene una buena oportunidad de encontrar al menos tres. Pedir los tres primeros (opinión personal) no solo limita las posibles respuestas, sino que también obliga al solicitante a ordenar según la prioridad. Aún así es (o debería ser) fácil de responder.
Esta es una pregunta simple que pone a prueba muchos conocimientos profundos sobre diferentes lenguajes de programación. ¿Cuán profundo es realmente el conocimiento de esos temas? De esas respuestas puede decir mucho sobre el conocimiento y la comprensión real de la mecánica subyacente de los lenguajes de programación. Cuánto gastó esa persona con los detalles sucios, o si él / ella es solo alguien que vincula varias funciones API sin tener una idea real de lo que sucede debajo de ellas.
Este concepto de preguntas de nivel de entrada seguido de preguntas simples de conocimiento en profundidad también se puede utilizar para la mayoría de los otros temas. Siempre en este esquema: pregunta de rescate, pregunta de verificación, pregunta en profundidad. Otro ejemplo (de una entrevista Java):
- "¿Cómo calificaría su experiencia con el desarrollo multiproceso?"
- "Indique cuáles cree que son las tres cosas más importantes que debe considerar al desarrollar una aplicación multiproceso".
- "Por favor, nombre tres clases de la API de Java que puedan ayudarlo a desarrollar esas aplicaciones y dé una breve descripción de para qué se usan".
Estas tres preguntas le dirán más que cualquier pregunta técnica lo que el solicitante realmente sabe sobre esos temas, mientras que es justo responder teniendo en cuenta el conocimiento de puntos y el nivel de estrés.
Entonces, la próxima vez que alguien le haga 20 preguntas de codificación seguidas, sabrá que básicamente no tiene idea de cómo entrevistar a alguien adecuadamente. ;)