./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 [ ]Backend · .NETC#, ASP.NET Core [x]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)

01Eval harness para comparar dos promptsQue trates los cambios de prompt como cambios de código que se miden, y que sepas diseñar infraestructura de evaluación extensible.60 min

El equipo quiere cambiar el prompt de un extractor que, dado un email, devuelve { intent: "refund" | "question" | "complaint", orderId: string | null }. Tenés un dataset de 20 casos { input: string, expected: { intent, orderId } } y dos variantes de prompt. El modelo es un mock determinístico model(prompt, input) con respuestas pregrabadas por variante y caso, y algunas respuestas son JSON inválido.

Construí un harness que corra las dos variantes sobre todo el dataset con concurrencia limitada, puntúe cada salida y genere un reporte comparativo: accuracy de intent, exact match de orderId, tasa de JSON inválido, latencia p50 y p95, y la lista de casos donde una variante acierta y la otra no.

# requisitos

-Separar con claridad dataset, runner, scorers y reporte, de modo que agregar un scorer nuevo no toque el runner.
-Limitar la concurrencia a N llamadas simultáneas y aplicar timeout por caso.
-Un caso que falla o da timeout se registra como fallo, no aborta la corrida.
-Calcular percentiles de latencia correctamente sobre los casos completados.
-Producir un reporte legible en consola o JSON que destaque regresiones por caso.
-Hacer la corrida reproducible: guardar versión del prompt, modelo y parámetros junto con los resultados.

# si te sobra tiempo, te van a preguntar

-¿Cómo evaluarías salidas abiertas donde no hay un expected exacto? ¿Qué riesgos tiene usar un LLM como juez?
-Con 20 casos, ¿cuándo una diferencia de accuracy es ruido? ¿Cómo lo decidirías?
-¿Cómo integrarías esto en CI para bloquear un cambio de prompt que empeora la calidad?
-¿Cómo armarías y mantendrías el dataset a partir de tráfico real?

02Cliente de LLM con fallback y circuit breakerQue diseñes integraciones con proveedores externos pensando en resiliencia, testeabilidad y comportamiento bajo falla.60 min

Tu producto llama a dos proveedores de LLM. Cada uno se expone como provider.complete(request): Promise<Response> y puede fallar con { status: 429, retryAfterMs }, { status: 500 } o un timeout. Te dan mocks configurables para simular cada falla.

Implementá LlmClient.complete(request) que use el proveedor primario, reintente con backoff exponencial y jitter los errores transitorios, respete retryAfterMs en los 429, caiga al proveedor secundario cuando el primario no responde y abra un circuit breaker por proveedor tras 5 fallas consecutivas, que se mantenga abierto 30 segundos antes de probar con una sola request (half-open).

# requisitos

-Distinguir errores reintentables (429, 5xx, timeout) de los que no lo son (400, errores de validación).
-Implementar el circuit breaker como una máquina de estados explícita: closed, open y half-open.
-Inyectar el reloj y el random para poder testear backoff y breaker sin esperas reales.
-Respetar un deadline total por request, sumando reintentos y fallback.
-Exponer métricas: intentos, fallbacks y estado del breaker por proveedor.

# si te sobra tiempo, te van a preguntar

-¿Qué problemas trae hacer fallback a un modelo distinto en cuanto a formato y calidad de salida?
-¿Cómo evitarías que muchos procesos reintenten a la vez y empeoren un rate limit (thundering herd)?
-¿Reintentarías una request con streaming que ya emitió tokens al usuario?

03Cache semántico de respuestasQue combines estructuras de datos clásicas con conceptos de IA y analices con criterio los trade-offs de corrección contra costo.60 min

Para bajar costos, querés reutilizar respuestas de preguntas muy parecidas. Tenés un mock embed(text): number[] y un mock model(question): Promise<string>. Diseñá e implementá SemanticCache con get(question) y set(question, answer), y una función answer(question) que consulte el cache antes de llamar al modelo.

Una entrada se considera hit si la similitud coseno entre embeddings es mayor o igual a un umbral configurable (por ejemplo 0.92). El cache tiene capacidad máxima con política LRU y un TTL por entrada. Ejemplo: si se guardó "¿Cuál es el horario de atención?", la pregunta "¿En qué horario atienden?" debería ser hit, pero "¿Cuál es el horario de envíos?" no.

# requisitos

-Implementar LRU con operaciones de actualización en O(1), más el costo de la búsqueda por similitud.
-Expirar entradas por TTL usando un reloj inyectable.
-Normalizar la pregunta (mayúsculas, espacios) antes de calcular el embedding y probar primero un match exacto.
-Evitar llamadas duplicadas al modelo cuando llegan en paralelo dos preguntas equivalentes (request coalescing).
-Exponer hit rate y permitir invalidar todas las entradas de un tema o una versión de prompt.

# si te sobra tiempo, te van a preguntar

-¿Qué riesgos tiene un falso positivo en el cache y cómo elegirías el umbral con datos?
-¿Cómo manejarías respuestas que dependen del usuario o de datos que cambian?
-¿Qué estructura usarías si el cache tuviera millones de entradas?

# leetcode recomendado (AI engineering · Senior)

MediumTop K Frequent WordsSuma al top-k el desempate determinístico, un detalle clave cuando los rankings tienen que ser reproducibles.

MediumLRU CacheDiseño de una estructura con operaciones en O(1), la base de cualquier cache de respuestas o embeddings.

MediumDesign Add and Search Words Data StructureCombina trie y backtracking para búsquedas con comodines, típico en matching de patrones sobre texto.

MediumInsert IntervalExige manejar todos los casos de borde de intervalos, como al actualizar anotaciones sobre un documento.

MediumLongest Substring Without Repeating CharactersEs el sliding window canónico, el mismo patrón que usás para recorrer ventanas de tokens.

MediumWord BreakProgramación dinámica sobre segmentación de texto, muy cercana a cómo funciona la tokenización por subpalabras.

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)

01Eval harness para comparar dos promptsQue trates los cambios de prompt como cambios de código que se miden, y que sepas diseñar infraestructura de evaluación extensible.60 min

# requisitos

-Separar con claridad dataset, runner, scorers y reporte, de modo que agregar un scorer nuevo no toque el runner.
-Limitar la concurrencia a N llamadas simultáneas y aplicar timeout por caso.
-Un caso que falla o da timeout se registra como fallo, no aborta la corrida.
-Calcular percentiles de latencia correctamente sobre los casos completados.
-Producir un reporte legible en consola o JSON que destaque regresiones por caso.
-Hacer la corrida reproducible: guardar versión del prompt, modelo y parámetros junto con los resultados.

# si te sobra tiempo, te van a preguntar

-¿Cómo evaluarías salidas abiertas donde no hay un expected exacto? ¿Qué riesgos tiene usar un LLM como juez?
-Con 20 casos, ¿cuándo una diferencia de accuracy es ruido? ¿Cómo lo decidirías?
-¿Cómo integrarías esto en CI para bloquear un cambio de prompt que empeora la calidad?
-¿Cómo armarías y mantendrías el dataset a partir de tráfico real?

02Cliente de LLM con fallback y circuit breakerQue diseñes integraciones con proveedores externos pensando en resiliencia, testeabilidad y comportamiento bajo falla.60 min

# requisitos

-Distinguir errores reintentables (429, 5xx, timeout) de los que no lo son (400, errores de validación).
-Implementar el circuit breaker como una máquina de estados explícita: closed, open y half-open.
-Inyectar el reloj y el random para poder testear backoff y breaker sin esperas reales.
-Respetar un deadline total por request, sumando reintentos y fallback.
-Exponer métricas: intentos, fallbacks y estado del breaker por proveedor.

# si te sobra tiempo, te van a preguntar

-¿Qué problemas trae hacer fallback a un modelo distinto en cuanto a formato y calidad de salida?
-¿Cómo evitarías que muchos procesos reintenten a la vez y empeoren un rate limit (thundering herd)?
-¿Reintentarías una request con streaming que ya emitió tokens al usuario?

03Cache semántico de respuestasQue combines estructuras de datos clásicas con conceptos de IA y analices con criterio los trade-offs de corrección contra costo.60 min

# requisitos

-Implementar LRU con operaciones de actualización en O(1), más el costo de la búsqueda por similitud.
-Expirar entradas por TTL usando un reloj inyectable.
-Normalizar la pregunta (mayúsculas, espacios) antes de calcular el embedding y probar primero un match exacto.
-Evitar llamadas duplicadas al modelo cuando llegan en paralelo dos preguntas equivalentes (request coalescing).
-Exponer hit rate y permitir invalidar todas las entradas de un tema o una versión de prompt.

# si te sobra tiempo, te van a preguntar

-¿Qué riesgos tiene un falso positivo en el cache y cómo elegirías el umbral con datos?
-¿Cómo manejarías respuestas que dependen del usuario o de datos que cambian?
-¿Qué estructura usarías si el cache tuviera millones de entradas?

# leetcode recomendado (AI engineering · Senior)

MediumTop K Frequent WordsSuma al top-k el desempate determinístico, un detalle clave cuando los rankings tienen que ser reproducibles.

MediumLRU CacheDiseño de una estructura con operaciones en O(1), la base de cualquier cache de respuestas o embeddings.

MediumDesign Add and Search Words Data StructureCombina trie y backtracking para búsquedas con comodines, típico en matching de patrones sobre texto.

MediumInsert IntervalExige manejar todos los casos de borde de intervalos, como al actualizar anotaciones sobre un documento.

MediumLongest Substring Without Repeating CharactersEs el sliding window canónico, el mismo patrón que usás para recorrer ventanas de tokens.

MediumWord BreakProgramación dinámica sobre segmentación de texto, muy cercana a cómo funciona la tokenización por subpalabras.