Como lidar com um júnior?

Como entrar em uma grande empresa sendo um júnior? Como contratar um júnior qualificado sendo uma grande empresa? Abaixo, contarei nossa história sobre a contratação de iniciantes para front-end: como elaboramos tarefas de teste, nos preparamos para entrevistas e organizamos um programa de mentoria para o desenvolvimento e integração de novatos, além do motivo pelo qual perguntas padrão para entrevistas não funcionam.

Eu estou tentando domesticar um júnior

Olá! Meu nome é Pavel, e eu trabalho com front-end na equipe da Wrike. Estamos criando um sistema de gerenciamento de projetos e colaboração. Estou no mundo da web desde 2010, trabalhei por 3 anos em um trabalho remoto no exterior, participei de várias startups e lecionei um curso sobre tecnologias web na universidade. Na empresa, participo do desenvolvimento de cursos técnicos e do programa de mentoria da Wrike para júniores, além de lidar diretamente com a sua contratação.

Por que pensamos em contratar júniores?

Até recentemente, estávamos contratando desenvolvedores de front-end de nível médio ou sênior - aqueles que são suficientemente autônomos para lidar com tarefas de produtos após a integração. No início deste ano, percebemos que queríamos mudar essa política: em um ano, o número de nossas equipes de produtos quase dobrou, o número de front-enders se aproximou da marca de cem, e no futuro próximo, isso deverá dobrar novamente. Há muito trabalho e poucas mãos disponíveis, e no mercado há ainda menos, então decidimos buscar pessoas que estão apenas começando sua jornada no front-end e percebemos que estamos prontos para investir em seu desenvolvimento.

Quem é um júnior?

Essa é a primeira pergunta que nos fizemos. Existem diferentes critérios, mas o princípio mais simples e claro é o seguinte:

Um júnior precisa de uma explicação sobre qual funcionalidade implementar e como fazê-la. Um profissional médio precisa que lhe digam qual funcionalidade é necessária e ele mesmo descobrirá a implementação. Um sênior, por sua vez, irá te explicar por que essa funcionalidade não deve ser feita de forma alguma.

De qualquer forma, um júnior é aquele desenvolvedor que precisa de conselhos sobre como implementar determinada solução. Do que decidimos partir:

1. Um júnior é alguém que deseja se desenvolver e está disposto a trabalhar duro por isso;
2. Ele nem sempre sabe exatamente em que direção quer se desenvolver;
3. Necessita de conselhos e busca ajuda externa - seja de seu líder, mentor ou da comunidade.

Além disso, tivemos algumas hipóteses:

1. Para a posição de júnior, haverá uma tempestade de currículos.É preciso filtrar as respostas aleatórias já na fase de envio dos currículos;
2. O filtro inicial não ajudará — são necessárias mais tarefas de teste;
3. As tarefas de teste assustarão todos — elas não são necessárias.

E, claro, tínhamos um objetivo: 4 juniores em 3 semanas.

Com essa compreensão, começamos a experimentar. O plano era simples: começar com um funil o mais amplo possível e tentar estreitá-lo gradualmente, de modo a conseguir processar o fluxo, mas sem reduzi-lo a 1 candidato por semana.

Publicamos a vaga

Para a empresa: Haverá centenas de respostas! Pensem em um filtro.

Para o júnior: Não tenham medo de um questionário antes de enviar o currículo e a tarefa de teste — isso é um sinal de que a empresa se preocupa com vocês e configurou bem o processo.

No primeiro dia, recebemos cerca de 70 currículos de candidatos 'com conhecimento em JavaScript'. E depois mais. E mais. Não podíamos fisicamente convidar todos para uma entrevista no escritório e escolhemos os que tinham os projetos pessoais mais legais, GitHub ativo ou, pelo menos, alguma experiência.

Mas a principal conclusão que tiramos no primeiro dia foi — a tempestade começou. Era hora de adicionar um formulário de questionário antes do envio do currículo. Sua tarefa era filtrar os candidatos que não estavam dispostos a fazer um esforço mínimo para enviar o currículo e aqueles que não tinham conhecimento e contexto suficiente para pesquisar as respostas corretas.

Ele continha perguntas padrão sobre JS, front-end, web, Ciência da Computação — todos que sabem o que se pergunta em uma entrevista para front-end conhecem. Qual é a diferença entre let/var/const? Como aplicar estilos apenas para telas menores que 600px de largura? Não queríamos fazer essas perguntas na entrevista técnica — a prática mostrou que é possível respondê-las após 2-3 entrevistas, sem entender nada de desenvolvimento. Mas, ao menos, elas puderam nos mostrar inicialmente se o candidato entende, em princípio, o contexto.

Para cada categoria, preparamos de 3 a 5 perguntas e, dia após dia, mudamos seu conjunto no formulário de resposta, até que excluímos as mais fáceis e as mais difíceis. Isso ajudou a reduzir o fluxo — em 3 semanas, recebemos 122 candidatos, com os quais era possível continuar trabalhando. Eram estudantes de TI; jovens que desejaram mudar do backend para o frontend; trabalhadores ou engenheiros entre 25 e 35 anos, que decidiram drasticamente mudar de profissão e se dedicaram de diferentes formas ao autoaprendizado, cursos e estágios.

Conhecendo melhor

Para a empresa: A tarefa de teste não afasta os candidatos, mas ajuda a reduzir a lista de seleção.

Para o júnior: Não copie e cole as tarefas de teste — isso é perceptível. E mantenha seu GitHub organizado!

Se tivéssemos convidado todos para a entrevista técnica, teríamos que realizar cerca de 40 entrevistas por semana apenas para juniores e somente para o frontend. Por isso, decidimos testar a segunda hipótese — sobre a tarefa de teste.

O que era importante para nós na tarefa de teste:

1. Construir uma boa arquitetura escalável, mas sem overengineering;
2. É melhor levar mais tempo, mas fazer bem, do que fazer algo às pressas e enviar com o comentário "definitivamente irei finalizar";
3. O histórico de desenvolvimento no git — cultura de engenharia, iteração no desenvolvimento e o fato de que a solução não foi simplesmente copiada.

Concordamos em que queríamos ver uma tarefa algorítmica e um pequeno aplicativo web. As tarefas algorítmicas foram preparadas no nível de laboratórios dos cursos introdutórios — busca binária, ordenação, verificação de anagramas, manipulação de listas e árvores. No final, decidimos por busca binária como a primeira opção de teste. O aplicativo web deveria ser o jogo da velha usando qualquer framework (ou sem ele).

Quase metade dos candidatos restantes completou a tarefa de teste — recebemos soluções de 54 candidatos. Uma visão incrível — quantas implementações do jogo da velha, prontas para serem copiadas, você acha que existem na rede?

Quantas?Na verdade, parece que apenas 3. E na grande maioria das soluções, eram essas 3 variantes.
O que não gostei:

• copy-paste, ou desenvolvimento seguindo o mesmo tutorial sem uma arquitetura própria;
• as duas tarefas em um único repositório em pastas diferentes, e claro, sem histórico de commits;
• código sujo, violação do DRY, falta de formatação;
• mistura de modelo, visão e controlador em uma única classe com centenas de linhas de código;
• falta de compreensão sobre testes unitários;
• a solução "direta" — uma hardcode de uma matriz de combinações vencedoras 3x3, o que será bastante difícil de expandir para 10x10, por exemplo.

Além disso, prestamos atenção em repositórios vizinhos — projetos legais que estavam indo bem, enquanto várias tarefas de teste de outras empresas eram mais um sinal de alerta: por que o candidato não conseguiu passar para lá?

No final, encontramos ótimas opções em React, Angular, Vanilla JS — acumulamos 29 delas. E também decidimos convidar um candidato sem teste devido aos seus projetos incríveis. Nossa hipótese sobre a utilidade das tarefas de teste foi confirmada.

Entrevista técnica

Para a empresa: Vocês não receberam apenas intermediários/sêniores! É necessário um enfoque mais individual.

Para o júnior: Lembrem-se, isso não é um exame — não tentem se calar e tirar uma nota mediana ou confundir o professor com um fluxo de todo o seu conhecimento para que ele fique confuso e dê uma nota "excelente".

O que queremos entender na entrevista técnica? Uma coisa simples — como o candidato pensa. Provavelmente, ele possui algumas habilidades técnicas, dado que passou pelas primeiras etapas de seleção — resta saber se ele sabe aplicá-las. Concordamos em 3 tarefas.

A primeira — sobre algoritmos e estruturas de dados. Com uma caneta, em um pedaço de papel, em pseudo-código e com desenhos, discutimos como copiar uma árvore ou como remover um elemento de uma lista encadeada. A desagradável descoberta foi que nem todos entendem recursão e como referências funcionam.

A segunda — live coding. Acessamos o codewars.com, escolhemos tarefas simples como ordenar um array de palavras pela última letra e, durante 30-40 minutos, tentamos, junto com o candidato, fazer todos os testes passarem. Parecia que não deveria haver surpresas de pessoas que conseguiram implementar jogo da velha — mas na prática, nem todos conseguiram perceber que o valor precisava ser armazenado em uma variável e que a função deveria retornar algo através do return. Embora eu realmente espero que isso tenha sido nervosismo e que eles conseguiram resolver essas tarefas em condições mais leves.

Finalmente, a terceira — um pouco sobre arquitetura. Discutimos como poderia ser feita uma barra de pesquisa, como o debounce funciona, como renderizar vários widgets nas sugestões de pesquisa, como o frontend pode interagir com o backend. Foram encontradas várias soluções interessantes, incluindo sobre renderização do lado do servidor e web sockets.

Realizamos 21 entrevista seguindo esse modelo. O público era completamente diversificado — vamos usar quadrinhos:

1. «Raketa». Nunca se acalma, sempre se mete em tudo e nas entrevistas te sobrecarrega com um fluxo de pensamentos, muitas vezes sem relação direta com a pergunta feita. Se fosse na universidade, seria aquela tentativa de mostrar todos os seus conhecimentos, quando você só lembra que não estudou aquele tópico na noite anterior — de qualquer forma, não conseguiria responder.
2. «Groot». É difícil estabelecer contato com ele, porque ele é o Groot. Nas entrevistas, é necessário um tempo considerável para aquecê-lo, extrair respostas palavra por palavra. E se for um bloqueio mental, tudo bem — caso contrário, no dia a dia de trabalho será muito desafiador.
3. «Drax». Anteriormente trabalhava com transporte de carga e aprendeu programação apenas com JS pelo Stackoverflow, por isso nem sempre consegue entender do que se está falando na entrevista. Apesar disso, é uma boa pessoa, tem boas intenções e deseja se tornar um ótimo desenvolvedor front-end.
4. E talvez, «Star-Lord». No geral, um candidato razoável, com quem é possível negociar e estabelecer um diálogo.

Ao final de nossas investigações 7 candidatos chegaram à fase final, confirmando suas habilidades técnicas com uma excelente tarefa de teste e boas respostas nas entrevistas.

Cultura de Fit

Para a empresa: Você trabalhará com ele! O candidato está realmente pronto para trabalhar extremamente duro para seu desenvolvimento? Ele se integrará na equipe?

Para o júnior: Você trabalhará com eles! A empresa está realmente disposta a investir no crescimento dos juniores, ou simplesmente jogará todo o trabalho sujo sobre você por um salário baixo?

Cada júnior, além da equipe de produto, cuja liderança precisa concordar em aceitá-lo, é atribuído a um mentor. A tarefa do mentor é guiá-lo através de um processo de integração de três meses e aprimoramento de habilidades técnicas. Portanto, em cada cultural fit, éramos mentores e fazíamos a nós mesmos a pergunta: “Vou assumir a responsabilidade de desenvolver esse candidato em 3 meses seguindo nosso plano?”

Essa etapa transcorreu sem particularidades e, no final, nos trouxe 4 ofertas, 3 das quais foram aceitas, e os meninos se juntaram às equipes.

Vida após a oferta

Para a empresa: Cuide dos seus juniores ou outros o farão!

Para o júnior: AAAAAAAAAAA!

Quando um novo funcionário chega, ele precisa ser integrado — informado sobre os processos, explicado como tudo funciona na empresa e na equipe, e como ele deve trabalhar em geral. Quando um júnior chega, é necessário entender como desenvolvê-lo.

Ao pensar sobre isso, elaboramos uma lista de 26 habilidades que, em nossa opinião, um júnior deve ter ao final do período de integração de três meses. Isso incluiu hard skills (de nossa stack), conhecimento sobre nossos processos, Scrum, infraestrutura e arquitetura do projeto. Nós organizamos isso em um roadmap distribuído ao longo de 3 meses.

Por exemplo, aqui está o roadmap do meu júnior.

A cada júnior, atribuirmos um mentor que trabalha com ele de maneira individual. Dependendo do mentor e do nível atual do candidato, as reuniões podem ocorrer de 1 a 5 vezes por semana, com duração de 1 hora cada. Os mentores são desenvolvedores frontend voluntários que querem fazer algo a mais do que apenas escrever código.

Parte da carga dos mentores é aliviada pelos cursos sobre nossa stack — Dart, Angular. Os cursos são realizados regularmente para pequenos grupos de 4-6 pessoas, onde os alunos estudam sem se afastar do trabalho.

Durante 3 meses, coletamos periodicamente feedback de júniores, seus mentores e líderes, e ajustamos o processo individualmente. De 1 a 2 vezes ao longo do período, realizamos uma avaliação das habilidades desenvolvidas; uma avaliação semelhante é feita ao final — com base nisso, são formuladas recomendações sobre o que realmente deve ser aprimorado.

Conclusão

Para a empresa: Vale a pena investir em júniores? Sim!

Para o júnior: Procure empresas que selecionam candidatos cuidadosamente e sabem como desenvolvê-los.

Em 3 meses, analisamos 122 questionários, 54 testes e realizamos 21 entrevistas técnicas. Isso nos trouxe 3 ótimos júniores, que agora completaram metade de seus roadmaps de integração e aceleração. Eles já estão resolvendo tarefas reais de produto em nosso projeto, onde só no frontend há mais de 2.000.000 linhas de código e mais de 400 repositórios.

Descobrimos que o funil para júniores pode e deve ser bastante complexo, mas, no final, apenas aqueles que realmente estão prontos para trabalhar duro e se dedicar ao seu desenvolvimento passam por ele.

Agora, nossa principal tarefa é finalizar os roadmaps de três meses para o desenvolvimento de cada juniores em um formato de trabalho individual com um mentor e cursos em grupo, coletar métricas, feedback dos leads, mentores e dos próprios juniores. Com isso, o primeiro experimento poderá ser considerado concluído, permitindo tirar conclusões, melhorar o processo e reiniciá-lo para seleção de novos candidatos.

Fonte: habr.com