Módulo 7: El proceso de contratación en 2026
5. La entrevista técnica en inglés
Descripción
En la llamada con el recruiter demostraste que existes, que encajas y que sabes de qué hablas. Esta es la etapa donde te piden mostrarlo: resolver un problema, diseñar un sistema o defender el código que ya escribiste, y hacerlo pensando en voz alta en inglés mientras alguien te observa. Aquí es donde la mayoría de los hispanohablantes se pone tensa, y no siempre por falta de habilidad técnica. Se ponen tensos porque creen que la entrevista mide si llegan a la respuesta correcta, cuando en realidad mide algo bastante distinto: cómo piensas cuando no sabes la respuesta todavía.
Ese es el giro que cambia todo. Un entrevistador que ya trabaja en la empresa no te va a pedir que memorices; te va a pedir que trabajes con él durante cuarenta y cinco minutos como trabajarían un martes cualquiera frente a un bug. Le interesa ver si haces buenas preguntas, si organizas tu enfoque antes de escribir, si detectas tus propios errores, si sabes decir "no estoy seguro, déjame verificar". Todo eso es comunicación, y la comunicación es exactamente lo que esta guía te ha estado entrenando. El "pensar en voz alta" que practicaste en el módulo 5 no era un ejercicio de calentamiento: era la habilidad central de esta lección.
Conexión con el módulo: en la lección anterior sostuviste la conversación de encaje con el recruiter. Ahora entras a la sala donde se decide la parte técnica. En la siguiente lección aprenderás a contar tus historias de comportamiento con la estructura STAR; aquí nos quedamos estrictamente en lo técnico: coding, diseño y defensa de un take-home. Esta lección te da la estructura para narrar una solución, el vocabulario para hablar de complejidad y trade-offs, y un plan concreto para cuando te trabas, que es el momento que más se teme y el más fácil de convertir a tu favor.
Antes de empezar: qué evalúa de verdad esta entrevista
Un desarrollador con buen nivel técnico puede reprobar una entrevista técnica por callarse. Y un desarrollador promedio puede pasarla porque hizo el proceso legible. Esto no es injusto ni azar: es que la entrevista técnica, en la práctica de 2026, evalúa el proceso más que el resultado. El entrevistador está tratando de responder una pregunta muy concreta sobre ti: "¿Cómo sería trabajar contigo?"
Piénsalo como una sesión de pair programming disfrazada de examen. En pair programming real, tu compañero no lee tu mente; tú narras lo que haces para que él pueda seguirte, corregirte y aportar. La entrevista es igual. Si resuelves el problema en silencio y escribes la solución perfecta sin decir palabra, el entrevistador se queda sin datos y tiene que asumir lo peor. Si vas diciendo lo que piensas —aunque te equivoques a mitad de camino— le das exactamente lo que vino a buscar.
Esto tiene una consecuencia enorme y muy tranquilizadora para quien carga con el síndrome del impostor lingüístico: no necesitas hablar un inglés bonito, necesitas hablar un inglés legible. No te evalúan por acento ni por gramática perfecta. Te evalúan por si el entrevistador puede seguir tu razonamiento. Un inglés técnico claro, con frases cortas y vocabulario preciso, gana siempre a un inglés "fluido" pero vago. Y las frases cortas con vocabulario preciso son algo que se aprende, no un don. Esta lección es ese vocabulario.
Qué esperar de la logística. La mayoría de las entrevistas técnicas en inglés de 2026 son remotas, de 45 a 60 minutos, en un editor compartido (CoderPad, HackerRank, CodeSignal) o en tu propio editor compartiendo pantalla. Casi siempre hay una persona observando y conversando contigo; a veces dos. Lo importante: están de tu lado más de lo que crees. Su trabajo es contratar, no reprobar; una entrevista donde el candidato brilla les hace la vida más fácil.
La estructura que convierte el caos en una narración
Cuando te dan un problema, la reacción del pánico es lanzarse a escribir código. No lo hagas. Hay una secuencia de seis pasos que sirve para casi cualquier entrevista de coding, y su verdadero valor es doble: te ordena la cabeza y le da al entrevistador una narración limpia que seguir. Los mismos seis pasos son tu guion en inglés.
| Paso | Qué haces | Por qué importa |
|---|---|---|
| 1. Reformular | Repites el problema con tus palabras | Confirmas que entendiste y ganas segundos para pensar |
| 2. Aclarar supuestos | Preguntas sobre bordes, tamaños, tipos | Demuestras que piensas antes de teclear |
| 3. Proponer un enfoque | Dices tu plan en voz alta antes de codificar | Le das al entrevistador la oportunidad de corregirte a tiempo |
| 4. Mencionar trade-offs | Comparas al menos dos caminos | Muestras criterio de ingeniería, no solo mecánica |
| 5. Implementar | Escribes narrando lo que haces | Mantienes al entrevistador contigo, no adivinando |
| 6. Probar | Corres ejemplos, incluidos los bordes | Detectas tus errores antes que él |
Vamos paso a paso, con el inglés que necesitas en cada uno.
Paso 1 — Reformular el problema
No arranques a resolver algo que quizás entendiste mal. Devuelve el problema con tus palabras. Esto te da tres o cuatro segundos de aire y le confirma al entrevistador que están hablando de lo mismo.
Frases modelo en inglés:
"Let me make sure I understand. We need to find the two numbers that add up to the target, and return their indices — is that right?" (Déjame confirmar que entendí. Necesitamos encontrar los dos números que sumen el objetivo y devolver sus índices, ¿correcto?)
"So the input is a list of integers, and the output is a single boolean. Let me restate it back to you." (Entonces la entrada es una lista de enteros y la salida es un solo booleano. Déjame repetírtelo.)
El patrón útil aquí es "Let me make sure I understand…" y "So, if I got it right, …". Son fórmulas de apertura que suenan profesionales y te compran tiempo sin que parezca que dudas.
Paso 2 — Aclarar supuestos
Nadie te va a dar un problema completamente especificado, porque una parte de lo que miden es si preguntas. Las preguntas correctas son señal de seniority. Pregunta por el tamaño de la entrada, los tipos, los casos vacíos, los duplicados, si hay que optimizar memoria o velocidad.
Frases modelo en inglés:
"A couple of clarifying questions before I start. Can the input be empty? And can there be duplicate values?" (Un par de preguntas antes de empezar. ¿Puede la entrada estar vacía? ¿Puede haber valores duplicados?)
"Should I optimize for time or for memory here?" (¿Optimizo por tiempo o por memoria aquí?)
"Are the inputs always valid, or do I need to handle malformed data?" (¿Las entradas son siempre válidas, o tengo que manejar datos mal formados?)
Vocabulario clave de esta fase: edge case (caso borde), constraint (restricción), assumption (supuesto), input / output, empty / null, duplicates, sorted / unsorted.
Paso 3 — Proponer un enfoque antes de codificar
Este es el paso que más candidatos se saltan y el que más impresiona cuando lo haces. Antes de escribir una sola línea, di tu plan. Si es malo, el entrevistador te corrige ahí y te ahorra veinte minutos perdidos. Si es bueno, ya ganaste la entrevista casi entera.
Frases modelo en inglés:
"My first idea is a brute-force approach with two nested loops. It works, but it's O(n²). Let me think if there's something better." (Mi primera idea es un enfoque de fuerza bruta con dos bucles anidados. Funciona, pero es O(n²). Déjame pensar si hay algo mejor.)
"I think a hash map lets me do this in a single pass. Let me walk you through the idea before I code it." (Creo que un hash map me permite hacerlo en una sola pasada. Déjame explicarte la idea antes de codificarla.)
El conector de oro es "Let me walk you through…" (déjame llevarte por…). Es la frase que un ingeniero senior usa a diario para explicar algo a un colega, y suena exactamente igual de natural en una entrevista.
Paso 4 — Mencionar trade-offs
Un trade-off es un compromiso: ganas algo a cambio de perder otra cosa. En ingeniería casi nunca hay una solución perfecta, hay una solución adecuada para un contexto. Nombrar el trade-off en voz alta es la diferencia entre "sé programar" y "sé decidir".
Frases modelo en inglés:
"The hash map approach is faster — O(n) — but it uses extra memory. The two-pointer version is O(n log n) if we sort first, but it's constant space. Given the constraints, I'd go with the hash map." (El enfoque con hash map es más rápido —O(n)— pero usa memoria extra. La versión de dos punteros es O(n log n) si ordenamos primero, pero usa espacio constante. Dadas las restricciones, me iría con el hash map.)
"There's a trade-off here between readability and performance. For this size of input I'd prioritize readability." (Hay un compromiso entre legibilidad y rendimiento. Para este tamaño de entrada priorizaría la legibilidad.)
Fíjate en la fórmula: "There's a trade-off between X and Y. Given [context], I'd go with Z." Memoriza ese molde. Sirve en coding, en diseño y en la vida real del trabajo.
Paso 5 — Implementar narrando
Ahora sí, código. Pero no en silencio. Narra lo que haces a un nivel medio: ni cada punto y coma, ni un silencio de tres minutos. Di la intención de cada bloque.
Frases modelo en inglés:
"I'll create a hash map to store the values I've already seen." (Voy a crear un hash map para guardar los valores que ya vi.)
"Now I iterate through the array, and for each element I check if its complement is already in the map." (Ahora recorro el arreglo, y para cada elemento verifico si su complemento ya está en el map.)
"I'm using a descriptive variable name here so the logic stays readable." (Uso un nombre de variable descriptivo aquí para que la lógica se mantenga legible.)
Si te equivocas mientras escribes —y te vas a equivocar, todos lo hacen— dilo con naturalidad: "Wait, that's not right. Let me fix that." Corregirte en voz alta no es debilidad; es justo la señal de que sabes revisar tu propio trabajo.
Paso 6 — Probar
No esperes a que el entrevistador te pregunte "¿y funciona?". Adelántate. Corre un ejemplo normal a mano y, sobre todo, corre los casos borde que identificaste en el paso 2.
Frases modelo en inglés:
"Let me trace through an example. If the input is [2, 7, 11] and the target is 9…" (Déjame recorrer un ejemplo. Si la entrada es [2, 7, 11] y el objetivo es 9…)
"Now let me check the edge cases: an empty list, and a list with a single element." (Ahora reviso los casos borde: una lista vacía y una lista con un solo elemento.)
"I think there's an off-by-one error here. Let me double-check the loop bounds." (Creo que hay un error de uno-por-uno aquí. Déjame revisar los límites del bucle.)
Vocabulario de complejidad, rendimiento y trade-offs
No puedes narrar una solución técnica sin las palabras técnicas. Esta es la caja de herramientas mínima. No la memorices de golpe; léela en voz alta, y cuando practiques, oblígate a usar tres términos por sesión.
| Español | Inglés | Cómo se dice en voz alta |
|---|---|---|
| Complejidad temporal | Time complexity | "This runs in linear time, O(n)." |
| Complejidad espacial | Space complexity | "It uses constant space, O(1)." |
| Fuerza bruta | Brute force | "Let me start with a brute-force solution." |
| Una sola pasada | Single pass / one pass | "We can solve it in a single pass." |
| Anidado | Nested | "Two nested loops give us O(n²)." |
| Caso borde | Edge case | "Let me handle the edge cases." |
| Cuello de botella | Bottleneck | "The sort is the bottleneck here." |
| Compensación | Trade-off | "There's a trade-off between time and space." |
| Escalar | To scale | "This won't scale to millions of records." |
| Optimizar | To optimize | "We could optimize this later if needed." |
Cómo se leen las complejidades en inglés, porque esto se dice, no se escribe:
O(1)→ "oh of one" o "constant time"O(n)→ "oh of n" o "linear time"O(n log n)→ "oh of n log n"O(n²)→ "oh of n squared"O(2^n)→ "oh of two to the n" (exponential)
Un detalle de pronunciación que tranquiliza: la "O" se lee como la letra ("oh"), no como "cero". Muchos hispanohablantes dudan justo ahí. Ya no.
Qué hacer cuando te trabas (el momento que crees que te hunde y en realidad te salva)
Vas a trabarte. En algún punto de alguna entrevista, tu mente se va a quedar en blanco delante de una persona que te está evaluando en tu segundo idioma. Esto no es una posibilidad remota; es lo normal, y le pasa también a los nativos. La diferencia entre quien pasa y quien no pasa no es si se traban, sino qué hacen cuando pasa.
La reacción que te hunde es el silencio. El entrevistador ve una pantalla congelada, una cara de pánico y ni una palabra. No tiene datos, así que asume que no sabes. La reacción que te salva es verbalizar el bloqueo: convertir tu atasco en información útil para los dos.
Frases modelo en inglés para cuando te trabas:
"I'm going to think out loud for a moment. I know I need to reduce this to O(n), but I'm not seeing the trick yet." (Voy a pensar en voz alta un momento. Sé que necesito reducir esto a O(n), pero todavía no veo el truco.)
"Let me step back and reconsider my approach." (Déjame dar un paso atrás y reconsiderar mi enfoque.)
"I'm stuck on this part. My instinct says a hash map, but I'm not sure how to handle the duplicates. Can I get a small hint?" (Estoy atascado en esta parte. Mi instinto dice hash map, pero no estoy seguro de cómo manejar los duplicados. ¿Me puedes dar una pista pequeña?)
Sobre pedir una pista: pedir una pista bien no resta puntos, gana puntos. La clave está en cómo la pides. No digas "no sé, ayúdame". Di dónde estás, qué ya descartaste y qué específicamente te falta. Eso demuestra que estás razonando, no rindiéndote. Compara:
| Pedir mal (parece rendición) | Pedir bien (parece colaboración) |
|---|---|
| "I don't know how to do this." | "I've narrowed it down to a hash map, but I'm stuck on the duplicates. Could you point me in a direction?" |
| (silencio de 90 segundos) | "Let me think out loud so you can see where I'm at." |
| "Can you just tell me the answer?" | "Am I on the right track with the two-pointer idea?" |
Qué esperar: un buen entrevistador quiere que resuelvas el problema, así que casi siempre te dará la pista y muchas veces eso reencarrila la entrevista por completo. Una pista pedida con criterio y bien aprovechada puede terminar en un "sí" de contratación. Pedir ayuda de forma inteligente es una habilidad de trabajo, no una confesión de ignorancia.
Y una frase para ganar tiempo sin quedarte en blanco, que puedes usar mientras piensas:
"That's a good question, let me think about it for a second." (Buena pregunta, déjame pensarlo un segundo.)
Decir eso en inglés, con calma, ya te distingue. El silencio asusta; una frase puente, no.
La entrevista de diseño de sistemas
No todas las entrevistas técnicas son de algoritmos. A partir de cierto nivel —y en muchos puestos de backend, plataforma o arquitectura desde antes— te van a pedir diseñar un sistema: "diseña un acortador de URLs", "diseña el feed de notificaciones". Aquí no hay una respuesta correcta única; hay decisiones defendibles. Es, literalmente, el "documento de diseño en lenguaje llano" que el ecosistema de Architecture pedía, pero hablado.
La estructura para narrarlo en inglés:
- Aclarar requisitos y escala. "Before I design, how many users are we talking about? Reads-heavy or writes-heavy?" (Antes de diseñar, ¿de cuántos usuarios hablamos? ¿Predominan las lecturas o las escrituras?)
- Definir el API o los contratos. "Let me sketch the main endpoints first." (Déjame bosquejar los endpoints principales primero.)
- Dibujar los componentes. "At a high level, we have a load balancer, an application layer, and a data store." (A alto nivel tenemos un balanceador de carga, una capa de aplicación y un almacén de datos.)
- Justificar cada decisión con su trade-off. "I'd use a relational database here for consistency, but if we need horizontal scale we could move to a NoSQL store — the trade-off is weaker consistency guarantees." (Usaría una base relacional aquí por consistencia, pero si necesitamos escala horizontal podríamos pasar a NoSQL; el compromiso es garantías de consistencia más débiles.)
- Anticipar cuellos de botella. "The bottleneck will likely be the database reads, so I'd add a caching layer." (El cuello de botella probablemente serán las lecturas de la base, así que agregaría una capa de caché.)
Vocabulario de diseño que debes reconocer y usar: load balancer, cache, database (relational / NoSQL), horizontal vs vertical scaling, latency, throughput, consistency, availability, sharding, replication, queue, rate limiting. No necesitas usarlos todos; necesitas usar los correctos con seguridad. La frase que sostiene toda la entrevista de diseño es la misma del paso 4 de coding: "The trade-off here is…". Un diseño sin trade-offs suena a que memorizaste una respuesta; un diseño con trade-offs suena a que has construido cosas de verdad.
Defender un take-home o revisar tu propio código
Cada vez más procesos reemplazan el algoritmo en vivo por un take-home: te dan un problema para resolver en casa, con tu editor y tu tiempo, y luego una llamada para defenderlo. Esta modalidad es una bendición para quien se pone nervioso resolviendo en vivo, porque el código ya está escrito y con calma. Pero tiene su propia habilidad: hablar de decisiones que ya tomaste.
Aquí la pregunta estrella es "Why did you…?" — por qué elegiste esta librería, por qué estructuraste así las carpetas, por qué no escribiste tests para tal parte. No es un ataque; es curiosidad genuina sobre tu criterio. La trampa es ponerse a la defensiva. La salida es tratar cada decisión como lo que fue: una elección entre opciones, con un motivo.
Frases modelo en inglés para defender tu código:
"I chose this library because it's well-maintained and the team likely already knows it. I did consider writing it from scratch, but that felt like over-engineering for the scope." (Elegí esta librería porque está bien mantenida y probablemente el equipo ya la conoce. Consideré escribirlo desde cero, pero me pareció sobreingeniería para el alcance.)
"I focused my tests on the core business logic and left the trivial getters untested. Given the time box, that's where the risk was." (Enfoqué las pruebas en la lógica de negocio central y dejé sin probar los getters triviales. Dado el tiempo, ahí estaba el riesgo.)
"That's a fair point. If I had more time, I'd refactor this into a separate service. For now I kept it simple on purpose." (Es un punto justo. Con más tiempo, lo refactorizaría a un servicio aparte. Por ahora lo mantuve simple a propósito.)
Esa última frase esconde una herramienta poderosa: reconocer una limitación sin disculparte por ella. "That's a fair point" seguido de "I kept it simple on purpose" convierte una posible crítica en una decisión consciente. Estás mostrando que sabías del trade-off y elegiste. Eso es exactamente lo que separa a un senior de un junior, y se dice con dos frases aprendibles.
Otra fórmula útil cuando el entrevistador señala algo que sí mejorarías: "You're right, that's a limitation. My reasoning was [X], but I can see how [Y] would be better." Concedes, explicas tu lógica y no te derrumbas. Impecable.
Qué debes evaluar tú del entrevistador
La entrevista es de dos vías, aunque el nervio la haga sentir como un interrogatorio. Mientras te evalúan, tú también recibes datos sobre cómo es trabajar ahí, y prestar atención te da dos ventajas: decides mejor si aceptar, y proyectas la seguridad de quien no está mendigando un puesto. Observa:
- ¿El problema se parece al trabajo real, o es un acertijo de concurso? Un problema aplicado sugiere un equipo pragmático. Un acertijo abstracto puede indicar una cultura de "hazing" técnico.
- ¿Cómo reacciona cuando te trabas? Si te da espacio y una pista, es alguien con quien se puede trabajar. Si te deja hundirte en silencio, ya sabes algo del equipo.
- ¿Puede responder tus preguntas técnicas con claridad? Cuando le preguntes por qué eligieron su stack, ¿te da razones o eslóganes?
- ¿Te trata como colega o como sospechoso? El tono de la sala suele ser el tono del día a día.
Una pregunta que puedes hacer al final, y que revela mucho:
"What does a typical week look like for the person in this role?" (¿Cómo se ve una semana típica para la persona en este puesto?)
La respuesta te dice si el rol es el que anunciaron o algo distinto. Y hacerla, en inglés, con naturalidad, cierra la entrevista con la impresión que quieres dejar: la de alguien que también está eligiendo.
Tu plan de práctica para esta lección
El inglés técnico bajo presión no se aprende leyendo; se aprende hablando solo, mal, muchas veces, hasta que deja de doler. Antes de tu próxima entrevista real, entrena así:
- Toma tres problemas fáciles de cualquier plataforma de práctica y resuélvelos en voz alta y en inglés, grabándote. No importa si tu código es lento; importa que narres los seis pasos completos.
- Escúchate. Vas a odiar tu acento los primeros dos minutos y después dejarás de notarlo. Lo que buscas no es sonar nativo: es que tu razonamiento sea seguible. ¿Se entiende tu plan? ¿Dijiste el trade-off? ¿Verbalizaste cuando te trabaste?
- Practica trabarte a propósito. Elige un problema por encima de tu nivel y, cuando te atasques, di en voz alta la frase de pedir pista. Entrena el músculo de no callarte.
- Memoriza cinco fórmulas puente: "Let me make sure I understand…", "Let me walk you through…", "There's a trade-off between X and Y…", "Let me step back…", "That's a fair point, I did that on purpose because…". Con esas cinco navegas casi cualquier entrevista.
Cierro con lo que necesitas oír si el impostor lingüístico te está hablando ahora mismo. Tú ya sabes programar; eso no está en duda en esta lección. Lo único nuevo es narrar en inglés lo que ya haces en tu cabeza, y eso es un conjunto pequeño y finito de frases que se practican en una semana. El entrevistador no busca a alguien que hable inglés perfecto. Busca a alguien con quien dé gusto resolver un problema. Esa persona puedes ser tú hablando lento, con frases cortas, con un acento marcado y con las fórmulas de esta lección. No necesitas más inglés del que ya tienes. Necesitas usar el que tienes con método. Ese método acabas de aprenderlo.
Ejercicios
Ejercicio 1 — Reformular en voz alta. Te dan este problema en la entrevista: "Given an array of integers and a target sum, return the indices of the two numbers that add up to the target. You can assume there's exactly one solution." Escribe, en inglés, la frase de reformulación que dirías antes de tocar el teclado.
Ver solución
"Let me make sure I understand. We have an array of integers and a target value, and I need to return the indices of the two elements that sum to the target. There's guaranteed to be exactly one solution — is that right?"
Por qué funciona: repite el problema con tus propias palabras (no lo copias literal), incluye el dato clave que te dieron (una sola solución garantizada) y cierra con una pregunta corta que invita al entrevistador a confirmar o corregir antes de que pierdas tiempo resolviendo el problema equivocado.
Ejercicio 2 — Nombrar el trade-off. Tienes dos soluciones para el mismo problema: una con un hash map que corre en O(n) pero usa memoria extra, y otra con dos punteros que corre en O(n log n) porque primero ordena, pero usa espacio constante. Usando el molde "There's a trade-off between X and Y. Given [context], I'd go with Z.", escribe la frase completa.
Ver solución
"There's a trade-off between the hash map approach, which is faster at O(n) but uses extra memory, and the two-pointer approach, which is O(n log n) but uses constant space. Given that we don't have strict memory constraints here, I'd go with the hash map."
Por qué funciona: nombra las dos opciones con su complejidad y su costo, y cierra con una decisión — exactamente la secuencia que un entrevistador quiere escuchar para confirmar que entiendes que no hay una respuesta "correcta" única, sino una elegida con criterio.
Ejercicio 3 — Convertir el silencio en pista bien pedida. Te trabaste resolviendo un problema de árboles binarios. Tu primer impulso mental es "no sé cómo seguir". Reescribe ese pensamiento como una petición de pista que suene a colaboración, no a rendición.
Ver solución
"I've narrowed it down to a recursive approach, and I think I need to track the depth as I go, but I'm not sure how to combine the results from both subtrees. Could you point me in a direction?"
Por qué funciona: dice dónde estás (recursión, tracking de profundidad), qué específicamente te falta (combinar resultados de subárboles) y termina pidiendo dirección, no la respuesta. Eso demuestra que sigues razonando — la señal que separa "pedir ayuda bien" de "rendirse".
Ejercicio 4 — Defender una decisión de tu take-home sin ponerte a la defensiva. El entrevistador te pregunta: "Why didn't you add input validation on this endpoint?" Tú sí lo pensaste, pero decidiste priorizar otra cosa por el tiempo limitado del ejercicio. Responde usando la fórmula de reconocer sin disculparte.
Ver solución
"That's a fair point — I did think about it. Given the time box, I prioritized the core matching logic since that's where the actual complexity lives. In a real PR I'd add validation before merging, but for this exercise I made a conscious trade-off."
Por qué funciona: reconoce la observación del entrevistador sin disculparse, explica el motivo (prioridad más límite de tiempo) y aclara que fue una decisión consciente, no un descuido — la diferencia entre sonar junior y sonar senior está exactamente en esa distinción.
Resumen y siguiente paso
Antes de avanzar a la siguiente lección, deberías poder:
- Narrar cualquier problema de coding en inglés siguiendo los seis pasos: reformular, aclarar supuestos, proponer un enfoque, mencionar el trade-off, implementar narrando y probar.
- Usar sin dudar el molde "There's a trade-off between X and Y. Given [context], I'd go with Z." para justificar una decisión técnica.
- Pedir una pista cuando te trabas de manera que suene a colaboración ("I've narrowed it down to..., but I'm stuck on...") en vez de quedarte en silencio o rendirte.
- Estructurar una respuesta de diseño de sistemas con requisitos, API, componentes, trade-offs y cuellos de botella.
- Defender una decisión de tu take-home reconociendo una limitación sin disculparte por ella.
Si alguno de estos cinco puntos todavía te cuesta, vuelve a grabarte narrando un problema fácil antes de seguir: el vocabulario se fija con repetición, no con lectura.
La siguiente lección deja atrás lo estrictamente técnico. Ya sabes narrar cómo piensas frente a un problema de código o un diseño de sistema; ahora te toca narrar cómo piensas frente a una situación de trabajo real: un conflicto, un error, una decisión bajo presión. Esa es la entrevista de comportamiento, y en la próxima lección aprenderás la estructura STAR para contar esas historias en inglés sin sonar ni ensayado ni disperso.
Recursos
- System Design Primer — repositorio de referencia con el vocabulario y los patrones (load balancer, caching, sharding, replication) que necesitas para la entrevista de diseño de sistemas.
- Big-O Cheat Sheet — tabla de complejidad temporal y espacial de estructuras de datos y algoritmos comunes, útil para verificar tus afirmaciones de O(n) o O(n log n) antes de decirlas en voz alta.
- interviewing.io — plataforma para practicar entrevistas técnicas en vivo, en inglés, con ingenieros de empresas como Meta, Google y Amazon; ideal para entrenar el "pensar en voz alta" con un interlocutor real.
- How We Hire — Interviewing, Google Careers — descripción oficial de Google sobre qué evalúan sus entrevistas técnicas y cómo prepararte.
- Interviewing at Amazon — guía oficial de Amazon sobre su proceso de entrevistas, incluida la parte técnica.