./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 [x]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 idempotente en FastAPITu criterio para operaciones críticas: atomicidad en la base, fallas parciales con terceros y código testeable.60 min

Implementá POST /payments en FastAPI. El cliente envía el header Idempotency-Key y el body { "amount": "100.00", "currency": "ARS", "customer_id": "c_123" }. El endpoint llama a un proveedor externo que puede tardar o fallar.

Un reintento con la misma key y el mismo body debe devolver la respuesta original sin volver a cobrar; con la misma key y otro body, 422; si el primero sigue en curso, 409. Usá Postgres con SQLAlchemy (podés escribir el schema y las queries).

# requisitos

-La reserva de la key es atómica (INSERT ... ON CONFLICT DO NOTHING o constraint único), sin carreras entre dos workers.
-Guardá el hash del body, el estado y la respuesta serializada.
-Resolvé la lógica de idempotencia como una dependencia o un servicio reusable, no mezclada en el handler.
-Definí qué pasa con keys que quedaron en processing porque el proceso murió.
-Escribí al menos un test que dispare dos requests concurrentes con la misma key.

# si te sobra tiempo, te van a preguntar

-¿Cómo te enterás si el proveedor cobró aunque vos hayas recibido un timeout?
-¿Usarías una transacción que envuelva la llamada al proveedor? ¿Por qué no?
-¿Cómo limpiarías las keys viejas sin afectar la performance de la tabla?

02Worker pool con reintentos y dead letter queueQue entiendas el modelo de concurrencia de Python y puedas diseñar un procesamiento en background robusto ante fallas.60 min

Implementá un procesador de jobs en Python sin Celery: una clase JobRunner que recibe jobs { "id": str, "type": str, "payload": dict, "attempts": int }, los reparte entre N workers y ejecuta el handler registrado para cada type.

Los jobs que fallan se reintentan con backoff exponencial hasta max_attempts; después van a una dead letter queue. Elegí si lo hacés con asyncio o con threads y justificalo según el tipo de trabajo.

# requisitos

-Usá una cola de la biblioteca estándar (asyncio.Queue o queue.Queue) como cola de trabajo.
-El reintento con delay no bloquea a un worker mientras espera.
-Implementá un shutdown ordenado: dejar de aceptar jobs, terminar los en curso y devolver los pendientes.
-Exponé métricas simples: procesados, fallidos y en la dead letter queue.
-Un handler que excede su timeout cuenta como intento fallido.

# si te sobra tiempo, te van a preguntar

-¿Qué cambia si los jobs son CPU-bound? ¿Cómo afecta el GIL?
-¿Cómo garantizarías at-least-once si el proceso muere a mitad de un job?
-¿En qué casos lo reemplazarías por Celery, RQ o una tabla con SKIP LOCKED?

03Motor de reglas de precios extensibleTu capacidad de modelar un dominio cambiante con código extensible, testeable y fácil de leer.60 min

Un e-commerce calcula el precio final de un carrito aplicando promociones: "2x1 en el producto X", "10% off en la categoría Y si el carrito supera $50.000" y "envío gratis para clientes premium". Hoy es un if gigante y cada promo nueva rompe algo.

Diseñá en código un módulo que reciba un carrito { "items": [{ "sku": str, "category": str, "price": Decimal, "qty": int }], "customer_tier": str } y una lista de reglas, y devuelva el total y el detalle de descuentos aplicados.

# requisitos

-Cada regla es una clase o función independiente con una interfaz común (Protocol o clase abstracta).
-Agregar una regla nueva no requiere modificar las existentes ni el motor.
-Definí cómo se resuelve el orden y la combinación de reglas: acumulables, excluyentes o con prioridad.
-El resultado es explicable: lista de reglas aplicadas con el monto que descontó cada una.
-Usá Decimal y tipado estricto; escribí tests para al menos dos reglas combinadas.

# si te sobra tiempo, te van a preguntar

-¿Cómo harías para que negocio configure reglas sin deploy (por ejemplo desde la base)?
-¿Cómo evitarías que una combinación de reglas deje un precio negativo?
-¿Qué patrones de diseño reconocés en tu solución?

# leetcode recomendado (Backend · Python · Senior)

MediumLRU CacheDiseñar un cache O(1) con hash map y lista enlazada (o OrderedDict) es una pregunta casi obligada.

HardFind Median from Data StreamDos heaps para mantener una métrica en streaming, la misma idea que calcular percentiles en vivo.

MediumNetwork Delay TimeDijkstra con heapq, útil para razonar sobre propagación en redes y grafos de servicios.

HardMinimum Window SubstringEl sliding window más exigente, prueba si podés mantener invariantes con varios contadores.

MediumBuilding H2OSincronizar grupos de threads con semáforos y barreras, como coordinar workers que dependen entre sí.

MediumTask SchedulerPlanificar tareas con cooldown usando heap y conteos, muy cercano a schedulers de jobs reales.

HardDepartment Top Three SalariesFunciones de ventana como DENSE_RANK para obtener el top N por grupo, algo que todo senior debería escribir de memoria.

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 idempotente en FastAPITu criterio para operaciones críticas: atomicidad en la base, fallas parciales con terceros y código testeable.60 min

# requisitos

-La reserva de la key es atómica (INSERT ... ON CONFLICT DO NOTHING o constraint único), sin carreras entre dos workers.
-Guardá el hash del body, el estado y la respuesta serializada.
-Resolvé la lógica de idempotencia como una dependencia o un servicio reusable, no mezclada en el handler.
-Definí qué pasa con keys que quedaron en processing porque el proceso murió.
-Escribí al menos un test que dispare dos requests concurrentes con la misma key.

# si te sobra tiempo, te van a preguntar

-¿Cómo te enterás si el proveedor cobró aunque vos hayas recibido un timeout?
-¿Usarías una transacción que envuelva la llamada al proveedor? ¿Por qué no?
-¿Cómo limpiarías las keys viejas sin afectar la performance de la tabla?

02Worker pool con reintentos y dead letter queueQue entiendas el modelo de concurrencia de Python y puedas diseñar un procesamiento en background robusto ante fallas.60 min

# requisitos

-Usá una cola de la biblioteca estándar (asyncio.Queue o queue.Queue) como cola de trabajo.
-El reintento con delay no bloquea a un worker mientras espera.
-Implementá un shutdown ordenado: dejar de aceptar jobs, terminar los en curso y devolver los pendientes.
-Exponé métricas simples: procesados, fallidos y en la dead letter queue.
-Un handler que excede su timeout cuenta como intento fallido.

# si te sobra tiempo, te van a preguntar

-¿Qué cambia si los jobs son CPU-bound? ¿Cómo afecta el GIL?
-¿Cómo garantizarías at-least-once si el proceso muere a mitad de un job?
-¿En qué casos lo reemplazarías por Celery, RQ o una tabla con SKIP LOCKED?

03Motor de reglas de precios extensibleTu capacidad de modelar un dominio cambiante con código extensible, testeable y fácil de leer.60 min

# requisitos

-Cada regla es una clase o función independiente con una interfaz común (Protocol o clase abstracta).
-Agregar una regla nueva no requiere modificar las existentes ni el motor.
-Definí cómo se resuelve el orden y la combinación de reglas: acumulables, excluyentes o con prioridad.
-El resultado es explicable: lista de reglas aplicadas con el monto que descontó cada una.
-Usá Decimal y tipado estricto; escribí tests para al menos dos reglas combinadas.

# si te sobra tiempo, te van a preguntar

-¿Cómo harías para que negocio configure reglas sin deploy (por ejemplo desde la base)?
-¿Cómo evitarías que una combinación de reglas deje un precio negativo?
-¿Qué patrones de diseño reconocés en tu solución?

# leetcode recomendado (Backend · Python · Senior)

MediumLRU CacheDiseñar un cache O(1) con hash map y lista enlazada (o OrderedDict) es una pregunta casi obligada.

HardFind Median from Data StreamDos heaps para mantener una métrica en streaming, la misma idea que calcular percentiles en vivo.

MediumNetwork Delay TimeDijkstra con heapq, útil para razonar sobre propagación en redes y grafos de servicios.

HardMinimum Window SubstringEl sliding window más exigente, prueba si podés mantener invariantes con varios contadores.

MediumBuilding H2OSincronizar grupos de threads con semáforos y barreras, como coordinar workers que dependen entre sí.

MediumTask SchedulerPlanificar tareas con cooldown usando heap y conteos, muy cercano a schedulers de jobs reales.

HardDepartment Top Three SalariesFunciones de ventana como DENSE_RANK para obtener el top N por grupo, algo que todo senior debería escribir de memoria.