Currículo de Desenvolvedor Mobile: Plataforma, Loja e Resultado

Um currículo de desenvolvedor mobile que lista Kotlin, Swift e React Native sem dizer em quais apps trabalhou deixa a vaga com a mesma dúvida de antes, que é saber se o candidato programou ou só estudou. O recrutador de mobile procura a plataforma, a linguagem e a loja onde o app foi publicado, e a leitura automática procura os mesmos nomes. Para o currículo de desenvolvedor mobile, a regra é ligar cada tecnologia a um app real, com número de usuário, de crash ou de release. Este guia mostra a ordem do texto, os termos e antes e depois.

A vaga pode estar em Android, em iOS ou em multiplataforma com React Native ou Flutter. Cada uma exige uma leitura diferente do mesmo trabalho, e o currículo precisa dizer qual delas é a sua, logo no início, antes que o leitor tenha que deduzir.

Qual plataforma deve aparecer primeiro no currículo?

A plataforma aparece antes da linguagem, porque é ela que decide a vaga. Um desenvolvedor Android com Kotlin não é lido como desenvolvedor iOS só por ter escrito algumas telas em Swift. Se você trabalhou nas duas, a primeira linha deve dizer as duas. Se trabalhou em uma e usou multiplataforma na outra, a ordem deve refletir o tempo de cada uma.

Antes: Desenvolvedor mobile com experiência em Kotlin, Swift e React Native.

Depois: Desenvolvedor mobile Android e iOS, com dois apps nativos em Kotlin e Swift e um módulo compartilhado em React Native.

O segundo texto diz onde você trabalhou e com que tipo de código. Se a vaga é de uma plataforma de tecnologia que tem formato próprio de candidatura, leia a comparação em Gupy vs Revelo: qual currículo de tecnologia usar antes de decidir a ordem das seções. Os termos de plataforma da área estão em palavras-chave para desenvolvedor mobile, e um currículo pronto da função, para comparar a estrutura, está em o exemplo de desenvolvedor mobile.

Como ligar cada linguagem a um app que você publicou?

Uma linguagem sozinha numa lista não prova que você a usou em produção. O que prova é a frase que liga a linguagem a um app, a uma função e a um resultado. Você não precisa de um app grande para isso. Precisa de um app em que a linguagem foi usada para algo que existe e funciona.

Antes: Programei em Kotlin e Swift em projetos de aplicativos.

Depois: Programei em Kotlin o módulo de login de um app de agendamento com 30 mil usuários ativos por mês, publicado na Google Play.

A segunda frase tem linguagem, módulo, tamanho de uso e loja. A primeira tem só a linguagem e a palavra projetos, que serve para qualquer pessoa que tenha passado por um curso. O leitor não precisa acreditar em você quando vê o módulo e o número.

Onde o app está publicado, e como escrever isso?

Para publicar um app Android, o desenvolvedor usa o Google Play Console. Para iOS, usa o App Store Connect da Apple. Esses dois painéis são o lugar onde a publicação, as versões e a revisão da loja acontecem. Quando o currículo cita a loja e o painel, ele mostra que você conhece o caminho do código até o usuário, e não só a parte de desenvolver a tela.

Escreva a loja e o processo na mesma linha, sem separar em duas listas. A linha abaixo mostra como fica quando há mais de um app e mais de uma loja.

Antes: Experiência com publicação de aplicativos nas lojas.

Depois: Publiquei três apps na Google Play e na App Store, com oito releases por ano, enviadas pelo Google Play Console e pelo App Store Connect.

Se você não publicou em uma das lojas, não escreva a outra como se tivesse feito. A vaga que pede publicação na App Store pergunta sobre a revisão da Apple, e quem nunca passou por ela não consegue responder com detalhe.

Firebase, API REST e CI/CD: o que escrever de cada um?

Essas três ferramentas aparecem em quase toda vaga de mobile, e cada uma se escreve de um jeito diferente. O que vale é dizer para que você as usou no app, e não apenas que as conhece.

• Firebase, para monitorar falhas, enviar notificações ou medir uso. Diga qual dessas funções você usou, porque o nome do produto não indica o que o app fazia com ele.
• API REST, para integrar o app com um serviço. Escreva quantos endpoints você consumiu e se havia cache offline, porque é o que diferencia uma integração simples de uma integração que aguenta uma rede ruim.
• CI/CD, para o pipeline que compila, testa e envia a versão. Diga o que o pipeline faz, por exemplo rodar testes a cada alteração, e quantas versões ele entregou, porque “CI/CD” sem detalhe é um termo que todo mundo copia.

Se você programa em React Native a partir de JavaScript e TypeScript, a lógica de escrever o que fez também vale para a parte web, como mostra o currículo de desenvolvedor front-end, que trata de como o JavaScript precisa aparecer ligado a um produto.

Quais medidas de qualidade o mobile precisa mostrar?

O trabalho de mobile é medido por falha, por avaliação de loja e pelo ritmo de entrega. Se você acompanhou alguma dessas medidas, escreva o número. Se não acompanhou, diga qual medida existia no time e o que você fez para melhorá-la.

Antes: Preocupado com qualidade e performance dos aplicativos.

Depois: Reduzi em 22% a taxa de falhas de um app com 60 mil usuários ativos, medida no painel de falhas, com correções em Swift e revisão de código antes de cada versão.

A cobertura de testes também conta, desde que você diga o que foi testado. “85% de cobertura” sem a parte do código coberta não diz nada. Se a cobertura foi calculada pela ferramenta do projeto, escreva a ferramenta e o escopo, para que a entrevista não encontre um número que ninguém sabe explicar.

E se você está começando na área mobile?

Um app publicado na loja, mesmo sem muitos usuários, é a prova mais forte que um iniciante tem. Ele mostra que você passou por todo o ciclo, da tela ao envio, e que entendeu a revisão da loja. Escreva o nome do app, a loja em que ele está, a stack e o que você resolveu nele, em uma seção de projetos.

O repositório também conta, quando está organizado. Se o seu código está no GitHub com um README que explica o app, o guia de currículo de programador sobre GitHub e projetos mostra como apresentar esse material sem exagerar. A regra é a mesma para qualquer projeto: escreva o que existe e o que você fez, sem inflar downloads ou usuários que não existem.

Quais erros mais derrubam o currículo de desenvolvedor mobile?

Alguns erros aparecem tanto que vale conferi-los antes de enviar, porque são fáceis de corrigir e custam a vaga com frequência.

• Plataforma escondida no meio do texto. A vaga procura Android ou iOS na primeira leitura, e se o termo não aparece no título ou no resumo, a pessoa que escreveu a plataforma com clareza passa à frente.
• Lista de linguagens sem app. Dez linguagens em uma linha, sem nenhuma frase de uso, são lidas como conhecimento de curso, mesmo que você tenha usado todas.
• Número de download inventado. Além de ser fácil de checar em loja, ele some na primeira pergunta da entrevista sobre o app.
• React Native ou Flutter escritos como nativos. A vaga nativa testa a plataforma, e o candidato que trocou uma pela outra costuma travar nessa parte.

O que fazer antes de enviar o currículo de desenvolvedor mobile?

A regra que resume o guia: diga a plataforma logo no começo, ligue cada linguagem a um app com função e resultado, e cite a loja e o painel em que a publicação aconteceu. Quando o texto faz isso, o recrutador entende a sua experiência em uma leitura, e não precisa adivinhá-la.

A consequência de não fazer isso é deixar a vaga com a dúvida: você programou para o usuário ou só escreveu código para um professor? Essa dúvida costuma ser resolvida em favor de quem mostrou o app. Antes de enviar, cole o texto da vaga na análise gratuita do AjustaCV. Ela compara o seu currículo com o texto da vaga e mostra quais termos ele já tem e quais faltam, sem cadastro. Use o resultado para achar as lacunas e preencha-as só com o que você construiu.

Perguntas frequentes