Cómo prepararte para una entrevista de Staff Engineer o Tech Lead

Cómo prepararte para una entrevista de Staff Engineer o Tech Lead

Si llegaste hasta acá es porque ya acumulaste años como Senior y alguien —una empresa, un recruiter, vos mismo— está evaluando si das el salto. El problema es que la entrevista de Staff o Tech Lead es un animal completamente distinto a las que ya pasaste. Ya no te piden que resuelvas LeetCode medium en 20 minutos ni que expliques la complejidad de un algoritmo de ordenamiento. Te piden que pienses a escala organizacional, que muestres que podés mover equipos sin ser su manager, y que tomes decisiones técnicas que impactan durante años.

Esta guía te lleva desde el primer mail del recruiter hasta el design round final. Sin relleno.

La diferencia real entre Senior y Staff

Antes de prepararte para la entrevista, necesitás entender qué están evaluando. Y para eso, necesitás tener claro cuál es la brecha.

Un Senior Engineer resuelve problemas técnicos complejos dentro de un equipo. Ejecuta bien, mentoriza a los juniors, toma ownership de features de principio a fin. La vara es: ¿puedo confiarle este proyecto y sé que lo entrega?

Un Staff Engineer resuelve problemas técnicos complejos que abarcan múltiples equipos o sistemas. Su impacto no se mide en features, se mide en si otros ingenieros trabajan mejor gracias a él. La vara es: ¿está moviendo la aguja técnica de la organización?

| Dimensión | Senior | Staff |

|---|---|---|

| Scope | Un equipo, un sistema | Múltiples equipos, plataforma |

| Impacto | Features, bugs, performance | Arquitectura, estándares, decisiones |

| Influencia | Dentro del equipo | Hacia afuera, sin autoridad directa |

| Horizon | Meses | 1-3 años |

| Éxito | Mis proyectos andan | Los equipos de otros andan mejor por mí |

| Deuda técnica | La resuelve | Decide qué resolver, en qué orden y por qué |

En la entrevista, la mayoría de los candidatos que llegan de Senior siguen contestando como Senior. Dan respuestas técnicamente correctas pero con scope individual. El entrevistador los escucha y piensa: "Muy bueno. Pero esto es un Senior fuerte, no un Staff."

Estructura típica del proceso

Cada empresa tiene su flavor, pero el proceso de Staff/Tech Lead suele incluir:

1. 1Screening con Hiring Manager (30-45 min) — qué hiciste, por qué querés el rol, cultura fit
2. 2Technical screening (45-60 min) — código o sistema, a veces los dos
3. 3System Design (60-90 min) — el round definitorio en este nivel
4. 4Behavioral / Leadership (45-60 min) — STAR stories con lente de influencia, mentoring, conflictos técnicos
5. 5Cross-functional (45 min) — cómo trabajás con PM, design, data, infra
6. 6Debrief del loop — el hiring manager consolida los votos

En muchas empresas el "Design Round" puede ser un round separado de arquitectura o mezclado con behavioral. En empresas grandes (Google, Meta, Stripe) es un round dedicado de 60-90 minutos donde diseñás un sistema desde cero.

El Design Round: qué evalúan exactamente

Este es el round que más diferencia a los candidatos de Staff de los de Senior. Te voy a dar el rubric interno que usan la mayoría de las empresas, aunque pocas lo publican abiertamente.

1. Clarificación del problema (10-15 min)

No empezás a dibujar. Hacés preguntas. Los entrevistadores de Staff están evaluando si sabés cuáles son las preguntas que importan.

Preguntas que muestran nivel Staff:

• ¿Cuántos usuarios activos? ¿Cuál es el pico proyectado?
• ¿Cuál es la latencia aceptable para el P99? ¿Y para el P50?
• ¿Es más importante la consistencia o la disponibilidad en este contexto?
• ¿Tenemos un budget de infraestructura conocido o esto es greenfield?
• ¿Hay regulaciones de data residency que considerar (GDPR, LGPD)?
• ¿Qué ya existe que podemos reusar?

Preguntas que muestran nivel Senior-en-modo-Staff-cosplay:

• ¿Usamos MySQL o Postgres?
• ¿En qué lenguaje lo implementamos?

2. Estimaciones y back-of-the-envelope (10 min)

Te van a pedir que calcules load. No necesitás ser exacto, necesitás mostrar que razonás de forma ordenada.

Ejemplo: "Diseñá un sistema de notificaciones para 10M usuarios"

Estimaciones base:
- DAU: 10M usuarios
- Notificaciones por usuario por día: ~5 (push) + 2 (email)
- Total: 70M notificaciones/día
- Peak factor: 10x → 700M/día en peak (ej: Black Friday)
- QPS promedio: 70M / 86400s ≈ 810 QPS
- Peak QPS: 8100 QPS

Storage:
- Metadata por notificación: ~200 bytes
- Retención: 30 días
- 70M * 200B * 30 = 420 GB/mes → ~5 TB/año

Esto nos dice que necesitamos:
- Queue distribuida (no un simple cron)
- Storage que escale horizontalmente
- Separar email (tolera latencia) de push (latencia <5s)

3. High-level design (20 min)

Dibujás los componentes principales. A nivel Staff se espera que:

• Menciones los tradeoffs, no solo la solución
• Elijas patrones de diseño con justificación (event sourcing vs CRUD, sync vs async)
• Pensés en failure modes desde el principio, no como afterthought

4. Deep dive en un componente (15 min)

El entrevistador te va a pedir que profundices en algo. Elegí bien cuándo preguntar "¿En qué componente querés que me meta?" vs. cuándo vos proponés: "El componente más interesante para discutir acá es X porque Y."

5. Cierre y tradeoffs (10 min)

Resumís las decisiones principales y sus costos. Un candidato de Staff dice: "La decisión más importante que tomé fue usar eventualmente consistente porque sacrificamos que el usuario vea el count de notificaciones con 1-2s de delay, lo cual es aceptable para este caso de uso, y ganamos 10x en throughput."

50 preguntas con respuestas de ejemplo

Sección 1: Qué diferencia a un Staff de un Senior

1. ¿Cómo describís la diferencia entre tu trabajo actual como Senior y lo que buscás hacer como Staff?

Respuesta ejemplo:

"Como Senior, mi impacto es directo: diseño, construyo, entrego. Como Staff, el impacto es multiplicado: trabajo en los problemas que, si los resuelvo, hacen que otros ingenieros trabajen 10x mejor. En mi último año noté que el mayor cuello de botella del equipo no eran features, era que cada squad tomaba las mismas decisiones de arquitectura en forma aislada y terminábamos con 4 formas distintas de manejar errores. Empecé a impulsar un ADR process, un error handling standard y una guild de plataforma. Eso desbloqueó más capacidad que cualquier feature que yo pudiera haber construido solo."

2. ¿Cuándo fue la última vez que multiplicaste el output de otros ingenieros?

Respuesta ejemplo:

"Identificamos que los backend developers perdían 2 horas promedio por sprint luchando con el setup de entornos locales. Tomé ownership de buildear una CLI interna (dev up) que levanta el stack con un comando, inyecta variables de entorno desde el secret manager y tiene health checks automáticos. En 6 semanas 15 ingenieros ganaron ~30 horas de sprint por ciclo — eso equivale a un engineering month por mes."

3. ¿Cuál fue la decisión técnica más difícil que tomaste y cómo la tomaste?

Respuesta ejemplo:

"Teníamos un sistema de recomendaciones que corría en un monolito y empezó a degradar el tiempo de deploy de todo el equipo. La decisión era: extraer como microservicio ahora (costo: 3 sprints de deuda + riesgo de regresión) vs. vivir con deploys lentos por 1 año más mientras terminábamos el roadmap de producto. Armé un RFC, calculé el costo de oportunidad en días-persona de los deploys lentos (resultado: 2.1 FTE-days/sprint perdidos), y lo presenté al CTO y al PM. La decisión fue extraer con un team de 2 personas en modo feature-freeze durante 2.5 sprints. El PM se bancó el costo porque el ROI era claro y cuantificado."

4. ¿Qué significa para vos "impacto sin autoridad directa"?

Respuesta ejemplo:

"Significa convencer por la calidad del argumento y la confianza que construiste, no por tu título. Cuando proponés un cambio arquitectónico que afecta a 3 equipos que no te reportan, tenés que entender sus incentivos, sus restricciones de roadmap, sus miedos técnicos. Mi approach es: antes de presentar mi propuesta, tengo 1:1s con los tech leads de cada equipo afectado para entender sus objeciones reales, incorporo esas objeciones al RFC, y cuando llego al meeting de decisión, la propuesta ya tiene los buy-ins informales. La reunión es para formalizar, no para convencer."

5. ¿Cómo priorizás en qué problemas técnicos enfocarte?

Respuesta ejemplo:

"Uso una versión simple de Expected Value: (impacto en productividad de otros × número de ingenieros afectados) / (complejidad de implementación). Los problemas de plataforma, tooling y developer experience suelen ganar porque el numerador es grande. También chequeo: ¿hay alguien más que pueda resolver esto? Si sí, dejo que lo resuelvan. Mi tiempo de Staff va a donde nadie más puede llegar — sea por scope técnico o por necesidad de coordinación cross-team."

Sección 2: Arquitectura — construir vs comprar, ADRs

6. ¿Cómo decidís cuándo construir una solución in-house vs comprar o usar open source?

Respuesta ejemplo:

"Uso tres filtros: (1) ¿Es esto una ventaja competitiva core? Si no, no construyas. (2) ¿El tiempo de integración de la solución externa es mayor que el tiempo de construir algo good-enough? A veces sí. (3) ¿Cuál es el costo total de ownership? No solo la licencia, sino meses de mantenimiento, upgrades, soporte, vendor lock-in. En la práctica: autenticación, facturación, monitoreo, search full-text → casi siempre compro. Lógica de negocio central, algoritmos propietarios, data pipelines con semántica muy particular → construyo."

7. ¿Qué es un ADR y cuándo lo usás?

Respuesta ejemplo:

"Architecture Decision Record. Un documento corto (1-2 páginas) que captura: cuál era el problema, qué opciones evaluamos, qué decidimos y por qué, y cuáles son las consecuencias y tradeoffs aceptados. Lo uso cuando la decisión (a) es irreversible o costosa de revertir, (b) afecta a múltiples equipos, (c) tiene alternativas razonables que vale la pena documentar. El valor principal no es el documento en sí, sino el proceso de escribirlo: te fuerza a articular los tradeoffs antes de committearte."

Un ADR bien estructurado se ve así:

# ADR-042: Usar Kafka como event bus central

## Estado
Aceptado — 2025-03-15

## Contexto
Necesitamos propagar eventos entre 6 servicios. Actualmente usamos
llamadas HTTP síncronas que crean acoplamiento temporal y cascadean
fallos. Evaluamos: Kafka, RabbitMQ, AWS SQS/SNS, Redis Streams.

## Decisión
Kafka con un cluster gestionado (MSK).

## Razones
- Replay de eventos: necesario para el pipeline de ML (puede reprocesar
  desde el offset arbitrario)
- Múltiples consumer groups: 3 servicios distintos leen el mismo evento
  con semántica independiente
- El equipo de infra ya tiene expertise; MSK reduce el operational burden
- RabbitMQ descartado: no soporta replay nativo
- SQS descartado: no soporta múltiples consumers sobre la misma cola
  con ordering garantizado

## Consecuencias
- (+) Desacoplamiento temporal; los servicios pueden caerse sin cascadear
- (+) Auditoría natural del event log
- (-) Complejidad operacional mayor que HTTP
- (-) Eventual consistency: los consumidores no ven el evento inmediatamente
- (-) Latencia P99 de ~100ms vs ~10ms en HTTP
- Aceptamos: para los casos de uso actuales, la consistencia eventual
  es tolerable (máximo delay aceptable: 500ms)

8. ¿Cómo manejás el pushback cuando tu propuesta de arquitectura va contra lo que quiere el equipo?

Respuesta ejemplo:

"Primero escucho el pushback para entender si es técnico o político. Si es técnico — 'ese approach tiene el problema X' — lo evalúo honestamente; a veces el pushback tiene razón y mi propuesta mejora. Si es resistencia al cambio o miedo al trabajo extra, trabajo en el porqué: ¿qué les preocupa realmente? ¿El timeline? ¿La estabilidad del sistema? ¿Que los haga quedar mal? Una vez que entiendo el miedo real, puedo addressarlo. Si después de todo el proceso genuinamente no hay consenso, lo escalo al Staff/Principal o al Engineering Manager para que desempate — no es rendirse, es usar el proceso correcto."

9. Describí cómo diseñarías un sistema de rate limiting distribuido.

Respuesta ejemplo:

"Primero clarificaría los requirements: ¿qué granularidad? (por usuario, por IP, por API key, por tenant), ¿qué algoritmo? (fixed window, sliding window, token bucket), ¿cuántos requests por segundo en peak?

Para un sistema con 100k req/s:

Opción A — Redis con sliding window log:

MULTI
ZREMRANGEBYSCORE key 0 (now - window_ms)
ZADD key now now
ZCARD key
EXPIRE key window_ms
EXEC

Problema: O(n) en memoria por usuario, no escala bien a millones de usuarios activos.

Opción B — Token bucket en Redis con Lua:

local key = KEYS[1]
local rate = tonumber(ARGV[1])
local capacity = tonumber(ARGV[2])
local now = tonumber(ARGV[3])
local requested = tonumber(ARGV[4])

local last_tokens = tonumber(redis.call('hget', key, 'tokens'))
local last_refreshed = tonumber(redis.call('hget', key, 'ts'))

if last_tokens == nil then
  last_tokens = capacity
  last_refreshed = now
end

local delta = math.max(0, now - last_refreshed)
local filled_tokens = math.min(capacity, last_tokens + (delta * rate))
local allowed = filled_tokens >= requested
local new_tokens = filled_tokens

if allowed then
  new_tokens = filled_tokens - requested
end

redis.call('hset', key, 'tokens', new_tokens, 'ts', now)
redis.call('expire', key, math.ceil(capacity / rate) * 2)

return { allowed and 1 or 0, new_tokens }

Para escalar a múltiples Redis nodes: consistent hashing + sticky routing por user_id al mismo shard. Si necesitamos geo-distributed, usamos approximate counting con eventual sync entre regiones y aceptamos que en el borde corto período podés pasar levemente el límite — documentado como tradeoff aceptable."

10. ¿Cuándo elegís consistencia eventual vs. consistencia fuerte?

Respuesta ejemplo:

"La regla de oro: si el usuario puede tolerar ver el dato 'viejo' por unos segundos sin consecuencias graves, eventual. Si una lectura stale puede causar daño (cobrar dos veces, mostrar saldo equivocado, perder una reserva), necesitás consistencia fuerte. En la práctica: counters de likes → eventual. Saldo bancario → fuerte. Feed de noticias → eventual. Inventario en ecommerce → fuerte (o al menos leaky bucket con validación en checkout). La trampa es no haberlo pensado en el diseño inicial y terminar con un sistema eventualmente consistente donde no debería serlo."

Sección 3: Deuda técnica a escala

11. ¿Cómo manejás la deuda técnica cuando tenés múltiples equipos y un roadmap que nunca para?

Respuesta ejemplo:

"Lo primero es dejar de tratar la deuda técnica como un problema técnico. Es un problema de negocio disfrazado. Cuando la frameo como 'esta deuda nos está costando X días de engineering por sprint' o 'esta deuda fue la causa raíz de los últimos 3 incidentes', el PM de repente tiene interés. Mi approach: mantengo un registro de deuda clasificada por costo real (tiempo perdido + riesgo de incidente + dificultad de onboarding) y presento los top 3 items a cada planning como una propuesta concreta con ROI estimado. No pido tiempo para 'limpiar cosas'. Pido tiempo para 'reducir el tiempo de deploy de 45 a 15 minutos', que es lo que la deuda en el pipeline nos está costando."

12. ¿Cómo diferenciás deuda técnica de una decisión técnica simplemente mala?

Respuesta ejemplo:

"La deuda técnica es una deuda que tomaste conscientemente: elegiste el camino rápido sabiendo el costo futuro. Una decisión mala es una que tomaste sin entender las consecuencias. La distinción importa porque cambia cómo la manejás. La deuda se paga en el momento acordado. La decisión mala necesita un post-mortem para entender por qué se tomó y qué proceso de revisión habría la capturado. Tratar todo como 'deuda' crea una narrativa de víctima; tratar todo como 'decisión mala' crea una cultura de blame. La distinción honesta es la que permite mejorar."

13. ¿Qué harías si heredás un sistema con deuda técnica masiva y el equipo quiere reescribir todo?

Respuesta ejemplo:

"Escucho el impulso, pero casi siempre digo no al big-bang rewrite. La razón: los sistemas legados son legados porque el negocio los necesita. El equipo que los reescribe pierde el conocimiento implícito de los edge cases, los bugs que son en realidad features, las integraciones no documentadas. El resultado típico es que terminás con el mismo sistema pero sin los arreglos de 10 años de producción. Mi approach preferido es el strangler fig pattern: identificás el boundary del sistema, construís el nuevo al lado, y vas migrando componente por componente con feature flags. Cada migración es pequeña, reversible y testeable independientemente."

Strangler Fig — estructura de migración:

[Legacy System] ←─── [Router/Facade] ←─── Tráfico
                           │
                    [New System] (10% tráfico inicialmente)

Paso 1: Router enfrente del legacy
Paso 2: Construir primer componente en el nuevo sistema
Paso 3: Migrar 1% del tráfico para ese path
Paso 4: Monitorear, iterar, escalar a 100%
Paso 5: Eliminar el path del legacy
Repetir por componente

14. ¿Cómo decidís qué deuda técnica NO vale la pena pagar?

Respuesta ejemplo:

"Si el sistema va a ser reemplazado en 6 meses, probablemente no vale la pena limpiar la deuda. Si el componente no se toca hace 2 años, tiene buena cobertura de tests y funciona, la deuda ahí es arqueología — no la toques. El costo de limpiar deuda que nadie va a ver es real (tiempo de engineering) y el beneficio es teórico. Priorizo deuda en sistemas que: se modifican frecuentemente, tienen incidentes recurrentes, o son puerta de entrada para nuevos ingenieros."

15. ¿Cómo convencés a un PM de que un sprint de deuda técnica vale la pena?

Respuesta ejemplo:

"No lo llamo sprint de deuda técnica. Lo llamo por lo que produce. Ejemplo real: 'Necesito dos sprints para refactorizar el módulo de pagos. El beneficio: el tiempo de deploy pasa de 45 a 12 minutos (nos devuelve 1.5 días de ingeniería por sprint), reducimos el riesgo de incidente en ese módulo del 40% al 5% según el histórico, y onboarding de nuevos devs pasa de 2 semanas a 3 días para ese sistema.' El PM tiene que decir sí o no a eso, no a 'limpiar código'. Si no puedo cuantificar el beneficio, probablemente no debería estar pidiendo el tiempo."

Sección 4: Influir en roadmaps técnicos

16. ¿Cómo influís en el roadmap técnico sin ser el Engineering Manager?

Respuesta ejemplo:

"A través de dos canales: datos y relaciones. Datos: construyo el caso con métricas (velocity, incidentes, tiempo perdido en developer experience). Si el dato no existe, lo mido primero. Relaciones: construyo confianza con el EM y el PM mucho antes de que necesite pedirles algo. Cuando tengo una propuesta técnica grande, la paso primero por ellos en conversación informal, incorporo su feedback, y cuando llego a la planning meeting la propuesta ya tiene sus huellas digitales. El peor momento para convencer a alguien de algo es cuando lo estás mirando a los ojos en una reunión plenaria."

17. ¿Qué hacés cuando el roadmap de producto está bloqueando trabajo técnico crítico?

Respuesta ejemplo:

"Primero entiendo si el bloqueo es real o percibido. ¿El trabajo técnico es crítico porque alguien en engineering dice que lo es, o hay un costo de negocio medible? Si es real, lo traduzco a términos de negocio: velocidad de delivery, riesgo de incidente, time-to-market de features futuras. Luego propongo alternativas que no sean un cero-a-uno: ¿podemos hacer un 20% del trabajo técnico que resuelve el 80% del riesgo? ¿Podemos intercalar el trabajo técnico en los sprints normales en lugar de pedir un sprint dedicado? Si el EM y el PM siguen diciendno que no y el riesgo es real, lo escalo a la siguiente instancia. No lo dejo sin resolver ni lo resuelvo unilateralmente."

18. ¿Cómo comunicás una decisión técnica compleja a stakeholders no técnicos?

Respuesta ejemplo:

"La regla de comunicación que uso: el nivel de detalle técnico que compartís debe ser inversamente proporcional al poder de decisión de la audiencia. Un VP Engineering necesita el resumen en 2 minutos: qué problema resuelve, cuánto cuesta, qué riesgo elimina. El detalle técnico va en el RFC que adjuntás para quien quiera leer. En la presentación, uso analogías físicas para los conceptos de sistemas distribuidos porque son universalmente comprensibles. 'Usar un caché es como tener una lista de atajos en tu escritorio en lugar de ir al archivero cada vez que necesitás un documento' — eso lo entiende cualquier persona."

19. ¿Cuándo defendés una posición técnica hasta el final y cuándo cedés?

Respuesta ejemplo:

"Defiendo cuando tengo datos que apoyan mi posición y la alternativa tiene un riesgo técnico real que la otra parte no está valorando correctamente. Cedo cuando me doy cuenta de que mi posición era basada en preferencia o costumbre más que en evidencia, o cuando el costo de no ceder (la relación, el momentum del equipo) supera el costo técnico. La distinción que importa: ¿estoy cediendo porque me convencieron de que tenían razón (bueno) o porque me cansé de pelear (malo)? Si es lo segundo, el problema va a volver en 6 meses y va a ser peor."

20. ¿Cómo priorizás entre múltiples iniciativas técnicas que compiten por el mismo presupuesto?

Respuesta ejemplo:

"Uso un RICE simplificado adaptado para trabajo técnico: Reach (cuántos ingenieros impacta), Impact (cuánto mejora su velocidad o confiabilidad, 1-5), Confidence (qué tan seguro estoy de la estimación, %), Effort (semanas de engineering). Calculo el score, ordeno, y presento el top 3 con la propuesta de qué hacemos con los que no entran. El ejercicio de scoring también es útil como conversación: cuando el EM ve que el ítem que él quería hacer tiene score bajo, o pregunta qué le falta para subir, o lo retira del backlog."

Sección 5: Mentoring de engineers senior

21. ¿Cómo mentoreás a un engineer senior que quiere llegar a Staff?

Respuesta ejemplo:

"Lo primero es entender qué parte del gap es habilidad vs exposición. Un Senior que tiene las habilidades de Staff pero nunca tuvo la oportunidad de liderear un proyecto cross-team necesita oportunidades, no coaching. Un Senior que tiene la oportunidad pero aún piensa en scope individual necesita coaching. Para el segundo caso, mi approach es darles proyectos que requieran coordinar con otros equipos, pedirles que escriban RFCs y defiendan sus decisiones, y darles feedback específico cuando veo pensamiento de scope individual: 'Lo que propusiste resuelve el problema para tu equipo. ¿Qué impacto tiene en el equipo de payments que consumen tu API?'"

22. ¿Qué hacés cuando un senior que mentoreás está listo para Staff pero no lo ve?

Respuesta ejemplo:

"Le muestro los datos. Llevo un registro mental (y a veces escrito) de los momentos donde mostró comportamiento de Staff: cuando resolvió el incident que afectaba a 3 equipos, cuando escribió el RFC de migración de base de datos que todo el org adoptó. Se lo presento como evidencia: 'Mirá lo que hiciste en los últimos 6 meses. ¿Eso parece trabajo de Senior o de Staff?' El síndrome del impostor en engineers buenos es real. La mayoría de los que no se ven listos para Staff están mucho más listos que lo que creen."

23. ¿Qué hacés cuando un senior que mentoreás tiene todos los skills técnicos pero el feedback constante es que 'no comunica bien'?

Respuesta ejemplo:

"Este feedback vago es un pattern: 'no comunica bien' suele significar una de tres cosas: (1) habla muy técnico para la audiencia, (2) no escucha activamente / interrumpe, o (3) su comunicación escrita es densa y difícil de consumir. Primero específico el problema con el hiring manager o con quien da el feedback: ¿en qué situación puntual notaste esto? Luego trabajamos el skill específico. Para (1): ejercicios de analogías y de parafrasear para distintas audiencias. Para (2): grabamos una reunión, vemos juntos. Para (3): reescribimos sus últimos 3 documentos con feedback línea a línea."

24. ¿Cómo equilibrás dar feedback directo con no desmotivar a alguien?

Respuesta ejemplo:

"Soy directo porque el feedback vago no ayuda a nadie. 'Podés mejorar la comunicación' no da información accionable. 'En el design review de ayer explicaste el flow de datos pero no cubriste qué pasa cuando el servicio downstream falla — eso es lo que el equipo de operaciones necesita saber para aceptar el diseño' es concreto y accionable. La clave del balance no es suavizar el mensaje, es contextualizarlo: 'Te digo esto porque veo el potencial para que hagas la transición a Staff este año, y este es el único gap que veo consistentemente.'"

25. ¿Cómo manejás el mentoring cuando tenés muy poco tiempo?

Respuesta ejemplo:

"Estructuro el mentoring para que sea eficiente: 1:1 quincenal de 30 minutos con agenda fija (qué estás trabajando, dónde estás trabado, qué decististe esta semana y por qué). El feedback sale de ahí y de observar su trabajo en context (PRs, RFCs, reuniones). No necesito reuniones adicionales si veo el trabajo. También hago lo que llamo 'live coaching': cuando estamos en una reunión juntos y veo una oportunidad que se pierde, lo noto brevemente después de la reunión, no en el momento. El mentoring distribuido en touchpoints pequeños es más efectivo que los bloques grandes mensuales."

Sección 6: Preguntas de behavioral — liderazgo y conflicto

26. Contame de una vez que tuviste que influir en una decisión técnica sin tener autoridad sobre el equipo.

Respuesta ejemplo:

"El equipo de mobile quería adoptar GraphQL para la nueva app. Yo era el Staff del backend y no era mi equipo, pero iba a ser mi plomería. Mi preocupación era el overhead de mantener un schema unificado con los 5 services que teníamos. En lugar de ir al EM a quejarme, armé un spike de dos días con el tech lead de mobile donde construimos un prototype real de la alternativa (REST + BFF pattern). Mostramos los resultados en el design review: el BFF era 30% menos código total, cero overhead de schema federation, y el equipo de mobile tenía el control del contrato que querían. Se adoptó el BFF. El punto no fue que gané la discusión, fue que convertí la conversación de 'yo digo X, vos decís Y' a 'los datos dicen Z'."

27. Describí un momento donde tu decisión técnica fue equivocada. ¿Qué aprendiste?

Respuesta ejemplo:

"Insistí en adoptar event sourcing para el módulo de órdenes de un ecommerce. El argumento era sólido en papel: audit log completo, replay de eventos, temporal queries. Seis meses después, la complejidad operacional (sagas, compensating transactions, proyecciones desincronizadas) estaba matando la velocidad del equipo. Aprendí que event sourcing es una solución para problemas específicos y en ese dominio teníamos un CRUD problem disfrazado de event sourcing problem. El error no fue proponer la arquitectura, fue no cuestionar suficientemente si el problema que resolvía era el problema que teníamos. Hoy antes de proponer una arquitectura compleja me hago la pregunta: ¿cuál es el problema que estoy resolviendo y hay una solución más simple que lo resuelve en el 80%?"

28. ¿Cómo manejaste un conflicto técnico serio con otro Staff Engineer o Tech Lead?

Respuesta ejemplo:

"Dos Staff Engineers, dos visiones distintas de cómo manejar el service mesh de la empresa. El otro Staff quería Istio; yo quería Linkerd por la complejidad operacional más baja. El conflicto se estaba politizando en el equipo. Mi movimiento: propuse que cada uno escribiera un RFC independiente con sus razones y tradeoffs, y pedimos a un tercer Staff (de otra empresa, via network) que revisara ambos como external reviewer. El resultado fue un RFC híbrido que tomó lo mejor de los dos. Lo más valioso del proceso fue que el conflicto dejó de ser sobre egos y volvió a ser sobre datos. Los dos aprendimos algo."

29. ¿Alguna vez tuviste que decirle a un senior manager que su idea técnica era mala? ¿Cómo lo manejaste?

Respuesta ejemplo:

"El VP Engineering quería que migráramos a un nuevo ORM que él había usado en su empresa anterior. Era una migración de tres meses con zero beneficio funcional visible para el usuario. En lugar de decirle directamente 'eso es una mala idea', le pregunté: '¿Qué problema estamos tratando de resolver con este cambio?' Cuando articuló el problema (consistencia en el acceso a datos entre equipos), propuse que resolviéramos el problema específico: un set de convenciones documentadas + linting rules que se podían implementar en 2 semanas sin migración. Se olvidó del ORM. La táctica: hacé que la persona se enfoque en el problema en lugar de la solución. Es más fácil descartar una solución cuando el problema está bien articulado."

30. ¿Qué hacés cuando un proyecto técnico que lideraste va mal?

Respuesta ejemplo:

"Primero, lo reconozco rápido. Los proyectos que van mal que duelen más son los que siguieron mal por seis meses porque nadie quería decirlo. Mi heurística: si en el standup hay más silencio de lo normal y los updates empiezan a sonar vagos, está pasando algo. Levanto la mano en el 1:1 con el EM antes de que llegue al EM por otro canal. Segundo, cambio de modo: de builder a problem-solver. ¿Cuál es el estado real? ¿Cuál es el mínimo que necesitamos entregar para que el negocio no se vea afectado? ¿Qué aprendimos? La transparencia temprana con el bad news protege la confianza mucho más que el optimismo tardío."

Sección 7: System design avanzado

31. ¿Cómo diseñarías un sistema de search con autocompletado para 50M usuarios?

Respuesta ejemplo:

"Separamos el problema en tres partes: indexing, query serving, y autocomplete.

Indexing pipeline:

Fuentes de datos → Event Queue (Kafka)
                          ↓
                   Index Worker Pool
                          ↓
                   Elasticsearch cluster (shards por categoría)
                   + Trie en Redis para autocomplete

Autocomplete con Trie en Redis:

Para cada término indexado:
ZADD autocomplete:prefix 0 "término completo"

Query: "micro" → ZRANGEBYLEX autocomplete:micro "[micro" "[micro\xff" LIMIT 0 5

Optimización: pre-computar top-K por prefix para los 1M prefixes más comunes
Guardar en Redis Hash: HSET top_autocomplete micro "microservices|microfront|micro1"

Tradeoffs principales:

• Elasticsearch vs Solr vs Meilisearch: ES gana en el ecosistema y el operational tooling disponible
• Typo tolerance: Elasticsearch fuzzy queries con edit distance 1 para prefixes > 4 chars
• Freshness vs performance: índice eventual (segundos de lag) vs índice síncrono (latencia de escritura). Para search general: eventual. Para search de precios o inventario: síncrono o near-realtime con Kafka lag < 1s."

32. ¿Cómo diseñarías el backend de una feature de collaborative editing (tipo Google Docs)?

Respuesta ejemplo:

"El problema core es conflict resolution cuando dos usuarios editan el mismo documento simultáneamente. Las dos estrategias principales:

Operational Transformation (OT) — el approach clásico:

User A: inserta 'x' en posición 5
User B: inserta 'y' en posición 5 (simultáneamente)

Si A llega primero al servidor:
→ La operación de B se transforma: insertar 'y' en posición 6

Problema: el algoritmo de transformación es complejo y difícil de implementar correctamente en presencia de muchos tipos de operación.

CRDT (Conflict-free Replicated Data Types) — el approach moderno:

Cada character tiene un ID único (posición lógica en un árbol). Los inserts son always commutative y associative. Yjs, Automerge, y Diamond Types son implementaciones open source.

Arquitectura para production:

Cliente (yjs) ←WebSocket→ Collaboration Server
                                    ↓
                            Redis (session state + awareness)
                                    ↓
                            PostgreSQL (document snapshots cada N ops)

El awareness (quién está editando qué) corre en Redis con TTL corto. El documento se snapshottea en Postgres periódicamente para no hacer full replay desde el inicio."

33. Describí cómo pensarías la migración de una base de datos relacional a microservicios sin downtime.

Respuesta ejemplo:

"El patrón que funciona es Strangler Fig + Database-per-Service con sincronización transitoria:

Fase 1 — Dual write:
Monolith → escribe en DB_monolith Y publica evento en Kafka
Nuevo servicio → lee de Kafka y construye su propia DB

Fase 2 — Verificación:
Compará ambas DBs con un reconciliation job periódico
Cuando la discrepancia es < 0.01%, avanzás

Fase 3 — Read migration:
Feature flag: 10% del tráfico lee del nuevo servicio
Monitoreo intensivo (latencia, error rate, data correctness)
Escalar gradualmente a 100%

Fase 4 — Write migration:
Idem pero para writes

Fase 5 — Cleanup:
Eliminar dual write, eliminar tablas del monolith

El anti-patrón que hay que evitar: cut-over en un día. Siempre hay edge cases que solo aparecen con tráfico real. La migración gradual con feature flags es la única que te permite detectarlos sin que afecten al 100% de los usuarios."

34. ¿Cómo diseñarías el sistema de autenticación para una plataforma multi-tenant con SSO?

Respuesta ejemplo:

"El corazón del sistema es el Identity Provider. Para una plataforma multi-tenant con SSO:

Componentes:

• Auth Service: emisión y validación de tokens (JWT o opaque con introspection)
• Tenant Service: gestión de configuración por tenant (ej: qué IdPs externos aceptan)
• Session Service: sesiones activas en Redis con TTL

Flujo SSO con OIDC:

1. Usuario navega a app.empresa.com
2. App redirige a auth.tuplataforma.com/authorize?tenant=empresa
3. Auth Service determina el IdP del tenant (ej: Okta de esa empresa)
4. Redirige al IdP externo
5. IdP autentica y redirige back con authorization code
6. Auth Service intercambia code por id_token, valida claims
7. Emite tu propio JWT/session cookie con los claims normalizados de tu plataforma
8. App valida el JWT en cada request

Por qué emitís tu propio token y no usás el del IdP:

• Control sobre expiración y claims
• Vendor lock-in: si el tenant cambia de Okta a Azure AD, solo cambia el paso 3-6, el resto de la app no se entera
• Auditoría centralizada en tu sistema

Multi-tenancy en el token:

{
  "sub": "user_123",
  "tenant_id": "tenant_empresa",
  "roles": ["admin"],
  "permissions": ["read:orders", "write:orders"],
  "exp": 1735689600
}

35. ¿Cómo diseñarías el sistema de observabilidad para una arquitectura de microservicios?

Respuesta ejemplo:

"Los tres pilares son Logs, Metrics y Traces. Pero la pregunta interesante es cómo los conectás.

Estructura básica:

Servicios → OpenTelemetry SDK (logs + metrics + traces)
                    ↓
            OpenTelemetry Collector (procesamiento, sampling)
                    ↓
         ┌─────────┬──────────┐
      Grafana   Prometheus  Jaeger/Tempo
      (logs)    (metrics)   (traces)

La decisión más importante: sampling strategy

Traces al 100% con alto QPS es prohibitivo en storage. Opciones:

• Head sampling: decidís al inicio del request (simple, pierde contexto)
• Tail sampling: acumulás todos los spans y decidís al final (mejor, más complejo)
• Adaptive sampling: aumenta sample rate cuando hay errores o latencia alta

Correlación — el verdadero valor:

Un trace ID que viaja en el header de cada request y se incluye en cada log line te permite ir de una alerta de Grafana a los logs exactos a los spans exactos del trace. Sin esto, troubleshoot en microservicios es arqueología.

# Middleware que propaga trace context
def trace_middleware(request, next_handler):
    trace_id = request.headers.get('X-Trace-ID') or generate_trace_id()
    with tracer.start_span('http_request', attributes={'trace.id': trace_id}):
        logger.info('Request received', extra={'trace_id': trace_id})
        response = next_handler(request)
        return response

Sección 8: Preguntas sobre procesos y estándares

36. ¿Cómo establecés estándares técnicos en una organización donde nadie los adoptó antes?

Respuesta ejemplo:

"El error más común es empezar por el documento. 'Acá está el estándar de código, todos lo adoptan' — eso no funciona. El approach que funciona: (1) identifico los 2-3 problemas que más duelen (debugging difícil, deploys que rompen cosas, onboarding lento), (2) propongo un estándar como la solución a ESE problema, no como 'buena práctica' abstracta, (3) lo piloteo con un equipo voluntario, (4) hago que el equipo lo presente en el all-hands técnico (no yo), (5) lo doc en el repo. El estándar que surge de la necesidad y tiene early adopters que lo defienden se adopta. El que baja desde arriba por decreto, no."

37. ¿Cómo manejás el code review cuando sos el único Staff y todos esperan tu aprobación?

Respuesta ejemplo:

"No soy el gatekeeping único de nada. Ese es el anti-patrón más rápido para crear un bottleneck. Mi approach: defino criterios claros de qué tipos de PR necesitan un Staff y cuáles pueden ser aprobados por Seniors. Para los Staff-required PRs (cambios de arquitectura, nuevas dependencias de infra, cambios cross-service), marco los puntos de atención en el template del PR y hago la review en las primeras 4 horas hábiles. Para el resto, confío en el equipo y estoy disponible para dudas puntuales. Y activamente developeo a los Seniors para que puedan aprobar más tipos de PRs con el tiempo."

38. ¿Qué hacés cuando descubrís una vulnerabilidad de seguridad seria en código de otro equipo?

Respuesta ejemplo:

"Seguimiento del responsible disclosure process interno. Primero notifico al tech lead del equipo directamente y en privado — no en Slack público, no en JIRA abierto, no en code review comments. Incluyo el impacto potencial y la exploitabilidad. Si no hay respuesta en 24 horas o el equipo no tiene capacidad para resolverlo, escalo al CISO o al Engineering Manager. Si la vulnerabilidad está siendo explotada activamente, el proceso se salta al escalamiento inmediato. Lo que no hago: resolver yo el problema sin avisar (shadow IT técnico) ni ignorarlo porque 'no es mi equipo'."

39. ¿Cómo medís el impacto de tu trabajo como Staff Engineer?

Respuesta ejemplo:

"Las métricas que uso: (1) Developer velocity — ¿los equipos que uso como referencia están entregando más rápido? (2) Mean Time to Recovery (MTTR) — si hice trabajo de reliability, esto debe bajar. (3) Onboarding time — si mejoré developer experience, cuánto tardan los nuevos ingenieros en hacer su primer PR a producción. (4) Adoption de estándares — qué porcentaje de los PRs siguen los estándares que establecí. (5) Solicitudes de consejo — cuántos engineers de otros equipos me buscan por semana. Este último es un proxy de confianza. El impacto de Staff no es siempre cuantificable, pero siempre hay algún número que podés mover."

40. ¿Cómo preparás a un equipo para un incident grave antes de que ocurra?

Respuesta ejemplo:

"Game days y chaos engineering. Un game day por trimestre donde apagamos un componente en staging y el equipo tiene que detectar, diagnosticar y resolver. Lo que siempre encontramos: los runbooks están desactualizados, los alerts están mal calibrados, o no hay acceso al sistema correcto porque alguien se fue y nadie actualizó los permisos. El valor no es el ejercicio en sí, es la lista de remediation actions que salen. Para chaos engineering en staging: Chaos Monkey o Chaos Toolkit para matar instancias aleatoriamente o inyectar latencia y ver qué se rompe. El objetivo es encontrar los failure modes antes de que los encuentre producción a las 3 de la mañana."

Sección 9: Preguntas de cultura y valores

41. ¿Cómo creás una cultura de documentación técnica sin que se convierta en burocracia?

Respuesta ejemplo:

"El problema con la documentación es el incentivo: escribirla cuesta tiempo ahora, el beneficio lo cosecha otro equipo en seis meses. Mi approach: documentación as code (en el repo, con PR reviews igual que el código, con CI que chequea links rotos y ejemplos que corren). Tres reglas de contenido: (1) si es una decisión importante, escribe un ADR en el momento que la tomás, no después, (2) si es un how-to que tardaste más de 30 minutos en resolver, documentalo en el README del sistema relevante, (3) si es contexto de negocio del sistema, va en el Wiki. Lo que no documentamos: el código que habla por sí solo."

42. ¿Cómo manejás la deuda de documentación en sistemas legados?

Respuesta ejemplo:

"Con una regla de Boy Scout técnica: cuando tocás un sistema, lo dejás mejor documentado de cómo lo encontraste. No en un sprint separado de 'documentar todo' (que nunca ocurre), sino como parte de cada cambio. Si modificás la función processPayment, agregás un comentario que explique el edge case que encontraste. Si hacés onboarding a un nuevo dev, convertís sus preguntas en actualización del README. En seis meses, los sistemas que más se tocan terminan bien documentados — que son los que más lo necesitan."

43. ¿Qué hacés cuando un engineer en tu equipo está claramente burnout?

Respuesta ejemplo:

"Primero lo observo antes de actuar para asegurarme de que es lo que creo que es. Señales: PRs que se demoran más de lo normal, participación en reuniones más baja, entusiasmo en las propuestas técnicas ausente. Cuando estoy razonablemente seguro, abro la conversación directamente en el 1:1: 'Noté que en las últimas semanas parece que tenés menos energía de lo usual. ¿Estás bien?' No diagnostico ni asumo, pregunto. Si confirma que está mal, la conversación pasa a: ¿qué podemos hacer ahora? ¿Menos responsabilidades temporalmente? ¿Tiempo off? ¿Hay algo en el trabajo que lo está causando que podemos cambiar? Y lo notifico al EM — no es un secreto, es un problema del equipo que el EM necesita saber."

44. ¿Cómo manejás la presión de un deadline imposible con calidad técnica?

Respuesta ejemplo:

"Primero chequeo si el deadline es real o heredado. Un deadline real es: el contrato con el cliente se firma el 15 o lo perdemos. Un deadline heredado es: alguien puso una fecha en el roadmap hace seis meses sin evidencia de que era alcanzable. Para el deadline real: negocio el scope, no la calidad. '¿Qué es lo mínimo que necesitás listo el 15 para que el contrato se firme?' Casi siempre hay un subconjunto manejable. Para el deadline heredado: presento la evidencia de que la fecha no es realista con las estimaciones actuales y propongo alternativas. Lo que no hago: aceptar un deadline imposible y entregar código de mierda silenciosamente."

45. ¿Qué preguntas hacés vos al entrevistador al final de la entrevista?

Respuesta ejemplo:

"Las que más me dan información real sobre si quiero trabajar ahí:

• '¿Cuál fue el último incidente de producción importante y qué aprendizajes dejó?' (te dice mucho sobre la cultura de reliability y blame)
• '¿Cuál es la decisión técnica que en retrospectiva darías de nuevo de otra forma?' (inteligencia intelectual y humildad del equipo)
• '¿Cómo se toman las decisiones de arquitectura que afectan a múltiples equipos?' (te dice si tu rol de Staff va a tener poder real o va a ser cosmético)
• '¿Qué está frenando más al equipo técnico ahora mismo?' (te dice si el problema que van a pedirte resolver es el que vos querés resolver)
• '¿Cómo es el día a día de alguien en este rol?' (los Staff que trabajan solo en reuniones y los que también escriben código son roles completamente distintos)"

Sección 10: Preguntas técnicas de lenguajes y sistemas

46. ¿Cuándo usás async/await y cuándo usás threads en un backend?

Respuesta ejemplo:

"La distinción es I/O-bound vs CPU-bound. Async/await brilla en I/O-bound work: esperar respuestas de DBs, APIs externas, lectura de files. Un solo thread puede manejar miles de conexiones simultáneas porque no está realmente esperando, está cediendo el control al event loop mientras espera.

# I/O-bound: perfecto para async
async def get_user_with_orders(user_id: str):
    user, orders = await asyncio.gather(
        db.fetch_user(user_id),        # espera a DB
        db.fetch_orders(user_id)        # en paralelo
    )
    return {**user, 'orders': orders}

# CPU-bound: necesitás threads o processes
def compute_recommendation_score(user_vector, item_matrix):
    # esto necesita CPU real, no async
    return np.dot(user_vector, item_matrix.T)

# Para CPU-bound en async context: ProcessPoolExecutor
async def get_recommendations(user_id: str):
    user_vector = await db.fetch_user_vector(user_id)
    loop = asyncio.get_event_loop()
    scores = await loop.run_in_executor(
        process_pool,
        compute_recommendation_score,
        user_vector, item_matrix
    )
    return scores

El error común: usar async para trabajo CPU-bound. El event loop se bloquea y todos los demás requests esperan."

47. ¿Cómo diseñarías un sistema de feature flags para una empresa con 50 engineers?

Respuesta ejemplo:

"Los feature flags tienen cuatro usos distintos y cada uno tiene requisitos diferentes: (1) killswitches (apagar algo roto en producción), (2) rollouts graduales, (3) A/B testing, (4) configuración por tenant.

Arquitectura mínima viable:

interface FeatureFlag {
  key: string;
  enabled: boolean;
  rollout_percentage: number;   // 0-100
  targeting_rules: Rule[];      // user_id, tenant_id, region, etc.
  overrides: Record<string, boolean>;  // user/tenant específicos
}

// Evaluación client-side (para latencia baja)
function isEnabled(flagKey: string, context: EvalContext): boolean {
  const flag = flagCache.get(flagKey);
  if (!flag) return false;
  
  // Override explícito (para QA y canary users)
  if (flag.overrides[context.userId] !== undefined) {
    return flag.overrides[context.userId];
  }
  
  // Targeting rules
  for (const rule of flag.targeting_rules) {
    if (rule.matches(context)) return rule.value;
  }
  
  // Rollout gradual: hash determinístico para consistencia
  const hash = murmurhash(flagKey + context.userId) % 100;
  return hash < flag.rollout_percentage;
}

Lo que más importa en un feature flag system:

• Latencia de evaluación < 1ms (local cache)
• Actualización sin deploy (push via SSE o polling < 5s)
• Audit log de quién cambió qué y cuándo
• Expiración automática: los flags tienen fecha de vencimiento para limpiar el tech debt de los flags muertos"

48. ¿Cuándo usás SQL y cuándo NoSQL?

Respuesta ejemplo:

"La decisión no es SQL vs NoSQL, es relacional vs documento vs columnar vs grafo, y depende del access pattern.

Relacional (Postgres, MySQL): cuando los datos tienen relaciones complejas, cuando necesitás queries ad-hoc impredecibles, cuando la consistencia transaccional es crítica (ACID). La mayoría de las aplicaciones de negocio deberían empezar acá.

Documento (MongoDB, DynamoDB en modo documento): cuando el schema cambia frecuentemente, cuando la unidad natural de acceso es un documento completo (no necesitás joins), cuando escala horizontal de escritura es prioritaria. Cuidado: los joins malos que terminás haciendo en la app son peores que los del ORM.

Columnar (Cassandra, ScyllaDB): cuando el write throughput es extremo (millones de eventos/segundo), cuando el access pattern es predecible y específico (siempre por partition key), cuando podés tolerar eventual consistency. Jamás uses Cassandra para queries analíticas ad-hoc — te va a hacer llorar.

Grafo (Neo4j, Amazon Neptune): cuando la relación entre entidades es el dato (redes sociales, detección de fraude, recomendaciones basadas en grafo). Los grafos en SQL son posibles pero dolorosos pasado cierto grado de profundidad.

La trampa clásica: elegir NoSQL porque suena moderno y terminar reimplementando joins en la aplicación."

49. ¿Cómo diseñarías el sistema de caching de una aplicación con alta concurrencia?

Respuesta ejemplo:

"Primero mapeamos dónde está el pain: ¿es la DB el cuello de botella? ¿El compute? ¿Las llamadas a APIs externas? El caching en el lugar equivocado no ayuda.

Layers de caching:

Request → CDN Cache (assets estáticos, respuestas cacheables)
               ↓ miss
         → Application Cache (Redis — resultados de queries costosas)
               ↓ miss
         → Database Query Cache (pg_cache, built-in)
               ↓ miss
         → Database (almacenamiento real)

El problema de cache invalidation (el más difícil):

// Opción A: TTL-based (simple, eventualmente consistente)
await redis.setex(`user:${userId}`, 300, JSON.stringify(userData));

// Opción B: Event-based invalidation (consistente, más complejo)
// Al actualizar el usuario, publicar evento
await kafka.publish('user.updated', { userId });

// Consumer en el cache service
kafka.subscribe('user.updated', async ({ userId }) => {
  await redis.del(`user:${userId}`);
});

// Opción C: Write-through (consistente, mayor latencia de escritura)
async function updateUser(userId, data) {
  await db.update('users', data, { id: userId });
  await redis.setex(`user:${userId}`, 3600, JSON.stringify(data));
}

Cache stampede — el problema que nadie menciona en las entrevistas:

Cuando el TTL de un item popular expira, 1000 requests simultáneos van a la DB. Solución: mutex o probabilistic early expiration.

async function getWithMutex(key: string, loader: () => Promise<any>) {
  const cached = await redis.get(key);
  if (cached) return JSON.parse(cached);
  
  const lockKey = `lock:${key}`;
  const locked = await redis.setnx(lockKey, '1');
  
  if (locked) {
    try {
      const data = await loader();
      await redis.setex(key, 300, JSON.stringify(data));
      return data;
    } finally {
      await redis.del(lockKey);
    }
  } else {
    // Otro proceso está cargando, esperar y reintentar
    await sleep(50);
    return getWithMutex(key, loader);
  }
}

50. ¿Cómo manejás el versionado de APIs en un sistema con muchos clientes?

Respuesta ejemplo:

"Tres estrategias principales con tradeoffs distintos:

URI versioning (/v1/users, /v2/users):

Simple, explícito, visible en logs. Desventaja: si tenés 10 versiones activas, mantenés 10 bases de código.

Header versioning (Accept: application/vnd.myapi.v2+json):

URL limpia, pero debugging es más difícil. Los logs no te dicen qué versión se llamó a primera vista.

Sunset versioning (mi preferido para la mayoría de los casos):

1. Deployás v2 con soporte backward-compatible con v1
2. Anunciás sunset de v1 con fecha (mínimo 6 meses)
3. Agregás deprecation warnings en los headers de respuesta:
   Deprecation: true
   Sunset: Sat, 01 Jan 2027 00:00:00 GMT
   Link: <https://docs.tuapi.com/v2>; rel="successor-version"
4. Monitoreás qué clientes siguen usando v1 acercándose a la fecha
5. Contactás activamente a los que no migraron
6. Apagás v1

Lo que más importa en API versioning:

• Breaking changes vs non-breaking changes: agregar campos es non-breaking, cambiar tipos o remover campos es breaking
• Contract testing (Pact, Dredd): testear que el productor y el consumidor tienen el contrato sincronizado
• Semantic versioning para SDKs: MAJOR.MINOR.PATCH con changelog detallado"

Errores comunes en entrevistas de Staff

Error 1: Responder como Senior a preguntas de Staff

Cuando te preguntan "¿cómo mejorarías la performance del sistema?", si tu respuesta es sobre optimizar queries o cachear llamadas a la DB, estás respondiendo como Senior. La respuesta de Staff incluye: cómo identificás cuál parte del sistema tiene el mayor impacto, cómo priorizás con el PM, cómo comunicás el plan a múltiples equipos, y cómo medís el éxito.

Error 2: Proponer soluciones sin mencionar tradeoffs

"Usamos Kubernetes" es una respuesta de Senior. "Usamos Kubernetes porque necesitamos X, lo que nos da Y, a costo de Z. Evaluamos también Docker Swarm porque es más simple operacionalmente, pero en este caso X justifica la complejidad adicional" es una respuesta de Staff.

Error 3: No preguntar suficiente en el Design Round

Los entrevistadores de Staff premian las buenas preguntas. Si empezás a diseñar en los primeros dos minutos sin clarificar requirements, parecés un Senior que quiere llegar a la solución rápido.

Error 4: No mencionar el failure mode

¿Qué pasa cuando el Redis se cae? ¿Cuándo el Kafka tiene lag de 10 minutos? ¿Cuando el servicio B no responde? Los candidatos de Staff piensan en resilience desde el diseño, no como afterthought.

Error 5: Dar respuestas de libro de texto

"Para consistencia eventual usamos CRDT" puede ser correcto o puede ser totalmente inapropiado para el contexto dado. Los entrevistadores de Staff saben cuando alguien memorizó respuestas vs. cuando realmente entiende los tradeoffs.

Error 6: No demostrar ownership de resultados negativos

Cuando te pregunten sobre fracasos o errores, los candidatos que dicen "el equipo tomó la decisión equivocada" o "el PM nos presionó y por eso salió mal" pierden puntos. Los candidatos de Staff asumen responsabilidad porque en ese nivel el ownership es total.

Qué hacés el día anterior a la entrevista

No estudies nuevos conceptos. Si llegaste hasta el día anterior sin saber qué es un CRDT, no lo vas a aprender en 12 horas de forma útil. Lo que sí podés hacer:

1. 1Preparate 5-6 historias STAR fuertes de tu carrera que cubran: decisión técnica difícil, conflicto con otro equipo, proyecto que falló y qué aprendiste, mentoring de alguien que creció, cambio que impactó positivamente a múltiples equipos.

1. 2Practicá tu Design Round en voz alta. Tomá cualquier sistema conocido (Twitter feed, Uber surge pricing, Slack message delivery) y explicalo en voz alta como si estuvieras en la entrevista. El primer draft mental siempre está desorganizado; practicarlo en voz alta fuerza la claridad.

1. 3Preparate preguntas para hacer vos. Tener preguntas buenas al final de cada round demuestra que pensaste en el rol, no solo en pasar la entrevista.

1. 4Revisá el contexto de la empresa. No la landing page — buscá artículos de engineering blog, papers de sistemas, posts técnicos en LinkedIn de los engineers. Cuando podés referenciar un problema técnico real que tuvo la empresa, la conversación cambia completamente.

Cómo InterviewHack.ai te ayuda a prepararte

Prepararse para una entrevista de Staff Engineer requiere practicar el tipo correcto de preguntas con feedback que apunte a lo que falta. El dossier de InterviewHack.ai genera las preguntas específicas para la empresa y el rol que estás aplicando, ancladas en tu CV real, no en respuestas genéricas. La práctica guiada te ayuda a articular tus historias bajo presión — porque saber la respuesta y poder decirla fluida bajo estrés son dos habilidades distintas.