E aqui vou brincar um pouco sobre o que precisa ser simples. Exemplo, eu adoraria escrever textos mais curtos, mas isso não é tão simples assim.

Eu acompanho diversas ferramentas e estruturas para testar a capacidade de uma pessoa montar algoritmos usando elementos de uma linguagem de programação. E vejo pessoas que podem ser excelentes fazendo isso, mas não conseguem se manter calmas com um problema sendo relatado em produção. Ou não conseguem ter paciência para ensinar outras pessoas sobre um assunto.

Um processo seletivo deveria compor entendimento sobre algumas características das pessoas candidatas:

• Como elas aprendem, através de exemplos, livros, grupos, comunidades?
• Como elas entendem uma abstração? Um sistema de compra online por exemplo.
• Como elas reconhecem padrões? O problema que temos é mais parecido com marketplace, com site de empresa, com site de cursos?
• Como elas quebram um problema? Inclusive no caso de uma solução de programação indicar como elas testariam o problema, por exemplo usando ou sugerindo uma solução “pronta” até poder chegar em alguma demanda específica.
• E tecnicamente como elas se desenvolvem? E aí vem meu ponto de crítica principal com os testes que vejo nas empresas ainda nos dias de 2024.

E claro, antes de qualquer coisa, se financeiramente o “limite” financeiro existente é compatível com a expectativa da pessoa candidata. Pense que você tem um valor entre x e y, e a pessoa espera z. Nem faz sentido seguir falando. Explique, agradeça e mantenha o contato para futuras oportunidades.

No caso dos testes técnicos eu tenho uma prática de testes desde 2009 que funciona, e que considero bem simples.

E ela ganha uma informação importante que ganhei de uma empresa que trabalhei pelos anos de 2007-2008: lembre que toda pessoa que vai ser entrevistada pode se tornar um cliente em algum momento.

Logo, quero usar o tempo da pessoa de forma adequada e quero valorizar o tempo da pessoa.

Importante também que o teste técnico só vai para as pessoas quando se entende que queremos evoluir com a pessoa tecnicamente. Se as questões anteriores não estiverem ok, não faz sentido testar tecnicamente.

E com isso eu tenho algumas práticas nos testes técnicos:

• A pessoa candidata pode usar no máximo 1 hora para fazer o teste. E é como um exercício de coding dojo. Não estamos com a preocupação de terminar o problema. Estamos buscando entender o desafio e praticar o problema. Se a pessoa dedica dias, querendo entregar algo “perfeito”, por estar acostumada a outros processos de seleção, normalmente o processo termina. Queremos avaliar o progresso e permitir a abertura para conversa.
• A pessoa candidata pode perguntar o quanto quiser sobre o problema. Não existe limite para conversar sobre o problema e resolver questões. O importante é ter tempo de código no máximo de 1 hora ou perto disso. O pensamento é de rodar uma sessão de Coding Dojo mesmo.
• A partir do teste técnico, podemos marcar mais uma reunião / conversa para falar sobre o código e explorar as questões de padrões, abstrações e quebra de problemas. Passando por essa conversa, normalmente se vai para a parte de oferta de trabalho.
• Os problemas a serem resolvidos são baseados em problemas de Coding Dojos. E podem ser exemplos baseados em regras de negócios em princípio simples ou com simulações de códigos legados e sem teste.
• O teste técnico está validando o uso de lógica, padrões e bibliotecas básicas da linguagem escolhida. Não é necessário entregar nada de banco de dados, múltiplos serviços ou interface. Inclusive se entregar, o normal é a pessoa ser eliminada. Estes aspectos são avisados antes do processo seletivo.

Tempos depois lendo outros autores, descobri sobre restaurantes que usam como teste técnico para cozinheiros o processo de fazer omelete. O teste permite avaliar uma série de questões, das habilidades de quem cozinha. E assim nesta linha, a minha estrutura valida uma preocupação com qualidade, lógica de organização do código, como se avança no problema (commits), uso de test first ou não (tdd) e assim vai.

E quando vou avaliar o código da pessoa candidata tenho uma priorização que vai assim:

• Se eu consigo ler somente o código de testes, é o mundo perfeito. Isso já me permite convidar a pessoa para uma próxima conversa.
• Se eu preciso ler o código da lógica de negócios além do código de testes para entender o que foi feito, a preocupação já aumenta, no entendimento de como o código de teste está contando as histórias. Lembrar que esta estrutura é uma forma de documentação real das regras e das possibilidades de cenários.
• Se eu precisar executar o código para ver funcionando… ou entender como magicamente o código pode estar funcionando, fica bem complicado de querer seguir adiante na conversa. Claro, dependendo o tipo de requisito técnico da vaga, a conversa vai seguir.

Uma coisa que me importa nos processos seletivos, é que as pessoas devem sair melhores do que chegam. A equipe que está conduzindo o processo seletivo precisa conseguir aprender com a pessoa ali presente e também conseguir ensinar, apresentar o que se faz dentro do trabalho da equipe.

Mesmo que a equipe não queira seguir para oferta com a pessoa candidata, o processo é evolutivo. A pessoa pode aprender mais sobre o processo da equipe. E a equipe também vai poder aprender mais sobre necessidades que as pessoas candidatas possuem e assim o processo de contratação também melhora.

Acho que uma regra sobre o quão complicado um processo seletivo pode ser é pensar (1) se você faria o processo seletivo e (2) se as pessoas atualmente na equipe passariam no teste. Isso vai dizer muito sobre nossas preocupações ao avaliar outras pessoas e muitas vezes o quanto não pensamos na noss própria avaliação.

— Daniel Wildt

P.S.: já comentei sobre o processo de contratação de pessoas e empresas… no fim do dia, busque pertencimento!

Venha junto! Consciência de tempo, projetos paralelos e apoio no seu caminho de aprendizagem, através do projeto A Filosofia da Tranquilidade! Olha também a newsletter e projetos do agora.