Hace tiempo que quiero escribir sobre las entrevistas técnicas, pero después de un par de experiencias recientes, me he decidido a hacerlo ya. Este artículo va dirigido a programadores en busca de trabajo, pero sobre todo es un mensaje para programadores que participan en procesos de selección, decidiendo quién entra y quién no en una empresa. Para quien no lo sepa, la vida del programador es una vida privilegiada. No falta trabajo, está generalmente bien pagado, y además cada vez es más habitual que incluso nos dejen trabajar en remoto. Una libertad que pocas profesiones tienen a su alcance, la gran mayoría requiere plantarse físicamente en el mismo lugar, cada día de lunes a viernes, con un horario cerrado. Nosotros los programadores podemos optar a trabajar desde cualquier sitio y administrando nuestro tiempo, con un criterio que se reduce a “terminar mis tareas a tiempo”. Todo esto suena muy bien y realmente me siento feliz porque las cosas son así para mi y mis colegas. Pero no todo es felicidad, obviamente hay puntos oscuros en nuestro sector. Muchas veces hay horas extras no remuneradas, managers que no tienen ni idea de tecnología (cada vez menos, afortunadamente), ambientes de rivalidad tóxica, temporadas de presión y de no quitar la vista de una pantalla durante días, semanas e incluso meses… Son cosas que podría decirse que en cierto modo están presentes en otros sectores, pero en el nuestro es bastante común. Ahora, ya entrando en el tema que nos ocupa, voy a hablar del punto más negro, en mi opinión. Esto es, la velocidad con la que cambian las tecnologías, las modas, y con ello, el miedo constante a quedarse obsoleto y a las pruebas de selección cada vez más duras.

Programador que buscas trabajo

Si estás buscando cambiar de trabajo, o estás desempleado y estás intentando entrar en una empresa, habrás sentido un pequeño escalofrío al leer el párrafo anterior. Pongámonos en la situación del programador más habitual: llevas mucho tiempo en una empresa, trabajando para uno o dos proyectos o desarrollando producto. El equipo al que perteneces ha decidido usar una tecnología, bien porque se adapta al proyecto, o simplemente porque es “lo que todo el mundo está haciendo”. O sea, una de esas modas pasajeras. Angular, React, Vue… También puede que hayas entrado en la empresa y lleven tiempo usando esa tecnología, o incluso un framework propio. El caso es que estás ahí, haciendo tu trabajo lo mejor posible, con un ojo en las nuevas tendencias, leyendo artículos técnicos, haciendo algún tutorial, y siempre comparando lo que tú y tu equipo hace con posibles alternativas. Aprendiendo siempre, cada día, mejorando, intentando crecer y aportar valor. Pero el mundo fuera de tu trabajo cambia más rápido. Salen nuevas librerías y frameworks. Cientos, miles de artículos en Medium, LinkedIn, blogs de rockstar developers y otras populares plataformas bombardean Internet con opiniones y guías de “buenas prácticas”. Los requerimientos de estas nuevas tecnologías y la cantidad de herramientas alrededor de ellas crecen cada día. Ahora el programador de Javascript tiene que ser un experto en unit testing, end to end testing, docker, programación funcional (en especial inmutabilidad, paradigmas más populares, etc). Además, saber CSS o SASS/LESS ya no basta, ahora también CSS en JS. También temas de testing se hacen cada vez más complejos, llega el unit testing al UI, el Test Driven Development, e2e, con sus correspondientes librerías y herramientas: mocha, webdriver, selenium, jest… Mientras, tú, en tu empresa, no usas nada de eso. Por mil motivos. Te pueden llamar poderosamente la atención, pero no consigues introducir esas tecnologías y formas de trabajar en tu día a día. Antes, esto era una simple queja: me gustaría hacer todo eso porque suena divertido y además seguro que al final redunda en más calidad y menos bugs. O sea, reducir frustraciones para ti y para tu equipo, a costa de invertir un tiempo en aprender a controlar ese creciente nuevo ecosistema. Bueno, hoy en día ya no miramos a otras empresas que hacen todo lo nuevo y mejor con simple envidia sana. Ahora miramos con miedo. ¿Por qué? Porque el día que queramos cambiar de trabajo, o que nos quedemos en el paro, iremos probablemente a parar a una de esas empresas y nos exigirán experiencia con todo eso que no hemos tocado. Lo hemos visto en tutoriales, hemos hecho algún experimento, pero no nos hemos peleado con ello en proyectos en la vida real. No hemos configurado desde cero un entorno que incluya ese inmenso manojo de distintas herramientas, integrándolas todas juntas de forma que satisfaga al sí experimentado programador. Ese experimentado programador que tuvo la suerte de poder aprender todo eso trabajando, en un proyecto real, y apoyado por un equipo entero. Quizá no fue suerte, quizá empujó lo suficiente para que esas tecnologías fueran adoptadas en su proyecto, en su empresa. Pero en todo caso no fue una guerra que libró él solo. Fue una decisión hecha en grupo, en equipo. Seguramente no fue fácil, no le vamos a quitar mérito. Pero ese mismo programador, que pasó por ese proceso, un día se encuentra en la posición de decidir si contratar o no a alguien que no tiene ni sus conocimientos ni su experiencia en lo que él/ella llama “buenas prácticas”. Ahora viene el mensaje para la persona en esta posición.

Programador que filtras candidatos

No me malinterpretes, toda empresa tiene absoluto derecho a decidir a quién contrata y lo que espera de un programador. Faltaría más. Quizá el equipo necesite a alguien productivo desde el primer día, y por tanto cuanto más conozca, mejor. El peligro viene cuando se generaliza el alto nivel de exigencia, cuando una persona que ha pasado por una situación de cambio y aprendizaje, patrocinado por su equipo y empresa, asume que otro programador no está a la altura por no haber tenido la misma oportunidad. Cuando se rechaza a un candidato que no sigue los últimos paradigmas, se le está diciendo a la persona rechazada: “no creo que seas capaz de aprender”. Porque en nuestro mundo, en programación, no es cuestión de saber o no saber, es cuestión de ser capaces o no de aprender. Y después de aprender, poner en práctica. Es bastante desolador enfrentarte a esta situación como candidato. Especialmente porque de repente, todo eso que nunca tuviste la oportunidad de hacer en un proyecto, lo tienes que aprender, tú solo, en tu casa, en tu tiempo libre, quitándole tiempo a ocio, pareja, hijos. Y tienes que aprenderlo bien, todo de golpe, ponerlo en un proyecto que sea capaz de convencer al experimentado programador que lo mirará fríamente. Y le encontrará defectos, porque su experiencia en proyectos reales, habrá depurado su técnica y será muy superior a la del candidato.

Evalua a la persona

Lo que estoy diciendo con este artículo no es que no filtremos a la gente y que dejemos pasar a todo el mundo. No. Las pruebas de selección tienen que ser exhaustivas, hay que comprobar que una persona de verdad podría encajar en un equipo a todos los niveles, técnico y personal. Pero no seamos obtusos. Y sobre todo, no veamos la paja en ojo ajeno ignorando la viga en en propio. No olvidemos nuestra propia trayectoria, hace unos meses sabíamos menos de lo que sabemos ahora, y hemos aprendido a veces por curiosidad, otras por mejorar, y hasta quizá para cumplir con nuevos requerimientos de nuestra empresa o del mercado en general. Yo, por hablar casos concretos que puedo poner como ejemplo, con total orgullo, he sido Lead Front-End Developer en una startup alemana que creció enormemente y hoy en día es una megaempresa. Allí, cuando entré, éramos 4 gatos en una habitación, y cuando me fui 3 años después, la empresa tenía más de 300 empleados en varias ciudades europeas. Como Team Lead, una de mis funciones era reclutar developers. Pasaban un primer filtro con Recursos Humanos, pero luego pasaban a mis manos. Les mandaba una prueba técnica y decidía si hacer una última entrevista con ellos o no. No voy a mentir, era un coñazo. Tenía que revisar un número creciente de pruebas, compaginando con mis tareas de desarrollo, muchas veces bajo mucha presión y deadlines estrictos. Pero lo hacía, y veía cada prueba como una persona ilusionada que había pasado parte de su tiempo en intentar mostrarme sus skills. Por aquel entonces era poco lo que demostrar. HTML, CSS y Javascript en forma de jQuery y ya. Nada de Gulp, Grunt, Webpack, ni frameworks, ni tests unitarios, nada. Había gente que se lo curraba, me enviaban proyectos con una estructura limpia, comentarios, código legible, y hasta reusable. La verdad que tenía que ser un auténtico desastre para descartarlo, por ejemplo todos los archivos en la misma carpeta, código duplicado, y en general  red flags comunes que hoy en día siguen vigentes. Era exigente, pero en caso de duda, cuando el código era solo “correcto” y nada en la prueba me impresionaba, aún generalmente seguía adelante con el proceso. Le daba a la persona la oportunidad de explicarme qué cosas mejoraría, y en general un poco que me contara cómo había llegado a producir el mini-proyecto. Me interesaba la persona. Muchas veces, en contra del criterio de mis superiores, recomendé contratar a ciertas personas. Vi en ellas voluntad real de aprender, de crecer. Vi  ilusión. Muchos programadores pueden saberlo todo sobre el último grito en desarrollo, pero hablas con ellos y  están quemados. Yo siempre me guié por el instinto para decidirme a apostar por alguien, y el principal era ese, la ilusión. Porque la ilusión y la voluntad llevan a la persona a querer seguir aprendiendo, a disfrutar de su trabajo, a querer ser mejor. Y todo ello es contagioso y aporta un valioso factor de frescura a un equipo. En caso de ser contratada, esa persona tendrá mucho que demostrar, y un periodo de prueba que superar, que para eso está. Tengo que decir, repito, con orgullo, que elegí bien. Hoy en día, gente por la que tuve que pelear para recibir el visto bueno, son los mejores profesionales con los que he tenido el placer de trabajar. Han crecido dentro de aquella empresa, o fuera de ella, ocupando puestos de Senior y de Lead Developers. No digo que sin mi no hubieran llegado a donde están, lo que digo es que sin mi y sin otras personas que deciden con mi mismo criterio, muchos grandes profesionales se quedarían fuera del mercado. Yo mismo tengo 17 años de experiencia y temo las entrevistas técnicas. Muchas veces, me tratan con frialdad, no valoran mi recorrido, mi capacidad de adaptación y de aprendizaje. Acepto esto como parte del sistema, y por supuesto eso no me detendrá. Pero me gustaría lanzar este mensaje ahí fuera, por si cae en manos de las personas que filtran candidatos. El mensaje es simple:

EVALUA A LA PERSONA.

La persona, entendida como un conjunto de habilidades: sus conocimientos, su actitud, su visión, su forma de expresarse. Contratar a un crack que luego es un inadaptado o que tiene ideas muy cerradas y se niega a salir de su  comfort zone, ¿de qué te sirve? Y a los que os encontráis buscando trabajo: no os desmoralicéis. Fallar en una entrevista o ser rechazados por un review negativo de una prueba técnica es una oportunidad para aprender. Sí, seguramente es más fácil hacerlo mientras cobras un sueldo y apoyado por un equipo, y no a solas en tu casa. Pero puedes hacerlo. Toma el feedback de esas entrevistas fallidas y úsalo para aprender, para mejorar. Busca opinión de amigos o profesionales del sector, crea un proyecto que sea tu sandbox de pruebas, y depúralo hasta que pase el más exigente de los tests. Alguien será capaz de ver ese progreso, esa actitud. Y te darán la oportunidad. No te rindas. Si te ha gustado este artículo, por favor comparte :) Y si tienes problemas para encontrar talento, te sugiero mi nuevo artículo,  Cómo encontrar buenos programadores