Architecture

Cómo prepararte para una entrevista de system design (guía práctica 2026)

Dambert Muñoz

Dambert Muñoz

Staff Engineer @ Rappi · ex-BCP, Scotiabank, OpenBank (Santander)

3 de julio de 20269 min de lectura
#system design#entrevista técnica#arquitectura de software#senior developer#tradeoffs
Compartir

Si ya entregas features pero te frenaron en la ronda de system design — o llevas años de Mid sin que llegue el ascenso — este artículo es para ti. Me ha tocado estar en las dos sillas: pasé estas entrevistas en bancos top y unicornios como Rappi, y también me ha tocado hacerlas como entrevistador. Esto es lo que se evalúa de verdad.

Lo que el entrevistador realmente busca

Nadie espera que diseñes Twitter en 45 minutos. El entrevistador evalúa cómo piensas bajo ambigüedad: si haces las preguntas correctas, si partes el problema con límites claros, y sobre todo si cada decisión viene con su tradeoff explícito. La respuesta 'depende' es correcta — siempre que digas de qué depende y qué elegirías en cada caso.

Lo que separa a un Senior de un Staff no es saber más tecnologías: es defender cada decisión con un tradeoff, bajo presión, sin dogma.

Dambert Muñoz

La estructura de 5 pasos

1. Acota el problema antes de dibujar (5 min)

El error número uno es empezar a dibujar cajas de inmediato. Primero pregunta: ¿cuántos usuarios? ¿qué operación domina, lectura o escritura? ¿qué es inaceptable que falle? Con tres números y una restricción ya puedes diseñar algo defendible — sin ellos, solo estás recitando arquitecturas de moda.

2. Modela el dominio, no la infraestructura

Qué entidades existen, qué reglas las gobiernan, qué invariantes no se pueden romper. Un candidato que empieza por el dominio suena a alguien que ha construido sistemas reales; uno que empieza por 'pongo un Kafka' suena a alguien que vio un video.

3. Parte el sistema en módulos con responsabilidad clara

Boundaries: qué módulo es dueño de qué dato y qué contrato expone. Aquí es donde muestras criterio de verdad — y donde aplica la decisión clásica: ¿monolito modular o servicios? La respuesta honesta para la mayoría de etapas es el monolito modular, y saber decir eso (con el porqué) da más puntos que proponer microservicios por reflejo.

4. Elige almacenamiento y consistencia por el caso de uso

SQL vs NoSQL no es religión: es transacciones y forma de acceso. Di qué guardas, cómo lo consultas, dónde necesitas consistencia fuerte y dónde toleras eventual. Suma puntos hablar de idempotencia y de los casos borde que tumban producción: reintentos, doble click, race conditions.

5. Cierra con fallas y evolución

¿Qué pasa si se cae este componente? ¿Cómo lo observas en producción? ¿Qué cambiarías si el tráfico crece 10x? Cerrar con esto demuestra que piensas el sistema completo — exactamente lo que se espera de un Staff.

Los errores que eliminan candidatos

  • Recitar tecnologías sin justificar: cada componente que dibujas debe tener un porqué. 'Uso Redis' no dice nada; 'cacheo aquí porque esta lectura domina el tráfico' sí.
  • No hacer ninguna pregunta: diseñar sin acotar es la señal más clara de falta de experiencia real.
  • Sobre-ingeniería: proponer event sourcing y 12 microservicios para un CRUD te resta. La abstracción prematura es deuda, y los entrevistadores lo saben.
  • No saber defender bajo repregunta: si al primer '¿y por qué no X?' cambias tu diseño entero, comunicas que no era tu criterio sino una receta memorizada.

Cómo practicar (sin memorizar respuestas)

  1. Toma un requerimiento ambiguo real ('un sistema de reservas', 'un feed') y practica los 5 pasos en voz alta, con tiempo.
  2. Construye al menos un proyecto donde TÚ tomaste las decisiones de arquitectura, y documenta la decisión clave en un ADR (Architecture Decision Record). En la entrevista, ese proyecto es tu mejor material.
  3. Busca a alguien con vara real que te haga la repregunta incómoda. La diferencia entre practicar solo y practicar con feedback es semanas contra meses.

El ADR como arma secreta

Documentar una decisión (contexto, opciones, tradeoff, elección) te entrena exactamente el músculo que evalúa system design. Y llevar un ADR real a la entrevista — 'esta decisión la tomé así y por esto' — te separa del 95% de candidatos.

Si quieres entrenarlo con vara real

En mi curso de arquitectura de software en vivo construimos un SaaS real en 6 horas: boundaries, capas, persistencia, testing y deploy — y cierro simulando una review donde te hago las preguntas que te haría un Staff en frío. Sales con el proyecto desplegado y tu primer ADR escrito. Y si lo que quieres es medirte ya, en la mentoría 1:1 te hago un mock interview de system design con la vara de banca y unicornio, con feedback sin filtro.

Dambert Muñoz

Escrito por

Dambert Muñoz

Staff Engineer @ Rappi · ex-BCP, Scotiabank, OpenBank (Santander)

Staff Engineer con 12+ años en banca top, unicornios y una startup de YCombinator. Enseño el criterio que se usa adentro.