./live-coding

enunciados + leetcode

Enunciados como los de una entrevista real para resolver por tu cuenta, con el tiempo que te darían, y problemas de LeetCode recomendados para cada tecnología y seniority. Nada se corrige acá: resolvelo en tu editor, en voz alta, y marcá lo que ya practicaste.

# 1. tecnología

[ ]Frontend · React.jsweb, hooks, Next.js [ ]Frontend · iOSSwift, SwiftUI, UIKit [ ]Frontend · AndroidKotlin, Jetpack Compose [ ]Frontend · React NativeExpo, iOS y Android [x]Backend · Node.jsExpress, NestJS [ ]Backend · PythonDjango, FastAPI [ ]Backend · JavaSpring Boot [ ]Backend · .NETC#, ASP.NET Core [ ]AI engineeringconstruir agentes de IA [ ]Agentic engineeringdesarrollar con agentes [ ]Quality engineeringtesting manual y automatizado

# 2. seniority

[ ]Junior [ ]Semi-senior [x]Senior

# ejercicios (resolvelos por tu cuenta, con el tiempo que darían en la entrevista)

01Endpoint de pagos idempotenteTu criterio para diseñar operaciones seguras ante reintentos y fallas parciales, cuidando la atomicidad y la separación de responsabilidades.60 min

Diseñá e implementá POST /payments en NestJS. El cliente manda el header Idempotency-Key y un body { amount: number, currency: string, customerId: string }. El endpoint llama a un PaymentProvider.charge() externo que puede tardar varios segundos o hacer timeout.

Si el cliente reintenta con la misma key y el mismo body, tiene que recibir exactamente la misma respuesta sin cobrar dos veces. Si reintenta con la misma key y un body distinto, respondé 422. Si llega un reintento mientras el primer request todavía se está procesando, respondé 409.

# requisitos

-Persistí las keys en una tabla (podés escribir el schema SQL) con estado processing, completed o failed, hash del body y respuesta guardada.
-La reserva de la key es atómica: usá un constraint único o INSERT ... ON CONFLICT, no un SELECT seguido de INSERT.
-Definí qué pasa si el proceso muere con la key en processing.
-Las keys expiran después de 24 horas.
-Separá el controller, el servicio de idempotencia y el cliente del proveedor para poder testearlos por separado.

# si te sobra tiempo, te van a preguntar

-¿Cómo te protegés si el proveedor cobró pero vos hiciste timeout antes de recibir la respuesta?
-¿Lo resolverías como interceptor de NestJS para reusarlo en otros endpoints? ¿Qué limitaciones tiene?
-¿Qué cambia si en vez de Postgres usás Redis para guardar las keys?
-¿Cómo lo testearías, incluyendo requests concurrentes?

02Cola de jobs con concurrencia y reintentosQue sepas coordinar trabajo asíncrono concurrente en Node con límites, reintentos y apagado ordenado, que es la base de cualquier sistema de background jobs.60 min

Implementá en TypeScript una JobQueue en memoria. Se registran handlers con queue.process(type, handler, { concurrency }) y se encolan jobs con queue.add(type, payload, { maxAttempts, backoffMs }). Un handler es (payload) => Promise<void>.

La cola tiene que ejecutar como máximo concurrency jobs del mismo tipo en paralelo, reintentar los fallidos con backoff exponencial hasta maxAttempts y, cuando se agotan, moverlos a una dead letter queue consultable con queue.failed().

# requisitos

-El límite de concurrencia se respeta siempre, incluso si se encolan 1.000 jobs de golpe.
-Un job que tira una excepción o rechaza la promesa cuenta como intento fallido.
-Soportá un timeout por job: si el handler no termina a tiempo, el intento falla.
-Implementá queue.close() que deja de tomar jobs nuevos y espera a que terminen los que están corriendo (graceful shutdown).
-Emití eventos completed y failed con EventEmitter.

# si te sobra tiempo, te van a preguntar

-¿Qué garantías perdés por ser en memoria y cómo lo llevarías a BullMQ o a una tabla en Postgres con SELECT ... FOR UPDATE SKIP LOCKED?
-¿Cómo harías para que un handler sea idempotente si el job se procesa dos veces?
-¿Cómo agregarías prioridades o jobs diferidos?

03Rate limiter como middlewareTu capacidad para elegir un algoritmo con trade-offs claros y llevarlo a un entorno distribuido sin condiciones de carrera.45 min

Escribí un middleware de Express que limite cada API key a N requests por ventana de W segundos. La key viene en el header X-Api-Key. Cuando se excede el límite, respondé 429 con el header Retry-After indicando cuántos segundos faltan.

Primero implementalo con un store en memoria detrás de una interfaz RateLimitStore, y después explicá o esbozá la implementación con Redis para que funcione con varias instancias del servicio.

# requisitos

-Elegí y justificá el algoritmo: fixed window, sliding window log, sliding window counter o token bucket.
-Agregá los headers X-RateLimit-Limit y X-RateLimit-Remaining en todas las respuestas.
-El store en memoria no crece sin límite con keys que dejaron de usarse.
-En la versión con Redis, la operación de chequear e incrementar es atómica (por ejemplo con un script Lua o MULTI).
-El middleware es configurable por ruta.

# si te sobra tiempo, te van a preguntar

-¿Qué hacés si Redis no responde: dejás pasar el tráfico o lo bloqueás?
-¿Cómo soportarías límites distintos por plan de cliente?
-¿Qué problema tiene fixed window en el borde entre dos ventanas?

# leetcode recomendado (Backend · Node.js · Senior)

MediumLRU CacheCombinar hash map con lista doblemente enlazada para operaciones O(1) es una pregunta de diseño casi obligada.

HardLFU CacheLleva el LRU un paso más allá y prueba si podés mantener varias estructuras sincronizadas sin errores.

MediumCourse Schedule IIOrden topológico y detección de ciclos, lo mismo que resolver dependencias entre jobs, migraciones o paquetes.

HardMerge k Sorted ListsUsar un heap para fusionar k fuentes ordenadas es el patrón de combinar streams o resultados de varias shards.

HardSliding Window MaximumLa deque monótona resuelve métricas por ventana en O(n), útil para monitoreo y agregaciones en tiempo real.

MediumDesign Authentication ManagerModela tokens con expiración y renovación, el mismo problema que sesiones o un cache con TTL.

HardTrips and UsersUna consulta con varios JOIN, filtros y agregación condicional, como las que escribís para reportes de negocio.

enunciados + leetcode

# 1. tecnología

# 2. seniority

[ ]Junior [ ]Semi-senior [x]Senior

# ejercicios (resolvelos por tu cuenta, con el tiempo que darían en la entrevista)

01Endpoint de pagos idempotenteTu criterio para diseñar operaciones seguras ante reintentos y fallas parciales, cuidando la atomicidad y la separación de responsabilidades.60 min

# requisitos

-Persistí las keys en una tabla (podés escribir el schema SQL) con estado processing, completed o failed, hash del body y respuesta guardada.
-La reserva de la key es atómica: usá un constraint único o INSERT ... ON CONFLICT, no un SELECT seguido de INSERT.
-Definí qué pasa si el proceso muere con la key en processing.
-Las keys expiran después de 24 horas.
-Separá el controller, el servicio de idempotencia y el cliente del proveedor para poder testearlos por separado.

# si te sobra tiempo, te van a preguntar

-¿Cómo te protegés si el proveedor cobró pero vos hiciste timeout antes de recibir la respuesta?
-¿Lo resolverías como interceptor de NestJS para reusarlo en otros endpoints? ¿Qué limitaciones tiene?
-¿Qué cambia si en vez de Postgres usás Redis para guardar las keys?
-¿Cómo lo testearías, incluyendo requests concurrentes?

# requisitos

-El límite de concurrencia se respeta siempre, incluso si se encolan 1.000 jobs de golpe.
-Un job que tira una excepción o rechaza la promesa cuenta como intento fallido.
-Soportá un timeout por job: si el handler no termina a tiempo, el intento falla.
-Implementá queue.close() que deja de tomar jobs nuevos y espera a que terminen los que están corriendo (graceful shutdown).
-Emití eventos completed y failed con EventEmitter.

# si te sobra tiempo, te van a preguntar

-¿Qué garantías perdés por ser en memoria y cómo lo llevarías a BullMQ o a una tabla en Postgres con SELECT ... FOR UPDATE SKIP LOCKED?
-¿Cómo harías para que un handler sea idempotente si el job se procesa dos veces?
-¿Cómo agregarías prioridades o jobs diferidos?

03Rate limiter como middlewareTu capacidad para elegir un algoritmo con trade-offs claros y llevarlo a un entorno distribuido sin condiciones de carrera.45 min

Primero implementalo con un store en memoria detrás de una interfaz RateLimitStore, y después explicá o esbozá la implementación con Redis para que funcione con varias instancias del servicio.

# requisitos

-Elegí y justificá el algoritmo: fixed window, sliding window log, sliding window counter o token bucket.
-Agregá los headers X-RateLimit-Limit y X-RateLimit-Remaining en todas las respuestas.
-El store en memoria no crece sin límite con keys que dejaron de usarse.
-En la versión con Redis, la operación de chequear e incrementar es atómica (por ejemplo con un script Lua o MULTI).
-El middleware es configurable por ruta.

# si te sobra tiempo, te van a preguntar

-¿Qué hacés si Redis no responde: dejás pasar el tráfico o lo bloqueás?
-¿Cómo soportarías límites distintos por plan de cliente?
-¿Qué problema tiene fixed window en el borde entre dos ventanas?

# leetcode recomendado (Backend · Node.js · Senior)

MediumLRU CacheCombinar hash map con lista doblemente enlazada para operaciones O(1) es una pregunta de diseño casi obligada.

HardLFU CacheLleva el LRU un paso más allá y prueba si podés mantener varias estructuras sincronizadas sin errores.

MediumCourse Schedule IIOrden topológico y detección de ciclos, lo mismo que resolver dependencias entre jobs, migraciones o paquetes.

HardMerge k Sorted ListsUsar un heap para fusionar k fuentes ordenadas es el patrón de combinar streams o resultados de varias shards.

HardSliding Window MaximumLa deque monótona resuelve métricas por ventana en O(n), útil para monitoreo y agregaciones en tiempo real.

MediumDesign Authentication ManagerModela tokens con expiración y renovación, el mismo problema que sesiones o un cache con TTL.

HardTrips and UsersUna consulta con varios JOIN, filtros y agregación condicional, como las que escribís para reportes de negocio.