Dicas para teste técnico com Unity #1

Dicas para teste técnico com Unity #1

Parte do meu trabalho na Aquiris é avaliar testes e realizar entrevistas técnicas com candidatos. Nos últimos anos aplicando testes, percebi que existe um padrão de erros básicos que, infelizmente, são comuns até para Senior Programmers. Este será o primeiro de uma série com dicas e sugestões do que fazer e não fazer em um teste técnico, focando Unity e C#.

Quando uma empresa de jogos pede para um candidato realizar um teste técnico utilizando Unity, pode ser algo desde criar um jogo do zero, corrigir ou expandir um projeto existente. A qualidade do código também é avaliada, mas parte do teste consiste em ver o conhecimento do candidato em desenvolvimento de jogos, boas práticas, organização e conhecimento na própria engine em questão. Antes de falar de assuntos mais técnicos, vamos começar com um bem simples: como enviar o teste.

Melhores práticas para enviar o resultado de um teste técnico

Submeter o teste técnico feito na Unity não é simplesmente zipar toda a pasta do projeto e enviar. Isso requer não enviar algumas pastas e arquivos, o que também é avaliado por demonstrar conhecimento da estrutura básica da Unity e boas práticas de organização do projeto. Um projeto Unity, basicamente, é composto pelas seguinte pastas:

  • Assets: Onde fica o projeto em si
  • Packages: JSON com as dependências do projeto
  • ProjectSettings: Configuração do projeto

Qualquer outra pasta além destas não é necessário adicionar, isso é o mínimo para rodar qualquer projeto Unity. Nunca inclua a pasta Library, ela não é necessária para rodar o jogo e aumenta muito o tamanho do projeto. Se um zip contém mais de 1MB, eu ja suspeito que esta pasta, desnecessária para o projeto, foi incluída.

Se você utilizar um repositório git em um servíco como o GitHub (recomendo), na criação do repositório é possível escolher iniciar o repositório com um arquivo .gitignore com a configuração da Unity para ignorar qualquer arquivo e pasta desnecessária.

Outras recomendações são sempre criar o repositório como privado, já que é um teste técnico para uma vaga, e marcar a opção de adicionar o arquivo README. Neste arquivo inclua toda e qualquer informação relevante sobre o projeto, como rodar o jogo e detalhes que sejam relevantes para o teste técnico. Use este arquivo para documentar o que for necessério, assim todas informações ficarão junto ao projeto/repositório, e não perdidas em um arquivo externo ou em um e-mail.

Configurando o repositório corretamente, além de facilitar o seu desenvolvimento, vai simplificar a submissão, pois você precisa apenas baixá-lo como zip e enviar. Isso é importante, envie como zip. Quem vai revisar o teste técnico pode estar usando um macOS e não precisa ser obrigado a baixar um app pra descompactar rar ou outro formato diferente.

Por fim, após ter o seu arquivo zip enxuto, envie por e-mail e compartilhe através do Google Drive ou similares, assim a pessoa que receber o seu teste técnico vai ter mais de uma maneira de baixá-lo caso tenha algum problema. Enviar o resultado é uma tarefa simples, mas você ganhará pontos em se preocupar com estes detalhes.

Por mais que o tempo para fazer o teste técnico seja curto, você não levará mais do que alguns minutos para configurar o projeto e deixar tudo pronto para uma submissão tranquila, então falta de tempo não é desculpa para enviar o resultado do teste de qualquer jeito.

Gostou dessa dica? Comente abaixo compartilhando sua experiência realizando testes técnicos para vagas em desenvolvmento de jogos. No próximo post vou abortar um erro comum relacionado a programação e uso das APIs da Unity.

comments powered by Disqus