Tenho recebido essa pergunta com frequência. Vou tentar contar aqui um pouco de como fazemos pra contratar. O foco será em programadores para times de projetos de desenvolvimento de software. Quem sabe eu ou outra pessoa não faz outro sobre líderes/scrum masters e/ou outras linhas de trabalho mais pra frente.

Primeiro temos que analisar de onde vem a demanda. Quem está precisando de mais gente? Como não temos gerentes na empresa, alguém tem que medir a alocação das pessoas, certo? Errado. Na Lambda3 os times se auto-organizam em volta de um projeto demandado por um cliente. As pessoas nunca estão paradas esperando o projeto chegar, então é uma questão de avaliação de quando os projetos de cada um terminam ou permitem saída. Com isso, temos uma ideia de quem será o time do projeto, e quando cada um vai entrar pra ajudar. Esse time avalia se o número de pessoas é suficiente. Às vezes, alguém que já está atendendo o cliente ajuda, quando temos mais de um projeto no cliente, ou é um projeto onde já estamos atendendo com consultoria (algo bem comum). Se não for, o próprio time pede mais gente. Pra quem? Para as outras pessoas da empresa. O time sai à caça de ajuda. Se não encontrar, avalia a contratação ou revisão de prazos com o cliente.

Se decidir por contratar, verificamos se tem alguém já cuidando disso. Nesse momento, quem tem mais puxado o processo de contratações é o Raphael Molesim. Então, nesse momento, vamos falar com ele. Ele se voluntariou a puxar isso, e algum dia pode ser outra pessoa, se ele não quiser mais fazer isso. Ele verifica se já falou com alguém que poderia encaixar na posição, e fala com outras pessoas da empresa que podem ter se envolvido com candidatos passados. Também fala com outras pessoas da empresa, via diversos mecanismos (chat, e-mail, pessoalmente, etc) pra ver se alguém tem alguma pessoa interessante pra indicar. Uma grande parte das contratações vem de amigos de pessoas que já trabalham na Lambda3. E também avalia o mercado, vendo pessoas que nos mandaram currículos ou que demonstraram que gostariam de trabalhar com a gente.

O Raphael ou outra pessoa entra em contato com os possíveis futuros Lambdas. Conversa com eles por telefone, avalia se eles tem disponibilidade, se se interessam para uma conversa mais séria sobre o assunto. Se sim, a pessoa é chamada para ir na Lambda3 conversar. O currículo, certificações, experiência, pesa pouco nesse processo como um todo, porque geralmente já conhecemos a pessoa, alguém da Lambda3 já conversou com ela antes. É muito raro chamarmos alguém que nunca vimos antes.

Quando a pessoa vai na Lambda3, o Raphael e/ou algumas pessoas da empresa bate um papo com o candidato. Ele conta sobre a vida dele, o que ele faz no trabalho, o que ele gosta de fazer, etc. Nós contamos o que a Lambda3 é, contamos que não temos gerentes ou planos de carreira, contamos sobre democracia organizacional. Se tudo bater, falamos de salário, possíveis datas, etc. E aí entra a parte boa. Pedimos pra pessoa resolver um problema. Jogamos um cenário, e pedimos pra pessoa resolver. Eu já fiz isso pedindo pra pessoa desenvolver alguns diagramas arquiteturais, contar um pouco sobre como faria o projeto, etc. Criamos o cenário ao longo da conversa. Depois disso vamos pro código. A pessoa pega a ferramenta que conhece (não precisa ser a ferramenta que o projeto que está demandando usa) e implementa sua ideia. Aí avaliamos o conhecimento de OO, padrões, linguagens, frameworks, testes, etc. Só depois dessa fase é que consideramos de fato a contratação. Um programador nunca é contratado na Lambda3 sem mostrar o código que sabe fazer. E isso é batido com o que precisamos: se precisamos de uma pessoa mais experiente, ele tem que demonstrar código nesse nível. Se está começando, exigimos bem menos.

Já aconteceu de conversarmos com pessoas que na hora do bate papo diziam que sabiam tudo de tudo. Sabiam OO, DDD, TDD, BDD (e outros xDDs), que liam todos os blogs, que programavam em Java, C#, Python, Ruby, ObjectiveC, Javascript e até uma linguagem obscura hipster qualquer. Mas na hora do código, quando ela está usando a ferramenta que escolheu, onde é melhor, tem problemas de sintaxe na linguagem, ou não sabe escrever testes, ou escreve um código totalmente procedural, ou todas essas juntas. O código desnuda o candidato. Mostra quem ele realmente é e o que sabe.

O time que vai trabalhar com a pessoa geralmente participa de algumas partes do processo de entrevista, e sempre antes de fechar ele tem que conhecer a pessoa pra ver se bate.

O novo funcionário também escolhe o próprio salário, ele decide quanto quer ganhar. A Lambda3 só avalia se está dentro do que ela pode pagar, e se bate com o que os outros ganham. Todo mundo sabe quanto todo mundo ganha, então a pessoa tem que estar na média. Se está muito acima não contratamos. Se pediu muito pouco normalmente nós mesmos falamos que é pouco.

Se tudo deu certo batemos o martelo. Fechamos uma data de início, sempre pedindo para o novo Lambda terminar o que estava fazendo na empresa atual numa boa, sem stress. Já fechamos contratações que demoraram 2 meses para vir para a empresa. É importante respeitar a empresa atual. Se o candidato diz que vai deixar o empregador atual na mão isso é mal visto, ele pode fazer o mesmo com a gente.

Depois de tudo certo, umas 2 semanas antes da pessoa entrar já criamos e-mail, e damos acesso a todo o resto do arsenal de comunicação (chat, gestão de projetos, github, etc). A pessoa passa a participar no seu tempo livre das discussões da empresa, e já começa interada do que está acontecendo. Nós costumamos mandar um e-mail contando da contratação para todo mundo, apresentando a pessoa, passando twitter, facebook, github da pessoa pra todo mundo conhecer ela melhor.

E é assim que contratamos. Agora um comentário paralelo sobre um problema que temos encontrado. Serve para uma auto avaliação da nossa indústria:

Temos tido uma situação recorrente que é um problema no mercado atual. A demanda atual por programadores é muito alta. Falta gente boa. Isso tem deixado os programadores preguiçosos, e permitido um aumento de salário sem sentido. Hoje em dia temos visto pessoas ganhando de acordo com seu tempo de trabalho, e não de acordo com seu conhecimento. A pessoa é sênior por tempo, mas não é sênior no comportamento ou por experiência em projetos. Assim, temos visto pessoas com 10, 15, 20 anos de experiência, mas que sempre trabalharam em projetos muito parecidos, sem grandes desafios técnicos, e sem estudar. Só que, com 10 anos de experiência, o salário da pessoa já é alto, ainda que seu conhecimento não seja. E ela já fundamentou uma estrutura de custos, ela precisa ganhar um bom salário para se manter, tem filhos, carro, prestação da casa pra pagar. Só que não entrega o que custa. Essa situação é muito ruim, porque a pessoa não pode abrir mão do salário, mas também não oferece retorno compatível com o que precisa ganhar. Nós não contratamos essas pessoas, e, infelizmente, enquanto elas não puderem dar um passo para trás para poderem evoluir, acabarão continuando nos mesmos projetos iguais. Isso não necessariamente é um problema, porque esses projetos existirão por muitos anos ainda, mas pode ser um problema se a pessoa quer aprender, quer evoluir, mas não quer abrir mão do que ganha, ainda que ela esteja, de certa forma, inflacionada. Uma vez que atinja a senioridade de fato, o salário dela voltará a ser o que era antes, mas há esse período de ajuste.

É difícil comunicar isso para a pessoa, mas geralmente apresentamos os problemas que vimos no código e na entrevista em geral. A pessoa não contratada geralmente sai da entrevista entendendo porque não foi contratada. Trabalhamos com total transparência com os candidatos, eles são parte da comunidade de desenvolvimento de software, são pessoas, e merecem respeito.

Contratar não é fácil e toma tempo. É importante fazer direito, porque as pessoas são a Lambda3. Tomamos muito cuidado com isso.

PS: Se você quer trabalhar com a gente, mande um e-mail: [email protected]. Temos vagas para preencher no Rio e em São Paulo, a empresa está crescendo.

Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.