Parte do nosso trabalho e propósito aqui na Gama é encontrar e recrutar pessoas que tenham talento, prepará-las para as empresas parceiras treinando-as para que já cheguem o mais capacitadas o possível para os novos desafios. Mas para isso precisamos primeiro criar um critério de seleção que seja o mais rápido e fácil levando em consideração volume e tempo que nossos parceiros têm para preencher suas vagas em suas empresas. A forma para conseguir isso é através de uma prova que meça habilidades e competências técnicas.
Para isso tivemos uma ideia e sua tarefa é construir uma API nossa aplicação chamada ATS (Applicant Tracking System), mas não se preocupe em desenvolver todas as etapas citadas na imagem acima, vamos focar apenas na etapa de testes online.
Aqui na Gama, utilizamos nossa stack baseada em javascript, para ser mais preciso, recomendamos fortemente a adoção das seguintes tecnologias:
- Javascript (Nodejs)
- Banco dados Relacional (SQL) - Postgres
Quer mandar bem demais no teste ? Então te desafio a construir a aplicação utilizando:
- Typescript
- Nest.js
- TypeORM
- Swagger (OpenAPI)
Vamos te dar um help e já te entregar uma sugestão de modelagem de banco de dados, a estrutura é simples mas pode ficar bem complexa se você vacilar nas regras de negócio.
https://dbdiagram.io/d/620ed328485e433543d26b9d
Queremos avaliar sua capacidade de desenvolver e documentar um back-end para uma aplicação. Serão avaliados:
- Qualidade de escrita e de execução de código fonte;
- Quais ferramentas foram utilizadas, como e por quê foram escolhidas;
- Seu conhecimento em banco de dados
- Seu conhecimento em construção de APIs seguindo os padrões RESTful;
- Capacidade de comprometimento com o próprio desafio;
- Documentação da API (planejamento para que outros desenvolvedores possam usar e integrar ao front-end)
- Uma aplicação contendo uma API real simples, sem autenticação, que atenda os requisitos descritos abaixo, fazendo requisições à um banco de dados para persistência;
- README.md contendo informações básicas sobre o projeto e um guia para que outro desenvolvedor possa montar o mesmo ambiente e executá-lo em sua máquina.
Aqui vamos além dos itens mínimos de requisitos, mas darão uma boa qualidade na sua entrega se você resolver segui-los. Então recomendamos fortemente que se dedique de verdade!
- Uso de quaisquer ferramentas que facilitem seu trabalho
- Migrations ou Scripts para configuração do banco de dados utilizado
- Testes Unitários
- Testes e2e
- Autenticação/Autorização com OAuth e/ou JWT
- Deploy em cloud publica (heroku ou netlify são boas opções do mercado e gratuitas)
- ESLint e Prettier
- Documentação dos endpoints (recomendamos fortemente o uso do Swagger)
- Conteinerização da aplicação com instruções (reocmendamos docker e docker-compose)
- Sugestões sobre esse desafio embasadas em melhorias ou mudanças do escopo
Aqui temos uma lista do que imaginamos ser as rotas ideais para sua aplicação, mas sinta-se o mais confortável o possível para propor mudanças
Devemos ter uma rota para listar todas as Provas Técnicas
disponíveis
GET /exams
O corpo da requisição deve conter as informações de uma Prova Técnica
válida. A resposta, em caso de sucesso, deve ser o mesmo objeto, com seu novo ID gerado.
POST /applications
Content-Type: application/json
Exemplo: body request
{
"user": "c9f500c3-7115-4b97-9d2b-7128002dfdfd",
"exam": "891d8157-127f-46b3-b1ed-d77fe731e706"
}
Quem for consumir sua api pode fazer a busca de Inscrições por Usuário
GET /applications/{{user_id}}
Importante destacar que apenas uma Prova Técnica
com suas Questões
apenas pode ser retornada após
GET /exams/{{id}}
GET /exams/{{exam_id}}/questions/{{question_id}}
POST /exams/{{exam_id}}/question/{{question_id}}
Content-Type: application/json
Exemplo: body request
{
"application": "c9f500c3-7115-4b97-9d2b-7128002dfdfd",
"alternative": "a99c9178-5d21-41ce-ac90-b51304b40855"
}
Uma vez que a Prova Técnica
as respostas dadas para as Questões
não podem mais ser alteradas. Atente-se que está implementação é opcional
POST /applications/{{id}}/finish
Content-Type: application/json
Exemplo: body request
{
"user": "c9f500c3-7115-4b97-9d2b-7128002dfdfd",
"submission": "0ced2afc-418e-47b4-a16e-3efa8b7d4373"
}
O Score é calculado após a conclusão de uma prova. Atente-se que está implementação é opcional
GET /applications/{{id}}/score
Se você chegou até aqui, vamos te ajudar te dando o pulo do gato... Você tem autonomia para fazer qualquer modificação até agora pelo que foi apresentado. Sejam as tecnologias, os frameworks, as bibliotecas, a modelagem do banco de dados... tudo! Mas vamos querer entender como sua cabeça funciona e para isso você tem a responsabilidade sobre essa tomada de decisão.. como diz o ditado: então para cada escolha, uma renúncia!
-
A API deve ser real e escrita por você. Ferramentas que criam APIs automaticamente (Loopback, json-server, etc) não são aceitas;
-
Todos os requisitos precisam ser cumpridos mesmo que você proponha alguma mudança no fluxo geral, um usuário precisa se inscrever em uma prova, responder as provas e ter seu score disponível assim que ela finalizar todas as questões disponíveis. Inclusive encorajamos demais a você encontrar formas mais inteligentes para resolver alguns dos requisitos
Suba o seu projeto para o Github e libere acesso para o usuário jcbombardelli
.
BOA SORTE E QUALQUER DÚVIDA, NÃO DEIXE DE ENTRAR EM CONTATO CONOSCO 💚 #GOGAMA