Estava vendo um vídeo sobre como saber se uma pessoa toca bem ou mal a bateria. E já vi gente fazendo essa pergunta sobre desenvolvimento de software. E aí, como se mede se uma pessoa desenvolve software bem ou não?

Sobre o “desenvolver software”, algumas perguntas podem aparecer, como exemplo: sabe padrões de projeto? Conhece ferramentas de automação? Mais de N linguagens de programação? É especialista em alguma linguagem? Tem certificações?

Eu já pensei muito sobre isso, e vejo um padrão interessante. Na uMov.me a gente tem um teste prático para a galera fazer durante o processo de conversas. Esse processo permite viajar muito longe no código fonte. É um problema simples. E muito por isto, a gente pede que a pessoa use no máximo 1 hora do tempo para realizar o exercício. E também um foco sobre modelagem do problema e validação com testes automatizados.

Não tenho problema sobre as pessoas realizarem mais horas (na verdade tenho), mas acho que esse jogo da restrição de uma hora serve por alguns motivos:

• Não deixar a pessoa ter todo o tempo do mundo para planejar e pensar sobre a melhor solução. A restrição de tempo ajuda neste sentido.
• Ao indicar o foco em modelagem e automação, as pessoas não tem chance de tentar usar um super framework do momento ou coisa do tipo. Esse tipo de discussão a gente percebe quando conversa na entrevista, questiona sobre projetos que se participou, desafios, modelos de aprendizado de novas tecnologias e coisas assim.
• Não quero que a pessoa perca tempo demais neste processo. Já vi empresas usarem os testes de contratação para repassar trabalho de produção para quem participa. E não vejo problema algum em fazer isto, se ao final do trabalho realizado a pessoa seja remunerada. Vejo o teste como uma história de usuário em desenvolvimento, funcionando como um lembrete para conversa.

O ponto todo é que mesmo falando todo esse blá blá blá, no final do dia saber se uma pessoa desenvolve bem software ou não, na minha visão, vai se resumir em uma pergunta: essa pessoa, consegue levar em conta o contexto do problema para trabalhar a solução? Consegue atuar com abstração, reconhecimento de padrões e quebra de problemas em problemas menores?

Nota, a pessoa pode ser a melhor em uma determinada técnica, mas não necessariamente em todo momento aquela é a única pessoa técnica disponível. Ela combina com o ritmo de entrega esperado pelo cliente? É possível demonstrar avanços ao cliente, sobre o trabalho sendo realizado?

No fim, assim como o vídeo abaixo fala que o bom profissional da bateria é aquele que consegue tocar com a música e fazer parte dela, o desenvolver software bate muito parecido quando penso nisso. Se eu consigo desenvolver software tendo o contexto de negócio, restrições de tempo, financeiras e técnicas (exemplo infra), me adaptar conforme a necessidade, esse vai ser sempre um excelente diferencial.

— Daniel Wildt (faça parte do meu clube)