TL;DR · Respuesta directa

Las entrevistas técnicas tipo Leetcode hard evalúan preparación para entrevistas, no capacidad de ingeniería real. El estándar 2026 en empresas que contratan bien: 1 coding práctico relevante al stack, 1 system design abierto, 1 code review colaborativo, 1 behavioral con historias técnicas. Total 4-5 horas. Los candidatos senior rechazan procesos con rondas de algorithms puros porque señalan falta de criterio en evaluación.

Las entrevistas técnicas en startups mexicanas siguen arrastrando un problema que Google reconoció hace años: evaluamos preparación para entrevistas más que capacidad de construir software real. El developer senior que no practicó Leetcode en 3 meses falla el primer screen; el junior que memorizó patrones lo pasa. Resultado: equipos técnicos sesgados hacia quien tuvo tiempo de preparar entrevistas, no hacia quien va a hacer mejor trabajo.

Qué NO evalúa bien un whiteboard tradicional

  • Capacidad real de ingeniería: construir software es trabajar con context grande y tiempo de reflexión. El whiteboard de 45 min mide otra cosa.
  • Colaboración: cómo trabaja el candidato con un peer en decisión compleja.
  • Criterio técnico: cómo decide entre trade-offs reales, no problemas de juguete.
  • Comunicación técnica: cómo explica decisiones a no-técnicos o juniors.
  • Debugging en código existente: lo que el dev hace 60% del tiempo en trabajo real.

Framework · las 4 rondas del loop técnico efectivo

Ronda 1 · Coding práctico relevante (60-90 min)

Problema diseñado para reflejar el stack y tipo de trabajo real. Ejemplos:

  • Backend API: "Aquí hay un endpoint que tiene un bug y no performa bien. Arréglalo. Tenés acceso a logs, docs del framework y StackOverflow".
  • Frontend: "Aquí hay un componente con problemas de re-render. Diagnosticá y optimizá. Podés usar DevTools".
  • Data Eng: "Aquí hay un pipeline que falla intermitente. Aquí los logs. ¿Qué hipótesis tenés y cómo validás?".

Qué evaluás: capacidad de debugging, razonamiento sobre trade-offs, uso de recursos disponibles (DevTools, docs), comunicación durante ejecución.

Qué NO evaluás: memoria de algoritmos, sintaxis perfecta, velocidad de escritura.

Ronda 2 · System Design abierto (60-90 min)

Problema de diseño de sistema real, de complejidad apropiada al nivel del candidato:

  • Mid: "Diseñá un sistema de notificaciones in-app para usuarios activos".
  • Senior: "Diseñá el backend de un feature de pagos entre usuarios tipo Venmo para LATAM".
  • Staff: "Diseñá un sistema de eventos que soporte 500K events/segundo con garantías at-least-once y procesamiento en 2+ centros geográficos".

Qué evaluás: estructura del pensamiento, hacer preguntas correctas al inicio (scope, escala, constraints), razonamiento sobre trade-offs (consistencia vs. disponibilidad, build vs. buy), identificación proactiva de edge cases.

Ronda 3 · Code Review Colaborativo (45-60 min)

Pull request sintético (250-500 líneas) con 5-8 issues de diferentes severidades. El candidato lo revisa con el interviewer como si fueran colegas. Evaluás:

  • Encuentra bugs importantes.
  • Distingue entre estilo y sustancia.
  • Comunica feedback constructivamente.
  • Pregunta cuando no entiende el contexto del cambio.
  • Reconoce cuando no sabe algo y propone cómo averiguar.

Esta ronda es especialmente reveladora — evalúa cómo interactúa con peers en decisiones técnicas. Red flag: candidato que solo da feedback negativo sin reconocer partes buenas, o que no puede defender su feedback cuando el interviewer lo cuestiona.

Ronda 4 · Behavioral con historias técnicas (45-60 min)

STAR adaptado a contexto técnico:

  • "Contame del bug más difícil que debuggeaste en 2024. Cómo llegaste al root cause".
  • "Una decisión de arquitectura donde estuviste en desacuerdo con tu team. Cómo se resolvió".
  • "Un proyecto que terminó diferente de lo planeado. Qué aprendiste técnicamente".
  • "Una vez que tomaste una decisión técnica que después resultó equivocada. Qué hiciste".

Rúbrica por ronda · hacer calibración explícita

Cada ronda debe tener rúbrica escrita 1-5 con descriptores específicos. Ejemplo para System Design:

  • 1 — Inadecuado: no pregunta scope inicial, propone solución sin preguntas, no identifica trade-offs.
  • 3 — Cumple: pregunta scope, propone diseño viable, menciona 2-3 trade-offs con análisis básico.
  • 5 — Excepcional: pregunta scope con 4+ preguntas críticas, propone 2-3 alternativas y justifica elección, identifica edge cases proactivamente, estima escalamiento con números.

Red flags en el diseño del loop

  • 6+ rondas técnicas: los senior no tienen tiempo — abandonan el proceso.
  • Algorithms hard para rol de negocio: señala que la empresa no sabe qué evaluar.
  • Take-home de 20+ horas: se interpreta como trabajo gratuito. Mejor sesión presencial paga de 4-6h o take-home de <6h.
  • Whiteboard sin acceso a docs: en trabajo real ningún dev escribe sin docs/Stack. Evaluar sin eso es teatro.
  • Mismo tipo de pregunta en 3 rondas: redundante. Cada ronda debe evaluar dimensión distinta.

Entrenamiento de interviewers · no-negociable

Antes de que un ingeniero entreviste, debería:

  • Haber shadowed 3-4 entrevistas con interviewer senior.
  • Haber practicado la rúbrica con feedback específico.
  • Haber conducido 1-2 entrevistas con interviewer senior presente como shadow.
  • Haber leído los principios de hiring de la empresa.

El costo del entrenamiento es bajo (4-8 horas por interviewer). El costo de no hacerlo es alto: falsos positivos, falsos negativos, candidate experience destruido.

La pregunta que importa

Si tus mejores developers actuales volvieran a hacer tu proceso de entrevistas hoy, ¿pasarían todas las rondas? Si la respuesta es "algunos no" — tu proceso tiene falsos negativos. Y si tus mejores no pasarían lo que actualmente usás para evaluar candidatos, probablemente estás rechazando gente que sería excelente hire. Los loops técnicos bien diseñados identifican rendimiento real, no preparación para entrevistas.