¿Cuál es la mejor manera de discernir un excelente programador en una entrevista de trabajo?

82

En el marco de una entrevista: ¿Cuál es la mejor manera de identificar de manera confiable cuando alguien es un excelente programador ? Con esto quiero decir que es uno de los que es 10-15 veces más eficiente / rápido / mejor que sus pares hacia el extremo inferior del espectro.

Muchos de nosotros hemos oído hablar del problema FizzBuzz como una forma de eliminar a los débiles. Ciertamente, tomar de 5 a 10 minutos para resolver ese problema es un indicador serio de que un solicitante es un candidato débil. Creo que un buen indicador es poder resolverlo tan rápido como puedas escribir. Sin embargo, esto no parece suficiente.

¿Es tal vez algo como darle un programa de errores moderadamente complicado y ver qué tan rápido puede asimilarlo e identificar todos los problemas con él?

Claudiu
fuente
La pregunta supone que se puede hacer de manera confiable.
Anthony
no necesariamente. una respuesta válida sería 'no hay forma'
Claudiu

Respuestas:

65

Pido disculpas a cualquiera que no le interesen las respuestas largas, pero creo que es bastante importante calificar a sus candidatos antes de contratarlos. Cualquiera que haya realizado una cantidad significativa de entrevistas en esta industria sabe que la mayoría de los candidatos no durarán los primeros 15-30 minutos de una entrevista, por lo que la mayor parte de esta lista no será necesaria. Solo tenga en cuenta lo costoso que es (tanto financiera como emocionalmente) despedir a alguien antes de descartar mi lista como exagerada. He tratado de enumerar los temas de mi entrevista aquí por orden de importancia.

Inteligencia general (enigmas / rompecabezas de lógica)

Conocimiento de informática

Ejercicios de programación

  • MCD , Factorial , Fibonacci , Torres de Hanoi
  • Cadena y lista de inversión
  • Determine si una lista vinculada individualmente tiene un bucle (¿puede hacerlo con solo dos punteros?)
  • Encuentra el error

Conocimiento de técnicas de programación orientada a objetos y patrones de diseño comunes.

Análisis de algoritmos ( complejidad de tiempo de ejecución O (n) y requisitos de almacenamiento)

Uso de herramientas y metodologías.

Conocimiento de vulnerabilidades y ataques de seguridad comunes.

Matemática Básica

Criptografía

  • Criptografía de clave pública
  • Criptografía de clave simétrica
  • Funciones hash
  • Protocolos criptográficos (intercambio secreto, pruebas de conocimiento cero)

Matemáticas discretas

  • Lógica
  • Teoría de conjuntos
  • Teoría de grafos
  • Teoría de la información
  • Combinatoria
  • Pruebas (como la existencia de números irracionales, números primos infinitos)

También es posible que desee echar un vistazo al libro Programación de entrevistas expuestas . Es una buena referencia sobre el tema.

rboyd
fuente
10
Uf, esa debe ser una larga entrevista.
Rick Minerich
8
Hoy intenté resolver "Crossing Bridges" con mi compañero de equipo de la competencia de programación ACM. La única diferencia es que tenemos que resolverlo para cualquier cantidad de personas. Nos llevó unos 30 minutos resolver cualquier cantidad de N personas ... pero en una entrevista, siento que los acertijos son una métrica pobre.
52
En una entrevista, los acertijos apestan porque el entrevistado está nervioso, no piensa bien, etc. Además, ¡muchos acertijos son a-ha! escriba cosas que realmente no le digan nada sobre el candidato.
11
Encuentro estos problemas matemáticos de alta dificultad. Después de haber terminado su licenciatura en informática durante 10 años, ¿cómo puede recordar cómo demostrar números irracionales y cosas así?
14
El problema con los rompecabezas es que la mayoría de la gente no los ha resuelto; Acaban de ver las respuestas antes. Por lo tanto, los candidatos más inteligentes fingirán no haberlos visto y encontrarán vacilantes la respuesta que ya conocen. Si su objetivo es contratar personas inteligentes, no personas engañosas, entonces los rompecabezas son una mala elección.
Kyralessa
28

Ah, la eterna pregunta.

Hice muchas entrevistas este año (tengo dos candidatos programados para mañana), y en mi experiencia, la contratación se trata más de la intuición y las habilidades de las personas, y menos del conocimiento técnico.

  1. Tómese su tiempo con CV. Algunos CV se pueden rechazar en segundos, otros demoran media hora. A veces pienso en el candidato basado en el CV mucho más de lo que lo entrevisto. Algunas veces he preparado preguntas de entrevista específicamente para ese candidato, a pesar de que generalmente no tengo preguntas preparadas.

  2. Conocimiento técnico: hay un mínimo que quiero, y esto suele ser bastante fácil de decir. En caso de duda, durante la entrevista, hable sobre los proyectos que mencionó en el CV y ​​profundice lo que necesite. Esto suele ser más que suficiente para decirle lo que sabe y lo que lo motiva. La educación no es importante, los trabajos previos son importantes, los posibles proyectos personales tienen un puntaje alto.

  3. Pregúntele qué quiere hacer y hacia dónde quiere ir con su carrera: ¿necesita lo que tiene y puede proporcionar lo que quiere? Además, cerca del final de la entrevista, generalmente pregunto sobre un salario preferido. Si está fuera de mi alcance, o si no pagaré tanto por lo que sabe, ahí es donde terminaremos la entrevista.

  4. Lo más importante es que el candidato debe encajar en el equipo, y debo sentirme seguro de que podremos trabajar juntos. No necesito que me guste, pero debo ser capaz de manejarlo, y él necesita poder manejarme. Si ese no es el caso, lo aprobaré, porque no podré usar su conocimiento técnico. Por otro lado, si este es el caso, y si aprende rápido, su falta de conocimiento técnico no me impedirá contratarlo.

He entrenado a chicas de Recursos Humanos para que me pasen cualquier currículum tan pronto como las obtengan; Programo la entrevista personalmente, lo más rápido que pueda (idealmente pasado mañana después de recibir un CV para buenos CV). Luego recibe una entrevista de media hora o una hora conmigo y al menos con un compañero de trabajo (generalmente mi jefe o miembro del equipo), donde puedo conocerlo y responder cualquier pregunta. Incluso si rechazo su solicitud en el acto, recibe un recorrido de 20-30 minutos por la compañía y hablo sobre lo que hacemos y cómo lo hacemos. Luego lo envié a Recursos Humanos para una prueba psicológica y un poco de codificación en papel / SQL realmente muy básico. Ambas pruebas casi nunca juegan un papel importante en mi decisión, es más una verificación que juzgué correctamente en la entrevista. Después de los resultados, son 15 minutos de conversación donde le hago una oferta, y si negociamos los términos con los que ambos estamos contentos, lo contratan.

Este es un proceso por el que tuve que luchar a través de la burocracia de la empresa, después de perder un par de grandes candidatos, y que funciona porque soy yo quien decide sobre la contratación (aunque escucho los consejos de RR.HH. y compañeros de trabajo, mi la palabra es final) Más tomadores de decisiones, proceso más largo. Cuanto más largo sea el proceso, más tienes que ser Google para obtener la parte superior del cultivo.

Tan pronto como estoy seguro de que no es un partido, termino la entrevista, él recibe la gira de la compañía y se acabó. Esto puede ser tan corto como dos minutos por teléfono mientras se programa la entrevista. Incluso si rechaza a un candidato, venda la empresa. Si hizo un buen trabajo, la buena contratación puede ser de boca en boca del candidato rechazado.

Además, un consejo. Envíe cartas de rechazo (o correos electrónicos) para cada solicitud que reciba. En mi empresa actual, generalmente se lo dejo a RR. respondió en lugar de dejarme preguntándome si algún día responderán ".

Domchi
fuente
Pruebas psicologicas?
55
@ Ink-Jet: no, la prueba psicológica fue correcta: se le pide al candidato que escriba un código que será mantenido por un hombre violento que también conoce la dirección de su casa.
Eso es lo que leí la primera vez, para ser honesto.
@Grundlefleck - sí, eso es correcto. :)
Domchi
2
Si recibiera tu carta de rechazo, te lo agradecería. Fui rechazado por el silencio después de llegar a una entrevista telefónica, y es estresante.
01d55
24

Esta respuesta es un poco fuera de la caja, pero creo que es un punto valioso.

Los mejores programadores rara vez se entrevistan. No tienen que hacerlo . Si su empresa cambia particularmente el mundo, o está envuelta en secreto de manera emocionante, o varios programadores que respetan han ido allí, entonces pueden postularse, pero normalmente los grandes programadores obtienen trabajos a través de su red de asociados, no enviando currículums.

Entonces: la mejor manera de decirle a un excelente programador en una entrevista de trabajo es que no está allí .


fuente
2
tan cierto ... gran punto. :)
Arnis Lapsa
55
Entonces ... ¿es "a quién conoces" en lugar de "lo que haces"? Los programadores verdaderamente horribles también obtienen su trabajo a través de amigos y familiares. Oh, lo siento "red de asociados".
Philip
17

Cualquier respuesta debe incluir ejemplos de código. Contratar a un programador sin ver su código es como contratar a un chef sin probar su cocina.

Andy Lester
fuente
11

Posiblemente un programador "excelente" no viene a usted para una entrevista. Probablemente tengas que robarle a alguien más.

interestar
fuente
doh! Esta respuesta parece ser cada vez más popular. Del mismo modo que tengo que empezar a salir y la solicitud de empleo ...
Interstar
9

Una forma de distinguir a los programadores apasionados de los programadores "Solo quiero un trabajo" es preguntarles qué libro están leyendo esta semana. Luego pregúntales sobre los libros que han leído en las últimas semanas.

He descubierto que los programadores apasionados SIEMPRE leen, y generalmente la lista incluirá algunos programas / Comp. Sci. libros en la lista reciente.

No se trata solo de mantenerse "al día con la profesión": los programadores apasionados tienen un deseo y un amor por la programación y tienden a devorar material sobre una variedad de temas, no solo el idioma que están usando ahora, sino también las metodologías, otros idiomas (especialmente nuevos o "extraños" o antiguos), otros aspectos de TI (tal vez robótica, o IA, o juegos, o ...)

Si no tienen una lista de libros reciente, en mi experiencia probablemente no sean programadores.

Salud,

-R

Huntrods
fuente
8
Mi lista de libros recientes es casi siempre ficción. Mi lectura técnica reciente está casi completamente en línea, porque está más actualizada.
1
Mejor aún, pregúntales qué libro escribieron este mes. :)
7

Hay diferentes escalas de tiempo en las que alguien puede ser "rápido": algunas personas inteligentes pueden resolver acertijos difíciles en segundos, pero algunas personas inteligentes producen mucho código bueno en un mes, aunque no sean tan rápidos en las preguntas de la entrevista.

Pregunte a los candidatos si están activos en algún proyecto de código abierto en el que pueda revisar parte de su código, y dedique algún tiempo a leer los archivos de la lista de correo de los proyectos y los registros de confirmación. Eso le dirá mucho más que cualquier cosa que los candidatos puedan demostrar en una entrevista. (Por supuesto, esto no puede reemplazar la entrevista, ya que no todos los buenos programadores hacen trabajo de código abierto).

Jouni K. Seppänen
fuente
7

El libro " Smart and Gets Things Done: Joel Spolsky's Concise Guide to Finding the Best Technical Talent " puede ayudar a encontrar una respuesta.

Tabla de contenidos:

  • Introducción
  • Capítulo 1: "Golpear las notas altas"
  • Capítulo 2: "Encontrar grandes desarrolladores"
  • Capítulo 3: "Una guía de campo para desarrolladores"
  • Capítulo 4: "Ordenar hojas de vida"
  • Capítulo 5: "La pantalla del teléfono"
  • Capítulo 6: "La guía guerrillera para las entrevistas"
  • Capítulo 7: "Arreglando equipos subóptimos"
  • Apéndice: "La prueba de Joel"

El artículo de Joel "La guía guerrillera para las entrevistas (versión 3)" también puede ser útil.

Y el artículo "Hecho, y hace las cosas inteligentes" de Steve Yegge sobre el tema.

sergtk
fuente
4

Hágales una serie de preguntas que requieran que codifiquen y haga que las preguntas se vuelvan más difíciles. Si parecen disfrutar el desafío, probablemente tengas uno en vivo.

Si no pueden responder la primera pregunta fácil, como "escribir un bucle for" o algo estúpidamente fácil, entonces sabes que esta persona no puede codificar.


fuente
4

Pídales que codifiquen en una pizarra. Solo de esta manera podrás saber si saben cómo escribir código.


fuente
No sé por qué esto fue rechazado. Si un programador no puede escribir código en una pizarra, ¿qué le hace pensar que podrá escribirlo en una computadora?
Kristopher Johnson
3
@Kristopher: Si un programador puede escribir un buen código en una computadora, ¿qué le hace pensar que podrá escribirlo en una pizarra? Esos son ambientes considerablemente diferentes.
David Thornley
La "prueba de pizarra" no pretende simular la codificación real. Es una oportunidad de ver cómo piensa el candidato, si el candidato puede describir lo que está haciendo, qué tan rápido el candidato forma una solución en su cabeza, etc. Alguien que simplemente mira la pizarra sin saber qué escribir probablemente tendrá El mismo problema en una computadora.
Kristopher Johnson
3

Debes juzgar principalmente el trabajo que ya han hecho. Cualquier código o idea que alguien genere durante una entrevista llena de ansiedad es un pobre representante de lo que realmente puede producir en un equipo.

Para hacer desafíos de codificación, use IM con algo como codepad.com y déjelos hacerlo desde la comodidad de su propia casa. ¿Escribe gran parte de su código en una pizarra frente a su jefe, con una fecha límite de 30 minutos y su bonificación en la línea? Yo no.

Entonces, ¿la entrevista no tiene sentido? No, pero el énfasis debe estar en ellos explicando lo que han hecho y exactamente lo que han contribuido.

También estarás sujeto a todo tipo de prejuicios psicológicos una vez que te encuentres con alguien cara a cara. No contrates accidentalmente a un programador porque hicieron un mejor contacto visual o son más altos que otra persona. Para sortearlos, realizaría la mayor cantidad de entrevistas posible por mensajería instantánea / correo electrónico antes de conocerlos cara a cara.


fuente
Puede revertir este efecto observando los sesgos psicológicos de otras personas en el historial de contratación de candidatos. Las personas de baja estatura que han tenido altos cargos y han logrado cosas probablemente son realmente buenas. Las personas altas con la misma historia serán, en promedio, no tan buenas y sobrevivirán en puntos de halo.
Tim Williscroft
2

El idioma no importa. La lógica lo hace. Me refiero a que los IDE y los cumplidores son tan buenos en estos días que cualquier buen programador puede aprender cualquier idioma (bueno, tal vez no ensamblador) en una semana; volverse decente en un par de semanas y ser muy bueno en un par de meses.

Es su cerebro (el de ella) lo que debes confirmar. Y tú haces eso mi hablar. Les pido que resuelvan problemas simples. No escribiendo código sino guiándome por su lógica para llegar a una solución.

Pero admito que si no puede escribir un bucle simple contando del 1 al 10, tienes problemas.

Stephen Cox
fuente
1

En primer lugar, hay una manera de tener una idea antes de que comience la entrevista:

Si tienen un blog o contribuyen a uno o más proyectos de código abierto, solo mire el código y los artículos que han escrito. En primer lugar, si han hecho cualquiera de estos, entonces tienen la iniciativa de hacer las cosas. Además, puede comparar estas cosas con la experiencia laboral que han enumerado en su currículum y hacerse una idea si se van a casa y aprenden más después del trabajo, o si se van a casa y se olvidan del trabajo después de las 5 p.m.

Básicamente, ¿les apasiona programar o no? Esa es la verdadera pregunta.

Chris Pietschmann
fuente
1

Tener un buen programador presente en la entrevista es lo mejor en mi opinión.

Solo un experto puede juzgar si el solicitante solo conoce muchas preguntas de la entrevista o si realmente está pensando en los problemas y puede entrar en detalles. Recuerde, no desea contratar personas para resolver acertijos de entrevistas, desea contratarlos para que realicen el trabajo real.

Los rompecabezas son para excluir a las personas que no entienden lo básico. Si desea evaluar la habilidad, prepare algunas cosas sobre las que usted (o su "buen programador") pueden entrar en detalles y centrarse en las que el solicitante tiene que pensar por un momento. ¿Cómo aborda los problemas de los que no conoce de inmediato la solución?

mdm
fuente
1

No creo que debas hablar de pasión en la entrevista. Francamente, parece que una empresa que busca 'pasión' realmente significa 'trabajar sin dinero para la idea'.

La pasión ni siquiera garantiza la excelencia. Quiero decir que paso casi toda mi vida programando, leyendo sobre programación, aprendiendo idiomas locos como Erlang o Clojure y no me pagan por nada de eso. Sin embargo, soy un asco en la programación.

Creo que un excelente programador debe tener una pista de los proyectos exitosos en los que ha participado activamente. Por lo tanto, hacer que un programador escriba algo por encima de FizzBuzz básico es innecesario en la entrevista. Hable sobre sus proyectos pasados ​​y lo que hicieron. ¿Estás contratando programadores para resolver los cubos de Rubik y contar canicas o trabajar en proyectos de software largos y grandes y agotadores de más de 50 líneas de coe?


fuente
1

http://www.inter-sections.net/2007/11/13/how-to-recognise-a-good-programmer/

Del artículo:


Los criterios en viñetas

Entonces, en resumen, aquí hay algunos indicadores y contraindicadores que deberían ayudarlo a reconocer a un buen programador.

Indicadores positivos :

  • Apasionado por la tecnología.
  • Los programas como pasatiempo
  • Hablará en voz alta sobre un tema técnico si se le anima
  • Proyectos paralelos personales significativos (y a menudo numerosos) a lo largo de los años
  • Aprende nuevas tecnologías por su cuenta.
  • Opinión 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ó a programar 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 no estar en CV)

Indicadores negativos :

  • La programación es un trabajo diario.

  • Realmente no quiero "hablar de compras", incluso cuando me animan

  • Aprende nuevas tecnologías en cursos patrocinados por la empresa.

  • Feliz de trabajar con cualquier tecnología que haya 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

  • Centrado 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

Ronny Brendel
fuente
¿Le importaría explicar más sobre lo que hace y por qué lo recomienda como respuesta a la pregunta que se hace? Las "respuestas de solo enlace" no son del todo bienvenidas en Stack Exchange
mosto
0

Un excelente programador también podrá trabajar con esos pares de bajo espectro. Mientras puedan hacer la prueba y no revolcarse en su ego, entonces tienes un buen candidato, ¿no?

Sin embargo, esa prueba de fizzbuzz es un poco divertida. La solución que se me ocurre utiliza el operador de módulo. Lo que solo sé por elaborar coordenadas de mapeo de hojas de caracteres (nunca mencionado en la escuela o la universidad) ¿El programador promedio sabría eso o he tenido una educación basura?


fuente
Me sorprende que no haya encontrado el operador de módulo. Me presentaron en los diferentes idiomas que aprendí durante el año.
2
Si se especializó en CS en la universidad, el operador del módulo está programando 101
Sorprendentemente, cosas como bit-shift y módulo se omiten en la universidad
Claudiu
Creo que depende de qué tipo de cosas estén tratando de enseñarte en la universidad. No creo que alguna vez haya usado módulo en un problema del mundo real, ni lo haya enseñado explícitamente. Pero es muy común en este tipo de ejercicio (y en las preguntas del examen).
interstar
2
En realidad, ambos generalmente se enseñan en la escuela primaria; en esa etapa se les conoce como "el resto" y "multiplicando por 10".
intuido el
0

Un criterio que uso es ver el 'tipo' de lenguajes y herramientas en las que ha trabajado, ya sea en proyectos académicos o profesionales y qué es exactamente lo que logró. ¿Siempre ha trabajado a nivel de aplicación usando bibliotecas estándar (siempre un tipo C # o VB6?) O ha realizado un proyecto usando C en Linux que trata de cosas difíciles como punteros, administración de memoria, recursión, sincronización de procesos, exclusión mutua, eventos, etc. Si él siempre ha usado estos conceptos básicos y fundamentales bajo alguna capa de abstracción, dudaré.

Obviamente, esto es además de hacerle escribir código. Nada es un sustituto de eso. Sin embargo, tengo en cuenta el hecho de que algunas personas pueden escribir código más rápido que otras, y las personas tienen un tiempo de respuesta diferente cuando están en el centro de atención de una entrevista.


fuente
recursividad, sincronización de procesos, exclusión mutua. Esas tecnologías son igualmente importantes si trabaja con C #, VB.NET, C o lenguaje ensamblador.
-1 - Esto está muy mal. 'Tipo' de lenguajes y herramientas son 100% 'irrelevantes'.
Morgan Herlocker