Contratação, Entrevistas e Candidatos
Contratar não é fácil. Todos que já participaram de um processo de contratação sabem disso. Falando especificamente do nosso mercado de tecnologia, eu mesmo já tive que contratar e demitir muitas pessoas. O principal problema? Existe falta de bons profissionais no mercado. E não estou falando de pouco, estou falando de uma enorme maneira.
É muito fácil hoje fazer parte do mercado de informática. Qualquer um pode dizer que é programador, analista, engenheiro. O sintoma mais comum é que quanto mais de baixa qualidade é a mão-de-obra disponível, começa a se subir os critérios na hora de filtrar os currículos. Oras, basta pedir mais qualificações, certo? Errado!
Quando o mercado passou a exigir graduação em alguma faculdade, todo mundo correu para se formar. Mas o mercado não é bobo, ao perceber isso, as faculdades criaram dezenas de programas para facilitar e conseguir atrair mais e mais gente. Agora você tem piadas do tipo como se formar em 2 anos e fazer uma pós ao mesmo tempo. Toda vez que você sobe critérios indiretos, rapidamente alguém vai encontrar uma maneira de subvertê-lo. Empresas que ainda usam critérios como faculdade, MBA, certificações, estão perdendo seu tempo.
Depois, existem as famosas entrevistas. Os candidatos filtrados pelo RH são chamados, o RH entrevista para saber se o sujeito é minimamente são, se não parece ser do tipo que vai surtar, que tem distúrbios psicológicos, enfim, que não vai dar muito problema. Daí o gerente ou responsável da área que precisa do recurso, entrevista o sujeito. E isso é um processo completamente aleatório porque na enorme maioria das vezes (eu diria quase todas) esse gerente/responsável não tem a mínima idéia do que perguntar ou na verdade nem está se importando. No final das contas é basicamente uma questão dele ir ou não com a cara de quem está entrevistando.
Ao final, um dos candidatos é aprovado e começa a trabalhar. Algumas empresas que tem muitos “colaboradores” sabem que tem 3 meses de experiência para poder mandar o recém-contratado embora, segundo a CLT. Porém, já vi muitas falharem em fazer isso. Como tem muitas pessoas às vezes existem algumas métricas e critérios para saber avaliar. Mas novamente, no final é o gerente da área que decide se manda o cara embora ou não. Mas normalmente já existem tantos outros problemas maiores para se preocupar que isso passa batido. E assim entra mais um péssimo funcionário no cabide da empresa. Quanto maior a empresa, maior esse problema.
Quer pior do que isso? A grande maioria das pessoas que diz saber programar, na realidade não tem a mínima idéia do que é ser um programador, tem sorte se souber copiar e colar trechos de códigos dos outros. Isso é uma constatação. Para alguns projetos que eu gerenciava em consultoria, já tive que olhar 100, 200 currículos para filtrar meia dúzia, e depois mandar metade embora.
A razão de ainda existir tanta gente ruim no mercado? Lei da oferta e da procura: enquanto tiver gente contratando e mantendo, eles continuam existindo. A primeira regra para toda empresa: mande embora assim que possível. Nunca segure um problema por mais tempo do que o necessário. Eu mesmo sou culpado disso, pois normalmente o problema é tão generalizado que você pensa “que bem vai fazer só eu cortar na minha equipe?”, mas isso não é desculpa. Portanto, pelo menos se for um novo contratado, use os 3 meses de experiência. Onde muitos erram é no velho problema de custo perdido. Eles pensam, “mas eu já gastei 3 meses com esse cara, vou mandar ele embora e começar tudo de novo? Talvez ainda dê para dar um ‘jeitinho’ …” e esse é o padrão para o desastre.
Currículos não significam muita coisa. Fato importante: é muito simples fazer um currículo parecer impressionante. Mais ainda: quantas empresas você já viu que checam ítem a ítem desse currículo ligando para as empresas antigas e pedindo referências? Talvez algumas até façam isso, mas eu nunca vi, especialmente se o cargo é baixo.
Entrevistas são praticamente inúteis, servem somente para ter uma primeira impressão, nada mais profundo do que isso, por isso nem adianta prolongar muito. RH filtrando currículos e gerentes fazendo a seleção, é outra bobagem, pois nenhum deles tem qualificação para realizar essa tarefa – não importa o que diz o currículo deles!
Uma Sugestão
A primeira coisa a ter em mente é: esse novo sujeito vai trabalhar com quem? Dificilmente alguém entra numa empresa de tecnologia, hoje em dia, para se enfiar num cubículo e ficar isolado – se sua empresa é assim, então o problema é mais embaixo. Ele vai precisar participar de uma equipe. Porém, essa equipe normalmente não tem controle sobre quem entra ou quem sai, é o chefe deles que sabe disso. E vocês já ouviram o velho ditado: “quem pode manda e quem tem juízo obedece”. Essa é a primeira coisa que deve ser quebrada.
O RH até pode fazer uma seleção mínima só para diminuir a quantidade de papel. No enorme montante de candidatos ruins, você poderia também pegar todos os currículos, jogar ao alto e pegar alguns deles. O processo é aleatório mesmo, portanto tanto faz o critério de filtro. Daí, quando você tiver uma meia dúzia que parece minimamente interessante, traga para fazer entrevista mas não deixe o chefe fazer isso, delegue para a equipe onde esse candidato trabalharia.
Se possível faça ele vir mais de um dia – nem sempre dá, eu sei. Mas se for possível seria bom ver o que ele tem a dizer sobre os projetos, opiniões técnicas, e até mesmo colocar a mão no código seria interessante. Digamos que você “vá com a cara” de um deles. Agora delegue à equipe para torná-lo produtivo o mais rápido possível. De preferência, em um mês, esse novo funcionário deveria trabalhar em par com todos da equipe, ainda talvez um pouco mais como co-piloto do que piloto. Ao final de um mês, converse abertamente com a equipe e veja se todos gostaram ou se tem ressalvas. Não precisa esperar 3 meses, um mês é suficiente. E isso não é uma “democracia”, se tiver um da sua equipe que não gostou dele, isso deve ser levado em consideração (talvez seja o único que tenha se interessado!)
Outra coisa importante: dê mais preferência a indicações de candidatos vindos da própria equipe e de pessoas que você já conhece. Não existe filtro melhor do que redes sociais: eu confio no meu amigo, e meu amigo confia num tal fulano, portanto há chances de conseguir gostar desse fulano muito mais do que algum estranho aleatório. Aliás, essa é a base de um bom sistema de segurança: 3 pontos de confiança. Não dá para ser seguro com menos do que isso.
Portanto, esse é o primeiro passo: delegue à equipe a responsabilidade de selecionar e aceitar ou não um novo colega entre eles, afinal são eles que vão sofrer caso esse novo contratado só faça bobagem. E mesmo que não faça bobagem, significa que você terá um peso morto que ninguém vai dar bola.
E se você já estiver nesse caminho, o próximo é mais importante: faça a própria equipe contratar seu próprio chefe! E evite avaliações de cima para baixo ou mesmo 360, faça avaliações apenas de baixo para cima primeiro, funcionário avaliando seu chefe. Mas isso é tema para outro artigo.
terça-feira, 27 de julho de 2010 -
14:26
|
Fabio Akita é um conhecido blogueiro e evangelista da comunidade Ruby on Rails e Agile. Atualmente é Gerente de Projetos pela Gonow Tecnologia. Foi Gerente de Projetos na Locaweb, onde também fez parceria na concepção da conferência anual Rails Summit (rebatizada de "RubyConf Brasil"). Já trabalhou como Brazil Rails Practice Manager para a consultoria americana Surgeworks LLC. Por mais de 5 anos foi consultor de integração e desenvolvimento no mundo SAP. Tem mais de 15 anos de experiência nas áreas de desenvolvimento de software e gestão de projetos, dá palestras em faculdades e conferências de tecnologia e gestão
Gostei muito do texto, mas tenho algumas observações a fazer:
Um mês de entrevista é inviável, irreal. Seria o ideal, mas é impossível, por vários motivos, então precisaríamos procurar outras alternativas.
Já fiz seleção de candidatos em uma empresa que trabalhei e o formato infelizmente era esse mesmo que você descreveu. Típico cenário de grandes empresas burocratonas. Sem contar o fato de que não tínhamos processo algum de avaliação, a coisa se tornava aleatória, e era muito difícil parar para fazer um, já que tínhamos as tarefas do dia-a-dia fungando no nosso cangote. Sem subsídio da empresa, é muito difícil fazer algo bem feito.
O que sempre imaginei que pudesse ser um “meio-termo” para isso seria uma espécie de avaliação, ou prova. Mas não como as provas convencionais, no papel, o que é ridículo, mas algum tipo de prova prática, botando o candidato para fazer alguma tarefa em um computador. Tenho um esboço desse escrito, mas ainda não consegui botar em prática, até porque hoje não faço mais seleção.
Sei que muita gente não gosta de prova e já vi várias pessoas dizendo que acham um absurdo, o que sinceramente não consigo entender.
Qual sua opinião sobre provas?
Não é um mês de “entrevista”. Tecnicamente ele já está trabalhando, mas é período de experiência. A melhor avaliação nunca é via prova ou coisa assim, é no dia a dia, sob a vigilância da própria equipe checando o que ele está fazendo, com mais atenção especialmente no primeiro mês. Prova escrita não prova nada. Código no repositório, que o resto da equipe consegue avaliar como “bom código” é muito melhor. Para conseguir isso, o recém-contratado precisa demonstrar que sabe conversar, que sabe entender o problema, que sabe buscar soluções, que sabe aprender a lidar com as ferramentas, até o ponto onde consegue colaborar código útil ao projeto.
Muito bom artigo, Akita! Concordo que entrevistas são superficiais em comparação com a avaliação no dia a dia feita pela equipe, mas acredito que podemos (nós técnicos, não o pessoal de RH) otimizar as entrevistas com um esforço relativamente baixo, de forma que não sejam “praticamente inúteis”.
Fazer os candidatos escrever algum código (num quadro ou papel) é uma delas. O Joel Spolsky sugere (em Smart & Gets Things Done) uma questão de recursividade e outra de ponteiros (se aplicável). Se um programador mostra através de código que compreende esses conceitos, ele geralmente possui a aptidão técnica necessária.
Uma outra coisa é apresentar problemas técnicos que o candidato provavelmente nunca resolveu e perguntar como resolveria, mas sem fornecer muitas informações. A intenção é verificar se ele faz perguntas adequadas para colher dados, se é capaz de lidar com problemas desconhecidos e propor soluções razoavelmente adequadas.
Tenho visto bons resultados com essas sugestões do Joel. E você, o que aborda em entrevistas técnicas?
Tudo isso é válido, mas meu ponto é que uma única entrevista, não importa quão técnica ela seja, jamais será suficiente até que o candidato tenha hands-on com a equipe e com os projetos de verdade. Dado que a quantidade de maus candidatos é infinitamente maior do que os bons, quanto menor for o tempo de entrevista, menos tempo você também vai perder. A entrevista é bom para isso: uma primeira impressão. Se o candidato tiver projetos open source para mostrar, melhor ainda. Na maioria dos casos não tem. Daí conversando, de programador pra programador, você mais ou menos afere um pouco dos hábitos de um programador (nunca faça um não-programador entrevistar um programador). Acho que colocar um exercício prático – e rápido – é válido para ver se o sujeito tem um mínimo de conhecimento. Às vezes não precisa nem que ele comece a escrever, só a discussão em torno de como resolver o problema já ajuda a descobrir com quem estamos lidando.
É interessante ler a opinião das pessoas da área de TIC, e respeito a todas elas pois refletem a sua realidade.
Creio que aqui foi colocado de lado o aspecto pessoa, gente mesmo, do profissional é cobrado saber lidar com muitas tecnologias diferentes, mas não é cobrado lidar com pessoas diferentes, não é cobrado lidar com pessoas de outros departamentos, sem pessoas não existe projeto, todas as pessoas possuem conhecimentos diferentes.
Quer selecionar bem um candidato para o seu grupo, coloque-se no lugar dele, quer que ele codifique dentro do padrão que você considera adequado, dê treinamento a ele, não deixe de considerar a amplitude do conhecimento extra código.
Não devemos esquecer que o pessoal do RH também faz parte do grupo da empresa e também possui responsabilidades, inclusive identificar quem é adequado para a empresa dentro e fora dela, portanto contratar pessoas considerando redes sociais é desqualificar os colegas do RH.
Saber cobrar responsabilidades profissionalmente é o que falta para as pessoas de TIC, cobre do RH uma boa contratação, cobre do seu chefe um bom planejamento para treinamento e adaptação dos novos contratados, se você é líder ou gerente passe ao departamento responsável (RH) exatamente o que você deseja do profissional, quando ele chegar gerencie o seu conhecimento.
Eis o problema, o “exatamente o que deseja”. Não dá para escrever num papel uma lista de critérios e terceirizar o filtro. Claro, coisas óbvias e macro, sem problemas, mas em última instância é mais uma questão de “feeling” do que qualquer outra coisa. Na maioria das vezes não dá sequer para tentar explicar, a pessoa apenas “encaixa”. E quem deve decidir isso, também não é o terceiro chamado “gerente”, que nada mais faz do que ter o papel de intermediário. Os afetados diretamente são as pessoas da equipe, portanto isso deve estar na alçada deles.
Sr.Akita, eu estava justamente buscando informações para a minha decisão de demitir um recém-contrato (12 dias), pois percebi nos detalhes que o mesmo não preencherá as necessidades da empresa e principalmente da equipe, hoje tive uma conversa com os meus pares e fomos unânimes. Sinto-me segura agora, afinal em 08 anos de liderança essa será a minha primeira demissão. Sempre tive como premissa avaliar sempre o esforço, a vontade de fazer, muito antes das qualidades técnicas, e infelizmene não vejo o brilho no olhar do novo contratado.