Framework de entrevista

Root Cause AnalysisIssue Tree + 5 Whys

Preguntas de ejecución, análisis y diagnóstico

Cuándo recurrir a él

Cualquier «la métrica X cayó o se disparó», revisión de incidencias, o «por qué está roto el funnel».

2681 preguntas de este tipo, repartidas en 1419 de las 2004 empresas de nuestro banco de entrevistas.

¿Qué es el análisis de causa raíz en una entrevista?

El análisis de causa raíz responde a "la métrica X se movió, ¿por qué?" estructurando la búsqueda en vez de adivinar. Enuncias el problema con precisión, segmentas, construyes un árbol MECE cuyas ramas no se solapan, haces cinco porqués por cada rama viva, y luego nombras una hipótesis comprobable y el test que la confirmaría. El framework existe para impedirte adivinar en la primera frase.

Mira la explicación de Root Cause Analysis

Tres minutos: la misma respuesta débil reescrita en una sólida, y los datos de nuestro banco sobre a quién se lo preguntan de verdad.

El análisis de causa raíz responde a "la métrica X se movió, ¿por qué?" estructurando la búsqueda en vez de adivinar. El setenta y nueve por ciento de las empresas de nuestro banco hace una pregunta de tipo root-cause. Recuento sobre 100.000+ preguntas de entrevista reales de 1800+ empresas, por tipo de pregunta. Medido, no estimado. Fuente: el banco de preguntas de entrevista de JobMentis.

Los pasos de Root Cause Analysis

Cada paso es un movimiento, y el orden es lo importante. Saltarse pasos es lo que hace que una respuesta suene desordenada aunque el contenido sea bueno.

  1. 1

    Enunciar el problema con precisión

    ¿Qué cambió, cuándo, cuánto y para quién?

  2. 2

    Segmentar

    Interno contra externo, geografía, plataforma, cohorte, paso del funnel.

  3. 3

    Construir un árbol MECE

    Las ramas de primer nivel deben ser mutuamente excluyentes y colectivamente exhaustivas.

  4. 4

    Hacer cinco porqués por cada rama viva

    Profundiza hasta llegar a una hipótesis comprobable.

  5. 5

    Priorizar y probar

    Elige la hipótesis de mayor impacto y propón el test que la confirma.

Una respuesta Root Cause Analysis débil, reescrita

El acrónimo está en todos los blogs de entrevistas. El contraste puntuado no: es la parte que conviene releer.

Pregunta

La tasa de apertura de notificaciones cayó un 8% semana contra semana. Depúralo.

Respuesta débil

Puede que el texto de las notificaciones se haya quedado soso, o que la gente esté saturada. Probaría a cambiar el texto a ver si la tasa de apertura se recupera. También podríamos enviarlas a mejor hora.

Respuesta fuerte

Primero enunciarlo con precisión: tasa de apertura, no envíos, un 8% relativo abajo semana contra semana, desde cuándo exactamente y para quién. Luego segmentar antes de hipotetizar: interno contra externo, iOS contra Android, por idioma, por tipo de notificación, por antigüedad de cohorte. Digamos que sale solo en Android, desde el martes. Ahora un árbol MECE con tres ramas: se entregan menos notificaciones, las mismas notificaciones se abren menos, o cambió la medición. Cinco porqués por "entregadas": ¿salió una versión el martes, cambió el canal FCM, ese canal venía silenciado por defecto? Eso ya es una hipótesis comprobable. El test es comparar los acuses de entrega antes y después de la versión en Android, lo que la confirma o la descarta en una hora.

Por qué gana la versión fuerte: La respuesta fuerte segmenta antes de hipotetizar, mantiene ramas mutuamente excluyentes para que un usuario no pueda estar en dos a la vez, y cierra con un test concreto que se puede ejecutar hoy. La débil adivina una causa en su primera frase y propone un arreglo para ella, exactamente lo que el framework existe para impedir.

Qué aplana una respuesta Root Cause Analysis

Los movimientos que convierten un buen framework en una respuesta olvidable.

  • Adivinar la causa antes de segmentar.

  • Ramas que se solapan, por ejemplo «usuarios iOS» contra «usuarios de pago»: se puede ser ambos.

  • Ningún test concreto al final.

A quién le preguntan de verdad con Root Cause Analysis

Contado sobre todas las preguntas de nuestro banco de entrevistas, no estimado. Las preguntas de tipo Root Cause Analysis no se reparten de forma uniforme: estos son los perfiles y sectores cuyos procesos más se apoyan en ellas.

Practica Root Cause Analysis en voz alta, no en tu cabeza

Pruébalo con esta pregunta

La tasa de apertura de notificaciones cayó un 8 % semana contra semana. Depúralo.

Leer un framework genera falsa confianza. El simulador de voz te hace una pregunta de tipo Root Cause Analysis, escucha la respuesta entera y puntúa la estructura, la señal y la duración, para que descubras dónde se desvía tu relato antes de que lo haga un entrevistador.

Empezar una entrevista simulada

Empresas que hacen preguntas Root Cause Analysis

Estas empresas hacen preguntas de tipo Root Cause Analysis en su proceso. Cada banco contiene las preguntas reales y la rúbrica con la que puntuamos.

Root Cause Analysis: preguntas frecuentes

¿Cuáles son los pasos del análisis de causa raíz en una entrevista?

Enunciar el problema con precisión (qué cambió, cuándo, cuánto, para quién), segmentarlo (plataforma, geografía, cohorte, paso del funnel), construir un árbol MECE, hacer cinco porqués por cada rama viva hasta llegar a una hipótesis comprobable, y luego priorizar una hipótesis y proponer el test que la confirma.

¿Qué significa MECE?

MECE son mutuamente excluyente y colectivamente exhaustivo. Cada rama de tu árbol debe estar separada de las demás, y juntas deben cubrir todas las posibilidades. "Usuarios iOS" y "usuarios de pago" no es MECE, porque una persona puede ser ambas, y unas ramas que se solapan hacen imposible cerrar el análisis.

¿Cuál es el error más común en el análisis de causa raíz?

Adivinar la causa antes de segmentar. En cuanto has nombrado un sospechoso en la primera frase, el resto de la respuesta se convierte en una búsqueda de pruebas que lo respalden. Los otros dos son ramas que se solapan y terminar sin ningún test concreto.

¿A qué perfiles les preguntan sobre causa raíz?

En nuestro banco de entrevistas, los ingenieros de software se enfrentan al mayor número de preguntas de tipo causa raíz y depuración, seguidos de los product managers y luego de ventas. Es una técnica de origen consultor, pero cualquier perfil que deba explicar por qué se movió un número se la encontrará.