Las entrevistas de Android se enfocan en idioms de Kotlin, coroutines, y el ciclo de vida de la plataforma — la mayoría de las preguntas senior en realidad preguntan si entiendes que tu proceso puede morir en cualquier momento. Aquí están las preguntas hechas más a menudo, cada una con una respuesta modelo. Senior: arquitectura, trade-offs, mentoría y toma de decisiones.
Por el límite que cambia junto y por tiempo de build. Un módulo de feature que se puede construir y testear sin el resto se paga a sí mismo en velocidad de compilación y en hacer explícita la dirección de dependencia. Dividir por capa — un módulo de todos los view models — usualmente produce módulos que siempre cambian juntos, que es el costo sin el beneficio.
Haz que la base de datos local sea la fuente de verdad y la red un sincronizador, así la UI nunca espera por conectividad. Luego la parte difícil son los conflictos y el ordenamiento: una cola de operaciones pendientes que sobrevive un reinicio, requests idempotentes para que un reintento sea seguro, y una regla explícita para qué gana cuando ambos lados cambiaron. Agregar esto después significa reescribir la capa de datos.
Empieza con la agrupación del crash — qué dispositivos y qué pantallas, ya que los dispositivos con poca memoria revelan lo que otros toleran. Los bitmaps son la respuesta usual: una imagen de resolución completa decodificada para un thumbnail cuesta megabytes cada una. LeakCanary en un build de debug nombra los objetos retenidos, y el memory profiler muestra si el heap crece y nunca vuelve.
WorkManager, porque persiste el request y honra las restricciones que el sistema impone — red, carga, Doze. Una coroutine en un scope muere con el proceso, y una alarma no es un scheduler. El trabajo en sí tiene que ser idempotente, ya que el sistema lo va a reintentar, y una tarea que no lo sea puede correr dos veces.
Incrementalmente, en ambas direcciones: Compose dentro de un fragment, un ComposeView en un layout existente, y la interoperabilidad que deja convertir una pantalla a la vez. Convierte una pantalla cuando de todas formas necesita trabajo en vez de como un proyecto, porque una reescritura sin cambio de producto es lo primero que se corta cuando cambian las prioridades.
Lógica de negocio y reducción de estado como unit tests planos — corren en segundos y son los que atrapan defectos reales. Comportamiento de repositorio y base de datos con una base de datos en memoria, ya que las suposiciones del ORM son exactamente lo que los mocks esconden. Luego un puñado de tests de instrumentación sobre los flujos que nunca deben romperse, aceptando que son lo bastante lentos como para que una suite grande de ellos deje de correrse.
En una entrevista real hablas bajo presión. Cam hace estas mismas preguntas, evalúa cada respuesta y muestra exactamente qué mejorar.
Practicar entrevista de Senior Android (Kotlin) →