Cómo explicar un proyecto tuyo cuando el entrevistador entra en detalle

Es tu proyecto. Escribiste la mayor parte del código, arreglaste el peor fallo a las dos de la mañana y lo conoces mejor que nadie en la sala. Por eso sorprende tanto que, cuando el entrevistador pregunta por qué la caché se invalida como se invalida, una respuesta que parecía evidente se venga abajo a mitad de frase.

Los psicólogos han medido ese desfase, y saber cómo funciona hace mucho más fácil prepararse.

Por qué cuesta explicar tu propio trabajo

En una serie de estudios muy conocida, Leonid Rozenblit y Frank Keil pidieron a estudiantes de posgrado de Yale que puntuaran, en una escala de siete puntos, lo bien que entendían aparatos cotidianos como una cremallera, una cisterna, una cerradura de cilindro y un helicóptero. A continuación, los estudiantes escribieron paso a paso cómo funcionaba cada uno y volvieron a puntuar su comprensión. Las puntuaciones bajaron. Bajaron aún más tras una pregunta de diagnóstico que exigía conocer de verdad el mecanismo, como cómo forzarías una cerradura de cilindro. Al final leyeron la explicación de un experto y volvieron a valorar lo que sabían antes, y las puntuaciones siguieron bajas. Su primera sensación de comprensión simplemente había sido demasiado alta (Rozenblit y Keil, 2002).

Los autores lo llaman la ilusión de profundidad explicativa. Era mucho más fuerte con las explicaciones que con los datos, los procedimientos o las historias, y los motivos que dan encajan casi demasiado bien con un proyecto de software. Mientras trabajas, tienes el sistema delante, así que poder consultar algo se siente como saberlo. Entiendes el nivel superior y das por sabidos los inferiores. Rara vez tienes que explicar todo de principio a fin, así que nunca descubres dónde se rompe tu explicación.

Una entrevista hace exactamente esa pregunta de diagnóstico.

En qué profundizan los entrevistadores

Los reclutadores de Amazon describen sin rodeos el fallo más común. Los candidatos no profundizan lo suficiente. Para cada pregunta quieren un relato detallado de una sola situación, con las cifras, las personas que trabajaban en el proyecto y los resultados que conseguiste. También piden a los candidatos que describan sus acciones en primera persona, porque la entrevista trata de lo que hiciste tú (reclutadores de Amazon). Uno de los principios de liderazgo de la empresa, Dive Deep, pide mantenerse al tanto de los detalles (Amazon).

Espera la misma forma te entrevistes donde te entrevistes. Das una visión general breve, y el entrevistador hace pregunta tras pregunta, cada una un nivel más abajo. La visión general es la parte fácil, y lo que se evalúa son las preguntas de seguimiento.

Una explicación de dos minutos

Empieza por el problema y por las personas a las que afectaba, en una o dos frases que incluyan la limitación que lo hacía difícil.

La búsqueda de nuestro portal de pacientes tardaba casi un segundo, y las incidencias de soporte sobre ella se duplicaron tras la versión de primavera.

Di en una frase lo que era tuyo y en otra lo que hicieron otros. La mayor parte de los dos minutos es para dos o tres decisiones, y en cada una nombra la opción que descartaste. Una decisión con una alternativa descartada muestra criterio. Una lista de herramientas no muestra nada.

Podríamos haber añadido réplicas. Elegí un índice precalculado porque lo lento era el ranking, y las réplicas solo ayudan con las lecturas.

Cierra con el resultado, una cifra y lo que cambiarías.

El p95 pasó de unos 800 milisegundos a menos de 200. Si lo hiciera otra vez, daría contrapresión a la tarea de reconstrucción del índice desde el principio.

Para ahí y deja que el entrevistador elija el hilo.

Prepara la escalera de preguntas de seguimiento

Hay unas cuantas preguntas de seguimiento que salen en casi todas las conversaciones a fondo sobre un proyecto, y cada una merece una o dos frases escritas antes de la entrevista. Te preguntarán por qué elegiste este diseño frente a la alternativa obvia, cuál fue el fallo más difícil y cómo lo encontraste, y cómo supiste que funcionaba y qué mediste. También te preguntarán qué pasa cuando se cae una dependencia, una tarea se reinicia a medias o la entrada se multiplica por diez, qué partes escribiste, decidiste o revisaste tú y qué harías de otra forma.

La prueba de Rozenblit y Keil funciona igual de bien contigo. Elige el flujo central del proyecto, una petición o una tarea de principio a fin, y escríbelo paso a paso sin abrir el código. Añade una pregunta de diagnóstico sobre él, como qué pasa si el servicio se reinicia a mitad, y respóndela. Cada sitio en el que dudes es una pregunta de seguimiento a punto de llegar. Abre el código, cubre el hueco y escribe la respuesta en una frase que puedas decir en voz alta.

Errores que hunden buenos proyectos

El más común es nombrar tecnologías. React, Node, Postgres y Redis no le dicen al entrevistador nada sobre cómo piensas. Muy cerca está hablar en nombre de todo el equipo de principio a fin, cuando estás ahí para hablar de tu parte. Muchas explicaciones no mencionan ni una cifra. Latencia, usuarios, dinero, tiempo ahorrado o tasa de errores, con una basta. Hay candidatos que se atribuyen más de lo que hicieron, y la siguiente pregunta baja un nivel más. Otros explican cada componente. Elige los dos que concentraron las decisiones más interesantes y deja el resto para las preguntas.

Deja que los archivos hagan parte del trabajo

En parte creamos Prepped para esto. Añade la carpeta del proyecto o el repositorio de GitHub a una entrevista en Prepped, y su preparación lee los archivos y redacta respuestas a las preguntas que probablemente te harán sobre el código, indicando de qué archivo sale cada respuesta. Lo que los archivos no respaldan queda marcado, para que sepas qué comprobar. El banco de preguntas también tiene una estructura de proyecto, con el problema, tu papel, las decisiones clave y el resultado, para ensayar la explicación hasta que quepa en dos minutos.