¿Cómo domesticar a un junior?

¿Cómo entrar en una gran empresa si eres junior? ¿Cómo contratar un junior decente si eres una gran empresa? Debajo del corte, les contaré nuestra historia de la contratación de principiantes desde el principio: cómo trabajamos en tareas de prueba, nos preparamos para realizar entrevistas y creamos un programa de tutoría para el desarrollo y la incorporación de recién llegados, y también por qué las preguntas de entrevista estándar no No funciona.

Estoy tratando de domesticar a Junior

¡Hola! Mi nombre es Pavel, trabajo en el front-end del equipo de Wrike. Creamos un sistema de gestión y colaboración de proyectos. Trabajo en la web desde 2010, trabajé durante 3 años en el extranjero, participé en varias startups e impartí un curso sobre tecnologías web en la universidad. En la empresa, participo en el desarrollo de cursos técnicos y el programa de tutoría de Wrike para jóvenes, además de reclutarlos directamente.

¿Por qué pensamos siquiera en contratar jóvenes?

Hasta hace poco, contratábamos desarrolladores de nivel medio o superior para el frontend, lo suficientemente independientes como para realizar tareas del producto después de la incorporación. A principios de este año, nos dimos cuenta de que queríamos cambiar esta política: a lo largo del año, el número de nuestros equipos de productos casi se ha duplicado, el número de desarrolladores front-end se ha acercado a cien y, en un futuro próximo, todo esto tener que duplicar de nuevo. Hay mucho trabajo, pocas manos libres y hay aún menos en el mercado, por lo que decidimos recurrir a los muchachos que recién están comenzando su viaje en la parte delantera y nos dimos cuenta de que estamos listos para invertir en sus desarrollo.

¿Quién es un junior?

Esta es la primera pregunta que nos hicimos. Existen diferentes criterios, pero el principio más sencillo y comprensible es este:

Es necesario explicarle a Junior qué característica y cómo hacerla. Es necesario explicarle al Medio qué característica se necesita y él mismo descubrirá la implementación. El propio firmante le explicará por qué no es necesario realizar esta función en absoluto.

De una forma u otra, un junior es un desarrollador que necesita consejos sobre cómo implementar tal o cual solución. Sobre qué decidimos construir:

1. Junior es alguien que quiere desarrollarse y está dispuesto a trabajar duro para ello;
2. No siempre sabe en qué dirección quiere desarrollarse;
3. Necesita consejo y busca ayuda externa: de su líder, mentor o de la comunidad.

También teníamos varias hipótesis:

1. Habrá una tormenta de respuestas a la posición de junio. Debe filtrar las respuestas aleatorias en la etapa de envío de su currículum;
2. Un filtro primario no ayudará. — se necesitan más tareas de prueba;
3. Las tareas de prueba asustarán a todos - no son necesarios.

Y por supuesto, teníamos un objetivo: 4 juniors en 3 semanas.

Con esta comprensión comenzamos a experimentar. El plan era simple: comenzar con el embudo más amplio posible e intentar reducirlo gradualmente para poder procesar el flujo, pero no reducirlo a 1 candidato por semana.

Publicamos una vacante

Para la compañía: ¡Habrá cientos de respuestas! Piensa en un filtro.

para jóvenes: No tenga miedo del cuestionario antes de enviar su currículum y su tarea de prueba; esto es una señal de que la empresa se ha ocupado de usted y ha configurado bien el proceso.

El primer día, recibimos alrededor de 70 currículums de candidatos "con conocimientos de JavaScript". Y luego otra vez. Y además. Físicamente no podíamos invitar a todos a la oficina para una entrevista y elegimos entre ellos a los chicos con los mejores proyectos favoritos, Github en vivo o al menos experiencia.

Pero la principal conclusión a la que llegamos el primer día fue que la tormenta había comenzado. Ahora es el momento de agregar un formulario de cuestionario antes de enviar su currículum. Su objetivo era eliminar a los candidatos que no estaban dispuestos a hacer el mínimo esfuerzo para enviar un currículum y a aquellos que no tenían el conocimiento y el contexto para al menos buscar en Google las respuestas correctas.

Contenía preguntas estándar sobre JS, diseño, web, informática; cualquiera que imagine lo que pregunta en una entrevista inicial las conoce. ¿Cuál es la diferencia entre let/var/const? ¿Cómo puedo aplicar estilos sólo a pantallas de menos de 600 píxeles de ancho? No queríamos hacer estas preguntas en una entrevista técnica; la práctica ha demostrado que se pueden responder después de 2 o 3 entrevistas sin entender en absoluto el desarrollo. Pero inicialmente pudieron mostrarnos si el candidato, en principio, comprende el contexto.

En cada categoría preparamos de 3 a 5 preguntas y día tras día cambiamos su conjunto en el formulario de respuestas hasta eliminar las más pasables y las más difíciles. Esto nos permitió reducir el flujo: en 3 semanas recibimos 122 candidatos, con el que podríamos seguir trabajando. Estos eran estudiantes de TI; chicos que querían pasar al frente desde el backend; trabajadores o ingenieros, de 25 a 35 años, que querían cambiar radicalmente de profesión y dedicaron distintos esfuerzos a la autoformación, a cursos y a prácticas.

Conociéndonos mejor

Para la compañía: La tarea de prueba no disuade a los candidatos, pero ayuda a acortar el embudo.

para jóvenes: No copie y pegue los de prueba, se nota. ¡Y mantén tu github en orden!

Si convocáramos a todos para una entrevista técnica, tendríamos que realizar unas 40 entrevistas por semana sólo para los jóvenes y sólo en la parte inicial. Por lo tanto, decidimos probar la segunda hipótesis: sobre la tarea de prueba.

Lo que fue importante para nosotros en la prueba:

1. Construya una buena arquitectura escalable, pero sin demasiada ingeniería;
2. Es mejor tardar más, pero hacerlo bien, que armar una manualidad de la noche a la mañana y enviarla con el comentario “seguro que la termino”;
3. La historia del desarrollo en Git es la cultura de la ingeniería, el desarrollo iterativo y el hecho de que la solución no fue copiada descaradamente.

Acordamos que queríamos analizar un problema algorítmico y una pequeña aplicación web. Los algorítmicos se prepararon a nivel de laboratorios de nivel elemental: búsqueda binaria, clasificación, verificación de anagramas, trabajo con listas y árboles. Al final, nos decidimos por la búsqueda binaria como primera opción de prueba. La aplicación web tenía que ser tres en raya utilizando cualquier marco (o sin él).

Casi la mitad de los chicos restantes completaron la tarea de prueba: nos enviaron las soluciones. 54 candidatos. Increíble visión: ¿cuántas implementaciones de tres en raya, listas para copiar y pegar, crees que hay en Internet?

Сколько?De hecho, parece que sólo hay 3. Y en la gran mayoría de decisiones estaban precisamente estas 3 opciones.
Lo que no me gustó:

• copiar y pegar, o desarrollo basado en el mismo tutorial sin arquitectura propia;
• ambas tareas están en el mismo repositorio en carpetas diferentes, por supuesto no hay historial de confirmaciones;
• código sucio, violación DRY, falta de formato;
• una mezcla de modelo, vista y controlador en una clase de cientos de líneas de código;
• falta de comprensión de las pruebas unitarias;
• una solución "frontal" es un código rígido de una matriz de combinaciones ganadoras de 3x3, que será bastante difícil de ampliar a 10x10, por ejemplo.

También prestamos atención a los repositorios vecinos: los proyectos favoritos interesantes fueron una ventaja y un montón de tareas de prueba de otras empresas fueron más bien una llamada de atención: ¿por qué el candidato no podía llegar allí?

Como resultado, encontramos opciones interesantes en React, Angular, Vanilla JS (había 29) y decidimos invitar a un candidato más sin realizar pruebas para sus proyectos favoritos. Se confirmó nuestra hipótesis sobre los beneficios de las tareas de prueba.

Entrevista técnica

Para la compañía: ¡No son los de nivel medio o superior los que han acudido a ti! Necesitamos un enfoque más individual.

para jóvenes: Recuerde que esto no es un examen, no intente quedarse en silencio por una C ni bombardear al profesor con un chorro de todos sus conocimientos posibles para que se confunda y dé un "excelente".

¿Qué queremos entender en una entrevista técnica? Algo muy sencillo: cómo piensa el candidato. Probablemente tenga algunas habilidades duras si ha pasado las primeras etapas de selección; queda por ver si sabe cómo usarlas. Acordamos 3 tareas.

El primero trata sobre algoritmos y estructuras de datos. Con un bolígrafo, en una hoja de papel, en pseudolenguaje y con la ayuda de dibujos, descubrimos cómo copiar un árbol o cómo eliminar un elemento de una lista enlazada individualmente. El desagradable descubrimiento fue que no todo el mundo entiende la recursividad y cómo funcionan las referencias.

El segundo es la codificación en vivo. Fuimos a codewars.com, eligió cosas simples como ordenar una serie de palabras por la última letra y durante 30 a 40 minutos junto con el candidato intentó aprobar todas las pruebas. Parecía que no debería haber sorpresas por parte de los chicos que dominaban el tres en raya, pero en la práctica, no todos pudieron darse cuenta de que el valor debería almacenarse en una variable y que la función debería devolver algo mediante retorno. Aunque espero sinceramente que haya sido un poco de nerviosismo y que los muchachos hayan podido afrontar estas tareas en condiciones más ligeras.

Finalmente, el tercero es un poco sobre arquitectura. Discutimos cómo hacer una barra de búsqueda, cómo funciona el rebote, cómo representar varios widgets en las sugerencias de búsqueda y cómo el front-end puede interactuar con el back-end. Hubo muchas soluciones interesantes, incluida la renderización del lado del servidor y los sockets web.

Realizamos 21 entrevistas utilizando este diseño. El público era completamente diverso; veamos los cómics:

1. "Cohete". Nunca se calma, se involucra en todo y durante una entrevista te abrumará con un torrente de pensamientos que ni siquiera están directamente relacionados con la pregunta formulada. Si fuera en una universidad, este sería un intento familiar de demostrar, bueno, todos tus conocimientos, cuando lo único que recuerdas sobre el boleto que encontraste es que anoche decidiste no estudiarlo; todavía no puedes conseguirlo. fuera.
2. "Groot". Es bastante difícil ponerse en contacto con él porque es Groot. Durante una entrevista, hay que dedicar mucho tiempo a intentar obtener respuestas palabra por palabra. Es bueno si es solo un estupor; de lo contrario, le resultará muy difícil en su trabajo diario.
3. "Drax". Solía ​​​​trabajar en transporte de carga y, en términos de programación, solo aprendí JS en Stackoverflow, por lo que no siempre entiendo de qué se habla en una entrevista. Al mismo tiempo, es una buena persona, tiene las mejores intenciones y quiere convertirse en un gran desarrollador front-end.
4. Probablemente vamos "Señor de las estrellas". En general, un buen candidato con el que se puede negociar y entablar un diálogo.

Al final de nuestra investigación 7 candidatos Llegaron a la final, confirmando sus duras habilidades con una gran prueba y buenas respuestas a la entrevista.

Ajuste cultural

Para la compañía: ¡Trabajas con él! ¿Está el candidato dispuesto a trabajar muy duro para su desarrollo? ¿Encajará realmente en el equipo?

para jóvenes: ¡Trabajas con ellos! ¿Está la empresa realmente dispuesta a invertir en el crecimiento de las juniors o simplemente le dejará todo el trabajo sucio por un salario bajo?

Cada junior, además del equipo de producto, cuyo líder debe aceptar contratarlo, recibe un mentor. La tarea del mentor es guiarlo a través de un proceso de tres meses de incorporación y mejora de habilidades duras. Por lo tanto, llegamos a cada encuentro cultural como mentores y respondimos a la pregunta: "¿Asumiré la responsabilidad de desarrollar un candidato en 3 meses según nuestro plan?"

Esta etapa transcurrió sin particularidades y al final nos trajo 4 ofertas, 3 de los cuales fueron aceptados y los muchachos ingresaron a los equipos.

La vida después de la oferta.

Para la compañía: ¡Cuida a tus juniors o los demás lo harán!

para jóvenes: AAAAAAAAAA!!!

Cuando llega un nuevo empleado, es necesario incorporarlo: actualizarlo con los procesos, explicarle cómo funciona todo en la empresa y en el equipo, y cómo debe trabajar en general. Cuando sale un junior, es necesario comprender cómo desarrollarlo.

Cuando lo pensamos, se nos ocurrió una lista de 26 habilidades que, en nuestra opinión, un junior debería tener al final del período de incorporación de tres meses. Esto incluía habilidades duras (según nuestro stack), conocimiento de nuestros procesos, Scrum, infraestructura y arquitectura del proyecto. Los combinamos en una hoja de ruta, distribuida en 3 meses.

Por ejemplo, aquí está la hoja de ruta de mi junior.

Asignamos un mentor a cada junior que trabaja con él individualmente. Dependiendo del mentor y del nivel actual del candidato, las reuniones pueden realizarse de 1 a 5 veces por semana durante 1 hora. Los mentores son desarrolladores front-end voluntarios que quieren hacer algo más que escribir código.

Parte de la carga de los mentores se elimina con los cursos de nuestra pila: Dart, Angular. Los cursos se imparten periódicamente para grupos pequeños de 4 a 6 personas, donde los estudiantes estudian sin interrupción del trabajo.

A lo largo de 3 meses, recopilamos periódicamente comentarios de los jóvenes, sus mentores y líderes y ajustamos el proceso individualmente. Las habilidades mejoradas se verifican 1 o 2 veces durante todo el período, se realiza la misma verificación al final; en base a ellas, se forman recomendaciones sobre qué es exactamente lo que se debe mejorar.

Conclusión

Para la compañía: ¿Vale la pena invertir en juniors? ¡Sí!

para jóvenes: Busque empresas que seleccionen cuidadosamente a los candidatos y sepan cómo desarrollarlos

Durante 3 meses, revisamos 122 cuestionarios, 54 tareas de prueba y realizamos 21 entrevistas técnicas. Esto nos trajo a 3 grandes jóvenes que ahora han completado la mitad de sus hojas de ruta de incorporación y aceleración. Ya están completando tareas de productos reales en nuestro proyecto, donde hay más de 2 de líneas de código y más de 000 repositorios solo en el front-end.

Descubrimos que el embudo para juniors puede y debe ser bastante complejo, pero al final solo pasan por él aquellos chicos que están realmente dispuestos a trabajar muy duro e invertir en su desarrollo.

Ahora nuestra tarea principal es completar hojas de ruta de desarrollo de tres meses para cada junior en el modo de trabajo individual con un mentor y cursos generales, recopilar métricas, comentarios de los líderes, mentores y los propios muchachos. En este punto se puede dar por finalizado el primer experimento, sacar conclusiones, mejorar el proceso y reiniciarlo para seleccionar nuevos candidatos.

Fuente: habr.com