Como você avaliaria o perfil do Github de um programador? [fechadas]

Muitas pessoas na comunidade de código aberto dizem que consideram fortemente o perfil do Github de um candidato ao contratar.

Sou ativo no Github, com alguns projetos meus e algumas contribuições para outros. Mas, olhando para o meu próprio perfil como se eu fosse um empregador, vejo muito barulho: projetos que clonei, mas nunca contribuí, etc. Os projetos e patches dos quais me orgulho não se destacam.

Se você avalia o perfil das pessoas no Github, como o faz? E como desenvolvedor, devo fazer algo diferente - por exemplo, excluir repositórios clonados nos quais não estou trabalhando ativamente?

Eu usei perfis do GitHub, fluxos de twitter e blogs, todos como indicadores de qualidade na programação de entrevistas / triagem de candidatos. Todos eles geram sinais diferentes à sua maneira.

9 em cada 10 candidatos nunca enviaram um único patch para um único projeto de código aberto. Até a atualização de documentação quebrada coloca você no escalão superior do desenvolvedor. Isso mostra que você está familiarizado o suficiente com algum pacote de código-fonte aberto para saber o que há de errado, você se importa com o envio de um patch e os mantenedores desse pacote acham que seu trabalho é bom o suficiente para ser incluído. Como generalização, mostra que você toma a iniciativa de deixar as coisas sujas melhores do que as encontrou.

Parece muito simples, mas novamente 9 em cada 10 desenvolvedores nunca se preocupam em dar esse passo importante.

Portanto, um único patch aceito parece ótimo. Uma longa história de 2 a 3 patches simples por trimestre é ainda melhor. Ainda melhor do que isso seria contribuir com algo digno de nota.

1. Contribuições substanciais para importantes projetos de código aberto (superior a 0,1% -1% dos candidatos)
2. Histórico estendido de pequenas contribuições para qualquer projeto (superior a 5% dos candidatos)
3. Um único patch de uma linha para um pacote relativamente desconhecido (superior a 10% dos candidatos)

Na mesma nota, os desenvolvedores que twittam sobre beber e assistir a filmes o tempo todo tendem a fazer contratações medíocres. Um fluxo de tuítes em que cada terceira mensagem é sobre tecnologia aponta para o tipo de desenvolvedor de cães de ferro-velho raivoso que se preocupa com o seu ofício e busca incansavelmente soluções.

Os blogs também são um ótimo indicador de qualidade, mas para o estilo de comunicação e não para as proezas técnicas. Quantos programadores se preocupam em escrever o artigo # 1 do blog? O mesmo tipo de pontos de corte de 1% / 5% / 10% se aplica aqui.

Como desenvolvedor, eu não faria nada diferente na conta do Github. Não é problema seu que a conta do Github não possa ser avaliada rapidamente. E estritamente falando, também não é problema do Github - destina-se ao desenvolvimento de software colaborativo, não para avaliar desenvolvedores.

Deve haver ferramentas especiais para avaliação do usuário, trabalhando com dados do Github. Por enquanto, você pode usar sites de terceiros. Por exemplo, há http://coderwall.com - uma rápida olhada no perfil mostra se o desenvolvedor já enviou um patch, se alguém bifurcou seu projeto, quantos idiomas ele usa ...

Outra opção seria gerar automaticamente esse resumo em sua página inicial usando a API do Github: uma lista personalizada de projetos com vários garfos e observadores, a última vez que foram atualizados etc.

Tenha cuidado ao avaliar candidatos com base em um perfil do GitHub. O GitHub não é um CV. Existem muitos engenheiros excelentes que não têm perfis chamativos, por várias razões: eles podem ter trabalhado para empresas de código fechado ou podem gastar mais tempo em outras atividades, como família, hobbies, etc.

Embora uma contribuição para um projeto de código aberto possa ser uma vantagem para um candidato (como o @marshally mencionou), você deve avaliar e contratar da maneira antiga, conversando.

Algumas referências que encontrei logo após ler este tópico:

• GitHub não é seu currículo
• Usuários mais ativos do GitHub , esp. estes 2 comentários de colaboradores importantes: 1 , 2 .

Eu acho que você pode, você só precisa de um tempo extra olhando se ele está realmente ativo no github ou não, olhando para o fluxo de atividades dele.

Você pode ver como empurra, problemas, etc., o que é um grande indicador de que ele está realmente ativo e trabalhando em algo, em vez de apenas ficar brincando.

Se alguém estiver olhando para avaliá-lo, deve olhar sua imagem "verdadeira", o código de baixa qualidade e também o bom código. Eu entrevistei recentemente e o entrevistador me pediu para abrir minha conta no github, depois ele navegou por um dos meus repositórios, olhou através de algum código de baixa qualidade que escrevi um ano atrás em um idioma que estava aprendendo.

Então, ele me perguntou, como você pode melhorar isso? Eu respondi todas as respostas corretamente, porque sabia como melhorar isso, mas realmente não me importava em consertar esse projeto, porque era apenas um projeto para aprender.

O mesmo acontece com a conta stackoverflow.com. É mais óbvio no SO, pois você tem reputação, etc.

Pessoalmente, não vejo o valor de olhar o perfil deles por si só. Como você disse corretamente, tende a haver uma taxa de ruído grande o suficiente para não valer a pena peneirar.

Recentemente, me inscrevi e fui dispensado do meu primeiro trabalho de desenvolvedor e achei o processo que eles usaram muito justo. Em vez de perguntar sobre perfis e afins, eles se concentraram nos projetos que escolhi listar no meu currículo.

Na realidade, existem apenas algumas coisas que você precisa coletar de um candidato, as principais são: eles podem se desenvolver, são motivados e como funcionam? Tudo isso pode ser obtido a partir de uma pré-entrevista ou conversa na primeira rodada, isso pode ser feito por telefone ou 1 hora na entrevista no local.

A idéia é deixar o candidato falar e descobrir onde está sua paixão. Descobri que esse estilo mais descontraído me abriu muito mais do que enviar meu perfil para qualquer um dos serviços que utilizo relacionados ao desenvolvimento.

Foi bom não ser lançado em uma entrevista técnica primeiro. Parecia que eles tinham a atitude correta de encontrar um bom "time" e depois avaliar as habilidades.