Recientemente estuve buscando trabajo y algunos de los procesos de selección tenían una sección llamada la entrevista técnica exhaustiva (o deep dive interview).
En la gran mayoría de casos, esta parte de la entrevista suele ir “dentro” de otra, o no se hace tan a fondo, pero en dos procesos en concreto la hora entera fue para dicha entrevista.
En este post, veremos sobre qué trata dicha entrevista .
Índice
1 - De qué trata la entrevista técnica exhaustiva
Muchos, como era mi caso hasta hace nada, no habrás tenido este tipo de entrevistas. Por lo menos no de forma individual dentro de un proceso de selección, sino que durante alguna de las entrevistas del proceso os habrán hecho preguntas sobre los proyectos que tocáis actualmente en la empresa y sus tecnologías. Al ser parte de una entrevista mayor, la gran parte de tecnologías se tocan por encima y ya está.
En este caso, esta entrevista es lo mismo, pero centrada exclusivamente en un unico proyecto real, durante una hora. Esta entrevista suele darse para puestos relativamente altos dentro de lo que sería desarrollo, puestos de Staff, principal o distinguished en empresas TOP como puede ser una FAANG o de similar nivel. Una empresa pequeña o que su producto principal no es software no te va a hacer una entrevista tan exhaustiva como esta.
Esto quiere decir que necesitas saber muy bien todos los puntos de la aplicación ya que vas a tener que analizar en detalle una aplicación o sistema donde hayas trabajado recientemente.
Algo muy importante de esta entrevista es que el proyecto donde hayas trabajado sea complejo. Ojo, no me refiero a que tenga sobre ingeniería, sino que el proceso en sí no sea un simple CRUD a la base de datos con cuatro eventos, sinó que tenga más chicha. Si el proceso es muy simple, fallaréis la entrevista, lo cual no me parece del todo justo, ya que es algo externo a nosotros.
Otro punto importante es que cuanto más impacto tenga en los clientes mejor. Porque como veremos más adelante, es una de las partes clave del proceso.
Técnicamente podríais mostrar un proyecto de hobby que hayáis realizado recientemente, pero personalmente no lo recomiendo, ya que en esta entrevista va a haber preguntas muy técnicas y sobre los problemas técnicos que sí es un proyecto de hobby quizá no los hayas visto o no hayas profundizado tanto.
2 - Prepararse para una entrevista técnica exhaustiva
La clave para pasar la entrevista deep dive es tener todo preparado de antemano y para ello me refiero a tener un documento con el proyecto que quieres destacar, este paso os puede servir tanto para la deep dive como para los procesos donde es parte de otra entrevista, aunque fuera de la deep dive no se hacen preguntas en profundidad al respecto.
Mi recomendación aquí es generar un fichero con cada proyecto que realices en la empresa, y personalmente es algo que nunca había pensado, pero tener toda la información en un fichero os puede servir también en el futuro, en 5 o 6 o incluso 10 años para recordar en que habéis trabajado y tenerlo documentado.
El fichero, que tendrá entre 2 y 4 páginas debemos tratar lo siguiente:
Describir el sistema y que lo hizo importante dentro de la empresa.
Aquí es donde debemos describir los problemas no técnicos a los que nos hemos enfrentado.
Puedes hacer un pequeño párrafo sobre qué es lo que hace la empresa donde trabajas y cómo ese proyecto encaja en el sistema actual.
Esta sección se centra más en el producto que en la parte técnica, ya que al final las empresas venden un producto y es importante como parte de la empresa entender dicho producto.
Implementación técnica.
Ahora sí, llega el momento de explicar el problema de forma técnica. Debemos incluir cuál ha sido nuestro rol, o como hemos sido parte del proceso. De qué partes del sistema hemos sido parte, esto es importante de mencionar ya que en muchos casos un sistema si es grande puede incluir varios equipos, y quizá tú no tengas visibilidad sobre lo que hacen dichos equipos. Esto también es importante para que así no te pregunten cosas sobre dichas partes del proceso, y si lo hacen y tu no sabes con exactitud lo que hacen, que no cuente de forma negativa.
Por poner un ejemplo, imaginémonos que hemos trabajado en un sistema de notificaciones dentro de nuestra empresa, similar al que vimos dentro del curso de diseño de sistemas .
Lo Ideal en este escenario es mencionar que hemos trabajado en esta parte del proceso, y si la hemos liderado por supuesto mencionarlo también. Quizá nos hagan alguna pregunta como cómo funciona, el sistema donde mandamos por ejemplo los emails, en nuestro caso es una aplicación de terceros, pero puede ser otro equipo de la empresa, tener una idea básica sobre el funcionamiento de estos sistemas es importante.
Yo recomiendo tener una imagen con un diagrama del sistema ya que siempre refresca la memoria mucho más.
Durante esta sección de la entrevista, mencionaras el proceso y porque es importante dentro de la empresa, pero además qué compromisos tuviste que tomar y por qué.
En este diagrama en particular hay varios, uno por ejemplo es porque nuestro sistema tiene eventos como punto de entrada y no una llamada HTTP, esa es una pregunta que muy posiblemente nos vayan a hacer.
Porque hemos decidido separar en múltiples colas en vez de utilizar una sola o incluso llamar directamente al servicio de terceros desde el consumidor.
Lo que el entrevistador busca encontrar en esta sección es comprender qué desafíos técnicos encontraste en el proceso. Así que lo ideal es tener preparado o documentado todos los desafíos o decisiones tomadas y por qué.
Otro ejemplo puede ser el uso de cierta tecnología en la nube, porque hemos elegido esa y no otra, cómo hacemos para escalar, que opciones tenemos y planes de futuro.
Lanzamiento
Cuando realizamos aplicaciones debemos hacerlas disponibles a nuestros clientes, para ello debemos tener un plan de lanzamiento. Debemos saber cual es el plan.
En mi experiencia personal hay varias opciones.
Hacer el MVP y desplegar eso a los clientes e ir iterando sobre las mejoras, o directamente publicar un sistema 100% completo.
Por volver al caso anterior del sistema de notificaciones, podemos tener un MVP que únicamente envía emails o podemos tener una aplicación completa que envia 10 tipos de notificaciones diferentes.
Otra opción común es lanzar la funcionalidad, ya sea el MVP o completa a un grupo de usuarios y de ahí ir aumentando la disponibilidad una vez sabemos y garantizamos que funciona como es esperado. Y por supuesto como está implementada dicha opción de forma técnica.
Normalmente, esta decisión no tiene nada que ver con la parte técnica, pero como miembros del equipo debemos saber el porqué de nuestra puesta en producción. Y por supuesto los planes a futuro. OJO hay sitios donde vas a tener un NDA o similares, no digas nada que pueda ser comprometido, pero no suele ser el caso.
Resultados
Debemos mencionar cómo evaluamos si el sistema es un éxito o no. Normalmente será dependiendo de su uso, aquí debemos mencionar las métricas que hacen o indican si nuestro sistema es un éxito. Para un sistema de notificaciones puede ser tan sencillo como que tenga uso, pero cada sistema dentro de una empresa va a tener métricas diferentes.
Tener una lista de métricas a evaluar junto a la explicación de por qué esa métrica es importante suele ser suficiente en estos casos.
Debemos tener en cuenta y mencionar el impacto en la organización o en los clientes. Por ejemplo, ¿es un nuevo producto? Ha generado ventas, eso es un resultado positivo para la organización, quizá incluir este sistema en un producto existente haya hecho ganar X número de clientes que estaban en un competidor.
Lecciones aprendidas
Debemos mencionar que hemos aprendido, tanto nosotros de forma personal como a nivel de empresa, que decisiones se tomaron inicialmente que luego cambiaron y por qué.
¿Ha habido alguna parte del proceso de la empresa que haya cambiado debido a este proyecto? Por ejemplo, la forma de hacer lanzamientos o incluso la forma de planificar los proyectos. Quizá anteriormente se hacía un desarrollo waterfall y con este proyecto ahora es más ágil.
¿Hemos tenido algún aprendizaje nosotros mismos? Quizá en este proyecto has tenido que trabajar con 4 o 5 equipos diferentes por primera vez en tu carrera así que de ahí seguro que has sacado aprendizaje.
Este aprendizaje también tiene que ver con la parte técnica, has tenido que aprender e implementar tecnologías que no conocías? Cómo te diste cuenta que te hacían falta, cómo las aprendiste y qué impacto han tenido.
Por supuesto si ha habido alguna lección de cara al usuario final, comenta el feedback de usuarios os hizo cambiar cierta parte del proceso también es importante.
Para este tipo de entrevistas tienes que tener en mente tanto a la empresa, a ti mismo como al cliente, todos los puntos son igual de importantes.
