… para pessoas programadoras

Como sou programador eu procuro sempre ter uma abordagem voltada para solução de problemas. Mesmo quando o problema que se apresenta não seja solucionável com software.

No momento que a empresa onde eu trabalhava precisou aumentar a equipe fiquei de frente com alguns problemas importantes: como encontrar e contratar profissionais com o perfil que a gente precisava? Qual o perfil de profissional que a gente precisava?

A empresa estava construindo os alicerces de uma plataforma de software. A pequena equipe que já trabalhava com a gente era muito qualificada e experiente. Também valorizavam a qualidade das práticas e processos de desenvolvimento para entregar sempre o melhor resultado.

Então a gente tinha que contratar programadores que prezam a qualidade das soluções desenvolvidas e fazer essas contratações em ritmo bom.

Perceberam que os dois requisitos podem soar contraditórios? Qualidade ou velocidade? Ambos!… Nessas situação a gente travou um limiar no aspecto qualidade e criou um processo que pudesse agilizar e uniformizar todas as contratações.

Processos & Práticas

Nesse artigo eu vou descrever o processo de seleção que construi, junto com minha equipe e o departamento de Recursos Humanos da empresa. Essa é a versão do processo que estava em uso até o momento que eu deixei a empresa. Não sei se eles ainda estão usando mas eu suspeito que não.

O processo não é perfeito e, como disse, prioriza um perfil de profissional bastante específico: profissionais apaixonados por programação que querem trabalhar em uma equipe que desenvolve software. São profissionais que priorizam muita qualidade e boas práticas.

Falei esse monte de coisas aqui em cima mas o que eu realmente queria fazer era criar o ambiente perfeito para o programador que existe em mim amaria trabalhar. ?

Esse processo não é muito eficaz para empresas que precisam crescer o seu time de desenvolvimento de forma muito rápida ou que estejam em um estágio onde o mais importante é criar soluções rápidas para os problemas que se apresentam. E vocês verão que ele é bem longo.

O processo todo é dividido em 8 fases. Cada prospecto/candidato tinha um card no JIRA que tinha algumas customizações que exigia o preenchimento de certas informações fossem feitas antes de se avançar para a próxima fase. Cada fase do processo era representado por uma coluna no JIRA.

Aviso para candidatos

Algumas informações desse artigo podem ser muito valiosas para vocês também. Entender como um desse processos funciona te permite fazer engenharia reversa e hackear o sistema. Espero que vocês façam bom uso desse material.

Etapas do processo

Etapa 0: Captação

Antigamente as empresas descreviam as vagas com seus requisitos, colocavam em alguns forums e sites de emprego e ficavam esperando a enxurada de candidatos. Aí era só jogar todos esse candidatos nos diversos filtros, avaliar eles e escolher o mais adequado entre todos os finalistas. Essa abordagem passiva para contratar programadores não funciona mais tão bem.

Hoje é muito difícil contratar bons programadores. Contratar bons programadores com experiência está se tornando quase impossível. Não sei se isso vai ser assim pra sempre mas já é uma realidade faz vários anos.

Por conta disso a abordagem passiva para buscar candidatos precisa ser modificada e as empresas, agora, precisam ser pró-ativos na captação de bons prospectos/candidatos (leads). Uma vez que você encontra esses candidatos devemos iniciar o processo de “venda” da vaga para ele.

Na empresa onde eu trabalhava a gente tinha diversas técnicas de captação. Eu vivia me embrenhando em redes sociais e grupos de desenvolvimento de software em busca de projetos bacanas e sempre que esbarrava em um programador interessante eu criava um card no JIRA com as referências desse prospecto.

A empresa também incentivava (e financiava) os programadores da nossa equipe a participar de eventos de tecnologia e levar a palav… digo… apresentar as oportunidades que trabalho que a gente tinha aberto. A gente também tinha um orçamento para patrocinar esses eventos e poder ter uma presença mais marcante nessas ocasiões.

A equipe de RH também ajudava muito na captação buscando leads em plataformas como Linkedin, Stackoverflow, etc.

Eu fiz um breve “treinamento” (uma reunião rápida pra passar umas dicas) com a equipe de recrutadores explicando como abordar esse leads sem soar muito intrusivos. Ensinando a não ter nenhuma abordagem massiva (spam, mail marketing, etc) e sempre abordar cada lead depois de ter lido perfil e se informado sobre o possível candidato. Também expliquei como se comportar em comunidades de FLOSS e nunca postar uma vaga sem antes se apresentar e perguntar quais são as regras daquele grupo para anunciar vagas abertas.

As descrições das vagas precisam “vender o produto”. Então elas precisam ser muito completas e contar até mesmo detalhes das tecnologias, processos, benefícios, etc. Apesar disso, nessa empresa, a gente não anunciava a faixa salarial e sempre dávamos respostas vagas como ‘acima da média de mercado praticadas no Glassdoor’. Não consegui convencer todo mundo sobre a importância de divulgar a faixa salarial. Mas esse assunto é complicado o suficiente e provavelmente merece um artigo só sobre ele.

O processo todo deveria ter como alicerce o respeito total com os candidatos. Respeito com a pessoa, com o tempo da pessoa, e com a dedicação dela ao processo.

Etapa 1: Entrevista Inicial

Com o contato do prospecto e o estudo prévio dele já podemos entrar em contato e marcar a entrevista preliminar caso ele tenha interesse em nos atender.

O dia e horário que você marcar essa entrevista já vai dizer um pouco sobre o ritmo de trabalho da empresa. Então fique esperto com entrevistas em horários bizarros como fins-de-semana ou tarde da noite. A menos que o candidato peça um horário diferente tente falar com ele em horário comercial.

Se ele topou envie o convite por e-mail e marque em sua agenda e JAMAIS se atrase para essa entrevista. É crucial que você respeite o candidato desde o primeiro contato. Lembre que é a sua empresa que precisa dele.

Essa parte do processo é a que vou detalhar menos porque ela era conduzida majoritariamente pelas psicólogas do RH da empresa que, por questões de ética profissional, não podiam detalhar o que faziam. Recomendo muito usar profissionais de psicologia no processo de recrutamento das empresas. A quantidade de informações úteis que eles conseguem trazer para o processo é incrível.

Na entrevista inicial uma das psicólogas iniciava o contato online com o candidato, fazia algumas perguntas para ver se o candidato se encaixava no perfil de profissional que a empresa dava preferência e começava algumas anotações sobre pontos de atenção para serem explorados nas próximas etapas.

Um exemplo: a empresa tem trabalho remoto e o candidato diz que nunca trabalhou remoto antes. Isso obviamente não desclassifica o candidato mas prepara os avaliadores das próximas etapas para ver se o candidato consegue se desenrolar bem nessa modalidade de trabalho.

Aliás, essa etapa dificilmente ‘desclassificava’ alguém. Ela era muito mais útil para fornecer subsídios para os avaliadores. Em alguns raros casos a recrutadora era desrespeitada durante essa entrevista e, nestes casos, obviamente, o candidato caia por ali mesmo.

Uma vez que a psicóloga estava confortável pra enviar o candidato para a próxima fase ela já apresentava o teste técnico (próxima fase), explicava como proceder com o teste e já deixava um contato para eventuais dúvidas. O teste não tinha prazo máximo pra ser feito mas a psicóloga contactava o candidato regularmente (semanalmente) pra perguntar se estava tudo ok com o teste. Algumas vezes os candidatos abortavam o processo e não avisavam nada pra gente e essas ligações serviam pra gente mover o card desse candidato pra coluna de finalização.

Uma observação importante: a recrutadora também era a coordenadora do processo de cada candidato. Ela que “batia o bumbo” para que os processos andassem e os prazos fossem cumpridos. Ela também centralizava a comunicação com o candidato para garantir que ela estava dentro dos padrões.

Etapa 2: Teste Técnico (Candidato)

Eu não gosto de testes de quadro branco e acho esses testes de sites como HackerHank bastante limitados. Por mais que seja bem difícil e trabalhoso especificar um teste técnico que consiga abranger a avaliação de todas as habilidades importantes em um candidato eu acho que vale o investimento.

O teste técnico é peça muito importante de todo o processo. Não só porque ele vai avaliar se o candidato tem o mínimo de conhecimento para trabalhar nos projetos que a empresa precisa. O teste técnico serve como subsídio para algumas etapas posteriores.

O teste técnico que criamos possuíam as seguintes características:

1. Venda seu peixe. O documento com o teste é uma boa oportunidade para mostrar como vai ser legal trabalhar junto com você na empresa.
2. Projeto completo. O teste tem que pedir um projeto completo. Do desenvolvimento até o deployment em produção. Indique sites que possibilitem o deploy gratuito desse teste para o candidato (ex. Heroku).
3. Definição de escopo e requisitos objetiva. O teste tem que ser enviado para o candidato com um único documento contendo todo o escopo do projeto. Se você espera que o candidato saiba inglês, por exemplo, envie esse documento em inglês. O documento deve especificar apenas o Quê precisa ser feito. Nunca diga como fazer à menos que isso faça parte das práticas que o candidato precise dominar mas que seja muito difícil ou demorado para ensinar. Exemplos de coisas que você pode pedir:
   1. Código com strings e identificadores em inglês;
   2. Usar alguma linguagem que a empresa use (para que possa ser avaliado);
   3. Testes automatizados;
   4. Documentação (no idioma que você quer avaliar no candidato);
   5. Armazenado em controle de versão;
   6. Seguir um coding style específico;
   7. Praticar conceitos de 12 Factor-App;
   8. API em um estilo específico (ex. REST, GraphQL, gRPC, etc)
4. Simples e factível em 1 dia. Bons profissionais, geralmente, já estão trabalhando. É importante entender que eles não tem tempo para investir em um teste longo e trabalhoso.
5. Não-relacionado à atividade da empresa. Não faz muito tempo algumas empresas usavam testes técnicos para obter desenvolvimento gratuito de candidatos. Por conta disso programadores são bastante desconfiados de testes que pedem o desenvolvimento de algo que a empresa possa usar sem pagar.
6. Código aberto por padrão. Exceto em casos onde o candidato pede explicitamente para manter o teste dele fechado deixe ele como opensource. Isso diminui as dúvidas sobre o uso do código sem pagamento. Algumas pessoas me perguntavam se isso não pode ser usado por outros candidatos para copiar testes. Sim. E tudo bem, afinal, todo desenvolvedor sempre acaba copiando um código aqui e ali. Nas etapas seguintes é possível levantar o que foi copiado e a motivação para isso. Se foi plágio completo você consegue detectar fácil.
7. Exercitar vários aspectos do trabalho. O teste pode ter uma regra de negócio elaborada, implementar uma API REST, armazenar os dados em um DB, ter modelos diferentes interagindo, etc. Problemas pontuais com coisas como carrinho de compras, gestão de assinaturas e pagamentos, gestão de conteúdo, logística e entregas, etc são ótimas fontes de ‘problemas de negócio’ que podem ser explorados para criar um teste. Lembre apenas de limitar bem o escopo para que seja possível criar algo em um dia.
8. Validade limitada. O teste tem que ter uma validade limitada. A validade serve para que você reabilite candidatos que eventualmente não foram selecionados em um processo anterior a participar novamente. Ele fez o teste-1 e não foi adiante 6 meses atrás mas ele estudou os pontos que você indicou e quer aplicar para uma vaga novamente. Se o teste mudou ele pode reaplicar.
9. Produzir contexto extra-código. O teste precisa permitir que o programador trabalhe nele como ele trabalharia na sua empresa porque não devemos avaliar apenas o código produzido. Precisamos ver a documentação do projeto, a linha do tempo dos commits e as mensagens de commit, abordagens alternativas para solução do problema, etc.
10. Sem prazo para entrega. É importante deixar claro para o candidato que o objetivo dele é fazer o melhor teste que ele puder e não o tempo que ele leva para fazer isso. O tempo para realizar o teste precisa ser descartado completamente da avaliação porque cada candidato tem uma situação completamente diferente de outro candidato. Tem candidato que tem emprego e outro que não tem. Tem candidato que tem atividades paralelas e outros que não tem. Tem candidato que está estudando um tópico novo para fazer o teste e outros que já sabem tal tópico. É importantíssimo reforçar isso para o candidato sempre que entrarmos em contato com ele para que esse contato não se pareça com alguma forma de pressão por entrega. Diga que ele será avaliado pelo que ele entregar e não pelo tempo que ele levou pra entregar.

Abaixo você consegue ver um exemplo de teste técnico:

Assim que o candidato concluir o teste e enviar o material pra você a próxima etapa começa. Chegou a hora de avaliar o teste.

Etapa 3: Avaliação Técnica

A avaliação do teste precisa ser feita por um programador da equipe ou gestor que tenha trabalhado como programador da equipe. Ele vai pegar o código do candidato e uma ficha de avaliação com perguntas claras e objetivas sobre tudo o que a empresa espera do candidato e preencher essa avaliação.

Mais do que a avaliação em si, nesse momento é bem importante que apareçam dúvidas na cabeça do avaliador. Essas dúvidas precisam ser anotadas juntamente com os resultados da avaliação porque elas serão extremamente úteis na próxima etapa do processo seletivo.

Na empresa onde implementamos esse processo a gente criou uma planilha com um questionário com perguntas bem objetivas agrupadas em tópicos. Cada pergunta dessa gerava uma nota entre 0 (min) e 3 (max). Cada nota dessas tinha um peso variando entre 1 e 3 que posteriormente era usada em uma média ponderada.

No final a gente gerava um gráfico do tipo radar com um eixo em cada tópico (ex. Documentação, Modelagem de Banco, Commits, etc) e uma lista de notas e observações do avaliador.

Você pode baixar um modelo dessa avaliação aqui:

Quando o volume era menor a gente colocava dois programadores para avaliar o mesmo teste e depois fazia uma ‘acareação’ mediada entre os avaliadores para evitar problemas de interpretação. Mas em um determinado momento o volume de testes para revisar ficou grande demais e só um programador fazia a avaliação de cada teste.

Fizemos essa mudança porque raramente encontrávamos divergências muito grande e em todas as vezes o motivo da divergência era a falta de objetividade na pergunta do questionário que era prontamente corrigido.

Essa avaliação não pode demorar muito pra ser feita e, se isso acontecer por algum motivo, é importante manter o candidato informado.

Em alguns casos o candidato vai muito mal e recebe avaliações muito ruins e seguir com o processo provavelmente seria um desperdício de tempo para todos.

Nesses casos é muito importante devolver uma resposta para o candidato e, se possível, indicar os pontos de estudo e melhoria para ele. Eu tinha uma lista de links para artigos ou livros para indicar que ajudariam o candidato a cobrir todos os pontos onde ele precisava melhorar.

Esse feedback precisa ser mais abrangente do que específico:

From: [email protected]
 
Olá [candidato],

Após a avaliação do seu teste técnico [url do
teste] nós optamos por não seguir adiante com
seu processo seletivo nesse momento.

Agradecemos o seu tempo e dedicação até aqui e
gostaríamos de vê-lo novamente no futuro quando
lançarmos um novo teste técnico para a vaga.

Para isso gostaríamos de sugerir a leitura dos
seguintes materiais:

* [link para um artigo sobre apis rest]
* [link para um livro sobre modelagem OO]
* [link para livro sobre TDD]
* [link para um bom curso de Python no youtube]

Se você tiver qualquer dúvida ou tiver
interesse em nos dar um feedback sobre
o processo até aqui é só entrar em contato.

Obrigado,
Equipe Empresa Co.

Esse e-mail não é o lugar para escrever coisas como ‘você não foi aprovado porque a sua modelagem de banco estava toda errada’. Prefira indicar um bom livro sobre modelagem relacional. Dê preferência para conteúdo gratuito. Lembrem-se que o candidato pode estar numa situação financeira complicada.

Na empresa onde eu trabalhei eu pedi verba para comprar ebooks e enviar para candidatos que não eram aprovados. Mas a verba não foi aprovada.

Etapa 4: Entrevista Técnica

Assim que a avaliação do teste técnico ficava pronta um gestor de tecnologia poderia prosseguir com o agendamento da entrevista técnica com o candidato. Ele fazia isso sempre buscando o melhor horário para o candidato. A entrevista também precisava ter uma duração fixa pré-determinada. Deve-se evitar dividir essa entrevista em etapas distintas. Ter ela em uma única sessão garante que você vai avaliar o candidato em sua plenitude de humores.

Conduzir uma boa entrevista exige mais técnica do que experiência. Pode ser que eu escreva só sobre isso em um artigo futuro então vou só pontuar algumas coisas que a gente fazia lá.

Antes de ir para a entrevista técnica o gestor já se preparava usando as informações das avaliações feitas pela recrutadora na entrevista inicial, as anotações da avaliação técnica e dando uma conferida no Linkedin ou no Github do candidato. Eu evitava redes sociais não profissionais (Twitter, Instagram, Facebook, etc) porque nas poucas vezes que olhei essas redes acabei sentindo que a entrevista ficou enviesada de forma negativa.

Os gestores que faziam essas entrevistas já tinham alguma experiência com processos de recrutamento mas, mesmo assim, a gente ainda sugeria certos procedimentos para tentar padronizar a experiência. A gente sugeria que o entrevistador criasse um plano para a entrevista com algumas perguntas-guia para fazer para o candidato. Meus planos geralmente tinham umas 3 perguntas padrão que giravam em torno de relacionamento com equipe, processos e experiências anteriores, e umas 2 ou 3 perguntas que variavam em função do resultado das avaliações. Nem sempre eu usava essas perguntas mas sabia que elas estavam lá caso a entrevista ficasse meio truncada.

Condução da entrevista

Essa etapa não era muito padronizada então vou descrever como eu conduzia as minhas entrevistas. Como eu já disse eu iniciava a entrevista com um plano construído sobre as avaliações anteriores e uma breve olhada nas redes sociais profissionais do candidato.

Sabendo que essa entrevista costuma ser a que deixa os candidatos mais nervosos e que muitos candidatos, mesmo aqueles com muita experiência, podem ‘travar’ nesse momento eu dedicava um bocado de tempo no começo só para deixar o ambiente mais leve e as coisas mais calmas. Você precisa que o candidato esteja tranquilo para conseguir uma boa entrevista.

A entrevista técnica sempre começava com algumas perguntas básicas e despretensiosas sobre o candidato. Começar a conversa perguntando sobre algum hobby ou coisas positivas que surgiram na entrevista inicial tira o peso da entrevista e diminuíam o nervosismo do candidato.

Um exemplo do que eu fazia era só perguntar coisas que o candidato sabe como responder com 100% de certeza. Perguntas como: “Qual seu nome?” ou “Qual sua idade?” estão nessa categoria. “Quais linguagens de programação você gosta?” não está nessa categoria porque o candidato vai começar a pensar sobre qual é a resposta que o entrevistador quer ouvir.

Eu tomava muito cuidado com perguntas sobre a intimidade do candidato (ex. “Você é tem namorada(o)?”). Até pra perguntar se o candidato era casado(a) ou tinha filhos eu evitava. Se eu não estivesse 100% certo de que essas perguntas eram seguras eu não fazia. Por isso o planejamento prévio é essencial.

Uma dica que sempre dou para quem está começando a fazer entrevistas é: você não precisa ser algo que você não é. Se você não é engraçado não precisa ser engraçado. Só tente ter empatia pelo candidato para poder ajudar ele.

Quando você sentir que o candidato está mais calmo você pode serguir com o seu plano para a entrevista. Chegou a hora de falar pouco e ouvir muito.

Aqui eu partia para as perguntas técnicas. É muito comum que programadores estejam mais confortáveis com a parte de hard skills então a transição para essas perguntas acontecia de modo mais natural.

Eu usava o teste do candidato para formular questões bem objetivas. Perguntas do tipo: “Aqui nesse ponto do seu código você fez isso. Porque você fez assim e não assado?” (ex. “Vi aqui nessa parte do seu teste que você modelou esse relacionamento em 1-para-N… mas e se essa entidade estiver em M contextos, não seria melhor um N-para-M?”).

Eu prestava atenção no que estava sendo dito (ex. “eu optei por modelar 1-para-N porque na descrição do problema não existia o requisito que pediria uma modelagem N-para-M”), mas também observe o que não está sendo dito. No exemplo anterior dá pra inferir que o candidato segue bem as especificações mas pode não ser muito pró-ativo em questionar essas especificações. Eu encadeava mais perguntas pra dirimir essa dúvida e não ficar só com a minha “inferência”.

Também gostava de fazer perguntas que podiam ser respondidas corretamente de vários modos diferentes e emendar uma segunda pergunta contrapondo a resposta. Exemplo: “Se você tivesse desenvolvendo um ORM como você faria pra persistir um objeto no banco de dados? Faria obj.save() ou storage.save(obj)?” e a próxima pergunta seria: “Mas [a outra abordagem] não teria a vantagem de [vantagem da outra abordagem]?”. Esse tipo de pergunta permite ver o candidato reagindo à uma situação de argumentação e defesa de seus pontos de vista. Alguns candidatos até explicaram a teoria e as referências para as duas abordagens (Active Records vs. Data Mappers). Esse foi contratado, né? ?

Uma vez que as questões técnicas foram esclarecidas eu partia para as “perguntas difíceis”. Aqui eu queria entender mais sobre os soft skills do candidato. Nesse momento o candidato estava mais amaciado com as coisas que ele (teoricamente) sabia e conseguiria responder com a guarda mais baixa.

Eu voltava então a fazer perguntas relacionadas ao comportamento e relacionamento do candidato com as equipes que ele teve.

Queria saber como era a relação dele com gestores, o que ele gostava no trabalho, o que ele detestava, o que ele gostaria de mudar, o que ele conseguiu mudar, o que ele não conseguiu mudar, porque ele não conseguiu mudar, etc.

Eu sempre tomava notas durante a entrevista. Precisava fazer isso para alimentar o nosso relatório sobre o candidato.

Finalmente chegamos ao fim da entrevista. Você agradece o candidato e avisa que ele receberá um retorno num prazo específico. Cumpra esse prazo.

Retorno

O retorno para o candidato podia ser de 2 tipos:

1. Paramos: agradecíamos o candidato pelo tempo investido no processo, informávamos que ele pode voltar a tentar a vaga no futuro, indicávamos caminhos que ele poderia tomar para ser melhor sucedido na próxima oportunidade, e deixávamos um canal sempre aberto para comunicação com ele. Esse retorno era por e-mail mas eventualmente o RH entrava em contato direto com o candidato.
2. Continuamos: parabenizávamos o candidato e informávamos que a próxima etapa seria uma dinâmica de Pair Programming remoto com um dos nossos desenvolvedores. Pedíamos um espaço na agenda do candidato para essa atividade.

Etapa 5: Dinâmica de Pair Programming Remoto

A equipe de tecnologia da empresa onde implementamos esse processo sempre trabalhou remotamente. Trabalhar remoto é uma atividade que pede certos soft skills importantes (ex. auto-gestão, auto-organização, etc) e o nosso processo precisava avaliar se o candidato tinha essas características, se era necessário desenvolvê-las, ou se a empresa seria incapaz de desenvolver essas qualidades no profissional caso ele fosse contratado.

Quebramos a cabeça pra descobrir um modo de fazer essa avaliação e, certo dia, participando de um Coding Dojo com alguns amigos eu tive a ideia de tentar algo parecido para avaliar a dinâmica de trabalho remoto do candidato. Deu super certo e se tornou a etapa que me deixava mais entusiasmado com os resultados.

Montamos um servidor remoto (usando AWS Cloud9) com a linguagem Python, framework de teste, editor de textos e conectávamos um desenvolvedor da nossa equipe e o candidato para fazer pair programming. Além dos dois programadores um gestor (geralmente o mesmo que fez a entrevista técnica) ficava na audiência coordenando a atividade e observando a dinâmica.

O gestor então apresentava o problema que seria abordado na dinâmica. Eram problemas de Coding Dojo já conhecidos (ex. mostrar números decimais com algarismos romanos). Nenhum dos programadores pode saber qual vai ser o problema de antemão. Tem que ser uma surpresa para ambos.

É muito importante deixar claro para ambos que o objetivo da dinâmica é ver a dupla trabalhando e não a resolução do problema. Deixe claro para o candidato que se não der tempo de resolver o problema está tudo bem.

Uma vez apresentado o problema os programadores começavam a trabalhar nele usando TDD e baby steps. Em intervalos de 5 minutos (cronometrados) os programadores são obrigados a trocar de posições como piloto e co-piloto do teclado.

Assim que o timebox foi atingido o programador pode deixar a sala e o gestor pode conversar com o candidato sobre a dinâmica.

A gente usava essa oportunidade para perguntar sobre situações que aconteceram durante a sessão de pair programming. Fazíamos muitas perguntas sobre comportamento (ex. “naquele momento o [nome-do-dev] propôs algo que você não concordou/entendeu e mesmo assim você seguiu com a proposta dele, porque você não parou pra questionar ele sobre a decisão?”).

Também é possível ver se o candidato consegue expressar bem suas ideias e propostas.

Essa etapa tem que ter duração fixa e não precisa ser longa. Na empresa a duração dessa etapa começou com uma hora de duração e foi diminuindo até durar 40min.

Algumas vezes a gente colhia as impressões do programador da nossa equipe que fez pareou com o candidato para complementar nossa avaliação.

Era muito raro um candidato cair nessa etapa. Se o candidato foi muito mal e a gente entendesse que não daria para prosseguir a gente falava que ele receberia o feedback em alguns dias e procedia com o e-mail de agradecimento e etc.

Se o candidato tivesse ido bem nessa etapa ele já recebia uma lista de dias e horários para a entrevista final com o CEO. Era a única ocasião onde o candidato não tinha o controle total sobre a agenda do processo. Infelizmente a agenda do CEO era uma selva e tinha muito poucos buracos para ocupar com as entrevistas com candidatos. Mas ele fazia questão de entrevistar todo mundo de todos os setores da empresa.

Etapa 6: Entrevista Final

A entrevista final com o CEO era a etapa de consolidação & arremate do processo. Ela existia para determinar se o candidato tinha fit com a cultura da empresa mas também era usada para dirimir alguns questionamentos que ainda estavam aberto sobre o candidato.

Para isso o CEO recebia um “dossiê” com tudo o que foi levantado sobre o candidato nas etapas anteriores bem como alguns pontos de atenção que a gente detectou nas etapas anteriores. A gente chamava esses pontos de atenção de red flags (bandeiras vermelhas).

Uma das coisas que essa entrevista tentava avaliar era o nível de comprometimento com a empresa que a gente podia esperar do candidato. Para a empresa era importante que o candidato fosse trabalhar lá com um certo nível de comprometimento e não chegar lá como um trampolim para outra vaga que pagasse mais. Afinal o time dessa empresa era muito reconhecido no mercado e passar por ele “valorizava o passe” de qualquer profissional.

Nessa etapa todos os candidatos já chegavam travados pelo nervosismo. Afinal, era o CEO da empresa… Então o CEO com a maior calma e paciência ia acalmando o candidato antes de partir para as perguntas.

Durante a entrevista o CEO contrapunha as resposta do candidato com anotações do relatório que ele tinha recebido para tentar encontrar, explorar e esclarecer divergências.

Assim que a entrevista terminava o candidato era avisado de que ele receberia o resultado final do processo em alguns dias. Geralmente era no dia seguinte mesmo. Assim que o CEO terminava a entrevista com o candidato era bem comum ele já reunir o comitê que iria decidir sobre a contratação.

Decisão Final

Essa etapa era rápida e a decisão era colegiada. Um candidato só era contratado se houvesse unanimidade desse colegiado que era formado por todos os gestores e recrutadores que participaram do processo daquele candidato.

A decisão era rápida porque todos já tinham tido acesso ao relatório final com todas as informações levantadas ao longo de todo o processo. Bastava avaliar as forças e fraquezas de cada candidato, traçar um plano para potencializar as forças e lidar com os pontos de atenção do candidato e decidir sobre a contratação.

Feedback

A etapa de feedback tem duas versões. O feedback para o candidato que foi contratado e o feedback para o candidato que não vai seguir para contratação naquele momento.

Para os candidatos que não seguiriam a gente enviava um e-mail bastante completo para informar que a gente não seguiria adiante com a contratação, agradecíamos a dedicação do candidato, indicávamos alguns caminhos para futuras tentativas e deixávamos uma linha de comunicação aberta para esse candidato.

Na linha do respeito ao candidato, algumas vezes, a gente entrava em contato direto com o candidato. Geralmente quando eram candidatos muito jovens que, eventualmente, não conseguiriam lidar muito bem com a não-contratação. As psicólogas avaliavam se isso era necessário ou não e por isso disse que ter esse tipo de profissional envolvido no processo é super importante.

Para os candidatos que foram aprovados a gente mandava um e-mail de congratulações com as primeiras instruções do nosso processo de on boarding que, modéstia à parte, também ficou lindão (e provavelmente vou descrever aqui).

É possível que o candidato recuse a oferta nessa etapa. Esteja preparado para isso e peça, educadamente, que, se possível, o candidato explique o motivo da recusa para ver se é possível melhorar algo no processo. Lembrem que o feedback é uma via de mão dupla e o candidato é o protagonista.

A gente também colhia feedback dos candidatos contratados durante o on boarding. A gente tinha um formulário (Google Forms) interno onde o novo funcionário preenchia suas impressões, apontava problemas e sugeria melhorias. As recrutadoras do RH colhiam essas informações e traziam os feedbacks de forma anônima para nossas reuniões de processos.