Tips de storytelling para entrevistas técnicas

Puedes leer este post en inglés aquí.

A los humanos nos encantan las historias. Nos encanta contarlas y nos encanta leerlas, escucharlas y verlas. Más allá del entretenimiento, las historias nos han permitido colaborar y construir el mundo en el que vivimos hoy. Sapiens de Yuval Noah Harari habla en profundidad sobre esto.

Como las las historias son tan importantes, parece que no hay mejor forma de explorar la mente humana. Me gustaría compartir cómo hago yo las entrevistas técnicas y enfatizar la importancia del storytelling. Supongo que estos consejos también se pueden aplicar a entrevistas para Product Managers, Product Designers, etc.

Puedes suscribirte a mi newsletter With a grain of salt y recibir un email con novedades cada cierto tiempo.

Tu quieres que los candidatos a los que entrevistas te cuenten una buena historia. La verdad es que la mayoría de las veces, no lo harán. A menos que hayan investigado mucho, los candidato no conocen qué le gusta a su audiencia. En este caso, tu. Van a necesitar que les guíes y el primer paso es que conozcan a su audiencia.

La audiencia

Presentarte demuestra que te preocupas lo suficiente por los candidatos como para hacerles saber con quién van a pasar la próxima hora. La forma en la que te presentes establecerá el tono de la historia.

Soy David. Soy Ingeniero de Software de Producto. Después de sobrevivir a muchas startups en Madrid, me mudé a Valencia. El sol, la playa, la ciudad, la gente y la comunidad tecnológica y startupil me trajeron aquí. Hace unos meses, Creditas me adoptó para mejorar las cosas que supuestamente se me dan bien: android, backend, liderar equipos y hacer preguntas incómodas a los Product Managers.

Este no es tu CV, por lo que no te tiene que tomar más de un minuto. Prepáratelo de antemano si es necesario. No improvises. Enfócate en lo que realmente importa y sé cercano; sé real. Pocos narradores, ya sean escritores, guionistas o directores de cine, han tenido éxito sin ser reales. Sin ser honestos. Menciona lo que te gusta, lo que es importante para ti, lo que te impulsa y lo que te motivó a estar donde estás. No des demasiados detalles sobre tu experiencia técnica. La mayoría de las veces, son irrelevantes para la historia que los candidatos te van a contar.

Worldbuilding

Cualquier equipo de Ingeniería de Producto que se considere ágil, acaba, en algún momento, con algunas tareas por hacer. A veces es una tarjeta en un tablero de JIRA; o simplemente un post-it en una pared; o incluso un mensaje en Slack de tu Product Manager que dice que una tarea es urgente. Auqnue esperemos que no… Es un viaje muy largo hasta que una feature está en una máquina en el vasto Internet y alguien la está usando. Me gustaría que me llevaras de la mano y recorramos juntos el viaje de una feature. Desde tarea a producción.

Empieza la historia por donde creas necesario, y da un resumen de lo que ha pasó anteriormente. Estás construyendo un mundo frente a los candidatos. Este mundo tiene reglas que deben respetarse. Tiene personajes que tienen ciertas habilidades y responsabilidades. Tiene una historia que debe tenerse en cuenta y tiene momento: una fuerza que hace que la historia avance en cierta dirección. Menciona todo lo que consideres relevante para la historia.

El ritmo

Tienes una tarea por hacer. Tal vez, lo primero que hagas, será acertcarte a una pizzarra junto a un compañero. ¿Cómo empiezas?

El tempo de una historia afecta mucho a cómo se interpretan los eventos. Cada latido es una oportunidad para profundizar en un tema tanto como los candidatos deseen. El ritmo revela lo que es importante para ellos.

Has pasado un tiempo en la pizarra explorando diferentes soluciones y parece que ya lo tenéis claro. Luego os sentáis frente a un teclado y un monitor preparados para hacer pair programming. ¿Cómo hecéis eso?

Tu eres el guía. Y como guí debes tratar de mantener un ritmo constante. Acelera o desacelera tan lento como sea necesario para que el candidato tenga tiempo de adaptarse.

Ramas

La tarea está acabada. ¿O quizá no? Bueno, sabemos que al menos la feature está programada. Pero ese código no puede quedarse en nuestra máquina para siempre. Es inútil, ya que no aporta ningún valor al usuario.

Piensa en cualquier historia como un árbol. Comienzas desde la raíz y navegas hacia arriba. Hay mil caminos posibles. Cuando los candidatos completen la historia, solo habrán explorado uno. La historia siempre empuja la línea temporal hacia delante. Los flashbacks o saltos entre ramas no son una buena idea porque añaden confusión y fatiga mental. No hagas preguntas que no tengan relación entre sí. Dales una transición y deja que los candidatos exploren el camino que quieran.

Antes de llevar ese código a producción, tal vez deberíamos invitar a alguien a revisarlo.

A veces quieres que el candidato explore algo específico. Por ejemplo estrategias de testing “outsinde in o inside out”. Vas a obligar al candidato a ir a lugares a los que no tenía intención de ir. Esa es una rama forzada. Eso está bien si vas construyendo la historia hacia allí y vas conduciendo a los candidatos en esa dirección. Tienes que mantener el impulso que la historia ya tiene y aprovecharlo. Observa cómo los candidatos manejan la situación, cómo salen de ella y cómo improvisan.

Transiciones y giros de guión

Ya casi hemos acabado. El código se revisa y la feature se prueba en un entorno de staging. Ahora es el momento de desplegar a producción. Y queremos hacerlo sin problemas y sin fricción. Es bueno que ya tengamos establecido una pipeline sólido de CI/CD, que lleve nuestro código a través de diferentes pasos. Tengo mucha curiosidad por saber cómo funciona todo eso.

Las transiciones ayudan a que la historia avance en cierta dirección. La mayoría de los candidatos no saben cómo se supone que tiene que avanzar la historia y qué lugares necesitan explorar. Las transiciones no deberían ser drásticas. Avanzan la historia poquito a poquito. Esto les da a los candidatos tiempo para adaptarse y estar preparados para construir la historia hacia delante.

Cuando desplegamos a producción, esperamos que todo vaya bien. Y esta vez parece que todo ha ido bien. Sin embargo, al día siguiente, el Product Manager nos dice que hay un error en la feature que implementamos. Eso es sorprendente pero no inesperado. ¿Cómo buscamos ese error? ¿Qué herramientas necesitamos?

Por otro lado, los giros de guión o plot twists ponen a los candidatos en una situación completamente nueva. Estos giros de trama no cambian el contexto por completo. Se basan en el contexto que los candidatos ya tienen, pero no aprovechan al máximo el momento de la historia. Algo inesperado pero familiar ha sucedido. Los plot twists existen porque quieres crear un conflicto. Una historia no es interesante sin conflicto. Deja que el candidato explore eso.

Sabemos que los productos no son estáticos, evolucionan… Se supone que el software cambia. Si no fuera así, debería ser hardware. Necesitamos ser lo más ágiles posible trabajando en pequeñas iteraciones para asegurarnos de que lo que hacemos realmente agrega valor. Desde una perspectiva de Ingeniería, la configuración más simple para un producto digital es tener un cliente front-end y un back-end que sirve una API REST. A medida que nuestro producto evoluciona, nuestra API también evolucionará. Hablemos sobre qué cosas deben tenerse en cuenta cuando evolucionamos nuestra API de una manera tan iterativa.

Las historias son continuas. Los eventos no suceden sin motivo. Todo tiene una causa. Conocemos y entendemos las razones detrás de ellos y podemos responder de manera adecuada y proporcional. Las transiciones necesitan dar suficiente contexto para entender por qué está pasando algo. Solo entonces, el candidato podrá responder de manera apropiada. Tu quieres que los candidatos entiendan lo que estás preguntando. Si la rama que deseas explorar abre un mundo completamente nuevo, la transición debe ser mucho más rica.

Niveles de abstracción

Después de muchas iteraciones, parece que nuestro producto tiene mucho más éxito de lo que esprábamos. La carga de nuestros servicios aumenta día a día y estamos empezando a ver picos de tráfico. ¿Qué debemos de tener en cuenta y qué debemos hacer en este momento?

La historia comienza a muy bajo nivel. Todo muy especifico. A medida que avanza la entrevista y se desarrolla la historia, aumenta la fatiga mental. Es una buena idea pasar de temas específicos a más abstractos. Hacia el final solo deberían tratarse conceptos abstractos, ideas o conclusiones.

Wrapping up

Por desgracia, no tienes tiempo para explorarlo todo. Pero cuando la historia haya acabado, deberías entender no solo algo de lo que los candidatos conocen, sino que también deberías haber conectado con ellos a cierto nivel. Las historias, las buenas historias, nos hacen desear más. Si ese deseo está presente, entonces tienes la respuesta que has estado buscando durante toda esta hora.

Una forma más humana de conducir entrevistas.

Muchas gracias a undraw.co por las ilustraciones. Puedes suscribirte a mi newsletter With a grain of salt y recibir un email con novedades cada cierto tiempo.