./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 [ ]Backend · JavaSpring Boot [x]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 operaciones críticas: atomicidad, fallas parciales con terceros y diseño reusable dentro del pipeline de ASP.NET Core.60 min

Implementá POST /payments en ASP.NET Core con header Idempotency-Key y body { "amount": 2500.00, "currency": "ARS", "customerId": "c_42" }. El endpoint llama a un IPaymentGateway externo que puede tardar varios segundos o hacer timeout.

Un reintento con la misma key y el mismo body devuelve la respuesta original sin volver a cobrar; con otro body, 422; si el original sigue en curso, 409. Las keys se guardan en SQL Server o Postgres con EF Core.

# requisitos

-La reserva de la key es atómica con un índice único; manejá la DbUpdateException por duplicado.
-Guardá hash del body, estado y respuesta serializada.
-Implementá la lógica como un endpoint filter o middleware reusable, no dentro del handler.
-Definí qué pasa con keys que quedan en Processing porque el proceso murió.
-Escribí un test de integración con WebApplicationFactory que envíe requests concurrentes con la misma key.

# si te sobra tiempo, te van a preguntar

-¿Cómo reconciliás un pago que el gateway procesó pero cuya respuesta nunca te llegó?
-¿Meterías la llamada al gateway dentro de una transacción de base? ¿Por qué no?
-¿Cómo limpiarías keys viejas sin bloquear la tabla?

02Rate limiter por clienteQue sepas implementar un algoritmo concurrente correcto en .NET, testeable y con un plan claro para escalarlo.45 min

Implementá desde cero un rate limiter con token bucket: cada API key tiene una capacidad de N tokens que se recargan a R tokens por segundo. Exponelo como middleware que responde 429 con Retry-After cuando no hay tokens.

Después comparalo con el middleware de rate limiting que trae ASP.NET Core (AddRateLimiter) y explicá cómo lo llevarías a varias instancias con Redis.

# requisitos

-El bucket se recarga de forma lazy según el tiempo transcurrido, sin timers por cliente.
-La operación de consumir un token es thread-safe sin un lock global para todos los clientes.
-Inyectá el reloj (TimeProvider) para poder testear sin esperar.
-Los buckets de clientes inactivos se liberan.
-Distintos planes de cliente tienen capacidades distintas, leídas de configuración.

# si te sobra tiempo, te van a preguntar

-¿Qué diferencia hay entre token bucket, fixed window y sliding window en ráfagas de tráfico?
-¿Cómo garantizás atomicidad en Redis?
-¿Qué hacés si Redis no responde?

03Modelar el ciclo de vida de una ordenTu capacidad de modelar un dominio con reglas claras, efectos desacoplados y consistencia ante concurrencia.60 min

Una orden pasa por los estados Created, Paid, Shipped, Delivered y Cancelled. Solo se puede cancelar antes del envío, solo se puede enviar si está pagada, y cada cambio de estado tiene que disparar efectos: emails, liberar stock, avisar a logística.

Diseñá en C# el modelo de dominio y el servicio de aplicación para estas transiciones, de forma que las reglas no queden repartidas en controllers ni en if sueltos.

# requisitos

-La entidad Order encapsula sus transiciones con métodos como Pay(), Ship() y Cancel(); el estado no tiene setter público.
-Una transición inválida devuelve un error de dominio claro (excepción propia o un tipo Result, justificá la elección).
-Los efectos se modelan como domain events que se despachan después de guardar, no dentro de la entidad.
-Explicá cómo garantizarías que los eventos no se pierdan si falla el envío después del commit (outbox).
-Escribí tests unitarios de las transiciones sin depender de la base.

# si te sobra tiempo, te van a preguntar

-¿Cómo manejarías dos requests concurrentes que intentan Ship() y Cancel() sobre la misma orden?
-¿Usarías una librería de state machine como Stateless? ¿Qué ganás y qué perdés?
-¿Cómo versionarías los eventos si otros servicios los consumen?

# leetcode recomendado (Backend · .NET · Senior)

HardLFU CacheMantener varias estructuras sincronizadas en O(1), una prueba exigente de diseño de estructuras de datos.

HardFind Median from Data StreamDos heaps con PriorityQueue para una métrica en streaming, la idea detrás de percentiles en vivo.

MediumAccounts MergeUnion-find o DFS para unificar entidades duplicadas, un problema real de deduplicación de clientes.

HardSerialize and Deserialize Binary TreeDiseñar un formato de serialización y su parser, algo que como senior tenés que razonar con cuidado.

MediumFizz Buzz MultithreadedCoordinar cuatro threads sobre un estado compartido, ideal para practicar SemaphoreSlim y Monitor.

MediumDesign a Food Rating SystemCombinar diccionarios con estructuras ordenadas y actualizaciones, como un ranking que cambia en vivo.

HardDepartment Top Three SalariesFunciones de ventana como DENSE_RANK para el top N por grupo, una consulta que un senior debería dominar.

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 operaciones críticas: atomicidad, fallas parciales con terceros y diseño reusable dentro del pipeline de ASP.NET Core.60 min

# requisitos

-La reserva de la key es atómica con un índice único; manejá la DbUpdateException por duplicado.
-Guardá hash del body, estado y respuesta serializada.
-Implementá la lógica como un endpoint filter o middleware reusable, no dentro del handler.
-Definí qué pasa con keys que quedan en Processing porque el proceso murió.
-Escribí un test de integración con WebApplicationFactory que envíe requests concurrentes con la misma key.

# si te sobra tiempo, te van a preguntar

-¿Cómo reconciliás un pago que el gateway procesó pero cuya respuesta nunca te llegó?
-¿Meterías la llamada al gateway dentro de una transacción de base? ¿Por qué no?
-¿Cómo limpiarías keys viejas sin bloquear la tabla?

02Rate limiter por clienteQue sepas implementar un algoritmo concurrente correcto en .NET, testeable y con un plan claro para escalarlo.45 min

Después comparalo con el middleware de rate limiting que trae ASP.NET Core (AddRateLimiter) y explicá cómo lo llevarías a varias instancias con Redis.

# requisitos

-El bucket se recarga de forma lazy según el tiempo transcurrido, sin timers por cliente.
-La operación de consumir un token es thread-safe sin un lock global para todos los clientes.
-Inyectá el reloj (TimeProvider) para poder testear sin esperar.
-Los buckets de clientes inactivos se liberan.
-Distintos planes de cliente tienen capacidades distintas, leídas de configuración.

# si te sobra tiempo, te van a preguntar

-¿Qué diferencia hay entre token bucket, fixed window y sliding window en ráfagas de tráfico?
-¿Cómo garantizás atomicidad en Redis?
-¿Qué hacés si Redis no responde?

03Modelar el ciclo de vida de una ordenTu capacidad de modelar un dominio con reglas claras, efectos desacoplados y consistencia ante concurrencia.60 min

Diseñá en C# el modelo de dominio y el servicio de aplicación para estas transiciones, de forma que las reglas no queden repartidas en controllers ni en if sueltos.

# requisitos

-La entidad Order encapsula sus transiciones con métodos como Pay(), Ship() y Cancel(); el estado no tiene setter público.
-Una transición inválida devuelve un error de dominio claro (excepción propia o un tipo Result, justificá la elección).
-Los efectos se modelan como domain events que se despachan después de guardar, no dentro de la entidad.
-Explicá cómo garantizarías que los eventos no se pierdan si falla el envío después del commit (outbox).
-Escribí tests unitarios de las transiciones sin depender de la base.

# si te sobra tiempo, te van a preguntar

-¿Cómo manejarías dos requests concurrentes que intentan Ship() y Cancel() sobre la misma orden?
-¿Usarías una librería de state machine como Stateless? ¿Qué ganás y qué perdés?
-¿Cómo versionarías los eventos si otros servicios los consumen?

# leetcode recomendado (Backend · .NET · Senior)

HardLFU CacheMantener varias estructuras sincronizadas en O(1), una prueba exigente de diseño de estructuras de datos.

HardFind Median from Data StreamDos heaps con PriorityQueue para una métrica en streaming, la idea detrás de percentiles en vivo.

MediumAccounts MergeUnion-find o DFS para unificar entidades duplicadas, un problema real de deduplicación de clientes.

HardSerialize and Deserialize Binary TreeDiseñar un formato de serialización y su parser, algo que como senior tenés que razonar con cuidado.

MediumFizz Buzz MultithreadedCoordinar cuatro threads sobre un estado compartido, ideal para practicar SemaphoreSlim y Monitor.

MediumDesign a Food Rating SystemCombinar diccionarios con estructuras ordenadas y actualizaciones, como un ranking que cambia en vivo.

HardDepartment Top Three SalariesFunciones de ventana como DENSE_RANK para el top N por grupo, una consulta que un senior debería dominar.