Entrevista de system design en inglés: cómo explicar tu diseño

Por Andrés, DevSecOps Architect21 de octubre de 20267 min de lectura

En una entrevista de diseño de sistemas no te evalúan solo por el diagrama. Te evalúan por cómo piensas en voz alta, en inglés, durante 45 minutos. Puedes saber perfectamente qué es un load balancer y aun así quedarte en silencio porque no encuentras la frase para decir "esto depende". Aquí tienes las frases para cada etapa de una system design interview en inglés, con ejemplos concretos de un diseño típico: un acortador de URLs.

Aclarar requisitos antes de dibujar

El error más caro es empezar a dibujar cajas en el primer minuto. El enunciado suele ser vago a propósito: el entrevistador quiere ver si haces preguntas. Dedica los primeros cinco minutos a esto y dilo explícitamente:

Requisitos funcionales: qué hace el sistema

• "What are the core features we need to support?"
• "Should users be able to choose a custom short URL, or is it always generated?"
• "Do the links expire, or do they live forever?"
• "Is analytics in scope, like counting clicks per link?"
• "Can I assume users are already authenticated, or do I need to design that too?"

Requisitos no funcionales: cómo debe comportarse

• "How many users are we expecting, roughly?"
• "Is this read-heavy or write-heavy?"
• "What latency are we aiming for on redirects?"
• "How important is availability compared to consistency here?"
• "Is it OK if a new link takes a few seconds to work everywhere?"

Cierra la etapa con un resumen. Esto demuestra que escuchaste y te da un contrato con el entrevistador:

Si el entrevistador te devuelve la pregunta con "What do you think?", no te bloquees. Propón tú una suposición: "I'll assume around 100 million new links per month. We can adjust later if needed."

Estimar la escala en voz alta

Las estimaciones back-of-the-envelope asustan más por el inglés que por la matemática. Nadie espera números exactos; esperan que razones en voz alta y redondees sin miedo. Usa frases que marquen que es una aproximación:

• "Let me do a quick back-of-the-envelope calculation."
• "If we have 100 million new links a month, that's roughly 40 writes per second."
• "Assuming a read-to-write ratio of 100 to 1, we'd get about 4,000 reads per second."
• "Each record is maybe 500 bytes, so over five years we're looking at a few terabytes."
• "I'll round that up to keep the math simple."
• "That's well within what a single database can handle for writes, but reads need caching."

Ojo con leer números en voz alta. 4,000 se dice "four thousand", no "four thousands". 100M es "a hundred million". Y en inglés la coma separa miles y el punto separa decimales, al revés que en Chile. Si dudas con la pronunciación de términos como throughput, cache o queue, revisa cómo se pronuncian las palabras técnicas en inglés.

Describir componentes y flujo de datos

Aquí la clave es narrar mientras dibujas. Primero el panorama general, después el detalle. Anuncia lo que vas a hacer:

Presentar componentes

• "At a high level, we have three main components: an API layer, a key generation service, and a database."
• "The API servers are stateless, so we can scale them horizontally behind a load balancer."
• "I'd put a cache in front of the database, since most traffic is reads."
• "This service is responsible for generating unique keys."

Explicar el flujo de datos

Describe una petición de punta a punta. Usa conectores de secuencia: first, then, once, after that, finally.

Verbos útiles para el flujo: sends, routes, forwards, queries, stores, publishes, consumes, returns, falls back to. Si el diagrama crece, señala dónde estás: "Going back to the write path…" o "This arrow here is the async part."

Trade-offs y cuellos de botella

Lo que separa a un candidato senior es que no presenta su diseño como perfecto. Nombra las alternativas, elige una y explica el costo. La estructura base:

Ejemplos:

• "We could use a relational database or a key-value store. Since the access pattern is a simple lookup by key, I'd go with a key-value store. The trade-off is that we lose easy joins, but we don't really need them."
• "Writing to the analytics pipeline asynchronously keeps redirects fast. The cost is that click counts will be slightly delayed."
• "I'm choosing availability over consistency here. If a new link takes a second to replicate, that's not a big deal for users."

Para cuellos de botella, adelántate antes de que te pregunten:

• "The main bottleneck I see is the database under heavy read load."
• "This is a single point of failure, so I'd add a replica."
• "If one link goes viral, we could get a hot key. Caching popular keys at the edge would help."
• "As we grow, we'll probably need to shard the database by key."

Cuando el entrevistador te cuestiona

Si el entrevistador dice "What if traffic grows ten times?" o "Why not just use SQL?", no es un ataque. Casi siempre quiere ver cómo razonas bajo presión. Tres reglas: no te defiendas por reflejo, piensa en voz alta y acepta cambiar de opinión si el argumento es bueno.

Ganar tiempo para pensar

• "That's a good point. Let me think about that for a second."
• "Just to make sure I understand, are you worried about latency or about cost?"

Defender tu decisión

• "I considered that, but I went with this approach because…"
• "SQL would work too. My concern is scaling writes later, but at this volume it's a reasonable choice."

Ajustar el diseño

• "You're right, that would be a problem. Let me adjust the design."
• "In that case, I'd add a message queue between these two services."
• "If traffic grew ten times, the first thing to break would be the cache layer, so I'd…"

Y si no sabes algo, dilo con honestidad y razona igual: "I haven't worked with that technology directly, but based on how it works, I'd expect…" Es mucho mejor que inventar.

Errores comunes de los hispanohablantes

Un último consejo: usa I'd (I would) para proponer. "I'd add a cache" suena a propuesta abierta a discusión, que es justo el tono de una entrevista de diseño. Para preparar la parte de experiencia de la misma entrevista, revisa las preguntas más comunes en entrevistas técnicas en inglés y el método STAR.