Desenvolvedor Android: O que esperam de você numa entrevista técnica?

Nem de longe sou especialista em recrutamento de desenvolvedores. Mas posso afirmar que nos últimos 3 anos já entrevistei mais pessoas do que sou capaz de contar, desde junior a especialistas.

Na maioria das empresas brasileiras o processo seletivo pode ser separado em 3 etapas principais: Primeiro contato com o pessoal de recrutamento, entrevista técnica e entrevista com a gestão e/ou time. E é justamente na etapa técnica em que me encaixo e é a etapa que, geralmente, os desenvolvedores mais possuem dúvidas e ficam nervosos.

Tipos de entrevistas técnicas

Obviamente, a forma como cada empresa avalia o candidato difere bastante. Mas no geral, existem 3 abordagens mais utilizadas:

• Código no Github: Essa é a abordagem que mais vejo as empresas utilizarem. Geralmente, lhe pedem o link de algum projeto recente ou te dão um prazo para desenvolver algo e mandar o link posteriormente. Após o envio do link, marcamos o bate-papo técnico para debater o código.
• Live-Coding/White board: Creio ser a abordagem mais temida pelos candidatos. Não lhe pedem um projeto com antecedência, apenas marcam a entrevista e lhe darão um problema para ser resolvido/trabalhado durante o tempo da entrevista. Busca avaliar seu raciocínio lógico, habilidade em quebrar o problema em partes menores, conhecimento em estrutura de dados, etc.
• Bate papo técnico: Nessa abordagem, geralmente não se faz necessário um projeto prévio. O intuito é realmente ser um bate-papo em que perguntas técnicas serão expostas, com situações hipotéticas, onde os temas podem ir se aprofundando, a depender do nível ao qual o candidato está sendo avaliado.

Como dito, há diversas outras formas de avaliar tecnicamente um candidato, como por exemplo, usando hackerRank, etc. ou até mesmo misturar as abordagens. Tudo vai depender da empresa que está se candidatando.

Caso tenha dúvidas de quais tecnologias utilizar e/ou por onde começar a estudar para se tornar um desenvolvedor Android, veja a sequência de artigos que criei sobre o tema aqui.

Sobre a tal "régua" de contratação

Agora que sabe que existem diversas formas de te avaliar tecnicamente, preciso lhe dizer uma realidade dura e cruel: Seu nível de senioridade é volátil. Ou seja: Você pode estar hoje como Pleno na empresa XPTO, mas ao participar de um processo seletivo da empresa ABC pode ser classificado como júnior.

Injusto? Não. Cada empresa define, mesmo que de forma não intencional, uma "régua de contratação". Isso é algo que pode frustrar muitos desenvolvedores, principalmente se ele for classificado com uma senioridade "abaixo" do que atua hoje.

Consigo ouvir o desespero do ego ferido à quilômetros de distância, afinal: "Como assim eu, que sou especialista no meu atual emprego, fui rejeitado nessa empresa para uma vaga sênior?!". Mas a realidade é uma só: É só questão de nomenclatura. Então, não leve para o pessoal se você um dia for reprovado em uma vaga com o mesmo nível de senioridade em que já atua. São projetos diferentes e complexidades distintas.

Porém, às vezes e muito às vezes, essa régua pode ser flexível a depender da urgência da vaga/projeto.

Photo by Magnet.me on Unsplash

Tópicos avaliados por senioridade

Sabendo agora sobre a tal "régua" de contratação, gostaria de explicitar aqui que os pontos que vou citar abaixo são baseados totalmente em meus 3 anos entrevistando candidatos (em 3 empresas diferentes). Não sendo uma verdade absoluta, mas que pode ser um bom “norte” para quem deseja entender melhor o processo avaliativo "por baixo dos panos".

Vai ser possível notar também que, muitas vezes, os pontos avaliados são os mesmos. Porém, o que muda é a profundidade de conhecimento exigido. Exemplo: É um plus se um desenvolvedor júnior já tiver ouvido falar sobre testes automatizados e sua devida importância. Para um pleno, é esperado que já tenha tido ao menos alguma experiência com testes e saiba criá-los (mesmo que necessite de algum apoio). Já para um sênior, é requerido que, não somente tenha experiência com testes, como também seja capaz de apontar o que deve ser testado ou não em um projeto, conhecer os diferentes tipos de testes, etc.

Percebem? O tema é o mesmo para todos: Testes automatizados. Porém, tanto a obrigatoriedade quanto a profundidade no conhecimento do tema diferem de nível pra nível.

Outro ponto relevante a ser mencionado é que, apesar de ser uma etapa técnica, o seu comportamental durante a entrevista vai contar tanto quanto. Por esse motivo, vou separar os tópicos em: Hard skill e Soft Skill. E sim, você pode ser incrível tecnicamente e ainda assim, ser reprovado por alguma soft skill não evoluída. :)

Dito isso, vamos começar…

Junior

Vamos começar pelo nível mais delicado, pois geralmente são pessoas com pouco conhecimento técnico e com grande ansiedade, o que pode dificultar a extração do conhecimento técnico. Mas no geral, o que é avaliado/esperado desses candidatos:

• Hard Skill:

Conhecimento de Android: Parece algo óbvio, mas acreditem, não é. Já entrevistei candidatos que não sabiam como funcionava o ciclo de vida de uma activity, não sabiam explicar as diferenças entre Activity e Fragment e por aí vai. Então: Foque em aprender a base.

Boas práticas: É algo muito observado durante a entrevista o quanto o candidato se preocupa com boas práticas de programação e até com Clean Code: Como nomeia as variáveis, como declara funções, como realiza a separação do que entra em cada classe e por aí vai. Se você é acostumado a nomear suas variáveis com letras (x, y, abc) sugiro que mude o quanto antes para nomes legíveis e de compreensão auto contidas.

MVVM: É óbvio que existem diversas formas de construir um código, mas verdade seja dita: A maioria dos projetos do mercado utilizam MVVM. Então é muito importante não somente saber COMO utilizar essa arquitetura, mas também saber explicar o que entra em cada camada.

Threads e chamada de API: Vou colocar esses tópicos em um bolo só... Saber o que é uma thread, como (e quando) usar ao menos as principais (Main e IO), qual o impacto de rodar tudo na Main Thread, saber realizar uma chamada pra um serviço (podendo usar Coroutines, Rx, etc), etc. São pontos importantíssimos para compreender e conseguir explicar quando lhe perguntado, de forma clara e objetiva.

Testes: Já dei um pequeno spoiler lá em cima sobre o que é esperado de um Junior quando o assunto é testes. Entender o que é, quais as vantagens, quais os tipos de testes automatizados e qual o objetivo que cada um espera alcançar. Se quiser ir até um pouco mais longe, recomendo dois passos: Tentar construir seus próprio testes unitários e entender sobre pirâmide de testes.

• Soft Skill:

Comunicação: Para um nível de estagiário/júnior, obviamente, a parte técnica conta muito. Mas é justamente nas soft skills que muitos candidatos se perdem. E comunicação é um dos pilares: Saber transmitir o que pensa, se mostrar receptivo a feedbacks, dizer abertamente quando não sabe de algo* e se mostrar interessado em saber (você pode perguntar a resposta, ou anotar para posterior pesquisa).

* Alguns candidatos acreditam que dizer abertamente que não sabem/conhecem algo que foi lhe perguntado é um ponto negativo, quando na realidade, é extremamente positivo (claro, você não deve dizer isso pra todas as perguntas). Ter a humildade de admitir que não conhece algo, principalmente em cargos inicias, é positivo pois acredite: Você não saber muita coisa é esperado.

Envolvimento com a comunidade/Formas de aprendizado: Esse ponto é extremamente importante, afinal, ele vai demonstrar qual seu nível de comprometimento com sua carreira. Obviamente, não é esperado que você faça palestras, escreva artigos, etc. Mas você faz cursos? Você assiste palestras? Lê artigos? Como se mantém atualizado? São perguntas que fazemos para todos os entrevistados.

Top 5 erros mais comuns

Vou listar aqui os erros mais comuns que um candidato(a) junior pode cometer durante a entrevista que, para nós entrevistadores, já nos faz repensar sobre a aprovação do mesmo:

1- Copiar o projeto e/ou fazer o que "sempre foi feito", sem entender o motivo de decisões/implementações. Acredite: Não conseguir explicar o seu próprio código é um grande tiro no pé. Estude (e entenda) o que está implementando.

2- Se mostrar reativo a feedbacks: Vai ser normal verbalizar pontos de melhoria em seu código durante a entrevista. Mostre-se aberto, interessado em aprender. É o que esperamos de um júnior. Já entrevistei um candidato que todo feedback que eu dava sobre o código, ele dizia: "Eu sei disso, só não fiz por falta de tempo." #RedFlag

3- Inventar respostas: Nós percebemos quando o candidato não entende/sabe um determinado assunto. Tentar "enrolar" uma resposta, jogando frases soltas, só demonstra uma certa resistência em dizer que não sabe algo.

4- Preocupação com layout e performance: É um ponto que deve estar no seu radar desde sempre. Qual o impacto de usar um único Constraint Layout ao invés de vários LinearLayout aninhados? Por qual motivo usar RecyclerView? Construir um layout vai muito além de "exibir itens na tela". E demonstrar preocupação nesses pontos é algo que, com certeza, vai lhe dar uns pontinhos a mais.

5- O último, e pra mim, o mais "problemático" é composto por várias vertentes, mas posso resumir como "falta de base". E essa base pode ser tanto teórica quanto prática. Saber usar o Kotlin (sim, já vi gente fazendo código como se estivesse no Java, sendo que com Kotlin poderia abstrair e facilitar a implementação) é tão importante quanto saber a diferença de Activity x Fragment. Não sabe o que seria uma boa base? Tenho uma série de artigos no qual descrevo os pontos que você deve estudar para se tornar um bom desenvolvedor android.

E aí, discordam de algum ponto? Sentiram falta de algum ponto que já lhe foi cobrado e que não citei?

No próximo artigo vamos nos aprofundar nos pré-requisitos de um desenvolvedor Pleno e um sênior. :)