Olá olá!
Esses dias estava passeando pelos meus repositórios do GitHub e vi um dos últimos desafios técnicos que fiz por lá. Refletindo um pouco sobre ele e sobre tudo o que eu aprendi enquanto entrevistadora técnica na minha empresa atual decidi fazer um compilado de dicas que eu daria pra mim mesma naquela época.
Bem, lhes apresento a minha lista de 5 dicas de como escrever um bom desafio técnico:
Entenda o problema
Durante o desafio técnico (seja escrevendo código ou whiteboard), a primeira coisa que precisa ficar clara é qual o problema que você vai ter que resolver. Quanto menor for o seu nível de dúvidas, maior é a possibilidade de entregar uma solução assertiva e, ouso dizer, gerando uma entrega com mais confiança até.
Os envolvidos na entrevista técnica estão preparado para tirar suas dúvidas e (pelo menos nas entrevistas que já participei) isso não afeta em nada o resultado daquela etapa. Pode perguntar sem medo!
Aqui também vale destacar a importância de confirmar se todos os contratos estão sendo cumpridos uma vez que a solução estiver pronta.
Se o desafio for escrever uma API por exemplo, confirme se os retornos, rotas e validações estão de acordo com o descrito no problema, veja se os pré-requisitos funcionais e não funcionais do código foram atendidos.
Um detalhe importante é que não é incomum seu projeto ser testado de forma automática. Então se no desafio você precisa criar uma rota para a url /create-user e você escreve /createUser, pode ser que o teste não passe e isso acabe te atrapalhando. Novamente, confirme se os requisitos foram atendidos.
Não deixe de entregar seu desafio porque não conseguir completá-lo. O ideal é entregar tudo de acordo com o que foi pedido, mas não é impossível passar em uma vaga sem ter concluído 100% do desafio.
Explique seu repositório
Nada me deixa mais triste com um repositório do que a falta de documentação. O que eu preciso instalar pra fazer o projeto rodar? Quais comandos eu preciso chamar para conseguir fazer o que precisa? Existe Docker? Tem alguma coisa de fora da linguagem que eu preciso? Alguma configuração?
É extremamente importante que a pessoa que vai avaliar sua solução consiga saber facilmente como ela funciona. Inclusive pessoas de outros lugares. Seu GitHub, GitLab, Bitbucket, etc, é um portfólio e pode ser seu grande aliado.
Tire um tempo para atualizar o README e, pelo menos, explicar a ideia geral do projeto, como instalar e como utilizar. E confirme se tudo funciona conforme o descrito.
Destaque para a lógica
Muitas vezes vemos nas vagas alguma menção à framework. Então assumimos que para escrever uma boa solução precisaremos usar aquele framework e demonstrar nosso conhecimento sobre ele. Só que nem sempre é assim.
Quem vai avaliar precisa entender como é seu processo criativo, o que você pensou até chegar em uma solução e como você trabalha.
O uso de um framework me faz lembrar de dois possíveis problemas logo de cara:
- Às vezes a solução enviada está tão acoplada com as funcionalidades existentes no framework que é impossível avaliar como é o código de quem entregou. Código gerado pelo framework é bem diferente do código que nós escrevemos no dia a dia.
- Quando uma solução depende demais das features disponíveis no framework pode ser que a solução enviada seja muito mais complexa do que o necessário.
Não é ruim usar frameworks ou bibliotecas, mas crie algo que demonstre sua linha de raciocínio, algo que você entenda porque funciona, como funciona, que você acredita que seja a forma mais otimizada de resolver algo e que vai saber explicar posteriormente.
Demonstre conhecer a tecnologia utilizada
Aqui é meio que uma extensão da dica anterior. Demonstrar que você conhece funcionalidades da linguagem escolhida que não estão no framework vai te ajudar, conseguir explicar porque usou determinado banco ou determinada biblioteca também vai te ajudar.
Saiba os motivos pelos quais está usando a tecnologia que você escolheu. Pode ser que você esteja aplicando para uma vaga de níveis iniciais e só usou o MySQL porque está acostumado com isso, então esse é seu motivo e tudo bem. Mas a medida que o nível das vagas vai aumentando, essa exigência também vai aumentando, então questione as decisões que você toma automaticamente e veja se fazem sentido para o contexto do desafio proposto.
Lembre-se das melhores práticas
Um código bom é um código que funciona e que também é legível. Não existe essa de que só funcionar está bom, ainda mais em um momento onde seu código é avaliado.
Algumas vagas, pelo menos na minha bolha de PHP, fazem menção a algo chamado PSR (PHP Standard Recommendation) que nada mais é do que uma lista de boas práticas para escrita de código. Fala sobre formatação, nomenclaturas, estilo de código, etc. Esse é um detalhe que costuma ser visto com bastante carinho, não necessariamente uma exigência, mas algo que vai te ajudar.
Veja se a linguagem que está usando também possui um guia de melhores práticas e se atenha a elas. Deixe seu código legível, use terminologias com consistência, escolha bons nomes para classes, funções e variáveis e não escreva comentários sem necessidade.
Bom, é isso. Espero que seja de alguma ajuda. Se quiserem deixar mais dicas aqui nos comentários ou tirar alguma dúvida, o espaço é nosso!
Até a próxima!
Top comments (0)