Como entrar em uma grande empresa se você é júnior? Como contratar um júnior decente se você é uma grande empresa? Abaixo, contarei nossa história de contratação de iniciantes no front-end: como trabalhamos nas tarefas de teste, nos preparamos para conduzir entrevistas e construímos um programa de mentoria para o desenvolvimento e integração de recém-chegados, e também por que as perguntas padrão da entrevista não são necessárias. não funciona.
Estou tentando domar Junior
Olá! Meu nome é Pavel, faço trabalho de front-end na equipe Wrike. Criamos um sistema para gerenciamento e colaboração de projetos. Trabalho com web desde 2010, trabalhei 3 anos no exterior, participei de diversas startups e ministrei curso sobre tecnologias web na universidade. Na empresa, estou envolvido no desenvolvimento de cursos técnicos e do programa de mentoria Wrike para juniores, além de recrutá-los diretamente.
Por que pensamos em contratar juniores?
Até recentemente, recrutávamos desenvolvedores de nível médio ou sênior para o frontend – independentes o suficiente para realizar tarefas de produto após a integração. No início deste ano, percebemos que queríamos mudar esta política: ao longo do ano, o número de nossas equipes de produto quase dobrou, o número de desenvolvedores front-end se aproximou de cem e, num futuro próximo, tudo isso irá tem que dobrar novamente. Há muito trabalho, poucas mãos livres e há ainda menos no mercado, então decidimos recorrer à galera que está começando sua jornada no front-end e percebemos que estamos prontos para investir em seus desenvolvimento.
Quem é júnior?
Esta é a primeira pergunta que nos perguntamos. Existem diferentes critérios, mas o princípio mais simples e compreensível é este:
Junior precisa ser explicado qual recurso e como fazê-lo. O Médio precisa ser explicado qual recurso é necessário e ele mesmo descobrirá a implementação. O próprio signatário explicará por que esse recurso não precisa ser feito.
De uma forma ou de outra, um júnior é um desenvolvedor que precisa de conselhos sobre como implementar esta ou aquela solução. O que decidimos construir:
- Junior é alguém que quer se desenvolver e está pronto para trabalhar muito para isso;
- Ele nem sempre sabe em que direção quer se desenvolver;
- Precisa de conselhos e busca ajuda externa - de seu líder, mentor ou da comunidade.
Também tínhamos várias hipóteses:
- Haverá uma tempestade de respostas à posição de junho. Você precisa filtrar as respostas aleatórias na fase de envio do seu currículo;
- Um filtro primário não ajudará. — são necessárias mais tarefas de teste;
- As tarefas de teste vão assustar todo mundo - eles não são necessários.
E claro, tínhamos um objetivo: 4 juniores em 3 semanas.
Com essa constatação, começamos a experimentar. O plano era simples: começar com o funil mais amplo possível e tentar estreita-lo gradativamente para poder processar o fluxo, mas sem reduzi-lo para 1 candidato por semana.
Publicamos uma vaga
Pela empresa: Haverá centenas de respostas! Pense em um filtro.
Para júnior: Não tenha medo do questionário antes de enviar seu currículo e tarefa de teste – isso é sinal de que a empresa cuidou de você e configurou bem o processo.
No primeiro dia, recebemos cerca de 70 currículos de candidatos “com conhecimento de JavaScript”. E então novamente. E mais longe. Não podíamos fisicamente convidar todos para uma entrevista no escritório e escolhemos entre eles os caras com os projetos de estimação mais legais, o Github ao vivo ou pelo menos a experiência.
Mas a principal conclusão que tiramos logo no primeiro dia foi que a tempestade havia começado. Agora é a hora de adicionar um formulário de questionário antes de enviar seu currículo. Seu objetivo era eliminar candidatos que não estivessem dispostos a fazer o mínimo esforço para enviar um currículo e aqueles que não tivessem o conhecimento e o contexto para pelo menos pesquisar no Google as respostas corretas.
Continha perguntas padrão sobre JS, layout, web, ciência da computação - todos que imaginam o que perguntam em uma entrevista inicial as conhecem. Qual é a diferença entre let/var/const? Como posso aplicar estilos apenas a telas menores que 600px de largura? Não queríamos fazer essas perguntas em uma entrevista técnica - a prática tem mostrado que elas podem ser respondidas após 2 a 3 entrevistas sem qualquer compreensão do desenvolvimento. Mas conseguiram inicialmente mostrar-nos se o candidato, em princípio, compreende o contexto.
Em cada categoria preparamos de 3 a 5 questões e dia após dia alteramos seu conjunto no formulário de respostas até eliminarmos as mais aceitáveis e as mais difíceis. Isso nos permitiu reduzir o fluxo - em 3 semanas recebemos 122 candidatos, com o qual poderíamos trabalhar mais. Estes eram estudantes de TI; caras que queriam passar do back-end para a frente; trabalhadores ou engenheiros, de 25 a 35 anos, que queriam mudar radicalmente de profissão e dedicavam esforços variados à autoeducação, cursos e estágios.
Conhecendo-se melhor
Pela empresa: a tarefa do teste não desanima os candidatos, mas ajuda a encurtar o funil.
Para júnior: Não copie e cole os testes - é perceptível. E mantenha seu github em ordem!
Se convocássemos todos para uma entrevista técnica, teríamos que realizar cerca de 40 entrevistas por semana apenas para juniores e apenas no front-end. Portanto, decidimos testar a segunda hipótese - sobre a tarefa de teste.
O que foi importante para nós no teste:
- Construir uma boa arquitetura escalável, mas sem excesso de engenharia;
- É melhor demorar mais, mas fazer bem, do que montar um artesanato durante a noite e enviar com o comentário “Com certeza vou terminar”;
- A história do desenvolvimento no Git é a cultura da engenharia, o desenvolvimento iterativo e o fato de a solução não ter sido copiada descaradamente.
Concordamos que queríamos analisar um problema algorítmico e uma pequena aplicação web. Os algorítmicos foram elaborados em laboratórios de nível elementar - busca binária, classificação, verificação de anagramas, trabalho com listas e árvores. No final, optamos pela pesquisa binária como primeira opção de teste. A aplicação web tinha que ser um jogo da velha usando qualquer framework (ou sem ele).
Quase metade dos caras restantes completaram a tarefa de teste - eles nos enviaram as soluções 54 candidatos. Visão incrível - quantas implementações do jogo da velha, prontas para copiar e colar, você acha que existem na Internet?
Сколько?Na verdade, parece que existem apenas 3. E na grande maioria das decisões existiam precisamente estas 3 opções.
O que não gostou:
- copiar e colar ou desenvolvimento baseado no mesmo tutorial sem arquitetura própria;
- ambas as tarefas estão no mesmo repositório em pastas diferentes, claro que não há histórico de commits;
- código sujo, violação DRY, falta de formatação;
- uma mistura de modelo, visão e controlador em uma classe com centenas de linhas de código;
- falta de compreensão de testes unitários;
- uma solução “frontal” é um código rígido de uma matriz 3x3 de combinações vencedoras, que será bastante difícil de expandir para 10x10, por exemplo.
Também prestamos atenção aos repositórios vizinhos - projetos interessantes eram uma vantagem, e um monte de tarefas de teste de outras empresas eram mais um alerta: por que o candidato não conseguiu chegar lá?
Como resultado, encontramos opções legais em React, Angular, Vanilla JS - eram 29. E decidimos convidar mais um candidato sem testar para seus projetos muito legais. Nossa hipótese sobre os benefícios das tarefas de teste foi confirmada.
Entrevista técnica
Pela empresa: Não foram os intermediários/idosos que vieram até você! Precisamos de uma abordagem mais individual.
Para júnior: Lembre-se que isso não é um exame - não tente ficar calado por causa de um C ou bombardear o professor com um fluxo de todo o seu conhecimento possível para que ele se confunda e dê uma nota “excelente”.
O que queremos entender em uma entrevista técnica? Uma coisa simples é como o candidato pensa. Ele provavelmente possui algumas habilidades difíceis se tiver passado nos primeiros estágios de seleção – resta saber se ele sabe como usá-las. Concordamos em 3 tarefas.
A primeira é sobre algoritmos e estruturas de dados. Com uma caneta, num pedaço de papel, em pseudolinguagem e com a ajuda de desenhos, descobrimos como copiar uma árvore ou como remover um elemento de uma lista encadeada individualmente. A descoberta desagradável foi que nem todo mundo entende a recursão e como funcionam as referências.
A segunda é a codificação ao vivo. Nós fomos a , escolheu coisas simples como classificar uma série de palavras pela última letra e por 30-40 minutos junto com o candidato tentou fazer todos os testes passarem. Parecia que não deveria haver surpresas por parte dos caras que dominavam o jogo da velha - mas na prática, nem todos conseguiram perceber que o valor deveria ser armazenado em uma variável, e a função deveria retornar algo via return. Embora eu sinceramente espere que tenha sido um nervosismo, e que os caras tenham conseguido lidar com essas tarefas em condições mais leves.
Por fim, o terceiro é um pouco sobre arquitetura. Discutimos como fazer uma barra de pesquisa, como funciona o debounce, como renderizar vários widgets nas dicas de pesquisa, como o front-end pode interagir com o back-end. Havia muitas soluções interessantes, incluindo renderização no lado do servidor e web sockets.
Conduzimos 21 entrevistas usando esse design. O público era completamente diversificado - vejamos os quadrinhos:
- "Foguete". Ele nunca se acalma, se envolve em tudo e durante uma entrevista vai sobrecarregar você com uma torrente de pensamentos que nem mesmo estão diretamente relacionados à pergunta feita. Se fosse em uma universidade, seria uma tentativa familiar de demonstrar, bem, todo o seu conhecimento, quando tudo o que você lembra do ingresso que encontrou é que ontem à noite você decidiu não estudá-lo - você ainda não consegue isso.
- "Groot". É muito difícil entrar em contato com ele porque ele é o Groot. Durante uma entrevista, você passa muito tempo tentando obter respostas palavra por palavra. É bom que seja apenas um estupor - caso contrário, será muito difícil para você no seu trabalho diário.
- "Drax". Já trabalhei com transporte de cargas e em termos de programação só aprendi JS no Stackoverflow, então nem sempre entendo o que está sendo discutido em uma entrevista. Ao mesmo tempo, ele é uma boa pessoa, tem as melhores intenções e quer se tornar um grande desenvolvedor front-end.
- Nós provavelmente "Senhor das Estrelas". No geral, um bom candidato com quem você pode negociar e construir um diálogo.
Ao final de nossa pesquisa 7 candidatos chegaram à final, confirmando suas habilidades com um ótimo teste e boas respostas na entrevista.
Ajuste cultural
Pela empresa: Você trabalha com ele! O candidato está disposto a trabalhar arduamente para o seu desenvolvimento? Ele realmente se encaixará no time?
Para júnior: Você trabalha com eles! A empresa está realmente pronta para investir no crescimento dos juniores ou simplesmente despejará todo o trabalho sujo sobre você por um salário baixo?
Cada júnior, além do time de produto, cujo lead deve concordar em contratá-lo, ganha um mentor. A tarefa do mentor é guiá-lo através de um processo de três meses de integração e atualização de habilidades técnicas. Portanto, chegamos a cada ajuste cultural como mentores e respondemos à pergunta: “Assumirei a responsabilidade de desenvolver um candidato em 3 meses de acordo com o nosso plano?”
Esta etapa passou sem particularidades e acabou por nos trazer 4 ofertas, sendo 3 aceitos, e a galera entrou nas equipes.
Vida depois da oferta
Pela empresa: Cuide de seus juniores ou outros o farão!
Para júnior: AAAAAAAAAAA!!!
Quando um novo funcionário sai, ele precisa ser integrado - atualizado sobre os processos, informado sobre como funciona tudo na empresa e na equipe e como deve trabalhar de forma geral. Quando um júnior sai, você precisa entender como desenvolvê-lo.
Pensando bem, chegamos a uma lista de 26 habilidades que, em nossa opinião, um júnior deveria ter ao final do período de integração de três meses. Isso incluiu hard skills (de acordo com nosso stack), conhecimento de nossos processos, Scrum, infraestrutura e arquitetura de projetos. Nós os combinamos em um roteiro, distribuído ao longo de 3 meses.
Por exemplo, aqui está o roteiro do meu júnior
Atribuímos um mentor para cada júnior que trabalha com ele individualmente. Dependendo do mentor e do nível atual do candidato, as reuniões podem ocorrer de 1 a 5 vezes por semana durante 1 hora. Mentores são desenvolvedores front-end voluntários que desejam fazer algo mais do que apenas escrever código.
Parte da carga dos mentores é aliviada pelos cursos da nossa pilha - Dart, Angular. Os cursos são ministrados regularmente para pequenos grupos de 4 a 6 pessoas, onde os alunos estudam sem interrupção do trabalho.
Ao longo de 3 meses, coletamos periodicamente feedback dos juniores, seus mentores e líderes e ajustamos o processo individualmente. As habilidades aprimoradas são verificadas 1 a 2 vezes ao longo de todo o período, a mesma verificação é realizada no final - com base nelas, são formadas recomendações sobre o que exatamente precisa ser melhorado.
Conclusão
Pela empresa: Vale a pena investir em juniores? Sim!
Para júnior: Procure empresas que selecionem cuidadosamente os candidatos e saibam como desenvolvê-los
Ao longo de 3 meses, revisamos 122 questionários, 54 tarefas de teste e realizamos 21 entrevistas técnicas. Isso nos trouxe três grandes juniores que já completaram metade de seus roteiros de integração e aceleração. Eles já estão concluindo tarefas reais de produto em nosso projeto, onde existem mais de 3 de linhas de código e mais de 2 repositórios somente no front-end.
Descobrimos que o funil para juniores pode e deve ser bastante complexo, mas no final só passa por ele quem está realmente disposto a trabalhar muito e investir no seu desenvolvimento.
Agora nossa principal tarefa é completar roteiros de desenvolvimento de três meses para cada júnior na modalidade de trabalho individual com um mentor e cursos gerais, coletar métricas, feedback de leads, mentores e dos próprios caras. Neste ponto, o primeiro experimento pode ser considerado concluído, conclusões podem ser tiradas, o processo pode ser melhorado e reiniciado para seleção de novos candidatos.
Fonte: habr.com