Inglés para developers: entrevistas técnicas
Inglés para la entrevista de system design: el guión para explicar tu diseño en voz alta
21 de octubre de 2026
Saber el vocabulario no alcanza. Este es el guión real: las frases para aclarar requisitos, declarar suposiciones, explicar tradeoffs y responder a las preguntas difíciles, en orden.
Esto no es una lista de vocabulario
Una entrevista de system design se evalúa tanto por cómo comunicas tu razonamiento como por el diseño en sí. Saber qué es un load balancer o un shard no sirve de mucho si te quedas callado mientras dibujas, o si te congelas apenas el entrevistador te hace una pregunta difícil.
Esta guía es el guión: las frases exactas que dices, en el orden en que las dices, desde que recibes el enunciado hasta que cierras. Si necesitas el vocabulario de base, nuestra guía de System Design Vocabulary lo cubre. Si quieres el panorama completo de cada etapa de una entrevista técnica, nuestra guía de Coding Interview Questions lo cubre. Esta página no es ninguna de las dos. Es la narración.
Puntos clave
- Agrega siempre un 'because' a cada decisión de diseño en voz alta. Ese razonamiento es literalmente lo que se está evaluando.
- Declara tus suposiciones explícitamente en vez de diseñar en silencio dentro de tu cabeza.
- Trata las preguntas difíciles como una invitación a profundizar, no como una señal de que hiciste algo mal.
- Está bien decir 'I don't know X directly, but here's how I'd reason about it' en vez de congelarte.
- Cierra siempre con un resumen de una línea de las decisiones clave que tomaste.
1. Clarifying requirements before you design
1. Aclarar los requisitos antes de diseñar
Los primeros dos minutos deciden si tu diseño se construye sobre una base sólida. Pregunta por la escala, la consistencia y el alcance antes de dibujar nada.
“What scale are we talking about, roughly how many users or requests per second?”
Pregunta siempre por la escala antes de diseñar nada. Cambia cada decisión que tomes después.
“Are we optimizing more for read-heavy or write-heavy traffic?”
Esta sola pregunta define todo tu modelo de datos y tu estrategia de cache.
“Is strong consistency required here, or is eventual consistency acceptable?”
Muestra que entiendes el tradeoff de consistencia antes de elegir una base de datos.
“Should I assume this needs to support multiple regions, or is a single region fine for now?”
La distribución geográfica cambia tu enfoque de latencia y replicación de datos.
“Just so I am scoping this correctly: are we designing the whole system, or focusing on one specific part?”
Evita que gastes los primeros diez minutos en la capa equivocada.
2. Stating your assumptions out loud
2. Declarar tus suposiciones en voz alta
Cuando el entrevistador no te da un número, no diseñes en silencio dentro de tu cabeza. Di la suposición en voz alta para que puedan corregirla a tiempo si está mal.
“I am going to assume we have around 10 million daily active users unless you tell me otherwise.”
Decir un número en voz alta, aunque sea aproximado, muestra que piensas de forma cuantitativa.
“Let's assume reads outnumber writes roughly 100 to 1, which is typical for this kind of system.”
Justifica la suposición con una razón, no solo con una suposición al aire.
“I will design for the common case first, and call out where the edge cases would need a different approach.”
Muestra capacidad de priorizar en vez de intentar resolver todo a la vez.
“Correct me if I am wrong, but I am assuming availability matters more than strict consistency here.”
Formularlo como pregunta invita al entrevistador a corregirte a tiempo, antes de construir sobre una suposición equivocada.
3. Narrating tradeoffs as you draw
3. Explicar los tradeoffs mientras dibujas
Cada decisión de diseño se evalúa por el razonamiento detrás, no por la decisión en sí. Agrega un 'because' a todo, y nombra lo que estás sacrificando.
“I am going with a message queue here instead of a direct call, because it decouples the two services if one goes down.”
Agrega siempre el 'because'. El razonamiento es lo que realmente se está evaluando.
“The tradeoff with this approach is lower latency, but we lose strong consistency. I think that is acceptable here because...”
Nombrar el tradeoff explícitamente, en vez de esperar a que el entrevistador lo note, genera confianza.
“I am adding a cache in front of the database here to handle the read-heavy traffic we discussed earlier.”
Haz referencia a los requisitos que aclaraste antes. Muestra que el diseño responde a restricciones reales, no a un patrón memorizado.
“An alternative here would be to shard by user ID instead of by region. I am choosing region because our reads are geographically clustered.”
Mencionar la alternativa que descartaste, y por qué, es más fuerte que presentar una sola opción.
“Let me walk through what happens when a write comes in, step by step.”
Una frase de transición útil al pasar del diagrama general a un flujo específico.
4. Handling pushback without getting defensive
4. Responder a las preguntas difíciles sin ponerte a la defensiva
Cuando el entrevistador encuentra un hueco en tu diseño, la entrevista está funcionando como debería. Trátalo como una invitación a profundizar, no como un veredicto.
“That's a good point. If traffic grew 10x, the bottleneck would move to the database layer. Here's how I would address that.”
Nunca te pongas a la defensiva. Trata las preguntas difíciles como una invitación a pensar un nivel más profundo, no como un ataque a tu diseño.
“You're right, I did not consider that failure mode. Let me adjust the design.”
Reconocer un vacío directamente es mucho mejor que discutir o sobre-explicar.
“Let me think about that for a second.”
Es totalmente aceptable hacer una pausa en voz alta en vez de entrar en pánico y responder apurado.
“Good catch. That would actually break under concurrent writes. I would fix that by adding an optimistic lock.”
Usa 'good catch'. Transmite confianza en vez de vergüenza.
5. What to say when you do not know something
5. Qué decir cuando no sabes algo
Congelarte es el único error real acá. Ser honesto sobre un vacío mientras sigues razonando en voz alta es exactamente lo que hace un ingeniero senior.
“I have not worked directly with that technology, but based on what I know about similar systems, I would expect...”
Es honesto, y aun así muestra capacidad de razonar en vez de simplemente quedarte callado.
“I am not 100% sure of the exact mechanism, but conceptually I believe it works like this.”
Separa lo que sabes con certeza de lo que estás infiriendo.
“That is outside what I have hands-on experience with. Can I reason through it out loud instead?”
Convierte un vacío de conocimiento en una oportunidad de mostrar tu proceso de pensamiento, que es lo que realmente se evalúa.
6. Wrapping up the interview
6. Cerrar la entrevista
Un buen cierre le muestra al entrevistador que tienes el diseño completo en la cabeza, no solo la última parte de la que hablaste.
“To summarize, the key decisions were a relational database for the core data, a cache for the read-heavy path, and a queue for the write path.”
Cierra siempre con un resumen. Muestra que puedes ver el diseño completo, no solo lo último de lo que hablaste.
“If I had more time, the next thing I would dig into is the failure handling for the queue.”
Una forma sólida de cerrar, mostrando que sabes qué quedó sin resolver.
“Does this address what you were looking for, or is there a part you would like me to go deeper on?”
Le devuelve el control al entrevistador en vez de asumir que cubriste todo.
Artículos relacionados
Esta página es el guión de la narración, no la teoría. Si necesitas el vocabulario de base, empieza acá. Si quieres el mapa completo de cada etapa de la entrevista, empieza allá.
¿Listo para practicar tu inglés en el trabajo?
Lingua-e tiene ejercicios interactivos basados en conversaciones reales de developers: standups, code reviews, retrospectivas y más. Practica hasta que salga solo.
Prueba Lingua-e gratis
Escrito por
Roxana LafuenteFundadora de Lingua-e
Roxana Lafuente es ingeniera de software con más de 8 años de experiencia. Al comienzo de su carrera, aunque ya había aprobado el First Certificate in English, se bloqueaba cada vez que tenía que hablar en el standup diario. Era un problema que nadie estaba resolviendo. Después de más de 2.000 standups, descubrió qué es lo que realmente construye la fluidez: practicar situaciones que se parecen a tu trabajo real. Creó Lingua-e para que otros developers no tuvieran que tomar el camino largo para sentirse seguros trabajando en un entorno de desarrollo internacional.