Este texto é continuação natural deste outro texto. Depois de alguns meses realizando entrevistas de emprego com pessoas espalhadas pelo mundo, consegui definir um bom processo de testes para medir o conhecimentos dos seus candidatos.
Bons métodos começam com as perguntas certas. A seguir proporei três.
O que queremos medir ao escolher um candidato?
Essa eu diria que é a pergunta mais importante. Também acho importante dizer ao candidato como a dinâmica com ele funciona, qual o objetivo dela, o que se quer medir. Acho muito bom que o candidato entenda a intenção da empresa, o que deixa as coisas muito mais transparentes. Transparência é a primeira grande virtude de uma empresa, porque mantém todos no maior nível de honestidade possível.
Então, o que eu meço num candidato? Basicamente:
- Sua capacidade de resolver um problema dentro da linguagem e frameworks escolhidos. Testar genericamente "capacidade de resolver problemas" é idiota e desrespeitoso com o candidato, que não vem para a entrevista preparado para isso. Se a ideia é testar o candidato em pseudocódigo, use um problema relacionado com o dia a dia do trabalho ou algo que possa ser resolvido pela maioria dos programadores em uma hora. Lógica de xadrez ou qualquer outro jogo de tabuleiro não é algo que se resolva em uma hora, pelo menos não pela média dos programadores que conheço;
- Sua capacidade de se adaptar a uma situação em que ele não conhece muito bem, como usar uma nova biblioteca, por exemplo. De novo, dentro da linguagem e frameworks escolhidos;
- Sua postura profissional ao comunicar um problema que encontrou ou uma solução que pretende aplicar para resolver, ou ainda como se comporta ao pedir ajuda. Não há qualquer problema em não conhecer como uma coisa funciona ou não saber um conceito. A grande questão é medir como é o retorno do candidato quando ele passa a conhecer o conceito. Capacidade de assimilação é um ótimo critério a ser medido;
- Ritmo (ou rapidez), estilo de código, qualidade (aqui entra eficiência, se o código é pequeno e legível, e eficácia, ou seja, se o código resolve tudo o que foi pedido) e comportamental.
A seguir, coloco 4 propostas que só examinadores otários pedem em entrevistas. Se você já entrevistou alguém usando qualquer uma delas, melhore, ou se aposente. É um grande favor que faz ao mundo:
- Algoritmos de ordenação, ou problemas acadêmicos em geral. Há quilos de algoritmos de ordenação na Internet, refinados até o último caracter de código. Se você está com saudade da faculdade, por favor, volte para ela. Você usa menos de 40% do que aprendeu na faculdade no seu dia-a-dia;
- Quiz. De novo, a Internet é o melhor lugar para perguntas e respostas como essas. Se o candidato sabe o que é uma coleção imutável, uma classe abstrata ou a definição canônica de polimorfismo, isso não faz ele o candidato mais indicado para a posição: apenas que ele é capaz de memorizar muitos conceitos do Google. Aplicá-los é outra coisa. A única ressalva que faço aqui é se a pergunta é relativa a alguma coisa do dia-a-dia. Vinculado a isso, é razoável e justo pedir um exemplo em código;
- Um problema de quatro horas para resolver em uma. Na boa, se você faz isso, você é um babaca. Irremediavelmente. Pior ainda é se você espera que "o candidato de fato não consiga terminar", porque tem aquela esperança de achar um grande talento numa massa de candidatos. Você é apenas sádico e imbecil. Pessoas em ambiente profissional não esperam trabalhar com metas impossíveis. Ou se você é do tipo que defende metas impossíveis, a barraca de coco verde na praia te espera;
- Um problema que você não sabe resolver. Antes de mais nada, teste a si mesmo contra o problema. Meça quanto tempo você demora. Seja honesto e use condições que você quer aplicar ao candidato, depois use mais tempo e melhore a solução. Não há qualquer problema se o candidato for melhor que você. Isso, a meu ver, é um bom sinal.
Como queremos medir e por que escolhemos os métodos que escolhemos?
Sou naturalmente contra resolver no papel ou no quadro branco. O candidato não tem a chance de testar o código. Há uma boa chance de, a rigor, o código não funcionar porque alguma coisinha mínima faltou, como um fechamento de chaves ou colchetes ou um ponto-e-vírgula. Conferência de símbolos é trabalho para uma IDE, não para o candidato.
Assim sendo, a forma mais justa e razoável de aplicar o teste é usando um Fiddle. Ao final deste texto, colocarei os que julgo melhores para isso. Um Fiddle é uma ferramenta online que é composta por um editor de texto e um compilador/interpretador em tempo real. Ou seja, o candidato escreve o código, o testa e a evolução da sua solução pode ser acompanhada ao vivo. Seus recursos são limitados, ou seja, qualquer ajuda por uma IDE não existe. A única coisa que não é possível é depurar o código. Ainda.
Se a avaliação envolve produzir uma solução com a ajuda de uma IDE, uma solução com controle remoto pode ser uma ótima alternativa, se o candidato não está presencialmente. Neste caso, recomendo as seguintes ferramentas:
"Porque eu gosto" ou "porque acho melhor" não é resposta para sua escolha de método de avaliação. Você não tem que colocar suas preferências pessoais acima do interesse da empresa, mesmo que você seja o dono dela. Se essa é sua melhor resposta, por favor, amadureça. O candidato não iria gostar nem um pouco que a avaliação é baseada num achismo seu.
Respostas boas para esta segunda pergunta são "porque fazemos uso frequente de determinadas estruturas", ou ainda "porque nossos futuros projetos serão usados com isso". Encontrando métodos de avaliação que respondam bem a uma dessas duas perguntas, você estará num ótimo caminho.
Qual a visão que queremos que o candidato tenha da empresa?
Possivelmente quase ninguém pensa nesta pergunta quando elabora uma avaliação, mas ela é importantíssima. Eu muito provavelmente indicaria amigos e colegas meus para empresas que possuem um bom método de avaliação. Jamais indicaria amigos e colegas meus para empresas com avaliações idiotas e absurdas.
Ainda que o candidato não passe, ele potencialmente pode colocar em contato com a empresa pessoas que sejam mais aptas para a vaga do que ele. Já aconteceu na empresa que fundei e em mais algumas empresas que conheci com um processo seletivo bacana.
Proposta Coding Craft
Se você gostaria de estabelecer um processo seletivo intrigante, divertido e altamente rico em informações, a Disciplina Coding Craft tem um produto para isso. Mais do que ninguém, queremos que sua empresa seja capaz de escolher o melhor candidato para suas equipes. Sobretudo, que o candidato se sinta avaliado e goste do processo. Sendo assim, dará seu melhor do início ao fim.
Treinamos e capacitamos sua equipe para a elaboração dos mecanismos de entrevistas mais apropriados para o que se deseja de um profissional. Este serviço de consultoria tem um preço fixo e é feita em três etapas: instrução, implementação e teste de dinâmica. Pode envolver até três profissionais da sua empresa.
Investimento: R$600. Há um pequeno livro que acompanha a consultoria, no qual explico o processo mais a fundo.
Interessou? Se manifeste por mensagem aqui, me procure no Twitter, no Facebook ou LinkedIn.
Fiddles Recomendados
- C#: DotNetFiddle;
- JavaScript: JSFiddle;
- Java: Repl.it;
- Python: Repl.it, tendo versão para o Python 2;
- Ruby: Repl.it;
- SQL: SQLFiddle;
- PHP: Repl.it.