Cómo Preparar una Entrevista Técnica en 2026
La pantalla estaba compartida. El cronómetro corría. Y yo ahí, con las manos sudadas sobre el teclado, mirando un editor vacío como si hubiera olvidado cómo escribir código.
“Implementa un LRU cache,” me dijo el entrevistador. Así, tranquilo, como quien pide la hora.
Yo sabía hacerlo. Lo había hecho esa misma semana en el trabajo. Pero ahí, con un desconocido observando cada tecla que pulsaba, mi cerebro decidió que era el momento perfecto para apagarse. Escribí class LRUCache. Lo borré. Lo volví a escribir. Lo volví a borrar. Doce minutos así.
No me dieron el puesto. Obvio.
Eso fue hace cinco años. Desde entonces he estado en ambos lados de la mesa — pasé entrevistas en tres empresas y he evaluado a más de sesenta candidatos como senior engineer. Y lo que entendí — tarde, como siempre — es que prepararse para una entrevista técnica es una habilidad independiente. Casi no tiene nada que ver con ser buen ingeniero en el día a día.
Me hubiera gustado que alguien me lo hubiera dicho en su momento.
Antes de estudiar lo que sea
Mi amigo Marc, el año pasado. Lo veo llegar un lunes con unas ojeras brutales. “Estuve grindando programación dinámica todo el fin de semana,” me dice, orgulloso. Problemas de mochila, subsecuencias, el catálogo completo. Tres semanas llevaba así. Su novia estaba a punto de matarlo.
¿Su entrevista? Un take-home de cuatro horas y pair programming sobre su codebase en React.
Tres semanas de DP. Para una sesión de pair programming en React. Todavía se lo recuerdo. No le hace gracia.
La lección: ve a investigar qué pregunta realmente la empresa. Glassdoor, Blind, su blog de ingeniería, su página de Careers — dedícale treinta minutos. Eso es todo. Algunas empresas literalmente describen el proceso. Treinta minutos de investigación te pueden salvar de terminar como Marc.
Esto es lo que te vas a encontrar en 2026:
- Coding en directo — tú, un editor compartido, un problema, 30-45 minutos. Alguien mirándote pensar. El formato que se niega a morir.
- Take-home — “debería tomar 3-4 horas.” Mentira. Presupuesta el doble.
- System design — sobre todo si tienes 4+ años. Menos sobre lo que sabes, más sobre cómo razonas.
- Pair programming con código real — las startups adoran esto. Se acerca más al trabajo real, lo cual lo hace más difícil, paradójicamente.
- Comportamental — la ronda que todo el mundo ignora y que elimina gente en silencio.
En fin. Averigua el formato primero. Todo lo demás parte de ahí.
El plan que seguiría (sabiendo lo que sé ahora)
Seis semanas. Ese es el punto ideal si estás trabajando a tiempo completo. Una hora al día, quizás hora y media cuando estés concentrado. Si tus bases son sólidas, comprímelo a cuatro. Si no has tocado un algoritmo desde la universidad, estíralo a ocho. El número importa mucho menos que hacer algo todos los días.
Semanas 1-2: descubrir dónde duele.
Me acuerdo de la primera vez que hice esto honestamente. Me senté con cinco problemas variados — arrays, árboles, grafos, uno de DP, strings — y me di permiso para fallar. Sin pistas. Sin Stack Overflow. Solo yo y el problema.
Fue brutal. Me quedé mirando un problema de árboles que en el trabajo habría resuelto en quince minutos. Con Google. Con un debugger. Sin nadie mirándome. Pero sin todo eso, no pude terminarlo.
¿Esa sensación incómoda? Es útil. Es tu cerebro mapeando los huecos. Si los árboles te van bien pero la DP te paraliza, ahora sabes dónde apuntar. No pierdas tiempo repasando lo que ya sabes porque se siente productivo. Yo lo hice. Es procrastinación disfrazada de plan de estudio.
Dos problemas al día. Lee el editorial después, incluso cuando lo resolviste.
Semanas 3-4: cuando los patrones empiezan a encajar.
Hay un momento — y no puedo decirte cuándo llega, porque es diferente para cada persona — donde dejas de ver problemas individuales y empiezas a ver formas. “Ah, esto es sliding window.” “Espera, esto es simplemente BFS con un paso extra.” Ese momento es todo el objetivo de estas dos semanas.
Sliding window, two pointers, BFS/DFS, binary search on answer, templates básicos de DP. Cinco a ocho problemas por patrón, dificultad creciente. Lleva un pequeño registro — dos frases después de cada problema. Qué fallaste, qué aprendiste. Suena tedioso. Es lo que realmente hace que los patrones se queden.
El mío se llamaba notas-entrevista.md. Muy creativo, lo sé.
Semana 5: system design y la ronda comportamental que nadie prepara.
System design: aprende los bloques básicos. Load balancers, caching, message queues, SQL vs NoSQL. Practica diseñando tres o cuatro sistemas clásicos — URL shortener, chat, feed de noticias. El truco no es memorizar arquitecturas. Es entender por qué elegirías una cosa sobre otra, porque el entrevistador va a cuestionar cada decisión.
Comportamental: prepara cinco historias en formato STAR. Un problema técnico difícil. Un desacuerdo. Un fracaso. Un proyecto que lideraste. Sé honesto. Los entrevistadores detectan una historia ensayada de héroe a kilómetros. Un fracaso bien contado con reflexión genuina siempre gana a “y entonces salvé el día.”
Yo pensaba que la ronda comportamental era relleno. Hasta que vi a tres ingenieros sólidos ser rechazados puramente por eso. Me hizo cambiar de opinión bastante rápido.
Semana 6: deja de leer y sal a jugar el partido.
Esta semana importa más que las otras cinco juntas.
Dos o tres mock interviews. Con una persona real. No un chatbot. Alguien que se quede en silencio incómodo mientras piensas, y luego te pregunte “¿puedes optimizar eso?” justo cuando creías que habías terminado.
Y practica en voz alta. No puedo enfatizar esto suficiente. Di lo que estás pensando. “Estoy considerando un hashmap aquí, pero me preocupa el espacio…” Dilo. Incluso cuando se sienta ridículo. Incluso cuando la idea está a medio formar.
Lo que mata a la gente (lo he visto pasar)
Te cuento una escena que he vivido probablemente treinta veces como entrevistador:
Un candidato recibe el problema. Lo lee. Asiente. Y después… silencio. Cinco minutos. Ocho minutos. El cursor se mueve de vez en cuando. Claramente está pensando. Quizás hasta correctamente. Pero yo no tengo idea de qué está pasando en su cabeza. Y cuando se acaba el tiempo y no ha explicado su enfoque, no puedo darle crédito por un razonamiento que nunca escuché.
El silencio es el asesino número uno. No la falta de conocimiento. No las respuestas incorrectas. El silencio.
He rechazado candidatos que sospechaba eran lo suficientemente capaces para el puesto. Porque programaban como si estuvieran solos. Y en una entrevista, eso es lo único que no puedes ser.
Practica narrar tu pensamiento. A un amigo, a una pared, a tu gato. Una vez le expliqué merge sort a mi taza de café en la pausa del almuerzo. Un compañero entró y se fue lentamente. Pero para la entrevista, hablar mientras pensaba ya era automático.
Los otros dos asesinos son más rápidos de explicar: rendirse después de cinco minutos (eso es leer soluciones, no practicar — veinte minutos de incomodidad es donde ocurre el aprendizaje real) y saltarse los mediums para ir directo a los hard porque se siente más productivo. Esto último es puro ego. Lo sé porque lo hice. Y luego un medium con un pequeño giro me destrozó en una entrevista real.
Para que la práctica funcione de verdad
Vuelve a los problemas tres a cinco días después. Si no puedes resolverlos sin pistas, no aprendiste el patrón. Solo lo alquilaste temporalmente.
Siempre usa un cronómetro. Practicar sin tiempo genera falsa confianza.
Explica las soluciones en voz alta. Incluso estando solo. Especialmente estando solo. Mi gato ha escuchado más sobre binary search de lo que cualquier gato debería soportar. No le impresionó nada. Mis habilidades de entrevista mejoraron igual.
Practica con personas reales. Las herramientas de IA están bien para resolver problemas, pero no pueden recrear la presión social. Las preguntas de seguimiento. El silencio.
En fin. Eso es todo para la sección de práctica.
Lo que siempre me preguntan
¿Cuánto tiempo toma esto? Depende. Si ya resuelves problemas regularmente, quizás cuatro semanas. Volviendo de un descanso largo, seis a ocho. La constancia diaria importa más que el total de semanas. Una hora al día le gana a ocho horas un domingo de vez en cuando.
¿Startups vs big tech? Sí, mundos diferentes. Big tech sigue con mucho algoritmo y system design. Las startups se inclinan por take-homes, pair programming, “muéstranos cómo piensas sobre trade-offs.” Algunas hacen ambas cosas ahora. Investiga la empresa. Lo sigo diciendo. Lo voy a seguir diciendo.
¿Cómo sé si estoy listo? Cuando los mediums te toman menos de treinta minutos y puedes hablar sobre tu enfoque todo el tiempo. Si los problemas fáciles todavía te hacen tropezar, necesitas más tiempo. Está bien. Mejor saberlo que entrar sin preparación y quedarte mirando un cursor parpadeante durante doce minutos.
Probablemente debería haber organizado esto mejor. Ni modo.
¿Listo para empezar? Únete a la comunidad de acceso anticipado →