Perguntas frequentes para um gerente de contratação de engenharia de software - Parte 3 de 5: Portfólios e GitHubs

As Entrevistas Técnicas evoluíram muito desde que fiz a transição de Engenheiro de Software para Gerente de Engenharia. Particularmente na era pós-Covid, houve uma maior ênfase na pessoa, o que considero uma mudança importante e bem-vinda.

Ao longo da década entrevistando centenas de programadores, também tive o prazer de trabalhar com vários bootcamps, faculdades e centenas de candidatos a emprego no LinkedIn. Em meio a todas as mudanças nos últimos anos, em vários locais e mídias, algo permaneceu consistente: as perguntas que me fazem.

Com isso em mente, pensei - por que não fazer um FAQ da minha perspectiva como gerente de contratação?

Embora essa seja minha perspectiva, ela se baseia em anos de observação e dados de apoio. Mas dito isso, conselho não é fato. Você pode discordar de certos pontos, e tudo bem. As opiniões das quais discordamos nos permitem entender melhor nossos próprios pontos de vista. Na melhor das hipóteses, espero que essas respostas o ajudem a conseguir o emprego dos seus sonhos. Na pior das hipóteses, espero que o ajudem a formar suas próprias ideias sobre como abordar sua carreira.

Nesta parte, vou me concentrar nas perguntas que recebi sobre portfólios e GitHubs .

Em Portfólios

1. Eu realmente preciso de um portfólio/site?

   Realmente depende - mas sou extremamente a favor deles. Currículos me mostram seu lado profissional. Portfólios mostram sua personalidade, seus interesses. Eles dão aos gerentes de contratação uma noção diferente de quem você é e como deseja crescer.

   
   

   Claro, nem todo mundo precisa de um - ou tem o desejo de construir um. Conheço muitos codificadores de sucesso que não têm um portfólio/site e nunca precisaram de um. Na verdade, a maioria dos desenvolvedores que conheço não tem um. E se for esse o caso, por que insisto neles?

   
   

   A resposta simples é que é um jogo de probabilidades. A contratação de tecnologia é um mundo selvagem no momento - há muita demanda, muitos candidatos, é ultracompetitivo, mas as pessoas também estão lutando para encontrar empregos. Um portfólio não garante que você consiga um emprego, mas oferece uma vantagem significativa sobre outros candidatos, desde que você o faça corretamente.

   
   

   Seu portfólio não precisa ser um grande empreendimento - e como os benefícios superam em muito os custos, acho que construí-los faz muito sentido. Como os portfólios são pessoais, acho que as pessoas ficam sobrecarregadas com "a arte do possível" - e então nunca produzem nada.

   
   

   Se você construir seu portfólio de forma iterativa, começando pequeno e expandindo apenas conforme necessário e conforme tiver tempo, é uma ótima maneira de se estabelecer.

   
   

   Para saber mais, aqui estão alguns recursos sobre como criar um portfólio matador:

   • Vamos Falar de Portfólios!

   • Vamos Falar (Ainda Mais!) Sobre Portfólios !

   • 7 etapas para criar seu MVP de portfólio

   • Lumbobot

     
     

2. O que eu coloco no meu portfólio?

   Em primeiro lugar, conheça seu público. Seu portfólio não é para seus amigos, sua família - seu público real é o gerente de contratação. Você deseja focar seu conteúdo de forma que seja fácil de consumir - então concentre-se em como você apresenta as coisas. Pense nisso como seu currículo + criatividade. Adicione algum estilo a ele, mas torne-o utilizável.

   
   

   Sou um grande fã de visuais rápidos que ajudam alguém a ter uma ideia do que você pode fazer - seja listando seus idiomas, listando seus anos de experiência com cada um, listando seus projetos, tornando-os visuais, interativos, mas não adicione qualquer "atrito" a ele também. Com isso, quero dizer que apresentações de slides lentas que exigem que eu sente e espere que as coisas apareçam e desapareçam não é uma boa abordagem. Liste tudo para que eu possa ver, consumir e seguir em frente.

   
   

   Outra coisa é: dê um pouco de vida. Não faça parecer que você o construiu anos atrás e se esqueceu dele - adicione alguns elementos dinâmicos, para que esteja sempre com uma aparência nova. Faça com que ele alimente seu twitter, ou apenas crie uma pequena integração em seu blog, ou apenas tenha um "microblog" que mantenha as pessoas atualizadas sobre o que você está trabalhando.

   
   

   O conteúdo principal está em torno de seus projetos. O que você construiu, o que você está construindo. Inclua boas anotações que cubram o que você aprendeu, o que o desafiou, do que você se orgulha, o que você faria melhor. Impactos e Resultados.

   
   

   Este modelo que fiz é o mínimo que você deve listar. É tudo estático, tem elementos de design mínimos, mas realmente ajuda um gerente de contratação a entender quem você é:

   
   

   
   

   

   
   

   Como você pode ver, os principais itens a serem listados são:

   • A pilha de tecnologia e metodologias que você conhece

   • Uma mini-biografia

   • Links importantes - para seu GitHub, seu currículo, seu LinkedIn,

   • Visuais rápidos que resumem sua carreira

   • Projetos, com a pilha de tecnologia e links para o GitHub

   • Seções "ao vivo" que você pode atualizar facilmente com o que está trabalhando/lendo (atualize-as talvez uma vez por mês).

     
     

   Como eu disse antes, você deve levar mais de um fim de semana para criar algo assim e isso ajudará a dar ao seu aplicativo um pouco mais de vantagem.

   
   

   À medida que você cresce em sua carreira, atualizá-la torna-se bastante trivial.

   
   

3. Não posso simplesmente usar o GitHub?

   Você pode - sim. Mas não basta despejar seus projetos no GitHub e encerrar o dia. Crie uma página de destino adequada do GitHub e use-a como seu portfólio.

   
   

   Você pode construí-lo usando o GitHub Pages - basta seguir os mesmos princípios listados acima.

   
   

4. Devo obter meu próprio nome de domínio?

   Você não precisa de um - mas ter seu próprio domínio é como ter seu estacionário. É um toque agradável.

   
   

5. Quão pessoal devo entrar no meu site? Devo compartilhar fotos de família? Receitas? Uma foto da minha salamandra de estimação?

   Compartilhe o que você gosta - apenas saiba o propósito. Não é para ser um perfil do Facebook - mas também não é para ser um perfil do LinkedIn. Seu público seria um gerente de contratação.

   
   

   Ajude-os a conhecer o lado social e profissional de você.

   
   

6. Devo me preocupar com SEO, page ranks, etc.?

   Não. Isso acabou. Mantenha seu HTML limpo - mas também não se estresse com isso.

   
   

   Faça apenas o que for mais relevante para as funções que você exerce: se for um desenvolvedor Node, construa coisas com Node. Se for SEO, com certeza - otimize para os mecanismos de pesquisa. Mas se você é um engenheiro de SQL, provavelmente não vou julgá-lo por suas habilidades em HTML/CSS.

   
   

7. Devo incluir um currículo para download / meu e-mail?

   Em última análise, isso depende de você - mas se você incluir qualquer um deles, tenha cuidado com as informações que torna públicas. Talvez remova seu número de telefone de seu currículo para download. Certifique-se de que seu provedor de e-mail filtrará spam.

   
   

   Como alternativa, direcione as pessoas para o seu LinkedIn ou inclua um formulário onde elas possam entrar em contato com você.

No GitHub

1. Como deve ser minha página de destino do GitHub?

   Escreva um ReadMe simples que imite o conteúdo do seu portfólio. Simples, limpo e elegante. Você vai querer mantê-lo atualizado, portanto, certifique-se de construí-lo de forma que seja um esforço mínimo.

   
   

   Fixe seus projetos e inclua links importantes para seu portfólio/LinkedIn.

   
   

   Você não precisa exagerar embora. Embora existam alguns incríveis por aí, acho que mantê-lo simples é a melhor abordagem (a menos que você esteja construindo isso no lugar de um portfólio).

   Para referência, aqui está minha página inicial do GitHub: GitHub - Alishah Novin

   
   

2. Preciso realmente criar minhas páginas de projeto?

   Certifique-se de ter um arquivo ReadMe. Você pode fazer muito com eles - e eu os abordaria como se você estivesse escrevendo para outros desenvolvedores (pensando secretamente no gerente de contratação).

   
   

   Em um ambiente profissional, você frequentemente precisará explicar o que um produto ou recurso faz, como deve ser usado, quais são suas limitações etc. outros desenvolvedores que consumirão seu projeto, lembre-se de que seu público real é o gerente de contratação.

   
   

   Forneça uma visão geral, forneça capturas de tela, forneça um registro de alterações. Documente as coisas para mostrar que você pode comunicar conceitos técnicos.

   
   

   Outro exemplo, para referência, é minha página do GitHub para código/colisão . Lembre-se de que existem muito melhores por aí, mas criei esta página para dar uma ideia de como deve ser o seu mínimo.

   
   

   Não basta carregar seu projeto e chamá-lo um dia.

   
   

3. Preciso me preocupar com a qualidade do meu código ou com o quanto comentei?

   Seu código será analisado, sim. As pessoas vão procurar comentários e lê-los. Eles provavelmente não entrarão em detalhes, mas você deve certificar-se de que seus arquivos de código estejam apresentáveis.
   
   Trate-o como se fosse um projeto real. Especialmente se você melhorou um algoritmo, certifique-se de que ele apareça em seus comentários de commit.
   
   Os gerentes de contratação provavelmente não vão sentar lá e dissecar seu código para garantir que seja hipereficiente - mas eles vão analisá-lo para ter uma noção do que você sabe ou não sabe.
   
   Tenha cuidado com a engenharia excessiva ou com a criação de código espaguete complicado demais. Na verdade, tente reduzir qualquer cheiro de código.
   
   Um ótimo recurso de que gosto e que ajuda a escrever código superapresentável é Refactoring and Design Patterns .
   

   
   

4. Devo incluir meu GitHub no meu currículo?
   Sim. Como um URL, não como texto vinculado. Os currículos são impressos - e, até onde eu sei, você não pode clicar em um link no papel.
   

   
   

5. Devo incluir meu GitHub no meu LinkedIn?
   Sim.
   

   
   

6. Preciso me preocupar com a atividade do meu GitHub?
   Não. Essa é uma pressão desnecessária que nós, programadores, colocamos sobre nós mesmos. Queremos a cobiçada parede verde. Embora ter vários commits diários seja ótimo, isso não garante um emprego. Preocupe-se menos em ter uma alta frequência de commits e se preocupe mais em ter commits impactantes: projetos que mostram sua evolução e crescimento como desenvolvedor. Isso pode ser apenas alguns por mês.
   
   Por outro lado, certifique-se de não ter toneladas e toneladas de projetos abandonados/inacabados. Tenha ideias completas - todas podem estar em vários estágios de conclusão, mas não tenha mais de 2 projetos que não estejam em um estágio de MVP. Termine o que você começou. Sacrifique a novidade pelas nuances.

   
   

7. Devo incluir projetos de curso?

   O curso só é bom na ausência de seus próprios projetos. Mantenha os trabalhos do curso visíveis até que você tenha seus próprios projetos - então oculte as tarefas.

   
   

8. Devo incluir todos os meus projetos?
   Inclua apenas aquelas que são ideias completas e completas - elas não precisam ser produtos completos. Gosto de distinguir entre projetos e produtos. Um "Produto" está construindo um clone completo do Twitter/Facebook. O tamanho e o escopo dos produtos podem ser tão grandes que você pode nunca completá-los - e não será muito bom porque sobrecarregará o gerente de contratação.
   
   "Projetos" são unidades de trabalho mais discretas. Uma biblioteca. Um experimento.
   
   Você definitivamente deve compartilhar projetos e incluir em sua redação sobre o que eles eram - e o que você tentou alcançar.
   
   Inclua "Produtos" desde que estejam suficientemente adiantados para poderem ficar de pé sozinhos. Se você nunca passou da tela de login, não a inclua.
   
   Vou reiterar* (na verdade, estou apenas copiando e colando)*: Certifique-se de não ter toneladas e toneladas de projetos abandonados/inacabados. Tenha ideias completas - todas podem estar em vários estágios de conclusão, mas não tenha mais de 2 projetos que não estejam em um estágio de MVP. Termine o que você começou. Sacrifique a novidade pelas nuances.

   
   

Vale a pena notar que todas essas respostas são minhas próprias opiniões subjetivas que generalizei para pequenas e grandes empresas. Eles refletem meu estilo pessoal, mas também afirmo alegremente que eles também não estão 100% certos. É o que funcionou para mim - mas adoro receber informações e opiniões de outras pessoas.

Tem alguma dúvida que não respondi? Conecte-se comigo no LinkedIn e envie-os para mim!

Publicado também aqui .