Antes de começarmos gostaria de me apresentar, sou Leonardo Fiedler e atualmente trabalho como Data Architect na Senior Sistemas. A motivação inicial para este post surgiu depois da experiência adquirida ao avaliar algumas pessoas candidatas a vagas para trabalhar nas equipes em que fiz parte.

Gostaria de deixar claro que este post não é um guia, nem mesmo buscará estabelecer regras do que se deve fazer ou não, mas sim, compartilhar experiências sob a perspectiva de alguém que esteve do outro lado, avaliando desafios. As observações deste post também podem ser aplicadas a quaisquer outros projetos que você vir a desenvolver.

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

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 marcar um golaço ou virar o bola murcha logo de cara.

Primeiramente, procure entender as tecnologias que a empresa e a equipe utilizam no cotidiano - particularmente, sugiro dar preferência por estas, 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 enquanto produz a solução, isto poderá lhe causar contratempos desnecessários e ainda por cima, impactar na entrega final do seu trabalho.

É claro que, neste caso, o cuidado deve estar a aplicação de um conceito ou uma linguagem de maneira inédita. 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 inicia-se 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, exemplos e cenários, procure entender qual é o problema raíz, pois é ele quem você terá de atacar primeiro. Busque entender também onde está o foco deste 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 serão os que você deverá focar e atender com maestria (são esses que irão ser mais avaliados. Se não forem contemplados, dificilmente algo além deles vai contar ponto 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 antes de chegar nesta.

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

Desenvolvendo a Solução

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. Portanto, a dica aqui é: 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 grande problema também é algo 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" - o que acaba lhe consumindo 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ê nem sempre terá o tempo hábil para isso. Então, prefira fazer uma primeira versão e seguir em frente ao ficar parado 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 medianos de ótimos/excelentes 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 uma sequência de Gif/prints demonstrando o funcionamento da aplicação

• Diagrama de funcionamento da aplicação (ou uma explicação um pouco mais técnica e detalhada sobre o projeto)

Provavelmente você não conseguirá 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? Eis a questão... A verdade é que não há um consenso sobre isso, tem quem acredite que deva-se documentar pelo menos os métodos (as famosas docstring), já outros dizem que o código deve falar por si.

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, tenho adotado o padrão de escrever tudo em inglês - preferência pessoal mesmo. Independente do idioma adotado, jamais misture idiomas, como nesse caso a seguir:

# 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 (alguns) de seus ensinamentos em prática aqui também. Nunca os leu, não lembra, 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/métodos, deixe tudo ORGANIZADO! Mas lembre-se, vão te avaliar por uma solução pronta e entregue, ou seja, pelo conjunto da obra 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 S.A., para cada candidato que deixa uma config fixa no código, mais um bug aleatório nasce em algum sistema por aí. 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 (é rápido e bacana, mas não é top);

2. Criar um arquivo de configuração e utilizá-lo (ou então utilizar alguma lib que faça isso).

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 percebo de muita dificuldade das pessoas que se candidatam. A galera 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 sejam, se forem bons e bem documentados, os testes irão elevar o patamar do seu trabalho.

E não precisa ir muito longe, viu? Testes unitários, de carga ou de interface já irão lhe ajudar bastante, mostrando que você sabe sobre o assunto e também conhece como se implementa.

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.

Também após o desafio, recomendo fazer 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!