Cómo Pasar una Entrevista de Coding en 2026: Guía Completa
Todavía recuerdo el momento exacto en que supe que la había regado.
El problema era una variación de “merge intervals.” Ya lo había visto. De hecho, ya lo había resuelto — un domingo tranquilo por la tarde, con los pies en el escritorio, música de fondo, cero presión. Pero ahora alguien me estaba observando. Había un cronómetro. Mis manos sudaban y mi cerebro decidió tomarse unas vacaciones.
Escribí un loop anidado. Un loop anidado. Para merge intervals. La cara del entrevistador era educada, lo cual fue peor que si simplemente me hubiera dicho “no.” Cuando llegó el correo de rechazo dos días después, pensé: yo sé esto. Simplemente no pude hacerlo cuando importaba.
Dieciocho meses después. Otra empresa, problema más difícil, y salí sabiendo que lo había clavado. No porque me hubiera vuelto más inteligente. Porque había entendido que pasar entrevistas de coding es una habilidad específica con técnicas específicas, y por fin había dejado de engañarme.
Esto es todo lo que aprendí entre esos dos momentos.
Cómo son las entrevistas de coding en 2026
El formato ha cambiado. No de forma drástica — las empresas no dejaron de hacer preguntas de algoritmos. Pero el panorama se ha diversificado lo suficiente como para que llegar sin saber qué te espera sea más arriesgado que antes.
Esto es lo que te vas a encontrar:
- Coding en vivo clásico — sigue siendo el formato principal. Tú, un editor compartido, uno o dos problemas, 45 minutos. La mayoría de las grandes empresas tech siguen apoyándose en esto.
- Rondas asistidas por IA — esto es lo nuevo. Algunas empresas te dejan usar Copilot o herramientas similares y observan cómo las aprovechas. La dificultad de las preguntas sube para compensar.
- System design + coding combinados — en lugar de rondas separadas, diseñas un sistema y luego implementas una parte. Eficiente para la empresa, brutal para ti.
- Take-home con defensa en vivo — construyes algo en casa y luego defiendes cada línea de código en directo. Están evaluando tu criterio, no solo tu output.
- Pair programming — trabajas en el codebase real de la empresa junto a un miembro del equipo. Cada vez más común en startups.
El fondo no ha cambiado. Si sabes resolver problemas algorítmicos de forma clara y comunicar mientras lo haces, estás por delante del 80% de los candidatos. Todo lo demás es condimento.
Los 8 patrones fundamentales (este es el atajo real)
Algo que me tomó demasiado tiempo entender: no hay tantos tipos de problemas fundamentalmente diferentes. Hay unos ocho patrones base, y la mayoría de las preguntas de entrevista son variaciones de ellos. Una vez que ves el patrón, el problema pasa de “imposible” a “ah, es uno de esos.”
1. Sliding window (ventana deslizante)
Tienes un array o string y necesitas encontrar un subarray/substring que cumpla alguna condición. En vez de revisar cada subarray posible (que es lento), mantienes una “ventana” que se expande y se contrae. Ejemplos clásicos: substring más largo sin caracteres repetidos, suma máxima de un subarray de tamaño k.
La pista: “encontrar un subarray/substring contiguo que…”
2. Two pointers (dos punteros)
Dos índices moviéndose por un array ordenado o una lista enlazada, normalmente uno desde cada extremo o uno rápido y uno lento. Elimina la necesidad de loops anidados. Piensa en: two sum sobre un array ordenado, eliminar duplicados in place, detectar un ciclo.
La pista: entrada ordenada, o estás comparando pares.
3. BFS / DFS (recorrido de grafos y árboles)
BFS usa una cola, explora nivel por nivel. DFS usa una pila (o recursión), baja hasta el fondo antes de retroceder. Los árboles son solo grafos sin ciclos, así que los mismos patrones aplican. Recorrido por niveles, número de islas, camino más corto en un grafo no ponderado — todo es BFS/DFS.
La pista: cualquier cosa con una cuadrícula, árbol, grafo o “componentes conectados.”
4. Binary search (búsqueda binaria)
No es solo “encontrar un elemento en un array ordenado.” El poder real está en la búsqueda binaria sobre el espacio de respuestas — cuando buscas el valor mínimo o máximo que satisface alguna condición. Piensa en: Koko eating bananas, capacidad mínima para enviar paquetes.
La pista: “encontrar el valor mínimo/máximo tal que…”
5. Dynamic programming (programación dinámica)
El que aterroriza a todo el mundo. En esencia: descomponer el problema en subproblemas que se solapan, guardar los resultados para no recalcularlos. Empieza por la relación de recurrencia. Si puedes escribir la solución recursiva, puedes convertirla en DP.
La pista: “contar el número de formas,” “encontrar el mínimo/máximo,” y el problema tiene subestructura óptima.
6. Backtracking (vuelta atrás)
Construir soluciones de forma incremental y abandonar (“backtrackear”) en cuanto sabes que el camino actual no va a funcionar. Permutaciones, combinaciones, N-queens, solucionador de Sudoku. Es simplemente DFS sobre un árbol de decisiones.
La pista: “generar todos los posibles…” o “encontrar todos los válidos…”
7. Heap / Cola de prioridad
Cuando necesitas el k-ésimo más grande, el k-ésimo más pequeño, o estás fusionando k listas ordenadas. Un heap te da O(log n) para inserción y extracción de min/max, que es el punto ideal para estos problemas.
La pista: “k-ésimo más grande,” “top k,” “fusionar k ordenados.”
8. Pila monótona (monotonic stack)
Probablemente el patrón menos intuitivo, pero aparece más seguido de lo que crees. Una pila que mantiene sus elementos en orden. Se usa para “siguiente elemento mayor,” “rectángulo más grande en un histograma,” problemas de temperatura.
La pista: “siguiente elemento mayor/menor,” o estás comparando elementos con sus vecinos en una dirección específica.
Eso es todo. Ocho patrones. No necesitas memorizar doscientos problemas. Necesitas entender profundamente estas ocho formas y reconocer a cuál pertenece un problema nuevo. Cinco a ocho problemas por patrón, y empezarás a verlos en todas partes.
El framework de 5 pasos (úsalo durante la entrevista)
Esta es la parte que realmente cambió mis resultados. No fue saber más algoritmos — fue tener un proceso repetible para los 45 minutos en que me estaban observando.
Paso 1: Clarificar (2-3 minutos)
Antes de escribir un solo carácter de código, haz preguntas. ¿Cuáles son las restricciones de la entrada? ¿El array puede estar vacío? ¿Hay duplicados? ¿Qué debo retornar si no hay respuesta válida?
Yo solía saltar esto porque pensaba que me hacía ver lento. No es así. Te hace ver cuidadoso. Y más de una vez, las preguntas de clarificación revelaron que el problema era diferente de lo que había asumido inicialmente.
Paso 2: Fuerza bruta primero (3-5 minutos)
Describe la solución más simple que podría funcionar, aunque sea O(n^3). Dilo en voz alta. “La fuerza bruta sería revisar cada par, lo cual es O(n al cuadrado).” Pasan dos cosas: el entrevistador ve que puedes razonar sobre el problema, y tienes una base desde la cual optimizar. A veces la fuerza bruta es realmente aceptable. A veces dispara la idea para el enfoque óptimo.
Paso 3: Optimizar (5-8 minutos)
Aquí es donde entran los patrones. Pregúntate: ¿puedo ordenar primero? ¿Puedo usar un hashmap para evitar un loop anidado? ¿Es un sliding window? ¿Aplica búsqueda binaria? Repasa cada posibilidad en voz alta. El entrevistador quiere escuchar tu razonamiento, no solo tu respuesta final.
Si estás atascado, dilo. “Estoy intentando bajar de O(n al cuadrado) pero aún no veo cómo. Déjame pensar si un enfoque de two pointers funciona aquí…” Eso es infinitamente mejor que el silencio.
Paso 4: Codear (15-20 minutos)
Escribe código limpio. Usa nombres de variables con sentido. No x y temp — left, right, current_sum, max_length. Olvídate de los one-liners elegantes. Si necesitas una función auxiliar, créala. La legibilidad importa más que la elegancia en una entrevista.
Empieza desde arriba. No saltes de un lado a otro. Escribe la firma de la función, maneja los casos borde primero, luego la lógica principal.
Paso 5: Testear (3-5 minutos)
Recorre tu código con un ejemplo pequeño. Trázalo línea por línea. Revisa casos borde: entrada vacía, un solo elemento, todos duplicados, números negativos. Encuentra tus propios bugs antes de que lo haga el entrevistador.
Este paso me salvó dos veces. Una vez atrapé un error de off-by-one que hubiera hundido mi solución. El entrevistador literalmente dijo “buena captura” y pude ver la nota subiendo en tiempo real.
La técnica de “pensar en voz alta”
Le dedico una sección completa a esto porque es la palanca más poderosa que tienes, y casi nadie la practica bien.
Esto es lo que pasa en la cabeza del entrevistador cuando estás en silencio: nada útil. No puede darte crédito por pensar. No puede redirigirte si vas por el camino equivocado. No puede escribir “enfoque de resolución sólido” en su feedback porque no tiene evidencia de uno.
Pensar en voz alta significa narrar tu proceso de pensamiento continuamente:
- “Veo que el array está ordenado, así que estoy pensando en two pointers.”
- “Esto parece un problema de sliding window porque estamos buscando un subarray contiguo.”
- “Voy a probar un hashmap para guardar frecuencias — eso debería permitirme verificar existencia en O(1).”
- “Espera, creo que hay un bug en mi condición del while. Déjame trazar con la entrada [1, 2, 3].”
Al principio se siente absurdo. Como si estuvieras haciendo una cirugía mientras narras un programa de cocina. Pero después de una semana de práctica, se vuelve automático. Y transforma la entrevista: de un examen pasa a ser una conversación.
Yo practiqué resolviendo problemas mientras me grababa. Lo reproduje después. La primera grabación fue dolorosa — silencios largos, murmullos, frases a medias. Para la grabación número diez, sonaba como un ser humano normal explicando su trabajo. Eso es todo lo que necesitas.
Estrategia de práctica que realmente funciona
Déjame ahorrarte el error que yo cometí: pasé mi primer mes machacando problemas random en LeetCode como una máquina tragamonedas. Sin estructura, sin revisión, solo “dame otro medium.” Resolví unos 80 problemas y retuve aproximadamente cero.
Esto es lo que realmente funciona:
Volumen: 80 a 120 problemas en total. Eso es todo. Si estás haciendo más, estás machacando sin aprender. La distribución importa más que la cantidad: más o menos 20% easy (para calentar y ganar confianza), 60% medium (aquí es donde viven las entrevistas), 20% hard (para estirar tu pensamiento, no para memorizar soluciones).
Organiza por patrón, no al azar. Haz 5-8 problemas de sliding window seguidos. Luego 5-8 de two pointers. Luego BFS/DFS. Cuando agrupas por patrón, tu cerebro empieza a abstraer la forma común en lugar de memorizar soluciones individuales.
Repetición espaciada. Después de resolver un problema, márcalo. Vuelve en 3 días. ¿Puedes resolverlo de nuevo sin mirar tus notas? Si sí, vuelve en una semana. Si no, no aprendiste el patrón — vuelve mañana. Esta es la diferencia entre retención a corto plazo y a largo plazo, y eso importa porque tu entrevista puede ser semanas después de tu última sesión de práctica.
Plataformas: LeetCode sigue siendo el estándar. NeetCode tiene excelentes listas de problemas organizadas por patrón. Para simulacros de entrevista, prueba Pramp (gratis, con personas reales) o interviewing.io. La plataforma importa menos que la constancia.
Cronométrate. Siempre. 25 minutos para un medium. Si no lo resuelves en 25, mira el enfoque (no el código), luego inténtalo de nuevo desde cero. La práctica sin cronómetro es una trampa — construye una confianza que se evapora bajo presión.
Errores comunes (los he cometido todos)
Lanzarte directo al código. El entrevistador plantea el problema y tú empiezas a teclear. Sin clarificar, sin fuerza bruta, sin discusión. Estás codeando a ciegas y ni siquiera lo sabes.
Optimizar demasiado pronto. Tienes una fuerza bruta que funciona pero pasas 20 minutos buscando la solución óptima y se te acaba el tiempo sin nada que mostrar. Un O(n^2) que funciona le gana a un O(n) incompleto.
El silencio bajo presión. Ya insistí en esto, pero vale la pena repetirlo. El silencio no es neutral en una entrevista. El silencio es negativo.
Ignorar los casos borde. Arrays vacíos, un solo elemento, números negativos, desbordamiento de enteros. Los entrevistadores se dan cuenta cuando no piensas en esto.
Rechazar las pistas. Cuando el entrevistador dice “¿y si el array estuviera ordenado?” te está ayudando. Toma la pista. Decir “ah, entonces podría usar búsqueda binaria” muestra adaptabilidad, no debilidad.
Practicar solo problemas hard. La trampa del ego. Los hard son satisfactorios para presumir, pero la mayoría de las entrevistas son nivel medium. Un candidato que resuelve limpiamente dos mediums siempre le va a ganar a un candidato que batalló con un hard.
No revisar tus errores. Resolver un problema mal y pasar al siguiente es peor que no resolverlo. Lleva un registro. Dos líneas por problema: qué te trabó, qué harías diferente. Ese registro se convierte en oro durante tu última semana de preparación.
Preguntas que siempre me hacen
¿Necesito resolver el problema de forma óptima para pasar?
No siempre. Si explicas claramente la fuerza bruta, identificas por qué es lenta, y avanzas hacia lo óptimo — aunque no llegues del todo — muchos entrevistadores te van a aprobar. El proceso importa tanto como el resultado. He visto candidatos pasar con una solución ligeramente subóptima porque su comunicación era excelente.
¿Cuántos problemas de LeetCode son “suficientes”?
Calidad sobre cantidad. 80-120 problemas bien entendidos y organizados por patrón le ganan a 300 problemas random que no puedes reproducir una semana después. Si puedes mirar un medium nuevo e identificar el patrón en menos de dos minutos, has hecho suficiente.
¿Debo memorizar soluciones?
No. Memoriza patrones, no soluciones. Si entiendes por qué sliding window funciona para “substring más largo sin caracteres repetidos,” puedes aplicarlo a cualquier problema de subarray contiguo. Si memorizaste la solución específica, te quedas atascado en cuanto el problema cambia un poco.
¿Qué hago si me quedo completamente en blanco durante la entrevista?
Pasa. Incluso a gente con experiencia. Aquí va el plan de recuperación: vuelve al paso 1. Relee el problema. Repite las restricciones en voz alta. Prueba con la entrada más pequeña posible. Dibújalo. Habla de lo que sí sabes. “Sé que esto involucra un recorrido de grafo, solo estoy determinando cuál encaja mejor.” Los entrevistadores respetan la capacidad de recuperarse más de lo que crees.
Si aún no lo has hecho, lee cómo preparar una entrevista técnica para el plan de estudio completo de 6 semanas, y descarga la checklist de entrevista técnica para tus últimas 48 horas de preparación.
¿Listo para dejar de adivinar y empezar a prepararte? Únete al acceso anticipado →