De um simples teste à um desafio pessoal
Post publicado em 19/02/2018 16:46 Última atualização em 23/02/2018 17:22
É comum que empresas apliquem testes em seus processos seletivos. Já participei de vários, muitas vezes apenas por curiosidade e nas experiências que tive presenciei 3 padrões: 1) Teste lógico; 2) Teste abusivo e 3) Teste de conhecimento real.
Teste lógico
O teste lógico particularmente não gosto, colocam trocentas questões de algoritmos que aprendemos na faculdade e, como no meu caso, nunca mais usamos. No último que fiz assim, passei 2 dias somente estudando o algoritmo. Após isso, tentei o aplicar sem sucesso em uma das 15 questões do teste. As demais questões eram bem semelhantes, tendo uma ou outra um toque de algo mais comercial. O prazo: 3 dias. Obviamente que no segundo dia eu nem me importei mais em terminar, fiz as mais "comerciais" e deixei as de nível acadêmico de lado. Eu me pergunto: Será que os testes eram realmente válidos para a empresa? Os mesmos exploravam, em suas maiorias, algoritmos complexos, que não vejo aplicação fora do mundo acadêmico. Detalhe, que nunca me inscrevi em uma oportunidade para trabalhar com pesquisa ou qualquer área acadêmica. Sempre foco em mercado. Uma das empresas que me mandou um teste deste era uma agência especializada em WordPress.Teste abusivo
O teste abusivo é quando a empresa tem um problema pontual pra resolver e lança este em forma de desafio. Um que recebi, veio o UML, um PDF de especificações, a modelagem do banco e um pdf chamado "problema.pdf". No email o aplicador do teste dizia mais ou menos assim: "Leia toda a documentação para entender o que deveria estar fazendo e foque em resolver o que está descrito no arquivo "problema.pdf". Utilizamos o Codeigniter, com isso, o seu código deve estar com base no mesmo para facilitar nossa avaliação. Você tem duas semanas de prazo para apresentar a solução. Ela deve estar completamente funcional, ou seja, resolvendo o problema descrito e totalmente documentada. Boa sorte!" Mandei ele praquele lugar por dois motivos: 1) pelo tom do email afirmando que a intenção era ter mão de obra gratuíta e 2) a documentação era de um sistema de um cliente da empresa. O pior de tudo, é que era uma grande software house de Curitiba que enviara tal "teste de aptidão", como ele tinha chamado no título do email.Teste de conhecimento real
Esse é o que eu sempre me sujeito a fazer. O teste é simples, te dão um cenário hipotético e dizem: "Faça o melhor que puder". Já fiz diversos assim e sempre gosto do desafio que trazem e do crescimento que proporcionam. Mesmo que você não passe no teste, o aprendizado vale a pena.Oportunidade
Desde que estou trabalhando em casa me surgiram dezenas de propostas de emprego, algumas delas eu nem chegava a obter detalhes, simplesmente agradecia ao recrutador(a) e bola pra frente. Mas semana passada tudo mudou! Vi um anúncio no Linkedin sobre contratação PJ (que é minha preferência atualmente) e entrei em contato com a recrutadora. Enviei meu currículo às 3 da madrugada e por volta de 9 da manhã ela me respondeu. Disse que gostou do currículo, que a remuneração que eu pedia estava dentro do que a empresa se propunha a pagar e me colocou em contato com o gestor da oportunidade. Após todo aquele processo padrão das empresas de alocação, fui colocado em contato com o líder de desenvolvimento da empresa na qual eu seria alocado em caso de contratação. Conversamos bem, ele tirou todas as dúvidas a respeito do meu trabalho e eu tirei todas as dúvidas a respeito da empresa. Como resumo, aparentemente o meu perfil está dentro do que a empresa final esperava e ele me solicitou um teste prático.O desafio
No mesmo dia da nossa conversa recebo um email com o link do teste no github. Acessei imediatamente para ver o tamanho do problema. Confesso que já fui com pedras nas mãos por já ter visto testes de empresas não condizentes com a real necessidade da mesma, como menciono lá no início desde post nos tipos de teste que já fiz em processos seletivos. No entanto este era algo bem dinâmico mesmo, por mais que vejo que a solução que eu e outros devs deram ao problema possa ser utilizada tranquilamente dentro da empresa, eu aceitei porque estava aí uma chance de eu elevar o meu nível.O prazo
Não foi me definido prazo, como boa prática, eu considerei 2 dias, no entanto no fim do primeiro dia eu tive de pedir mais prazo porque como principal desenvolvedor de minha empresa, tenho alguns projetos rolando e estes requerem muita atenção. Expliquei a situação e sugeri um novo prazo que foi aceito.Início dos trabalhos
Após ler e reler toda a recomendação do teste eu decidi dar uma olhada em como outros devs resolveram o mesmo problema. Ver seus erros e não os repetir. Vi dos dois mais recentes e desisti. Não pelo código estar ruim não (não estavam, eram bem escritos), simplesmente porque não achei aquilo justo. Se o fulano errou em algo, não queria me aproveitar disso para conquistar o meu. Foi então que fechei os Pull Requests do teste e comecei do extremo zero.A aplicação a ser desenvolvida
Um sistema de reserva de poltronas para eventos. Veja o screenshot do teste.
Sem framework
No teste dizia que a não utilização de framework seria um diferencial então comecei o projeto sem. Montei minha própria estrutura MVC e estava fluindo bem. Após algumas horas eu vi que tudo que era mais básico (CRUD, rotas, validação) estava demorando muito para ser construído. Eu tinha que preparar meu sistema de rotas, minha renderização de views, carregamento de controllers e models, persistir e buscar informações no banco de dados. Após cerca de umas 5h initerruptas de trabalho eu vi que meu ambiente ainda não estava redondo e passível de erros.Com framework
Foi então que sabendo do prazo do teste e com a mentalidade de entregar algo pra subir o nível eu abadonei minha reinvenção da roda e utilizei o Zend Framework 3. O escolhi, não pelo fato de já trabalhar com ele e ter bastante coisa já definida de forma reutilizável. O Escolhi porque ele, juntamente do Symfony (em minha opinião) é um exemplo de boas práticas de código. A orientação à objetos é levada à sério, a testabilidade é intrínseca do framework, o MVC é muito maduro e toda a utilização do mesmo implica em o dev saber o que está fazendo, uma vez que o ZF é um framework "burro", você que tem que dizer tudo à ele. Se algo não funciona, a culpa é exclusivamente sua!CRUD, finalmente
Após algumas horas da migração de in-house framework para o ZF3, o CRUD estava completo. Bem como todo o sistema de rotas, mensagens de sessão (flash messages), persistência, migrações e ainda um plus: com o Docker configurado redondinho para o avaliador testar quando eu der o Pull Request. Foi aí que, com os itens básicos da aplicação prontos, eu pude focar no que eu realmente quis entregar de valor.Teste Unitários
A aplicação em si é pequena, mas tem algumas regras bem interessantes. Como diferencial, a entreguei com 100% de cobertura de testes. Passei por todos os pontos da aplicação: Controllers, Entities, Forms, Services, Fixtures e até o arquivo de carregamento do módulo do ZF que eu desenvolvi.Tempo real
Era isso que eu tanto queria entregar e que se tivesse continuado com o projeto anterior (de reinventar a roda), não seria possível. Utilizei o Firebase Realtime Database para possibilitar que as pré-reservas e reservas confirmadas fossem instantaneamente visualizadas para todos os visitantes. Ao estar nos detalhes de um evento, a lista de poltronas é exibida. Não utilizei nenhum framework para isso, fiz meu próprio sistema de seleção de poltronas, sem layout bem trabalhado, nem funcionalidades desnecessárias, somente o essencial: clicar em uma poltrona e a selecionar, clicar novamente para remover a seleção.
As poltronas em vermelho escuro são as que o visitante acabou de selecionar. Após isso ele pode inserir o seu e-mail e gerar a pré-reserva.
Em cinza escuro são as poltronas pré-reservas.
Já as cinza claro são as que já foram confirmadas. Ou seja, o visitante selecionou, ficou em pré-reserva e ele confirmou a reserva.
E todas as que estão em verde é que estão disponíveis para seleção.
Funcionamento do tempo real
Estando o visitante nesta tela de detalhes de um evento, quando outro visitante faz a pré-reserva, as devidas poltronas ficam na coloração cinza escura. Assim que o visitante da pré-reserva confirma a reserva as poltronas ficam na coloração cinza claro. Em qualquer uma das situações os demais visitantes ficam impossibilitados de selecionar as mesmas poltronas. Caso um visitante X selecione uma poltrona mas o visitante Y finalize a pré-reserva antes dele, uma validação impedirá a sobrescrita. Desta forma uma poltrona somente será reservada uma única vez por evento. Na imagem abaixo é ilustrado o processo de reserva com 3 visitantes ao mesmo tempo.
O primeiro visitante (em vermelho) seleciona as poltronas 26, 27, 28, 29 e 30. Preenche seu email e clica em reservar. No exato momento os visitantes 2 e 3 tem as respectivas poltronas alteradas para pré-reserva, impossibilitando a seleção das mesmas.