[su_wiloke_sc_company_website]Un colega del trabajo me alertó de un artículo muy interesante de Jeff Atwood (el de Stackoverflow) que hablaba sobre pistas a la hora de contratar un programador. Me he tomado la libertad de traducirlo libremente y añadir comentarios de mis propias experiencias. Por cierto, aprovecho para anunciar una página donde publico ofertas de empleo de IT: http://empleo.uptimiza.com.
Como en otros gremios, no hay un truco para contratar a un programador. Yo mismo he hecho cientos de entrevistas en los últimos 10 años, y he formado parte de procesos muy interesantes para empresas como Google (llegué a la 5ª entrevista), o Amazon (llegué al final, pero no me convencía el salario/lugar). Aquí van algunas pistas:
Puede parecer estúpido, pero nada más lejos de la realidad. Muchos programadores directamente no saben programar. Lo ideal es quedar por Skype a tener un primera charla distendida e informal, y explicar que la primera prueba es realizar un test online en ese momento. Es mejor no dilatar esto y quedar para más adelante, cuanto «más caliente» mejor. Es una prueba muy corta.
Existen muchísimos ejemplos de programación típicos de libro que pueden proponerse. «Torres de Hanoi», «Baraja de cartas», «Tres en raya» … Obviamente no hay que programar por completo la aplicación, sino ver cómo se desenvuelve la persona, cómo estructura el código, lo escribe, lo borra, lo reescribe, pone sus comentarios, etc …
Existen muchas herramientas online para poder ver colaborativamente a tiempo real la escritura de código. A mi me encanta www.stypi.com, no hace falta darte de alta y es fácil y rápida de usar. En apenas 5/10 minutos, te das cuenta si la persona se desenvuelve en el mundo de la programación y tiene mente de programador, y te sirve como primera criba.
2. Pedir un portfolio
Hoy en día existen cientos de servicios web que la gente usa para exponer su perfil de programador. Por ejemplo, participar activamente en StackOverflow, o en repositorios de código abierto en GitHub, o incluso tener un blog / twitter / facebook orientado a tu perfil de programador, da muchas pistas de cómo eres, cuánto te gusta lo que haces, y cómo interactúas como programador con Internet.
Por otra parte, haber participado en proyectos ya realizados da la posibilidad de preguntar al candidato, una vez vista la web que supuestamente ha hecho (porque hay muchas personas que por haber programador un par de líneas, se cree que ha hecho el proyecto entero), cómo ha hecho cierto módulo o parte de la web, y que te la explique, cómo la resolvió, qué problemas tuvo, etc.
3. Busca en tu comunidad
Por más que haya Infojobs, Elance, o Monster, no hay mejor sitio para buscar alguien que tu propia comunidad. Si formas parte de una empresa o proyecto en el que existe un foro o comunidad activa que participa mejorando el producto, o reportando problemas, no hay duda que son los mejores candidatos a tener en cuenta.
Además de que ya están involucrados en el proyecto o comunidad, si están participando de manera altruista, qué mejor manera de motivarlos ofreciéndoles trabajar directamente en el proyecto de manera remunerada.
Este encaje cultural te soluciona muchas preguntas sobre el candidato en lo que se refiere a dedicación, motivación y entusiasmo, que son valores tan importantes (o más) que los propios conocimientos técnicos.
Una llamada de teléfono (o Skype para ser más modernos y baratos si gustas) no es para hablar (para eso está la entrevista física), sino para hacer un chequeo del candidato a nivel técnico. Se le dice que coja papel y boli y se realizan preguntas típicas de exámen universitario básicas. Si quieres más detalles puedes leer este artículo, pero básicamente se podría hacer:
- Una prueba de código al vuelo, como por ejemplo «encuentra el valor intero más grande en un array de enteros»
- Algo de diseño básico, como «diseñar una representación al modelo HTML»
- Expresiones regulares, como «buscar en un listado de ficheros de un directorio cadenas que contengan números de teléfono con un formato específico»
- Estructuras de datos, como «¿por qué es mejor usar un hashtable que un array?»
- Temás de bits and bytes, con alguna pregunta tan friki como «¿Por qué los programadores piensan que el 31 de octubre (31 OCT) y el 25 de diciembre (25 DEC) son el mismo día?»
De esto, sufrí mucho personalmente, en las entrevistas de Amazon. No buscan que soluciones al momento la pregunta o el enigma, no importa que llegues a la solución en 10 segundos o en 1 minuto. Lo que más importa es cómo razonas, cómo piensas, cómo te enfrentas al problema. Lo más importante de todo es hablar todo lo que piensas: «pues tengo este problema, pero lo solucionaría así …»
5. Dales un proyecto
Los candidatos que llegan a este punto saben programar, tienen un portfolio interesante, encajan culturalmente en el proyecto y han pasado la entrevista telefónica con creces. ¿Ahora sería turno de la entrevista física? Todavía no. Quedar físicamente es mucha inversión de tiempo (imagínate que son 100 personas las que entrevistas … necesitarías 2 meses de plena dedicación).
Ahora se tienen que enfrentar a un problema real. No a un típico problema informático, sino algo real. Un problema que tengas en tu actual empresa/proyecto, algo que darías a otro empleado ese mismo día si no estuvieran envueltos en el «lío diario».
Obviamente no estamos insinuando que trabajen gratis para ti (aunque algunos ministros lo insinúen), debería de consensuarse una retribución por ello. Selecciona un pequeño proyecto que, idealmente, se puede hacer en unos pocos días, tal vez a lo sumo una semana. Debe ser algo modular, fácil de entender (sin tener que explicar detalles del proyecto) y fácil de implementar una vez recibidos los resultados (si son de calidad suficiente, claro). El candidato puede ir a la oficina, o puede trabajar de forma remota.
Si el subproyecto triunfa, ya casi tienes el candidato contratado. No he visto todavía un caso, en el que tras superar esta prueba y contratarlo, la persona no funcione en la empresa. Es importante saber bien el proyecto que se le da, lo modular que es (para entenderlo e implementarlo), y estar seguro de que ha pasado los 4 puntos anteriores, ya que este punto del proceso tiene un coste, aunque probablemente será más económico que no hacerlo y pagar las consecuencias más tarde.
Este punto no es muy común en España por nuestra forma de trabajar, pero cuando vivía/trabajaba en Estados Unidos, era bastante normal y se solía hacer físicamente en la empresa, como si estuvieras 1 o 2 días «de prácticas» (pero remunerado) delante de un ordenador ayudándoles con un módulo del proyecto. Como digo, nuestra cultura de trabajo es bastante diferente y no suele haber tanta pre-dedicación o entusiasmo a un proyecto. Un poco de crisis, un poco de desconfianza … y un poco de «españolismo», pero eso es tema para otro post.
6. Queda con él
Es un punto inevitable. Por muy técnicos que seamos, somos antes personas, y hay que conocerse y conseguir ese feeling que te asegura que es la persona correcta. Para llegar a este paso, tienes que estar 95% seguro de que contratarías a esa persona antes ni siquiera de conocerla físicamente (con las pruebas anteriores).
Existen muchas formas de hacer entrevistas: las hay de «preguntas raras», las de «a ver si te pillo», como las típicas aburridas y serias que casi más asustan que acercan. La entrevista debe ser relajada, informal, incluso con ciertos toques de humor, cercana, humana… No olvides que, si contratas a esa persona, vas a estar 8 horas (o más) junto a él cada día, y el resto del equipo también.
Lo primero es pedirle que se presente, que haga un «pitch» en el que hable de su experiencia, de cómo le gusta trabajar, de sus aspiraciones, … De esta forma puedes contestarte preguntas tan importantes como éstas:
- ¿Es una persona apasionada por lo que hace?
- ¿Se puede comunicar fácilmente con otros empleados?
- ¿Tiene experiencia y controla su área?
- ¿Encajará bien con el resto del equipo y el proyecto?
En cualquier caso, como dice Steve Yegge, cualquier programador debería saber cómo venderse a sí mismo, su código y su proyecto. Así que ¡deja que hable!
7. ¿Candidato perfecto?
Nada de lo que aquí se dice tiene garantía alguna. Somos personas, y como seres humanos, somos las máquinas más complejas que existen, imposibles de entender al 100% e imposibles de asegurar una continuidad laboral estable y óptima. Es importante tener en cuenta que pasamos muchas horas juntos en el trabajo, tiene que existir química en ambos lados.
En una empresa la relación trabajador – empresa es un quid pro quo, como un matrimonio. Debe existir la seguridad por parte de ambos de que la cosa puede funcionar, que va a ser divertido y rentable en todos los niveles (laboral, educativo – formativo, económico …)
He tenido mucha suerte en mi vida eligiendo a la gente con la que trabajo, y afortunadamente, puedo decir, que casi todos con los que he trabajado están mi lista de «querer volver a trabajar con ellos» (espero que ellos piensen lo mismo :) Es más, ya he tenido oportunidad de hacerlo con varias personas incluso 6 años después.
Y es que, al fin y al cabo, contratar a un programador para tu proyecto es, como en cualquier otro proceso de selección para formar equipos, crear una relación humana que proyecte el entusiasmo en un proyecto empresarial. Todo lo demás, es secundario … viene solo.
