Cómo seleccionar eficazmente a programadores excelentes durante las entrevistas

Primera parte: Probar la autenticidad de un currículum

Una vez estaba entrevistando a un candidato con un colega. Después de la entrevista, sentí que el candidato estaba bien, pero no sobresaliente. Pero mi colega parecía insatisfecho. "Mintió. Dijo que conocía la tecnología XXX, pero es obvio que nunca ha utilizado esta tecnología. No podemos querer a este tipo de persona en absoluto. Aunque esta tecnología XXX no es muy importante para nuestra empresa", porque se difundió. "Este pánico", continuó mi colega, "no creeré nada de lo que escriba en su currículum". Los solicitantes deben presentarse de manera muy positiva en sus currículums. Sin embargo, esta representación positiva debe tener un límite determinado. Más allá de este límite, la expresión será incorrecta. En el ejemplo anterior, no pensé que fuera tan grave como mis colegas porque asumí de antemano que cualquier cosa en el currículum era falsa a menos que se demostrara lo contrario. Si el currículum dice "Bueno en la tecnología XXX", entonces creo que es posible que el solicitante solo conozca el nombre de la tecnología XXX. Si el currículum dice: "Trabajé en un equipo que desarrollaba un sistema de negociación de acciones de subprocesos múltiples", entonces asumiría que el candidato simplemente eligió un color de fondo para el sistema. Mis requisitos nunca son estrictos, a menos que conozca a un tipo con diez años de experiencia laboral que ya no escribe código. Si alguien dice que desarrolló una herramienta de formato de texto para el software OpenOffice o que tiene un doctorado en filosofía, es fácil hacer suposiciones sobre sus habilidades. No se supone nada y todo debe ser probado.

Para cada descripción relevante en el currículum, primero evaluaré la situación real del solicitante. Luego, lo confirmé a través de la siguiente conversación.

Desarrollé un sistema operativo en tiempo real como proyecto de práctica.

¿Qué tamaño tiene el equipo en el que trabajas? Oh, entonces, ¿de qué parte eres realmente responsable? ¡Genial! Describe una tarea de alta prioridad a una tarea de baja prioridad. ¿Cuándo se envía un mensaje?

Hemos desarrollado de forma completamente independiente un conjunto de protocolos de transmisión de audio para sistemas de seguridad inalámbricos.

¿Cuántas personas hay en tu equipo? Solo tú. Oh, ¿cómo se prueba? ¿Por qué no usas RTP?

Corregir errores para el motor XXX.

Describe un error particularmente desafiante que encontraste y cómo lo solucionaste.

Parte 2: Descubrir la experiencia práctica

Tener más experiencia es un buen indicador de ser una buena persona. Los desarrolladores experimentados maduran cometiendo errores. Saben cuándo y cuándo no utilizar patrones de diseño. Tienen un sexto sentido sobre qué partes de los requisitos deben modificarse y cuáles deben permanecer iguales. Saben cuándo ser perezosos y cuándo pensativos. Es la experiencia real la que hace que la brecha entre los buenos desarrolladores y los mediocres sea tan amplia que no se pueda salvar.

No todas las experiencias son equivalentes. Es muy posible que alguien pueda adquirir habilidades sólidas a través de años de trabajo, escribiendo o reescribiendo innumerables cantidades de código en muchas tareas y cometiendo muchos errores. En otro caso, una persona sólo modificará una línea de código en un proyecto durante diez años sin aprender nada nuevo.

Descubriendo el tiempo oculto

Muchos grandes programadores comenzaron a programar en su segundo año de universidad. Cuando terminan la escuela, ya tienen varios años de experiencia laboral. Además, hay algunos programadores increíbles que comenzaron a aprender el arte de la programación cuando eran muy jóvenes. También conozco a varias personas que escribieron algunos programas modestos cuando eran adolescentes o antes. No puede encontrar esta información en su currículum, debe sacarla a relucir durante la entrevista.

¿Cómo llegaste al desarrollo de software?

¿Cuál fue el primer lenguaje de programación que aprendiste?

Densidad de experiencia

p >

Muchos programadores increíbles simplemente codifican durante sus horas de trabajo. Eso es excelente, el equilibrio entre el trabajo y la vida personal, y no hay ninguna razón por la que no debas contratar a alguien así. Sin embargo, realizar algunos proyectos de programación personal fuera del trabajo y la escuela es un buen indicador de un buen talento. Los candidatos con experiencia en programación amateur obviamente tienen más experiencia y se adaptan mejor a la empresa.

¿No tienes un proyecto personal? Aquí tienes algunos otros indicadores que pueden funcionar en este sentido:

Trabajar en equipos o grupos muy pequeños.

He participado en muchos proyectos diversos.

Tener una comprensión detallada de todos los niveles abstractos de un gran proyecto.

Servir como desarrollador principal en un equipo de proyecto.

Parte 3: Experiencia de verificación

Una vez que tenga una idea básica del verdadero nivel de experiencia del candidato, puede comenzar a verificar su importante experiencia práctica en programación. Definitivamente unos minutos no son suficientes para una prueba real, pero eso es todo. Podemos comprender la profundidad y amplitud del dominio de este conocimiento por parte de los candidatos haciendo preguntas sobre diversas áreas del desarrollo de la programación. Por supuesto, su percepción del nivel de habilidad de un candidato estará sesgada por su propio nivel de experiencia. Es imposible hacer juicios correctos sobre las respuestas en un área con la que no estás familiarizado. Por eso normalmente tenemos varios entrevistadores al mismo tiempo.

Los diferentes puestos de trabajo tendrán diferentes temas de entrevista. Sin embargo, las siguientes áreas son comunes:

Estructuras de datos y algoritmos

Multiproceso

Operaciones de bytes

Asignación de memoria

Objetos, herencia, patrones de diseño

Recursión

Conocimientos de ensamblaje y principios de operación del programa

Hay uno en cada campo que elijo. Seleccionado cuidadosamente. preguntas básicas ("¿Qué es una señal?"). Las preguntas son muy básicas y pueden responderse siempre que el candidato haya realizado algún trabajo en este campo. Cada área tiene una serie de otras cuestiones más profundas. Las respuestas de los candidatos a estas preguntas pueden demostrar si son profesionales. Por ejemplo, si le pregunta a un desarrollador experimentado de software integrado cómo convertir 0×4c a binario y escribe 4×16+12, esto no es del todo correcto.

Problemas de codificación

Después de completar los pasos anteriores, generalmente puedo determinar si el candidato puede aprobar la prueba. Si aún hay dificultades, los problemas de codificación se solucionarán. último obstáculo. Esto es muy importante y no puede pasarse por alto ni siquiera en una entrevista telefónica. Para ser eficaz, debe pensar y planificar las preguntas de codificación que hará antes de la entrevista. Si hace la pregunta equivocada, la respuesta no tendrá sentido.

En primer lugar, la selección de preguntas debe basarse en la experiencia laboral del candidato. Si piensas en un avión 3D y quieres centrar todas tus preguntas en torno a él, habrá preguntas maravillosas. Pero ahórrese la molestia y simplemente hable con sus colegas durante el almuerzo. Si el trabajo para el que está contratando no tiene nada que ver con gráficos 3D, entonces el candidato definitivamente será excluido injustamente.

El problema debe expresarse con precisión. "Escribir una función que mueva una pila de cartas" es una afirmación muy vaga. Dé un título funcional para evitar malentendidos, que suelen ocurrir. Si no tiene cuidado, el entrevistador puede responder una pregunta que sea más difícil o más fácil que la que usted hizo. Si es una pregunta más difícil, está bien, a menos que lo aturda. De poco sirve responder a preguntas más sencillas. Para evitar perder mucho tiempo, pídales su esquema de respuestas unos minutos después de que respondan la pregunta para ver si su comprensión va en la dirección correcta.