Em processos seletivos é bastante comum a prática de pedir que os candidatos resolvam desafios em casa, com o objetivo de avaliar suas habilidades em resolução de problemas e como o candidato coda. O interessante sobre resolução de problemas é que um mesmo problema pode ser solucionado de diferentes maneiras. A diferença entre as soluções será a experiência, o conhecimento da linguagem e como seu cérebro está acostumado a trabalhar. Tem um misto de organização do código e o que você prioriza mais, como “resolver o problema rápido e otimizá-lo ou saber otimizá-lo desde o início?”.

Nesse post vou compartilhar as minhas práticas quando resolvo esses desafios de código. Fique a vontade para compartilhar as suas no fim desse post!

Tipos de problemas

Os desafios de código podem variar bastante no que é pedido mas geralmente dividem-se em dois grupos:

• Criar um projeto do zero
• Resolver pequenos problemas

Para ambos, geralmente, existe um prazo para resolver. Até agora as empresas que já me pediram para criar um projeto variavam o prazo entre 4 e 7 dias. Os projetos eram diversificados. Aqui uma ideia dos que já fiz:

• CLI para recomendação de filmes
• API de transportes (com direito a deploy, containerização, documentação e testes de carga) 😱
• Cálculo de roteamento de carga
• Predição de empréstimos bancários

Todos bem diferentes. Um adendo que gostaria de fazer é: avalie se compensa o tempo que você vai gastar. Em um desafio com prazo de 7 dias para construir uma API com testes e documentação, por exemplo, depende do quanto de tempo disponível que você tem para isso. Está trabalhando em tempo integral? Tem família? Está bem da cabeça? Muitas coisas para considerar. E o principal: a vaga compensa? Projetos como parte do processo acabam eliminando muitos candidatos. Fazê-los acaba aumentando suas chances de ser chamado pra entrevista mas exige um investimento (grande) de tempo.

Resolveu fazer? Vamos pra as próximas dicas.

Entenda bem o problema

Às vezes a ansiedade domina a gente e detalhes importantes acabam sendo perdidos. Seja com 30’ ou 7 dias de prazo, leia tudo com calma. Se possível faça notas. Dessa forma você não precisará revisitar o enunciado todas as vezes.

Comunique-se: se não deu pra resolver tudo, não tem problema.

Algumas pessoas tem receio de pedir mais tempo ou dizer que algo faltou. Transparência é uma característica importante. Nem sempre você vai entregar tudo no prazo, imprevistos acontecem. Ninguém vai te bater ou assassinar sua família se você pedir mais dois dias pra fazer algo melhor.

Projetos grandes (prazo maior que 1 dia)

Nem sempre vão te pedir pra fazer algo que você já fez antes ou domina. Independente de qual seja o seu caso:

• Faça um plano

Parte dos desafios é entender como você organiza seu trabalho e resolve problemas. Depois de entender o que tem que ser feito, é importante traçar um plano, quebrando em tarefas menores. Assim você tem visibilidade do seu progresso e clareza sobre o que tem que ser feito.

• Resolva o problema começando pelo o que você manja mais

Essa dica veio de uma grande amiga e desenvolvedora. Se você faz logo a parte que você manda bem, a sua confiança está maior para partir pra algo que você não manja tanto assim. Claro, aqui estou partindo do pré suposto que as tarefas são divisíveis.

• Faça o melhor que você puder

“Mas claro que eu vou fazer o meu melhor. Duh.” Será mesmo? :)

Conceito de melhor varia entre as pessoas mas para algumas existe a ilusão que a empresa não vai olhar o código ou vai apenas conferir se o resultado está correto ou não. Se for pra não fazer com esmero, melhor nem enviar. Você pode acabar se queimando.

Certa feita, um colega de trabalho foi revisar o código de um candidato e viu um comentário dizendo que o autor era uma outra pessoa. Investigando o caso… surpresa! O candidato havia copiado e colado o código descaradamente. Talvez pensou que ninguém ia olhar, né?

• Evite *over engineering*

O pragmatismo é uma benção e uma característica cada vez mais buscada por empresas. Na minha ~humilde opinião, mais vale uma pessoa pragmática na hora de resolver problemas do que alguém super foda tecnicamente mas que não sabe ir direto ao ponto. Se está pedindo um endpoint retornando uma informação, se atenha em fazer isso primeiro. Se houver tempo e couber firulas, tudo bem. Você pode acabar numa armadilha se inventar muita coisa extra.

Desafios menores (prazo menor que 1 dia)

Os desafios menores se assemelham a problemas similares aos de uma maratona de programação. São problemas que vão avaliar se o resultado está correto e também fazer uma análise estática do seu código (provavelmente uma análise ciclomática e coisas do tipo).

As primeiras vezes que resolvi problemas assim em processos seletivos foi um horror. Me lembro que uma vez me pediram para fazer um jogo da velha multidimensional. Passei horas, o código ficou horrível e com uma solução complexa. Não passei. Com o tempo, aprendi algumas coisas:

• Antes de mais nada, resolva no papel

O motivo é bem simples: todas as vezes que você resolve no papel, os seus pensamentos ficam mais organizados e vendo os passos que você utilizou para resolver o problema escritos ali ajudam na hora de passar essa “lógica” para o código. Enquanto estiver resolvendo, conversar com você mesma(o) e tentar identificar o que está implícito (um cálculo, uma lógica, uma intuição) pode ser bem útil também!

• Só mais um loop ou recursão?

Não tem pra onde correr: apenas a prática vai ajudar a fortalecer a autoconfiança e a sua memória também. Em alguns casos, você vai precisar saber como manipular strings, calcular frequências e identificar elementos que são comuns em duas listas. Nesses casos, a linguagem de programação pode ajudar. Apenas programando, resolvendo problemas como os que estamos falando aqui ou no dia a dia, é que esses recursos vão fixar na sua cabeça. Em outros casos, você talvez precise saber sobre estruturas de dados, grafos ou programação dinâmica. Se usa um loop ou tem como abstrair pra uma recursão. Pra esses casos, um pouco de teoria será necessário. Se quiser saber mais sobre isso, procure por análise assintótica e/ou conteúdos de disciplinas de projeto e análise de algoritmos.

Existem incontáveis sites para praticar. O HackerRank é o meu preferido e eu já utilizei em processos seletivos de empresas como Spotify e Twilio. Fica a dica.

• Respira fundo

O último e não menos importante: tenha calma. Não é e nem será o último teste que você vai fazer. Além disso, ansiedade não traz vantagem nenhuma. Não deixe ela te dominar. :)

Se não der certo, está tudo bem também. Certa vez fiz um teste desses para uma empresa de BH e fui MUITO mal. Já estava convicta de que não seria chamada pra entrevista. Para minha surpresa, me chamaram e me deram a chance de explicar o que aconteceu (como eu estava pensando e o que eu acho que tinha dado errado). Passei pra próxima etapa. 🤔😅

Sob a perspectiva do avaliador

Durante a minha carreira já tive a oportunidade de estar também do lado de quem avalia o código e faz entrevistas técnicas com base em algum desafio. Nessas oportunidades, algumas coisas que eram observadas:

• Organização do projeto: estrutura de pastas, documentação necessária para rodar o projeto e testes
• Presença de testes: unitários (ou de integração - melhor tê-los do que não ter nenhum hehe)
• Abstração do problema: como foi modelado, se tem duplicação de código, facilidade de leitura, acúmulo de responsabilidade nas classes e métodos
• Boas práticas da linguagem escolhida.

Parece bastante coisa mas, com o tempo, a experiência vai resolvendo alguns casos e você já estará implementando as boas práticas naturalmente.

Um adendo sobre a entrevista técnica / pareamento

Falando em entrevista técnica, gostaria de reforçar: esteja preparado para responder perguntas sobre o seu próprio código. Se algo foi difícil de resolver, talvez valha a pena anotar isso pra relembrar no dia da entrevista.

Na entrevista você não precisa tentar passar uma impressão de que é super foda ou algo assim. Seja você mesmo. A transparência não é um sinal de fraqueza; pelo contrário. Essa dinâmica de avaliação de candidatos é uma tentativa de acessar quais áreas são boas e quais você precisaria de maior assistência.

Durante a entrevista, algumas pessoas tem dificuldade de explicar o seu código. Aqui algumas coisas que são comuns de ouvir dos candidatos:

“Não lembro porque eu fiz esse código há um mês”

Não custa nada dar uma relembrada no seu projeto antes de vir para entrevista. Lembre-se que são pessoas que estão do outro lado te avaliando. Você iria pra uma reunião com um cliente sem estar preparado sobre o assunto da reunião?

“Geralmente eu faria de tal jeito mas não tive tempo”

Eu vejo dois problemas nessa frase. “Eu faria de tal jeito”: porque não fez então, criatura? Dizer isso numa entrevista não faz sentido nenhum. Como você sabe o melhor jeito ou o jeito certo de fazer algo e não faz? Soa estranho, como uma bela desculpa esfarrapada.

O “não tive tempo” é outro clássico mas eu consigo entender. Alguns candidatos têm medo de solicitar mais tempo e serem prejudicados com isso. Na minha opinião, é bobagem. Levando em consideração o privilégio que temos na área de programação, onde as empresas matam cachorro a grito pra contratar desenvolvedores, é totalmente ok pedir um prazo maior. Já aconteceu comigo algumas vezes: já recebi desafio de código nas vésperas de uma viagem ou estava perto de terminar mas o prazo estava perto de vencer. Em todas as situações eu enviei um e-mail lá pessoa do recrutamento explicando a situação e voilá: meu prazo foi estendido e eu consegui entregar algo que me deixou satisfeita.

That’s all folks

Pra quem está fazendo processos seletivos: boa sorte! Se você tem alguma dica, deixa nos comentários! 😀

Até a próxima!