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

Cuando estaba en una posición similar, le decía al entrevistado: "Pretenda que soy Google. Si necesita buscar algo, simplemente dígalo".

En una pregunta, los entrevistados necesitaban poder descifrar el volumen de un cilindro, por lo que no me importaba si alguien decía: "Tendría que buscar en Google la fórmula para el 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 un conocimiento decente de cómo traducir el mundo real en software, por lo que era un concepto importante.

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

Tienes razón en que los nervios pueden ser un problema, pero aún espero que las personas puedan expresar su proceso de pensamiento, incluso si están nerviosos. 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. Su jefe usa el primero: no proporcione 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 contrate a esta persona, no podrá recibir ayuda constante de todos sus colegas.

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

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

Ejemplo:

  

- ¿Puede decirme cómo crear propiedades de solo lectura en C #, es decir, propiedades con un valor que se puede inicializar solo dentro de un constructor y no se puede cambiar 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 ... consigue y establece ...
  - Okay. Por lo tanto, un campo es una variable declarada dentro de una clase o estructura y válida dentro del ámbito de clase / estructura, mientras que una propiedad es como un campo, pero también proporciona un mecanismo para leer, escribir o calcular un valor. Ahora, ¿qué hay de readonly ? ¿Se usa con propiedades?
  - Creo que solo se usa para campos ...
  - Correcto. Entonces, ¿qué pasa con las propiedades?
  - No pueden ser de solo lectura.
  - ¿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.
  - Bien.
  - ¿Asi que? ¿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 apoyo?
  [...]

Dar la respuesta es una buena idea en todos los casos. Hubo varios casos en los que el entrevistado comentó mi respuesta de manera interesante, demostrando que incluso si no pudo responder a la pregunta en primer lugar, aún 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 sabe la respuesta . Proporcionar ayuda progresiva puede permitirle ver cómo la persona está pensando en un problema.

También puede mostrar otras cosas que la persona no sabe. Tomemos el ejemplo anterior: si me detuviera en la primera respuesta, no sabría 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 ella necesita ayuda, no hay nada de malo en esto. Si terminas respondiendo la pregunta por ti mismo, es una mala señal y esperamos que el entrevistado pueda responder a las otras preguntas.

Siempre me gusta ayudar a los entrevistados si están atrapados en una cosa simple (como el nombre de un patrón particular si obviamente saben lo que es), y les permite pasar por alto cosas como los detalles para 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 otra cosa que no sea adónde supongo que van.

Recuerdo que un entrevistador me hizo una pregunta específica 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 que enfrentan muchos entrevistados. A veces, la mirada en blanco no se debe a que la persona no resuelva bien los problemas, sino porque la persona que hace la pregunta no está siendo clara en lo que pregunta. En ese caso, el enfoque de su colega de decir y no hacer nada simplemente 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 trabajamos en el vacío, y que las entrevistas son lo suficientemente estresantes sin límites artificiales, me inclino a ofrecer tanta ayuda como lo solicite un entrevistado o sus necesidades. / p>

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

Alguien que esté buscando una posición de alto nivel pero que necesite mucha ayuda 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 mayores que escuchan, se comunican, usan la escucha activa, aclaran y luego proveen soluciones que son del tipo que me gustan.

Para "ingenieros de línea", he utilizado la técnica para programar pruebas en las que le da a un solicitante una computadora y un problema y algunas horas, luego regresa. En esa situación, le preguntamos al solicitante por adelantado 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 del código. Todas las habilidades que espero de un ingeniero experimentado el día 1.

Es importante destacar que todo el equipo de entrevistas había tomado 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 "anónimos" (currículum vicioso, malas habilidades de entrevista) que he encontrado.

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

A veces, proporcionar minor hints durante la entrevista oral ayuda a ver qué tan bien el candidato entiende el (los) tema (s). Sin embargo, debe haber no hints en las pruebas estándar que cada candidato debe realizar.

Básicamente, hay two main things que quizás quieras saber sobre un candidato potencial:

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

b) Habilidades técnicas : ¿tiene buenos antecedentes técnicos e interés en aprender cosas nuevas?

Para aprender sobre estos puntos mencionados, debe involucrar al candidato potencial en una conversación. También es importante asegurarse de que el candidato sea comfortable during the interview para obtener la máxima comprensión de sus habilidades actuales (tanto de software como de tecnología) y 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 se debe considerar es la capacidad 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 ciertas suposiciones al leer especificaciones o, en este caso, procesar una pregunta de entrevista. El candidato puede responder en base a estas suposiciones y perder totalmente el punto deseado. La pregunta puede ser defectuosa, o puede ser el candidato. En cualquier caso, permitir una aclaración a través de la comunicación demuestra una habilidad valiosa, una que los empleadores deberían 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 califica 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 puede venir, ir a trabajar y contribuir eficazmente de alguna manera valiosa a cualquier proyecto (s) en el que esté siendo contratado para trabajar que a la buena memoria que tiene.

Por lo tanto, entrenaré un poco si el candidato está atascado en algo esotérico, o en un matiz raramente utilizado, o en un caso de ventaja que podría ser relevante en una entrevista inventada, 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 "configúrelo y olvídelo" escriba cosas.

Sin embargo, no los entrenaré en cosas del mundo real, comunes, generales, fundamentales, de trabajo al día. Estas son las cosas que yo quiero que sean innatas para ellos.

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

¿Por qué no quiero hacer preguntas de seguimiento? Cuando intento descubrir la respuesta de la persona al estrés. He entrevistado a personas para algunos trabajos que se encontraban en entornos altamente estresantes y qué tan bien podrían 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 sus conocimientos técnicos, hago preguntas de seguimiento que pueden contener sugerencias sobre lo que estoy buscando. Contrariamente a la idea del gerente que dijo que tiene que hacerle las mismas preguntas a todos para ser justos, creo que esto es justo siempre que se cumplan varias condiciones. Primero a todos se les hace la misma pregunta base. Segundo, no debe hacer preguntas de seguimiento para ayudar a una sola persona. Si ha dejado que otros se tambaleen sin ayuda, debe dejar que todos se tambalean sin ayuda. En segundo lugar, debe comparar el desempeño de los candidatos en la pregunta, no solo en términos de su respuesta final, sino también en términos de lo difícil que fue arrastrarla fuera de ellos. Este proceso todavía trata a todos de manera justa.

Depende del tipo de programador que quieras. Un introvertido que puede escribir 20 grandes líneas de código en papel se verá bien para usted, jefe. Un desarrollador de software que pueda trabajar en millones de códigos de línea dentro de un equipo para producir un buen software de manera eficiente probablemente no lo hará muy bien. Me encantan este tipo de entrevistas como candidato; me dicen mucho sobre cómo el jefe trata a su personal y qué es la cultura de trabajo. En un caso como este, cuando salí de la entrevista, dije: "Gracias, nos permite ahorrar un poco de tiempo, si no me llamas, no te llamaré". Cuando se me preguntó por qué, señalé que no quería trabajar para una empresa que me hizo fallar.

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

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

Hace poco estuve en una situación similar. La dirección que obtuve de mi gerente y de Recursos Humanos fue que debíamos 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 seguían con un término técnico o algo, les ayudé 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 lograron pasar por la primera ronda.

Parte de lo que quieres en un empleado es alguien que pueda interactuar con el resto del equipo. Necesitas a alguien con habilidad requerida, cierto. Pero también necesita a alguien que sepa cuándo debe buscar ayuda y que tenga conocimiento propio y habilidad social para hacerlo. Este último conjunto de alféizares se establecerá mejorará la empresa a largo plazo que cualquier Du-jour de lenguaje informático en particular.

De la forma en que lo veo, una entrevista es una sesión de prueba, no una prueba . Principalmente trato de responder la pregunta "¿cómo se siente trabajar con esta persona?" A veces, incluso pretendo haber olvidado la respuesta a la pregunta, para que el ejercicio se sienta más colaborativo.

¿Alguna vez ha trabajado con alguien con quien simplemente no puede estar en la misma página cada vez que hablaba de un problema? ¿O alguien que hizo demasiadas preguntas en lugar de saltar y resolver problemas? En una entrevista me aseguro 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 "si escribe código limpio", "si está familiarizada con los conceptos necesarios" y "¿puede ella, de manera inteligente, plantear un problema para llegar a las ideas?" El candidato seguirá siendo el que "maneja" y escribe el código. Pero a lo largo del camino, espero que ella 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 un compañero de trabajo.