Github como currículo e visão geral sobre processos seletivos
Ou, pelo menos, os capitaneados pela minha pessoa
Não é de hoje que estou envolvido nos processos seletivos que rolam na empresa em que trabalho. Eliminar os candidatos ruins e conseguir desvendar os mistérios da relação custo/benefício ao contratar alguém já fazem parte do meu “job description” há alguns anos. Não que eu tenha aprendido tudo e nunca esteja errado. Mas, enfim, pelo menos eu posso dizer que tenho alguma experiência no assunto.
Antigamente eu costumava fazer uma pequena pré-seleção, chamar os candidatos para uma entrevista e, se fossem bem nela, eu os convidava para um teste prático, que consistia em resolver alguns probleminhas usando as tecnologias necessárias. Eles usavam um computador rodando Linux e acesso absolutamente normal à internet.
Hoje eu tenho usado uma abordagem um pouco diferente e que consiste em alguns passos simples mas bem eficientes (acredito eu) para se chegar no perfil profissional que eu realmente aprecio.
O meu foco, geralmente, é em desenvolvedores Python. Então a descrição dos processos deve seguir nessa linha. Quando algo não faz sentido para outra linguagem ou tecnologia, eu adapto ou elimino, obviamente.
1- Ordenação
Eu avalio alguns fatos, geralmente “binários”, e vou dando pontos para cada resposta positiva.
1.1- Github ou outros
O primeiro “pivô” é o perfil no Github (ou BitBucket ou Gitlab). Quem tem N ≥ 1 projetos próprios e razoavelmente atualizados já ganha pontos. O resto é resto.
1.1.1- Qualidade do código
Essa talvez seja a parte mais interessante. Eu leio muito código dos candidatos (eu costumo ler pelo menos dois projetos praticamente inteiros) e avalio algumas coisas:
- O projeto tem testes automatizados? (Importantíssimo!)
- Os arquivos do projeto seguem uma estrutura de diretórios bem organizada?
- O desenvolvedor traz manias bizarras de outras linguagens, como criar um diretório
src? - O projeto é preparado para rodar em um virtualenv?
- O “requirements” está bem escrito ou é meramente a saída de um “pip freeze”?
- O “requirements” dos testes está separado do de produção?
- Foi incluído no repositório arquivos de configuração da IDE? (Isso eu considero negativo.)
- O desenvolvedor escreveu um módulo Python, como todo programa Python deve ser, ou escreveu “estilo script”? Ele restringiu o conteúdo do
__main__.py, se existir, apenas ao que é necessário para execução via linha de comando? - Os nomes de variáveis, funções e classes estão em inglês?
- O desenvolvedor usa Python 3?
- O código passou por um “flake8” para adequar-se a um estilo mais “universal”? (Mas, veja: eu ignoro o “E501”: as linhas podem ser mais longas que 80 caracteres.)
- Lendo as funções e métodos, eu consigo entender o que está sendo feito?
- O desenvolvedor enche o código de documentação? (Isso eu considero ruim.)
- O código é “espartano”? (Logo escreverei um artigo sobre isso ;-)
- O README.md me explica o que eu preciso saber caso queira executar o programa?
- O desenvolvedor usa as bibliotecas adequadas ou tem mania de fazer “tratadores tupiniquim”? (Exemplo: manusear datas, fazer requisições HTTP, parsear URLs, lidar com paths do sistema de arquivos, concatenar strings, parsear argumentos de linha de comando, gerar logs, imprimir colorido no terminal.)
- Há paths hardcoded? Eles privilegiam usuários de Linux e Unices em geral ou usa o sistema bizarro do Windows?
Quem tem projetos bons ganha, novamente, alguns pontos. O resto é resto.
Eu não avalio muito a semântica dos projetos: não considero se o projeto é “útil ou inútil” nem nada nesse sentido. O que importa mesmo é a qualidade do código e a utilização correta do ecossistema da linguagem.
1.1.1.2- Colaboração com projetos de software livre
Colaborar com projetos de software livre também dá pontos. E não precisa ser muito: o que importa é ter feito alguma coisa.
Veja bem: escrever um pull request imenso é sinal de pró-atividade e disposição, mas muitas vezes isso é meramente questão de oportunidade. Bem pode ser que um PR de duas linhas seja tudo o que o desenvolvedor precisou fazer para resolver um grande problema e isso também indica um bom “engajamento”.
Enfim, colaborando muito ou pouco, o que importa é: colaborar.
1.1.2- Github versus outros
Hoje o Github é “o point” dos programadores que tem qualquer conexão com o mundo do software livre. Você pode até ter um ótimo perfil com projetos bem bacanas em outro sistema, como o Gitlab, mas por isso você perde alguns pontos. É como ser um excelente “especialista em SEO, mas que não trabalha com o Google”.
Praticamente todos os grandes projetos de software livre já migraram para o Github e provavelmente todos os projetos menores que tem qualquer relevância estão lá. Se você conscientemente decidiu ficar fora dessa festa, você deixa de ganhar uns pontinhos.
1.1.3- Os sem Github e nem nada
Se você caiu nesse grupo, você já está meio que com problemas. Afinal, que espécie de desenvolvedor é você que não colabora com nenhum projeto de software livre? Você nunca corrigiu um bug numa biblioteca open source? Nunca melhorou uma tradução que estava esquisita? Nunca criou um script (de 10 linhas que seja!) que achou que seria útil para mais alguém além de você nesse mundo?
Isso não chega a te desclassificar, mas levanta dúvidas quanto à tua identificação como “programador”. Me dá a impressão de que você “veste chapéu” de programador durante o horário de trabalho e, tão logo “dê o horário” você se livra dele e torna-se qualquer outra coisa. E, enquanto isso não faz de você, necessariamente, um mau profissional, certamente você é “secundado” por um “desenvolvedor de coração, que por acaso também ganha o pão de cada dia com isso, o que é muito bom”.
1.2- Artigos
Quem escreve artigos técnicos de qualidade também ganha pontos.
Quando possível, eu também avalio se o candidato lê artigos técnicos de qualidade. Muita gente não tem o dom de escrever ou, por algum motivo pessoal, simplesmente não o fazem. Não tem problema. Problema mesmo é não escrever nem ler nada. Se você escreve, ganha pontos. Se lê, também ganha alguns.
1.3- Experiência
Esse é um dos últimos pontos a serem analisados, mas podem render alguns pontos, sim. Por mais que eu esteja procurando desenvolvedores para cumprir um determinado tipo de tarefa, pode ser interessante encontrar alguém que já trabalhou em algum outro ramo de conhecimento. Ter trabalhado com, digamos, cyber-segurança pode ser um bônus para alguém que vai, a princípio, “meramente escrever APIs simples”.
1.4- Teste
Caso o candidato não tenha nenhum código recente publicado para que eu possa analisar, costumo passar para ele um teste, que geralmente consistem em colaborar com algum projeto de software livre, de preferência um em que eu tenha poder de fazer merge. Faço isso porque não gosto de testes que, fora o proveito para a empresa, são “inúteis” para o candidato. Ao colaborar com um projeto de software livre, pelo menos, o candidato acaba melhorando seu próprio Github, o que é muito bom para ele.
Mas, se o candidato ainda não tem bagagem suficiente para colaborar com um projeto em andamento, eu então crio algum teste adequado, geralmente “inócuo” (como criar um projeto Django e implementar uma API simples) e, nesse caso, peço para que o candidato faça pull requests frequentes, assim, pelo menos, ele tem oportunidade de ganhar algum conhecimento e experiência durante as conversas do code review.
O teste é eliminatório: candidato vai mal, candidato vai embora. Os que permanecem ganham mais ou menos pontos de acordo com a qualidade do código.
Mas, novamente: eu só aplico um teste em quem não tem código atualizado disponível para análise.
1.999- Escolaridade
Esse assunto um tanto polêmico, mas pode ser interessante você conhecer um pouco da minha experiência: eu estudei Ciência da Computação na UFPR. Na época era um curso pesadíssimo, com taxa alta de desistências e taxa mínima de formandos (serião: entrava 115, se não me engano, mas formavam-se uns 30). Os professores seguiam uma política rígida de tentar impedir que os alunos fizessem qualquer outra coisa na vida além de estudar. A ideia era formar “acadêmicos”, já que o curso era científico (e isso até faz sentido). As aulas eram à tarde e à noite, por exemplo, e não havia chance de mudar o curso para ter aulas somente à noite. Os professores realmente não queriam.
Problemas sociais à parte (veja que o pai de família que sustentava sua casa e queria estudar Ciência da Computação acabava sendo excluído), era um curso “de respeito”: não era para qualquer um.
Pois bem, eu sou um “drop out”: fiquei 6 anos estudando mas nunca me formei. E, curiosamente, trabalhei com N “coleguinhas” e cheguei a uma conclusão assustadora:
Se era bom aluno, era mau programador.
Os caras que conseguiram a façanha de “se formar em quatro anos” e que trabalharam comigo eram a ralé da ralé da miséria da programação porca. Aparentemente, acadêmicos podiam ser bons cientistas, mas ficavam perdidos na indústria.
Conto isso tudo para ilustrar um pouco da minha posição: o histórico acadêmico não quer dizer absolutamente nada. E, veja bem: eu não estou dizendo que rejeito imediatamente quem parece ter sido um bom aluno. Estou dizendo que ter sido um bom aluno na faculdade não tem significância alguma na hora de saber se você é um bom programador ou não.
Todavia, um histórico acadêmico que envolva Ciência da Computação acrescenta alguns “pontos condicionais”: contanto que você tenha ido bem nas avaliações anteriores, ter esse curso como background vem bem a calhar quando eu quiser conversar com o desenvolvedor em um nível mais elevado, sem ter que ficar explicando detalhes que seriam óbvios. Esse é um conhecimento bom e muito bem-vindo. Só não é “essencial”.
Mas isso só serve para Ciência da Computação. “Análise de Sistemas” e outros semelhantes eu ignoro completamente. Eles não acrescentam nem retiram ponto algum, absolutamente.
2- Análise comportamental
Isso é um assunto tão complexo que peguei tudo o que havia escrito aqui e estou usando para iniciar um outro artigo só para tratar disso.
3- Expectativa salarial
Aqui eu costumo perguntar ao candidato o quanto ele quer ganhar. E peço que me responda com sinceridade. Eu quero que ele seja sincero com relação a quanto ele acha que é o seu salário ideal e sinto-me livre para ser sincero durante uma eventual negociação.
Às vezes os valores são altos demais. Alguns candidatos merecem o salário alto que pedem, mas eu considero que, por melhor que seja o desenvolvedor, há um limite, digamos, “físico” natural até onde a produtividade de uma pessoa pode chegar. Logo, esse tipo de contratação fica para os momentos em que precisamos muito mais de um cérebro do que de um par de braços. Esses momentos existem e eu advogo a contratação de perfis mais caros quando isso se faz necessário.
Outros simplesmente não são tão bons quanto pensam e não valem o preço que pedem.
Às vezes os valores são mais baixos do que eu imaginava. E, outras vezes, são exatamente o que me parecia ideal. Geralmente esse é o caso quando precisa-se de um perfil com mais equilibrio entre cérebro e braços.
E os valores realmente baixos costumam vir de perfis em que o importante são braços, o que geralmente é um investimento da empresa, já que é necessário treinar e dar suporte constante a esse perfil, o que faz com que o valor aparentemente baixo acabe ficando “na média”.
Expectativa salarial só tira pontos se for o caso de ela ser mais alta do que entendemos que seria o ideal — considerando-se exclusivamente o desempenho do próprio candidato, ou se simplesmente for mais alta do que a empresa pode pagar.
Ah, e expectativa salarial baixa não acrescenta ponto algum.
4- Entrevista
Tudo indo bem, chamo o candidato para comparecer no escritório para conversarmos. Se é remoto, tento conversar via Discord ou qualquer outra ferramenta que permita que façamos uma “sala”. Geralmente mais alguém participa, como o CEO ou “a moça do RH”.
A entrevista serve para tirar dúvidas. Eu geralmente faço algumas perguntas “filosóficas” para saber até que ponto o desenvolvedor age por princípios ou por mero costume. Também pergunto:
- Por que quer sair da empresa em que está ou por que saiu da empresa em que estava?
- Foi tranquilo vir até o escritório?
- Descreva o que você faz hoje.
- Descreva o que você considera um ambiente de trabalho ideal.
- Você pesquisou sobre a empresa? Sabe o que fazemos? (Se não entendeu direito, eu explico.)
- Se eu resolvesse te contratar hoje, dentro de quanto tempo você poderia começar a trabalhar?
- Você tem alguma experiência com trabalho remoto?
- Você tem alguma dúvida quanto à empresa ou à vaga?
Além disso, algumas questões técnicas, claro.
A entrevista pode salvar ou por a perder o processo todo. É curioso ver o que acontece quando o candidato precisa, ativamente, falar sobre si mesmo.
Não tento intimidar ninguém durante entrevistas. Considero que é um cara querendo contratar conversando com outro cara que, por acaso, pode ser contratado. Somos iguais e ambos estamos tentando averiguar se podemos contribuir para o crescimento mútuo.
Mas, mesmo assim, alguns candidatos já comentaram coisas como “ele acabou comigo na entrevista”. Absolutamente não é o propósito e eu acredito que trate-se, em geral, de um problema de auto-confiança do próprio candidato, que sentiria-se tenso em qualquer outra entrevista. No fim das contas, é ele quem define o tom da conversa: ele pode agir como se estivesse sendo “escrutinado”, tenso e na defensiva, ou pode simplesmente conversar comigo, de igual para igual, tirar umas dúvidas, dar opiniões ou fazer graça de alguma coisa. O clima pode ser pesado ou leve, mesmo que eu sempre tente torná-lo leve.
(Algum dia escreverei um artigo sobre entrevistas, também…)
5- Contratação
“Ei, peça as contas aí logo, que estamos te contratando!”
5.1- Aviso prévio
“Oficial” ou não, uma das coisas que absolutamente não faço é pressionar para que o “contratando” deixe de cumprir suas últimas obrigações na empresa em que estava trabalhando. Afinal, se eu espero que ele faça tudo direito quando sair da nossa empresa, tenho que dar-lhe a oportunidade de fazer tudo direito agora que está saindo da empresa em que estava.
Mas para tudo há limites: se o tempo necessário para sair for maior que 30 dias eu não finalizo o acordo de contratação e prefiro continuar a busca.
5.2- Condições
Salário, condições de trabalho, horários, local, atribuições, benefícios… gosto de deixar tudo claro e bem explícito. Não existe coisa pior do que uma pessoa começar a trabalhar já com expectativas frustradas. Nessa hora, aplica-se um “choque de realidade final” para garantir-se que o “contratando” esteja bem ciente de onde está se metendo.
Ninguém reclama de receber o que foi acordado que receberia, certo?
Resumo
Desenvolvedor: teu Github é teu currículo. Colabore com a comunidade de software livre se você quiser emprego numa “empresa bacana”. Fazer isso é o equivalente a “ter diploma e muitas certificações” para entrar numa “empresa grande, velha e chata”.
(Outro assunto que merece um artigo: empresa pequena e legal versus empresa grande e chata.)
Pelo menos é isso que eu e alguns outros responsáveis pela contratação de desenvolvedores acreditamos.
~ A quilometragem pode variar. ~
[Jabá alert]
E por falar em contratação, a Dronemapp tem umas vagas abertas:
~ Apareeeçam! ~
