Después de más de 20 años en la industria tecnológica, he pasado por muchas entrevistas, en ambos lados de la mesa. He sido entrevistado y he entrevistado. Y desde que empecé a entrevistar, me di cuenta de lo mal que está el tema. Voy a intentar en este artículo explicar qué creo que está mal y qué he hecho yo personalmente para intentar mejorar el proceso, por si a alguien le ayuda.

Si has leído mi artículo El muro de la entrevista técnica, tendrás un poco de contexto respecto a lo que opino de las entrevistas como candidato. Resumiendo, si no lo has leído, creo que muchas veces el encargado de validar técnicamente a un candidato tiene visión de túnel, y se centra en el resultado de un test sin tener en cuenta nada más.

En mi opinión, es totalmente acertado tratar a un desarrollador como a un desconocido que tiene que demostrar sus conocimientos. Pero tampoco podemos arrugar el curriculum y lanzarlo a la papelera, juzgando toda su carrera y experiencia en una hora de entrevista y/o prueba técnica. Creo que hay que leerse el curriculum completo, detectar una trayectoria, una motivación y una actitud. Hay que tener en cuenta todo lo aprendido anteriormente, y la capacidad de adaptación. Si una persona ha hecho exactamente lo mismo durante toda su vida, si no ha salido de su área de confort, si no ha aprendido nada más que aquello que “le ha funcionado”, esto podría indicar que la persona es un tanto rígida, incluso cómoda. Si queremos a alguien con capacidad de aprendizaje y curiosidad, este curriculum ya nos estaría diciendo mucho. Si recibimos a alguien con experiencias variadas, que demuestran una evolución y un aprendizaje, incluyendo una especialización en un área, también tenemos un mensaje muy interesante y es esto en lo que nos tenemos que basar para decidir.

Lo que quiero decir es: no sirve un guión único para entrevistar a personas distintas, y la foto fija de lo que escuchamos en una hora es una visión muy sesgada de la persona a la que entrevistamos.

Llegado el momento de validar a alguien técnicamente, tenemos que tratar esa prueba técnica como lo que es: una fase desagradable del proceso de selección. Un momento… ¿por qué desagradable? Pues porque los programadores hemos tenido que sentarnos delante de EGOS con una visión única de cómo se hacen las cosas, o de programadores demasiado ocupados como para mostrar empatía alguna. Nos plantan un test copy & paste y, muchas veces sin siquiera saber cuáles son las condiciones del puesto de trabajo, tenemos que impresionar a esa persona. Además hoy en día muchos, muchos programadores tienen opiniones muy fuertes y arraigadas, y lo peor, distintas, de cómo implementar una solución. Y lo que no encaja en su cuadriculada visión, no sirve. Una cosa son las personas que se fijan en las buenas prácticas y los “antipatterns”, y otro tema son los opinionated developers. En mi humilde opinión, en las entrevistas técnicas abunda más lo segundo.

Por no mencionar, por ejemplo, ese puesto de Front-End developer que tiene como prueba técnica un algoritmo en Node.js para realizar una búsqueda binaria o buscar la forma más óptima de recorrer un árbol de nodos. O los que exigen TDD sí o sí. Unos piden cosas irrelevantes al puesto (sobre todo los que te piden que lo hagas en una pizarra o en papel). Otros asumen que su forma de hacer las cosas es la única, y de paso asumen que el candidato no podría aprender una nueva metodología. No hay peor arrogancia que descartar a un programador porque no tiene experiencia con nuevas metodologías, librerías o frameworks.

Sobre todo porque seguramente la persona que decide descartar aprendió eso mismo hace dos días.

Todos podemos aprender, y no hay que darle la patada a una persona que no ha tenido la oportunidad de aplicar algo en proyectos reales. Vale, también está el caso de ese candidato que no tiene ni idea de un concepto que debería al menos conocer. Pero todos sabemos que por muchos blogs que leamos, y por muchos podcasts que escuchemos, si no trabajamos con algo en proyectos de verdad, en nuestro puesto de trabajo, no llegaremos nunca al nivel de quien sí lo hace.

Como Team Lead en el pasado, fiché a gente en contra del criterio de mis Seniors. Vi el potencial, vi la actitud, sabía que si les daba la oportunidad, al menos iban a poner todo de su parte para cubrir los huecos de conocimiento. Y sabéis qué? Solo una vez me equivoqué, y fue porque dejé que la amistad con esa persona nublara mi filtro. Era mi amigo y asumí que se pondría las pilas por mí, pero no fue así. Pero son lecciones que ayudan, lo importante es no perder la fé en las personas, y sin caer en el buenismo, de verdad poner voluntad en centrarse en lo bueno de alguien, no en sus fallos. Las carencias son una cosa universal: todos las tenemos o las hemos tenido. Y todos, cuando nos han dado la oportunidad, hemos trabajado para mejorar. Yo creo que muchas veces no hay candidato malo sino entrevistador obtuso.

Como Technical Lead en la actualidad, dejo que Recursos Humanos haga su trabajo, su pre-filtro, que todavía es muy necesario. Y luego recibo a esas personas que aspiran al puesto, y me fijo en todo. Pero sobre todo, les doy la oportunidad de darle a la empresa lo que necesita: un buen profesional que lo dará todo en su puesto de trabajo.

Si quieres que te ayude a validar tus candidatos, no dudes en ponerte en contacto conmigo.