Cléber Zavadniak Follow

Cristão reformado, programador, linuxeiro, nerdão, pobrão

May 12 · 11 min read

Github como currículo e visão geral sobre

processos seletivos
Ou, pelo menos, os capitaneados pela minha pessoa

Esse chuveiro tem mais chance de ser contratado do que você. Entendedores entenderão.

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

Cara, ela tá tão na sua... ´sqn

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.

No, i'm not!

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”.

Hummm… continue…

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:

 Oportunidade: Desenvolvedor Python
PLENO/SÊNIOR
medium.com

Oportunidade: Desenvolvedor Swift/iOS

Pleno
medium.com

~ Apareeeçam! ~