Tabela de Conteúdos

1. Introdução
2. Escolha da Tecnologia
3. O Domínio do Desafio
4. Desenvolvendo a Solução do Desafio
5. Hora de Testar a Aplicação
6. Entrega e Conclusão

Introdução

Antes de mais nada, gostaria de me apresentar, sou Leonardo Fiedler e atualmente trabalho como pesquisador na Senior Sistemas. A motivação inicial para este post surgiu depois da experiência ao avaliar algumas pessoas candidatas a vaga para trabalhar na equipe que faço parte.

Deixo bem claro também que este post não é um guia, nem mesmo irá estabelecer regras do que fazer ou que não fazer, mas sim, será dado dicas e observações de alguém que esteve do outro lado, avaliando desafios. As dicas deste post também podem ser aplicadas a qualquer projeto que você for participar.

Para mandar bem no desafio é necessário atenção em todos os detalhe, desde a escolha da tecnologia, documentação, testes, até mesmo a entrega. Lembre-se que tudo conta e tudo é avaliado e levado em consideração.

Escolha da Tecnologia

Escolher sabiamente a tecnologia para resolver um problema é uma tarefa cotidiana na vida de uma pessoa desenvolvedora de softwares, por conta disso, caso o problema não especifique as tecnologias a serem utilizadas, você deverá fazer. E é aqui que você pode mitar ou virar o bola murcha logo de cara.

Primeiramente, procure entender as tecnologias que a empresa e a equipe que se está aplicando utilizam no cotidiano - particularmente, sugiro dar preferência por esta, mas caso não seja algo de sua familiaridade e isso não seja um impedimento para a vaga, escolha a tecnologia que você mais se sinta confortável.

Evite a ideia de selecionar uma tecnologia que nunca utilizou anteriormente para tentar aprender e fazer o desafio ao mesmo tempo, pois isto poderá lhe causar contratempos e ainda impactar no desempenho do seu trabalho.

É claro, estou falando de aplicar um conceito ou uma linguagem em sua totalidade que nunca foi praticado antes. Isso não se aplica, por exemplo, caso você já tenha utilizado MySQL mas o desafio seja com base no PostgreSQL - neste caso, já são compreendidos os conceitos de: SQL e bancos relacionais e só terá de aprender algumas especificidades de um para o outro.

Uma outra coisa importante na escolha das tecnologias: evite escolher algo somente pelo hype. Para cada decisão que tomar, tenha uma justificativa clara do porquê está escolhendo aquilo e lembre-se que esta escolha precisa estar atrelada diretamente ao domínio do problema.

O Domínio do Desafio

Normalmente, o desafio é iniciado com um texto introdutório, seguido por uma lista de requisitos. Durante a leitura do texto, deve-se buscar algumas respostas:

1. Qual o problema principal?
   Esta aqui é simples, num amontoado de requisitos, procure entender o problema principal, é ele que você tem de atacar. Tente entender também, onde estará o desafio principal, se é no front, back, arquitetura, banco de dados...

2. Quais os requisitos são mais importantes e essenciais?
   Sabendo o problema principal, mapeie todos os requisitos que são essenciais. Estes deverão ser os requisitos que você deverá focar e atender com maestria (são esses que irão ser avaliados, se não forem contemplados, dificilmente algo além deles vai contar muitos pontos para você)

3. O que pode ser o diferencial do seu trabalho?
   Pense no que poderá destacar o seu trabalho ao resolver este problema, porquê dentre N soluções alguém escolheria a sua como a resolução definitiva? Não necessariamente é obrigatório ter algo diferente, você pode ter uma sacada de arquitetura, uma ideia de comunicação, uma forma inteligente de criar a interface de usuário, como por exemplo, sendo responsiva para dispositivos móveis ou até mesmo hospedando sua solução para que os avaliadores possam acessar e executar online.
   Pense nas respostas das perguntas anteriores para chegar nesta.

Estando em mãos dessas 3 respostas, é hora de botar a mão na massa, mas não se esqueça que você terá um tempo limitado para fazer isso e deverá administrar sabiamente o tempo para entregar um bom desafio.

Desenvolvendo a Solução do Desafio

Essa é a melhor parte, mas que pode se tornar um pesadelo se você cometer alguns deslizes. Um dos mais clássicos, inclusive cometido por mim em diversos trabalhos da faculdade e pós graduação, é a PROCRASTINAÇÃO!

Pois é, uma única palavra, aparentemente tão inofensiva, pode fazer o prazo de entrega de 1 semana se tornar 1 dia em questão de algumas viradas de ponteiro. Administrar o tempo é fundamental e deixar para depois é sempre pior, então a dica é: comece assim que receber o desafio, trace metas diárias e estabeleça um prazo de entrega antes da data planejada (eu gosto de terminar um dia antes, assim ainda me sobram algumas horas para rever e fazer alguns ajustes pontuais).

O segundo problema é algo também bem conhecido no meio de tecnologia, onde você entra em um espiral de pesquisas e divagações, tentando fazer algo funcionar de uma forma e investe muito tempo tentando fazer algo "perfeito" e isso lhe consome um tempo precioso. Entregar um desafio da melhor forma possível é algo que todos adoram, mas lembre-se que a perfeição nunca existirá e você não terá tempo hábil para isso. Então, prefira fazer e seguir em frente ao ficar perdendo tempo com coisas que podem ser melhoradas futuramente.

Durante o desenvolvimento do desafio, seu objetivo deve ser avançar as etapas, sem perder o ritmo. Mas espere, não vá muito rápido para não se atrapalhar nas próprias pernas! Nesta etapa, você não pode esquecer de documentar e testar.
DOCUMENTAÇÃO é um ponto que separa bons/medianos de ótimos trabalhos. Ao abrir um projeto, ler um README.md que contém informações sobre:

• O que é o projeto?
• Quais tecnologias utilizadas?
• Como instalar e executar a aplicação?
• Link de acesso público ou um Gif/prints demonstrando o funcionamento da aplicação
• Diagrama de funcionamento da aplicação (ou uma explicação um pouco mais técnica sobre como funciona o projeto)

Provavelmente você não consiga fazer tudo isso em um desafio, mas escolha alguns desses itens e dê uma atenção a documentação, porque caso não tenha, uma pessoa avaliadora terá bastante dificuldade em saber o que você fez e precisará passar pelas suas classes e métodos para entender seu código.
E a propósito, eu falei em documentar o todo, mas e o código, documentar ou não documentar? Eis a questão... Não há um consenso entre os avaliadores, assim como não há consenso entre as pessoas da área, tem os que acreditam que deve-se documentar os métodos, já outros dizem que o código deve ser a própria documentação.

Particularmente, gosto de documentar algumas parte do código, mas sem aquelas obviedades, como:

# Este código abaixo printa o texto Hello World
print('Hello World')

Aliás, falando desse trecho de código, escrever em português ou inglês?

Essa também é uma questão complexa e na verdade, não há uma resposta correta. Particularmente, eu adoto a seguinte postura: estou no Brasil, todos falam o português, então este é o idioma padrão por aqui. A menos que a empresa seja estrangeira ou o problema explicitamente me peça para trocar o idioma, eu escreverei neste idioma.
Independente do idioma que adotar, jamais misture idiomas, como nesse caso abaixo:

# Este método faz algo
def do_something():
  pass

# This method does something
def faz_algo():
  pass

Você deve ter lido até agora esta seção e pensado: caramba, cadê a parte em que ele vai falar de Clean Code, Clean Architecture e tudo mais que eu tenho de fazer no meu código? Pois bem, vamos falar disso.

Acho muito bacana tudo isso, de verdade, mas veja só, você tem um desafio e um prazo curto para fazê-lo. Você já conhece esses livros e já os aplicou alguma vez antes? Ótimo, coloque seus ensinamentos em prática aqui também. Nunca os leu, não lembra, deu branco ou qualquer outro motivo: faça o básico! Foco na entrega, no resultado final. Escreva um código bem estruturado, divida em classes/arquivos, deixe tudo ORGANIZADO! Mas lembre-se, vão te avaliar por uma solução pronta e entregue, ou seja, pelo todo e não apenas por um item em específico.

Um outro detalhe muito importante no código, evite a utilização de strings de configuração fixas! Pois é, segundo a agência Dados Inventados SA, para cada candidato que deixa uma config fixa no código, um dia é acrescentado a pandemia (como se já não bastassem outros motivos). Vai usar uma URL? Um parâmetro estático? Então você tem 2 alternativas para fazer isso de forma elegante:

1. Crie uma constante (é bacana, mas não é top);
2. Criar um arquivo de configução e utilizá-lo (esse é o que eu recomendaria se quisesse gabaritar no desafio).

Com todas essas dicas, as pessoas que irão avaliar vão até lhe agradecer pelo seu desafio...

Hora de Testar a Aplicação

Então você construiu a aplicação, fez todos os passos e terminou o desenvolvimento. Aparentemente, está tudo certo e tudo funciona como esperado.

Mas espere, você criou testes?? Xiii...
Essa é uma parte que percebi de maior dificuldade as pessoas que se candidataram. A maioria investe tanto tempo desenvolvendo que não há sequer espaço para testes, por mais simples que sejam.

Uma dica para você destacar o seu projeto: preocupe-se e implemente casos de testes. Por mais simples que eles sejam, bons e bem documentados testes irão elevar o patamar do seu trabalho.

E não precisa pensar muito complicado, viu? Pode fazer testes unitários e de carga se for uma API, pode fazer testes de interface ou até algum outro.

Normalmente, este é um item que fica por último e em certas vagas, como a que avaliei, os testes não eram nem especificados no desafio. Porém, quem fizer...

Entrega e Conclusão

Parabéns, se você chegou até aqui, possivelmente passou por toda a odisseia e está pronto para entregar o seu trabalho e correr para negociar o salário.

Brincadeiras a parte, após concluir o desafio, caso ainda tenha tempo, sugiro que publique em algum lugar para que os avaliadores possam ver.

É normal, infelizmente, que o seu desafio não ganhe um feedback como devesse ser merecido após tanto esforço. No entanto, publique seu código no GitHub e compartilhe com pessoas mais experientes, peça a elas um feedback (pode mandar lá no Twitter também, inclusive).

Também após o desafio, gosto e recomendo que faça uma retrospectiva de tudo que construiu, as dificuldades encontradas, o que pode estudar mais e o que fazer de diferente em uma próxima.

Testes técnicos são uma maneira de avaliar, de forma geral, o conhecimento e domínio em um conjunto de ferramentas e caso você não tenha ficado satisfeito com o resultado, não se cobre tanto, lembre-se que o aprendizado é um processo e você sempre estará em seu meio. Reflita sobre seus acertos e erros e tente novamente caso não tenha obtido êxito.

Espero que tenha gostado e bons desafios!