Superar una entrevista técnica para programadores en 2026 ya no consiste en memorizar algoritmos: las empresas miden cómo piensas, cómo lees código existente y cómo razonas sobre sistemas reales bajo presión.
El proceso técnico para perfiles de programación ha cambiado mucho en los últimos tres años. La mayoría de empresas en España ha abandonado los tests cronometrados tipo HackerRank y ha vuelto a formatos más cercanos al trabajo real: pair programming, system design y revisión de código.
Esta guía explica cada fase, qué se evalúa y cómo prepararla sin perder seis meses estudiando algoritmos que no usarás.
Las fases típicas en 2026
Un proceso completo en empresa tecnológica suele tener entre 3 y 5 fases técnicas:
| Fase | Duración | Formato | Quién entrevista |
|---|---|---|---|
| Screening | 30-45 min | Llamada con preguntas conceptuales | Tech recruiter o tech lead |
| Live coding | 60-90 min | Coding compartido con el entrevistador | Senior o staff engineer |
| System design | 60 min | Pizarra digital, diseño de sistema | Staff o arquitecto |
| Take-home | 4-8 horas (en tu casa) | Proyecto pequeño | Lo revisa el equipo |
| Cultural fit | 45 min | Conversación con el manager | Engineering manager |
Algunas empresas hacen todo en un solo día (onsite virtual). Otras lo reparten en dos semanas.
Fase 1: el screening
Es la primera barrera. Te llamará un reclutador técnico o un tech lead. Buscan:
- Que sabes describir lo que pone en tu CV con detalle.
- Que tu stack actual y experiencia encaja con la oferta.
- Que tienes nociones claras de los fundamentos.
Preguntas típicas:
- "Cuéntame cómo está construido el sistema en el que trabajas ahora."
- "¿Qué diferencia hay entre una lista y un set, y cuándo usarías uno u otro?"
- "¿Qué hace exactamente un index en una base de datos?"
- "¿Cómo manejas errores en tu lenguaje habitual?"
No es una entrevista trampa, pero si dudas en preguntas básicas, no pasas.
Fase 2: live coding
Aquí es donde se decide buena parte del proceso. Te pedirán resolver un problema en directo, normalmente con el entrevistador escuchando, durante 45-60 minutos.
Formatos habituales
- Algoritmo medio: implementar algo tipo cache LRU, parser de logs, función de búsqueda con paginación. Nivel medium de LeetCode, no hard.
- Bug fixing: te dan un repo con un bug y tienes que encontrarlo.
- Feature pequeña sobre código existente: te dan una base y tienes que añadir una funcionalidad.
Cómo se evalúa realmente
No buscan la solución perfecta. Buscan:
- Cómo piensas en voz alta. Si te quedas en silencio cinco minutos, no pueden evaluarte.
- Cómo manejas la ambigüedad: si entiendes que faltan datos y haces preguntas antes de empezar.
- Tu código limpio: nombres claros, funciones cortas, separación de responsabilidades.
- Tu manejo de casos extremos: arrays vacíos, valores nulos, inputs malformados.
- Cómo testeas: si propones tests y los ejecutas mentalmente.
Estructura recomendada para el live coding
- Aclarar el problema (5 min): repite con tus palabras qué te están pidiendo. Pregunta dudas: tamaño esperado del input, qué hacer en bordes, restricciones.
- Diseñar antes de codear (5 min): explica tu approach. Datos, complejidad esperada, edge cases.
- Implementar (25-35 min): código limpio, en voz alta, sin saltar pasos.
- Testear (10 min): casos normales, casos límite, una traza completa mental.
- Refactorizar si queda tiempo (5 min).
Errores que te eliminan
- Empezar a teclear sin haber entendido el problema.
- Quedarte mudo cuando te bloqueas. Di "estoy pensando en X, dudo entre Y y Z".
- Defenderte cuando el entrevistador te da un hint. Acéptalo y úsalo.
- Ignorar los casos límite.
Fase 3: system design
Suele ser solo para perfiles senior (de 3-4 años en adelante). Te plantean un problema abierto del tipo "diseña un sistema tipo Twitter" o "diseña el backend de un sistema de notificaciones para 10 millones de usuarios".
Qué evalúan
- Si haces las preguntas correctas antes de diseñar (escala, latencias, consistencia eventual o fuerte).
- Si conoces los building blocks: caches, colas, bases de datos relacionales vs NoSQL, sharding, replicación.
- Si justificas trade-offs con criterio.
- Si reconoces tus límites cuando los toques.
Estructura recomendada
- Clarificar requisitos funcionales y no funcionales (5-10 min).
- Estimar magnitudes: usuarios, requests por segundo, datos almacenados (5 min).
- Diagrama de alto nivel: APIs, servicios, bases de datos (15 min).
- Profundizar en una o dos partes según pregunte el entrevistador (20-30 min).
- Discutir trade-offs y posibles mejoras (5-10 min).
Lectura recomendada
Lee con calma "Designing Data-Intensive Applications" de Martin Kleppmann. No hace falta memorizarlo, pero los capítulos 1, 5 y 11 cubren el 80% de lo que se pregunta.
Fase 4: take-home
Te dan un proyecto pequeño para hacer en casa, normalmente 4 a 8 horas. Lo que evalúan:
- Código de producción: tests, README, manejo de errores, estructura.
- Decisiones de diseño: por qué elegiste esa librería, ese patrón.
- Hasta dónde llegaste vs lo que era opcional.
Reglas para no estropearlo
- Lee el enunciado dos veces antes de empezar. Subraya los "must" y los "nice to have".
- Time-boxing: si te dan 6 horas, no dediques 20. Pero tampoco entregues en 90 minutos.
- README con: cómo correrlo, decisiones tomadas, qué dejaste fuera y por qué.
- Tests, aunque sean básicos. Es la línea más visible entre junior y senior.
Take-homes a rechazar
Si el take-home parece trabajo real disfrazado (te piden construir un módulo completo de su producto), responde con educación:
"Estaría encantado de hacer una prueba técnica, pero el alcance de la propuesta excede el tiempo razonable de un proceso. ¿Podríamos sustituirlo por un pair programming sobre vuestra base de código?"
Las empresas serias lo aceptan.
Fase 5: cultural fit
La fase menos técnica, pero igual de importante. Hablas con el engineering manager o futuro jefe directo. Buscan:
- Cómo te llevas con feedback (te cuentan situaciones y ven cómo reaccionas).
- Cómo gestionas conflictos en equipo.
- Tu motivación real para el puesto.
Usa el método STAR aquí también. Hablamos más en Método STAR para respuestas.
Plan de preparación realista
Si tienes dos semanas hasta el proceso:
| Día | Tarea |
|---|---|
| 1-2 | Repasar fundamentos del lenguaje principal (data structures, async, errores) |
| 3-4 | 10 problemas medium de LeetCode en tu lenguaje |
| 5-6 | Repasar SQL básico y diseño de tablas |
| 7-8 | Estudiar system design: capítulos clave de DDIA |
| 9-10 | Hacer 2 mock interviews (Pramp, Interviewing.io o con un amigo) |
| 11-12 | Investigar la empresa: producto, stack, equipo |
| 13 | Take-home si te lo han mandado |
| 14 | Descanso y repaso ligero |
Qué NO necesitas estudiar (al menos para España)
- Algoritmos hard de competición tipo segment trees o suffix arrays.
- Lenguajes que no usarás (no estudies C++ si vas a una empresa Python).
- Patrones de diseño teóricos sin ejemplo de uso.
Las empresas españolas que hacen procesos al estilo FAANG son pocas. La mayoría busca código limpio, criterio y comunicación.
El día de la entrevista
- Prepara el setup: portátil, segundo monitor si tienes, auriculares cableados.
- Cierra Slack, Discord, todo lo que pueda interrumpir.
- Ten agua a mano y papel para apuntar.
- Si es por videollamada, comprueba la cámara y luz 30 minutos antes.
Preguntas frecuentes
¿Cuánto suele durar una entrevista de trabajo en España?
La primera entrevista con RRHH dura entre 30 y 45 minutos. Las técnicas o de competencias se extienden hasta 60-90 minutos. En procesos con varias rondas, calcula 2 a 4 entrevistas a lo largo de 2 a 4 semanas hasta la oferta final.
¿Qué pregunta es la que más se falla?
"Háblame de una debilidad" y "¿por qué dejas tu empresa actual?". La primera por respuestas tópicas tipo "soy perfeccionista", la segunda por hablar mal del jefe anterior. Ambas miden autoconciencia y madurez profesional más que la respuesta literal.
¿Hay que enviar email de agradecimiento tras la entrevista?
Sí, en las 24 horas siguientes. Un email corto agradeciendo el tiempo, retomando un punto concreto que se habló y confirmando interés en avanzar suma puntos y diferencia frente a candidatos que no lo hacen. No alarga ni cambia el sentido de la entrevista.
¿Cuándo se debe hablar de salario?
Solo si pregunta el entrevistador o al final, cuando ya haya interés mutuo. Si te lo preguntan en la primera ronda, da un rango orientativo basado en mercado y deja claro que es negociable según paquete completo (variable, beneficios, flexibilidad).
Próximos pasos
La mejor preparación es práctica deliberada: una hora al día durante 10 días bate dos sesiones de cinco horas. Si el proceso incluye una entrevista personal aparte, repasa Entrevista personal vs técnica para preparar ambos formatos. Y mientras tanto, mantén el flujo de procesos en ofertas activas. Una entrevista técnica con tres ofertas en paralelo se siente muy distinta a una con cero.
