Perguntas de Entrevista para Programador Mobile

Resposta-modelo

Depende da equipa e do produto. Escolho React Native quando já existe experiência em JavaScript ou TypeScript e é preciso reaproveitar programadores web, ou quando o ecossistema de bibliotecas JavaScript representa uma vantagem. Prefiro Flutter quando o desempenho da interface e a consistência visual entre plataformas são prioritárias, porque desenha os seus próprios componentes e reduz as diferenças entre iOS e Android. Em ambos os casos, avalio a maturidade das bibliotecas de que preciso antes de decidir.

Resposta-modelo

A base de código partilhada acelera a entrega e reduz o custo de manutenção, mas nem sempre iguala o desempenho e o acesso imediato às APIs mais recentes de cada plataforma. Na prática, adoto uma abordagem híbrida: mantenho a maior parte da aplicação em React Native ou Flutter e desço ao nativo — Kotlin no Android, Swift no iOS — nos pontos críticos, como animações complexas, processamento de vídeo ou integrações com hardware específico.

Resposta-modelo

Começo por medir com ferramentas de profiling antes de otimizar às cegas. Reduzo o número de re-renderizações, uso listas com carregamento preguiçoso, comprimo imagens e evito bloquear a thread principal. Vigio o tamanho do pacote e o tempo de arranque a frio, porque em dispositivos modestos são os fatores que mais afetam a retenção. Testo sempre num aparelho físico antigo, não apenas no emulador.

Resposta-modelo

No Android, giro as assinaturas da aplicação, preparo os ficheiros de release e uso lançamentos faseados na Play Console para detetar problemas antes de chegarem a todos os utilizadores. No iOS, trabalho com certificados e perfis no App Store Connect, submeto builds através do TestFlight para testes internos e preparo a aplicação para a revisão da Apple, cujos critérios acompanho de perto. Automatizo grande parte deste fluxo com Fastlane para reduzir erros manuais.

Resposta-modelo

Escolho a solução conforme a complexidade. Para estado local simples, uso as ferramentas nativas da framework; para estado partilhado, recorro a Redux ou Zustand em React Native, ou a Bloc e Riverpod em Flutter. O princípio é manter o estado previsível e testável, evitando lógica dispersa pelos componentes de interface.

Resposta-modelo

Defino as versões mínimas suportadas com base nos dados reais dos utilizadores, não por hábito. Uso deteção de capacidades em vez de assumir comportamentos por versão, testo numa matriz de dispositivos representativa e apoio-me em serviços de teste em dispositivos reais na nuvem quando não tenho o equipamento. Monitorizo as falhas por versão e por modelo com Crashlytics para priorizar correções.

Adio a inicialização dos módulos que não são necessários no primeiro ecrã, minimizo o trabalho na thread principal durante o arranque, uso carregamento preguiçoso de recursos e reduzo o tamanho do pacote. Meço com as ferramentas de profiling da plataforma antes e depois de cada alteração para confirmar o ganho.

Isolo a camada de rede numa camada de serviços, com tratamento centralizado de erros, tempos limite e novas tentativas. Faço cache das respostas quando faz sentido, trato o estado offline e serializo os dados em modelos tipados. Em projetos com necessidades de dados mais complexas, pondero GraphQL para reduzir o excesso de pedidos.

Combino testes unitários para a lógica de negócio, testes de widget ou de componente para a interface e alguns testes de ponta a ponta para os fluxos críticos, como o registo e o pagamento. Integro-os no pipeline de CI/CD para que corram a cada alteração, evitando regressões antes da publicação.

Recolho apenas os dados necessários, peço consentimento explícito, cifro o armazenamento local sensível e uso comunicação segura com o servidor. Documento as finalidades do tratamento e garanto mecanismos de eliminação de conta e de dados, em linha com o RGPD e as orientações da CNPD.

Leio com atenção o motivo da rejeição, que a Apple costuma associar a uma diretriz específica. Corrijo o problema, documento a alteração e respondo no App Store Connect a explicar o que foi ajustado. Se o prazo estiver em risco, comunico de imediato à equipa de produto e proponho um plano alternativo, como submeter primeiro uma correção mínima.

Consulto os relatórios de falhas no Crashlytics filtrados por modelo e por versão do sistema, tento reproduzir num equipamento igual ou num serviço de dispositivos reais na nuvem e isolo a causa. Depois de corrigir, lanço uma versão faseada para confirmar a solução antes de a disponibilizar a todos.

Apresento os dados: quantos utilizadores usam esses dispositivos e qual o impacto medido. Proponho alternativas, como uma versão mais leve da funcionalidade ou a sua ativação apenas em equipamentos capazes. O objetivo é decidir com base em factos e não sacrificar uma parte relevante da base de utilizadores.

Estabilizo primeiro o que falha com mais frequência, apoiado nos relatórios de falhas. Introduzo testes nos fluxos críticos antes de refatorar, para não criar regressões, e negoceio com a equipa de produto um plano incremental que concilie novas funcionalidades com a redução gradual da dívida técnica.