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

01Cola de acciones offlineQue diseñes soluciones offline robustas, razonando sobre consistencia, idempotencia y ciclo de vida de la app en mobile.60 min

En una app de pedidos para vendedores en la calle, la conexión se corta todo el tiempo. Diseñá e implementá una cola que guarda las acciones del usuario (createOrder, updateOrder, cancelOrder) cuando no hay conexión y las envía en orden cuando vuelve.

Usá @react-native-community/netinfo para detectar la conexión (podés mockearlo) y una API mockeada que falla un 20% de las veces. La UI muestra cada pedido con su estado: sincronizado, pendiente o con error.

# requisitos

-La cola se persiste y sobrevive a que el sistema mate la app.
-Las acciones se envían en orden y una que falla no se saltea en silencio.
-Cada acción lleva una clave de idempotencia para que un reintento no duplique pedidos.
-Las acciones sobre pedidos creados offline usan un id local que se reemplaza por el del servidor.
-Los reintentos usan backoff y hay un máximo; después se marca el error para que el usuario decida.
-La UI se actualiza de forma optimista.

# si te sobra tiempo, te van a preguntar

-¿Qué hacés si el servidor rechaza una acción del medio de la cola por un conflicto?
-¿Cómo sincronizarías en background con la app cerrada en iOS y en Android?
-¿Cómo testearías los escenarios de red intermitente?
-¿Cómo evitarías que dos procesos procesen la cola a la vez?

02Galería de 5.000 fotosQue puedas diagnosticar y resolver problemas de performance y memoria reales en React Native, conociendo los límites entre JS y nativo.60 min

Tenés que mostrar una galería en grilla de 3 columnas con 5.000 fotos { id: string, thumbUrl: string, fullUrl: string, width: number, height: number }. Al tocar una foto se abre en pantalla completa con swipe horizontal para pasar a la siguiente y pinch to zoom.

Hoy la versión existente usa ScrollView con map, tarda 4 segundos en abrir y se cierra por memoria en Android. Reescribila para que abra al instante y scrollee fluido.

# requisitos

-Grilla virtualizada (FlatList con numColumns y getItemLayout, o FlashList con estimatedItemSize).
-Las miniaturas usan una librería con cache de imágenes (por ejemplo expo-image) y tamaño acotado.
-El visor a pantalla completa también se virtualiza y abre directamente en la foto tocada.
-Los gestos y animaciones corren en el UI thread (Reanimated y Gesture Handler).
-Explicá cómo verificarías la mejora con herramientas de profiling.

# si te sobra tiempo, te van a preguntar

-¿Cómo implementarías una transición compartida de la miniatura al visor?
-¿Qué cambia con la New Architecture para este tipo de pantalla?
-¿Cómo manejarías la selección múltiple para compartir fotos?
-¿Cómo detectarías leaks de memoria?

03Cache LRU con TTLQue diseñes una utilidad de bajo nivel correcta y testeable, con buen uso de estructuras de datos y promesas en TypeScript.45 min

Implementá en TypeScript createCache<K, V>({ max, ttlMs }), que devuelve un objeto con get(key), set(key, value), has(key), delete(key) y size. Cuando se supera max se desaloja la entrada usada hace más tiempo, y una entrada vencida se comporta como si no existiera.

Después, usalo para envolver una función async: cachedFetch = withCache(fetchUser, { max: 100, ttlMs: 60_000 }), donde dos llamadas simultáneas con el mismo id comparten la misma promesa.

# requisitos

-get y set son O(1), aprovechando el orden de inserción de Map.
-Las entradas vencidas se limpian de forma perezosa al leerlas, sin timers por entrada.
-Si la promesa cacheada rechaza, se saca del cache para no guardar errores.
-El tiempo se inyecta (por ejemplo now = Date.now) para poder testear sin esperar.
-Los tipos genéricos se preservan en withCache.

# si te sobra tiempo, te van a preguntar

-¿Cómo agregarías stale-while-revalidate?
-¿Cómo persistirías el cache entre sesiones de la app?
-¿Qué cambiaría si el cache tuviera que ser compartido entre JS y código nativo?

# leetcode recomendado (Frontend · React Native · Senior)

MediumPromise Time LimitDel plan 30 Days of JavaScript: ponerle timeout a una promesa, crítico en apps con redes inestables.

MediumExecute Asynchronous Functions in ParallelDel plan 30 Days of JavaScript: implementar Promise.all a mano, una pregunta asíncrona clásica de nivel senior.

MediumJoin Two Arrays by IDDel plan 30 Days of JavaScript: mergear datos locales con datos del servidor por id, como en una sincronización offline.

MediumEvent EmitterDel plan 30 Days of JavaScript: el patrón pub/sub que usan los módulos nativos para mandar eventos a JS.

MediumLRU CacheDiseño de estructura con Map en O(1); muy frecuente en senior y directamente aplicable a caches de imágenes y datos.

HardSliding Window MaximumDeque monotónica sobre una ventana; mide si podés llevar un patrón conocido a su versión exigente.

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)

01Cola de acciones offlineQue diseñes soluciones offline robustas, razonando sobre consistencia, idempotencia y ciclo de vida de la app en mobile.60 min

# requisitos

-La cola se persiste y sobrevive a que el sistema mate la app.
-Las acciones se envían en orden y una que falla no se saltea en silencio.
-Cada acción lleva una clave de idempotencia para que un reintento no duplique pedidos.
-Las acciones sobre pedidos creados offline usan un id local que se reemplaza por el del servidor.
-Los reintentos usan backoff y hay un máximo; después se marca el error para que el usuario decida.
-La UI se actualiza de forma optimista.

# si te sobra tiempo, te van a preguntar

-¿Qué hacés si el servidor rechaza una acción del medio de la cola por un conflicto?
-¿Cómo sincronizarías en background con la app cerrada en iOS y en Android?
-¿Cómo testearías los escenarios de red intermitente?
-¿Cómo evitarías que dos procesos procesen la cola a la vez?

02Galería de 5.000 fotosQue puedas diagnosticar y resolver problemas de performance y memoria reales en React Native, conociendo los límites entre JS y nativo.60 min

Hoy la versión existente usa ScrollView con map, tarda 4 segundos en abrir y se cierra por memoria en Android. Reescribila para que abra al instante y scrollee fluido.

# requisitos

-Grilla virtualizada (FlatList con numColumns y getItemLayout, o FlashList con estimatedItemSize).
-Las miniaturas usan una librería con cache de imágenes (por ejemplo expo-image) y tamaño acotado.
-El visor a pantalla completa también se virtualiza y abre directamente en la foto tocada.
-Los gestos y animaciones corren en el UI thread (Reanimated y Gesture Handler).
-Explicá cómo verificarías la mejora con herramientas de profiling.

# si te sobra tiempo, te van a preguntar

-¿Cómo implementarías una transición compartida de la miniatura al visor?
-¿Qué cambia con la New Architecture para este tipo de pantalla?
-¿Cómo manejarías la selección múltiple para compartir fotos?
-¿Cómo detectarías leaks de memoria?

03Cache LRU con TTLQue diseñes una utilidad de bajo nivel correcta y testeable, con buen uso de estructuras de datos y promesas en TypeScript.45 min

Después, usalo para envolver una función async: cachedFetch = withCache(fetchUser, { max: 100, ttlMs: 60_000 }), donde dos llamadas simultáneas con el mismo id comparten la misma promesa.

# requisitos

-get y set son O(1), aprovechando el orden de inserción de Map.
-Las entradas vencidas se limpian de forma perezosa al leerlas, sin timers por entrada.
-Si la promesa cacheada rechaza, se saca del cache para no guardar errores.
-El tiempo se inyecta (por ejemplo now = Date.now) para poder testear sin esperar.
-Los tipos genéricos se preservan en withCache.

# si te sobra tiempo, te van a preguntar

-¿Cómo agregarías stale-while-revalidate?
-¿Cómo persistirías el cache entre sesiones de la app?
-¿Qué cambiaría si el cache tuviera que ser compartido entre JS y código nativo?

# leetcode recomendado (Frontend · React Native · Senior)

MediumPromise Time LimitDel plan 30 Days of JavaScript: ponerle timeout a una promesa, crítico en apps con redes inestables.

MediumExecute Asynchronous Functions in ParallelDel plan 30 Days of JavaScript: implementar Promise.all a mano, una pregunta asíncrona clásica de nivel senior.

MediumJoin Two Arrays by IDDel plan 30 Days of JavaScript: mergear datos locales con datos del servidor por id, como en una sincronización offline.

MediumEvent EmitterDel plan 30 Days of JavaScript: el patrón pub/sub que usan los módulos nativos para mandar eventos a JS.

MediumLRU CacheDiseño de estructura con Map en O(1); muy frecuente en senior y directamente aplicable a caches de imágenes y datos.

HardSliding Window MaximumDeque monotónica sobre una ventana; mide si podés llevar un patrón conocido a su versión exigente.