./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 [x]Semi-senior [ ]Senior

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

01Listado de productos con paginación y filtrosQue sepas diseñar un endpoint de listado que escala: validación de entrada, paginación por cursor y la relación entre la query y los índices.45 min

Tenemos un endpoint GET /products en NestJS o Express que hoy devuelve los 50.000 productos de una vez. Modificalo para que acepte ?limit=20&cursor=<cursor>&category=books&minPrice=10 y responda { data: Product[], nextCursor: string | null }. Un producto es { id: number, name: string, category: string, price: number, createdAt: string }.

Para el ejercicio podés simular la base con un array ordenado por createdAt descendente y id como desempate, pero escribí la consulta SQL equivalente que usarías en Postgres.

# requisitos

-Usá paginación por cursor (keyset), no OFFSET; el cursor codifica createdAt e id del último elemento.
-Validá los query params: limit entre 1 y 100 con default 20, minPrice numérico; si son inválidos respondé 400.
-Los filtros se aplican antes de paginar y el cursor sigue siendo válido con los mismos filtros.
-nextCursor es null cuando no hay más resultados.
-Explicá qué índice crearías para que la consulta sea eficiente.

# si te sobra tiempo, te van a preguntar

-¿Por qué OFFSET se degrada con tablas grandes y qué problema tiene si se insertan filas mientras paginás?
-¿Cómo harías para que el cliente no pueda manipular el cursor?
-¿Cómo agregarías ordenamiento por price sin romper el cursor?

02Cache en memoria con TTL y deduplicaciónTu dominio de promesas y concurrencia en el event loop de Node, y si pensás en fallas, memoria y el problema de thundering herd.45 min

Un servicio llama muchas veces por segundo a getExchangeRate(currency), que consulta una API lenta. Escribí una clase TtlCache<K, V> con get(key, loader) que devuelva el valor cacheado si no venció o, si no, llame a loader() (async), lo guarde con un TTL configurable y lo devuelva.

Además, si llegan 100 llamadas simultáneas para la misma key mientras el valor no está en cache, loader tiene que ejecutarse una sola vez y todas las llamadas tienen que recibir el mismo resultado.

# requisitos

-El TTL se pasa en el constructor y la expiración se evalúa al leer (lazy), sin un setInterval por cada clave.
-Las llamadas concurrentes a la misma clave comparten la misma promesa en vuelo.
-Si loader falla, el error se propaga a todos los que esperaban y no se cachea.
-Exponé delete(key) y clear().
-Toda la clase está tipada con genéricos.

# si te sobra tiempo, te van a preguntar

-¿Cómo limitarías la cantidad de entradas para que no crezca la memoria sin control?
-¿Qué pasa si tenés varias instancias del servicio detrás de un load balancer? ¿Cuándo pasarías a Redis?
-¿Qué es stale-while-revalidate y cómo lo implementarías acá?

03Procesar un archivo de logs grandeQue sepas procesar datos grandes en Node sin bloquear ni explotar la memoria, y que razones sobre métricas como percentiles.45 min

Tenemos un archivo de access logs de 5 GB donde cada línea tiene el formato 2024-05-01T10:00:00Z GET /api/users 200 123ms. Escribí un script en Node que lo lea y devuelva, por cada endpoint (método más path), la cantidad de requests, el porcentaje de respuestas 5xx y la latencia p95.

La salida esperada es un array como [{ endpoint: "GET /api/users", count: 1520, errorRate: 0.02, p95Ms: 340 }] ordenado por count descendente.

# requisitos

-No cargues el archivo entero en memoria: usá streams (fs.createReadStream con readline o similar).
-Las líneas mal formadas se cuentan y se saltean sin cortar el proceso.
-Normalizá paths con IDs, por ejemplo /api/users/42 pasa a /api/users/:id.
-Explicá la complejidad en memoria de tu cálculo de p95.

# si te sobra tiempo, te van a preguntar

-¿Qué harías si guardar todas las latencias por endpoint no entra en memoria?
-¿Cómo lo paralelizarías usando worker_threads o varios procesos?
-¿Qué es el backpressure en streams y cuándo te importaría acá?

# leetcode recomendado (Backend · Node.js · Semi-senior)

MediumGroup AnagramsAgrupar por una clave calculada es exactamente lo que hacés al agregar datos en un servicio.

MediumLongest Substring Without Repeating CharactersEl problema de referencia para sliding window, el patrón detrás de rate limiters y métricas por ventana.

MediumMerge IntervalsOrdenar y fusionar intervalos aparece en reservas, turnos y rangos de fechas en APIs reales.

MediumTop K Frequent ElementsCombina conteo con heap o bucket sort, igual que sacar los endpoints o usuarios más activos de un log.

MediumTime Based Key-Value StoreDiseñar una estructura con versiones por timestamp y búsqueda binaria se parece mucho a un cache o un store real.

EasyNumber of Recent CallsContar requests dentro de una ventana de tiempo con una cola es la base de un rate limiter.

MediumDepartment Highest SalaryPractica JOIN con subconsultas o funciones de ventana para quedarte con el máximo por grupo.

enunciados + leetcode

# 1. tecnología

# 2. seniority

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

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

Para el ejercicio podés simular la base con un array ordenado por createdAt descendente y id como desempate, pero escribí la consulta SQL equivalente que usarías en Postgres.

# requisitos

-Usá paginación por cursor (keyset), no OFFSET; el cursor codifica createdAt e id del último elemento.
-Validá los query params: limit entre 1 y 100 con default 20, minPrice numérico; si son inválidos respondé 400.
-Los filtros se aplican antes de paginar y el cursor sigue siendo válido con los mismos filtros.
-nextCursor es null cuando no hay más resultados.
-Explicá qué índice crearías para que la consulta sea eficiente.

# si te sobra tiempo, te van a preguntar

-¿Por qué OFFSET se degrada con tablas grandes y qué problema tiene si se insertan filas mientras paginás?
-¿Cómo harías para que el cliente no pueda manipular el cursor?
-¿Cómo agregarías ordenamiento por price sin romper el cursor?

02Cache en memoria con TTL y deduplicaciónTu dominio de promesas y concurrencia en el event loop de Node, y si pensás en fallas, memoria y el problema de thundering herd.45 min

# requisitos

-El TTL se pasa en el constructor y la expiración se evalúa al leer (lazy), sin un setInterval por cada clave.
-Las llamadas concurrentes a la misma clave comparten la misma promesa en vuelo.
-Si loader falla, el error se propaga a todos los que esperaban y no se cachea.
-Exponé delete(key) y clear().
-Toda la clase está tipada con genéricos.

# si te sobra tiempo, te van a preguntar

-¿Cómo limitarías la cantidad de entradas para que no crezca la memoria sin control?
-¿Qué pasa si tenés varias instancias del servicio detrás de un load balancer? ¿Cuándo pasarías a Redis?
-¿Qué es stale-while-revalidate y cómo lo implementarías acá?

03Procesar un archivo de logs grandeQue sepas procesar datos grandes en Node sin bloquear ni explotar la memoria, y que razones sobre métricas como percentiles.45 min

La salida esperada es un array como [{ endpoint: "GET /api/users", count: 1520, errorRate: 0.02, p95Ms: 340 }] ordenado por count descendente.

# requisitos

-No cargues el archivo entero en memoria: usá streams (fs.createReadStream con readline o similar).
-Las líneas mal formadas se cuentan y se saltean sin cortar el proceso.
-Normalizá paths con IDs, por ejemplo /api/users/42 pasa a /api/users/:id.
-Explicá la complejidad en memoria de tu cálculo de p95.

# si te sobra tiempo, te van a preguntar

-¿Qué harías si guardar todas las latencias por endpoint no entra en memoria?
-¿Cómo lo paralelizarías usando worker_threads o varios procesos?
-¿Qué es el backpressure en streams y cuándo te importaría acá?

# leetcode recomendado (Backend · Node.js · Semi-senior)

MediumGroup AnagramsAgrupar por una clave calculada es exactamente lo que hacés al agregar datos en un servicio.

MediumLongest Substring Without Repeating CharactersEl problema de referencia para sliding window, el patrón detrás de rate limiters y métricas por ventana.

MediumMerge IntervalsOrdenar y fusionar intervalos aparece en reservas, turnos y rangos de fechas en APIs reales.

MediumTop K Frequent ElementsCombina conteo con heap o bucket sort, igual que sacar los endpoints o usuarios más activos de un log.

MediumTime Based Key-Value StoreDiseñar una estructura con versiones por timestamp y búsqueda binaria se parece mucho a un cache o un store real.

EasyNumber of Recent CallsContar requests dentro de una ventana de tiempo con una cola es la base de un rate limiter.

MediumDepartment Highest SalaryPractica JOIN con subconsultas o funciones de ventana para quedarte con el máximo por grupo.