Mock interview de Android developer — práctica con IA

Las entrevistas de Android sondean dos cosas: cuánta fluidez tiene usted en Kotlin y cuánto ha peleado realmente contra el lifecycle. Los candidatos que consiguen ofertas conocen la diferencia entre un configuration change y una process death, saben argumentar a favor o en contra de Jetpack Compose con detalles concretos y no fingen que el stack de Activities es simple. Esta guía recorre cómo usar mock interviews con IA para ensayar el loop específico de Android, calibrado a los roles Kotlin-first de 2026.

Rondas típicas de una entrevista de Android developer

El loop de Android consta de 4–5 rondas. Screening del recruiter, una ronda de fundamentos de Kotlin (data classes, sealed classes, scope functions, generics, fundamentos de coroutines), una ronda de coding práctico (construir una pequeña feature en Compose o Views), una ronda de arquitectura («diseña la caché offline de esta feature») y una behavioral. Los loops senior añaden un deep-dive de la plataforma Android (process lifecycle, límites del trabajo en background, distribución en Play Store) y un architecture review de proyectos pasados.

La ronda de arquitectura y la de fundamentos de Kotlin mapean con limpieza al formato del mock con IA — son conversacionales. La ronda de coding rinde con un walkthrough verbal en el mock más práctica real en Android Studio en paralelo. Las rondas de pura implementación de UI son más difíciles de mockear; para esas, combine el mock con un takehome en un dispositivo o emulador real.

Principales temas técnicos

Fluidez en Kotlin

El entrevistador asume Kotlin, no Java. Esté listo: val vs var con los defaults correctos, data classes y qué equals/hashCode generan, sealed classes y when-expressions exhaustivas para modelar estado, scope functions (let, run, apply, also, with) y cuándo usar cuál, extension functions y sus reglas de dispatch, generics con varianza en el punto de declaración (in, out), inline y reified, el modelo de nullability de Kotlin y los platform types de la interop con Java. Una trampa común: explicar por qué un Java NPE aún puede ocurrir en un codebase Kotlin «seguro».

Coroutines y Flow

Requisito mínimo. Esté listo: structured concurrency (cancelación padre-hijo), CoroutineScope vs CoroutineContext, la diferencia entre launch y async, supervisorScope vs coroutineScope, manejo de excepciones (CoroutineExceptionHandler, try/catch alrededor de await), Flow vs StateFlow vs SharedFlow, hot vs cold streams, backpressure con Channels y los operadores buffer/conflate. Una pregunta favorita: «el usuario navega fuera a mitad del fetch — describe la forma correcta de cancelar y limpiar». Las respuestas fuertes encadenan lifecycle scopes (lifecycleScope, viewModelScope) y garantías de cancelación.

Jetpack Compose

Compose ha ganado para los proyectos nuevos, pero Views sigue vivo en el 70 % de los codebases en producción. Esté listo: el modelo de funciones @Composable y qué dispara realmente una recomposition, state hoisting y unidirectional data flow, remember vs rememberSaveable, LaunchedEffect vs DisposableEffect vs SideEffect, el orden de Modifier y por qué importa, las lazy lists (LazyColumn con keys para identidad estable), CompositionLocal para valores ambient, navegación (Navigation Compose vs Navigation Component para Views). Un prompt de debugging común: «la lazy list se recompone con demasiada agresividad — encuentra por qué».

Lifecycle, process y configuration changes

Aquí está el dolor con forma de Android. Esté listo: el Activity lifecycle (y por qué existe onSaveInstanceState), Fragments y el lifecycle doble, configuration changes vs process death (y por qué su estado en memoria desaparece en el segundo caso), el papel del ViewModel y qué sobrevive y qué no, los componentes lifecycle-aware, la diferencia entre ViewModels con scope de Activity y con scope de Fragment. Una trampa favorita: «el usuario rota el dispositivo tres veces durante una llamada de red — ¿qué debería ocurrir?».

Arquitectura y modularización

MVVM con un patrón Repository es la respuesta canónica; la pregunta es qué viene después. Esté listo: MVI para features muy basadas en máquinas de estado, Clean Architecture para separar el dominio del framework, modularización (feature modules vs layer modules, dynamic feature delivery), inyección de dependencias con Hilt o Koin, cómo es una arquitectura «single activity, multiple fragments» y cuándo romper esa regla. Esté listo para defender una elección en un codebase real.

Trabajo en background y restricciones de plataforma

Los loops senior profundizan en WorkManager (y las capas de JobScheduler/AlarmManager por debajo), Doze mode y App Standby, los cambios en los límites de ejecución en background desde O en adelante, foreground services y qué notificaciones requieren, push notifications vía Firebase Cloud Messaging, la distinción entre mensajes data-only y de notificación, y cómo manejar un process kill a mitad de un sync. Conocer esto separa a un senior de un mid.

Preguntas de escenario habituales

• «Diseña el sync offline de una app de notas. Room vs SQLite en crudo, resolución de conflictos, scheduling con WorkManager.»
• «Tu LazyColumn se recompone con demasiada frecuencia. Explícame el diagnóstico.» (Keys estables, estado inmutable, captura de lambdas.)
• «La app crashea en Samsung pero no en Pixel. ¿Cómo lo investigas?» (Modificaciones de OEM, permisos del manifest, killers de background de fabricante.)
• «Implementa descargas de imágenes en paralelo con un límite de concurrencia usando coroutines.»
• «El equipo quiere migrar de Views a Compose. ¿Roadmap?» (ComposeView en XML, ViewModels compartidos, rollout por pantalla, testing de regresión.)

Áreas de enfoque behavioral — qué buscan los hiring managers

Los hiring managers de Android filtran por tres rasgos. Primero, realismo de OEM — el mundo Android no es un único happy path con forma de Pixel. Los candidatos fuertes han entregado a Samsung, Xiaomi, Huawei y tienen anécdotas sobre bugs específicos de fabricante. Segundo, disciplina de Play Store — has gestionado un rechazo, un falso positivo de Play Protect, una regresión en un staged rollout. Tercero, conciencia sobre el tamaño de la app y la batería — los usuarios de Android son más sensibles al precio que los de iOS, y una app de 100 MB o un 4 % de drenaje de batería en background te cuesta instalaciones. Cuente con prompts que mapeen a uno de estos.

Cómo usar la práctica de mock con IA para este rol

Ponga el tipo de entrevista en «Tech Screening» y elija Android como plataforma. La IA pondera las preguntas hacia Kotlin, coroutines, Compose y lifecycle. Pegue la oferta cuando la tenga — los roles solo-Compose hacen preguntas muy distintas a las de codebases que aún usan Views.

Para practicar arquitectura, haga sesiones de «System Design» con prompts específicos de Android: app offline-first con sync de WorkManager, chat en tiempo real con Firebase, flujo de pago con autenticación biométrica, arquitectura de servicios multi-proceso. La IA presionará sobre las trampas del lifecycle que no existen en web.

Un drill que rinde: elige una feature de Compose que hayas entregado y pide a la IA que haga una entrevista de recomposition. «¿Qué dispara la recomposition aquí? ¿Qué pasa si cambio este estado? ¿Por qué esta captura de lambda provoca una recomposition?» El mock encontrará los huecos en tu modelo mental de Compose, que suelen ser exactamente los huecos que encuentran los entrevistadores.

Preguntas frecuentes