¿Cuáles son los pros y los contras de las preguntas del empleador del código durante una entrevista? [cerrado

Question

La prueba Joel La pregunta n. ° 11 es: "¿Escriben el código de los nuevos candidatos durante su entrevista?". ¿Cuáles son los argumentos a favor y para pedir a los nuevos candidatos que escriban código durante la entrevista y que tomen una decisión al respecto?

Answer 1

No veo los contras. Una entrevista tiene muchas partes, y un candidato debe ser respaldado "en la cadena" varias veces.

Entrevisto ~ 10 personas semanalmente. Realmente, realmente aprecio el hecho de que RRHH ha realizado todo el trabajo de fondo y me ha presentado muchas notas. Para cuando lleguen a mí, es hora de que obtenga sus pruebas.

Las pruebas dependen completamente de la posición. En general, trato de sondear:

• Habilidad de programación general. ¿Puedes usar operadores de manera efectiva? ¿Puede concebir un sistema numérico que tiene una radix que no es 10?

• ¿Sabes cómo hacer lo que te estamos contratando para hacer?

• Evaluación de sus contribuciones a cualquier proyecto de código abierto que haya enumerado

Intento mantenerlo breve y divertido. Cuando entro en la oficina, tomo las respuestas, las reviso y luego llevo a cabo una entrevista secundaria. Para ser contratado, generalmente tienes que pasar tres entrevistas.

También evalúo qué tan bien se mezclará con el equipo que lo recibirá. Ese equipo cuenta conmigo para hacerlo de manera efectiva.

Una cosa es responder preguntas en meta forma, es otra para producir código. Si te voy a contratar, realmente necesito verte producir código.

Answer 2

Con disculpas a Scott Whitlock:

Contras:

• ninguna

Pros:

• Ahorra mucho tiempo y angustia en el futuro si evita contratar a alguien que no pueda programar
• Requiere que tenga una persona técnica en la entrevista

Answer 3

Si ibas a contratar a un malabarista, estarías loco de no hacer que haga malabares por ti. O un músico que tendrías audición. De lo contrario, obtienes cosas como el impresionante yo-yo "maestro" K-strass.

Caminar a través de algo en una pizarra es el equivalente de programadores de un malabarismo rápido.

Answer 4

Creo que es muy útil, y siempre lo hago, pero dado que los beneficios se han cubierto tan bien, solo voy a discutir solo los negativos (aparentes).

Creo que es poco probable que las pruebas de código le den falsos positivos: las probabilidades son bajas de que alguien que realmente no puede escribir código logrará fingirlo en una entrevista, al menos si tiene una escala de preguntas de dificultad creciente. (Quizás el escenario más probable es que estén haciendo trampa preguntando a un amigo, si no es una entrevista cara a cara).

Los problemas son más en el lado falso negativo: ¿las pruebas de código lo llevarán a rechazar a la persona que en realidad es la mejor candidata?

Miedo escénico

Es posible que tenga a alguien que en realidad sea un desarrollador realmente bueno, pero que esté muy nervioso por esta entrevista, y obtienen un miedo esencialmente escénico. El desempeño bajo presión es importante hasta cierto punto, pero lidiar con el miedo escénico no es una parte clave de ser un programador (en comparación con otras profesiones), y sería desafortunado rechazar a alguien que sufre mal por él. Esto puede agravarse: si la persona no puede responder una pregunta que sabe que debe responder, puede ponerse más apretado. O, Como en esta pregunta, sienten que no pueden hablar y codificar al mismo tiempo.

Mitigación: comience con algunas preguntas sobre sus antecedentes, objetivos, etc., antes de saltar a las preguntas técnicas. Quizás comience con algunas preguntas técnicas más fáciles para que obtengan algo de impulso. No seas un idiota durante la entrevista (obstruyendo las semicolones, etc.).

Es una medida ruidosa

Las preguntas de código interesantes pueden tener más de una respuesta correcta. Si una persona escribe una respuesta correcta, y otra escribe una respuesta correcta y más eficiente, ¿cuánto peso debe tener eso?

Hasta cierto punto, esto es como el problema con algunas preguntas de "rompecabezas": la persona tiene la visión o no y obtienes un resultado casi binario. La inteligencia probablemente afecta la probabilidad de tener esa visión, pero el muestreo solo unas pocas veces le da una medida cruda.

Esto me molesta sobre las preguntas del código (aunque todavía las uso). La mejor mitigación que se me ocurre es que sea en la medida de lo posible tener una rampa de posibles soluciones: la persona puede al menos escribir una respuesta de fuerza bruta cruda o una respuesta para una parte del problema. Darme cuenta de que eso es mejor que nada es una buena señal. Entonces, si descubren más, pueden hacerlo más eficiente o un código más elegante. En la medida de lo posible, evite hacer preguntas que obtengan respuestas binarias.

No es realmente representativo

La programación no es un trabajo para resolver problemas algorítmicos de diez minutos uno tras otro: hay mucho más trabajo sobre la comprensión y el diseño de sistemas más grandes y concentrarse durante períodos prolongados de tiempo, por no decir nada de las habilidades interpersonales. Las preguntas de código realmente no prueban esto.

Pero, las preguntas del código no son las únicas preguntas que va a hacer: puede ver sus antecedentes, sus referencias, su trabajo de código abierto (si lo hay), para encontrar evidencia de esfuerzo sostenido, creatividad, habilidades interpersonales.

Saber cómo resolver pequeños problemas algorítmicos y cómo reducirlos al código es una condición necesaria pero no suficiente: si no puede resolver pequeños problemas y no puede escribir un código no trivial, entonces todo el pensamiento de la gran especie en el mundo no es Voy a hacerte un desarrollador productivo.

Cualquiera podría resolver eso

No, aparentemente no. Como el famoso post fizzbuzz Señala, los problemas que podría pensar son trampas triviales no solo nuevos graduados sino también personas con años de experiencia en la industria. No sé por qué. O la prueba de código es una mala medida (lo cual es posible, aunque creo que es poco probable), o no estaban contribuyendo mucho a los proyectos en su currículum, o se estaban haciendo mucho al copiar y pasar no Código algorítmico (que es posible).

Vale la pena reconocer que realmente puede hacer mucho sin escribir ningún código algorítmico. Las personas ganan mucho dinero en aplicaciones cuyo valor está en los gráficos o la lógica comercial, no en lo que podría llamar "programación", y eso está bien. Pero, si realmente necesita programadores, no es un buen ajuste.

Puede que no esté bien calibrado

Si se te ocurre una pregunta, la respuesta puede parecer fácil para ti. Sin embargo, si se le hace alguna pregunta comparable de la nada, o una pregunta que no está sesgada hacia sus propios intereses y antecedentes particulares, puede ser mucho más difícil.

Mitigación: ejecute las pruebas sobre algunos desarrolladores que ya conoce y vea cómo lo hacen. Quizás alguien que ya esté en su equipo, que conoce es muy inteligente, tendrá problemas con uno de ellos y puede considerar ajustarlo. Quizás piensen en una respuesta mejor o diferente.

Es demasiado como trivia

Creo que las preguntas del código ciertamente pueden entrar en trivia, si insiste en que las personas conocen las API oscuras de memoria, o obtengan la sintaxis perfecta, o recuerden la definición exacta de un algoritmo no trivial. Todos son razonables para confiar en documentos, búsquedas web o errores del compilador para recoger, y tienen poca correlación con experiencia real. Ni siquiera saber dónde es probable que la API sea quizás una pista que la persona no lo haya usado recientemente, pero eso no es necesariamente un problema siempre que no estén mintiendo en su currículum.

Entonces, la respuesta a esto es bastante simple: no hagas preguntas triviales y no te cuelguen en los errores triviales. Recuerde al candidato cómo se llama la API o déjelo buscarlo; corrige los errores de sintaxis; No pruebe las personas que memorizan las definiciones de la estructura de datos.

¿Cómo se compara?

Si tiene dos candidatos y ambos responden bien las preguntas, ¿cómo elige entre ellas? Podrías elegir al que terminó más rápido, pero tal vez allí comiences a elegir liebres sobre las tortugas. Podrías hacer otra ronda y hacer preguntas mucho más difíciles, pero tampoco estoy seguro de eso. Tal vez simplemente les dé un A+ e intentes elegir entre ellos en otros criterios (o tratar de encontrar el dinero para contratar a ambos).

Answer 5

Una estafa en la que puedo pensar es que es difícil "codificar en voz alta" frente a otras personas. Me resulta difícil incluso escribir con alguien que mira por encima del hombro, y no estoy solo. Me doy cuenta de que cuando alguien me llama a su estación de trabajo para ayudar con algo, de repente comienzan a hacer errores tipográficos, seleccionando el código de código incorrecto, incluso cometiendo errores francos, ninguno de los cuales habrían cometido si no hubiera estado sentado allí mismo. Demonios, he visto a la gente comenzar a usar el menú para operaciones de corte y pasta, solo porque estaban bajo observación. Este no es un comportamiento normal, y los codificadores de los que estoy hablando son excelentes programadores y bastante inteligentes.

Recientemente tuve una entrevista en la que el entrevistador me preguntó cómo codificaría una operación en particular y él dijo: "Solo muéstrame las matemáticas". Bueno, tuve que pensar en el problema primero antes de llegar a las matemáticas, por lo que me hizo hembreizar y hallar. Lo que puse en el tablero blanco al principio fue vergonzoso, y sentí que estaba perdiendo en ese momento. Finalmente obtuve el momento A-Ha y encontré la respuesta (en realidad cuando finalmente se me ocurrió lo que era De Verdad Preguntando), pero el "desastre" que hice antes de llegar allí me hizo sentir muy incómodo. Sin embargo, obtuve el trabajo, pero si el entrevistador hubiera sido menos paciente, podría no tener.

Creo que si le das a los entrevistados una tarea de codificación, dales algo de tiempo a solo para resolverlo en una computadora, tal vez incluso en un IDE con el que están familiarizados. Deje que escriban el código por usted y luego hablen de ello. Pregúnteles por qué hicieron las cosas de cierta manera, y si otra manera podría no ser mejor. Descubrirá más de ese tipo de proceso que pidiéndoles (en sentido figurado) orinar en una taza justo en frente de usted.

Answer 6

Contras: ninguno. Cada vez que gaste en configurar una PC, diseñando una prueba de código y revisarla, ahorrará un dolor de cabeza sin tener en el futuro.

Pros: "Confiar, pero verificar" - Ronald Regan. Muchas veces que he visto y escuchado de personas finalmente lo dejaron ir de un puesto, donde en la entrevista pensarías que estabas recibiendo una estrella de rock. La prueba está en el pudín; Quiero ver qué pueden hacer. Representará lo que sucede una vez que invierte tiempo y dinero contratando a alguien y pegará un nuevo proyecto frente a ellos.

Answer 7

Contras:

• Requiere que tenga una persona técnica en la entrevista

Pros:

• Ahorra mucho tiempo y angustia en el futuro si evita contratar a alguien que no pueda programar

Answer 8

Cuando entrevisté para mi trabajo actual, me dieron una lista de preguntas para escribir código por el reclutador. Estaba muy impresionado porque las preguntas obviamente fueron escritas por alguien que tenía un conocimiento profundo de SQL, por lo que funciona en ambos sentidos.

Answer 9

Tú De Verdad Desea que la persona escriba código en la entrevista; aún mejor, haga que emparejen el programa con un miembro en su equipo por X de tiempo (lo que sea que pueda pagar cómodamente en el tiempo/mano de obra).

Es prácticamente una de las únicas formas en que puede saber si esa persona puede codificar o no.

Prefiero un poco la programación de parejas, ya que mostrará el trabajo de su equipo, les da un ideal real para trabajar y les permite trabajar en un problema 'real' (la otra persona en la pareja puede guiarlos más allá de los detalles ambientales de que el entrevistado nunca podría saber razonablemente).

Hemos comenzado a usar esta política de contratación y estamos muy contentos con los resultados.

Answer 10

Juzgas un pájaro por sus plumas y un programador por su código.

Cuando comencé con la compañía actual para la que estoy trabajando, me pidieron que escribiera algún código C que genere o verifique la paridad de alguna entrada binaria (dependiendo de si está codificando o decodificando). Esta fue una pregunta de entrevista exactamente porque este tipo de problemas se resuelven durante el trabajo. Por supuesto, estoy pensando en no verificar la paridad, sino en trabajar en un nivel bajo.

Answer 11

Todas las respuestas hasta ahora (que leí) no abordaron el hecho de que La prueba de Joel no es (solo) una lista de mejores prácticas para empresarios Pero una lista de verificación para aliviar su Evaluación de un empleador de prospecto.

La cosa es ... si prueban a fondo sus candidatos, entonces probablemente contratan a personas que conocen sus cosas ... eso significa para ti

1. menos dolor de cabeza y también
2. la mayor posibilidad de aprendizaje algo de tus compañeros de trabajo

en lugar de arreglar los insectos después de ellos ...

Answer 12

Yo diría:

Pros

• Demuestra que el candidato tiene al menos un conocimiento pasable de la programación, ya que los currículums pueden fabricarse/embellecerse
• Si el entrevistador discute el código con el candidato, en lugar de que sea más como una prueba escrita, podría ser un buen indicador de cómo "combina" socialmente y si el candidato es una buena opción para la empresa/empresa y el equipo son buenos Se adapta al candidato

Contras

• Podría ser insultante para los candidatos si las preguntas son tonterías de memoria/triviales que nunca surgirían durante el trabajo (por ejemplo, "escribir un tipo de burbujas" cuando todos los marcos modernos que uno estarían usando en el trabajo se ha incorporado a la clasificación ", revertir una cadena. "Cuando hay un incorporado Reverse método o similar, o para pruebas escritas como "¿Cuáles son los argumentos para el Foo método del Bar clase ", cuando cualquier idiota podría buscar en Google eso o usar la documentación) en lugar de las preguntas arquitectónicas/de diseño que muestran que el candidato puede terminar las cosas y resolver problemas comerciales.

Answer 13

Un profesional es que muestra que alguien tiene conocimiento básico de programación o lo que sea (la última vez que me encontré con eso, me sorprendió cuán básica era la pregunta de SQL). También puede servir como base para una discusión técnica, preguntando por qué el candidato hizo tal y tal, y cómo podría mejorarse.

Toma tiempo en la entrevista, que podría usarse para otras cosas. Además, escribir código en una pizarra no es un entorno natural, y algunas personas tendrán problemas cada vez más graves con él. Podría hacer que pierdas un desarrollador que simplemente se pone nervioso sin herramientas o referencias normales.

Answer 14

La programación es una habilidad altamente técnica con un montón de "entregables" claros. O un candidato puede o no puede entregarlos. Por lo tanto, no hay "contras" para hacer preguntas técnicas. Es completamente para decir: "Muéstrame algún código para esta aplicación o" Muéstrame el código para una aplicación que ya ha escrito ".

No hacerlo podría conducir a un resultado como el siguiente: un hombre rico entrevistó a un tutor para enseñar a sus hijos a jugar al ajedrez (como un ejercicio de expansión mental). El tutor abrió una tabla a cuadros y comenzó a hablar sobre los 64 cuadrados, pero no tocó una pieza de ajedrez. Presionado por el tiempo, el padre contrató al tutor de todos modos. Y el tutor enseñó a los niños a jugar a los dolores.