La entrevista de decomposition, paso a paso (con dos casos resueltos)

En la entrevista de decomposition te dan un problema de negocio abierto y casi siempre vago, del tipo «una aseguradora quiere reducir el tiempo de gestión de siniestros», y tienes entre 45 y 60 minutos para convertirlo en un plan. Casi no hay código. Lo que se evalúa es cómo piensas.

Es la entrevista que mejor imita el trabajo real de un FDE. First Round Review cuenta que en Palantir las entrevistas giraban en torno a este tipo de problemas; por ejemplo, un escenario sobre insider trading en el que el candidato tenía que decidir qué datos necesitaría y qué preguntaría al cliente, para evaluar a la vez su razonamiento de negocio y el técnico.

Qué evalúan

El fallo más citado en todas las guías es el primero de la tabla: proponer una solución antes de entender el problema.

El método ACOTAR

Seis pasos fáciles de recordar. No es una receta rígida, sino una red de seguridad para no olvidarte de nada importante.

A · Aclarar el objetivo (5–8 min)

• ¿Por qué ahora? ¿Qué ha pasado para que esto sea una prioridad?
• ¿Quién lo pide y quién decidirá si ha funcionado?
• ¿Cómo se mide hoy? ¿Cuál sería un buen resultado en tres meses?
• ¿Qué restricciones hay: presupuesto, plazos, regulación, sistemas?

Termina el paso reformulando el objetivo en una frase y pide confirmación: «Entonces el objetivo es bajar el tiempo medio por siniestro de 12 a 6 días sin empeorar el fraude detectado, ¿correcto?»

C · Conocer usuarios y proceso actual (5–8 min)

• ¿Quién hace el trabajo hoy y cómo, paso a paso?
• ¿Dónde se pierde el tiempo o se cometen errores?
• ¿Qué casos son habituales y cuáles son raros pero caros?

Dibuja el proceso actual como una cadena de pasos. Es el mapa sobre el que vas a trabajar.

O · Ordenar datos y sistemas (5 min)

• ¿Qué datos genera cada paso? ¿Dónde viven y quién es su responsable?
• ¿Qué calidad tienen? ¿Hay datos históricos con el resultado final?
• ¿Qué sistemas habría que leer o escribir? ¿Tienen API?
• ¿Hay datos personales o sensibles?

T · Trocear en subproblemas y priorizar (8–10 min)

Divide el problema en tres a cinco subproblemas independientes y prioriza con dos ejes: impacto y facilidad, contando con la disponibilidad de los datos. Di en voz alta por qué eliges uno y descartas otros.

A · Acotar la primera versión (10–12 min)

Describe lo que entregarías en las primeras dos a cuatro semanas:

• Qué hace y qué no hace.
• Arquitectura a alto nivel: fuentes, procesamiento, dónde lo ve el usuario.
• Cómo encaja en el trabajo diario del usuario. Si le obliga a abrir otra herramienta, probablemente no lo usará.
• Qué haría falta después para escalarlo.

R · Riesgos y medición (5–8 min)

• Métrica principal, línea base y objetivo.
• Cómo evaluarías la calidad antes de ponerlo delante de usuarios.
• Riesgos técnicos, de datos, de adopción y regulatorios, cada uno con su mitigación.
• Siguientes pasos si funciona.

Termina con un resumen de un minuto: objetivo, primera versión, métrica, principal riesgo y siguiente paso.

Caso resuelto 1: siniestros en una aseguradora

«Una aseguradora de hogar quiere reducir el tiempo que tarda en gestionar los siniestros. ¿Cómo lo abordarías?»

A · Aclarar. El candidato pregunta y el entrevistador responde:

• ¿Por qué ahora? → Las quejas han subido y un competidor anuncia pagos en 48 horas.
• ¿Cómo se mide? → Tiempo medio desde la apertura hasta el pago: hoy 12 días.
• ¿Restricciones? → No puede aumentar el fraude pagado y el equipo no va a crecer.

Reformulación: «Bajar el tiempo medio de 12 días a menos de la mitad sin aumentar el fraude, con el mismo equipo».

C · Proceso. Apertura (llamada o web) → recopilación de documentación → peritación → decisión → pago. El entrevistador revela que el 60 % del tiempo se va esperando documentación: el cliente envía fotos y facturas por correo, a menudo incompletas, y un tramitador revisa a mano qué falta.

O · Datos. Correos con adjuntos, el sistema de gestión de siniestros (con API de lectura y escritura), el histórico de tres años con resultado final e importe, y los informes periciales en PDF. Hay datos personales: todo debe quedarse en la infraestructura del cliente.

T · Subproblemas:

1. Documentación incompleta que obliga a reclamar varias veces. Impacto alto, facilidad alta.
2. Siniestros sencillos que pasan por peritación sin necesidad. Impacto alto, facilidad media.
3. Tiempo de pago tras la decisión. Impacto bajo: ya es de un día.
4. Detección de fraude. Importante, pero arriesgado como primer paso.

Prioriza el 1, porque concentra el 60 % del tiempo, y deja el 2 como segunda fase.

A · Primera versión (tres semanas). Al abrir el siniestro, el sistema le dice al cliente exactamente qué documentos necesita según el tipo de siniestro. Cuando llegan, un modelo comprueba si están completos y legibles, y pide lo que falta en el momento, sin pasar por el tramitador. Los resultados se escriben en el sistema de gestión, donde el tramitador ya trabaja. Fuera de alcance: decisiones de pago y fraude.

R · Medición y riesgos.

• Métrica: días hasta tener la documentación completa (línea base a partir del histórico) y tiempo total por siniestro.
• Evaluación: 300 siniestros históricos etiquetados como «documentación completa o incompleta» y comprobar la precisión del sistema antes de activarlo.
• Riesgos: rechazar documentos válidos (mitigación: en caso de duda decide una persona); clientes mayores que no usan la web (mitigación: mantener el canal telefónico); privacidad (mitigación: procesamiento dentro de su nube).
• Siguiente paso: triaje de siniestros sencillos para evitar peritaciones innecesarias.

Por qué funciona esta respuesta: encuentra dónde se va el tiempo antes de proponer nada, elige el subproblema con más impacto y menos riesgo, se integra en la herramienta de siempre y deja una métrica comparable.

Caso resuelto 2: IA en la atención al cliente de una eléctrica

«Una comercializadora eléctrica con dos millones de clientes quiere usar agentes de IA en su atención al cliente. Diseña cómo lo harías.»

A · Aclarar. El objetivo real no es «usar IA», sino reducir el coste por contacto (hoy tiene un centro de llamadas externalizado) sin empeorar la satisfacción. Métrica: porcentaje de contactos resueltos sin agente humano y nota de satisfacción. Restricciones: sector regulado, datos personales y de facturación, plazos legales para algunas reclamaciones.

C · Usuarios y proceso. Unos 300.000 contactos al mes, por teléfono, chat y correo. El candidato pide la distribución por motivo. Respuesta: el 35 % son dudas sobre la factura, el 20 % cambios de datos o de titular, el 15 % lecturas del contador, el 10 % averías (que corresponden a la distribuidora, no a la comercializadora) y el resto, reclamaciones y otros.

O · Datos y sistemas. CRM con el historial de contactos, sistema de facturación con API, base de conocimiento desactualizada y grabaciones de llamadas. Cambiar el titular exige verificar la identidad.

T · Subproblemas y prioridad.

1. Dudas de factura: mucho volumen, información disponible por API y bajo riesgo si solo se explica. Primero.
2. Lecturas del contador: volumen medio, sencillo y automatizable de principio a fin. Segundo.
3. Averías: redirigir bien a la distribuidora ya ahorra llamadas. Sencillo, en paralelo.
4. Cambios de titular y reclamaciones: alto riesgo regulatorio y de identidad. Más adelante y siempre con una persona.

A · Primera versión (cuatro semanas). Un agente en el chat de la web y la app que explica la factura del cliente identificado: lee sus datos de facturación por API y responde con conceptos, consumos y comparativas. Si detecta enfado, una reclamación o un tema fuera de alcance, pasa a una persona con un resumen de la conversación. Fuera de alcance: modificar contratos o datos. El canal telefónico, más caro de integrar, va en la segunda fase.

R · Medición y riesgos.

• Evaluación antes de lanzar: 500 conversaciones reales anonimizadas sobre facturas, con la respuesta correcta validada por el equipo de calidad. Umbral: 95 % de respuestas correctas y ninguna información falsa sobre importes.
• Lanzamiento al 5 % del tráfico, comparado con un grupo de control en resolución, satisfacción y repetición del contacto en 7 días.
• Riesgos: inventarse conceptos de la factura (mitigación: el agente solo responde con datos de la API y cita la línea); cambios en la tarifa regulada (mitigación: una base de conocimiento con responsable y fecha de revisión); frustración (mitigación: paso a una persona siempre disponible); privacidad y regulación (mitigación: revisión con el delegado de protección de datos y con el área legal antes del piloto).
• Siguiente paso: lecturas de contador de principio a fin y después el canal de voz.

Por qué funciona: empieza por el motivo de contacto con más volumen y menos riesgo, separa explicar de modificar, evalúa antes de lanzar y mide contra un grupo de control. Además demuestra que entiende el sector: las averías son de la distribuidora.

Rúbrica para autoevaluarte

Grábate resolviendo un caso y puntúa de 1 a 3 cada fila (1 = no lo hice, 2 = a medias, 3 = bien):

Más de 25: listo para la entrevista. Entre 18 y 25: sigue practicando y repasa las filas con 1. Menos de 18: vuelve al método y practica con alguien que haga de entrevistador.

Cómo practicar

• En voz alta y cronometrado. Pensar en silencio no sirve: en la entrevista hay que hablar.
• Con otra persona que haga de cliente y solo dé información cuando se la pidas. En la comunidad del club puedes encontrar con quién practicar.
• Grábate y revisa la grabación con la rúbrica.
• Un caso al día durante dos semanas es mejor que diez casos en un fin de semana.

Quince casos para practicar

1. Una cadena de supermercados quiere reducir el desperdicio de producto fresco.
2. Un hospital quiere reducir las citas a las que los pacientes no acuden.
3. Un banco quiere acelerar la concesión de préstamos a pymes.
4. Un ayuntamiento quiere responder antes a las incidencias que comunican los vecinos.
5. Una empresa de logística quiere reducir las entregas fallidas.
6. Un despacho de abogados quiere usar IA para revisar contratos.
7. Una fábrica quiere anticipar averías en su maquinaria.
8. Una empresa de recobro quiere usar agentes de voz para recordar pagos pendientes.
9. Una aerolínea quiere gestionar mejor las reclamaciones por retrasos.
10. Una empresa de RR. HH. quiere automatizar la primera criba de candidatos.
11. Una universidad quiere reducir el abandono en primer curso.
12. Un fondo de inversión quiere detectar señales en documentos regulatorios.
13. Una empresa de software quiere que su equipo de soporte resuelva tickets más rápido.
14. Una distribuidora farmacéutica quiere evitar roturas de stock en farmacias.
15. Un organismo público quiere detectar fraude en ayudas.

Para los casos 6, 8 y 10, añade siempre la pregunta: ¿qué puede salir mal si la IA se equivoca, y quién responde?

Fuentes

• First Round Review: So You Want to Hire a Forward Deployed Engineer, sobre el enfoque de Palantir y el ejemplo de insider trading.
• Palantir: Dev versus Delta, sobre descomponer problemas de alto nivel, e Interviewing at Palantir: Our advice.
• Guía de preparación de terceros, orientativa: Aced (antes Exponent), Decomposition interview.
• El método ACOTAR, los casos y la rúbrica son del FDE Club. Los datos de los casos son inventados para practicar.