“Me llamaron de Recursos Humanos de una compañía y me dijeron que tenía que hacer la típica prueba de código. A mí me gustan, la verdad, porque me sirven para ver cómo respira la empresa, así que le dediqué un fin de semana: la trabajé, me planteé el reto, preparé la documentación… Pero menos de una hora después de haberla enviado me despacharon diciéndome que no era lo que buscaban, que no había usado cierto patrón que ellos querían. Muy bien, vale, pero… ¿De todo lo demás no había nada de lo que hablar? Aún estoy esperando que me contesten”.
Jorge Aguilera, programador veterano ya tiene empleo y en la empresa para la que trabaja, una startup llamada Tymit, ahora a él le toca con frecuencia estar del otro lado durante los procesos de selección: el de quienes ayudan a evaluar a los candidatos. Pero no olvida lo que le ocurrió hace algunos años como aspirante. “Lo tengo clavado. Ahora me río, pero en su momento me fastidió, la verdad”, admite. Explica que por esa razón, cuando en su compañía buscan fichajes intentan que impere el feedback. “Que la gente vea que no son recursos, sino humanos”. El de Jorge sin duda, no es un caso aislado. Ni siquiera el más sangrante o polémico. Aunque cada empresa es un mundo y la forma de plantear los métodos de selección varía en cada compañía, los procesos que afrontan los programadores cuando buscan trabajo están rodeados con frecuencia de, cómo mínimo, cuestiones abiertas a debate: ofertas que apenas incluyen información y durante las que el aspirante no llega a tener contacto directo con sus futuros empleadores, una enorme variedad de sistemas de evaluación —lo que hace prácticamente imposible estandarizarlos—, pruebas que exigen varios días de dedicación por parte del candidato sin ningún tipo de compromiso ni contraprestación… Incluso la sensación de que las compañías pueden llegar a sacar provecho en sus negocios de ese mismo material —que el desarrollador realiza para demostrar sus habilidades— sin el menor pago a su autor. Las casuísticas son numerosas.
Programadores y empresas explican sus puntos de vista.
Un fin de semana de trabajo… sin garantías
“Sí he tenido que hacer alguna prueba de ese tipo, de aventarme un fin de semana completo o un puente, tener que cancelar todos mis planes porque tenía que hacer una prueba de código”, reconoce Fran Quesada, desarrollador. Aunque evaluaciones de este tipo son frecuentes, apunta también que “poco a poco van perdiendo prestigio” en el sector. “Empieza a verse mal que tengas que dedicar tanto tiempo. Pero depende totalmente de la empresa. Yo personalmente no creo tanto en su validez. Al final los períodos de prueba están para lo que están”, comenta.
“Yo lo veo justificado si necesitas a alguien no tanto por el código que escribe sino por cómo organiza. Si necesitas asegurarte de que la persona que va a entrar en tu equipo es organizada o algo similar. Por suerte o por desgracia hay gente que copia. La realidad es que tú puedes enviar una prueba de código, que el entrevistado te la entregue y no la haya hecho él. Eso puede ocurrir. En ese sentido es un arma de doble filo. Yo personalmente opino que muchas cosas que se ven en una prueba de código se pueden ver en una conversación normal con alguien”.
A pesar de su experiencia, Fran explica que nunca ha terminado una selección con la sospecha de que su prueba pudiese servir luego a la empresa para sacarse trabajo de encima gratis. “Las que he hecho normalmente son cosas que están completamente fuera del producto para el que me entrevistaban. Una, por ejemplo, consistía en programar el radar de una nave de Star Wars. Compañeros míos sí han tenido que hacer cosas, sin embargo, que se veía que eran funcionalidades que tenían que meter en sus aplicaciones. A lo mejor te pedían un lector de códigos QR y luego veías que esa misma empresa no lo tenía todavía”.
Ni cortas, ni fáciles y tremendamente diversas
“No son pruebas cortas, ni fáciles. Uno invierte esfuerzo y le pones muchas ganas porque quieres hacerlo bien y al final si no te escogen te quedas con la sensación de que has hecho trabajo para nada”, comenta Ariane Jurado, programadora, sobre las pruebas de código a las que los candidatos pueden dedicar varios días. A esa presión por ganar puntos ante la empresa se suma otro hándicap, recuerda: que habitualmente los candidatos están ya trabajando, lo que les obliga a sacar tiempo de debajo de las piedras, robar horas al sueño o al ocio y aprovechar ratos libres para completar los test que proponen las firmas.
A menudo están también las dudas, admite, sobre el uso que la empresa podría dar al material elaborado por los candidatos. “Hay pruebas técnicas que te piden mucha funcionalidad del producto al que aplicas y al final la gente siente que está sacando trabajo gratis. Hay mucho debate en la comunidad, con gente que dice que no deberíamos aceptar este tipo de pruebas porque al fin y al cabo supone un trabajo gratis y quien sostiene también que puedes demostrar tu capacidad técnica con un proyecto que ya hayas hecho, sin necesidad de hacer algo nuevo”.
Claro que existe el otro lado de la polémica, quienes defienden las pruebas, que las equiparan casi a las audiciones que se exige a los intérpretes. “Si bien la entrevista es la parte central del proceso de selección, quedarse solo con eso es un enfoque extremadamente negligente. ¿Alguien contrataría a un actor sin realizar un casting?, ¿un deportista sin realizar pruebas físicas?”, Llas ventajas de valorar el código fuente de los candidatos, una manera eficaz y rápida de filtrar a los aspirantes. La forma en cómo se lleva a la práctica no tiene por qué ser siempre igual, sin embargo. Una de las opciones sería que el candidato aportase algún proyecto que ya ha escrito. Otra, que resuelva un problema planteado por la compañía.
“Las ofertas son muy amplias, es cierto. Te piden muchos lenguajes, cosas tanto de back como de front; pero creo que eso pasa en todos los ámbitos, no solo en el mundo del desarrollo. Siempre hay cierto grado de incertidumbre y no saber qué va a pasar en una entrevista. Se puede extrapolar un poco a la amplitud y generalidad que puede tener un puesto. Hay un montón de lenguajes que están en constante evolución”.
Un consejo: practicar, enfrentarse a retos personales, documentarse, acudir con tranquilidad a la prueba y preguntar. “Tienes que saber que es una entrevista, que lo que quieren es conocerte y ver también cómo te enfrentas a situaciones que desconoces”.
