Seqüência (não programada) deste post. Este é um desvio (não previsto) da série "Gerenciando o Trabalho Criativo" que está sendo desenvolvida no Finito.

Hard skills - as habilidades técnicas de um candidato - são, teoricamente, de fácil avaliação. Eu escrevi na parte anterior que o candidato é dispensado de testes dependendo dos diplomas e certificações que ele apresentar. O que mais precisaria provar um desenvolvedor que tem, por exemplo, um certificado de 'Arquiteto Java' assinado pela Sun?

Se todos os passos anteriores foram realizados, "nada" é a resposta. O que não significa, como veremos logo abaixo, que a(o) cara já pode se considerar contratado. É importante deixar claro para o candidato que hard skills atestados são um "plus", mas não dão garantia nenhuma de admissão.

Mas vamos supor que o candidato em questão não é "certificado", ou não possui certificados ou diplomas suficientes. Suficientes para garantir que ele é indicado para determinado cargo. O cara escreveu no currículo seu Objetivo - se candidatou para aquela vaga. Tem empresa por aí que nem chama o cara para um bate-papo caso ele não tenha preencha alguns requisitos. Tem sua lógica, mas acho que as empresas que agem assim perdem belas oportunidades de conhecer gente interessante. Afinal, mesmo ciente das restrições aquela pessoa se candidatou para aquela vaga. Se o seu currículo atesta que ele já assumiu aquele perfil em outros projetos, por que eliminá-lo do processo seletivo? É outra infeliz idiotice de alguns deptos de RH que existem por aí.

Oras, se uma pessoa consegue assumir determinadas responsabilidades sem nunca ter recebido uma educação formal para aquilo, ela deveria merecer, no mínimo, um pouco de curiosidade. As empresas buscam cada vez mais profissionais que tenham boa capacidade de aprendizado. Mas ao mesmo tempo eliminam a possibilidade de contratar "auto-didatas de verdade"! Sei que é um aspecto um tanto polêmico dos processo de formação de equipes. Sei também que tem muito picareta por aí. Mas na nossa área (TI), que só agora ameaça algum tipo de formalização, algumas exigências são míopes. Ainda mais quando tratamos de projetos que vão exigir altas doses de criatividade - leia-se: capacidade de aprendizado e assimilação de informações.

Voltando ao ponto: nosso candidato diz ter certas 'habilidades duras' mas não apresentou nenhuma 'prova' (certificado ou diploma). Por desconfortável que seja, é recomendável que ele passe por um pequeno teste. Pequeno mesmo. Independente da disciplina, sabemos que 4 ou 5 questões bem formuladas são suficientes para garantir se um candidato domina ou não aquele tema. Se estou avaliando um Analista de Sistemas que deve dominar a linguagem UML, por exemplo, peço que ele desenvolva 2 ou 3 diagramas fundamentais a partir de um determinado problema/solução. Complemento o teste pedindo que ele corrija um diagrama de classes, diretamente relacionado com o problema tratado nos diagramas anteriormente desenvolvidos. Nada que alguém que saiba o que falou que sabe não faça em questão de 30 ou 60 minutos. Uso o mesmo modelo (4-5 questões inter-relacionadas) para todo tipo de teste: SQL, Java, .Net etc.

A primeira questão vale 1 ponto, a segunda 2 e assim por diante até 5. Portanto, cada questão representa um grau de dificuldade maior em relação à anterior. O candidato que não conseguir somar 10 pontos (de um total de 15), está com sérios problemas. Mas não pode ser automaticamente eliminado do processo de seleção. Devemos excluir apenas aqueles que não conseguiram somar 6 pontos. Alguma coisa muito errada aconteceu no processo de seleção dos currículos. Ou na sua elaboração, o que pode ser indicativo de algo ainda mais grave. Mas, neste momento, deixa de ser um problema nosso.

Vamos relembrar algumas coisas: no momento em que os testes são aplicados estão acontecendo, simultaneamente, uma dinâmica e uma série de entrevistas individuais. Como foi colocado na 2ª parte desta série, estamos lidando com algo entre 6 e 10 candidatos. A aplicação do teste não exige acompanhamento de ninguém. O candidato só precisa de uma sala, papel e caneta. Ops... podemos trocar papel e caneta por um micro. Sem prejuízo para o processo. Ops 2: desde que o micro não esteja conectado na Internet, né? Como sou um tanto jurássico, ainda prefiro papel e caneta.

Durante o processo (que é um tanto cansativo), é praticamente impossível tirar conclusões. Não pode ser nosso objetivo sair desta 'maratona' de avaliações com uma equipe formada. Como eu já coloquei anteriormente, o mais importante aqui é ouvir e observar. Ao final do processo devemos ter informações suficientes para apoiar nosso 3º e último "filtro". Na próxima semana a gente conversa sobre ele.