Por qué la entrevista técnica no es solo un examen de código
Un error muy frecuente: creer que la entrevista técnica se aprueba si el código funciona. Eso es necesario pero no suficiente. Las empresas que hacen buenas entrevistas técnicas evalúan al menos cinco dimensiones:
- Comprensión del problema: ¿Hacés preguntas antes de escribir código? ¿Clarificás los casos edge?
- Proceso de pensamiento: ¿Pensás en voz alta? ¿Explorás alternativas antes de comprometerte con una solución?
- Calidad del código: ¿Es legible? ¿Tiene buenas abstracciones? ¿Considerás la complejidad temporal y espacial?
- Manejo de la presión: ¿Cómo reaccionás cuando te trabás o cuando el entrevistador da un hint?
- Comunicación: ¿Podés explicar tus decisiones a alguien que no vio tu código antes?
Esto significa que alguien con un código imperfecto pero que comunicó bien su proceso puede pasar una entrevista. Y alguien con el código correcto pero en silencio total puede no pasar. La entrevista técnica es también una evaluación de cómo vas a ser como colega.
Los tres tipos de entrevista técnica más comunes
1. Live coding — resolución de algoritmos
El tipo más conocido. Te dan un problema (de arrays, strings, árboles, grafos, DP) y tenés que resolverlo en tiempo real, generalmente en una plataforma compartida como HackerRank, CoderPad, o incluso Google Docs.
Este es el tipo que más nervios genera y más práctica requiere. No porque sea el más difícil conceptualmente, sino porque la presión del tiempo y del otro mirando cambia todo.
El framework de los 5 pasos para live coding:
- Repetí el problema en tus palabras para confirmar que entendiste
- Preguntá por los casos edge antes de escribir código
- Pensá en el approach en voz alta antes de codear
- Escribí código limpio con nombres de variables que se explican solos
- Testeá con los ejemplos dados y con al menos un caso edge propio
2. Take-home challenge
Un proyecto o ejercicio para hacer en tu tiempo (generalmente 3-7 días). Es más cercano al trabajo real, pero también es evaluado con más exigencia porque no tenés restricción de tiempo.
Lo que diferencia una entrega buena de una mediocre:
- README claro: explicá las decisiones de diseño, cómo correr el proyecto, y qué mejorarías si tuvieras más tiempo
- Tests: al menos tests unitarios de la lógica central. Muestra que pensás en la calidad del código
- Código organizado: separación de responsabilidades, nombres descriptivos, sin código comentado al azar
- Sin over-engineering: hacé lo que piden, no más. Agregar features no pedidas raramente suma puntos
3. System design
Para roles semi-senior en adelante. Te piden diseñar la arquitectura de un sistema: "diseñá un sistema de mensajería como WhatsApp" o "cómo diseñarías el backend de un feed de redes sociales".
No hay una respuesta correcta única — lo que evalúan es cómo razonás sobre tradeoffs, escalabilidad, consistencia y disponibilidad.
Un framework útil para system design:
- Clarificá el alcance: ¿cuántos usuarios? ¿qué features son prioridad?
- Estimá el orden de magnitud (usuarios, requests por segundo, storage)
- Diseñá el API de alto nivel primero
- Describí los componentes principales y cómo se conectan
- Identificá los bottlenecks y cómo los resolverías (caché, particionado, CDN)
- Discutí tradeoffs de las decisiones que tomaste
Cómo practicar de forma efectiva
El error más común en la preparación es hacer muchos problemas de forma pasiva: leer la solución, entenderla, y pasar al siguiente. Eso no sirve para una entrevista real, donde tenés que producir la solución bajo presión.
La práctica efectiva es activa y verborrágica:
- Tiempo límite siempre. Ponete un timer de 30-45 minutos por problema. Si no llegaste, revisás la solución, la entendés, y lo intentás de nuevo al día siguiente sin mirar el código.
- Hablá en voz alta mientras resolvés. Aunque estés solo. Esto entrena el hábito de verbalizar el proceso que es clave en el live coding real.
- Grabate ocasionalmente. Ver cómo explicás un problema desde afuera es muy revelador. ¿Sos claro? ¿Tenés mucho tiempo en silencio? ¿Digresás?
- Hacé mock interviews con otras personas. Pramp, interviewing.io, o simplemente un colega que te entreviste. El factor humano cambia todo.
- Revisá los errores, no los éxitos. Los problemas que resolviste bien no te enseñan mucho. Los que fallaste, sí.
Recursos concretos para prepararse
Algoritmos
LeetCode
Empezá con el plan "Top Interview 150". Priorizá Easy y Medium antes de ir a Hard.
Algoritmos
NeetCode.io
Roadmap estructurado por temas con videos explicativos. Muy bueno para quienes empiezan de cero con LeetCode.
System Design
System Design Primer
Repositorio de GitHub con guías detalladas de todos los componentes. Gratis y muy completo.
System Design
Designing Data-Intensive Applications
El libro de Martin Kleppmann. El más recomendado para entender sistemas distribuidos en profundidad.
Mock interviews
Pramp
Mock interviews peer-to-peer gratuitas. Simulás el formato real con otra persona.
Mock interviews
interviewing.io
Entrevistas anónimas con ingenieros de empresas tech. Algunas gratuitas, otras pagas.
Behavioral
Cracking the Coding Interview
El clásico. Tiene una sección excelente sobre las preguntas conductuales además de los algoritmos.
Práctica
Codewars
Más enfocado en la práctica diaria que en la preparación de entrevistas. Bueno para mantener el ritmo.
Los 5 errores más comunes en live coding
- Empezar a escribir código inmediatamente sin clarificar el problema. Siempre hay ambigüedad intencional. Hacer preguntas es una señal positiva, no de ignorancia.
- Quedarse en silencio total. Si no sabés cómo avanzar, decilo: "Estoy pensando en un enfoque de fuerza bruta primero, aunque sé que no es óptimo. ¿Procedería así o preferís que piense en algo más eficiente?"
- No considerar los casos edge. ¿Qué pasa si el array está vacío? ¿Si hay duplicados? ¿Si el input es null? Mencionarlos te suma puntos aunque no los implementes todos.
- Pedir pistas demasiado rápido. El entrevistador espera que luchés un poco. Dar por perdido a los 5 minutos muestra poca resiliencia. Pero tampoco te bloquees 20 minutos en silencio — pedí una hint cuando lo necesitás.
- No testear el código al final. Corré mentalmente el código con los ejemplos del enunciado. Anotá los valores de las variables. Esto demuestra rigor.
El aspecto menos hablado: la mentalidad
Las entrevistas técnicas bajo presión generan ansiedad incluso en personas muy competentes. Eso es completamente normal. El problema es cuando la ansiedad bloquea el acceso al conocimiento que tenés.
Algunas técnicas que funcionan:
- Reformulá la presión como señal positiva: la activación fisiológica que sentís (pulso acelerado, tensión) es energía. Tu cerebro la está generando para que te desempeñes mejor, no peor.
- Tomá una pausa visible: si te trabás, está bien decir "déjame pensar 30 segundos en silencio". Muestra autoregulación, no debilidad.
- Rehearsal repetido: la ansiedad de entrevista se reduce con exposición. Hacé tantas mock interviews como puedas antes de la real.
- Separación entre la persona y el resultado: no aprobar una entrevista técnica no dice nada sobre tu valor como desarrollador. Los procesos técnicos son imperfectos y tienen mucho ruido.
Perspectiva desde RRHH: cuando un candidato se traba en un problema técnico pero mantiene la calma, sigue razonando y comunica su proceso, me genera más confianza que uno que resuelve rápido pero sin explicar nada. Lo primero me dice cómo va a trabajar bajo presión en el día a día.
Plan de preparación de 4 semanas
- Semana 1: repasar estructuras de datos básicas (arrays, strings, hashmaps, listas). 1 problema Easy por día en LeetCode.
- Semana 2: árboles, recursión, búsqueda binaria. 1-2 problemas Medium por día. Primera mock interview con colega.
- Semana 3: grafos, BFS/DFS, programación dinámica básica. Practicar system design con 2 sistemas por semana.
- Semana 4: simulacros completos de entrevista (45 minutos, solo, con timer, hablando en voz alta). Al menos 1 mock interview externa (Pramp).