Parafraseando un artículo que leí en TechCrunch…
Todos los que hemos dirigido un departamento de IT hemos vivido la misma pesadilla: Un nuevo programador se presenta a trabajar, y uno trata de ser amable, de darle la bienvenida y todo el apoyo para un excelente comienzo, pero al cabo de las horas y los días pareciera que le cuesta agarrar el ritmo, agarrar el paso; las preguntas que hace revelan una ignorancia básica; y su trabajo, cuando finalmente emerge, es tan poco elegante, tan poco eficiente y a veces tan enredado, que aunque funcione, es necesario que alguien más competente lo haga de nuevo. Entonces, le reclamas a quien le entrevistó, o a los del departamento de “Recursos Inhumanos”, si es que el parasitismo burocrático ya ha infestado la compañía, y te juran que ellos solo contratan a personas tipo “A1”, arriba del promedio, del exclusivo 1% de genios disponibles en el mercado.
Es un grave problema, especialmente ahora, cuando se está dando un nuevo “boom” en el área de ingeniería de software. Todo el mundo está desesperado por contratar programadores y analistas, pero no es fácil substituirlos. Un buen desarrollador puede ser 50 veces más productivo que uno mediocre, mientras que los realmente malos llegan a tener una productividad negativa. Contratar a uno de ellos es un terrible error para cualquier empresa; y para una que recién empieza (start up, como les dicen), puede tener una magnitud catastrófica que bien podría llevarla a la quiebra. Pero ¿Qué tanto ocurre?
Como muchas de las resacas que están afectando al área de ingeniería de software actualmente, lo anterior es culpa de Microsoft. Antes, cuando la empresa era el “imperio del mal” en donde todo el mundo secretamente quería trabajar, sus reclutadores eran famosos por sus preguntas complejas durante las entrevistas, tales como “por qué las tapas de las alcantarillas son redondas” o “escríbeme una búsqueda binaria.”
Todos querían ser como Microsoft, incluso Google, hasta que todo el mundo empezó a querer ser como Google (hasta hace muy poco); Fue así como ese tipo de entrevistas persistieron. Sin embargo, esa clase de preguntas en las entrevistas empiezan a considerarse inútiles desde el punto de vista de las métricas, además de que se está extendiendo una corriente de reclutadores que las consideran extremadamente ofensivas.
Un excelente avance al respecto es el hecho que Google ha empezado a admitir que su algoritmo de reclutamiento es bastante problemático. Lástima que no lo hayan arreglado aún. El problema fundamental es que las habilidades requeridas para salir airoso de una entrevista para un empleo en el área de software no son precisamente las necesarias para ser un exitoso desarrollador. Existe cierta correlación, sin embargo, pero es como si un equipo de futbol se concentrara en contratar jugadores que puedan correr muy rápido únicamente, para luego descubrir que en los partidos la velocidad no lo es todo.
En realidad la situación es mucho peor. Al menos algunos jugadores de futbol tienen que ser rápidos, pero con seguridad ningún ingeniero de software tendrá que escribir una “búsqueda binaria” después de que haya sido contratado. Es como si se escogiera a un contratista porque sabe forjar hierro usando carbón, martillo y fuego, cuando en realidad lo que necesitan saber es: a) Dónde está la ferretería más cercana y b) Qué hacer con el hierro una vez que lo hayan comprado.
El famoso ingeniero y escritor Joel Spolsky explicó muy correctamente en una ocasión que son dos cosas las que se buscan en un candidato para una posición de desarrollo de software: Primero que –obviamente- sea listo; luego, que termine las cosas. En ese sentido, lastimosamente, las universidades están llenas de listos, pero no de gente que terminé lo que ha empezado. Sin embargo, se debe establecer algo más: Que no sea completamente inepto. De verdad, es increíble la cantidad de personas incompetentes que se presentan a entrevistas técnicas. Por ello es que Google utiliza la rutina de la “búsqueda binaria” como un filtro inicial que el candidato debe pasar luego de sentarse a la mesa. Y no deben pasar más de cinco minutos antes de que empiece la verdadera entrevista.
Entonces, ¿En qué debe consistir una buena entrevista técnica? Pues, primero que nada, en no entrevistar a nadie que no tenga logros. Nunca. Diplomas, certificados, maestrías no son logros; el enfoque debe ser sobre la participación del candidato en proyectos que buscaron desarrollar aplicaciones, sistemas o incluso páginas web con usuarios reales detrás. No hay excusas para que un ingeniero de software no pueda decir “eso, lo hice yo”, máxime en un mundo en el que existe acceso gratis a Google Apps, Amazon Web Services y a publicar programas en algún mercado de aplicaciones Android.
El sistema antiguo de reclutamiento estaba basado en información limitada. Todo lo que se sabía del candidato estaba en su hoja de vida. Pero si se entrevista únicamente a personas con logros, entonces se tiene una base mucho más amplia con la cual trabajar. Hay que dejar de usar las preguntas complejas del filtro inicial para enfocarse en que el entrevistado muestre y explique lo que ha desarrollado a lo largo de su trayectoria, que hable sobre sus decisiones de diseño y que haría diferente con lo que saben ahora. Luego ponerle a implementar una funcionalidad mientras se le observa, para que uno pueda darse cuenta de primera mano cómo trabaja y como piensa mientras lo hace. Eso es lo que se necesita en una entrevista técnica, no medir si el individuo sabe utilizar un anticuado algoritmo o estructura de datos. El mundo, en realidad, ya ha cambiado.
