Si hay algo que suscite un debate encendido en el sector tecnológico son las pruebas técnicas en los procesos de selección
17 feb 2021 . Actualizado a las 05:00 h.Si hay algo que suscite un debate encendido en el sector tecnológico son las pruebas técnicas en los procesos de selección ¿Son un mal necesario o un rito inútil que solo sirve para proporcionar una falsa sensación de seguridad?
Pues... depende. En los tiempos que corren, cualquier matización de un tema tan polémico como este supone arriesgarte a despertar la ira de aquellos afortunados que no albergan ninguna duda de estar en posesión de la verdad -sea cuál sea su postura-, pero lo cierto es que las pruebas técnicas no son malas de por sí, pero si hay muchas pruebas técnicas malas.
Por supuesto, podríamos optar por no hacer ningún tipo de prueba técnica. En otros sectores no son tan comunes ¿por qué deberían serlo en la industria informática? Es habitual oír comparaciones desafortunadas con áreas como la arquitectura o la medicina -«A ningún médico le piden que opere unas cataratas en el proceso de selección»-, pero la analogía es profundamente desafortunada.
Por suerte, nuestra profesión es una de las más abiertas del mundo. A la inmensa mayoría de las empresas les da absolutamente igual cómo hayas adquirido la experiencia y habilidades necesarias para desempeñar con éxito un puesto de trabajo, pero esa apertura -que trasciende la formación reglada, la colegiación forzosa o la suscripción obligatoria de seguros de responsabilidad civil- obliga a las empresas a desarrollar procesos propios para validar esa experiencia y habilidades.
Por otro lado están las peculiaridades del oficio. Existe un amplio consenso en el sector sobre la consideración de la programación, el diseño e incluso la administración de hardware como un proceso creativo más que simplemente ejecutivo. Esa misma creatividad que hace que sea mucho más complejo estimar cuanto se tardará en construir un software funcional que una pared de 7 metros de ladrillo, también hace que sea absurdo esperar una productividad homogénea de dos profesionales, aunque compartan la misma formación y experiencia.
Pero aunque así fuera, tampoco sería un método de selección efectivo porque la construcción de software es un proceso colaborativo. Es muy complicado determinar de forma sencilla donde empieza y acaba la autoría de un código o las aportaciones concretas de un técnico a un proyecto. Hay desarrolladores que en 10 años han visto atacar naves en llamas más allá de Orión y rayos-C brillar en la oscuridad cerca de la Puerta de Tannhäuser, pero también hay gente con 10 años de experiencia que se ha limitado a repetir su primer año diez veces. Por eso, un curriculum técnico necesita un análisis cualitativo no solo cuantitativo. Otra cosa es que lo hagamos de forma correcta.
Desde que empezamos a trabajar en Manfred hemos tenido la oportunidad de participar en centenares de procesos de selección para empresas de todo tipo y conocer un montón de pruebas técnicas diferentes, recogiendo feedback tanto de candidatos como de empresas. Supongo que eso nos ha dado la posibilidad de identificar cierto patrón de éxito, un conjunto de buenas prácticas que comparten los procesos de selección mas efectivos que intentamos replicar en nuestros propios procesos. Empezando por algo tan sencillo y al mismo tiempo tan complicado como ser conscientes de qué somos y qué queremos.
Debemos empezar asumiendo que un proceso de selección -incluyendo la prueba técnica- nunca es objetivo sino subjetivo. Pero en vez de deshumanizar el mismo -por ejemplo, delegando las pruebas técnicas en sistemas automatizados que devuelven una «puntuación» que determine el éxito de una candidatura- lo mejor que podemos hacer para combatir nuestros propios sesgos es asumirlos, para que el encargado de un proceso de selección pueda identificar cuando están condicionando su toma de decisiones. Puede ser algo tan tonto como menospreciar a alguien que nos escriba con una cuenta de Hotmail o cosas mucho mas graves, como discriminar a alguien por su género, edad, raza, religión u origen.
También deberíamos asumir quienes somos y actuar en consecuencia, para no hacer el ridículo. Es verdad que el Ego del Programador es una de las «enfermedades» más extendidas en el sector, pero igual que no todos somos Margaret Hamilton o Dennis Ritchie y debemos aceptar que no estamos capacitados para cubrir todas las vacantes técnicas, no todas las empresas son Apple o Microsoft, así que, no tiene sentido que copien sus procesos de selección, incluyendo las pruebas técnicas. Primero, porque no se enfrentan a los mismos retos técnicos organizativos o de negocio. Segundo, porque no poseen -ni de lejos- la misma capacidad de atracción de talento.
Una compañía como Google recibe tres millones de currículos al año, así que, se puede permitir poner a los candidatos a «programar» en Google Docs, diseñar algoritmos en una pizarra en blanco y hasta pedirles que hagan el pino. Puede desperdiciar candidaturas válidas aunque necesite encontrar gente que programe tan fino Pochettino como para desarrollar un sistema que aguante zillones de peticiones concurrentes con una disponibilidad de cinco nueves. Que una empresa tecnológica normal -una que, por ejemplo, desarrolle aplicaciones web B2B con unos cuantos miles de usuarios- haga las mismas pruebas es... absurdo.
Sorprendentemente, esas pruebas técnicas draconianas no suelen partir del típico directivo flipao que ha leído un libro sobre como atan perros con longanizas en Silicon Valley y pretende hacer lo mismo en Lalín o San Cristovo, sino de un equipo técnico que -en demasiadas ocasiones- no sería capaz de superar las pruebas técnicas que exigen a los candidatos. Por eso, nunca deberíamos empezar un proceso de selección sin que todos los implicados en el mismo tengan claro los objetivos empresariales que hay detrás del mismo. En más de una ocasión he tenido conversaciones como esta:
- ¿Por qué pides que los candidatos sepan gestionar una infraestructura en la nube si se van a dedicar a programar?
- No sé. No sabía que poner y he puesto eso porque oye si saben mejor que mejor.
Un momento clave de nuestra Historia fue el día en el que rechazaron a uno de nuestros candidatos en un proceso de selección para una empresa desesperada por encontrar programadores para implementar las funcionalidades que su creciente base de usuarios le demandaba. Los técnicos justificaron el corte porque en la prueba había usado tabuladores en vez de espacios. Recuerdo la cara de estupefacción de la responsable de Recursos Humanos cuando le dijimos que no aceptábamos el resultado de la prueba y le pedimos que la devolviera al equipo de desarrollo para que la evaluara de nuevo. Perdimos la cuenta, por supuesto, pero el tiempo invertido nos sirvió para tomar consciencia de hasta que punto llegan a estar desalineados los objetivos que se marca el técnico que evalúa una prueba -que cree que debe encontrar a la próxima Sabela Ramos- y las necesidades de la empresa que, en la inmensa mayoría de los casos, simplemente necesita ampliar su capacidad de ejecución con técnicos competentes.
Pero ¿qué es «un técnico competente»? Pues depende de cada empresa y cada circunstancia. Algunas quieren que sean efectivos de forma inmediata o que resuelvan una necesidad específica, pero las empresas mas estratégicas y que piensan a largo plazo se centran en buscar profesionales que puedan afrontar cualquier reto tecnológico que pueda aparecer en un futuro, algo que parece tener sentido en una industria donde herramientas y procesos quedan obsoletos en un corto espacio de tiempo. Por eso, en vez de comprobar su dominio de una tecnología concreta, se enfocan en detectar hasta que punto han asimilado buenas prácticas de desarrollo como el empleo de TDD o de preprocesadores CSS, la implementación de los principios SOLID, el uso de sistemas de integración continua o librerías de componentes UI reutilizables.
El problema es que el empleo de esas buenas prácticas es, en muchos casos, transversal y va más allá de lo que se puede plasmar en un simple ejercicio de código. Por eso, el objetivo de una prueba técnica no debería ser otro que crear un contexto que facilite una conversación posterior de la que se pueda deducir la idoneidad del candidato para el puesto. Una evaluación que debería ser mutua, porque lo peor que le podría pasar a una empresa no es que nadie que encaje con lo que busca, sino que encuentre a alguien que sí lo haga, le contrate e invierta tiempo y recursos para que se integre lo antes posible, solo para descubrir que este abandona la compañía a los pocos meses porque la misión de la misma y su día a día no están alineados con sus motivaciones e intereses.
Pero una vez que tenemos claro qué debería proporcionarnos una prueba técnica ¿cómo deberíamos implementarla? Cómo dice mi amiga Justyna, haciendo que se parezca lo más posible al trabajo que desempeñará el candidato. Si vamos a dejarle buscar en Google o usar un IDE cuando esté desarrollando, por ejemplo, tiene sentido que también pueda hacerlo durante la prueba. Y, si es posible, que cuente con los materiales -código, gráficos, documentos- con los que trabajaría en su día a día. Esta orientación trasciende el mundo del desarrollo de software. Nosotros, a los candidatos a un puesto de recruiting les pedimos que redacten una oferta de empleo y hagan una propuesta para cubrir la vacante a partir de alguna base de datos abierta, como LinkedIn. Lo mismo que harían si trabajaran aquí.
El formato que finalmente se implemente -ya sea una prueba presencial, un test para hacer solo en casa o un ejercicio colaborativo, como por ejemplo una sesión pair programming- también debería acercarse lo máximo posible a la cultura de trabajo de la empresa.
Una cosa importante a tener en cuenta es ser exhaustivos y explícitos a la hora de explicar al candidato qué se evaluará en la prueba. Si para nosotros es imprescindible ver cómo usa el nombre de variables y métodos para autodocumentar su código o -por ejemplo- comprobar si sabe minificar JavaScript, deberíamos especificarlo en el enunciado de la prueba, igual que le informaríamos del conjunto de procesos, normas y convenciones que debería seguir cuando empezara a trabajar con nosotros.
Recuerdo un proceso en el que los candidatos debían hacer una llamada a una API REST y pintar los datos recibidos en una página web. Una prueba aparentemente sencilla contra la que tropezaban uno tras otro... hasta que nos dimos cuenta de dónde estaba el problema: la empresa esperaba que, a partir de cierto número de resultados, el candidato los paginara. Algo que no se le pasaba por la cabeza a la mayoría de ellos hasta que sugerimos que el HTML estático, que se proporcionaba para incrustar los resultados dinámicos, incluyera un par de etiquetas que pusieran "< Prev" y "Next >". Lo que sucedió después, os sorprendería... o no.
Por último, no deberíamos olvidar jamás que -en un mercado laboral donde, aparentemente, hay más vacantes que profesionales con la experiencia y habilidades necesarias para poder cubrirlas- cuando iniciamos un proceso de selección estamos vendiendo, no comprando. Debemos vender nuestra compañía, dejar claro por qué alguien debería abandonar su zona de confort para venir a trabajar con nosotros y no con otros... sin obviar que los candidatos descartados de hoy pueden ser perfectamente válidos el día de mañana, así que, preocuparnos porque nuestro proceso sea lo más agradable posible no es solo una cuestión de humanidad y empatía, sino también estratégica.
Si diseñamos una prueba técnica que exige que alguien invierta 20 horas de su tiempo es probable que nadie la haga. Si nuestro proceso de selección hace que los candidatos estén a disgusto es probable que nadie nos seleccione. Recuerdo hablar con la responsable de talento de una gran operadora de telecomunicaciones que se quejaba de las pocas candidaturas que conseguían cristalizar en contrataciones. Cuando me explicó que obligaban a los candidatos a desplazarse hasta su oficina -donde sentaban a grupos de 4 o 5 en una bancada de ordenadores, todos juntos al mismo tiempo- para hacer la prueba técnica de forma presencial mientras un técnico de la empresa se sentaba detrás de cada uno para ver lo que estaban haciendo, le dije que lo que me extrañaba es que hubiera alguno que la completara.
En general, más allá de las pruebas técnicas, un proceso de selección debería aportar a los candidatos un valor equivalente al tiempo que estos hayan invertido en el mismo. Algunos creen que la mejor manera sería remunerar el tiempo invertido en hacer una prueba técnica. Puede ser, pero dependiendo de la legislación laboral local llevarlo a la práctica podría ser un auténtico engorro, tanto para la compañía como para los propios candidatos. Lo mínimo que estos deberían llevarse, eso si, es tanta información de la empresa y de cómo se trabaja dentro de la misma como esta obtiene de ellos y su forma de trabajar.
En definitiva, las pruebas técnicas no sirven por sí solas para determinar la calidad de una candidatura -como mucho, para identificar extremos, tanto en un sentido como en otro-, pero en vez de afrontarlas como un incomodo problema, pueden convertirse en una oportunidad para que candidatos y empresas se conozcan. La conversación posterior sobre la misma debería ser suficiente para que unos y otros determinen si pueden trabajar juntos. Si la tecnología es un medio no un fin en sí misma, el objetivo de la prueba técnica no debería ser encontrar respuestas sino generar preguntas. Un mapa que nos ayude a encontrar lo que buscamos.
Esta Bonilista ha sido posible gracias a un operador de telecomunicaciones para startups
Imagina una compañía que solucionara todas las necesidades de conectividad de tu empresa (desde líneas móviles a centralitas virtuales) y para la que no fueses un número más sino un cliente con nombre y apellidos que pudiera comunicarse siempre con un mismo interlocutor para resolver cualquier duda o incidencia. Mi amigo Alex decidió dejar de imaginar y creó el operador que siempre hubiera querido encontrar.
¿Que para qué te vas a meter en movidas pudiendo contratar a un operador «de toda la vida»? Porque probablemente tus necesidades no sean las «de toda la vida». Por ejemplo, en Manfred decidimos poner un teléfono para atender las consultas de potenciales clientes, un número 900 (gratuito para el que llama), pero no queríamos atenderlo desde un teléfono fijo sino que queríamos que enrutara la llamada a un móvil, pero... ¿a qué móvil? Dependiendo del día -e incluso de la hora- atendería el teléfono Yago, yo mismo... o un contestador, si te daba por llamarnos a las dos de la mañana para que te ayudáramos a encontrar un developer de COBOL.
Podríamos conseguir lo mismo con un pastiche de lineas, APIs y servicios, pero Comunica proporciona todos estos servicios y mucho mas (acceso a Internet, monitorización IoT, números internacionales...), siempre con un trato exquisito, y un servicio técnico impecable que te atiende en castellano.
Para que podáis comprobar de primara mano la calidad de sus servicios, Comunica quiere obsequiar a los suscriptores de la Bonilista con un número 900 completamente gratuito (solo pagarás por las llamadas recibidas) durante 6 meses. Si os interesa la promoción solo tenéis que llamar al 910 600 600 o entrar en la web www.comunica.com y rellenar el formulario.
Este texto se publicó originalmente en la Bonilista, la lista de correo de noticias tecnológicas relevantes para personas importantes. Si desea suscribirse y leerlo antes que nadie, puede hacerlo aquí ¡es bastante gratis!