./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 [x]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 [ ]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)

01Repositorio offline-firstQue diseñes una capa de datos robusta para mobile, razonando sobre consistencia, fallas de red y procesos en background.60 min

Diseñá el repositorio de una lista de tareas que funciona sin conexión. La fuente de verdad es una base local (Room o un fake en memoria) y existe una API TasksApi con getTasks(), createTask() y updateTask().

La UI observa las tareas como Flow<List<Task>> y las ve al instante aunque no haya red. Las tareas creadas o editadas offline se marcan como pendientes de sync y se envían cuando vuelve la conexión.

# requisitos

-La UI solo lee de la base local; la red solo escribe en la base.
-Cada tarea tiene un estado de sync (sincronizada, pendiente, error) visible en la UI.
-La sincronización de pendientes se dispara con WorkManager cuando hay red y es idempotente.
-Definí una estrategia de conflictos (por ejemplo, last write wins por updatedAt) y explicala.
-Las tareas creadas offline tienen un id local y se reconcilian con el id del servidor.

# si te sobra tiempo, te van a preguntar

-¿Cómo manejarías un borrado offline de una tarea que otro dispositivo editó?
-¿Cómo testearías la sincronización de punta a punta?
-¿Qué pasa si la app se mata en medio de un sync?
-¿Cómo migrarías el esquema de la base sin perder pendientes?

02Map concurrente con límite de paralelismoQue domines coroutines avanzadas: structured concurrency, cancelación, primitivas de sincronización y testing de concurrencia.45 min

Implementá suspend fun <T, R> List<T>.mapConcurrently(limit: Int, transform: suspend (T) -> R): List<R>. Ejecuta transform sobre todos los elementos en paralelo, pero con como máximo limit corriendo al mismo tiempo, y devuelve los resultados en el orden original.

Caso de uso: subir 50 fotos a un servidor que no acepta más de 4 uploads simultáneos. Si una falla, el resto se cancela y el error se propaga al llamador.

# requisitos

-Respetá structured concurrency con coroutineScope.
-Limitá el paralelismo con Semaphore (o un pool de workers con Channel).
-Los resultados mantienen el orden de entrada.
-Si el llamador cancela, se cancelan todas las tareas en curso.
-Escribí un test que verifique que nunca hay más de limit tareas activas.

# si te sobra tiempo, te van a preguntar

-¿Cómo cambiarías el comportamiento para recolectar errores sin cancelar el resto?
-¿Qué diferencia hay entre coroutineScope y supervisorScope acá?
-¿Cómo reportarías el progreso a la UI?
-¿En qué dispatcher correrías el trabajo y por qué?

03Pantalla de chat performante en ComposeQue entiendas el modelo de recomposición y estabilidad de Compose y puedas construir una pantalla exigente sin problemas de performance.60 min

Armá la pantalla de una conversación de chat. Los mensajes llegan desde fun messages(chatId: String): Flow<List<Message>>, donde Message es data class Message(val id: String, val text: String, val fromMe: Boolean, val sentAt: Instant, val status: Status). El fake emite un mensaje nuevo cada 2 segundos y la conversación ya tiene 2.000 mensajes.

Los mensajes nuevos aparecen abajo. Si el usuario está leyendo más arriba, no se lo debe mover; en su lugar aparece un botón de nuevos mensajes. Abajo hay un input para enviar.

# requisitos

-LazyColumn con reverseLayout = true, keys estables y contentType por tipo de burbuja.
-Solo se hace auto-scroll si el usuario ya estaba al final de la lista.
-Separadores de fecha entre mensajes de días distintos sin recalcular toda la lista en cada recomposición.
-Los modelos de UI son estables o inmutables para que Compose pueda saltear recomposiciones.
-El input sube con el teclado usando imePadding.

# si te sobra tiempo, te van a preguntar

-¿Cómo detectarías y medirías recomposiciones innecesarias?
-¿Cómo implementarías la carga de mensajes viejos al scrollear hacia arriba?
-¿Qué te dan los Baseline Profiles en una pantalla como esta?
-¿Cómo mostrarías el envío optimista de un mensaje y su reintento si falla?

# leetcode recomendado (Frontend · Android · Senior)

MediumLRU CacheHash map más lista doblemente enlazada; aparece seguido porque Android usa LruCache para imágenes.

MediumTime Based Key-Value StoreDiseño de estructura con búsqueda binaria sobre timestamps, parecido a versionar datos para sync.

MediumInsert Delete GetRandom O(1)Combinar array y mapa para garantizar operaciones en O(1); prueba diseño fino de estructuras.

MediumClone GraphRecorrido de grafos con mapa de visitados, la misma idea que copiar estructuras con ciclos.

HardLFU CacheVersión exigente del LRU con frecuencias; mide si podés mantener varios invariantes a la vez.

HardTrapping Rain WaterDos punteros o prefijos máximos; un Hard clásico que aparece en entrevistas senior.

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)

01Repositorio offline-firstQue diseñes una capa de datos robusta para mobile, razonando sobre consistencia, fallas de red y procesos en background.60 min

# requisitos

-La UI solo lee de la base local; la red solo escribe en la base.
-Cada tarea tiene un estado de sync (sincronizada, pendiente, error) visible en la UI.
-La sincronización de pendientes se dispara con WorkManager cuando hay red y es idempotente.
-Definí una estrategia de conflictos (por ejemplo, last write wins por updatedAt) y explicala.
-Las tareas creadas offline tienen un id local y se reconcilian con el id del servidor.

# si te sobra tiempo, te van a preguntar

-¿Cómo manejarías un borrado offline de una tarea que otro dispositivo editó?
-¿Cómo testearías la sincronización de punta a punta?
-¿Qué pasa si la app se mata en medio de un sync?
-¿Cómo migrarías el esquema de la base sin perder pendientes?

02Map concurrente con límite de paralelismoQue domines coroutines avanzadas: structured concurrency, cancelación, primitivas de sincronización y testing de concurrencia.45 min

Caso de uso: subir 50 fotos a un servidor que no acepta más de 4 uploads simultáneos. Si una falla, el resto se cancela y el error se propaga al llamador.

# requisitos

-Respetá structured concurrency con coroutineScope.
-Limitá el paralelismo con Semaphore (o un pool de workers con Channel).
-Los resultados mantienen el orden de entrada.
-Si el llamador cancela, se cancelan todas las tareas en curso.
-Escribí un test que verifique que nunca hay más de limit tareas activas.

# si te sobra tiempo, te van a preguntar

-¿Cómo cambiarías el comportamiento para recolectar errores sin cancelar el resto?
-¿Qué diferencia hay entre coroutineScope y supervisorScope acá?
-¿Cómo reportarías el progreso a la UI?
-¿En qué dispatcher correrías el trabajo y por qué?

03Pantalla de chat performante en ComposeQue entiendas el modelo de recomposición y estabilidad de Compose y puedas construir una pantalla exigente sin problemas de performance.60 min

Los mensajes nuevos aparecen abajo. Si el usuario está leyendo más arriba, no se lo debe mover; en su lugar aparece un botón de nuevos mensajes. Abajo hay un input para enviar.

# requisitos

-LazyColumn con reverseLayout = true, keys estables y contentType por tipo de burbuja.
-Solo se hace auto-scroll si el usuario ya estaba al final de la lista.
-Separadores de fecha entre mensajes de días distintos sin recalcular toda la lista en cada recomposición.
-Los modelos de UI son estables o inmutables para que Compose pueda saltear recomposiciones.
-El input sube con el teclado usando imePadding.

# si te sobra tiempo, te van a preguntar

-¿Cómo detectarías y medirías recomposiciones innecesarias?
-¿Cómo implementarías la carga de mensajes viejos al scrollear hacia arriba?
-¿Qué te dan los Baseline Profiles en una pantalla como esta?
-¿Cómo mostrarías el envío optimista de un mensaje y su reintento si falla?

# leetcode recomendado (Frontend · Android · Senior)

MediumLRU CacheHash map más lista doblemente enlazada; aparece seguido porque Android usa LruCache para imágenes.

MediumTime Based Key-Value StoreDiseño de estructura con búsqueda binaria sobre timestamps, parecido a versionar datos para sync.

MediumInsert Delete GetRandom O(1)Combinar array y mapa para garantizar operaciones en O(1); prueba diseño fino de estructuras.

MediumClone GraphRecorrido de grafos con mapa de visitados, la misma idea que copiar estructuras con ciclos.

HardLFU CacheVersión exigente del LRU con frecuencias; mide si podés mantener varios invariantes a la vez.

HardTrapping Rain WaterDos punteros o prefijos máximos; un Hard clásico que aparece en entrevistas senior.