Sobre os processos de seleção em TI
O que se deve buscar e o que se deve esperar num processo seletivo
https://vidadeprogramador.com.br/2018/03/02/teste-de-admissao/
Prática consagrada
Há muitos lugares sem nenhuma maturidade no processo de seleção, em geral se valem mais pela habilidade de quem vai selecionar, o que, em se tratando de um processo conduzido por alguém técnico, normalmente o gestor, ou a pessoa de maior senioridade ou tempo de casa, pode ser uma boa coisa.
Nesses lugares em que os processos ainda não estão maduros, os melhores pelos quais passei tinham uma ação conjunta entre alguém de RH e alguém técnico.
Mas, nos locais em que a busca é algo sempre presente, há uma prática consagrada: o teste prático.
Existem empresários que se aproveitam dessa prática para conseguirem resolver, de graça, pequenas demandas internas, mas eu nunca tive o desprazer de topar um lugar assim.
Mas voltando à normalidade, há nos testes práticos características muito similares na maioria das empresas que já estão nesse nível. Esse teste consiste em, seguindo uma especificação, criar um pequeno sistema, partir do zero, e entregar.
Com isso busca-se entender o nível técnico do candidato.
Se uma pessoa é capaz de entender uma especificação, implementar com código limpo e demais boas práticas, teria-se alguém bem capacitado. Com a ajuda de uma pessoa da área de psicologia, o que em geral é o caso nos departamentos e cargos de RH, tem-se uma visão completa do candidato.
E pode-se com isso evitar muitos problemas, desde comportamentais, até mesmo, os de desalinhamento técnico.
Só que, do ponto de vista do candidato, esse teste, geralmente, diz nada a respeito de como será o trabalho. É apenas um desafio intelectual (ao menos para mim, desafios intelectuais abstratos são um porre). E para a empresa também, que não tem como perceber o candidato em ação.
Admito: é importante que se estabeleça um entendimento o mais global possível de um candidato.
O que me atormenta é a falta de orientação prática dos testes ditos práticos, pois eles não dizem nada acerca do comportamento cotidiano de um desenvolvedor.
Como seria um teste levando em conta essa rotina?
Minha prática, quando tenho a oportunidade de planejar um teste, é que ele reflita o cotidiano da empresa, especialmente no relacionamento com as diversas pessoas dentro do ambiente de trabalho.
Por exemplo, certa feita em que tive essa liberdade, o teste prático para ser administrador interno de rede foi identificar porque, numa máquina, a rede não estava funcionando. Um candidato rapidamente percebeu o cabo desconectado, o outro depois de verificar algumas coisas, pediu ajuda.
Um arrumou rapidamente, mas um era falastrão, o outro não.
Garantimos nessa situação um teste prático muito perto da realidade, mas o determinante foi que percebemos um comportamento cordial no candidato que não conseguiu, que era o mais importante no perfil desejado que construímos. E o teste prático acabou confirmando conhecimento acerca de Windows e humildade para pedir ajuda, pois para nós, tão importante quanto resolver um problema é a postura com que alguém se porta no relacionamento interpessoal.
E com as pessoas desenvolvedoras, o que se busca?
Bom relacionamento, conhecimento técnico e, penso eu, boa desenvoltura no que mais acontece dentro de uma empresa: remendar sistemas existentes.
Um teste que realmente verifica como a pessoa se comporta tecnicamente, como está seu conhecimento técnico, e sua capacidade de interação com a equipe, pode ser simplesmente resolver issues. Por mais simples que seja, resolver uma issue aberta em algum sistema opensource, ou mesmo que seja em um sistema pequeno apenas para a finalidade de testes, é muito melhor que perder uma semana escrevendo um sistema do zero que não serve pra nada.
Resolvendo uma issue e abrindo um PR, a pessoa candidata demonstra ser capaz de entender um problema, demonstra ser capaz de dizer que não entendeu, fazer os questionamentos adequados, e ainda, propor soluções fora do que é mais óbvio.
Ainda tem o benefício do processo de codereview.
Aqui penso que o melhor mesmo, é resolver uma issue e ser revisor de um PR.
Porque a revisão de PRs é uma arte. Pode ser a demonstração de desleixo, pode ser a demonstração de que a pessoa é propensa a rasgar dinheiro, tornando esse processo infinito ao concentrar-se em detalhes irrelevantes, e ainda, a pessoa tem que clonar repositório, fazer os testes funcionarem em sua máquina, fazer o sistema funcionar em sua máquina.
Todo esse processo é muito rico, não importa muito se uma coisa ou outra seja preciso ajuda. Aliás, importa sim, o quanto essa pessoa tenta? Ela desiste? Ela é preguiçosa e fica fazendo perguntas sem tentar nada? Ela é orgulhosa e fica tentando sem nunca pedir ajuda?
Aqui temos uma visão de como a pessoa entende, argumenta, convence, cede, enfim, como colabora. E então tem-se subsídios muito mais concretos para decidir por contratar. E também pra decidir ser contratado, pois tudo isso nos ajuda a pensar se uma empresa vale ou não à pena.