Práctica de system design interview — en solitario, con feedback de IA

System design es la ronda en la que ingenieros sólidos rinden por debajo de su nivel y otros mediocres consiguen de vez en cuando un golpe maestro, porque el listón no es «¿sabe la respuesta?» — es «¿sabe razonar sobre un problema difuso en voz alta bajo presión de tiempo?». Eso se puede entrenar. Los mocks con IA le dan la rara combinación de repeticiones ilimitadas y feedback consistente y estructurado.

Qué se puntúa realmente en una ronda de system design

Los candidatos asumen que la puntuación es «¿diseñó el sistema correcto?». No lo es. Los entrevistadores reales puntúan cinco cosas, y correlacionan débilmente entre sí. Primera: ¿aclaró el problema antes de diseñar? — en concreto, ¿preguntó por la escala, el ratio lectura/escritura, los requisitos de latencia y las restricciones? Segunda: ¿hizo cálculos de servilleta, o agitó la mano hablando de «mucho tráfico» sin números? Tercera: ¿propuso una API y un modelo de datos antes de dibujar cajas? Cuarta: ¿hizo una arquitectura que encaja con los requisitos que acaba de definir — y no una genérica? Quinta: ¿profundizó en al menos un componente y articuló tradeoffs, o se quedó en la superficie durante una hora?

La mayoría de los candidatos fallan en el punto 1 y en el 5. Empiezan a dibujar de inmediato porque parece productivo, y se quedan en el nivel de «cajas y flechas» toda la hora sin llegar nunca a defender una sola decisión. La solución es estructural: siga un framework, en cada problema, hasta que el framework salga solo.

El framework: seis fases, en cada problema

Úselo en cada diseño, incluidos los que parecen fáciles. Es más lento las tres primeras veces y más rápido para siempre después.

1. Aclarar (5 min). Requisitos funcionales — qué hace el sistema, qué no hace. No funcionales — escala, latencia, disponibilidad, consistencia. Restricciones — presupuesto, equipo, regulación. Confirme el alcance antes de diseñar. El entrevistador a veces no le dará ningún alcance a propósito, para ver si pregunta.
2. Estimar (5 min). Usuarios, QPS, almacenamiento, ancho de banda. Apunte los números (en voz alta, ya que está hablando). 100M DAU, 10 lecturas por usuario al día, reparto 80/20 lectura/escritura — eso son aproximadamente 12K QPS de lectura y 3K QPS de escritura. No necesita acertar; necesita ser plausible.
3. API (5 min). Defina los 3–5 endpoints más importantes. Método, ruta, parámetros, forma de la respuesta. Este paso importa más de lo que los candidatos creen, porque le obliga a nombrar sus sustantivos. Un POST /shorten con un body de {url, custom_alias?} es más concreto que agitar la mano hablando de «el servicio de URLs».
4. Modelo de datos (5 min). Tablas o esquemas de documentos, claves, índices. Indique su elección de almacén de datos (Postgres, DynamoDB, Cassandra) y defiéndala en una frase. La elección forma parte del modelo de datos — no es una decisión aparte para más tarde.
5. Arquitectura (15 min). Ahora sí dibuja cajas. Cliente, load balancer, API gateway, servicios, cachés, colas de mensajes, bases de datos. Recorra por separado el camino de lectura y el de escritura. No intente dibujar el diagrama perfecto a la primera — bosquéjelo y luego añada cajas a medida que descubra que las necesita.
6. Profundización + tradeoffs (15 min). El entrevistador dirá «profundicemos en X». O no lo hará, y entonces debería ofrecerse usted. Elija el componente más interesante y explique cómo funciona en detalle — estrategia de replicación, política de desalojo, enfoque de escalado. Termine con tradeoffs explícitos: «elegimos consistencia eventual porque el caso de uso tolera 30 segundos de desactualización y la alternativa era triplicar el coste».

Diseños habituales que debería ensayar en frío

URL shortener

El engañosamente fácil. El sistema es simple — generar un ID corto, almacenar el mapeo, redirigir en la consulta. La entrevista es difícil porque el entrevistador le presiona en cada detalle. ¿Cómo genera los IDs? (Aleatorio frente a incremental frente a hash base62 — cada uno con sus tradeoffs.) ¿Qué base de datos? (Un almacén KV como Redis para lecturas calientes, relacional para analítica.) ¿Cómo maneja las colisiones? (Reintento con un ID más largo, o preasignar un pool por nodo.) ¿Cuál es el ratio lectura/escritura? (100:1 como mínimo — diseñe pensando en muchas lecturas.) ¿Estrategia de caching? Read-through con un TTL alto, ya que las URLs rara vez cambian. Este diseño cubre quizá el 40 % de los temas que aparecen también en otros diseños.

Social feed (estilo Twitter)

El fan-out es la pregunta canónica. Push (escribir tweet → escribir en todos los timelines de los seguidores) frente a pull (escribir tweet → leer de la lista de seguidos en el momento de la consulta). Push optimiza la latencia de lectura a costa de la amplificación de escritura — malo para cuentas de famosos con 10M de seguidores. Pull optimiza el coste de escritura — malo para usuarios con miles de seguidos. La respuesta del mundo real es híbrida: push para usuarios normales, pull para famosos. Esté listo para explicar qué umbral elegiría (p. ej., número de seguidores > 10K dispara el comportamiento pull) y por qué.

Sistema de chat

Tres subsistemas interesantes: almacenamiento de mensajes, entrega y presencia. Almacenamiento: particionar por ID de conversación, guardar los mensajes en logs de solo añadido, archivar las conversaciones frías. Entrega: una conexión websocket por usuario activo, cola de mensajes para la entrega offline, push notifications para móvil. Presencia: efímera, basada en heartbeat, eventualmente consistente. El entrevistador presionará sobre la ordenación de mensajes (¿causal? ¿total? la ordenación total por conversación suele bastar) y las garantías de entrega (at-least-once es lo habitual — gestione la deduplicación en el cliente).

Usar los mocks con IA específicamente para system design

Elija el modo «Entrevista completa» y dígale a la IA que quiere una ronda de system design, no un screening. Especifique el diseño («URL shortener», «feed de Instagram») o deje que ella elija. Recorra el framework en voz alta — describa lo que dibujaría, recorra el camino de lectura, explique los tradeoffs a medida que los toma. La IA hará preguntas de seguimiento del mismo tipo que un entrevistador real: «¿qué pasa si falla la caché?», «¿cómo maneja una hot key?», «¿cuál es su estrategia de replicación y cuál es el modo de fallo?». Responda en frases completas con tradeoffs explícitos, porque así es como se puntúa la ronda real.

Un truco concreto: dígale a la IA que actúe como entrevistador senior en una FAANG. Presionará más sobre las suposiciones y se negará a aceptar respuestas genéricas. Es el ajuste de mayor apalancamiento para candidatos de senior en adelante, porque necesita practicar defender decisiones frente a réplicas, no solo enunciarlas.

Lo que el feedback de IA no detectará (y qué hacer al respecto)

El feedback de IA es excelente con la estructura, la articulación de tradeoffs y los componentes que faltan. Es más flojo con la calidad del diagrama (usted describe, no dibuja) y con si sus estimaciones numéricas son realistas para la escala concreta de la empresa. Mitíguelo haciendo una o dos sesiones con una pizarra de verdad — abra excalidraw en un segundo monitor y dibuje mientras habla. Combine los mocks con IA con una o dos rondas con un compañero o un coach en la última semana antes de la entrevista real, sobre todo si va a por un puesto de staff o principal.

Para las partes en las que la IA es excelente: estructura y articulación de tradeoffs. Reléase el feedback puntuado tras cada sesión y anote dos cambios concretos para la siguiente. Dos cambios por sesión componen rápido — tres sesiones y será medible que está más estructurado que el 80 % de los candidatos que entran a la sala.

Preguntas frecuentes