¿Cuáles son los pros y los contras para el empleador de las preguntas de código durante una entrevista? [cerrado]
16
La pregunta # 11 de Joel Test es: "¿Los nuevos candidatos escriben el código durante su entrevista?". ¿Cuáles son los argumentos a favor y en contra de pedirles a los nuevos candidatos que escriban un código durante la entrevista y que tomen una decisión al respecto?
¿Escribir código como lo escribe físicamente con un lápiz y su mano o escribir como en código de tipo en una máquina?
Chris
La principal estafa es hacer preguntas estúpidas o inútiles y pensar que lo hiciste bien. Como el comentario de alguien sobre que se le pida que escriba una lista vinculada.
Respuestas:
13
No veo los contras. Una entrevista tiene muchas partes, y un candidato debe ser respaldado 'en la cadena' varias veces.
Entrevisto a ~ 10 personas semanalmente. Realmente, realmente, REALMENTE aprecio el hecho de que RRHH haya hecho todo el trabajo de fondo y me haya presentado muchas notas. Para cuando lleguen a mí, es hora de que califique sus exámenes.
Las pruebas dependen completamente de la posición. En general, trato de sondear:
Habilidad de programación general. ¿Se pueden utilizar los operadores de manera efectiva? ¿Puedes concebir un sistema numérico que tenga una raíz que no sea 10?
¿Sabes cómo hacer lo que te estamos contratando?
Evaluación de sus contribuciones a cualquier proyecto de código abierto que haya enumerado
Intento que sea breve y divertido. Cuando entro en la oficina, tomo las respuestas, las reviso y luego realizo una entrevista secundaria. Para ser contratado, generalmente tiene que pasar por tres entrevistas.
También calculo qué tan bien se integrará con el equipo que lo recibirá. Ese equipo cuenta conmigo para hacerlo de manera efectiva.
Una cosa es responder preguntas en forma meta, y otra es realmente producir código. Si voy a contratarte, realmente necesito verte producir código.
Hmmm ... me considero un desarrollador calificado. Durante mis últimas tres entrevistas, cuando me preguntaron sobre algo como "qué hace un método en particular", o algo similar, decidí dejarlo. Como nunca busco un trabajo, donde estaría destinado a hacer algo que conozco muy bien. No es interesante. Como dijo mi ex jefe: "¿Reutilizable? Los programadores deberían ser reutilizables, programas, tal vez".
duros
@duros Siento escuchar eso. Un buen entrevistador debería ser capaz de hacer que el proceso sea divertido ... y debería darse cuenta de que otros programadores odian las pruebas.
Tim Post
No es que no me sienta cómodo cuando me hacen la prueba. Solo me doy cuenta de qué oportunidades para aprender y probar algo nuevo tendría, si me van a contratar como codificador ... Durante el último envié al entrevistador para leer los javadocs ...: - / Tal vez, yo ' estoy equivocado ...
duros
10
Una vez me pidieron en una entrevista escribir accesores para una lista vinculada en Perl. En los 8 años que llevo trabajando con Perl, no he encontrado un solo programa de producción que utilice listas vinculadas. Por supuesto, me metí y produje, en papel, métodos insert () y remove () y un objeto basado en hash que pensé que haría el trabajo. Lo primero que dijo el entrevistador cuando miró el periódico fue "Te faltan algunos puntos y comas"
leed25d
1
es otro producir código en realidad ; esto es muy, muy cierto. En repetidas ocasiones me han sorprendido las personas que describen un algoritmo plausible pero ni siquiera pueden comenzar a reducirlo a código. Eso, o han patinado sobre algún paso no algorítmico que no se puede evitar al escribir código.
Poolie
34
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 tengas una persona técnica en la entrevista
¿Puede "Exigir que tenga una persona técnica en la entrevista" ser considerado una estafa?
Yeikel
2
Supongo que depende de si estás tratando de desempeñar un papel o simplemente ocupar una silla. Pero en mi opinión, no, no se puede considerar una estafa.
Armand
19
Si fueras a contratar a un malabarista, estarías loco si no hicieras malabares por ti. O un músico tendrías una 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 los programadores de una malabarista de demostración rápida.
+1 para el enlace. Todavía creo que hacer malabares no es recordar cosas como firmas de métodos o similares, sino solo poder pensar y resolver problemas que nunca antes conociste ...
duros
44
Excepto que el malabarismo es una habilidad inmediata con solo unas pocas variantes, a menudo realizada frente a una audiencia. La programación es una tarea pesada y profunda, que rara vez se realiza como tal. También es mucho menos productivo en papel o pizarra. Dicho esto, las pruebas de pseudocódigo (o ignorar errores triviales del medio) pueden ser muy útiles.
Bruce Alderson el
10
Creo que es súper útil, y siempre lo hago, pero como los beneficios se han cubierto tan bien, voy a discutir solo los aspectos negativos (aparentes).
Creo que es poco probable que las pruebas de código te den falsos positivos: hay pocas probabilidades de que alguien que realmente no puede escribir código logre fingirlo en una entrevista, al menos si tienes 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 están más en el lado falso negativo: ¿las pruebas de código lo llevarán a rechazar a la persona que realmente es el mejor candidato?
Miedo escénico
Es posible que tengas a alguien que sea realmente un buen desarrollador, pero que esté muy nervioso por esta entrevista, y que esencialmente se asuste. Actuar bajo presión es importante hasta cierto punto, pero lidiar con el miedo escénico no es una parte tan importante de ser un programador (en comparación con otras profesiones), y sería desafortunado rechazar a alguien que lo padece gravemente. Esto puede agravarse: si la persona no puede responder una pregunta que sabe que debe responder, puede ponerse más tensa. O, como en esta pregunta , sienten que no pueden hablar y codificar al mismo tiempo.
mitigación: comience con algunas preguntas para conocerse sobre sus antecedentes, objetivos, etc., antes de saltar a preguntas técnicas. Quizás comience con algunas preguntas técnicas más fáciles para que obtengan un poco de impulso. No seas un idiota durante la entrevista (discutiendo sobre punto y coma, 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 debería ponerle?
Hasta cierto punto, esto es como el problema con algunas preguntas de "rompecabezas": la persona tiene la idea o no y obtienes un resultado casi binario. La inteligencia probablemente afecta la probabilidad de tener esa idea, pero el muestreo solo unas pocas veces le da una medida cruda.
Esto me molesta sobre las preguntas de código (aunque todavía las uso). La mejor mitigación en la que puedo pensar es tener una rampa de posibles soluciones: la persona puede al menos escribir una respuesta cruda de fuerza bruta, o una respuesta para Una parte del problema. Darse cuenta de que es mejor que nada es una buena señal. Luego, si descubren más, pueden hacerlo más eficiente o con 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 la concentración durante largos períodos de tiempo, por no hablar de las habilidades interpersonales. Las preguntas de código realmente no prueban esto.
Pero, las preguntas de código no son las únicas preguntas que va a hacer: puede ver sus antecedentes, sus referencias, su trabajo de código abierto (si corresponde), para encontrar evidencia de esfuerzo sostenido, creatividad y habilidades interpersonales.
Saber cómo resolver problemas algorítmicos pequeños y cómo reducirlos a código es una condición necesaria pero no suficiente: si no puede resolver problemas pequeños y no puede escribir código no trivial, entonces todo el pensamiento global en el mundo no lo es te hará un desarrollador productivo.
Cualquiera podría resolver eso
No, aparentemente no. Como señala la famosa publicación de FizzBuzz , los problemas que podría pensar son trampa trivial no solo para los recién graduados, sino también para personas con años de experiencia en la industria. No se porque. O la prueba de código es una medida deficiente (lo cual es posible, aunque creo que es poco probable), o no estaban contribuyendo mucho a los proyectos en su currículum, o estaban haciendo mucho al copiar y pegar código algorítmico (que es posible)
Vale la pena reconocer que realmente puedes hacer mucho sin escribir ningún código algorítmico. La gente gana mucho dinero con aplicaciones cuyo valor está en los gráficos o en la lógica empresarial, no en lo que podríamos llamar "programación", y eso está bien. Pero, si realmente necesita programadores, no es una buena opción.
Puede que no esté bien calibrado
Si se le ocurre una pregunta, la respuesta puede parecerle fácil. Sin embargo, si se le hace una pregunta inesperadamente comparable, 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 en algunos desarrolladores que ya conoce y vea cómo lo hacen. Quizás alguien de tu equipo, que sabes que es muy inteligente, tendrá problemas con uno de ellos y puedes considerar ajustarlo. Quizás piensen en una respuesta mejor o diferente.
Es demasiado como trivia
Creo que las preguntas de código ciertamente pueden entrar en trivia, si insiste en que las personas conozcan API oscuras de memoria, o consigan la sintaxis perfecta, o recuerden la definición exacta de un algoritmo no trivial. Es razonable confiar en documentos, búsquedas en la web o errores de compilación para recogerlos, y tienen poca correlación con la experiencia real. Ni siquiera saber dónde es probable que esté la API es quizás una pista de que la persona no la ha usado recientemente, pero eso no es necesariamente un problema mientras no mientan en su currículum.
Entonces la respuesta a esto es bastante simple: no hagas preguntas triviales y no te obsesiones con los errores triviales. Recuerde al candidato cómo se llama la API o déjelo buscarlo; arreglar errores de sintaxis; no pruebe personas que memoricen definiciones de estructura de datos
¿Cómo te comparas?
Si tiene dos candidatos y ambos responden bien a las preguntas, ¿cómo elige entre ellos? Podrías elegir al que terminó más rápido, pero tal vez allí comiences a recoger liebres sobre tortugas. Podrías hacer otra ronda y hacer preguntas mucho más difíciles, pero tampoco estoy seguro de eso. Quizás solo les dé a ambos un A + e intente elegir entre ellos con otros criterios (o intente encontrar el dinero para contratar a ambos).
Una desventaja que se me ocurre 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 de mi 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 cometer errores tipográficos, seleccionan el código incorrecto, incluso cometen errores francos, ninguno de los cuales habrían cometido si no hubiera estado sentado allí. Demonios, he visto a personas comenzar a usar el menú para operaciones de cortar y pegar, 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 me dijo: "Solo muéstrame las matemáticas". Bueno, primero tuve que pensar en el problema antes de llegar a la matemática, así que eso me hizo dudar. Lo que puse en la pizarra al principio fue vergonzoso, y sentí que estaba perdiendo en ese momento. Eventualmente obtuve el momento A-ha y encontré la respuesta (en realidad, cuando finalmente se me ocurrió lo que realmente estaba preguntando), pero el "desastre" que hice antes de llegar me hizo sentir muy incómodo. Sin embargo, conseguí el trabajo, pero si el entrevistador hubiera sido menos paciente, podría no haberlo hecho.
Creo que si le das a los entrevistados una tarea de codificación, dales algo de tiempo a solas para resolverlo en una computadora, tal vez incluso en un IDE con el que estén familiarizados. Permítales escribir el código por usted y luego hablen sobre ello. Pregúnteles por qué hicieron las cosas de cierta manera, y si otra forma podría no ser mejor. Descubrirá más de ese tipo de proceso que pidiéndoles que (en sentido figurado) orinen en una taza frente a usted.
Eso está bien, sin embargo. El objetivo de una pregunta de entrevista de codificación no es probar la capacidad de escritura o incluso el conocimiento perfecto de la API. Los errores tipográficos y otras cosas pueden ser ignorados y, en cambio, te enfocas en el proceso de pensamiento del candidato y en la familiaridad con los fundamentos de la programación. Por ejemplo, una vez formé parte de una entrevista que mostraba la incapacidad absoluta del candidato para pensar unos pasos más adelante (solucionarían un pequeño problema, se darían cuenta de que creaba otro problema, etc.).
Adam Lear
2
¿Es "difícil de codificar frente a otras personas"? Multa. Solo contrato a personas que pueden hacer cosas difíciles. Uno de ellos es poder discutir el código (es decir, el programa) con (frente a) otras personas.
Kevin Cline
1
@kevin cline: Te pierdes mi punto. ¿Te importa cómo las personas obtienen resultados, o solo quieres que obtengan resultados de acuerdo a tus caprichos? Muchas personas pueden codificar perfectamente en un entorno de equipo, pero necesitan "tiempo a solas" para producir con la máxima eficiencia. Parece el tipo de persona que no habría contratado a Mark Zuckerberg porque necesitaba ser "conectado" para obtener la máxima productividad.
Robusto el
1
@Robusto: No estoy haciendo preguntas profundas en una entrevista. Solo necesito ver a alguien resolver un problema simple en unos minutos. Y necesito personas que puedan trabajar en equipo. Esto significa una capacidad y disposición para hablar sobre código. Claro, puedo extrañar a un gran programador que simplemente no puede manejar la presión de una entrevista. Está bien. Pero una mala contratación es desastrosa.
Kevin Cline
6
Contras: ninguno. Cualquier tiempo que pase configurando una PC, diseñando una prueba de código y revisándola le ahorrará un dolor de cabeza incalculable en el futuro.
Pros: "Confía, pero verifica" - Ronald Regan. Muchas veces he visto y oído hablar de personas que finalmente dejaron ir desde una posición, donde en la entrevista pensarías que obtendrías una estrella de rock. La prueba está en el pudín; Quiero ver qué pueden hacer. Representará lo que sucede una vez que invierta tiempo y dinero en contratar a alguien y presente un nuevo proyecto frente a ellos.
Si está entrevistando a desarrolladores sin que participen personas técnicas, está condenado de todos modos.
David Thornley
@David: Estoy de acuerdo, creo que los profesionales aquí superan con creces los inconvenientes, pero fue la única "estafa" en la que pude pensar.
Scott Whitlock
4
Cuando me entrevisté para mi trabajo actual, el reclutador me dio una lista de preguntas para escribir el código. Me impresionó mucho porque obviamente las preguntas fueron escritas por alguien que tenía un profundo conocimiento de SQL, por lo que funciona en ambos sentidos.
Tu realmente quiere tener el código de escritura persona en la entrevista - aún mejor, conseguir que se programa par con un miembro de su equipo por X cantidad de tiempo (lo que puede 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 la pareja, ya que mostrará el trabajo de su equipo, les dará un IDE real para trabajar y les permitirá trabajar en un problema 'real' (la otra persona en la pareja puede guiarlos más allá de los detalles ambientales que el entrevistado nunca podría saberlo razonablemente).
Comenzamos a usar esta política de contratación y estamos muy contentos con los resultados.
+1 para pruebas de pareja: demuestra tanto la capacidad de trabajar con un compañero de equipo / como la capacidad de codificar.
Bruce Alderson el
2
Usted juzga a un pájaro por sus plumas y a un programador por su código.
Cuando comencé con la compañía actual para la que estoy trabajando, me pidieron que escribiera un código C que genere o verifique el bit de 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.
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, sino una lista de verificación para facilitar la evaluación de un posible empleador .
La cuestión es ... si prueban a fondo sus candidatos, entonces probablemente contraten a personas que conozcan sus cosas ... eso significa para ti
menos dolor de cabeza y también
la mayor posibilidad de aprender algo de tus compañeros de trabajo
Demuestra que el candidato tiene al menos un conocimiento aceptable de programación, ya que los currículums se pueden fabricar / embellecer
Si el entrevistador discute el código con el candidato, en lugar de ser más como una prueba escrita, podría ser un buen indicador de cómo se "relaciona" socialmente y si el candidato se ajusta bien a la compañía / compañía y el equipo es bueno se ajusta al candidato
Contras
Podría ser insultante para los candidatos si las preguntas son tonterías triviales que nunca aparecerían durante el trabajo (por ejemplo, "Escribir un tipo de burbuja" cuando todos los marcos modernos que uno usaría en el trabajo tienen una clasificación incorporada, "Invierta una cadena "cuando hay un Reversemétodo incorporado o similar, o para pruebas escritas cosas como" ¿Cuáles son los argumentos del Foométodo de la Barclase ", cuando cualquier idiota podría Google o usar la documentación) en lugar de preguntas de arquitectura / diseño que muestran El candidato puede hacer las cosas y resolver problemas de negocios .
Creo que "Invertir una cadena" es una excelente pregunta inicial en una entrevista de codificación. Si no saben por dónde comenzar (y un número sorprendente de personas no lo saben), probablemente no quiera contratarlos. Si usan el método incorporado, eso es bueno, te dice que no intentarán construir su propia rueda si se proporciona una, pero luego presentan una situación hipotética en la que el método incorporado tiene un error para que puedan necesitan escribir el suyo. Luego puede usar su código como punto de partida para hacer otras preguntas, como cómo solucionar cualquier error, uso de memoria, tiempo de ejecución, etc.
Gabe
0
Un profesional es que muestra que alguien tiene conocimientos básicos de programación o lo que sea (la última vez que me encontré con eso, me sorprendió lo básica que era la pregunta 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.
Lleva 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. Podría hacerte perder un desarrollador que se pone nervioso sin las herramientas o referencias normales.
Lo que lo sorprendería aún más es cuántas personas más no pudieron responder a esa pregunta básica que quién podría.
HLGEM
0
La programación es una habilidad altamente técnica con un montón de "entregas" claras. Un candidato puede o no puede entregarlos. Por lo tanto, no hay "inconvenientes" para hacer preguntas técnicas. Es totalmente para decir, "muéstrame un código para esta aplicación, o" muéstrame el código de una aplicación que YA has 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 que expande la mente). El tutor abrió un tablero 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 les enseñó a los niños a jugar CHEQUERAS.
Eso solo muestra un ejemplo de un entrevistador incompetente, no la necesidad de jugar ajedrez en una entrevista. El hombre rico podría haberme preguntado "explíqueme Castling", o algo similar, e inmediatamente haber tenido una idea de lo que el tutor sabía.
Respuestas:
No veo los contras. Una entrevista tiene muchas partes, y un candidato debe ser respaldado 'en la cadena' varias veces.
Entrevisto a ~ 10 personas semanalmente. Realmente, realmente, REALMENTE aprecio el hecho de que RRHH haya hecho todo el trabajo de fondo y me haya presentado muchas notas. Para cuando lleguen a mí, es hora de que califique sus exámenes.
Las pruebas dependen completamente de la posición. En general, trato de sondear:
Habilidad de programación general. ¿Se pueden utilizar los operadores de manera efectiva? ¿Puedes concebir un sistema numérico que tenga una raíz que no sea 10?
¿Sabes cómo hacer lo que te estamos contratando?
Evaluación de sus contribuciones a cualquier proyecto de código abierto que haya enumerado
Intento que sea breve y divertido. Cuando entro en la oficina, tomo las respuestas, las reviso y luego realizo una entrevista secundaria. Para ser contratado, generalmente tiene que pasar por tres entrevistas.
También calculo qué tan bien se integrará con el equipo que lo recibirá. Ese equipo cuenta conmigo para hacerlo de manera efectiva.
Una cosa es responder preguntas en forma meta, y otra es realmente producir código. Si voy a contratarte, realmente necesito verte producir código.
fuente
Con disculpas a Scott Whitlock:
Contras:
Pros:
fuente
Si fueras a contratar a un malabarista, estarías loco si no hicieras malabares por ti. O un músico tendrías una 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 los programadores de una malabarista de demostración rápida.
fuente
Creo que es súper útil, y siempre lo hago, pero como los beneficios se han cubierto tan bien, voy a discutir solo los aspectos negativos (aparentes).
Creo que es poco probable que las pruebas de código te den falsos positivos: hay pocas probabilidades de que alguien que realmente no puede escribir código logre fingirlo en una entrevista, al menos si tienes 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 están más en el lado falso negativo: ¿las pruebas de código lo llevarán a rechazar a la persona que realmente es el mejor candidato?
Miedo escénico
Es posible que tengas a alguien que sea realmente un buen desarrollador, pero que esté muy nervioso por esta entrevista, y que esencialmente se asuste. Actuar bajo presión es importante hasta cierto punto, pero lidiar con el miedo escénico no es una parte tan importante de ser un programador (en comparación con otras profesiones), y sería desafortunado rechazar a alguien que lo padece gravemente. Esto puede agravarse: si la persona no puede responder una pregunta que sabe que debe responder, puede ponerse más tensa. O, como en esta pregunta , sienten que no pueden hablar y codificar al mismo tiempo.
mitigación: comience con algunas preguntas para conocerse sobre sus antecedentes, objetivos, etc., antes de saltar a preguntas técnicas. Quizás comience con algunas preguntas técnicas más fáciles para que obtengan un poco de impulso. No seas un idiota durante la entrevista (discutiendo sobre punto y coma, 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 debería ponerle?
Hasta cierto punto, esto es como el problema con algunas preguntas de "rompecabezas": la persona tiene la idea o no y obtienes un resultado casi binario. La inteligencia probablemente afecta la probabilidad de tener esa idea, pero el muestreo solo unas pocas veces le da una medida cruda.
Esto me molesta sobre las preguntas de código (aunque todavía las uso). La mejor mitigación en la que puedo pensar es tener una rampa de posibles soluciones: la persona puede al menos escribir una respuesta cruda de fuerza bruta, o una respuesta para Una parte del problema. Darse cuenta de que es mejor que nada es una buena señal. Luego, si descubren más, pueden hacerlo más eficiente o con 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 la concentración durante largos períodos de tiempo, por no hablar de las habilidades interpersonales. Las preguntas de código realmente no prueban esto.
Pero, las preguntas de código no son las únicas preguntas que va a hacer: puede ver sus antecedentes, sus referencias, su trabajo de código abierto (si corresponde), para encontrar evidencia de esfuerzo sostenido, creatividad y habilidades interpersonales.
Saber cómo resolver problemas algorítmicos pequeños y cómo reducirlos a código es una condición necesaria pero no suficiente: si no puede resolver problemas pequeños y no puede escribir código no trivial, entonces todo el pensamiento global en el mundo no lo es te hará un desarrollador productivo.
Cualquiera podría resolver eso
No, aparentemente no. Como señala la famosa publicación de FizzBuzz , los problemas que podría pensar son trampa trivial no solo para los recién graduados, sino también para personas con años de experiencia en la industria. No se porque. O la prueba de código es una medida deficiente (lo cual es posible, aunque creo que es poco probable), o no estaban contribuyendo mucho a los proyectos en su currículum, o estaban haciendo mucho al copiar y pegar código algorítmico (que es posible)
Vale la pena reconocer que realmente puedes hacer mucho sin escribir ningún código algorítmico. La gente gana mucho dinero con aplicaciones cuyo valor está en los gráficos o en la lógica empresarial, no en lo que podríamos llamar "programación", y eso está bien. Pero, si realmente necesita programadores, no es una buena opción.
Puede que no esté bien calibrado
Si se le ocurre una pregunta, la respuesta puede parecerle fácil. Sin embargo, si se le hace una pregunta inesperadamente comparable, 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 en algunos desarrolladores que ya conoce y vea cómo lo hacen. Quizás alguien de tu equipo, que sabes que es muy inteligente, tendrá problemas con uno de ellos y puedes considerar ajustarlo. Quizás piensen en una respuesta mejor o diferente.
Es demasiado como trivia
Creo que las preguntas de código ciertamente pueden entrar en trivia, si insiste en que las personas conozcan API oscuras de memoria, o consigan la sintaxis perfecta, o recuerden la definición exacta de un algoritmo no trivial. Es razonable confiar en documentos, búsquedas en la web o errores de compilación para recogerlos, y tienen poca correlación con la experiencia real. Ni siquiera saber dónde es probable que esté la API es quizás una pista de que la persona no la ha usado recientemente, pero eso no es necesariamente un problema mientras no mientan en su currículum.
Entonces la respuesta a esto es bastante simple: no hagas preguntas triviales y no te obsesiones con los errores triviales. Recuerde al candidato cómo se llama la API o déjelo buscarlo; arreglar errores de sintaxis; no pruebe personas que memoricen definiciones de estructura de datos
¿Cómo te comparas?
Si tiene dos candidatos y ambos responden bien a las preguntas, ¿cómo elige entre ellos? Podrías elegir al que terminó más rápido, pero tal vez allí comiences a recoger liebres sobre tortugas. Podrías hacer otra ronda y hacer preguntas mucho más difíciles, pero tampoco estoy seguro de eso. Quizás solo les dé a ambos un A + e intente elegir entre ellos con otros criterios (o intente encontrar el dinero para contratar a ambos).
fuente
Una desventaja que se me ocurre 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 de mi 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 cometer errores tipográficos, seleccionan el código incorrecto, incluso cometen errores francos, ninguno de los cuales habrían cometido si no hubiera estado sentado allí. Demonios, he visto a personas comenzar a usar el menú para operaciones de cortar y pegar, 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 me dijo: "Solo muéstrame las matemáticas". Bueno, primero tuve que pensar en el problema antes de llegar a la matemática, así que eso me hizo dudar. Lo que puse en la pizarra al principio fue vergonzoso, y sentí que estaba perdiendo en ese momento. Eventualmente obtuve el momento A-ha y encontré la respuesta (en realidad, cuando finalmente se me ocurrió lo que realmente estaba preguntando), pero el "desastre" que hice antes de llegar me hizo sentir muy incómodo. Sin embargo, conseguí el trabajo, pero si el entrevistador hubiera sido menos paciente, podría no haberlo hecho.
Creo que si le das a los entrevistados una tarea de codificación, dales algo de tiempo a solas para resolverlo en una computadora, tal vez incluso en un IDE con el que estén familiarizados. Permítales escribir el código por usted y luego hablen sobre ello. Pregúnteles por qué hicieron las cosas de cierta manera, y si otra forma podría no ser mejor. Descubrirá más de ese tipo de proceso que pidiéndoles que (en sentido figurado) orinen en una taza frente a usted.
fuente
Contras: ninguno. Cualquier tiempo que pase configurando una PC, diseñando una prueba de código y revisándola le ahorrará un dolor de cabeza incalculable en el futuro.
Pros: "Confía, pero verifica" - Ronald Regan. Muchas veces he visto y oído hablar de personas que finalmente dejaron ir desde una posición, donde en la entrevista pensarías que obtendrías una estrella de rock. La prueba está en el pudín; Quiero ver qué pueden hacer. Representará lo que sucede una vez que invierta tiempo y dinero en contratar a alguien y presente un nuevo proyecto frente a ellos.
fuente
Contras:
Pros:
fuente
Cuando me entrevisté para mi trabajo actual, el reclutador me dio una lista de preguntas para escribir el código. Me impresionó mucho porque obviamente las preguntas fueron escritas por alguien que tenía un profundo conocimiento de SQL, por lo que funciona en ambos sentidos.
fuente
Tu realmente quiere tener el código de escritura persona en la entrevista - aún mejor, conseguir que se programa par con un miembro de su equipo por X cantidad de tiempo (lo que puede 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 la pareja, ya que mostrará el trabajo de su equipo, les dará un IDE real para trabajar y les permitirá trabajar en un problema 'real' (la otra persona en la pareja puede guiarlos más allá de los detalles ambientales que el entrevistado nunca podría saberlo razonablemente).
Comenzamos a usar esta política de contratación y estamos muy contentos con los resultados.
fuente
Usted juzga a un pájaro por sus plumas y a un programador por su código.
Cuando comencé con la compañía actual para la que estoy trabajando, me pidieron que escribiera un código C que genere o verifique el bit de 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.
fuente
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, sino una lista de verificación para facilitar la evaluación de un posible empleador .
La cuestión es ... si prueban a fondo sus candidatos, entonces probablemente contraten a personas que conozcan sus cosas ... eso significa para ti
en lugar de arreglar errores después de ellos ...
fuente
Yo diría:
Pros
Contras
Reversemétodo incorporado o similar, o para pruebas escritas cosas como" ¿Cuáles son los argumentos delFoométodo de laBarclase ", cuando cualquier idiota podría Google o usar la documentación) en lugar de preguntas de arquitectura / diseño que muestran El candidato puede hacer las cosas y resolver problemas de negocios .fuente
Un profesional es que muestra que alguien tiene conocimientos básicos de programación o lo que sea (la última vez que me encontré con eso, me sorprendió lo básica que era la pregunta 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.
Lleva 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. Podría hacerte perder un desarrollador que se pone nervioso sin las herramientas o referencias normales.
fuente
La programación es una habilidad altamente técnica con un montón de "entregas" claras. Un candidato puede o no puede entregarlos. Por lo tanto, no hay "inconvenientes" para hacer preguntas técnicas. Es totalmente para decir, "muéstrame un código para esta aplicación, o" muéstrame el código de una aplicación que YA has 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 que expande la mente). El tutor abrió un tablero 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 les enseñó a los niños a jugar CHEQUERAS.
fuente