“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”.
Habla Jorge Aguilera, programador veterano. Aunque por el tono de su voz —a camino entre el fastidio, la incredulidad y una frustración bien digerida con humor— pueda parecer que la prueba de código la hizo el fin de semana pasado, la anécdota le ocurrió hace ya algún tiempo.
Ahora Jorge tiene empleo y en la empresa para la que trabaja, la startup Tymit, le toca con frecuencia estar del otro lado durante los procesos de selección: el de quienes ayudan a evaluar a los candidatos. No olvida sin embargo lo que le ocurrió hace años como aspirante. “Lo tengo clavado. Ahora me río, pero en su momento me fastidió, la verdad”, admite. Por esa razón, explica, 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 no es un caso aislado. Ni siquiera el más sangrante o polémico. Aunque —reconocen desde el sector— cada empresa es un mundo y la forma de plantear los métodos de selección varía de una compañía a otra, 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 tirarme 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 —abunda Quesada—. 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 —relata el desarrollador—. 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”.
¿Cómo mejorar los procesos? Desde su experiencia Quesada apuesta por dos claves. Desde el punto de vista del entrevistador anima a cuidar el feedback, mantener informados a los candidatos en la medida de lo posible. “Me he encontrado muchas veces con que tenía que reclamar feedback técnico”, relata. A los candidatos les sugiere otra cuestión igual de relevante: reflexionar sobre las motivaciones y plantear todas las preguntas que les surjan para aclarar sus dudas.

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”, comenta.

Las pruebas prácticas tienen también sus defensores, 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?”, recoge este artículo de Infojobs en el que se apuntan las ventajas de valorar el código fuente de los candidatos, una manera eficaz y rápida —alega— 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 principales quejas de los candidatos: la excesiva duración de algunas pruebas técnicas, la duda de que pueda usarse como “trabajo gratis” y la falta de información o incluso feedback tras la entrevista
“Creo que estas pruebas de siete o diez días son una locura y no son necesarias para ver si la persona tiene o no la capacidad de trabajar contigo”, abunda Ariane. Otra de las cuestiones sobre las que llama la atención es su diversidad. A lo largo de su carrera se ha encontrado code test, pruebas de algoritmia en pizarra en blanco, entrevistas con personal del área de RR. HH., otras con técnicos durante las que se preguntaba por cuestiones como patrones de diseño o de arquitectura, testing, POO, principios SOLID, programación funcional, recursividad… “Para mí fue un choque darme cuenta de que no siempre te vas a encontrar con lo mismo. Esa incertidumbre se suma a los nervios de no saber qué te van a plantear, cómo será la prueba”, lamenta.

“No entiendo por qué no hay unanimidad, por qué no puede ser siempre el mismo tipo de pruebas. En el trabajo en el que estoy ahora me hicieron simplemente una batería de preguntas básicas de JavaScrip de 40 minutos. El mismo día que tuve la reunión con RR. HH. y el manager. Más o menos una hora y cuarenta minutos y ya estaba”.
Jesús Martín, desarrollador de aplicaciones para IOS, tiene también experiencia afrontando procesos de selección y reconoce lo distintas que pueden llegar a ser las pruebas. “Dependiendo de la empresa te puedes encontrar una cosa u otra, de una simple entrevista con el responsable técnico de la compañía a otra mucho más elaborada en la que primero hablas con Recursos Humanos, luego te mandan una prueba para que la hagas en casa… Sobre todo lo que cambian son las fases del proceso de selección”, comparte.
“Yo puedo llegar a entenderlo por parte de la empresa para que tu no te prepararse la entrevista. No hay nada estandarizado. En el mundo del software es difícil hacerlo porque al final la tecnología cambia muy rápido y encontrar una prueba estándar es muy complicado”. Al igual que otros muchos desarrolladores, Martín lamenta la falta de feedback e información por parte de algunas compañías durante el proceso de selección. También le ha tocado lidiar con pruebas de código que le requirieron varios días de dedicación. ¿Sintió en algún momento que estaba trabajando gratis? “Personalmente yo no, no me he encontrado en ese caso. Ni con la sospecha”, explica. La sensación que sí comparte es la de que los code test son “cada vez más comunes”.
Martín recuerda también cómo en algunas compañías tecnológicas se echa mano de las pruebas de algoritmia en pizarra, “la más complicada y bastante temida”. “En EE. UU. es muy común. Te ponen frente a una pizarra, te cuentan un problema técnico y tú tienes que llegar a una solución o decir cómo lo resolverías. Tienes que dar con una solución mientras te examinan. Aunque, como todo, se puede preparar”, señala. A modo de ejemplo recuerda
Cracking the Coding Interview, libro que trata precisamente sobre cómo enfocarlas. Una de las compañías en las que se recurre a la programación en una pizarra en blanco —según recogía en 2016 de Business Insider— es Google.

La diversidad de las pruebas puede estar directamente ligada con la propia heterogeneidad de perfiles profesionales que se dedican a la programación. Ariane lamenta, por ejemplo, que aún hay profesionales que miran con recelo los bootcamps. “Hay mucha gente que todavía no cree en los cursos intensivos, que tiene esa ‘titulitis’ en la cabeza y piensa que si no eres ingeniero no sirves para programar. Están equivocados. Hay que creer en la gente y ver sus capacidades”.

Del otro lado de la mesa: quienes seleccionan

Gracias a su dilatada experiencia Jorge Aguilera conoce bien los procesos desde ambos lados de la mesa. Desde la posición del candidato al que le llega por mail una prueba que debe completar en cierto tiempo —sin que haya el menor contacto humano con la compañía— a la del empresario o incluso técnico que apoya al departamento de RR. HH. durante la selección. En su empresa, Tymit, se emplea una “fórmula” de evaluación en la que se busca principalmente, asegura Jorge, “conocer la experiencia” y el modo de trabajar de quien se postula para el cargo.
La primera fase consiste en la búsqueda de currículos y perfiles desde el área de RR. HH., sobre la que recae la labor de “cribado inicial”. A los aspirantes se les explica en qué consiste la empresa, su enfoque o el puesto disponible. Le sigue una entrevista con personal de frontend y backend. “No son más de 15 o 20 minutos y no hablamos tanto de lo que hace la aplicación, como sí de la forma en que intentamos nosotros que lo haga. La idea es transmitir nuestros valores”, relata. Una vez completada, llegaría la entrevista técnica. “Ahí es donde tú tienes que darnos el feedback a nosotros”, bromea Jorge. Se habla de Java, fragmentos de código para que el candidato identifique su uso y problemas… “No necesito que me hagas pseudocódigo, solo que me lo discutas”.
“Diseñamos un documento sobre el que vamos a hablar de una serie de tecnologías. No hay prueba de código. No necesitas compartir pantalla, aunque en ocasiones es preferible que pudieras compartir porque a lo mejor te vas a sentir más cómodo escribiéndonos un pseudocódigo. Pero la función de esto es, por ejemplo: ponemos un cachito de código de Java y de lo que se trata es de que tú nos digas qué crees que hace el código, qué problemas le ves… Siempre en el plan de que te lo leas tranquilamente y me comentes qué problemas estás viendo. No necesito que me hagas un seudocódigo ni nada. Simplemente discútemelo”, señala Aguilera.

“Luego la siguiente prueba, a la que damos mucha importancia, son los test. Tenemos un ejemplo muy tonto. A veces hemos hecho una máquina de café; otras un radiador, algo que no es del negocio. Y planteamos: supón que tienes que hacer los test de la máquina, ¿Qué propondrías? Se trata de que planteen test unitarios, de integración, cómo lo diseñarían…”, comenta. A lo largo del proceso sobre la mesa se deslizan cuestiones relacionadas con Java, GIT, Docker… El último paso es la entrevista con el CTO para conocer la filosofía de la compañía.

Iria Vázquez, del departamento de RR. HH. de Bahía Software, explica que en su compañía recurren a un recruiting activo. “Estamos en LinkedIn buscando diferentes perfiles. Dado que en el sector actualmente el número de perfiles que están empleados es casi del 90% somos nosotros quienes contactamos con aquellos que nos parecen interesantes e iniciamos el proceso”, añade. Sus ofertas están disponibles también en su web de Enjoy Bahía. La primera toma de contacto de los aspirantes se establece con el departamento de selección de personal y consiste en una evaluación general a la que le sigue después la de carácter más técnico, en la que se puede plantear una evaluación y entrevista con personal del equipo, como un responsable del proyecto. “En el primer contacto ya dejamos claro de antemano cuál va a ser el proceso, en qué va a consistir y también los plazos”, apostilla.
“Es cierto que hay determinadas situaciones en las que los plazos se dilatan porque puede estar alguien de vacaciones, surgir algún imprevisto que lo retrase un poco… Pero habitualmente solemos manejar unos plazos de unas dos o tres semanas para concluir el proceso de selección en todas sus fases. Y es algo que el candidato conoce ya en el primer contacto”.
Durante el proceso —explica la técnica de RR. HH.— se recurre a pruebas de carácter técnico. Aunque pueden variar de una oferta a otra, poco tienen que ver sin embargo con las que requieren días de trabajo. “La más exigente está pensada para que se complete en tres horas, más o menos. Como cada candidato las hace en el momento que le viene bien, normalmente damos varios días de margen. Nos adaptamos a las circunstancias de cada uno de los candidatos. En función de sus preferencias o tiempo del que pueda disponer, nos amoldamos”, detalla.
Las empresas apuntan que las pruebas de código se centran en ejemplos totalmente ajenos a su negocio. Sus partidarios insisten en su validez y las equiparan a las audiciones a las que deben enfrentarse los actores.
¿Se usan los resultados de esas pruebas más tarde como un trabajo aprovechable? “En ningún caso. Las pruebas que tenemos planteadas de hecho son con ejemplos totalmente chorras. Por ejemplo una de las que tenemos es con una clínica veterinaria, que no son nuestros clientes ni especialidades. Son ejemplos cotidianos y no tienen nada de aprovechable”.
“En muchas ocasiones nos hemos encontrado con candidatos que son reticentes a hacer este tipo de pruebas. Lo entendemos. Ya no solo porque se puedan haber encontrado con situaciones de este tipo, sino también por la inversión de tiempo. Por eso para nosotros es fundamental que el candidato se pueda organizar como quiera para hacer la prueba”, comenta Iria, quien recalca, en cualquier caso, que sus pruebas oscilan entre los 15 minutos y las tres horas.

Ángela Souto trabaja también en el área de selección de personal de otra gran empresa de carácter tecnológico: Altia, consultoría y prestadora de servicios TIC. Su labor de búsqueda es igualmente proactiva y durante el proceso recurre principalmente a LinkedIn e InfoJobs, que pueden completar con plataformas internacionales. “A día de hoy un 70 u 80% consiste en búsqueda proactiva. El otro 20% pueden ser personas que se inscriben o se dirigen a nosotros a través de la web o por contactos y referencias internas. Hay que ser especialmente proactivo”, señala.
El primer peldaño para los aspirantes consiste también en una entrevista de carácter personal durante la que se atiende a cuestiones como las motivaciones o expectativas. “Con esa información continuamos o no con el candidato y se lo presentamos a los responsables técnicos del proceso de selección. Si le encaja, ya cerramos una entrevista presencial o telemática”, comenta.

¿Se aporta toda la información en la oferta? “Te mentiría si te digo que publicamos toda. Ponemos las tecnologías, pero no especificamos ni sector, ni cliente ni en qué va a consistir como tal porque muchas veces esa información es sensible —señala Ángela—. En el momento en que alguien se apunta y nos encaja, en esa primera llamada con nosotras le decimos qué proyecto es, las tecnologías… Intentamos dar la mayor información posible para que nadie se lleve un chasco”.
En cuanto al envío de pruebas técnicas, la compañía prescinde de ellas. “La filosofía es que hacemos una entrevista técnica y durante la conversación se pregunta, plantea cómo afrontar situaciones que nos permiten ver la capacidad resolutiva de la persona, su capacidad para aprender, qué problemas se ha encontrado, qué soluciones… Se trata de una entrevista para saber sus conocimientos, pero no hacemos una evaluación técnica”, detalla Souto: “Al final poner a prueba bajo un examen a alguien que ya tiene una trayectoria profesional no es la clave para detectar si es la persona que necesitamos para la compañía. Creemos que cuando una persona apuesta por nosotros y nosotros por esa persona, en el momento que llega a la empresa se aprecia muy rápido si tiene o no ese conocimiento. Se trata de confiar, de ver cómo funciona”.

El feedback con aspirantes es también fluido. “Hay procesos que se complican, que empiezan el día 1 y el 25 aún no están resueltos. En esos casos, habrá tenido dos contactos por nuestra parte”.
Gracias a su labor como responsable de operaciones y RR. HH. de KeepCoding, centro de formación en programación y tecnología, Marina Boticario aporta una visión de gran valor sobre la experiencia de los candidatos. “De lo que más se suelen quejar es de que les hacen pruebas incluso sin que haya una entrevista personal. El primer filtro es una prueba larga, a la que hay que dedicar mínimo un fin de semana. Y ahora sobre todo con el COVID-19 se está focalizando en el trabajo online. Te dan una prueba y hay veces en las que tienes que estar tres o cuatro días dedicado totalmente a hacerla —señala—. Es una manera más rápida de filtrar. Consiste solo en darle a un botón. No tienen que quedar con el candidato físicamente”.
“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”, abunda Boticario desde las oficinas de KeepCoding.

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”, comenta Marina.
Imágenes: Tim Regan (Flickr)

Fuente: https://www.xataka.com/otros/empresa-busca-programador-polemica-cuando-pruebas-seleccion-camuflan-trabajo-gratuito
Autor: Carlos Prego