Los procesos de selección suponen un momento importante tanto para la empresa que contrata como para el candidato que oposita al puesto. Unos deciden crecer (o contrarrestar una baja) haciendo una apuesta y buscando la pieza que le falta al equipo. Otros buscan su lugar en el mercado laboral ilusionándose y apostando por tu empresa.
Una de las fases claves de estos procesos son las pruebas técnicas y, en mi humilde opinión, la que generalmente peor se ejecuta. Según mi criterio, la prueba técnica solo se ha de realizar a aquellos candidatos que estamos convencidos de que son los adecuados para el puesto. Simultanear muchas pruebas técnicas para luego elegir entre ellas la que más nos convence me parece aprovecharse de la necesidad y del interés de los candidatos. Personalmente, solo doy acceso a la prueba técnica a aquellos candidatos con los que estoy convencido de que son los adecuados para el puesto.
Sería un ejercicio interesante obtener el dato de qué porcentaje de pruebas técnicas terminan en contratación en cada empresa.
Sería un ejercicio interesante obtener el dato de qué porcentaje de pruebas técnicas terminan en contratación en cada empresa. Este dato nos diría mucho acerca del respeto que tienen las empresas hacia los trabajadores.
Tipos de pruebas técnicas
En mi experiencia como candidato he realizado todo tipo de pruebas técnicas. Antes de analizarlas debo decir que cada puesto de trabajo y cada empresa es diferente, y cada tipo de prueba técnica puede ser más adecuada para un tipo de puesto. Voy a generalizar y a hablar de un puesto de desarrollador web fullstack o backend sin necesidades especiales en algoritmia, seguridad u otros aspectos que pueden condicionar la búsqueda de empleados.
Uno de estos tipos de prueba técnica es el test teórico. Esa prueba técnica en la que no tienes que picar código, solo responder a preguntas técnicas concretas. Sí, es muy fácil de evaluar, ¿pero qué sentido tiene preguntar el nombre de una clase o enumerar las propiedades de un patrón de diseño? Es información que está disponible en internet en todo momento y que no es concluyente: no saber cual es el nombre de una clase no implica no saber usarla o no conocer la teoría de ese patrón no implica no saber aplicarlo, ni saber cuándo debo hacerlo. Se me ocurren pocos casos en los que este tipo de pruebas sirvan para algo, la verdad.
Por fortuna, este tipo de pruebas tipo test no son las más habituales en el sector. Lo más habitual son las pruebas más prácticas en las que te solicitan montar desde cero un proyecto que cumpla ciertas características. Es cierto que estos ejercicios apenas dan trabajo al reclutador más allá del diseño del mismo, pero también le exigen mucho tiempo al candidato y un gran porcentaje del trabajo que pasa, no aporta nada de información. Se pasará la mayor parte del tiempo haciendo trabajo de configuración del entorno (nos puede dar algo de información acerca de su desempeño en esta tarea, pero no suele ser el objetivo de la prueba), creando el proyecto (generalmente no lo va a hacer en su día a día del trabajo), creando clases, entidades, formularios y otros artefactos simplemente para hacer funcionar el proyecto, creando un diseño e interfaz desde cero (cuando lo que más tendrá que hacer diariamente será crear nuevas pantallas con unas reglas de diseño ya establecidas), vistiéndola con sistemas de login, logout, menús, sesiones, tests, etc. Con todo este trabajo de “picar piedra” apenas le quedarán fuerzas (ni ganas) de demostrar la calidad de su código. Tampoco nos deja margen como reclutadores para pedirle cosas más específicas o concretas si no queremos que le dedique 20 horas a la prueba técnica. En mi opinión, no tiene ningún sentido.
Optimizar el esfuerzo del candidato
A mi modo de ver, una buena prueba técnica debe partir del máximo respeto al tiempo y el esfuerzo del candidato. Teniendo esto en cuenta, las pruebas técnicas que diseño siempre parten de un proyecto de base. Un proyecto pequeño pero tecnológicamente similar al proyecto al que se va a incorporar el candidato. En base a este proyecto, le pediré que realice diferentes tareas en función de las aptitudes que quiera evaluar. ¡Oh no! ¡Tendrá un código de referencia en el que basarse para copiar y pegar! Evidentemente. Bienvenido al sector del desarrollo en el mundo real. Así será su día a día cuando se incorpore y más le vale dominar el arte del copy-paste si quiere triunfar en el puesto.
¡Oh no! ¡Tendrá un código de referencia en el que basarse para copiar y pegar! Evidentemente. Bienvenido al sector del desarrollo en el mundo real.
Partir de un proyecto de base, nos permite pedirle al candidato tareas más específicas, ya que irá mucho más rápido y le requerirá menos esfuerzo llegar a este punto. Además, y este posiblemente sea el punto más importante de todo este análisis, nos permitirá personalizar la prueba técnica en función del candidato.
Prueba personalizada
¿Prueba técnica personalizada por candidato? Pues sí. No por puesto. No por nivel. Por candidato. Y esto lo hago después de pedirle al candidato que me envíe repositorios de código de proyectos tecnológicamente parecidos al nuestro. Reviso esos repositorios e intento evaluar ciertas competencias para excluirlas de la prueba técnica. ¿Es un proyecto simple pero ha sido capaz de trabajar correctamente con las entidades y las relaciones? Pues le quito la tarea de crear nuevas entidades y relaciones ¿Me quedan dudas? Se la mantengo.
Conviene tener en cuenta la situación personal y profesional del candidato. No podemos pedirle lo mismo a una persona que se encuentra desempleada y con todo el tiempo a disposición de dedicarse a la prueba, como a un trabajador en activo con exigencias familiares que tendrá que robarle horas al sueño para poder demostrarnos sus capacidades. Ni debemos presentarles la misma prueba, ni debemos evaluarlos igual. En estos casos podemos jugar con los tiempos de entrega y con el alcance de la prueba.
Llegados a este punto te puedes encontrar con varias situaciones a la hora de personalizar estas pruebas. Una de ellas es la de candidatos junior a los que apenas puedes quitarles tareas. Estos candidatos tendrán que hacer pruebas técnicas más largas y “guiadas”. Como compensación al esfuerzo extra siempre intento acompañarlos en el proceso y sobre todo, darles un feedback al terminar, sea positivo o negativo el resultado de la prueba. Que el esfuerzo que han hecho les valga la pena.
Otra de las situaciones habituales es cuando buscas a un desarrollador más senior. En estos casos, podrás evaluar muchas de sus aptitudes en los proyectos que te haya enviado de muestra y podrás prescindir de más tareas en la prueba técnica. Esto nos permite proponerle tareas más abiertas para que sea él mismo el que decida la resolución de una necesidad dentro del proyecto de prueba. Un lienzo en blanco para que nos deslumbre con su desempeño. También me gusta en estos casos señalarle una parte de la aplicación y pedirle que la refactorice, o ponerme un poco travieso y colocarle un bug incómodo dentro del código. ¿Qué porcentaje de nuestro tiempo como desarrolladores dedicamos a investigar bugs misteriosos? Pues es interesante saber cómo se maneja en estas situaciones.
¿Qué porcentaje de nuestro tiempo como desarrolladores dedicamos a investigar bugs misteriosos? Pues es interesante saber cómo se maneja en estas situaciones.
En los casos intermedios, toca afinar el trabajo, analizar bien al candidato y proponer una prueba con la que nos sintamos seguros de que nos va a dar la información que necesitamos y con la que no nos tenga que dedicar tres jornadas de su vida.
Acompañar, asistir y dar feedback
Siempre siempre siempre acompaño al candidato en la primera hora de su prueba técnica. Para echarle una mano para configurar el entorno y el proyecto y ayudarle a tener todo funcionando en el menor tiempo posible. También para explicarle en qué consiste la prueba técnica, resolver dudas y matizar los criterios que seguiré para evaluarla. Y siendo sinceros, también me vale para que me comparta pantalla y ver cómo se desenvuelve en directo. Esta primera hora de la prueba técnica te puede dar tanta información como todo el código que pique después.
Por supuesto también le ofrezco asistencia en caso de que encuentre algún tipo de bloqueo. No me interesa que esté dos horas bloqueado por un tecnicismo del framework o por un error que yo mismo le puedo resolver en un minuto. Me interesa saber si es capaz de resolver los problemas que le surjan, pero un dato muy valioso también puede ser descubrir si en el día a día va a saber transmitirme sus dudas y si nos vamos a entender.
Por último, es algo obligado darle feedback al candidato. Más allá del feedback técnico que les pueda ayudar a mejorar como programadores, hayan superado o no la prueba, en los casos negativos siempre les indico cuales han sido los criterios por los cuales no han sido seleccionados. Siempre con tacto y con respeto. Buscamos un perfil más senior. Tenemos otro candidato que se ajusta mejor a nivel técnico a los requisitos del puesto. Hay mil formas de decirlo de forma que el candidato pueda recibir constructivamente esa información y utilizarla para mejorar sus competencias profesionales.
Esta es nuestra forma de plantear pruebas técnicas. Estoy seguro de que aún hay mucho que mejorar en este proceso, pero si algo creo que nos diferencia mucho del 99% de las empresas es el respeto por el candidato, y creo fehacientemente que una empresa que cuida a los candidatos es una empresa que terminará cuidando a los empleados.