¿Cuál es la mejor manera de evaluar a los nuevos programadores? [cerrado]

50

¿Cuál es la mejor manera de evaluar a los mejores candidatos para obtener un nuevo trabajo (hablando simplemente en términos de habilidades de programación)? En mi empresa hemos tenido muchas malas experiencias con personas que tienen buenas calificaciones pero que no tienen habilidades reales de programación. Sus habilidades son simplemente como monos codificados, sin la capacidad de analizar los problemas y encontrar soluciones.

Más cosas que debo tener en cuenta:

  • El sistema educativo de mi país apesta, realmente apesta. los Las personas que son buenas en este tipo de trabajo son buenas porque tienen talento para ello. o realmente intenta aprender por su cuenta.

  • El título universitario / graduado / postgrado no significa necesariamente que sepas exactamente cómo hacer las cosas.

  • Las certificaciones tampoco significan nada aquí porque las personas a cargo del curso de certificación tampoco tienen habilidades (o están en trabajos de baja remuneración).

Realmente necesitamos obtener buenos candidatos que sean flexibles y no tengan pensamiento mecánico (porque este tipo de personas por experiencia tienen un bajo rendimiento).

Estamos en una institución gubernamental y las personas que son candidatos no necesariamente vienen de fuera, pero tenemos la posibilidad de aceptar o no candidatos hasta que encontremos la correcta.

Espero no estar sonando demasiado agresivo en mi pregunta; y BTW, yo también soy un programador.

edit: Me di cuenta de que aquí había algo realmente complejo. Desconectaré "la respuesta correcta" solo para permitir que la discusión sea fluida, sin ningún sesgo.

    
pregunta Rafael 27.03.2016 - 15:42

14 respuestas

51

En lo que respecta a la selección de candidatos, por lo general voy con un plan de tres huelgas:

  • Prueba regular con FizzBuzz- como preguntas de codificación y muchas preguntas de conocimiento donde tienen que dar ejemplos codificados. Dependiendo de la posición, pueden ser principios de OO, principios de diseño de SQL, etc. Incremento las dificultades de las preguntas a lo largo de la prueba para ver hasta dónde pueden llegar. La idea no es realmente tener respuestas a todas las preguntas (si es así, mejor), sino también ver si pueden reconocer cuándo no saben algo. La confianza es esencial, y no quiero que alguien me mienta en mi equipo.

  • Volver a la prueba con el candidato, y discutir sobre las respuestas. Posible extensión de las preguntas para alcanzar los límites del candidato. Esto puede ser extenso, y cuanto más extenso sea, mejor.

  • Última parte, pero no menos importante, The Code Review . Le pido al candidato que traiga una pieza de código (generalmente espacioo la prueba / discusión anterior y esta revisión unos días más, para que puedan escribir y pulir una pieza de código). Luego hacemos una revisión periódica del código con dos personas: una persona que trabajará directamente con el candidato y la persona que revisó la prueba con el candidato anteriormente. Con respecto a la revisión del código, puede leer este artículo desde JohnFX .

Al final de todo esto, deberías poder decidir si quieres que este candidato forme parte de tu equipo o no.

    
respondido por el Matthieu 12.04.2017 - 09:31
20

Comience por darles FizzBuzz para resolver . Eso debería eliminar lo peor de ellos.

Luego algo un poco más difícil, por ejemplo, cómo revertir una cadena sin funciones de biblioteca integradas. Pídales que hablen mientras resuelven para ver cuál es su proceso de pensamiento.

Puedes seguir dando problemas más difíciles si los encuentran muy fáciles, hasta que estés convencido de que pueden caminar y no solo hablar.

    
respondido por el Oded 15.12.2011 - 16:14
14

Solo busca la pasión por el trabajo.

Para citar a Joel, busque a las personas que son " Inteligente, y haga las cosas. "

El resto no importa

    
respondido por el CaffGeek 15.12.2011 - 17:18
13

Basado en mis 25 años de programación (que, sin duda, incluye solo 5 o 6 instancias de contratación de otros programadores):

Indicadores positivos:

  • Apasionado por la tecnología

  • Programas como pasatiempo

  • Hablará sobre un tema técnico si se te alienta

  • Proyectos colaterales personales significativos (ya menudo numerosos) a lo largo de los años

  • aprende nuevas tecnologías por su cuenta

  • Opiniones sobre qué tecnologías son mejores para varios usos

  • Muy incómodo con la idea de trabajar con una tecnología que no cree que sea "correcta"

  • Claramente inteligente, puede tener excelentes conversaciones sobre una variedad de temas

  • Comenzó la programación mucho antes de la universidad / trabajo

  • Tiene algunos "icebergs" ocultos, grandes proyectos personales bajo el radar CV

  • Conocimiento de una gran variedad de tecnologías no relacionadas (puede que no esté en el CV)

Indicadores negativos:

  • La programación es un trabajo diario

  • No quiero realmente "hablar", incluso cuando se lo alienta a

  • Aprende nuevas tecnologías en cursos patrocinados por la compañía

  • Feliz de trabajar con cualquier tecnología que hayas elegido, "todas las tecnologías son buenas"

  • No parece demasiado inteligente

  • Comenzó a programar en la universidad

  • Toda la experiencia de programación está en el CV

  • Enfocado principalmente en una o dos pilas de tecnología (por ejemplo, todo lo relacionado con el desarrollo de una aplicación Java), sin experiencia fuera de ella

Además, sugiero:

  • La prueba FizzBuzz (o algo así para probar la capacidad básica para escribir un algoritmo.
  • Versión más difícil de la prueba FizzBuzz (para llevarlos al punto de falla o casi falla)
  • Discuta su código y vea si están dispuestos a ser autocríticos y buscar mejoras (que probablemente no tuvieron tiempo de hacer en un corto en el examen de prueba) como:
    • buenos nombres de variables (he tenido programadores muy experimentados que usan variables en producción como "flag" (WTF ??)
    • modularización.
    • Anticipando problemas y haciendo "codificación defensiva"
  • La voluntad de ver las "fallas" como oportunidades de mejora. Creo que los mejores programadores siempre buscan defectos en su código anterior. No son tan egocéntricos como para pensar que encontrar un defecto es una afrenta personal. Lo ven como una oportunidad para hacerlo mejor. (Aquellos que no pueden ver las fallas de manera inquebrantable tampoco se sienten abrumados al ver una falla (y se vuelven súper poco seguros) o, para evitarlo, ignoran las fallas.
  • ¿Pueden depurar?
  • ¿Pueden ellos prueba de unidad? (He hablado con demasiados programadores que dicen "QC hace eso". No estoy hablando de Pruebas, estoy hablando de pruebas: escribe una función, ¿funciona? ¿Hace esfuerzos razonables para tratar con problemas probables (entrada nula, etc.)? Si no puedes hacer eso, ¿cómo saber cuándo has terminado?
  • ¿Tienen buenas habilidades de comunicación? (como mínimo: buena comprensión y autoconocimiento acerca de cuándo entienden o no lo hacen y disposición para decir "No entiendo, por favor, explícalo otra vez".

Gran parte del resumen anterior es de Cómo detectar a un buen programador , que es un gran artículo, centrado un poco más en los indicadores de mayor alcance. Definitivamente confirma mis intuiciones y experiencia. También hay muchas cosas (como "pasión") que normalmente no se mencionan en una lista de verificación de "qué es un buen programador".

    
respondido por el Clay Nichols 21.03.2012 - 14:40
10

La evaluación de la inteligencia de programación es una forma de prueba de Turing. Por lo tanto, no hay (actualmente) procedimientos de evaluación de formulario cerrado que se garantice que funcionen. Se requieren programadores inteligentes para reconocer a otros programadores inteligentes, pero solo con alguna probabilidad razonable.

Sus posibilidades serán mejores si tiene entrevistadores en su equipo que puedan oler los trabajos en la nieve, e instintivamente no les gusta trabajar con gente estúpida (incluso los que tienen buen aspecto, tienen un currículum impresionante y pueden escupir todas las soluciones enlatadas habituales de la memoria).

(Una metodología de posibilidad que ayudaría a la calidad del flujo de apilamiento como efecto secundario es desenterrar las preguntas antiguas del flujo de apilamiento, relacionadas de alguna manera con sus requisitos de trabajo, pero que en su opinión tienen respuestas inferiores; pregunte al entrevistado cómo lo harían. responda, y pídales que lo publiquen si es una buena respuesta. Similar a un recapcha para OCR de origen público.)

    
respondido por el hotpaw2 17.12.2011 - 00:35
7

Déles un problema, preferiblemente uno asociado con el dominio del problema en el que estarán trabajando, y pídales que discutan cómo lo abordarán. Puede hacer que solo discutan, seudodifiquen o escriban fragmentos de código real dependiendo de la confianza que tenga en su nivel de habilidad

Por ejemplo, si su organización realizó conferencias, pídales que describan cómo codificarían un sistema de registro en línea seguro. Deben ser capaces de cubrir algunos de los conceptos básicos y hacer buenas preguntas acerca de qué se debe implementar exactamente. A medida que interactúa, debe poder determinar si serán adecuados para su organización y la función que necesita que cumplan.

No soy un gran fanático de las pruebas de trivia de programación y los enigmas. Si bien pueden ser divertidos para algunas personas, también pueden molestar y / o estresar a otras personas, incluidas las personas que podrían ser la mejor opción para su equipo. Además, la información sobre muchas de estas pruebas está disponible en línea y fomentará la preparación de las pruebas y otras tácticas que reducirían su viabilidad para evaluar la capacidad del programador.

    
respondido por el jfrankcarr 15.12.2011 - 15:57
3

La lectura de esta pregunta y algunas de las respuestas que recibió me pidieron que escribiera un artículo que me parece interesante:

Prácticas extrañas de contratación al contratar desarrolladores de software

Ok, entonces el título del artículo es basura, pero el artículo llega al corazón del problema. No es el problema del candidato que hayas elegido entrevistarlos, no importa cuán inapropiados sean para el rol que tienes en mente. Si no ha logrado definir un procedimiento de contratación bien estructurado que le permita encontrar las gemas en bruto, tendrá que vivir con las consecuencias, y sí, esto significa obtener algunos candidatos que podrían Nunca cumplas con tus expectativas. Para filtrar a sus candidatos en función de sus cartas y currículos, primero debe pedirles a sus solicitantes que escriban una carta sobre ellos mismos y lo que desean del rol, y luego ver cómo está escrito el currículum. Si solo tiene uno o dos candidatos potenciales para entrevistar, entonces probablemente haya realizado la preselección correctamente. Si no puede decidir entre sus candidatos en esta etapa y todavía tiene cien solicitudes, es probable que haya establecido sus expectativas demasiado bajas o que no haya sido lo suficientemente agresivo en su proceso de filtrado.

Cuando finalmente encuentres que el 1 o 2 candidatos que consideras realmente valen la pena, no solo hagas un puñado de preguntas insensatas, sino que inviertes el tiempo para conocer a estas personas y participar de manera abierta. Discusiones sobre ingeniería de software en general. Aprenderá más de un enfoque informal sobre el candidato que nunca en la situación de la entrevista tradicional (y de alguna manera adversa). Además, no se limite a conformarse con una sola entrevista, sino que lleve a sus candidatos clave a varias reuniones en las que se utilice una discusión abierta y donde el candidato pueda reunirse con sus posibles colegas. El tiempo nunca se pierde, ya que los candidatos inapropiados no prosperarán muy bien en una discusión altamente técnica y mostrarán sus fallas muy rápidamente a medida que bajan la guardia. Si pasa el tiempo y aún no tiene un contrato, ha tenido la oportunidad de aprender más acerca de cuáles son sus necesidades y puede continuar mejorando su proceso de entrevistas en base a lo que aprendió de las entrevistas "fallidas".

    
respondido por el S.Robins 24.11.2012 - 22:56
1

No ha dicho para qué idioma, pero es bastante fácil probar el conocimiento de alguien. También depende del nivel que está buscando, pero hay un grupo bastante grande de preguntas con respecto a las preguntas de la entrevista.

Sin embargo, usted decide mantener su entrevista, don 't hace esas preguntas de la entrevista de "rompecabezas de pensamiento lateral" .

    
respondido por el BЈовић 23.05.2017 - 14:40
1

Te sugiero que vayas con una pregunta de FizzBuzz y contrates la primera que pase. Otras pruebas tienden a ser defectuosas ya que no todos los buenos programadores abordarán un problema como usted, o manejarán una entrevista sin tartamudear, o conocerán los idiomas que quieren o les importan o tonterías como intercambiar números enteros sin una tercera variable (¿quién necesita eso de todos modos? es decir, ya que la memoria RAM supera los 128 bytes?).

Piénsalo. Si la pregunta de FizzBuzz elimina 199 de 200, entonces solo eliminará cientos de entrevistas. ¿Realmente ibas a entrevistar a cientos de prospectos?

Parece que disminuyen los rendimientos después de FizzBuzz. Eso es asumiendo que 199/200 es incluso aproximadamente cercano. Y supongo que TU tiempo también es valioso ...

    
respondido por el Harold Bamford 04.01.2012 - 22:22
0

No estoy seguro de si esto es un comentario o una respuesta, pero básicamente lo que dijo Matthieu. Desea preguntas sencillas y sencillas que demoren un minuto o dos (pero no más de 5) y deben tratarse de áreas diferentes.

Tales ejemplos de preguntas sencillas y estúpidas son preguntas sobre recursiones, como si tuviera una lista y debe imprimirla en orden inverso sin utilizar un bucle. Una simple pregunta de expresión regular si la expresión regular se realiza normalmente en su desarrollo. Una pregunta sobre bits y bytes si usa C ++ (escriba una plantilla que acepte char a long e imprima la representación binaria. No se requiere especialización, solo use sizeof () para averiguar la longitud de los bits)

Debería llevarle alrededor de < = 3 minutos por pregunta

    
respondido por el user2528 04.01.2012 - 08:35
0

Pregúnteles sobre el desafío de programación más interesante que hayan intentado resolver, pero no pudieron, qué enfoque utilizaron al resolverlo, por qué no pudieron resolver y qué otro enfoque creen que puede resolverlo.

Esto es suficiente para que yo juzgue las habilidades de un programador como programador.

    
respondido por el Priyadarshi Kunal 05.01.2012 - 09:11
0
  1. ¿Pueden defender lo que dicen que saben? Lo pusieron en el currículum / CV como una habilidad o algo que hicieron en otro proyecto. Vea cómo pueden profundizar sobre el tema.
  2. ¿Pueden aprender algo nuevo? Hable sobre un aspecto de alto nivel de la tecnología que está utilizando o algo específico de la empresa de negocios en la que trabaja y vea si pueden captar el tema. ¿Hacen preguntas inteligentes? ¿Pueden llegar a una analogía? ¿Es similar a algo que han hecho en otra industria o tecnología?

  3. ¿Estarían más bien programando? No tiene que ser el número uno en su lista, pero tienen que mostrar una preferencia por escribir código. Y me refiero a escribir código y hacer algo, no sentarme a hablar y dibujar en la pizarra todo el día. No para minimizar la planificación ni para promover la codificación de vaqueros, pero debes tener un código eventualmente. Evita a los que evitan el teclado. Esta no es una posición de gestión.

Puedes hacer algunas anotaciones en una escala del uno al diez o simplemente confiar en poder oler tu propia clase.

    
respondido por el JeffO 05.01.2012 - 15:47
0

Si te hace sentir mejor, existen malos programadores en casi todos los países. Cómo eliminarlos es el problema.

El primer deshierbe es el currículum. Una cosa que busco es una gran cantidad de experiencia lingüística y nada que describa lo que hicieron en ese idioma. He visto currículos que afirman que saben todos los idiomas inventados y, sin embargo, su experiencia demuestra que solo han trabajado con Access y Visual Basic. Esos van directamente a la basura. 10 hojas de vida van directamente a la basura (especialmente las hojas de vida de personas con menos de 2 años de experiencia que he recibido). De los recién graduados universitarios con poca experiencia, tienes que ser muy exigente con la forma en que se presentan. Los mejores candiatos son cuidadosos con sus currículos, no tienen errores. ¿Realmente estás buscando a alguien a quien le importe tan poco que no se molestó en revisar su currículum?

Los curriculums vitae preparados profesionalmente van a la basura también. Una vez que haya leído cientos de currículos, puede seleccionarlos ya que usan exactamente la misma redacción. No puedes confiar en el contenido de un currículum preparado profesionalmente y sabes que la persona no hizo su propia preparación. Este es el tipo de persona que confiará en otros para resolver sus problemas por él, ¿realmente quieres eso en una posición de programación?

Busque cosas que hagan que la persona se destaque por las que elija. Eso es más difícil, por supuesto, con los que están recién salidos de la escuela, pero busque logros, contribuciones al código abierto, etc.

La próxima eliminación es la entrevista telefónica. Pregunte sobre los conceptos básicos que se relacionan con el trabajo real que tiene. Si las personas no tienen un conocimiento básico de los conceptos que necesita que tengan, no vale la pena molestarse en participar en una entrevista personal. Los jóvenes a menudo piensan que esto es injusto porque pueden buscar todo en Internet, pero la verdad es que nunca he conocido a un buen programador que haya tenido que buscar todo en Internet. Debe tener algún conocimiento de su profesión que no tenga que buscar cada vez.

Después de la entrevista telefónica, debe seleccionar los mejores 4-5 candidatos y la entrevista. Por supuesto, si solo tiene 1-2 buenos candidatos, no se moleste en entrevistar a las personas que ya eliminó. Ahora va a hacer las preguntas difíciles y tener una idea de cómo abordan los problemas. Nunca usaría la prueba de fizzbuzz porque es demasiado conocida, por lo que las respuestas no le dicen nada. En su lugar, inventa algunos problemas desde tu propio código base. Podría darles un requisito y una pieza de código y preguntarles si el código cumple con el requisito y, de no ser así, por qué no y qué podrían hacer para que cumpla con el requisito. Les pido que describan el problema de programación más difícil que han tenido que resolver y qué pasos tomaron para encontrar la respuesta. Me gustaría hacer algunas preguntas técnicas más a fondo. Recuerde que está tratando de familiarizarse con su competencia técnica, su capacidad de resolución y depuración de problemas y su capacidad para adaptarse a su equipo actual. También hago preguntas que probablemente no saben la respuesta para juzgar qué tan bien manejan el estrés, es un trabajo estresante, no quiero a alguien que se retire en la entrevista porque el estrés del trabajo es mayor que el estrés de la entrevista. . Busco fortalezas en áreas en las que actualmente estamos débiles y con capacidad para trabajar en equipo y presentarnos a los clientes (nuestros desarrolladores tratan ampliamente con los usuarios), su lista puede ser diferente.

    
respondido por el HLGEM 21.03.2012 - 16:02
-1

Los candidatos deben tener un problema del mundo real para resolver con la libertad de usar cualquier tecnología.

Si ella sale volando, ¡ella está adentro!

    
respondido por el SHOUBHIK BOSE 15.12.2011 - 18:26

Lea otras preguntas en las etiquetas