Como entrar nunha gran empresa se es un júnior? Como contratar un junior decente se es unha gran empresa? Debaixo do corte, contarei a nosa historia de contratación de principiantes no front end: como traballamos nas tarefas de proba, nos preparamos para realizar entrevistas e creamos un programa de orientación para o desenvolvemento e incorporación de novos chegados, e tamén por que as preguntas estándar das entrevistas non non funciona.
Estou intentando domar a Junior
Ola! Chámome Pavel, traballo de front-end no equipo de Wrike. Creamos un sistema de xestión e colaboración de proxectos. Levo traballando na web dende 2010, traballei 3 anos no estranxeiro, participei en varias startups e impartín un curso de tecnoloxías web na universidade. Na empresa, estou implicado no desenvolvemento de cursos técnicos e no programa de mentoring Wrike para mozos, así como na contratación directa dos mesmos.
Por que pensamos en contratar mozos?
Ata hai pouco, contratabamos desenvolvedores de nivel medio ou superior para o frontend, o suficientemente independentes como para realizar tarefas de produto despois da incorporación. A principios deste ano, decatámonos de que queriamos cambiar esta política: ao longo do ano o número dos nosos equipos de produtos case se duplicou, o número de desenvolvedores front-end achegouse ao centenar e, nun futuro próximo, todo isto será ter que dobrar de novo. Hai moito traballo, poucas mans libres e aínda hai menos no mercado, así que decidimos recorrer aos mozos que están a comezar a súa andaina na fronte e decatámonos de que estamos preparados para investir no seu desenvolvemento.
Quen é un junior?
Esta é a primeira pregunta que nos fixemos. Hai diferentes criterios, pero o principio máis sinxelo e comprensible é o seguinte:
Hai que explicarlle a Junior que función e como facelo. O Medio debe ser explicado que función é necesaria, e el descubrirá a implementación el mesmo. O propio signo explicarache por que non é necesario facer esta función.
Dun xeito ou doutro, un júnior é un programador que necesita consellos sobre como implementar esta ou aquela solución. Sobre o que decidimos construír:
- Junior é alguén que quere desenvolverse e está preparado para traballar duro para iso;
- Non sempre sabe en que dirección quere desenvolverse;
- Necesita consello e busca axuda de fóra: do seu líder, mentor ou da comunidade.
Tamén tiñamos varias hipóteses:
- Haberá unha tormenta de respostas á posición de xuño. Debe filtrar as respostas aleatorias na fase de envío do seu currículo;
- Un filtro principal non axudará. — son necesarias máis tarefas de proba;
- As tarefas de proba asustarán a todos - non son necesarios.
E por suposto, tiñamos un obxectivo: 4 juniors en 3 semanas.
Con esta constatación comezamos a experimentar. O plan era sinxelo: comeza co funil máis amplo posible e intenta reducilo gradualmente para que poidas procesar o fluxo, pero non reducilo a 1 candidato por semana.
Publicamos unha vacante
Para a empresa: Haberá centos de respostas! Pense nun filtro.
Para júnior: Non teñas medo do cuestionario antes de enviar o teu currículo e a tarefa de proba: este é un sinal de que a empresa coidou de ti e configurou ben o proceso.
O primeiro día, recibimos uns 70 currículos de candidatos "con coñecementos de JavaScript". E de novo. E máis aló. Non puidemos convidar a todos á oficina para unha entrevista e eliximos entre eles os mozos cos proxectos de mascotas máis chulos, Github en directo ou, polo menos, experiencia.
Pero a principal conclusión que fixemos para nós mesmos o primeiro día foi que a tormenta comezara. Agora é o momento de engadir un formulario de cuestionario antes de enviar o teu currículo. O seu obxectivo era eliminar aos candidatos que non estaban dispostos a facer o mínimo esforzo para enviar un currículo, e aqueles que non tiñan o coñecemento e o contexto para polo menos Google as respostas correctas.
Contiña preguntas estándar sobre JS, maquetación, web, Ciencias da Computación; todos os que imaxinan o que preguntan nunha entrevista frontal sábenas. Cal é a diferenza entre let/var/const? Como podo aplicar estilos só a pantallas de menos de 600 píxeles de ancho? Non queriamos facer estas preguntas nunha entrevista técnica: a práctica demostrou que se poden responder despois de 2-3 entrevistas sen entender o desenvolvemento. Pero nun principio puideron mostrarnos se o candidato, en principio, entende o contexto.
En cada categoría, preparamos 3-5 preguntas e día tras día cambiamos o seu conxunto no formulario de resposta ata eliminar as máis pasables e as máis difíciles. Isto permitiunos reducir o fluxo - en 3 semanas recibimos 122 candidatos, co que poderiamos traballar máis. Estes eran estudantes de informática; rapaces que querían pasar á fronte dende o fondo; traballadores ou enxeñeiros, de 25 a 35 anos, que querían cambiar radicalmente a súa ocupación e dedicaron distintos esforzos á autoformación, aos cursos e ás prácticas.
Coñecéndonos mellor
Para a empresa: A tarefa da proba non disuadi aos candidatos, pero axuda a acurtar o funil.
Para júnior: Non copies e pegues as de proba: nótase. E mantén o teu github en orde!
Se chamásemos a todos para unha entrevista técnica, teriamos que realizar unhas 40 entrevistas á semana só para os mozos e só no front end. Polo tanto, decidimos probar a segunda hipótese - sobre a tarefa de proba.
O que foi importante para nós na proba:
- Construír unha boa arquitectura escalable, pero sen sobreenxeñería;
- É mellor tardar máis, pero facelo ben, que montar unha manualidade durante a noite e enviala co comentario "Definitivamente o rematarei";
- A historia do desenvolvemento en Git é a cultura da enxeñaría, o desenvolvemento iterativo e o feito de que a solución non foi copiada descaradamente.
Acordamos que queriamos analizar un problema algorítmico e unha pequena aplicación web. Elaboráronse algorítmicos a nivel de laboratorios de nivel elemental: busca binaria, clasificación, comprobación de anagramas, traballo con listas e árbores. Ao final, decidimos a busca binaria como primeira opción de proba. A aplicación web tiña que ser tic-tac-toe usando calquera framework (ou sen el).
Case a metade dos rapaces restantes completaron a tarefa de proba: enviáronnos as solucións 54 candidatos. Unha visión incrible: cantas implementacións de tic-tac-toe, listas para copiar e pegar, cres que hai en Internet?
CantoDe feito, parece que só hai 3. E na gran maioría das decisións había precisamente estas 3 opcións.
O que non me gustou:
- copiar-pegar, ou desenvolvemento baseado no mesmo titorial sen a súa propia arquitectura;
- ambas tarefas están no mesmo repositorio en cartafoles diferentes, por suposto que non hai historial de commit;
- código sucio, violación DRY, falta de formato;
- unha mestura de modelo, vista e controlador nunha clase de centos de liñas de código de longo;
- falta de comprensión das probas unitarias;
- unha solución "frontal" é un código duro dunha matriz 3x3 de combinacións gañadoras, que será bastante difícil de expandir a 10x10, por exemplo.
Tamén prestamos atención aos repositorios veciños: os proxectos de mascotas interesantes eran unha vantaxe, e unha morea de tarefas de proba doutras empresas eran máis unha chamada de atención: por que o candidato non puido chegar alí?
Como resultado, atopamos opcións interesantes en React, Angular e Vanilla JS: había 29. E decidimos invitar a un candidato máis sen probar os seus proxectos de mascotas moi interesantes. Confirmouse a nosa hipótese sobre os beneficios das tarefas de proba.
Entrevista técnica
Para a empresa: Non son os medios/maiores os que viñeron a ti! Necesitamos un enfoque máis individual.
Para júnior: Lembra que este non é un exame; non intentes quedar calado por unha C nin bombardear ao profesor cun fluxo de todos os teus coñecementos posibles para que se confunda e dea un "excelente".
Que queremos entender nunha entrevista técnica? Unha cousa sinxela: como pensa o candidato. Probablemente teña algunhas habilidades difíciles se pasou as primeiras etapas de selección - está por ver se sabe como usalas. Acordamos 3 tarefas.
O primeiro trata sobre algoritmos e estruturas de datos. Cun bolígrafo, nun anaco de papel, en pseudolingua e coa axuda de debuxos, descubrimos como copiar unha árbore ou como eliminar un elemento dunha lista enlazada individualmente. O descubrimento desagradable foi que non todos entenden a recursividade e como funcionan as referencias.
O segundo é a codificación en directo. Fomos a , escolleu cousas sinxelas como ordenar unha matriz de palabras pola última letra e durante 30-40 minutos xunto co candidato tentaron facer pasar todas as probas. Parecía que non debería haber sorpresas por parte dos mozos que dominaran o tic-tac-toe, pero na práctica, non todos foron capaces de darse conta de que o valor debería almacenarse nunha variable e que a función debería devolver algo mediante o retorno. Aínda que espero sinceramente que fose un nerviosismo, e os mozos puideron xestionar estas tarefas en condicións máis lixeiras.
Finalmente, o terceiro trata un pouco sobre arquitectura. Discutimos como facer unha barra de busca, como funciona a eliminación de rebotes, como renderizar varios widgets en consellos de busca, como o front end pode interactuar co back end. Había moitas solucións interesantes, incluíndo a representación do lado do servidor e os sockets web.
Con este deseño realizamos 21 entrevistas. O público era completamente diverso: vexamos os cómics:
- "Foguete". Nunca se calma, métese en todo e durante unha entrevista abrumarache cunha corrente de pensamentos que nin sequera están directamente relacionados coa pregunta formulada. Se fose nunha universidade, este sería un intento familiar de demostrar, ben, todo o teu coñecemento, cando o único que lembras do billete que atopaches é que onte á noite decidiches non estudalo, aínda non podes conseguir. fóra.
- "Groot". É bastante difícil poñerse en contacto con el porque é Groot. Durante unha entrevista, tes que pasar moito tempo intentando obter respostas palabra por palabra. É bo se é só un estupor; se non, será moi difícil para ti no teu traballo diario.
- "Drax". Traballaba no transporte de carga e, en canto á programación, só aprendín JS en Stackoverflow, polo que non sempre entendo o que se fala nunha entrevista. Ao mesmo tempo, é unha boa persoa, ten as mellores intencións e quere converterse nun gran desenvolvedor front-end.
- Ben, probablemente "Star Lord". En xeral, un bo candidato co que podes negociar e dialogar.
Ao final da nosa investigación 7 candidatos chegaron ás finais, confirmando as súas habilidades cunha gran tarefa de proba e boas respostas á entrevista.
Axuste cultural
Para a empresa: Vostede traballa con el! O candidato está disposto a traballar moi duro para o seu desenvolvemento? Encaixará realmente no equipo?
Para júnior: Vostede traballa con eles! A empresa está realmente preparada para investir no crecemento dos mozos ou simplemente botaráche todo o traballo sucio por un salario baixo?
Cada junior, ademais do equipo de produto, cuxo líder debe aceptar asumilo, recibe un mentor. A tarefa do mentor é guialo a través dun proceso de tres meses de incorporación e actualización de habilidades. Por iso, acudimos a cada encaixe cultural como mentores e respondemos á pregunta: "Asumirei a responsabilidade de desenvolver un candidato en 3 meses segundo o noso plan?"
Esta etapa transcorreu sen características especiais e ao final trouxonos 4 ofertas, 3 dos cales foron aceptados, e os rapaces entraron nos equipos.
A vida despois da oferta
Para a empresa: Coida dos teus júnior ou outros!
Para júnior: AAAAAAAAAAA!!!
Cando sae un novo empregado, ten que ser incorporado - actualizado cos procesos, dicir como funciona todo na empresa e no equipo, e como debe traballar en xeral. Cando sae un júnior, cómpre entender como desenvolvelo.
Cando pensamos niso, elaboramos unha lista de 26 habilidades que, na nosa opinión, un júnior debería ter ao final do período de incorporación de tres meses. Isto incluía habilidades duras (segundo a nosa pila), coñecemento dos nosos procesos, Scrum, infraestrutura e arquitectura do proxecto. Combinámolos nunha folla de ruta, distribuída en 3 meses.
Por exemplo, aquí está a folla de ruta do meu junior
Asignamos un mentor a cada junior que traballe con el individualmente. Dependendo do mentor e do nivel actual do candidato, as reunións poden realizarse de 1 a 5 veces por semana durante 1 hora. Os mentores son desenvolvedores front-end voluntarios que queren facer algo máis que escribir código.
Parte da carga dos mentores é eliminada polos cursos da nosa pila: Dart, Angular. Os cursos realízanse regularmente para pequenos grupos de 4-6 persoas, onde os estudantes estudan sen interrupción do traballo.
Ao longo de 3 meses, recollemos periodicamente comentarios dos mozos, os seus mentores e líderes e axustamos o proceso individualmente. As habilidades aumentadas verifícanse 1-2 veces durante todo o período, a mesma comprobación realízase ao final; en función delas, fórmanse recomendacións sobre o que hai que mellorar exactamente.
Conclusión
Para a empresa: Paga a pena investir en juniors? Si!
Para júnior: Busca empresas que seleccionen coidadosamente candidatos e saiban como desenvolvelos
Durante 3 meses, revisamos 122 cuestionarios, 54 tarefas de proba e realizamos 21 entrevistas técnicas. Isto trouxonos 3 grandes mozos que agora completaron a metade das súas follas de ruta de incorporación e aceleración. Xa están a completar tarefas de produtos reais no noso proxecto, onde hai máis de 2 de liñas de código e máis de 000 repositorios só na interface.
Descubrimos que o funil para os xuvenís pode e debe ser bastante complexo, pero ao final só pasan aqueles rapaces que están realmente preparados para traballar moi duro e investir no seu desenvolvemento.
Agora a nosa tarefa principal é completar follas de ruta de desenvolvemento de tres meses para cada junior na modalidade de traballo individual cun mentor e cursos xerais, recoller métricas, comentarios dos leads, mentores e os propios rapaces. Neste punto, pódese considerar rematado o primeiro experimento, extraer conclusións, mellorar o proceso e comezar de novo para seleccionar novos candidatos.
Fonte: www.habr.com