Machine Learning Development

Cómo usar una entrevista fallida para subir tu nivel como desarrollador

 

Te llegó el mensaje: “Gracias por tu tiempo…”  Pero lo peor no es fallar una entrevista. Lo peor es quedarte con esta idea: “repito errores y no sé qué cambiar”.


Te lo decimos: si hoy no quedaste, eso no significa que “no sirves”. Significa que todavía te falta ajustar piezas específicas… y lo bueno es que eso se puede modificar.


Y ojo: a veces no es “porque lo hiciste terrible”, sino porque el mercado es duro y el embudo es pesado. En 2024, por ejemplo, se reportó un promedio de 180 applicantes por cada contratación.


Y aun llegando a entrevista, no siempre se traduce en oferta: NACE cita un interview-to-offer rate promedio de 47.5% (aprox. 48 de cada 100 candidatos entrevistados reciben ofertas). Súmale que el silencio es común: Greenhouse reportó que 61% de personas han sido ghosted después de una entrevista.


Así que si esperas “la razón exacta”, te puedes quedar esperando. Por eso este blog es un sistema simple para convertir una entrevista fallida en progreso real (no motivación de 24 horas).

 

Cómo analizar una entrevista fallida sin quedarte estancado


1) Primero: no fue “todo”. Fue algo (y vamos a encontrar qué)


Cuando uno falla, la mente hace esto:

 

  • “Me fue mal en todo”
  • “No soy bueno para entrevistas”
  • “Seguro era demasiado para mí”


Casi nunca es “todo”. Normalmente es una combinación de 2 o 3 gaps que se repiten. La clave es hacer un post-mortem rápido mientras lo tienes fresco.


Post-mortem de la entrevista en 15 minutos (cópialo tal cual)


Escribe estas preguntas en Notion/Google Doc y responde corto, sin drama:

  1. ¿Qué me preguntaron? (temas, no detalles: arrays, APIs, system design, debugging, SQL, etc.)
  2. ¿Dónde me trabé exactamente? (inicio, mitad, explicar, optimización, casos borde, comunicar)
  3. ¿Qué señales vi del entrevistador? (me redirigió, pedía más claridad, pidió complejidad, etc.)
  4. ¿Qué parte fue más incómoda? (nervios, blanco mental, hablar, codear rápido)
  5. Si repitieran la misma entrevista mañana, qué haría distinto? (3 bullets)


Esto convierte “me fue mal” en información.


2) Mapa de gaps: el tablero que te dice qué entrenar


Ahora clasifica lo que pasó en estas categorías. No inventes. Solo marca lo que realmente ocurrió.


A) Fundamentos / DSA (Data Structures & Algorithms)

 

  • Me costó elegir estructura de datos
  • No vi el approach
  • Me faltó práctica de patrones (two pointers, BFS/DFS, sliding window…)


B) Coding fluido (en vivo)

 

  • Me bloqueé escribiendo
  • Bugs tontos por nervios
  • No cubrí casos borde
  • No supe testear rápido


C) Explicación / comunicación

 

  • Tenía la idea pero no la pude explicar
  • No verbalicé trade-offs
  • Me quedé callado mucho rato


D) System design (para Mid+ o roles backend/fullstack)

 

  • No supe definir componentes
  • No hablé de escalabilidad/caching/DB
  • No hice preguntas de requisitos


E) Experiencia / proyectos

 

  • Mis ejemplos no fueron sólidos
  • Mi portafolio no respalda lo que digo
  • No supe contar impacto (métricas, decisiones)
     

Truco: elige máximo 2 gaps principales. Si eliges 6, no entrenas nada. Así que seleccionalos y comienza a trabajar en ello. 


3) Pedir feedback (sí, aunque casi nunca respondan)


No te quedes esperando que te lo regalen, pero pide feedback.


Puedes hacer un mensaje corto como:


Hola [Nombre], gracias por el proceso y el tiempo. Quiero mejorar para futuras entrevistas: ¿podrías compartir 1–2 puntos concretos que influyeron en la decisión (por ejemplo, un área técnica o de comunicación)?  Me ayudaría muchísimo para trabajar en ello. Gracias.


Si responden: excelente, trabajo en lo que te dijeron.
Si no responden: igual tú hiciste lo correcto.


4) Plan de 30 días (realista, no “voy a estudiar 8 horas diarias”)


La meta no es “ser perfecto”. Es subir tu hit rate.


Semana 1: Diagnóstico + base

 

  • 1 día: post-mortem + mapa de gaps
  • 3 días: fundamentos del gap #1 (ej: arrays/strings + patrones)
  • 2 días: 1 problema diario (con explicación en voz alta)
  • 1 día: revisar soluciones + escribir “qué aprendí”
     

Semana 2: Repetición inteligente

 

  • 4 días: 2 problemas por día (pero con calidad)
  • 2 días: mock interview (30–45 min)
  • 1 día: retro + lista de errores repetidos
     

Semana 3: Simulación (como en entrevista)

 

  • 3 días: problemas cronometrados (45 min)
  • 2 días: mock interview con alguien (o grabándote)
  • 2 días: pulir comunicación (explicar approach, trade-offs, casos borde)
     

Semana 4: Portafolio como refuerzo + entrevistas

 

  • 2 días: mejorar 1 proyecto (README, decisiones técnicas, screenshots)
  • 2 días: preparar 6 historias STAR (debugging, conflicto, impacto, aprendizaje)
  • 2 días: mocks
  • 1 día: aplicar + ajustar CV/LinkedIn según rol


5) Mock interviews: donde realmente mejora la cosa


Los mocks duelen porque muestran lo real: nervios, silencios, explicación confusa, bugs.


Checklist simple para cada mock:

  • ¿Hice preguntas antes de codear?
  • ¿Dije el approach antes de escribir?
  • ¿Mencioné casos borde?
  • ¿Probé con un ejemplo?
  • ¿Dije complejidad?
  • ¿Cerré con “si hubiera más tiempo, mejoraría…”?


Grábate aunque sea con audio. Es incómodo 2 días. Luego es ventaja.


6) Portafolio como refuerzo (para que tu “sí sé” tenga pruebas)


Tu portafolio no es “mira mi app”. Es:

 

  • Qué problema resolví
  • Qué decisiones tomé y por qué
  • Qué trade-offs hubo
  • Qué aprendí
  • (si puedes) impacto: performance, UX, tiempo, bugs reducidos


Si te cuesta venderte, el portafolio puede hacer una parte del trabajo por ti.


7) El objetivo no es gustarle a todos, es subir tu porcentaje


Que no hayas quedado normalmente significa algo mucho más simple: en esta ronda escogieron a otra persona. Tal vez tenía más experiencia en ese stack, venía de un dominio similar, encajó mejor con el equipo, o simplemente “hizo click” ese día. Eso no es una prueba de que seas malo, ni de que “no das la talla”.


Lo que sí puedes controlar es lo que haces con esto.


Haz tu post-mortem, detecta 1–2 gaps, entrena con mocks, refuerza tu portafolio y vuelve a intentarlo con una versión tuya más preparada. Porque al final, esto no va de aprobar “una entrevista”. Va de subir tu probabilidad. Y eso se construye.


Recursos relacionados

Si quieres complementar este plan con guías más específicas, te dejo tres recursos que encajan perfecto:


Y si sigues aplicando a entrevistas: revisa nuestra sección de Jobs y aplica a roles que encajen con lo que estás buscando. Puedes revisar nuestras redes sociales y conocer nuestra cultura profesional.