… lo que liquidó a la mayoría de los startups en el negocio e-business de los 90s fueron los malos programadores. Muchas de estas compañías se fundaron por gente de negocio pensando que la manera en que funciona un startup consistía en tener una idea ingeniosa y luego contratar a programadores para implementarla. En realidad esto es más difícil de lo que suena – de hecho, casi imposiblemente difícil – porque la gente de negocios no puede identificar a los buenos programadores. Ni siquiera tienen la oportunidad de encontrar a los mejores, porque ningún programador realmente bueno quiere implementar la visión de un hombre de negocios.

En la práctica lo que ocurre es que la gente de negocios selecciona a quienes creen que son buenos programadores (dice aquí en su currículum que es un Microsoft Certified Developer), pero no lo son. Entonces se quedan perplejos al darse cuenta que su nueva empresa avanza lenta y pesadamente como un bombardero de la Segunda Guerra Mundial mientras sus competidores rugen como aviones caza. Este tipo de startup está en la misma posición de una compañía grande, pero sin las mismas ventajas.

Así que, ¿cómo seleccionas buenos programadores si no eres un programador? No creo que exista una respuesta. Iba a decir que buscaras un buen programador para ayudarte a contratar a la gente. Pero si ni siquiera puedes reconocer a los buenos programadores, ¿cómo podrías hacer esto?

— Paul Graham. The 18 things that kill startups. Paulgraham.com. Oct 2006.

Desde hace tiempo hemos hecho nuestros pininos para tomar el control de una plataforma de software diseñada y construida en Estados Unidos. Sin embargo, un problema al que nos estamos enfrentando es la falta de personal para tomar por completo el know-how y hacer de esta plataforma algo nuestro. Puntualmente requiero de alguien dedicado de tiempo completo al sistema, pero los recursos con los que dispongo actualmente son personas enfocadas a otro tipo de proyectos, como integraciones con terceros, soporte de aplicaciones legadas o aplicaciones desktop. Por ello, desde hace rato llevo buscando un ingeniero de desarrollo en Java/J2EE.

El proceso es el siguiente: a través de un reclutador se buscan candidatos, que pasan a una primera entrevista con la gente de RH. Si no detectan inconsistencias en su persona, me pasan sus CVs. Como anteriormente he publicado en este blog, siempre me voy por las palabras clave: EJB 3.0, JMS, Spring, Struts. Si se ven bien, pasan a entrevista conmigo; si creo que tienen lo que se requiere los envío con los directores de operaciones e ingeniería. Posteriormente pasan a videoconferencia con el equipo de San Diego, quienes evalúan el nivel de inglés y manejo de tecnologías en Java.

Aunque por cuestiones internas de la compañía están congeladas las contrataciones de manera temporal, debo seguir entrevistando gente hasta tener una “cartera de candidatos” de la cual elegir en un par de meses. El detalle es que desde San Diego me están rebotando a la mayoría y los pocos que dejan satisfechos a los gabachos resultan ser unas divas. Por ejemplo, un ruso que estudió en el Instituto de Aviación de Moscú se veía como el candidato ideal, hasta que nos salió con que sólo trabaja después de las 10:00 AM porque… se le pegan las sábanas (nuestra hora de entrada es a las 8 de la mañana). Por otro lado, ya que en ciertas ocasiones tengo que entrevistar hasta a tres candidatos por día, ocupando de dos a tres horas de mi día laboral, el proceso se está volviendo muy pesado, por lo que estoy implementando con la gente de recursos humanos una pequeña iniciativa con el fin de determinar sin perder tanto tiempo si la gente sabe lo que dice que sabe.

Así hemos llegado a un quiz con 20 preguntas que nos dan un buen indicador de fortalezas y debilidades en áreas como diseño funcional, construcción, estructuras de datos, pruebas y mantenimiento. Sin embargo, la pregunta más importante de todas es la siguiente:

¿Qué es lo que más te preocupa cuando recibes o revisas el código de otra persona?

La mayoría se va con la finta y da una respuesta relacionada a problemas de estilo, como el nombre de las variables, la indentación o el número de comentarios en el código. ¡BEEEEP! Prueba no superada.

La respuesta correcta debe tratarse sobre temas de fondo: aversión por aplicaciones con poca cohesión, algoritmos lentos, código potencialmente inseguro o que no haya implementado patrones de diseño. ESO es lo que estamos buscando: ingenieros de software, no críticos de estilo.

Hace poco apliqué de contrabando esta pregunta a ciertos ex-compañeros de trabajo para ver qué tan acertada es para determinar su nivel. ¿El resultado? Aquellos que llevan menos de 5 años en la industria me dieron de manera consistente la respuesta de la indentación. De aquellos que cuentan con mayor seniority, sólo uno de cada cinco me respondió acertadamente. Y esto porque los dos que me respondieron bien son masters-de-masters con ya muchos años trabajando en esto.

¿Es ésta la pregunta perfecta en una entrevista de trabajo? Por supuesto que no. Sin embargo, es un buen filtro del que podemos echar mano si estamos buscando gente de buen nivel para hacerse cargo de aplicaciones complejas sin riesgo de que las chocolatee. Por lo pronto, con el nuevo cuestionario me podré ahorrar bastante tiempo y la pena de que los gringos me reboten gente porque “no los impresiona” o les falla el inglés a la hora de la verdad.

Anuncios