¿Cómo reconocer a un buen programador? [cerrado]

Haga que hablen sobre lo que les interesa. Todavía tengo que encontrarme con un desarrollador que sea realmente apasionado cuando hable sobre programación pero que realmente no pueda codificar. Es posible que existan, por supuesto, y su entrevista también debería verificar la competencia, pero la pasión es un buen indicador de mi experiencia. (Tenga en cuenta que no es lo mismo que poder "hablar lo que se dice" en términos de palabras de moda).

Pregúntales qué es lo que no les gusta de su idioma o plataforma favorita. ¿Cómo arreglarían las cosas? ¿Qué les gustaría ver en la próxima versión? ¿Tienen proyectos de hobby? Si tienen un blog, léelo. Compruebe su presencia general en línea.

Contratar a personas buenas es difícil .

Me ha costado algunos errores reales mejorarlo. Usted comienza a confiar mucho más en su tracto intestinal después de las primeras veces que no confía en él y lo lamenta.

Siento un gran respeto por las preguntas de la pantalla del teléfono de Steve Yegge y he usado esto como la base para entrevistar a personas con cierto éxito.
También creo que fui mejor entrevistando a personas después de leer Guía de Joel para la entrevista de guerrilla (ahora en la versión 3.0, eso es Delante de la versión para la web y todo, solo tiene que ser bueno).

También hay otras 57 preguntas (a fecha 20/11/2008) en Software Stackexchange etiquetado con entrevista y algunos de ellos se ven muy relevantes, así que échales un vistazo.

Algunas ideas:

• Haga varias preguntas abiertas desde varios ángulos diferentes:

  • Revisa algunos códigos. ¿Qué se identifica? Errores técnicos, inconsistencias de estilo, comentarios, algoritmos, mantenibilidad, etc ...
  • Escriba un código. Busque el proceso, la prueba de viñetas, la legibilidad, etc.
  • Cree un diseño de alto nivel para un sistema pequeño. Busque la comprensión del problema, el enfoque, las comunicaciones, la integridad, el detalle.
  • Describa el proceso de desarrollo de software. Busque el diseño, la colaboración, la revisión, las pruebas, los buenos / malos hábitos y la experiencia en general.

• Elige algo, cualquier cosa, el candidato dice saber bien. Haga una pregunta simple y luego, basándose en la respuesta, haga otra, ligeramente más detallada, y continúe "cavando" hasta que llegue al límite del conocimiento del candidato. Esto te da una idea de:

  • Honestidad: ¿sabe él o ella tanto como afirma?
  • Profundidad del conocimiento: ¿qué tan bien aprende las cosas?
  • Comunicación: ¿qué tan bien te explica algo que no te es familiar? ¿Es lógico el proceso de pensamiento?
  • Reacción a situaciones estresantes: ¿qué tan difícil trabaja para responder? ¿Lo finge? ¿Es inevitable o difícil el inevitable "no sé"?

• Pregunte cómo el candidato manejó diversas situaciones en trabajos anteriores: trabajo en equipo, proyectos vencidos, depuración, etc . ¿Las respuestas son positivas o negativas? ¿Apasionado? ¿Inteligente? ¿Arrogante?

Encuentro que los mejores candidatos son entusiastas, experimentados, seguros pero educados, y lo más importante, presente . Necesitas saber que hay alguien dentro. :-)

Para reconocer a un buen programador, tienes que ser un buen programador. Eso significa que debe saber muy bien la programación para ver todo lo que se dice y se hace en la entrevista, y debe saber qué preguntas hacer.

En la entrevista, he visto que a los candidatos se les da una respuesta incorrecta, pero su explicación ha demostrado que conocían el tema (y, por lo tanto, podrían obtener fácilmente la respuesta correcta al buscar en la red). Para ver eso, tienes que saber muy bien el tema sobre el que estás preguntando.

Otra cosa es evitar preguntas sobre detalles que podrían ser fácilmente buscadas en Google. Esa pregunta solo muestra qué tan bueno es el candidato para recordar cosas, no si él o ella realmente tiene el conocimiento y la comprensión que está buscando.

Mi recomendación es obtener ayuda de alguien que conozca mucho sobre programación y tenga buenas habilidades con las personas para ayudar con las entrevistas.

Edit: También escribí un comentario sobre entrevistas aquí .

Recuerda que la capacidad de programación no lo es todo. Podría tener al mejor programador del mundo trabajando para usted, pero si odian trabajar con otras personas, no lo encontrarán muy útil.

La personalidad de los programadores debería estar más arriba en la lista de lo que la mayoría de los empleadores parecen clasificar. En mi lugar de trabajo actual, son muy cuidadosos al contratar al tipo de persona correcto.

Las personas generalmente pueden aprender a ser mejores programadores, las personas generalmente no pueden aprender a ser mejores seres humanos.

Hazles código. Dé un problema que pueda resolverse en 4 o 5 horas aproximadamente e inspeccione el código para verificar la documentación, el estilo de codificación, cómo planeó la solución antes de comenzar a codificar, etc. No es necesario que resuelva el problema. Y como mencionó Jon Skeet, hágales hablar sobre la programación, su idioma de elección y cosas por el estilo. Puedes reconocer la pasión en un buen programador. Pregunte cuántos sitios relacionados con la programación siguen, como stackoverflow. Los blogs que siguen als pueden ser un buen indicador.

Me gusta la respuesta de la pasión. Creo que tienes que ser apasionado por lo que trabajas para ser realmente bueno en eso.

Un buen programador en el lado además del trabajo (de vez en cuando al menos). Le gusta resolver problemas de programación. Y cuando él / ella no puede encontrar un programa que resuelva una necesidad particular en casa, normalmente intentará resolverlo él mismo.

Pero hay varios tipos de programadores.

• Tienes los que aman documentar. Personalmente odio documentando Pero documentar lo que se hace puede ser importante.
• Tienes los "hackers". Los que están muy dispuestos a resolver un rompecabezas complejo en el que si lo buscan en Google, probablemente no encontrarían una solución. Pueden resolver "cualquier" problema siempre que tengan las herramientas que necesitan.
• Tienes personas que se educan para ser programadores solo porque el mercado fue bueno para ser contratado para la programación. Esas suelen ser mediocres porque carecen de pasión.
• Tienes a aquellos que son excelentes para comunicarse y "pueden resolver cualquier cosa", pero una vez que obtienen el trabajo, se quedan con los demás para obtener ayuda para el problema que están resolviendo.

Si puedes encontrar al "pirata informático" que también documenta muy bien y tiene excelentes habilidades de comunicación, creo que has alcanzado el bote acumulado.

Ah, y una última cosa. Probablemente no quieras un programador que tenga ambiciones de líder, ya que solo usará la programación para iniciar. Eso significa que perderá ese recurso tarde o temprano.

Una pregunta que haría cuando contratara a un programador sería: "¿Por qué te educaste como programador?". Eso sería un regalo muerto si vacilan allí.

Esa es mi opinión.

Un amigo mío está trabajando en una compañía en la que tiene un paso adicional en el proceso de contratación: después de la selección inicial y la entrevista, el solicitante debe "probar el trabajo" durante unos días. Me dijo que a pesar de que un candidato tenía todas las habilidades y talentos necesarios, no lo contrataron porque no era una buena persona para trabajar con él.

Es muy difícil reconocer a un programador basado solo en una entrevista de trabajo.

Algunas cosas que deciden que alguien es un buen programador son:

• capaz de trabajar en equipo
• escribe un buen código que sea comprensible y principal
• es capaz de aprender acerca de las nuevas tecnologías

Entonces, tienes algunos pequeños consejos que puedes encontrar en una entrevista:

• ¿Sabe el candidato un lenguaje de programación / tecnología o sabe múltiples? Si sabe diferentes idiomas, parece ser capaz de aprender cosas nuevas y posiblemente conozca las desventajas de su tecnología / idioma preferido actual. Por lo tanto, solicite conocimientos además de la tecnología que utiliza en su empresa.
• Pregunte por proyectos en los que ya haya trabajado, especialmente proyectos de hobby y código abierto. Los proyectos de pasatiempos te muestran que le gusta la programación y lo hace incluso en su tiempo libre (y así mejora sus habilidades). En un proyecto de código abierto puede buscar el código que ha escrito. Si el proyecto involucra a más de una persona, puede obtener pistas sobre sus habilidades de equipo. En un proyecto de SO, puede buscar los archivos de la lista de correo para saber más.

Podrías realizar alguna prueba en la entrevista.

Pero muchas veces también hay un problema con el entorno de trabajo en sí. Seguramente este podría no ser el caso en su organización, pero es bastante común en el campo de la industria del software que la deuda tecnológica sea demasiado grande. Entonces, cuando contrata a nuevas personas, no ayuda mucho si son buenas o no, debido a la deuda. Maximizar la legibilidad y la comprensión del código de su programa ayuda a los recién llegados a trabajar.

También muchas personas son tales que pueden cooperar, pero a veces no hay forma de cooperar. Por ejemplo, si todas las personas son desarrolladores, se supone que deben hacer su trabajo. Bueno, lo hacen. ¿Pero tienes un arquitecto que dirige el proyecto de desarrollo y mantiene reuniones y demás? Los desarrolladores normales pueden sentir que no tienen el mandato necesario para comenzar las reuniones y pueden pensar que interrumpir a otros de vez en cuando no es la forma.

La comunicación entre sí no debe ser el objetivo final. Cuanta menos comunicación se necesite, mejor, pero solo si es menos posible. Menos se hace posible si tienes un arquitecto. La cantidad total de comunicación puede mantenerse en un buen nivel, pero obtiene más resultados por la misma cantidad de comunicación.

Primero empiezo con las cosas habituales de la entrevista, considero muy importante ver si la persona que está frente a mí vale algo y determinar sus habilidades y conocimientos.

Después de eso, uso un par de técnicas en el campo de Java, como discutir algunos principios, principalmente tomados de Effective Java.

En esta etapa, cuando creo que puedo tener un buen programador frente a mí, le doy un código para que lo revise. Lo que quiero ver es que puede señalar las partes peligrosas del código, dar algunos consejos sobre mejoras, encontrar dificultades en el rendimiento y múltiples subprocesos Y que puede distinguir entre comentarios importantes y "comentarios de gusto". Todo esto me ayuda a encontrar un empleado más competente.

pero al final siempre recuerdo que contratar es un tipo de juego ... muy difícil de anticipar ...

Sé que esto no responde a lo que está preguntando, pero lo recomiendo, si las leyes lo permiten, siempre contrate de manera temporal al principio (dos semanas o un mes, según el trabajo). Si la persona vale su sal, no objetará, además es una salvaguarda para ambos (puede dejarlo ir y es posible que no le guste el trabajo y se vaya).