¿Cuánta ayuda debo brindar durante las entrevistas técnicas? [cerrado]

Me piden actuar o sentarme durante muchas entrevistas técnicas. Hacemos preguntas lógicas y problemas de programación simples que se espera que el entrevistado pueda resolver en papel. (Preferiría que tuvieran acceso a un teclado, pero eso es un problema para otro momento.) A veces siento que las personas sí saben cómo abordar un problema, pero están nerviosas o adivinan la pregunta ( no están destinados a ser preguntas capciosas).

Nunca he escuchado a mi jefe dar alguna ayuda o pistas. Simplemente agradece al entrevistado por la respuesta (no importa cuán bueno o malo sea) y pasa a la siguiente pregunta o problema. Pero sé algo sobre la madriguera del conejo que la derrota y los nervios pueden llevarte hacia abajo, y cómo deshabilita tu mente, y no puedo evitar preguntarme si proporcionar un poco de ayuda de vez en cuando nos ayudaría a terminar con programadores más capaces. de más entrevistas fallidas.

¿Debo proporcionar consejos y asistencia para los entrevistados confundidos (y si es así, ¿qué tan lejos debo llegar sin dejar de ser justo con los candidatos más preparados?)

Cuando estaba en una posición similar, le decía al entrevistado: "Finge que soy Google. Si necesitas buscar algo, solo dilo".

En una pregunta, los entrevistados necesitaban poder calcular el volumen de un cilindro, por lo que no me importó si alguien decía: "Tendría que buscar en Google la fórmula del volumen de un cilindro". Me interesaba saber si sabían cómo atacar el problema, no si habían memorizado fórmulas. Para el trabajo, tenían que tener una comprensión decente de cómo traducir el mundo real en software, por lo que era un concepto importante.

Por otro lado, no iba a decirles que necesitaban esa fórmula.

Tienes razón en que los nervios pueden ser un problema, pero todavía espero que las personas puedan expresar su proceso de pensamiento, incluso si están nerviosas. Simplemente no dar una respuesta era inaceptable.

Tiene dos enfoques que funcionan tanto para la resolución de problemas como para preguntas técnicas breves:

1. El primero lo usa su jefe: no brinde ninguna ayuda para probar cómo se comporta la persona en un contexto estresante. Es un enfoque perfectamente válido y puede dar algunas pistas sobre la persona. Después de todo, una vez que contrata a esta persona, no podrá recibir ayuda constante de todos sus colegas.

2. El segundo es proporcionar sugerencias y apoyo. El nivel de soporte no importa demasiado; lo único que importa es que cuanto más ayuda le brindes a la persona, menos tendrás que valorar su éxito.

Personalmente, creo que debe tomarse el tiempo suficiente para asegurarse de que la persona no pueda resolver un problema por sí misma y hacer que sienta que no puede resolverlo sin ayuda. Pero luego, puede proporcionar ayuda progresiva hasta que le diga a la persona la respuesta en sí.

Ejemplo:

- ¿Puede decirme cómo crea propiedades de solo lectura en C #, es decir, propiedades con un valor que puede inicializarse solo dentro de un constructor y no puede cambiarse más tarde?
- Por supuesto. Solo uso la palabra clave readonly.
- ¿Estás seguro? ¿Me puede explicar la diferencia entre una propiedad y un campo?
- Hm. Una propiedad es ... ya ves ... obtener y establecer ...
- Ok. Por lo tanto, un campo es una variable declarada dentro de una clase o una estructura y válida dentro del alcance de la clase / estructura, mientras que una propiedad es como un campo, pero también proporciona un mecanismo para leer, escribir o calcular un valor. ¿Y ahora qué pasa readonly? ¿Se usa con propiedades?
- Creo que se usa solo para campos ...
- Correcto. ¿Y qué hay de las propiedades?
- No se pueden leer solo.
- ¿Estás seguro? ¿Qué pasa con las propiedades que solo tienen captadores?
- Son de solo lectura.
- ¿Significa que su valor siempre será el mismo?
- Si.
- No en realidad no. El hecho de que tenga una propiedad con un captador no significa que su valor no cambie durante la vida útil de la instancia de la clase. Si el captador se refiere a un campo que se incrementa cada vez que accede a la propiedad, el valor devuelto aumentará continuamente.
- Derecha.
- ¿Entonces? ¿Tiene una idea de cómo puede implementar una propiedad con un valor que nunca cambia?
- No.
- Bueno, puedes usar un campo de respaldo de solo lectura. ¿Sabes qué es un campo de respaldo?
[...]

Dar la respuesta es una buena idea en todos los casos. Hubo varios casos en que el entrevistado comentó mi respuesta de una manera interesante, mostrando que incluso si no pudo responder a la pregunta en primer lugar, todavía sabe cosas relacionadas.

Además, al hacer una pregunta sin más ayuda, no tiene demasiada información sobre la persona, aparte del hecho de que ella sabe o no la respuesta . Brindar ayuda progresiva puede permitirle ver cómo piensa la persona acerca de un problema.

También puede mostrar otras cosas que la persona no sabe. Tome el ejemplo anterior: si me detuviera en la primera respuesta, no habría sabido que la persona no puede explicar la diferencia entre un campo y una propiedad o que no sabe qué es un campo de respaldo.

Si la persona responde de inmediato, está bien. Si necesita ayuda, no hay nada de malo en esto. Si termina respondiendo la pregunta usted mismo, es una mala señal y es de esperar que el entrevistado pueda responder las otras.

Siempre me gusta ayudar a los entrevistados si están atrapados en algo simple (como el nombre de un patrón en particular si obviamente saben lo que es), y dejarlos pasar por alto cosas como los detalles de establecer una conexión de base de datos. Sin embargo, si están tratando de diseñar algo, no digo mucho porque no quiero guiarlos o desecharlos si están pensando en algo más que adonde supongo que irán.

Recuerdo que un entrevistador me hizo una pregunta particular para resolver problemas y tenía un resultado muy específico en mente, pero no pudo comunicarme la pregunta con claridad. Esto describe la situación en la que se encuentran muchos entrevistados. A veces, la mirada en blanco no se debe a que la persona no es un buen solucionador de problemas, sino porque la persona que hace la pregunta no es clara en lo que está preguntando. En ese caso, el enfoque de su colega de decir y no hacer nada solo prueba que el candidato no piensa como su colega, o no está dentro de la cabeza de su colega. Creo que proporcionar una aclaración de la pregunta en diferentes palabras podría proporcionar mejores resultados para todos los involucrados.

Dado que los programadores (la mayoría de nosotros al menos) no trabajan en el vacío, y que las entrevistas son lo suficientemente estresantes sin límites artificiales, me inclinaría a ofrecer tanta ayuda como pida o necesite un entrevistado.

Pero tenga todo en cuenta al hacer un juicio final sobre el nivel de competencia real del solicitante.

Alguien que busca un puesto de alto nivel pero necesita mucha ayuda haría sonar las alarmas.

Para las "personas mayores", ofrezco preguntas cortas y abiertas y presto más atención a las preguntas que hacen que a la respuesta. Encuentro personas de la tercera edad que escuchan, se comunican, usan la escucha activa, aclaran y luego brindan soluciones del tipo que me gusta.

Para los "ingenieros de línea", he usado la técnica para programar pruebas en las que le das a un solicitante una computadora y un problema y unas pocas horas, luego regresas. En esa situación, le preguntamos al solicitante con anticipación qué sistema operativo y herramientas preferían (también una parte interesante de la experiencia de un programador). Cuando terminaron, como grupo les pedimos que presentaran la solución y por qué era mejor que otras soluciones: una revisión de código. Todas las habilidades que espero de un ingeniero experimentado el día 1.

Es importante destacar que todo el equipo de entrevistadores se tomó una tarde para hacer la misma prueba, por lo que sabíamos que la prueba era justa. Pasamos una hora examinando el enfoque de cada persona como lo haríamos con un entrevistado, lo que nos dio una idea de los diferentes enfoques.

Esta segunda técnica nos encontró a algunos de los mejores programadores "no reconocidos" (pésimo currículum vitae, pésimas habilidades de entrevista) que he encontrado.

Prefiero comenzar las entrevistas con una pregunta fácil de fomento de la confianza para que el candidato se sienta cómodo con el proceso. Cuando esto funciona, todavía le permite obtener tanta información como sea posible de preguntas posteriores sin dar ventaja a los candidatos que entienden mejor el lenguaje corporal que el material relacionado con el trabajo.

A veces, proporcionar minor hintsdurante la entrevista oral ayuda a ver qué tan bien el candidato entiende el tema (s). Sin embargo, debe haber no hintspruebas estándar que cada candidato debe tomar.

Básicamente, two main thingses posible que desee saber sobre el posible candidato:

a) Características personales : ¿encaja bien en su empresa o equipo?

b) Habilidades técnicas : ¿tiene buena experiencia técnica e interés en aprender cosas nuevas?

Para conocer estos puntos mencionados, debe involucrar al candidato potencial en una conversación. También es importante asegurarse de que el candidato esté comfortable during the interviewen orden para obtener la máxima comprensión de sus habilidades actuales (tanto blandas como tecnológicas), así como su potencial para hacer el trabajo.

Además, las habilidades de comunicación del candidato potencial son tan importantes como sus habilidades técnicas y competencia para resolver los problemas.

Parte de lo que debe considerarse son las habilidades de comunicación. Si el candidato no está claro acerca de la pregunta, debe hacer preguntas para aclarar. Esto es algo bueno, en mi opinión. Con demasiada frecuencia, se toman malas decisiones porque se hacen ciertos supuestos al leer las especificaciones o, en este caso, al procesar una pregunta de entrevista. El candidato puede responder con base en estos supuestos y perder totalmente el punto deseado. La pregunta puede ser defectuosa o puede ser el candidato. En cualquier caso, permitir la aclaración a través de la comunicación demuestra una habilidad valiosa, que los empleadores deben buscar.

Creo que, en última instancia, esto se reduce a tu personalidad como entrevistador, y lo que crees que es importante y, por lo tanto, realmente está evaluando al candidato.

Personalmente, valoro la capacidad práctica / pragmática sobre las trivias académicas / esotéricas. Estoy mucho más interesado en un candidato que pueda ingresar, ponerse a trabajar y contribuir eficazmente de alguna manera valiosa a cualquier proyecto (s) para el que estén siendo contratados para trabajar, que yo estoy en lo buena que es su memoria para las minucias.

Por lo tanto, voy a entrenar un poco si el candidato está atrapado en algo esotérico, o un matiz raramente usado, o un caso límite que podría ser relevante en una pregunta inventada de la entrevista, pero rara vez es relevante en la vida real. Especialmente cualquier cosa que puedan obtener con un par de minutos en Google o con una referencia de escritorio útil, o cosas de tipo "configúrelo y olvídese".

Sin embargo, no los entrenaré en el mundo real, común, convencional, fundamental, trabajo diario. Estas son las cosas que quiero ser innato para ellos.

Creo que depende de la situación de la entrevista y las preguntas. He usado ambas técnicas.

¿Por qué podría no querer hacer preguntas de seguimiento? Cuando trato de averiguar la respuesta de la persona al estrés. Entrevisté a personas para algunos trabajos que se encontraban en entornos muy estresantes y lo bien que pudieron manejar el estrés fue un factor crítico en nuestras evaluaciones, por lo que hicimos algunas preguntas extremadamente difíciles que nadie podría responder sin un poco de estrés.

Cuando trato de averiguar su conocimiento técnico, hago preguntas de seguimiento que pueden contener pistas sobre lo que estoy buscando. Al contrario de lo que piensa el gerente que dijo que tiene que hacerles a todos las mismas preguntas para ser justos, creo que esto es justo siempre que se cumplan varias condiciones. Primero, a todos se les hace la misma pregunta base. En segundo lugar, no debe hacer preguntas de seguimiento para ayudar a una sola persona. Si ha dejado que otros se muevan sin ayuda, debe dejar que todos se muevan sin ayuda. En segundo lugar, debe comparar el desempeño de los candidatos con respecto a la pregunta, no solo en términos de su respuesta final, sino en términos de lo difícil que fue sacarlos de ellos. Este proceso todavía trata a todos de manera justa.

Depende del tipo de programador que quieras. Un introvertido que pueda escribir 20 líneas de código en papel se verá bien para su jefe. Un desarrollador de software que pueda trabajar en millones de bases de código de línea dentro de un equipo para producir un buen software de manera eficiente probablemente no lo haga muy bien. Me encanta este tipo de entrevistas como candidato: me cuentan mucho sobre cómo el jefe trata a su personal y cuál es la cultura laboral. En un caso como este, cuando dejé la entrevista, dije: "Gracias. Vamos a ahorrarnos un poco de tiempo, si no me llamas, no te llamaré". Cuando me preguntaron por qué, señalé que no quería trabajar para una empresa que me hizo fracasar.

Es probable que su enfoque obtenga mejores selecciones para el desarrollo de software. El enfoque de los jefes funcionaría bien para los recolectores de basura y los muchachos que sostienen las piruletas Stop / Go en las obras viales.

El desarrollo de software es un esfuerzo de equipo, no un juego en solitario / lectura mental / no interactivo. Cuántos proyectos fallan porque el software hace lo que se le pidió, no lo que se quería.

Hace poco estuve en una situación similar. La dirección que obtuve de mi gerente y recursos humanos fue que teníamos que ser completamente justos con los 6 entrevistados, así que tuve que hacer el mismo conjunto de preguntas técnicas con una ayuda mínima para ver cómo se desempeña cada entrevistado. A veces, cuando sabían la respuesta pero se quedaban con un término técnico o algo, los ayudaba indirectamente con algunas preguntas que los guiaban a ese término. Hubo una segunda ronda de entrevistas después de la ronda técnica sobre personalidad y rasgos de comportamiento si lograban pasar por la primera ronda.

Parte de lo que quiere en un empleado es alguien que pueda interactuar con el resto del equipo. Necesitas a alguien con la habilidad requerida, cierto. Pero también necesita a alguien que sepa cuándo necesita buscar ayuda y que tenga autoconocimiento y habilidades sociales para hacerlo. Este último conjunto de alféizar establecerá a la compañía mejor a largo plazo que cualquier Du-jour en lenguaje informático en particular.

A mi modo de ver, una entrevista es una sesión de prueba de coworking, no una prueba . Principalmente estoy tratando de responder la pregunta "¿cómo se siente trabajar con esta persona?" A veces incluso pretendo haber olvidado la respuesta a la pregunta, para hacer que el ejercicio se sienta más colaborativo.

¿Alguna vez ha trabajado con alguien que usted podría no estar en la misma página con cada vez que habló a través de un problema? ¿O alguien que hizo demasiadas preguntas en lugar de saltar y resolver problemas? En una entrevista, principalmente me aseguro de que la persona con la que estoy hablando no sea una de esas. Hay un fuerte elemento de química allí.

En el proceso, por supuesto, también aprenderé cosas como "escribe código limpio", "está familiarizada con los conceptos requeridos" y "¿puede resolver un problema ingeniosamente para llegar a las ideas?" El candidato seguirá siendo el que "maneje" y escriba el código. Pero en el camino espero que esté más relajada y veré una versión de ella más cercana a lo que realmente vería día a día como compañera de trabajo.