./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 [ ]Backend · Node.jsExpress, NestJS [ ]Backend · PythonDjango, FastAPI [x]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)

01Transferencias idempotentes y consistentesTu criterio con transacciones, concurrencia en la base e idempotencia, que es lo que separa una API que funciona de una que no pierde plata.60 min

Implementá en Spring Boot POST /transfers con body { "fromAccount": "A", "toAccount": "B", "amount": 1500.00 } y header Idempotency-Key. Las cuentas están en Postgres con JPA y la transferencia tiene que debitar y acreditar de forma atómica.

Reintentos con la misma key y el mismo body devuelven la respuesta original sin duplicar el movimiento; con otro body, 422; si el original sigue en curso, 409. Además, dos transferencias concurrentes desde la misma cuenta no pueden dejar saldo negativo.

# requisitos

-Guardá las keys con un constraint único y decidí si se registran en la misma transacción que el movimiento.
-Evitá condiciones de carrera sobre el saldo con locking pesimista (@Lock(PESSIMISTIC_WRITE)) u optimista (@Version) y justificá la elección.
-Bloqueá las cuentas en un orden determinista para evitar deadlocks.
-Las validaciones de negocio devuelven errores claros: saldo insuficiente, cuenta inexistente, misma cuenta.
-Escribí un test de integración (por ejemplo con Testcontainers) que dispare transferencias concurrentes.

# si te sobra tiempo, te van a preguntar

-¿Cómo manejás el reintento cuando falla el locking optimista?
-¿Qué cambia si las cuentas viven en dos microservicios distintos? ¿Saga, outbox?
-¿Qué nivel de aislamiento de transacción usarías y por qué?

02Pool de workers con cola acotada y reintentosUn entendimiento profundo del modelo de concurrencia de Java: locks, condiciones, interrupciones y el Java Memory Model.60 min

Sin usar ExecutorService, implementá un WorkerPool con N threads que toman tareas de una cola acotada. submit(task) bloquea si la cola está llena, o falla después de un timeout configurable. Las tareas que lanzan excepción se reintentan hasta 3 veces y después van a una lista de fallidas.

El pool tiene que soportar shutdown() (no acepta nuevas tareas y termina las encoladas) y shutdownNow() (interrumpe los workers y devuelve las pendientes).

# requisitos

-Usá BlockingQueue o implementá la cola con ReentrantLock y Condition.
-Respetá la interrupción de threads: no tragues InterruptedException.
-Los contadores de completadas y fallidas son thread-safe (AtomicInteger o LongAdder).
-Un worker que muere por una excepción inesperada no reduce el tamaño del pool.
-Explicá qué garantías de visibilidad de memoria te da cada primitiva que usaste.

# si te sobra tiempo, te van a preguntar

-¿En qué se diferencia tu solución de ThreadPoolExecutor y su RejectedExecutionHandler?
-¿Cómo cambiaría el diseño con virtual threads?
-¿Cómo detectarías un worker trabado?

03Rate limiter distribuido como filtroTu capacidad para diseñar un componente transversal, elegir un algoritmo con criterio y llevarlo a un entorno distribuido.45 min

Implementá un OncePerRequestFilter de Spring que limite cada cliente (identificado por el header X-Api-Key) a una cantidad de requests por minuto que depende de su plan: FREE 60, PRO 600. Al excederse, respondé 429 con Retry-After.

Definí una interfaz RateLimiter con una implementación en memoria para tests y otra basada en Redis para producción, con varias instancias de la app.

# requisitos

-Elegí el algoritmo (token bucket, sliding window log o sliding window counter) y explicá sus trade-offs.
-La implementación en memoria es thread-safe y no acumula claves de clientes inactivos para siempre.
-En Redis, chequear e incrementar es atómico (script Lua o comandos atómicos).
-El filtro no aplica a rutas excluidas como /actuator/health.
-Agregá los headers X-RateLimit-Limit y X-RateLimit-Remaining.

# si te sobra tiempo, te van a preguntar

-¿Qué hacés si Redis está caído: fail open o fail closed?
-¿Lo pondrías en la app o en el API gateway?
-¿Cómo testearías el comportamiento en el borde de la ventana?

# leetcode recomendado (Backend · Java · Senior)

MediumLRU CacheLa pregunta de diseño de estructuras más frecuente; en Java además te preguntan por LinkedHashMap.

HardMerge k Sorted ListsFusionar k fuentes ordenadas con PriorityQueue, como combinar resultados de varias particiones.

HardWord LadderBFS sobre un grafo implícito, entrena modelar un problema como grafo antes de codear.

MediumInsert Delete GetRandom O(1)Combinar HashMap y ArrayList para cumplir varias operaciones O(1) a la vez.

MediumThe Dining PhilosophersEl problema clásico de deadlock; te obliga a explicar orden de locks y starvation.

MediumBuilding H2OSincronizar grupos de threads con Semaphore y CyclicBarrier, un ejercicio exigente de coordinación.

HardTrips and UsersVarios JOIN, filtros y agregación condicional en una sola consulta, como un reporte de negocio real.

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)

01Transferencias idempotentes y consistentesTu criterio con transacciones, concurrencia en la base e idempotencia, que es lo que separa una API que funciona de una que no pierde plata.60 min

# requisitos

-Guardá las keys con un constraint único y decidí si se registran en la misma transacción que el movimiento.
-Evitá condiciones de carrera sobre el saldo con locking pesimista (@Lock(PESSIMISTIC_WRITE)) u optimista (@Version) y justificá la elección.
-Bloqueá las cuentas en un orden determinista para evitar deadlocks.
-Las validaciones de negocio devuelven errores claros: saldo insuficiente, cuenta inexistente, misma cuenta.
-Escribí un test de integración (por ejemplo con Testcontainers) que dispare transferencias concurrentes.

# si te sobra tiempo, te van a preguntar

-¿Cómo manejás el reintento cuando falla el locking optimista?
-¿Qué cambia si las cuentas viven en dos microservicios distintos? ¿Saga, outbox?
-¿Qué nivel de aislamiento de transacción usarías y por qué?

02Pool de workers con cola acotada y reintentosUn entendimiento profundo del modelo de concurrencia de Java: locks, condiciones, interrupciones y el Java Memory Model.60 min

El pool tiene que soportar shutdown() (no acepta nuevas tareas y termina las encoladas) y shutdownNow() (interrumpe los workers y devuelve las pendientes).

# requisitos

-Usá BlockingQueue o implementá la cola con ReentrantLock y Condition.
-Respetá la interrupción de threads: no tragues InterruptedException.
-Los contadores de completadas y fallidas son thread-safe (AtomicInteger o LongAdder).
-Un worker que muere por una excepción inesperada no reduce el tamaño del pool.
-Explicá qué garantías de visibilidad de memoria te da cada primitiva que usaste.

# si te sobra tiempo, te van a preguntar

-¿En qué se diferencia tu solución de ThreadPoolExecutor y su RejectedExecutionHandler?
-¿Cómo cambiaría el diseño con virtual threads?
-¿Cómo detectarías un worker trabado?

03Rate limiter distribuido como filtroTu capacidad para diseñar un componente transversal, elegir un algoritmo con criterio y llevarlo a un entorno distribuido.45 min

Definí una interfaz RateLimiter con una implementación en memoria para tests y otra basada en Redis para producción, con varias instancias de la app.

# requisitos

-Elegí el algoritmo (token bucket, sliding window log o sliding window counter) y explicá sus trade-offs.
-La implementación en memoria es thread-safe y no acumula claves de clientes inactivos para siempre.
-En Redis, chequear e incrementar es atómico (script Lua o comandos atómicos).
-El filtro no aplica a rutas excluidas como /actuator/health.
-Agregá los headers X-RateLimit-Limit y X-RateLimit-Remaining.

# si te sobra tiempo, te van a preguntar

-¿Qué hacés si Redis está caído: fail open o fail closed?
-¿Lo pondrías en la app o en el API gateway?
-¿Cómo testearías el comportamiento en el borde de la ventana?

# leetcode recomendado (Backend · Java · Senior)

MediumLRU CacheLa pregunta de diseño de estructuras más frecuente; en Java además te preguntan por LinkedHashMap.

HardMerge k Sorted ListsFusionar k fuentes ordenadas con PriorityQueue, como combinar resultados de varias particiones.

HardWord LadderBFS sobre un grafo implícito, entrena modelar un problema como grafo antes de codear.

MediumInsert Delete GetRandom O(1)Combinar HashMap y ArrayList para cumplir varias operaciones O(1) a la vez.

MediumThe Dining PhilosophersEl problema clásico de deadlock; te obliga a explicar orden de locks y starvation.

MediumBuilding H2OSincronizar grupos de threads con Semaphore y CyclicBarrier, un ejercicio exigente de coordinación.

HardTrips and UsersVarios JOIN, filtros y agregación condicional en una sola consulta, como un reporte de negocio real.