Pruebas técnicas en un proceso de selección
Recruitment as a Passion #10 -
No vengo a plantear si una prueba técnica es necesaria o no durante un proceso de selección para un perfil técnico, si no quiero que hablemos del COMO.
Creo que comprobar el nivel técnico antes de contratar a una persona es siempre necesario, de una u otra manera deberemos comprobar que lo que la persona dice saber es cierto, o no. Esto es algo aplicable a cualquier sector, no solo al tecnológico.
En la industria tecnológica y más en concreto en la del desarrollo de software existe un grandísimo debate al respecto. Gran parte de la comunidad esta cansada de hacer pruebas para cada uno de los procesos de selección en los que participa, algunos incluso se niegan a participar del proceso si tienen que realizar una prueba técnica más. Otra gran parte, la realiza, invierte tiempo y se lo toma como un aprendizaje que le vendrá bien para su carrera profesional. Esta claro que todo el mundo tiene su opinión formada al respecto, pero, ¿existe un tipo de prueba que satisfaga a todos los "bandos"? Yo al menos no tengo la respuesta pero sé cual es para mi la prueba "perfecta" pero es solo mi opinión (si aguantas hasta el final, te contaré cual es).
Una cosa esta clara y es que toda prueba, debería cumplir unos mínimos:
Una prueba, siempre tiene que ser respetuosa con la persona que la realice. Obvio, ¿verdad?
Que sea ajustada en el tiempo. Tengamos en cuenta que la persona que la realiza, lo hará en su tiempo personal.
Ser clara. Es decir, que siempre vaya acompañada de una buena explicación de qué se debe hacer, que mínimos tiene que cumplir y que sería estupendo encontrar a la hora de corregir la prueba.
Es bueno dejar espacio para la creatividad, es más, en ocasiones se busca dejar ese espacio a las personas que la resuelva, pero de ser así, debe estar claro en el enunciado.
Asegurar que valida las capacidades que estás pidiendo para el puesto ofertado.
Si tienes una prueba exigente, que cuando se incorpore a la empresa tenga el mismo reto intelectual en su día a día. No hay nada mas frustrante que te pidan saber mandar un satélite a la luna, para luego estar haciendo un trabajo rutinario.
Una vez realizada la prueba, se debería dar tiempo a la persona para defender la solución aportada con parte del equipo técnico. Escuchar los motivos por los que realizo la prueba de una forma u otra.
Ser respetuoso con quien realiza el reto y escuchar los motivos por los que realizo la prueba de una u otra forma.
La persona o personas que revisen la prueba, deberían todos haber realizado la prueba con anterioridad.
Una prueba de código, en mi opinión, debería ser sobre lo que girase una conversación con las personas que han corregido la prueba. Un punto de partida.
Todo esto lo resumí en un hilo de Twitter que lance la semana pasada y que considero que esta bien darle continuidad y terminad de dar mi opinión al respecto.
Esto no son más que buenas prácticas a la hora de diseñar una prueba técnica, una serie de mínimos que se deberían cumplir, al menos desde mi punto de vista. Pero, existen muchas formas de validar los conocimientos técnicos de una persona, unos más acertados, otros que a mí, me cuesta ver con buenos ojos.
Una prueba técnica corta, sin limite de tiempo, pero que se pueda resolver en 2 o 3 horas. Una Kata, dejando a la elección del consumidor el lenguaje de programación para resolverla. Con criterio y que busque identificar una serie de conocimientos.
Una prueba técnica larga, exhaustiva, que requiera una dedicación importante. Algún compañero de la comunidad, me ha llegado a comentar que ha tenido que estudiar para hacer alguna prueba. Solo se suelen ver en empresas donde la gente "desee" trabajar y estén dispuestos a invertir el esfuerzo para conseguir ese sueño. También tenemos que tener en cuenta, que para las pruebas de selección de ciertas empresas como pueden ser Amazon, Microsoft, Spotify, Facebook y Atlassian entre otras, si no te preparas las entrevistas, pocas opciones tienes.
Pruebas de live coding con alguna herramienta con la que te monitorizan. Suelen ser con un tiempo fijado y en la que alguien de la empresa, estará presenciando como codificas. A mí esta modalidad no me gusta, puesto que no genera un ambiente en el que la persona pueda mostrar toda su capacidad. Genera ansiedad y nerviosismo, algo que no solemos tener a la hora de trabajar... espero.
Muchos técnicos tenemos proyectos personales, código propio del que estemos orgullosos y podamos mostrar a la empresa que oferta el empleo. Yo creo que con ese código y una conversación técnica acerca de cómo se ha desarrollado, puede ser más que suficiente para validar los conocimiento de la persona. Ventaja; no requiere de una inversión en concreto para el proceso.
Hace poco, descubrí la que ha sido hasta el momento una de las mejores pruebas que he visto. La persona que estaba haciendo el proceso de selección no tenía que invertir tiempo en codificar. Se trataba de una entrevista con dos personas del equipo de desarrollo, las cuales mostraban código real de la empresa y pedían a la persona entrevistada que pensara como añadir una funcionalidad nueva al código. No era un live coding donde la persona se sentiría observada, si no un trabajo colaborativo con gente que si todo iba bien, serian compañeros de trabajo. Es decir, lo más parecido al día a día de un equipo de desarrollo. De esta forma, puedes validar conocimientos técnicos, capacidad de comunicar y escuchar, trabajo en equipo... muchos factores los cuales harán de la persona un buen compañero de batallas. Pero eso no es todo, no solo la empresa tiene que validar a la persona, si no que la persona también tiene que tener claro que es el sitio donde quiere trabajar. Durante la entrevista, se vera cual es la base de código con la que trabajará dicha persona y podrá hacer pair programming con los que serian sus compañeros... un ejercicio de transparencia llevado a una entrevista técnica.
En definitiva, lo importante no es si un proceso de selección tiene o no tiene prueba técnica, si no de COMO sea esta. Debemos de buscar la forma que sea ventajosa para ambas partes, empresa y persona entrevistada.