Entrevistas de Android focam nos idioms do Kotlin, nas coroutines e no ciclo de vida da plataforma — a maioria das perguntas de nível sênior está, na verdade, testando se você entende que o seu processo pode ser encerrado a qualquer momento. Abaixo estão as perguntas mais feitas, cada uma com uma resposta modelo. Senior: arquitetura, trade-offs, mentoria e tomada de decisão.
Pela fronteira que muda junto, e pelo tempo de build. Um módulo de feature que pode ser construído e testado sem o resto se paga em velocidade de compilação e em deixar explícita a direção das dependências. Dividir por camada — um módulo com todas as view models — geralmente produz módulos que sempre mudam juntos, ou seja, o custo sem o benefício.
Faça do banco local a fonte da verdade e da rede um sincronizador, para que a UI nunca espere por conectividade. Depois a parte difícil são os conflitos e a ordem: uma fila de operações pendentes que sobrevive a um restart, requisições idempotentes para que um retry seja seguro, e uma regra explícita para quem ganha quando os dois lados mudaram. Adicionar isso depois significa reescrever a camada de dados.
Comece pelo agrupamento dos crashes — quais dispositivos e quais telas, já que dispositivos com pouca memória revelam o que os outros toleram. Bitmaps costumam ser a resposta: uma imagem em resolução total decodificada só para virar uma miniatura custa megabytes cada. O LeakCanary em um build de debug nomeia os objetos retidos, e o memory profiler mostra se o heap cresce e nunca volta.
WorkManager, porque ele persiste a requisição e respeita as restrições impostas pelo sistema — rede, carregamento, Doze. Uma coroutine em um scope morre junto com o processo, e um alarme não é um scheduler. O próprio trabalho precisa ser idempotente, já que o sistema vai tentar de novo, e uma tarefa que não é pode rodar duas vezes.
De forma incremental, nos dois sentidos: Compose dentro de um fragment, um ComposeView em um layout existente, e a interoperabilidade que permite converter uma tela de cada vez. Converta uma tela quando ela já precisa de trabalho de qualquer forma, em vez de tratar isso como um projeto à parte, porque uma reescrita sem mudança de produto é a primeira coisa cortada quando as prioridades mudam.
Lógica de negócio e redução de estado como testes unitários simples — rodam em segundos e são os que pegam defeitos de verdade. Comportamento de repositório e banco de dados com um banco em memória, já que as suposições do ORM são exatamente o que mocks escondem. Depois um punhado de testes de instrumentação sobre os fluxos que nunca podem quebrar, aceitando que são lentos o bastante para que uma suíte grande deles pare de ser rodada.
Numa entrevista de verdade você fala sob pressão. O Cam faz essas mesmas perguntas, avalia cada resposta e mostra exatamente o que melhorar.
Praticar entrevista de Senior Android (Kotlin) →