Nonsense

De pruebas técnicas y entrevistas

Está de moda en muchos procesos de selección soltarte una prueba para que hagas en casa. Es además curioso observar que se repiten exactamente las mismas frases:

  • “Es una pequeña prueba”
  • “Para que la hagas tranquilamente”
  • “Te damos 5 días” (en alguna rara ocasión son 3 días, pero entonces suelen decir “72 horas”)
  • “Pero no es que tengas que dedicar los cinco días. Está pensado para que le dediques un par de horas cada tarde.”

No voy a hacer tu prueba

El jueves, mientras hacía una de estas pruebas, decidí que sería la última. No voy a volver a hacer ninguna prueba de este tipo, con esas condiciones. Si esto hace que pierda oportunidades interesantes, pues que así sea.

Puedo hacer pruebas en una pizarra, hacer pair programming durante un rato, hacer una prueba que lleve un máximo de 1 hora -especialmente si lo hacemos juntos-. Puedo hacer otro tipo de pruebas, pero no esas.

Trabajo aburrido y gratis

Hay dos problemas básicos con ese tipo de pruebas. El primero es el tiempo que requieren. El jueves hice un experimento y limité la prueba a 2 horas (luego cuento más detalle) pero si quieres hacer bien la prueba, realmente necesitas dedicarle esas 8 o 16 horas que pretenden que dediques. Los procesos de selección son bastante asimétricos. Estar el mercado en una buena situación para los programadores (“más o menos buena”, que tampoco creo que sea para tirar cohetes como algunos pretenden), alivia un poco esa asimetría. Requerir una dedicación de 8-16 horas por cada proceso de selección es una muestra de fuerza, un intento de mantener las cosas a favor de la empresa. Yo estoy en paro y tengo todo el tiempo del mundo, pero es mi tiempo 1). Trabajar dos jornadas gratis para hacer una prueba estúpida no es una buena inversión de mi tiempo. Y no lo es no porque sea gratis, sino porque es estúpida. Porque no aporta nada que no tenga ya hecho y puedas ver o nada que no pueda contestarte en un rato de entrevista o puedas ver en un rato de escribir código juntos.

Porque ese es el segundo problema básico: Las pruebas son, en el fondo, estúpidamente aburridas. Y no me refiero solo a que sean aburridas para mi, sino a que son desarrollos aburridos, sosos, sin ningún aspecto destacable o único. La del jueves era, con ligeras variaciones, implementar TodoMVC “con Vue.js o React”.

La funcionalidad básica incluía:

  • Montar el proyecto desde 0
  • Hacer una llamada a un servicio para obtener la lista de tareas
  • Presentar la lista
    • Marcar/desmarcar tareas
    • Añadir tareas
    • Eliminar tareas
  • Filtrar/Buscar en la lista de tareas

Si quieres hacer “bien” la prueba, lógicamente debes presentar una solución que incluya:

  • Un buen diseño de la aplicación en componentes bien organizados
  • Un diseño de la interfaz “responsive” y “atractivo”
  • Tests (así en general, no especificaba el tipo de tests, así que puedes entender test unitarios, de integración, end-to-end, o todos ellos)
  • “Comentarios y explicaciones” (esto no todos lo piden; y es bueno pedirlo pero algunos parece que no entienden que esto es más importante que todo lo demás)

Esto es un ejemplo bastante típico. He hecho diferentes pruebas de este tipo, pero aproximadamente la carga de trabajo es similar en todas ellas.

Hay dos formas de hacer esta prueba. Una es “un desarrollo real”. Planteando el diseño de la aplicación con sus componentes bien organizados (p.ej. tu Lista, Tarea, Filtro, Botón…), con sus tests unitarios y sus tests end-to-end, con tus tareas y tus commits bien organizados y referenciando esas tareas en sus buenos mensajes de commit, escribiendo anotaciones con las decisiones que vas haciendo, etc. Con un diseño gráfico bonito, probado en diferentes dispositivos (o por lo menos tamaños de pantalla, tampoco hay que pasarse). En resumen, “profesionalmente”. Pero el problema es que hacer de esto un desarrollo “profesional”, requiere, tirando por lo bajo, más de dos jornadas completas.

La otra forma es pisar el acelerador a fondo y a ver qué sale. Te coges el problema y, hala, a tirar adelante como sea. Lo primero que la gente sacrifica son los tests, porque, reconozcámoslo, se llevan una buena parte del tiempo. Algún listillo lo que hace es incluir un test true is true o “test hello world” como para decir “mira, si tuviera tiempo escribiría tests; sé hacerlo” 2). Otros sacrifican hacerlo “bonito” porque “no soy diseñador” o, al revés, como sí lo son, lo hacen precioso pero entonces sacrifican alguna funcionalidad. Pero sea lo que sea lo que se sacrifique, el resultado final (y no lo digo solo por mi, lo digo habiendo visto ejercicios de otra mucha gente) termina sacrificando siempre lo único que podría ser interesante: La explicación de la toma de decisiones, de por qué han elegido hacer esto de este modo o de ese otro. ¡Normal! ¡Si la mayoría ni siquiera se molesta en cambiar el readme automático que le genera el crate-react-app o vue init de turno!

Esta vez yo fui por un tercer camino. Puse un límite estricto de 2 horas y decidí resolver el problema de forma económica. Incluí Buefy/Bulma (el enunciado no decía nada en contra). Buefy tiene una estupenda tabla/lista que me resolvía prácticamente todos los problemas del proyecto. Y los que no, un par de componentes más lo completaron. Al final, incluso haciéndolo así, entre montar el proyecto, leerme documentación de Buefy y Bulma, y encajar las piececitas de LEGO unas con otras, reconozco que me pasé (un poco) de las dos horas.

En el fondo, aunque sé perfectamente cuál es el objetivo del ejercicio, ¿qué muestra mejor mi experiencia que la decisión de resolverlo de la forma más económica posible?

Objetivos y realidades

Pero claro, también hay que considerar cuál es el objetivo del ejercicio. Cuando me presentaron este prueba del jueves en la entrevista, la persona que me entrevistaba explicó la necesidad de la prueba:

Si no es con esta prueba, ¿cómo voy a poder evaluar si realmente sabes?

Bueno, te contestaría, pero entonces a lo mejor tendríamos que cambiarnos los papeles y que fuera yo quien evaluara si tú sabes hacer tu trabajo o no. En fin, en cualquier caso, el supuesto objetivo es evaluar. Asumimos que para evaluar si sabes, puedo mirar tu código y, sin más, obtener una apreciación fiable de lo que sabes.

El problema de esto es múltiple.

Por un lado, si el ejercicio planteado tuviera por lo menos algún tipo de… no ya dificultad, sino tuviera al menos algún tipo de peculiaridad, de aspectos únicos o destacables, quizá y solo quizá, podríamos apreciar ciertas habilidades en la forma de resolverlo. Pero es un ejercicio completamente genérico y banal. De hecho, el principal problema es su banalidad. Es tan banal que podemos encontrar en 5 minutos al menos una docena o dos de tutoriales, guías, repositorios, etc, que resuelven este mismo desarrollo en su totalidad o en más de un 95%.

Esto por supuesto abre la veda a la picaresca. Puede ser la primera vez en mi vida que hago un proyecto con Vue, pero seguir un tutorial, copiar el código y cambiar dos o tres cositas no parece impensable. Pero más importante aún: Dada la banalidad del proyecto, su total carencia de puntos peculiares, es francamente difícil discernir si realmente lo ha desarrollado el candidato o si es un corta-pega ilustrado. Es más, incluso obviando esa opción pícara, el resultado al que puedan llegar varios candidatos, dada la sosería del proyecto y las restricciones de usar el mismo framework, será bastante parecido. Las diferencias de decisiones tomadas con prisas difícilmente pueden servir para evaluar correctamente. Como mucho te podrían servir para evaluar si sabe seguir las costumbres de ese framework, y poco más. Ni siquiera si las entiende.

Una justificación frecuente es que todo esto que estoy diciendo aplica a candidatos con un nivel mínimo, pero que sí que sirve fácilmente para distinguir a estos de los que ni siquiera tienen ese nivel mínimo. Bien, esto puede ser un argumento admisible. Sin embargo, precisamente eso es lo que con seguridad más fácil es de evaluar con otro tipo de pruebas o preguntas mucho más precisas y que no requieren de los candidatos dedicar dos jornadas completas. Yo me ahorraría el tiempo, tú te ahorrarías el tiempo, todos saldríamos ganando si tú supieras cómo hacer bien una entrevista.

¿Sin framework?

Otro aspecto desagradable es uno que he visto en un par de ocasiones. Te plantean el ejercicio en términos generales, pero no te explican cómo lo van a evaluar o qué tipo de detalles valoran positivamente.

Así recuerdo una ocasión en la que recibí un enunciado que mencionaba el uso de frameworks y librerías y decía explícitamente:

( no restriction on this )

Este ejercicio era algo más pequeño en alcance. Así que opté (y lo expliqué en el README) por:

The application is small and I decided to keep it so avoiding using any frameworks or libraries on the client (about 100 lines total on the client). The client is just a single JS file. In other circumstances I would've set up a build system, but for 100 lines and such a small functionality it didn't seem worth it.

Esas “100 líneas” estaban modularizadas, eso sí. Cada cosa estaba separada e independiente del resto. La respuesta fue “No has usado ningún framework!”. Claro, porque habías puesto que no había restricciones.

La mayoría de las veces no es tan evidente como esto. Pero aún así, en muy pocas ocasiones se explica qué es lo que se va a valorar y cómo. ¿Vas a contar cuántos tests he escrito? ¿Vas a pasar un análisis de cobertura? ¿O quizá te vale con que escriba dos tests interesantes y representativos? ¿Vais de guays a tope con la última versión de Vue porque así se ve que estoy “al día”? ¿O pensáis que basar vuestro negocio en una versión beta de un producto es una imbecilidad como una casa? 3) ¿Es parte de ejercicio que yo adivine estas cosas? Porque si es eso, incluiré en mi currículo que no me dedico a adivinar intenciones en estúpidos jueguecitos de poder.

Y por último, cuando yo dedique mi fin de semana o mis cinco tardes a hacer tu ejercicio, ¿me vas a dar feedback? O te limitarás a “no se ajusta a nuestras expectativas” o a “lo ha mirado el equipo de desarrollo y no me ha dicho motivos; no te puedo decir más”.

Meh

Esto es lo que pienso de tus pruebas. Y por esto no voy a hacerlas. Tu prueba es mala, es estúpida, no sirve para lo que crees que sirve y no te va a dar buen resultado. Si sigues basando tu proceso en una prueba de este tipo, seguirás contratando gente mediocre y seguirás sin saber por qué.

1)
También he hecho alguna prueba así cuando no estaba en paro y claro, encima tienes que dedicar tu fin de semana o el tiempo de la tarde que tienes para cocinar, estar con tu familia, dormir o lo que sea
2)
que es perfectamente inútil, porque que sepas montar la infraestructura para escribir tests no tiene nada que ver con que sepas escribir un tests buenos y útiles
3)
Y ¿aplica esto también a un ejercicio?