Como fazer o onboarding de desenvolvedores juniors?

[matheusml]

E aí galera :)

Queria saber sobre a experiência de vocês com novos devs (principalmente os juniors):

• Como vocês fazem o treinamento deles?
• O que pedir pra eles estudarem?
• É interessante fazer pair?

A ideia é basicamente ter um mini-guia para os seniors que querem contratar juniors e ajudar no onboarding deles.

Abraços!

[woliveiras]

Baseado na experiência que eu tive no meu último trampo, com o @teles (:heart:), vou contar um pouco como foi ser junior dev:

Quando eu entrei no VD tive claramente a certeza de que teria uma pessoa ao meu lado pra me ajudar, pois o Teles sentou do lado e foi trocando muita ideia comigo sobre como tudo iria funcionar. Ele foi me orientando e mostrando que os meus medos eram normais e a equipe já sabia do que estaria por vir; que era a baixa produtividade até eu pegar as manhas da plataforma e como a empresa funcionava. - Esse era um dos meus maiores medos.

Essa transparência fez muita diferença na minha confiança em pegar tarefas mais complicadas sem medo de estar demorando demais pra resolver.

Nós trocamos ideia e ele identificou onde eram minhas maiores dificuldades. No começo ele ia me passando tarefas com itenção de me mostrar como tudo funcionava, ensinar sobre a arquitetura da plataforma e me ensinar mais sobre as coisas que eu precisava aprender (Angular e esquema de build mais complexo).

Eu aprendi muito com essas tarefas!

Logo depois ele começou a aumentar o nível de complexidade das tarefas e, quando era algo muito complicado, fazia pair programming comigo pra me ajudar a pensar. Ele não ensinava a resolver, mas ia discutindo comigo pra que eu chegasse a uma solução e ele só me ajudava se eu não soubesse implementar. Então ele me orientava como escrever a solução.

Fora esse esquema de direcionar tarefas e pair programming, discutíamos muito sobre programação no geral. Seria uma reunião semanal (como as que rolam em algumas empresas), mas como eram só duas pessoas discutíamos a qualquer hora e sem data marcada mesmo.

Depois que eu já estava mais treinado, isso em uns 2 meses, ele começou a me botar no fogo mesmo... Ele trazia features completas e eu que tinha que planejar tudo o que iríamos fazer. Desde quebrar em tarefas, como iríamos implemtnar essas tarefas, como planejar os roadmaps das entregas, tanto as da feature que eu estava planejando quanto as outras que já estavam em andamento e não poderíamos parar.

Ele validava tudo isso comigo na base de jogar questões no ar e eu ter que resolver.

E quanto mais eu perguntava, mais ele virava a pergunta pra mim e me fazia pensar mais ainda.

Parecia uma discussão filosófica, mas era arquitetura de software e decisões estratégicas de engenharia.

O que mais me fez evoluir foi:

• transparência no começo, me mostrando que eu seria improdutivo e eles sabiam disso
• me passar pequenas tarefas e ir aumentando a complexidade delas
• me passar tarefas FODAS e fazer pair programming, mas sem encostar em código, só me questionando e auxiliando a tomar decisões
• me ensinar através de conversas sobre desenvolvimento
• soltar a bomba, literalmente, na minha mão, porém sempre estar ali pra ajudar

Acho que o mais importante é isso: ter a ciência que a equipe será improdutiva por, pelo menos, uns 3 ou 4 meses, e deixar isso claro pra pessoa que entra pra ela não ficar muito ansiosa e essa ansiedade atrapalhar toda a aprendizagem. E ter alguém com tempo plajenado nas sprints pra apoiar a pessoa nova.

Fora todo o apoio do Teles, teve também a ajuda do restante da equipe que sempre me orientava e me ajudava (as vezes também com pair programming) com as mais diversas tarefas.

[shadowmaru]

Então, aqui na Bio Ritmo não temos o costume de contratar devs juniors, mas vou falar como recepcionamos todos aqui:

• Reservamos as primeiras semanas para essa integração com a equipe e com os nossos projetos
  • No caso de alguém remoto, trazemos a pessoa para ficar aqui em SP por uma semana para essa integração, aí ela é mais concentrada
• Quando a pessoa chega, (idealmente) ela já tem a máquina, os acessórios, uma camiseta e algum outro brinde, e já está incluída em todas as ferramentas que usamos (email, issue tracker, slack, etc.)
• Esse primeiro dia é dedicado a instalar as coisas na máquina, torná-la usável
• Há uma apresentação do time, das equipes e da nossa forma de trabalhar, pelo gerente de desenvolvimento
• Também rolam alguns processos do DP, aí meio que foge do nosso controle
• Nos dias seguintes, a pessoa fica instalando os sistemas em que ela vai trabalhar
• Também acontecem apresentações desses sistemas feitas pelas pessoas que os desenvolvem
• Há também uma apresentação sobre a nossa infraestrutura de hospedagem, dada pela equipe de devops
• Mais pro fim da semana, apresentamos (pessoalmente) a empresa, principalmente para os setores que terão mais contato com a pessoa
• Há também uma visita a uma unidade Bio Ritmo ou Smart Fit
• Depois que os sistemas estão configurados, fazemos alguns dias de pair pra explicar mais a fundo algumas partes dos sistemas
• Há um repositório com vários tipos de documentação, que vão desde explicações técnicas de arquitetura até os processos do DP (dissídio, preenchimento da folha de ponto, etc.)

Bom, se fosse fazer isso para juniors, acho que o ritmo teria que ser um pouco mais lento, e com mais explicações e pair programming. Participar dos plannings sem necessariamente assumir alguma tarefa, e por aí vai.

Já estou lá faz tempo, e no começo era na base do 'se vira aí'. Achei que isso era meio ruim, daí dei a ideia de termos esse processo. Hoje eu estou responsável por esse onboarding, e sempre busco feedback para melhorar esse processo para fazer as pessoas se sentirem bem-vindas na empresa. Quero ver mais comentários de outras pessoas. É isso.