synthroid taking instructions

Inicio > Gestión TI > Encontrar desarrolladores impresionantes en las entrevistas de programación

Encontrar desarrolladores impresionantes en las entrevistas de programación

Domingo, 27 de Noviembre de 2016 Dejar un comentario Ir a comentarios

En una entrevista de trabajo, una vez pedí a un muy experimentado desarrollador de software incorporado escribir un programa que invierte una cadena y lo imprime en pantalla. El luchó con esta tarea básica. Este hombre era impresionante. Dale un cubo de piezas de repuesto, y él podría construir un robot y programarlo para navegar alrededor de la habitación. Había trabajado en los satélites que ahora se encuentran en órbita. Pudo haber codificado círculos a mí alrededor. Pero la única cosa que él nunca tuvo necesidad de hacer era: mostrar algo en la pantalla.


Algunas personas tienen una habilidad especial para hacer las preguntas adecuadas para detectar a los desarrolladores impresionantes en una entrevista de trabajo. Otros entrevistadores temen, llegar con el rabo entre las piernas, pregunta unas cuantas preguntas a través de Internet y va junto con el grupo de decisión. Pero entrevistar es una habilidad esencial para la mayoría de los desarrolladores. Una mala contratación tiene terribles consecuencias a largo plazo, porque eventualmente un sub-empleado puede traer a otros en la organización. Por otra parte, excluir injustamente a un candidato impresionante también duele.

Una entrevista de programación incluye al menos tres partes. En la parte I, se prueban las hipótesis que tenemos después de leer el curriculum vitae. En la parte II, tener una idea de la cantidad  verdadera de experiencia que el candidato tiene. Finalmente, se prueba esta experiencia con unos pocos controles sobre el terreno y una pregunta de programación.

Parte I: Pruebas de hipótesis a partir del curriculum vitae

Una vez entreviste un candidato junto con un compañero de trabajo. Cuando habiamos terminado, pensé que el candidato lo había hecho bien, pero no brillantemente. Mi compañero de trabajo, por el contrario, parecía enojado. “Mintió acerca de la tecnología X. Obviamente él no ha trabajado en eso. Definitivamente no a plazos.” Tecnología X ni siquiera era importante para nosotros. “Si mintió acerca de eso”, mi compañero de trabajo se fue por el, “Yo no confío nada en el currículum”.

Los candidatos deberán utilizar el curriculum vitae para presentarse a sí mismos en una luz positiva (Ver el curriculum completamente honesto). Sin embargo, hay una línea en que esta imagen positiva se convierte en falsedad. En el ejemplo anterior, no me preocupa tanto como a mi colega, porque yo ya asumi que todo lo que esta en el curriculum vitae es falso hasta que se demuestre lo contrario. Si el curriculum vitae, dice, “experto en la tecnología X”, entonces voy a asumir que el candidato sólo conoce el nombre de la tecnología de X. Si el curriculum vitae dice: “Trabajó en un grupo que desarrollo una plataforma multihilo para el comercio de acciones”, entonces yo asumiré que el candidato sólo eligió los colores para el fondo. Yo solía ser menos estricto hasta que conocí al hombre con 10 años de experiencia que no podría escribir código. Si alguien dice que escribió el formateador de texto de OpenOffice, o tiene un doctorado, es fácil hacer conjeturas acerca de sus habilidades. No Supongo nada. Todo debe ser probado.

Para cada artículo correspondiente en el curriculum vitae, en primer lugar trato de tener una idea de lo que el candidato realizo realmente. Entonces, yo hago que él o ella lo pruebe hablando de ello.

  • Desarrollo un sistema operativo de tiempo real como un trabajo de curso.
    ¿Qué tan grande fue el grupo que trabajo? ¿Un grupo de 15? Oh, bien entonces, ¿En qué parte específica has trabajado? ¿La cola de mensajes? Grandioso! ¿Puedes describir lo que sucede cuando una tarea de máxima prioridad envía un mensaje a una tarea de baja prioridad?
  • Desarrollo desde cero un protocolo de transferencia de audio para sistemas de seguridad inalámbrica.
    ¿Qué tan grande fue tu equipo? ¿Sólo tú? Guauu, ¿cómo probarlo? ¿Por qué no usaste RTP?
  • Corregio errores del XYZEngine.
    ¿Puedes describir un error que hayas encontrado todo un reto, y cómo solucionarlo?

Parte II: Encontrar la experiencia verdadera

Tener más experiencia es una buena indicación de impresionante. Desarrolladores experimentados han cometido errores. Ellos saben cuando, y cuando no aplicar patrones de diseño. Tienen un sexto sentido acerca de que parte de los requisitos probablemente van a cambiar, y qué parte probablemente seguirán siendo lo mismo. Ellos saben cuándo van a ser perezosos y cuándo ser pedantes. Es cierto que la experiencia hace la diferencia amplia entre los programadores mediocres e impresionantes.


(Impresionante no es proporcional a Experiencia)

Pero no toda experiencia es la misma. Ciertamente es posible que una persona adquiera conocimientos sólidos en un par de años, simplemente por trabajar en un montón de cosas diferentes, escribiendo y reescribiendo un sin número de líneas de código, y cometiendo muchos errores. Por otro lado, también es posible que alguien pase una década escribiendo una línea de cambios a un solo proyecto, sin aprender nada nuevo.


(Experiencia es igual tiempo por densidad)

Encontrar el tiempo escondido

Hay un montón de grandes desarrolladores que comenzaron a programar cuando estaban en su segundo año de universidad. En el momento en que salieron de las aulas, ellos tenían algunos años de experiencia. Por otro lado, algunos desarrolladores impresionantes comenzaron a aprender su arte a una temprana edad. Conozco varias personas que escribieron algunos programas que no son triviales en la adolescencia o antes. Esta información no se encuentra en ninguna parte de su hoja de vida, y debe ser convencido durante una entrevista.

  • ¿Por qué te metiste en el ámbito del desarrollo de software?
  • ¿Cuál es el primer lenguaje de programación que usted nunca aprendería?

La densidad de la experiencia

Muchos programadores impresionante hacen toda su programación en el trabajo. Éstos son grandiosos, buenos, personal que definitivamente deberías contratar. Sin embargo, hacer proyectos de programación personales fuera del trabajo o de clase es un indicador bastante bueno de impresionante. Un candidato con tiempo de programación personal, simplemente tiene más tiempo de vuelo bajo su cinturón, y será mejor para él. ¿No hay proyectos personales? Estos otros indicadores también van a contar para algunos puntos:

  • Trabajo en pequeños equipos o grupos.
  • Trabajo sobre una amplia variedad de proyectos
  • Conocimiento detallado de varias capas de abstracción en un gran proyecto
  • Ser el principal contribuidor de un proyecto en grupo

Parte III: Verificación de la experiencia

Después de pulsear el verdadero nivel de experiencia del candidato, es importante verificar la experiencia probada de sus habilidades de programación. A los pocos minutos de tiempo es totalmente insuficiente para una prueba de verdad, pero eso es todo lo que está disponible. Podemos tener una idea de la amplitud y profundidad de los conocimientos del candidato con preguntas acerca de las diferentes áreas de desarrollo de software. Por supuesto, su percepción de las habilidades del candidato se hará con preferencia en tus propias experiencias. No se puede juzgar la exactitud de las respuestas en temas que no te son familiares. Es por eso que hay varios entrevistadores.

Los temas específicos dependen de los requisitos del trabajo. Sin embargo, algunas áreas de ejemplo son:

  • estructuras de datos y algoritmos
  • multithreading
  • manipulación de bits
  • Asignación de memoria
  • objetos y la herencia, patrones de diseño
  • recursividad
  • compilación y cómo ejecutar los programas de computadoras

Cada área que elijo tiene una selección de preguntas básicas (“¿Qué es un semáforo?”). Estas son tan básicas que si el candidato no ha hecho ningún trabajo en el área, él o ella no sería capaz de responder. Cada área también tiene algunas preguntas de seguimiento más detalladas. La forma en que un candidato responde puede probar o refutar ser impresionante. Por ejemplo algo está mal si pides a un programador experimentado de integrados, convertir 0x4c a binario, y comienza anotando 4 x 16 + 12.

La pregunta de programación

Por lo general, después de todo lo anterior, tengo una muy buena idea si el candidato va a pasar o no, pero la cuestión de programación elimina toda duda. Es tan importante, que incluso entrevistas telefónicas no sean exentas. Para ser útil, una pregunta de programación requiere un análisis cuidadoso y la planificación antes de la entrevista. Preguntado por el camino equivocado, la respuesta será inútil.

En primer lugar, hay que elegir una pregunta sobre la base de lo que el candidato ha tenido experiencia. Puedes tener un problema inteligente que se hace más fácil si se piensa en convertir las intersecciones de los planos en 3D. Guárdalo para la hora del almuerzo con tus colegas. Si el trabajo no es de gráficos en 3D, los candidatos serían injustamente excluidos.

La pregunta debe ser formulada en forma precisa. “Escribir una función para barajar un mazo de cartas” es lamentablemente ambigua. Proporcionar el encabezado de la función y evitar malentendidos, que son muy comunes. Si no eres cuidadoso, el candidato contestará a un problema más difícil o más fácil que el que preguntó. La mas difícil es bueno, a menos que cause que él o ella se congelen. Lo más fácil no ofrece ninguna información. Para evitar una gran pérdida de tiempo, pide un resumen verbal de la solución después de unos minutos, para comprobar si el candidato está en el buen camino.

La influencia del orden de las preguntas

El orden en que se haga preguntas pueden influir profundamente en los procesos de pensamiento del candidato. Por ejemplo, yo solía hacer preguntas acerca de las tablas hash cuando pensaba que el candidato sabía acerca de ellos. Más tarde, en la entrevista, me gustaba hacer una pregunta de programación que no tenía nada que ver con las tablas hash. Los candidatos siempre se decidirán a usar una tabla hash en su aplicación, con las claves enteros únicos, consecutivos a partir de 0. Si yo evitaba hablar acerca de las tablas hash, los candidatos en su lugar optarían por utilizar una matriz.

Los candidatos también están fuertemente influidos por ti en la elección del lenguaje. Por ejemplo, si tu dices que el trabajo consiste principalmente en Java, cada candidato juraría que, caramba, Java es el mejor lenguaje y favorito para trabajar. Él decide usarlo para todas las preguntas de programación, al darse cuenta demasiado tarde de que él no puede recordar cómo declarar variables en el lenguaje que es el “mejor” de todos.

Evitar el sesgo de idioma

Es terriblemente fácil estar sesgado hacia un lenguaje de programación específico que se utiliza en tu empresa. Al fijarse en una herramienta en particular, te deshaceras de un montón de desarrolladores impresionantes. No trates de determinar si el candidato es impresionante en la programación en C o Java o lo que sea. En su lugar, debe tratar de averiguar si el candidato es impresionante en la programación del idioma que él o ella sabe mejor.

Yendo más lejos

Las directrices no se ocupan de todo. Se centran en la experiencia, y que podrían perderse los desarrolladores impresionantes que tienen poca experiencia, pero mucha de la capacidad innata. En particular, los entrevistadores lo desean, poner a prueba la capacidad de resolución de problemas utilizando los rompecabezas que no requieren ningún tipo de codificación.

La técnica de entrevista que he descrito aquí se basa en probar una hipótesis, probabilidad, y el instinto visceral. La hipótesis es que el candidato es un desarrollador impresionante. ¿Qué características lo hacen un desarrollador impresionante? No se pueden medir directamente las características, por lo que tiene que pedir en su lugar: ¿Cuál es la probabilidad de que el candidato tiene esas características, dado que él o ella puede responder a una pregunta en particular rápidamente? No es posible evaluar a un candidato en una entrevista con el 100% de éxito, pero al hacer preguntas reflexivas, puede acercarse.

Comparte y diviertete:
  • Print
  • Digg
  • StumbleUpon
  • del.icio.us
  • Facebook
  • Yahoo! Buzz
  • Twitter
  • Google Bookmarks
  • BarraPunto
  • Bitacoras.com
  • BlinkList
  • Blogosphere
  • Live
  • Meneame
  • MSN Reporter
  • MySpace
  • RSS
  • Suggest to Techmeme via Twitter
  • Technorati
  • LinkedIn
  • email
  • FriendFeed
  • PDF
  • Reddit
  • Wikio IT
  • Add to favorites
  • blogmarks
  • Mario R.P.

    Estoy de acuerdo con nicolas, es un post de gran utilidad y perfectamente entendible. Si bien algo escaso en cuanto a algoritmos de busqueda a modo de ejemplo, aunque las referencias son ya de lo más acertadas. Es obvio que cada prueba se realizará en base a los conocimientos del candidato, por lo que una interpretacion en pseudo-lenguaje es más que acertada si no se especifica la naturaleza del lenguaje a utilizar. Saludos y gracias.

  • nicolas cetinich

    no estoy de acuerdo con los demás todo se entendió bien, soy desarrollado y estaba interesado justamente en ver que buscan en mi cuando voy a una entrevista, gracias por el aporte.

  • Anonimo

    Estoy con Dfpalomar, no he entendido del todo gran parte del artículo. Espero que en las entrevistas te expreses mejor, mas que nada por el bien del entrevistado y de la empresa en la que supongo trabajas.

  • Dfpalomar

    Por momentos resulta complicado entenderte, deberias hacer algo por mejorar tu capacidad de redaccion.

  • Dfpalomar

    Por momentos resulta complicado entenderte, deberias hacer algo por mejorar tu capacidad de redaccion.

  • Pingback: Bitacoras.com()

Top Footer