Saltar al contenido
FDE Club
← Recursos

Paso 2 · Consigue el puesto · 1 de 3

Cómo preparar una entrevista de FDE: la guía completa

Qué buscan las empresas, cómo es cada fase del proceso (coding práctico, decomposition, system design, simulación con cliente, presentación de proyecto y entrevista de comportamiento), un plan de preparación de cuatro semanas y las preguntas que debes hacer tú.

FDE Club · Actualizado el 10 de noviembre de 2026 · 11 min · Todos los niveles

En esta guía (9 secciones)
  1. Qué buscan de verdad las empresas
  2. Cómo es el proceso
  3. Fase a fase
  4. Plan de preparación de cuatro semanas
  5. Si vienes de…
  6. Preguntas que debes hacer tú
  7. El día de la entrevista
  8. Los diez errores más comunes
  9. Fuentes

Una entrevista de FDE mide dos cosas a la vez: si eres buen ingeniero y si sabes convertir un problema ambiguo de un cliente en algo que funciona. La mayoría de candidatos prepara solo una de las dos. Esta guía te ayuda a preparar ambas.

Lo más importante en una frase: las guías de preparación coinciden en que el caso de decomposition es la fase con menos aprobados, y en que el error más habitual es lanzarse a proponer una solución antes de entender el problema.

Qué buscan de verdad las empresas

El listón técnico no baja. Según First Round Review, en Palantir los FDEs pasaban los mismos procesos de entrevista que los ingenieros de software. No esperes una versión «ligera» del proceso técnico.

Además del código, buscan rasgos concretos. First Round recoge los que comparten los mejores FDEs, según quienes los contratan:

  • Pensamiento independiente, sin manual: orientados a resultados. Un candidato dogmático o rígido es una señal de alarma.
  • Tenacidad: los problemas son difíciles y el trabajo a veces es duro.
  • Construir por compulsión: gente que hace herramientas, apps o proyectos open source por iniciativa propia.
  • Curiosidad por los negocios: interés genuino por cómo funciona la empresa del cliente.

Y valoran cómo piensas, no si te sabes la respuesta. En el blog de Palantir, sus ingenieros insisten en que la entrevista es una sesión de trabajo en colaboración: importa cómo abordas el problema y qué eres capaz de aprender sobre la marcha, no las respuestas memorizadas.

Cómo es el proceso

No hay un proceso estándar: cambia entre empresas e incluso entre equipos de la misma empresa. Estas son las fases que aparecen con más frecuencia:

Fase Duración Qué evalúan Cómo prepararla
Llamada con recruiting 20–30 min Motivación, encaje, idiomas, expectativas Tu historia en 90 segundos y por qué FDE
Hiring manager 30–45 min Experiencia con clientes, criterio, motivación Dos o tres historias con impacto medible
Coding práctico 45–90 min Código limpio sobre problemas reales APIs, datos, depuración, LLMs con Python
Decomposition / caso 45–60 min Estructurar un problema de negocio ambiguo La guía de decomposition
System design 45–60 min Arquitectura con restricciones de cliente Diseños con datos sensibles y sistemas heredados
Simulación con cliente 30–45 min Comunicación, gestión de expectativas Practicar con alguien que haga de cliente difícil
Presentación de proyecto 45–60 min Profundidad técnica y decisiones Un proyecto propio que puedas defender a fondo
Comportamiento y valores 30–45 min Cómo actúas bajo presión y con clientes Seis historias preparadas

Las guías de preparación de terceros, como Exponent o IGotAnOffer, describen procesos de entre dos semanas y dos meses. En el caso de OpenAI, por ejemplo, cuentan variantes con prueba para casa y defensa en directo en algunos equipos y sin ella en otros. Tómalo como algo orientativo: pregunta siempre a recruiting qué fases tendrá tu proceso y qué evalúa cada una. Es una pregunta normal y te dará mucha ventaja.

Fase a fase

1. La llamada con recruiting

Parece un trámite, pero aquí se filtra a mucha gente. Te preguntarán casi siempre por qué quieres ser FDE. Prepara una respuesta de 60 a 90 segundos con esta estructura:

  1. De dónde vienes: una frase.
  2. Un momento en que trabajaste con un usuario o cliente y lo que pasó.
  3. Por qué este rol y no otro: te gusta construir y ver el impacto en el cliente.
  4. Por qué esta empresa: algo concreto de su producto o sus clientes.

Ten clara tu disponibilidad para viajar, los idiomas con los que puedes trabajar con clientes y tu rango salarial. En las ofertas de nuestra bolsa, el inglés aparece en 27 de 51 y el español en 14.

2. Coding práctico

Normalmente no es algoritmia pura, sino problemas cercanos al día a día:

  • Consumir una API paginada, limpiar los datos y calcular algo.
  • Leer un CSV o JSON sucio y normalizarlo.
  • Depurar o ampliar código que ya existe.
  • Cada vez más, tareas con LLMs: llamar a un modelo con salida estructurada, implementar tool use, escribir un pequeño script de evaluación.

Cómo hacerlo bien:

  • Haz preguntas antes de escribir: formato de entrada, volumen, casos límite.
  • Empieza por una versión simple que funcione y mejórala después.
  • Piensa en voz alta y explica qué compromisos estás asumiendo.
  • Gestiona los errores: en el mundo real la API falla y los datos vienen mal.
  • Escribe un par de pruebas rápidas aunque no te las pidan.

Cómo practicar: Python es el lenguaje más pedido en nuestra bolsa (aparece en 18 de 51 ofertas). Haz ejercicios cronometrados de 45 minutos con APIs públicas y con la API de algún modelo. Prioriza la claridad sobre la astucia.

3. Decomposition

Te plantean un problema de negocio abierto y lo tienes que estructurar: qué preguntarías, qué datos necesitas, cuál sería la primera versión y cómo medirías el éxito. Palantir describe el rol justamente así: coger un problema de alto nivel, descomponerlo y diseñar una solución, bajando de los objetivos de negocio hasta el código.

Según las guías de preparación, es una de las fases que más pesa y la que más candidatos suspende. Le dedicamos una guía entera con un método y dos casos resueltos: La entrevista de decomposition, paso a paso.

4. System design orientado a cliente

Es como un system design clásico, pero con las restricciones de un cliente enterprise:

  • Datos sensibles que no pueden salir de su infraestructura.
  • Sistemas heredados sin API o con APIs lentas.
  • Equipos de IT que necesitan aprobar cada integración.
  • Plazos de semanas, no de trimestres.

En sistemas con LLMs, esperan que hables de latencia, coste por petición, evaluación de la calidad, alucinaciones, qué pasa cuando el modelo no sabe y cómo se monitoriza en producción.

Una estructura que funciona:

  1. Requisitos funcionales y no funcionales, preguntando por volumen, latencia y datos sensibles.
  2. Diseño de alto nivel: componentes y flujo de datos.
  3. Profundiza en la parte más arriesgada, no en la más cómoda.
  4. Evaluación y monitorización: cómo sabrás que funciona.
  5. Compromisos asumidos y cómo evolucionaría el sistema.

5. Simulación con cliente

Un entrevistador hace de cliente. Escenarios habituales:

  • El cliente está enfadado porque el piloto no funciona como esperaba.
  • Pide una funcionalidad nueva a mitad de proyecto («y ya que estáis…»).
  • Tienes que explicar a un directivo no técnico por qué la solución no puede acertar el 100 % de las veces.
  • El cliente quiere ir a producción y tú sabes que no está listo.

Un esquema sencillo para estas conversaciones:

  1. Escucha y reformula: «Si te he entendido bien, lo que te preocupa es…».
  2. Reconoce lo que sea legítimo, sin culpar a nadie.
  3. Da opciones con sus consecuencias, no un «no» seco: «Podemos hacer A esta semana si dejamos B para la siguiente, o hacer las dos y retrasar la entrega dos semanas».
  4. Cierra con un siguiente paso concreto: quién hace qué y para cuándo.

Se valora más la calma y la claridad que tener razón.

6. Presentación de un proyecto

Te piden presentar algo complejo que hayas construido y te interrumpen con preguntas sobre cada decisión. Elige un proyecto en el que:

  • Tomaste decisiones técnicas reales y puedes explicar las alternativas que descartaste.
  • Hubo un usuario o cliente y un resultado medible.
  • Algo salió mal y aprendiste algo.

Estructura en 10–15 minutos: problema y usuario, arquitectura, dos decisiones difíciles, resultados medidos, qué harías distinto. Prepárate para bajar al detalle de cualquier componente.

7. Entrevista de comportamiento

Prepara seis historias con estructura situación, acción, resultado y aprendizaje, y adáptalas a cada pregunta:

  1. Un cliente o usuario descontento al que le diste la vuelta.
  2. Un proyecto ambiguo en el que tuviste que definir tú el problema.
  3. Una vez que dijiste que no, o renegociaste el alcance, con argumentos.
  4. Un fallo tuyo en producción y qué hiciste después.
  5. Una vez que aprendiste algo muy rápido para desbloquear un proyecto.
  6. Un desacuerdo técnico con alguien de tu equipo.

Cuantifica el resultado siempre que puedas. «Mejoró bastante» no convence; «el tiempo de respuesta bajó de 3 días a 4 horas» sí.

Plan de preparación de cuatro semanas

Semana Foco Tareas
1 Base y relato Escribe tu historia «por qué FDE» y las seis historias. Lee qué es un FDE y el ciclo de un despliegue. Tres ejercicios de coding práctico.
2 Decomposition Estudia el método. Resuelve un caso al día en voz alta durante 30 minutos y grábate. Repasa el banco de preguntas.
3 Diseño y LLMs Dos system designs con restricciones enterprise. Un mini proyecto con LLM y evaluación que puedas enseñar.
4 Simulacros Dos entrevistas simuladas completas con otra persona (la comunidad del club sirve para esto). Prepara las preguntas para cada empresa. Descansa el día antes.

Si vienes de…

  • Ingeniería de software: tu punto fuerte es el código. Practica decomposition y simulación con cliente, y busca historias en las que hablaste con usuarios.
  • Consultoría: sabes estructurar y tratar con clientes. Demuestra que construyes software de producción: un proyecto desplegado vale más que diez presentaciones.
  • Data o ML: refuerza la ingeniería de despliegue (APIs, contenedores, monitorización) y habla de impacto en el negocio, no solo de métricas del modelo.
  • Preventa o Solutions Engineering: ya conoces el contexto de cliente. Demuestra profundidad técnica más allá de la demo, con código que mantuviste en producción.
  • Recién graduado: apóyate en proyectos con usuarios reales, prácticas y hackathons. Algunas ofertas de la bolsa están pensadas para ti: busca «Graduados» o «Emerging Talent».

Preguntas que debes hacer tú

Una entrevista también es tu oportunidad de averiguar si el puesto es lo que parece. The Pragmatic Engineer recoge casos de ingenieros que aceptaron un puesto de FDE y se encontraron con algo más parecido a consultoría que a ingeniería. Pregunta:

  1. ¿Qué porcentaje del tiempo se dedica a escribir código y cuánto a reuniones con clientes?
  2. ¿Cuánto se viaja? ¿A dónde y con qué antelación se sabe?
  3. ¿Con cuántos clientes trabaja a la vez un FDE?
  4. ¿Cómo llega lo que construimos en el campo al producto? ¿Puedes darme un ejemplo reciente?
  5. ¿Cómo se mide el éxito de un FDE aquí?
  6. ¿Cómo es la carrera: hay niveles de FDE? ¿Adónde han ido los FDEs que han crecido aquí?
  7. ¿Qué tipo de clientes y sectores llevaría el primer año?

El día de la entrevista

  • Sé qué fases tiene y quién te va a entrevistar.
  • Tienes a mano tu historia de 90 segundos y las seis historias.
  • Has preparado dos o tres preguntas específicas sobre los clientes y el producto de la empresa.
  • Entorno de coding probado: editor, conexión y, si es remota, compartir pantalla.
  • Papel o pizarra para estructurar en decomposition y system design.
  • Agua y diez minutos libres antes de empezar.

Los diez errores más comunes

  1. Proponer una solución antes de hacer preguntas.
  2. Quedarse en silencio mientras piensas: piensa en voz alta.
  3. Diseñar lo más sofisticado en vez de lo que el cliente necesita la primera semana.
  4. No hablar nunca de cómo se mide el éxito.
  5. Olvidarse de los datos: quién los tiene, en qué estado están, si se puede acceder a ellos.
  6. Ignorar seguridad y privacidad en un contexto enterprise.
  7. Hablar de «nosotros» sin aclarar qué hiciste tú.
  8. No reconocer lo que no sabes.
  9. Contar historias sin un resultado medible.
  10. No hacer ninguna pregunta al final.

Fuentes

¿Te ha servido?

Comenta la guía, propón mejoras o practica entrevistas con otros miembros en la comunidad del club.