luizhdteixeira / seja-um-guia-back

Instruções e detalhes sobre ser um Backend Engineer no Guiabolso

Home Page:https://jobs.kenoby.com/guiabolso

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Back-end Engineer no Guiabolso

Por favor, leia cada parágrafo atentamente. Todos são importantes

Aqui no Guiabolso trabalhamos em times. Nosso time é multidisciplinar, com foco no produto e na evolução tecnológica dos nossos sistemas.

Em um ambiente descontraído, prezamos pela qualidade e participação ativa dos desenvolvedores na construção da nossa plataforma. Temos um carinho especial pelo usuário, direcionando nossas decisões pela experiência e fazendo constantes ajustes para alinhar os nossos sistemas com as necessidades do mercado.

Hoje, trabalhamos com alguns grandes produtos:

  • Controle financeiro: uma ferramenta para gerenciamento de finanças pessoais, em um aplicativo, que se integra automaticamente com sua conta bancária (use e veja ;));
  • Crédito pessoal: canais de aquisição para crédito pessoal, com foco em ajudar o nosso usuário a sair daquela situação chata com o cartão ou o cheque especial;
  • GuiaBolso Connect: uma plataforma de inteligência de dados que conecta pessoas e empresas com o intuito de viabilizar negócios.

No Back-end nós temos todo o ecossistema de microserviços em nuvem na AWS. Discutimos constantemente as tecnologias que usamos e como melhorar a experiência para os nossos usuários e clientes, bem como um trabalho muito próximo com a equipe de design e produto. Dê uma olhada em como está nosso Tech-Radar, atualmente.

Gostou de tudo que está aí em cima? Então vem pra cá!!!

Você quer trabalhar no Guiabolso? Vamos te ajudar!

Para você, back-end engineer (que é um desenvolvedor de software e não um codador batedor de tecla), daremos o caminho das pedras.

Temos um processo seletivo que é dividido em algumas etapas, que não necessariamente seguem essa ordem:

  • O desafio técnico (descrito nesse repositório);
  • Um teste técnico em pair programming;
  • Uma conversa com nossa master blaster equipe técnica, pra fazer um fit cultural;
  • Conversa com o Time de Pessoas.

Qual o tal desafio técnico?

Estamos procurando profissionais que estejam bem familiarizados com a stack que estamos utilizando.

Pensamos em um desafio imaginando um ecossistema que ajude a testar as nossas funcionalidades, tanto de front quanto as integrações.

Desafio

Imagina que você está construindo uma API que vai servir de mock para um serviço que já existe.

Nós vamos testar o seu desafio apontando esse serviço que vai validar contrato e regra de negócio.

Se alguma das regras não estiver respeitada, seu desafio será negado.

  • Você vai criar uma API de transações que vamos usar como mock
  • Essa API deve ser uma API HTTP
  • Queremos que essa API devolva um JSON conforme um contrato específico
  • Esse código, por ser um mock, não pode usar recursos externos ao código (Por ex.: banco de dados em memória, banco hospedado, memcached, etc)

O desafio deve ser resolvido sem o uso de nenhuma biblioteca de terceiros (com exceção do server neh?!)

Regras de negócio

Requisição:

  • a requisição será um GET
  • a requisição deve respeitar o formato [GET] /<id>/transacoes/<ano>/<mes>
  • os parâmetros <id>, <ano> e <mês> são o conjunto de dados

Transação:

  • dado um conjunto de dados, deve ser retornada uma lista de transações
  • cada transação deve seguir o contrato de transação
  • a lista de transações deve ter um total de transações igual ao mês, multiplicado pelo primeiro dígito do id. Ex.: id 2995, mês 7, 2 * 7 = 14 transações na lista
  • dado dois conjuntos de dados iguais, as respostas devem ser as mesmas
  • isso significa que, para um mesmo id, mês e ano, deve ser retornada a mesma lista

Id:

  • o id de usuário é um número inteiro de 1.000 a 100.000

Descrição:

  • cada transação deve ter descrição aleatória legível
  • vocês devem criar a lógica para gerar essa descrição aleatória legível
  • a descrição deve ter o tipo string
  • essa descrição aleatória legível deve ser legível por humanos, isso significa que YhCekEr13RH não é válido, enquanto chaconapotalo pocanoçale é válido
  • cada descrição deve ter no mínimo 10 caracteres
  • cada descrição não pode superar 60 caracteres

Valor:

  • cada transação deve ter um valor baseado no id do usuário, no índice da transação e no mês
  • o valor da transação deve ser representado por um número inteiro (reais sem centavos)
  • o valor da transação deve estar entre -9.999.999 e 9.999.999, inclusive

Data:

  • cada transação deve ter uma data aleatória
  • o campo data deve ter o formato timestamp
  • o campo data deve ter o tipo long
  • a data aleatória deve estar dentro do range de ano e mês dados

Tratamento de erro de input:

  • utilize os status HTTP para representar os casos de exceção nas validações
  • além do status, deve ser respondido o motivo do erro

Contrato

Transação

[GET] /<id>/transacoes/<ano>/<mes>

Content-type: application/json

[
  {
     "descricao": "string(10, 120)"
     "data": "long(timestamp)"
     "valor": "integer(-9.999.999, 9.999.999)"
  }  
]

Quais são os requisitos?

Para tanto, você deverá construir uma aplicação com:

  • Gradle (pois usamos aqui e configurar o gradle é um passo importante no dia a dia)
  • Java 8+ ou Kotlin (pois é nossa stack principal)

P.S.: lembre-se, este é um desafio de backend. O resultado, qualidade e performance também serão levados em conta. Se quiser, use um framework, mas não esqueça que a primeira impressão conta.

Como entrego?

Você nos envia um e-mail para backmonstrao[arroba]guiabolso[ponto]com[ponto]br contendo:

  • Seu nome completo;

  • Seu telefone para contato;

  • Seu LinkedIn (se tiver);

  • Observações e comentários sobre o seu código que sejam interessantes apontar;

  • Onde você achou esse repositório ("Fulaninho me indicou", "Vi no grupo X", "Tive um sonho consciente...", etc);

  • Seu código ou URL do repositório;

  • URL do seu sistema rodando (caso tenha hospedado no heroku, por ex) opcional

Usando um VCS online (Git, Mercurial, SVN...)

Cuide do repositório que vai mandar. Crie um readme.md, dê um nome semântico, zele pelo conteúdo que vai entregar. Lembre-se, esse desafio é um resumo de como você trabalha.

Você pode usar o github, o bitbucket, o gitlab ou qualquer alternativa do gênero.

Mas eu estou empregado e não posso deixar isso público ou não vou usar github :(

Se não quiser abrir o código fonte em um repositório, nos envie compactado em Zip.

Pontos de avaliação

Veja, esse teste, além de um desafio, é uma forma de explorar e expressar sua desenvoltura com a plataforma backend. O foco da avaliação é a sua familiaridade com o desenvolvimenteo, lógica e boas práticas, lembrando que há um caráter seletivo.

Nesse sentido, alguns pontos que devem ser observados:

  • Seu código deve compilar e rodar.
  • As respostas devem respeitar o contrato.
  • Seu código deve passar no nosso validador.
  • Arquitetura é um combinado. Defina qual é a que você quer serguir, respeite a arquitetura escolhida e seja consistente.
  • Como você organiza seus arquivos, métodos, nomeia variáveis, lida com o seu código como um todo são outros pontos observados. Seja cuidadoso, utilize boas práticas e padrões.
  • Seja consistente. Se escolher um approach mais OO, siga até o final, assim como se usar Spring, use os recursos dele.
  • Siga as boas práticas da ferramenta escolhida, bem como respeite as boas práticas de código geral (um validador de qualidade pode te ajudar).
  • Codifique como você gostaria de trabalhar.
  • Imagine que esse código pode receber mais features, então não faça uma bagunça só para entregar.
  • Leia todo o desafio, 3 vezes, até o final e escreva "BATATA" no final do seu e-mail de entrega. E sim, isso é uma instrução idiota mas garante que você leu tudo até aqui.

O que provavelmente vamos olhar

  • Organização de pastas
  • Bibliotecas importadas
  • Nome dos arquivos
  • Separação de responsabilidades
  • Lógica e a criatividade na solução
  • Códigos HTTP escolhidos
  • Headers retornados
  • Performance

Vamos ler seu código, rodar, rodar nosso validador, apreciar o resultado, olhar, testar casos novos.

Invista o tempo necessário para fazer um desafio que demonstre o resumo das suas capacidades técnicas. Faça com carinho.

  • Se não entendeu algo, pergunte
  • Se não consegue fazer algo, explique no e-mail
  • Se precisa de mais tempo, peça

Muito provavelmente não vamos olhar seu currículo, nem vamos usar seu LinkedIn como critério de aprovação nessa etapa. Queremos seu código bem feito e funcionando!

Obrigado e boa sorte!

Licença

versão 13-11-2020

Licença Creative Commons
Este repositório, texto, códigos e forks estão licenciados com uma Licença Creative Commons Atribuição 3.0 Brasil.

As imagens e o nome Guiabolso são de propriedade do Guiabolso. Todos os direitos reservados (c) 2020.

About

Instruções e detalhes sobre ser um Backend Engineer no Guiabolso

https://jobs.kenoby.com/guiabolso