Las entrevistas técnicas son terribles
Pero ustedes también son bastante quejosos, digamos todo.
Sin Códigos es un espacio de reflexión sobre el mercado tecnológico y el impacto que la tecnología tiene en nuestras vidas. Lo escribe Bel Rey ✨ y sale una vez por semana ¡Suscribite y no te pierdas ninguna edición!
Hola nostálgicos de la internet ¿Cómo les va?
Se termina Octubre, mes del terror (si nos guiamos por los estándares estadounidenses) y aunque en este país no seamos de celebrar Halloween nos gusta disfrazarnos igual. El disfraz que me voy a poner hoy es de abogada del diablo ¿Saben por qué? Porque vamos a hablar sobre procesos de selección y si realmente están tan rotos como pensamos.
Vamos allá.
Esta semana me topé con este tweet:
No conozco al autor, y no pretendo hacer un juicio de valor sobre su queja ni meterme en la discusión twittera que quizás se armó (o no) bajo su post pero me parece interesante desmenuzar su mensaje e intentar entender que está pasando efectivamente con las entrevistas en tecnología.
Preludio
La conversación sobre si los procesos están rotos no me es ajena. En el pasado me quejé abiertamente de situaciones donde empresas me hicieron perder el tiempo en procesos larguísimos que podrían haber terminado mucho antes con solo invertir el orden de las entrevistas.
En mi experiencia, los procesos buscan medir tres termómetros en un candidato:
Capacidad técnica: Conocimientos y dominio de herramientas relacionadas al trabajo a realizar - idealmente acordes a las tareas esperadas y con complejidad ajustada al seniority.
Cultura: todo lo relacionado al empleado como persona que se desempeña en el contexto de una empresa, relación con sus compañeros, capacidad de trabajar en equipo, formas de comunicación. Muy suceptible a prejuicios del entrevistador.
Demás consideraciones: Entorno social del posible empleado, probabilidad de rotación / licencias, cualquier señal que indique descontento a corto y mediano plazo
Usualmente las entrevistas se dividen en pasos donde primero se hace un screening general para medir riesgos, después se procede a las entrevistas técnicas y finalmente se realizan las culturales.
En mi humilde opinión los procesos serían mucho más agradables tanto para candidatos y reclutadores si invertimos el orden. Screening > Cultura > Entrevistas técnicas. Es mucho más costoso para quién aplica y también para quien entrevista tener que pasar por todo el proceso de hacer / defender / evaluar una prueba técnica para tener que después descartar a un empleado en base a diferencias culturales. De hecho, voy un paso más allá y me atrevo a decir que se puede evaluar tranquilamente cultura midiendo desempeño en la defensa de un challenge técnico.
Para mi gusto los procesos de entrevista actuales son demasiado extensos e involucran a una cantidad de personas innecesarias que lo único que hacen es sumar sus prejuicios a una ronda de evaluaciones completamente subjetiva. En ese orden de las cosas me atrevo a decir que si, los procesos de entrevista están rotos.
Pero volviendo al punto del post original
¿Están rotas las pruebas técnicas para programadores?
Una práctica que se puso de moda en “big tech” como forma de screening técnico inicial es el uso de herramientas como leetcode o pruebas estandarizadas de conocimiento teórico para evaluar candidatos. La crítica más común a este tipo de pruebas es que no suelen estar relacionadas directamente con el trabajo a realizar en el puesto si uno es efectivamente contratado. Sus detractores critican su efectividad para medir conocimiento y también el hecho de que son más suceptibles a discriminar a ciertas minorías que historicamente performan peor en ese tipo de pruebas de stress.
Al margen de si estamos a favor o en contra de esta forma de evaluar, con ese tipo de evaluación se busca separar la paja del trigo: quieren personas con conocimiento teórico estandarizado, es decir, graduados de la universidad o con experiencia equivalente. ¿Querés trabajar con nosotros? Demostrá que estuviste expuesto a estos conceptos.
¿Cuál es el valor de poner un graduado universitario a pegarle a una API? Si una persona estudió para profesionalizarse en un campo y lo ponemos a realizar tareas relativamente “mundanas” nos generamos un problema a futuro: el riesgo de rotación. En pos de asegurarnos el “mejor” nivel técnico estamos abriendo otras vulnerabilidades en nuestro proceso de selección.
Ya en otras ediciones hablamos sobre la abstracción y los “expertos en herramientas” que buscan algunas empresas de la industria. Los procesos de selección deberían estar cuanto menos preparados para evaluar técnicamente el tipo de perfil que se pretende contratar.
Pero entre hacer por enésima vez un CRUD con la pokeapi y programar un tetris en treinta minutos hay una gran diferencia, entonces…
¿Un frontend debería poder programar un ajedrez?
O la otra cara de la pregunta ¿Debe un frontend simplemente dedicarse a hacer fetch a una API? ¿Qué crecimiento profesional le espera a la rama si la limitamos a maquetar y usar wrappers de código asíncrono? Con las lineas entre el front y el backend cada vez más desdibujadas y las herramientas que permiten automatizar nuestro trabajo quizás es momento de replantear el rol y devolverle un poco de la magia y el ingenio que parece reservado para las demás ramas de la programación.
Analicemos entonces, que clase de conocimientos requiere armar un tablero de ajedrez:
Para resolver el problema del tablero primero tenemos que poder analizar su complejidad. La forma en que planteamos el problema le puede dar al entrevistador información sobre nuestra formación en ciencias computacionales y las clasificaciones de problemas por dificultad.
Para la resolución del problema vamos a necesitar manejar diferentes conceptos
Estructuras de datos para armar y recorrer la matriz
Definir estructuras para cada pieza con sus reglas y características específicas
La habilidad para gestionar el estado del juego (como el turno, las piezas capturadas, el enroque, jaques, etc.) y la actualización de la posición de las piezas.
Al ser un problema complejo por la cantidad de combinatoria posible probablemente se busque conocimiento de algoritmos que permitan optimizar. Ya en este punto podemos hasta plantear algoritmos específicos de búsqueda, heurísticas y demás técnicas para optimizar complejidad.
Se me ocurren más items, pero la realidad es que esta prueba está pensada no para evaluar el uso de una herramienta en particular. Busca evaluar nuestro conocimiento en ciencias de la computación.
Problalemente no necesitamos saber todo eso para hacer una llamada a una API y renderizar datos pero ¿Y si el puesto exige más de nosotros? Lo rídicula o “rota” que nos parece una prueba tiene que ser medido contra las expectativas del puesto y no contra la generalidad de lo que creemos “debería saber un frontend”.
No tengo contexto sobre la búsqueda, el seniority esperado ni si la prueba es acorde o no al puesto. Lo que si me parece ridículo es la parte de sin buscar / sin ayudas porque realmente ¿Quién trabaja así? Se puede evaluar perfectamente lo que sabe una persona mirando cómo busca en google.
Pero si creo que tenemos que dejar de infantilizar el trabajo del frontend y tratarlo como si fuera el primo bobo de la programación, porque si dependemos exclusivamente de pegarle a APIs y mostrar datos lamento decirles que en seis meses v0 se va a quedar con todos nuestros trabajos.
¡Feliz viernes!
¿Me ayudás a crecer? ☕️
Si te gustó esta edición ayudame comentando o recomendalo con tus amigos <3
Regalame un Cafecito o sumate a un plan mensual
¡Nos vemos la semana que viene!