Recentemente, devido ao meu trabalho, selecionei estagiários em nossa empresa. Todo mundo que se lembra de como é ser estagiário / júnior deve se lembrar de como é difícil ficar preso em um local mais ou menos normal, sem experiência, onde gastará recursos em seu treinamento. Devido ao fato de o fluxo de desenvolvedores iniciantes ser muito grande, o empregador tem a oportunidade de escolher entre esse fluxo, se não o melhor, e depois pelo menos sensato, caras promissores que valem a pena gastar tempo em treinamento para empregá-los posteriormente.
Cada empresa possui sua própria metodologia para encontrar esses candidatos. Hoje, seguimos o seguinte: executamos uma pequena tarefa de teste (cerca de uma hora de trabalho, para um desenvolvedor experiente), para a qual o conhecimento básico do java é suficiente e pedimos para colocá-lo no github. Não limitamos o tempo de execução. Em seguida, cumprindo qualitativamente a tarefa, os candidatos são convidados para uma entrevista.
Uma tarefa geralmente contém uma implementação de métodos CRUD em um arquivo através de um
menu do console com uma ou duas entidades, além da validação de alguns campos. Como exemplo, darei uma situação clássica a um usuário que precise implementar a validação de e-mail e telefone de acordo com um modelo especificado, para que seja possível inserir de 1 a 3 telefones. Há muitas respostas e há muito poucos lugares - portanto, a seleção é bastante difícil.
Começando a verificar todas as tarefas seguidas, demorou cerca de 30 minutos para testar o desempenho com o lançamento e o feedback de cada tarefa, tive que revisar a metodologia de verificação e derivar critérios para filtrar rapidamente códigos de qualidade insuficientemente insuficiente. Por exemplo, ao abrir uma solução no github, vejo que todo o código está concentrado em várias classes e empilhado em um único pacote - uma falha rápida (e os princípios do OOP?).
Muitos podem achar essa abordagem injusta, para dizer que o problema está resolvido, o código funciona, mas a vida do estagiário e do júnior é dura e impiedosa.
A esse respeito, ofereço minha lista de recomendações para concluir a tarefa de teste
- Sua decisão deve funcionar de acordo com o ToR
Siga cuidadosamente os requisitos estabelecidos nas condições para resolver o problema. Não pense sobre seus campos em entidades, não altere as condições de validação etc. e assim por diante. Isso mostra como você está atento aos detalhes, o que é muito importante para o desenvolvedor. - Verifique cuidadosamente a tarefa concluída
Concluiu a tarefa - verifique o desempenho. Primeiro, a principal funcionalidade descrita no ToR, depois adicional. Tente "interromper" seu aplicativo: marque ou insira o aplicativo adequadamente para a tarefa; se você inserir dados inválidos, os dados serão o mais semelhante possível. Lembre-se de consertar tudo o que encontrar. - Codificação
Todos os arquivos devem estar na mesma codificação, na minha opinião em UTF-8. Configure seu IDE para isso. Lembre-se, se você possui Windows, o revisor pode ter Linux, e agachamentos adicionais com codificação são uma perda de tempo para o revisor. - Não confirmar em um commit
Você precisa confirmar quando resolver seu problema, adicionar descrições claras aos commits. Se você sabe inglês, é melhor em inglês. Indica indiretamente que você não apenas fundiu a solução de outra pessoa do git, mas escreveu o código por conta própria. - Tente não mesclar as decisões de outras pessoas
Como você reivindica o máximo para junho, na maioria das vezes você ainda não tem experiência suficiente para usar o código de outra pessoa. As condições da tarefa podem variar um pouco e, quando você simplesmente copia a solução de outra pessoa, ela pode já ser um pouco inconsistente com a tarefa atual. E a tarefa deve ser concluída exatamente com a tarefa (consulte P1). - Adicionar arquivo leia-me
Adicione o arquivo readme.md à raiz do projeto. Descreva resumidamente seu aplicativo, e explique explicações adicionais para o lançamento, se necessário. Se você já tiver outras tarefas concluídas, adicione o leia-me também. Por exemplo, se estou interessado em um candidato, posso ver o outro código dele. E se você não for aqui, também poderá anexar esse código ao seu currículo. - Faça um menu conveniente
O aplicativo deve ser amigável. Lembre-se de que o tempo para verificação geralmente é limitado; portanto, pré-carregue o aplicativo com dados, adicione um método para mostrar todas as entidades (que existe nas condições). A navegação pelo menu deve ser conveniente, por exemplo, usando números. E, às vezes, eles o implementam de tal maneira que, para excluir uma entidade, você precisa inserir "Excluir" no console. No entanto, não se pode exagerar e ir além do escopo do TK. - Faça o melhor que suas habilidades permitirem.
Desde que você decidiu executar a tarefa de teste, aproxime-se da solução com o máximo retorno. Mesmo que a tarefa pareça trivial e simples, você não precisa abordar sua solução formalmente e escrever código de joelhos. E se você não for a essa empresa, terá uma solução completa no github, que é prática. - Não esqueça os princípios da OOP
Deixe que você pareça que uma pequena tarefa, não se esqueça - a tarefa é um teste e o java é principalmente uma linguagem orientada a objetos. E eles analisarão não apenas a operacionalidade do aplicativo, mas também o código. A qualidade do código é uma parte muito importante da solução . Não escreva código espaguete. Coloque tudo em classes, pacotes. Crie interfaces sempre que necessário, faça transferências para ENUM , se necessário. - Tente usar padrões de design
Uma aplicação bem-sucedida de pelo menos um padrão de design mostrará que você tem um conceito sobre padrões de design (ou não). Antes de aplicar esse ou aquele padrão - descubra qual é a ideia, como deve funcionar e por que foi inventada. Se eu vejo padrões no código, na entrevista posso fazer uma pergunta sobre o padrão aplicado. - Use recursos
Todas as mensagens exibidas para o usuário são melhor capturadas em recursos e retiradas de lá. Isso mostrará ao revisor que você sabe como trabalhar com recursos e entender para que eles são usados. As mensagens são melhor exibidas em inglês. - Lembre-se de redefinir onde equals & hashcode é
- Use os recursos java8 +, como expressões lambda, fluxos
Não esqueça que, com mais frequência, as coleções são mais convenientes que uma matriz. Se a escolha for a favor de coleções, use as coleções corretas. Você deve estar pronto na entrevista para justificar sua escolha em favor de uma coleção ou matriz específica. - Testes
Se puder, escreva testes, mas já são cinco, com algumas vantagens. Freqüentemente, entende-se que qualquer bom código geralmente é coberto em testes. Embora para a tarefa apresentada no exemplo, a ausência de testes não seja um sinal de menos, pois esse é um aplicativo de console simples para conhecer o núcleo java.
Sumário
Uma grande metade dos candidatos envia uma solução para o problema sem erros e um código sólido - unidades que passam pela seleção natural e caem na próxima rodada. Todos os artistas recebem feedback. Aqueles que escreveram um código sólido que foi lançado - um feedback pessoal, aqueles que enviaram espaguete de joelhos - são mais generalizados.
PS: Espero que meu conselho o ajude, queridos candidatos, a desempenhar melhor suas tarefas de teste e com menor probabilidade de chorar os testadores com lágrimas de sangue. Boa sorte na sua pesquisa e um bom ponto de partida!