Preparación de Entrevistas de Codificación: Patrones, Plataformas y Práctica

Qué prueba realmente una entrevista de programación (señal frente a ruido)

Una entrevista de programación no es un examen de algoritmos. El entrevistador ya tiene la respuesta. Lo que está midiendo, en términos generales, es: ¿puede el candidato aclarar un problema ambiguo?, ¿puede elegir una estructura de datos que se ajuste a las restricciones?, ¿puede escribir código que compile y se ejecute correctamente la primera vez con entradas pequeñas?, y ¿puede explicar los compromisos sin estar a la defensiva cuando se cuestiona? El algoritmo real es el más fácil de los cinco.

Esto importa porque la mayoría de los candidatos invierten demasiado en el eje incorrecto. Resuelven cuatrocientos problemas de LeetCode pero se paralizan cuando el entrevistador interrumpe con «¿y si la entrada no cabe en la memoria?» Memorizan la recursión de merge-sort pero no pueden decir en voz alta por qué es n log n en lugar de n al cuadrado. Escriben la solución óptima y luego no pueden depurar un error de un carácter porque nunca han escrito el problema desde cero en un editor real.

La señal que un entrevistador busca es un pequeño conjunto de comportamientos:

• El candidato reformula el problema con sus propias palabras antes de escribir nada.
• El candidato nombra la estructura de datos que está buscando y explica por qué antes de declararla.
• El candidato escribe código en el orden aproximado en que una persona lo escribiría — no en el orden en que un libro de texto lo imprimiría.
• El candidato repasa un pequeño ejemplo a mano antes de afirmar que ha terminado.
• El candidato, cuando se le cuestiona, dice «tienes razón» o «déjame pensar en eso» en lugar de defender la respuesta incorrecta.

Todo en esta guía está al servicio de producir esos cinco comportamientos. Los patrones, las plataformas, las opciones de lenguaje — todo se reduce a: ¿puedes, en una máquina desconocida, con alguien observando, demostrar que piensas como un ingeniero en lugar de como alguien que ha memorizado soluciones?

Los ocho patrones de estructura de datos que cubren ~80% de las preguntas

Si repasas las preguntas de teléfono y presenciales de los últimos dos años de un bucle típico de nivel FAANG y las agrupes por enfoque, los mismos ocho patrones aparecen una y otra vez. Interiorizar estos es más valioso que resolver el doble de problemas sin pensar, porque el reconocimiento de patrones es lo que te lleva cuando la pregunta se formula de una manera que nunca has visto.

1. Dos punteros

Dos punteros es la respuesta cuando el problema está en un array ordenado, una cadena o una lista enlazada, y necesitas pares, particiones o reorganización en el lugar. El coste es lineal en la entrada; la memoria es constante. Las indicaciones clásicas son "suma de dos en array ordenado", "eliminar duplicados en el lugar", "contenedor con más agua" e "¿es esta cadena un palíndromo?" Si el problema dice ordenado, palíndromo o en el lugar, recurre a dos punteros antes que a cualquier otra cosa.

La trampa es no mantener el invariante. Cada vez que se mueven los punteros, deberías poder decir en una frase qué es verdadero entre ellos — por ejemplo, "todo a la izquierda de i no es duplicado, todo a la derecha de j no está procesado". Si no puedes articular el invariante, tu bucle estará desplazado por uno.

2. Ventana deslizante

La ventana deslizante es la pariente cercana de dos punteros. Úsala cuando el problema pide un subarray o subcadena contigua con una propiedad — subcadena más larga sin caracteres repetidos, ventana más pequeña que contiene todas las letras, suma máxima de tamaño k. Ambos punteros se mueven hacia adelante; la ventana crece a la derecha y se reduce a la izquierda cuando se viola la propiedad. Tiempo lineal, espacio constante o limitado por el alfabeto.

El diagnóstico son las palabras contiguo y subarray o subcadena. El error a evitar es tratarlo como bucles anidados con un atajo — si te encuentras recomputando el contenido de la ventana desde cero en cada paso, has vuelto a O(n²) y has perdido el punto.

3. BFS y DFS en árboles y gráficos

La búsqueda en amplitud (BFS) es para caminos más cortos en gráficos sin pesos, recorrido en orden de nivel de árboles y cualquier problema donde la respuesta depende de la distancia. La búsqueda en profundidad (DFS) es para conectividad, orden topológico, detección de ciclos y la mayoría de preguntas recursivas sobre árboles. Ambas son lineales en el tamaño del gráfico o árbol.

En una entrevista, la elección suele ser obvia por una palabra clave. Más corto, número mínimo de pasos o nivel — eso es BFS con una cola. Todos los caminos, contar componentes, ¿podemos llegar? — eso es DFS con recursión o una pila explícita. Sé lo suficientemente fluido como para poder escribir la forma iterativa de ambas sin tener que pensar.

4. Montículo y top-k

Cuando la pregunta pide "los k mayores", "los k menores", "la mediana de una secuencia" o "combinar k listas ordenadas", la respuesta es un montículo. Un montículo mínimo de tamaño k resuelve los k mayores en O(n log k). Dos montículos — un montículo mínimo de la mitad superior y un montículo máximo de la mitad inferior — te dan una mediana continua.

El valor de la entrevista de reconocer este patrón es principalmente en la explicación. Deberías poder decir, antes de escribir cualquier código, "Mantendré un montículo mínimo de tamaño k; inserto cada elemento y extraigo cuando el tamaño excede k; al final, el montículo contiene la respuesta". Esa frase sola a menudo es la respuesta.

5. Búsqueda binaria en la respuesta

La búsqueda binaria vanilla — encontrar un valor en un array ordenado — rara vez se pregunta ya porque todos la han memorizado. La variante interesante es la búsqueda binaria en la respuesta: cuando el problema tiene un predicado monótono, busca binariamente el rango de respuestas posibles y comprueba la viabilidad en cada punto medio.

Ejemplos: "divide este array en k subarrays contiguos minimizando la suma más grande", "encontrar el número más pequeño de páginas que un trabajador puede leer para que todos los libros se terminen en m días", "minimizar la distancia máxima entre estaciones de gasolina". El patrón siempre es el mismo — define un predicado feasible(x) que sea monótono en x, busca binariamente x, y devuelve la más pequeña o más grande x para la que el predicado se cumple. Si puedes nombrar el predicado en voz alta, tienes la solución.

6. Familias de programación dinámica

La programación dinámica es el patrón que más intimida a los candidatos y es también el que tiene la taxonomía más limpia. La mayoría de los problemas de DP caen en una de cinco familias:

• Estado unidimensional — subir escaleras, robo de casa, variantes de Fibonacci. El estado es un índice; la recurrencia depende de un número constante de estados anteriores.
• Cuadrícula bidimensional — caminos únicos, suma de camino mínimo, distancia de edición, subsecuencia común más larga. El estado es un par de índices.
• Mochila — mochila 0/1, suma de subconjunto, cambio de moneda. El estado es "artículos considerados hasta ahora × capacidad restante".
• DP de intervalo — explotar globos, multiplicación de cadena de matrices, partición de palíndromos. El estado es un par de índices que definen un rango.
• DP en árboles — robo de casa III, camino más largo en un árbol binario. La recurrencia está en resultados de subárbol combinados en el padre.

Si puedes identificar la familia en los primeros treinta segundos, la recurrencia suele ser mecánica. La trampa es pasar directamente al código — escribe la recurrencia en la pizarra primero, luego el caso base, luego el orden de iteración, luego el código. Invierte esto y pasarás el resto de la ronda parchando bugs.

7. Retroceso

El retroceso es la fuerza bruta a la que recurres cuando el problema pide todas las soluciones — todas las permutaciones, todas las combinaciones, todos los subconjuntos, todos los tableros de Sudoku válidos, todas las formas de particionar una cadena en palíndromos, N-reinas, búsqueda de palabras. La estructura es recursiva: intenta una opción, recurre, deshaz la opción, intenta la siguiente.

Las dos habilidades que el entrevistador busca son la poda y el paso deshacer. La poda es la diferencia entre exponencial y simplemente grande; el deshacer es la diferencia entre correcto y un error sutil. Siempre declara, antes de codificar: «Elijo, recurro, y deshago al regresar». Si olvidas deshacer, corromperás silenciosamente el estado para la siguiente rama.

8. Patrones de recorrido de grafos

Más allá de BFS y DFS simples, dos patrones de grafos aparecen lo suficientemente a menudo para merecer su propio lugar. Ordenamiento topológico — para problemas de estilo curso-horario con requisitos previos, plazos de horario y resolución de dependencias. Las dos implementaciones son el algoritmo de Kahn con grados de entrada y una cola, y un post-orden basado en DFS. Cualquiera está bien; elige el que puedas escribir sin pensar.

Union-find (conjunto disjunto) — para preguntas de conectividad, detección de aristas redundantes, el número de provincias, fusión de cuentas, y la mayoría de problemas «¿están estos dos nodos en el mismo componente?». Con compresión de caminos y unión por rango, el costo amortizado es efectivamente constante por operación. Memoriza la implementación de ocho líneas; la usarás más de lo que esperas.

Juntos estos ocho patrones — dos punteros, ventana deslizante, BFS/DFS, heap top-k, búsqueda binaria en la respuesta, familias DP, retroceso, y ordenamiento topológico más union-find — cubren aproximadamente el ochenta por ciento de cada ronda de codificación que verás. El veinte por ciento restante es principalmente tries, árboles de segmentos y manipulación de bits, que vale la pena conocer pero que rara vez aparecen en una pantalla de una hora.

Complejidad temporal, correctamente: cómo hablar de Big-O en la pizarra

La mayoría de los candidatos pueden recitar que la inserción en una tabla hash es O(1) y merge-sort es O(n log n). Muy pocos pueden hacer lo que realmente importa en una entrevista: derivar la complejidad a partir del código que tienen delante, en voz alta, sin vacilar.

El procedimiento mecánico es:

1. Identifica los bucles y las recursiones. Un único bucle sobre la entrada es O(n). Dos bucles anidados sobre la misma entrada es O(n²). Un bucle con un paso de división por dos es O(log n). Una recursión que se divide por la mitad y realiza trabajo lineal en cada nivel es O(n log n).
2. Multiplica en los anidamientos, suma en secuencia. Un bucle que contiene una búsqueda en tabla hash es O(n) en total, no O(n²). Un bucle seguido de un ordenamiento es O(n + n log n) = O(n log n).
3. Establece el término dominante. O(n + log n) es O(n). O(n² + n) es O(n²). Descarta los términos de orden inferior y los factores constantes.
4. Establece por separado el espacio. Memoria auxiliar es lo que tu código asigna más allá de la entrada. Una recursión tiene espacio de pila; una tabla hash tiene espacio O(n); el ordenamiento in situ es O(1) extra.

Practica esto en voz alta. La señal de un candidato experimentado es que diga «esto es O(n log n) en tiempo y O(n) de espacio adicional, dominado por el ordenamiento y el array auxiliar» antes de que el entrevistador lo pregunte. Decirlo primero señala confianza; decirlo después, en un tono defensivo, señala que estás adivinando.

Cuando el entrevistador cuestiona —y a menudo lo hace, especialmente sobre el factor constante— el movimiento correcto es involucrarse con la objeción específica en lugar de recitar el análisis asintótico nuevamente. «Tienes razón, el factor constante aquí es grande porque cada comparación realiza una copia de cadena; si precomputamos las claves, la constante disminuye aproximadamente por un factor de k» es una buena respuesta. «Bueno, asintóticamente sigue siendo O(n log n)» es una mala.

Plataformas de codificación en vivo: donde realmente ocurren las entrevistas

Los reclutadores en 2026 distribuyen las rondas de codificación en aproximadamente siete plataformas. Cada una tiene sus propias peculiaridades; el editor que se siente natural en una es lento en otra. Practicar solo en tu IDE es un error — las peculiaridades de la plataforma se convierten en tus peculiaridades durante una ronda de alto riesgo.

• LeetCode es el corpus de problemas más grande y lo más cercano a una lingua franca compartida para preguntas de entrevista. El editor es adecuado para problemas cortos, menos agradable para problemas largos; el ejecutor de pruebas es rápido; los hilos de discusión son una fuente subestimada de reconocimiento de patrones.
• HackerRank es lo que la mayoría de las grandes empresas utilizan para su primer examen técnico — empresas en finanzas, consultoría y tecnología tradicional. Su cobertura de lenguajes es amplia, pero su editor es más pesado y los casos de prueba son más estrictos sobre el análisis de entrada.
• Coderpad es la arena de colaboración en vivo que la mayoría de las empresas de software modernas utilizan durante la entrevista real. Admite ejecución conforme escribes para muchos lenguajes y tiene una herramienta de dibujo integrada para discusiones de diseño de sistemas.
• CodeSignal ejecuta la Evaluación General de Codificación que varios empleadores grandes utilizan como una puntuación estandarizada única. Sus problemas están cronometrados y son variados; el ritmo es la habilidad principal.
• InterviewBit tiene una pista curada de problemas organizados por tema, lo que facilita practicar un patrón único a la vez. El editor está más cerca de LeetCode que de Coderpad.
• HackerEarth se utiliza ampliamente en India y por empresas que contratan a nivel mundial; la calidad de los problemas varía pero la plataforma es confiable.
• Codility es la plataforma elegida por varias empresas europeas; el conjunto de pruebas es opaco (no siempre ves qué caso falló), lo que lo convierte en un proxy útil para la disciplina de razonar sobre casos límite sin la red de seguridad de un depurador.

Practica en al menos dos de estas antes de cualquier entrevista real. Usa una para amplitud (LeetCode) y otra para la sensación de un editor compartido en vivo (Coderpad). El costo cognitivo de la plataforma en sí debe acercarse a cero para cuando estés en una ronda real.

Lenguajes que vale la pena elegir: cuándo escoger cuál

No necesitas conocer doce lenguajes para entrevistar bien. Necesitas uno en el que puedas pensar, y un conocimiento de lectura básico de uno o dos más. Aquí está la lista honesta, en el orden aproximado en el que la mayoría de candidatos deberían considerarla.

• Python es la opción predeterminada. Sintaxis concisa, librería estándar muy completa (collections.Counter, heapq, bisect), sin código repetitivo, y un runtime tolerante. Se recomienda a menos que el rol lo demande específicamente.
• JavaScript y TypeScript son opciones razonables para roles de front-end y full-stack. JavaScript tiene una sintaxis amigable para entrevistas; TypeScript añade tipos pero te ralentiza un poco porque el compilador es más exigente. Elige TypeScript solo si el rol es explícitamente tipado.
• Java es la opción segura para roles backend en grandes empresas y para cualquier empresa donde el entrevistador probablemente escriba Java. La verbosidad es un precio; el sistema de tipos atrapa errores que Python no atrapará.
• C++ es la opción correcta para roles de sistemas, infraestructura e ingeniería de juegos, y para empresas donde el entrevistador espera ver iteradores y std::priority_queue. La aritmética de punteros y la ausencia de recolección de basura te dan más formas de cometer errores bajo presión de tiempo.
• Go es cada vez más común en roles de infraestructura backend y DevOps. La señal de entrevista está principalmente en preguntas de concurrencia; si puedes escribir una implementación correcta de productor-consumidor con goroutine + canales, has demostrado que entiendes el lenguaje.
• Rust es raro en rondas de entrevistas pero apareciendo cada vez más en empresas centradas en sistemas. La fricción del borrow-checker es real; no elijas Rust para una entrevista a menos que hayas practicado con él específicamente.
• Kotlin es la opción correcta para Android y un número creciente de roles backend de JVM; la sintaxis es más amigable que Java y la librería estándar está más cerca de la de Python.
• Ruby es raro fuera de empresas centradas en Rails; úsalo solo si el rol lo requiere.
• SQL es su propia disciplina y aparece en entrevistas de ingeniería de datos y análisis. Las funciones de ventana, expresiones de tabla común, y la diferencia entre WHERE y HAVING son los puntos de diferenciación consistentes.
• PHP todavía aparece en empresas con instalaciones maduras de WordPress o Drupal; raramente es la opción correcta para entrevista a menos que el rol lo demande.
• Scala aparece en empresas de plataformas de datos (Spark, Akka). Las características funcionales son poderosas en respuestas de entrevista pero solo si ya dominas el lenguaje.

El error más grande que cometen los candidatos con el lenguaje es cambiar bajo presión. Si has pasado seis meses practicando intensivamente en Python, no cambies a Java la mañana de la entrevista porque creas que la empresa "prefiere" Java. Prefieren código correcto y funcional en cualquiera de los lenguajes compatibles. Usa el que tus dedos conocen.

Rondas de system design: un marco breve para la preparación de código

Para bucles de código senior, el system design es la otra mitad de la ronda. La estructura de 45 minutos — aclarar, estimar, nivel alto, profundizar, compromisos — es la misma independientemente del rol, y las expectativas nivel a nivel cambian bruscamente: L3 a menudo obtiene un diseño orientado a objetos (estacionamiento, máquina expendedora); L4 una pregunta real de sistemas distribuidos (URL shortener, rate limiter); L5+ la expectativa senior de que dirijas la ronda y nombres compromisos sin ser preguntado.

La escala de niveles completa, la estructura de cinco componentes, y la lista de lectura recomendada (el System Design Interview de Alex Xu y el Designing Data-Intensive Applications de Kleppmann) se encuentran en nuestra guía de entrevista de ingeniero de software. Para preparación centrada en código, trata el system design como el pilar que viene después de la fluidez con patrones: los patrones y Big-O son lo mínimo necesario; system design es lo que separa la señal senior de la señal de nivel medio, y tiene que ser practicado de manera diferente — escribiendo casos, no escribiendo código.

Cómo la IA cambia la preparación para entrevistas de codificación

Lo más útil que hace la IA en la preparación para entrevistas de codificación hoy, también es lo menos vistoso: te proporciona un revisor incansable que puede examinar la solución que acabas de escribir, identificar el error, clasificarlo en uno de los ocho patrones y generar una pregunta de seguimiento de la misma familia.

Tres usos concretos vale la pena comprometerse a utilizar:

Ejercicios de reconocimiento de patrones. Pega un enunciado de problema en un modelo y pregunta, antes de leer más, «¿cuál de los ocho patrones es este y por qué?» Compara la respuesta del modelo con la tuya. Después de cincuenta problemas, tu reflejo de reconocimiento de patrones será más agudo que si resuelves el doble de problemas sin el meta-paso.

Revisión de código en tus propias soluciones. Una vez que hayas enviado, pídele al modelo que critique el código como si fuera un ingeniero senior en una revisión de código. Pregunta específicamente: ¿hay casos extremos que me perdí; es el nombre de variable claro; hay una línea de código que estoy usando que oscurece la lógica; la complejidad de tiempo coincide con las restricciones. Las críticas honestas superan el reflejo de «¡buen trabajo!»

Asistencia en vivo durante entrevistas reales. Esto es para lo que está construido Acedly: el reclutador en Zoom hace la pregunta, el asistente la transcribe, identifica el patrón, redacta un esquema fundamentado en tu currículum y renderiza el esquema en una pantalla que el entrevistador no puede ver — típicamente en menos de doscientos milisegundos. El asistente no escribe el código por ti; expone el patrón correcto y la estructura inicial adecuada para que tu presupuesto cognitivo vaya a escribir la solución en lugar de recordar si esto es ventana deslizante o dos punteros.

El error en los tres usos es dejar que el modelo piense por ti. Los ejercicios funcionan porque te comprometes con una respuesta primero y luego verificas; la revisión de código funciona porque ya has escrito código; la asistencia en vivo funciona porque ya has practicado los patrones y solo necesitas un aviso para disparar el recuerdo. Usada incorrectamente, la IA reemplaza tu cerebro. Usada correctamente, externaliza la logística para que tu cerebro sea libre de hacer la parte en la que realmente es bueno.

Preparación asistida por IA vs LeetCode grind vs plataformas de simulacro vs libros de texto

La mayoría de los candidatos hacen alguna mezcla de los cuatro. La pregunta no es cuál es el mejor, sino cuál mezcla se ajusta a tu debilidad. Aquí está la comparación honesta.

Feature	Preparación asistida por IA	LeetCode grind	Plataformas de entrevista simulada	Libros de texto (CLRS, EPI)
Mejor para	Reconocimiento de patrones, revisión de código, asistencia en vivo	Volumen y amplitud	Presión de tiempo y explicación verbal	Fundamentos, prueba y profundidad
Tiempo para la primera señal útil	Misma sesión	Después de ~50 problemas	Después de 2–3 simulacros	Múltiples semanas
Detecta puntos ciegos	Sí, clasificando errores	Solo por intuición	Sí, por retroalimentación del entrevistador	No (lectura pasiva)
Desarrolla la habilidad de hablar en voz alta	Parcial (basado en texto)	Débil	Fuerte	Ninguno
Desarrolla la habilidad de escribir rápido en plataforma extranjera	Indirecto	Fuerte	Fuerte	Ninguno
Costo	Suscripción (a menudo <$50/mo)	Gratis o LeetCode Premium	Cuotas por simulacro, a menudo $50–$150	Costo del libro, tiempo
Riesgo	Dependencia excesiva, omitiendo la escritura	Ceguera de patrones por repetición mecánica	El estilo de coaching varía	Lento, fácil de hojear

La receta combinada en la que se conforman la mayoría de ingenieros que trabajan es: libros de texto para fundamentos en una lectura lenta, LeetCode para volumen durante el viaje y bloques de fin de semana, revisión asistida por IA para reconocimiento de patrones y detección de errores, y un pequeño número de simulacros pagos en las dos semanas antes de un ciclo real. Ninguno de estos es suficiente por sí solo; la mezcla es el punto.

Un plan de preparación de cuatro semanas que realmente funciona

Si tienes cuatro semanas antes de una ronda de entrevistas, el plan siguiente es una distribución viable. No es el único, pero tiene la forma correcta: patrones primero, fluidez en la plataforma segundo, diseño de sistemas tercero, pruebas simuladas último.

• Semana 1 — patrones. Dos horas al día. Elige uno de los ocho patrones cada día laboral. Resuelve cinco problemas de dificultad media en ese patrón. Escribe un análisis de una línea para cada uno. Al final de la semana deberías ser capaz de reconocer cada patrón desde la primera lectura.
• Semana 2 — fluidez del lenguaje en las plataformas. Deja de cambiar. Resuelve quince problemas en LeetCode y diez en la plataforma que usa la empresa (HackerRank, Coderpad, o CodeSignal). La habilidad que se entrena es la velocidad de escritura y la familiaridad con el editor, no el algoritmo.
• Semana 3 — diseño de sistemas. Dedica cuarenta y cinco minutos por sesión, cada día laboral, a una pregunta de diseño diferente. Usa la estructura de cinco fases cada vez. Grábate; reprodúcelo. Los primeros tres son malos. En el quinto, la estructura comienza a sentirse automática.
• Semana 4 — pruebas simuladas y descanso. Dos pruebas simuladas pagadas en la primera mitad de la semana. La segunda mitad: descanso. Problemas más fáciles, un repaso de diseño de sistemas, sueño. No hagas sesiones maratónicas en las últimas cuarenta y ocho horas; el rendimiento marginal es negativo.

Ajusta los pesos a tus carencias. Si tienes ocho años de experiencia en diseño de sistemas y pocas rondas de LeetCode, invierte las semanas uno y tres. Si estás en el inicio de tu carrera con una sólida formación en Ciencias de la Computación, duplica la semana de fluidez de plataforma. La constante es la semana de descanso: cada candidato subestima cuánto importa el sueño en las últimas cuarenta y ocho horas.

Preguntas frecuentes

¿Cuántos problemas de LeetCode realmente necesito resolver?

¿Debo usar Python, Java o C++ para entrevistas de código?

¿Cómo difieren las entrevistas de diseño de sistemas de las rondas de código?

¿Se considera trampa usar IA para prepararse para entrevistas de código?

¿Cuán temprano debo comenzar la preparación para entrevistas de código?

¿Cuál es la única cosa de mayor apalancamiento que puedo hacer esta noche para mejorar?