¿Cómo domesticar a un junior?

¿Cómo entrar en una gran empresa si eres un junior? ¿Cómo contratar a un junior competente si eres una gran empresa? A continuación, compartiré nuestra historia sobre la contratación de principiantes para el frontend: cómo desarrollamos las pruebas de habilidades, nos preparamos para realizar entrevistas y establecimos un programa de mentoría para el desarrollo y la incorporación de nuevos talentos, además de por qué las preguntas estándar de entrevistas no funcionan.

Yo estoy intentando domesticar a un junior

¡Hola! Me llamo Pavel, hago frontend en el equipo de Wrike. Estamos creando un sistema para la gestión de proyectos y el trabajo colaborativo. He estado en el mundo web desde 2010, trabajé 3 años en remoto para el extranjero, participé en varias startups y di un curso sobre tecnologías web en la universidad. En la empresa, participo en el desarrollo de cursos técnicos y del programa de mentoría de Wrike para juniors, así como en su reclutamiento directo.

¿Por qué decidimos contratar juniors en primer lugar?

Hasta hace poco, estábamos contratando desarrolladores de frontend de nivel medio o senior, que fueran lo suficientemente independientes como para llevar a cabo tareas del producto después de la incorporación. A principios de este año, entendimos que queríamos cambiar esta política: en un año, el número de nuestros equipos de producto casi se ha duplicado, la cantidad de frontenders se ha acercado al centenar, y a corto plazo, todo esto debería duplicarse nuevamente. Hay mucho trabajo, pocas manos libres y aún menos en el mercado, por lo que decidimos buscar a aquellos que apenas comienzan su camino en el frontend y nos dimos cuenta de que estábamos listos para invertir en su desarrollo.

¿Qué es un junior?

Esta es la primera pregunta que nos hicimos. Existen diferentes criterios, pero el principio más simple y claro es el siguiente:

A un junior se le tiene que explicar qué característica y cómo implementarla. A un medio se le tiene que explicar qué característica se necesita, y él mismo se encargará de la implementación. Un senior, por su parte, te explicará por qué esa característica no debería hacerse en absoluto.

De un modo u otro, un junior es el desarrollador que necesita consejos sobre cómo implementar una solución u otra. De esto decidimos partir:

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

Además, teníamos algunas hipótesis:

1. Para el puesto de junior habrá una tormenta de respuestas. Hay que filtrar las respuestas aleatorias ya en la etapa de envío del currículum;
2. El filtro inicial no ayudará — necesitamos más tareas de prueba;
3. Las tareas de prueba asustarán a todos — no son necesarias.

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

Con esta comprensión comenzamos a experimentar. El plan era simple: empezar con un embudo lo más amplio posible y tratar de ir estrechándolo gradualmente para manejar el flujo, pero sin reducirlo a 1 candidato por semana.

Publicamos la vacante

Para la empresa: ¡Habrá cientos de respuestas! Piensa en el filtro.

Para el junior: No tengas miedo del cuestionario antes de enviar el currículum y la tarea de prueba, es una señal de que la empresa se preocupa por ti y ha configurado bien el proceso.

En el primer día recibimos alrededor de 70 currículos de candidatos 'con conocimientos de JavaScript'. Y luego más. Y más. Físicamente no pudimos invitar a todos a una entrevista en la oficina y elegimos a los chicos con los proyectos más interesantes, un GitHub activo o al menos experiencia.

Pero la principal conclusión que hicimos el primer día fue: la tormenta había comenzado. Era hora de añadir un formulario de cuestionario antes de enviar el currículum. Su tarea era filtrar a los candidatos que no estaban dispuestos a hacer un mínimo esfuerzo para enviar su currículum, y a aquellos que no dominaban los conocimientos y el contexto al menos en la medida suficiente para buscar las respuestas correctas.

Incluía preguntas estándar sobre JS, maquetación, web, Computer Science — las sabe cualquier persona que tenga una idea de lo que se pregunta en una entrevista para frontend. ¿Cuál es la diferencia entre let/var/const? ¿Cómo aplicar estilos solo para pantallas que tengan menos de 600px de ancho? No queríamos hacer estas preguntas en la entrevista técnica, la práctica mostró que la gente puede responder a ellas después de 2-3 entrevistas, sin entender realmente de desarrollo. Pero sí pudieron mostrarnos inicialmente si el candidato comprende, en principio, el contexto.

En cada categoría preparamos de 3 a 5 preguntas y día a día cambiamos su conjunto en el formulario de respuesta, hasta que eliminamos las más fáciles y las más difíciles. Esto permitió reducir el flujo: en 3 semanas obtuvimos 122 candidatos, con los que se podía trabajar más adelante. Eran estudiantes de IT; chicos que querían pasar del backend al frontend; trabajadores o ingenieros de entre 25 y 35 años que quisieron cambiar radicalmente de profesión y dedicaron diferentes esfuerzos a la autoeducación, cursos y pasantías.

Conozcámonos mejor

Para la empresa: La tarea de prueba no asusta a los candidatos, sino que ayuda a acortar el embudo.

Para el junior: No copies y pegues las pruebas; se nota. ¡Y mantén tu GitHub en orden!

Si hubiéramos invitado a todos a la entrevista técnica, tendríamos que realizar aproximadamente 40 entrevistas por semana solo para juniors y solo en frontend. Por eso decidimos probar la segunda hipótesis sobre la tarea de prueba.

Lo que era importante para nosotros en la prueba:

1. Construir una buena arquitectura escalable, pero sin sobreingeniería;
2. Es mejor tomarse más tiempo y hacerlo bien, que hacer algo rápido y enviarlo con el comentario 'definitivamente lo terminaré';
3. El historial de desarrollo en git es parte de la cultura de ingeniería, la iteratividad en el desarrollo y el hecho de que la solución no esté plagiada descaradamente.

Coincidimos en que queríamos ver un problema algorítmico y una pequeña aplicación web. Los problemas algorítmicos estaban preparados al nivel de laboratorios de los cursos iniciales: búsqueda binaria, ordenación, verificación de anagramas, trabajo con listas y árboles. Al final nos decidimos por la búsqueda binaria como la primera opción de prueba. La aplicación web debía ser un tres en raya utilizando cualquier framework (o sin él).

Casi la mitad de los candidatos restantes completaron la tarea de prueba; recibimos soluciones 54 candidatos. Un increíble insight: ¿cuántas implementaciones de tres en raya listas para copiar hay en la red?

¿Cuántas?En realidad, parece que solo hay 3. Y en la gran mayoría de las soluciones estaban precisamente esas 3 variantes.
Lo que no me gustó:

• copia y pega, o desarrollo a partir del mismo tutorial sin arquitectura propia;
• ambas tareas en un mismo repositorio en diferentes carpetas, sin historial de commits, por supuesto;
• código sucio, violación de DRY, falta de formato;
• mezcla de modelo, vista y controlador en una sola clase de cientos de líneas de código;
• falta de comprensión de las pruebas unitarias;
• una solución "directa" — hardcode de la matriz de combinaciones ganadoras 3x3, lo que será bastante difícil de ampliar a 10x10, por ejemplo.

Además, prestamos atención a los repositorios vecinos: los excelentes pet-proyectos prosperaban, mientras que varios trabajos de prueba de otras empresas eran más bien una señal de alerta: ¿por qué no pudo el candidato pasar allí?

Al final, encontramos excelentes opciones en React, Angular y Vanilla JS — se acumularon 29. Y decidimos invitar a otro candidato sin prueba por sus impresionantes pet-proyectos. Nuestra hipótesis sobre la utilidad de las pruebas se confirmó.

Entrevista técnica

Para la empresa: No están viniendo mid-levels/seniors! Necesitamos un enfoque más individual.

Para el junior: Recuerden que no es un examen — no intenten permanecer en silencio para obtener un aprobado o abrumar al profesor con toda su posible información, para que se confunda y les dé un "excelente".

¿Qué queremos entender en la entrevista técnica? Algo simple: cómo piensa el candidato. Probablemente tiene algunas habilidades técnicas, si ha pasado las primeras etapas de selección — solo queda averiguar si sabe aplicarlas. Acordamos en 3 tareas.

La primera — sobre algoritmos y estructuras de datos. Con un bolígrafo, en una hoja, en un pseudolenguaje y con dibujos, analizamos cómo copiar un árbol o cómo eliminar un elemento de una lista enlazada. Un descubrimiento desagradable fue que no todos entienden la recursión y cómo funcionan los punteros.

La segunda — live coding. Entrábamos a codewars.com, elegíamos cosas sencillas como ordenar un arreglo de palabras por la última letra y durante 30-40 minutos intentábamos hacer que todas las pruebas pasaran junto con el candidato. Parecía que no debería haber sorpresas de chicos que habían dominado el tres en raya — pero en la práctica no todos lograron entender que el valor debía guardarse en una variable y que la función debía retornar algo a través de return. Aunque espero sinceramente que eso haya sido nervios y que los chicos pudieran resolver estas tareas en condiciones más relajadas.

Finalmente, la tercera — un poco sobre arquitectura. Discutimos cómo se podría hacer una barra de búsqueda, cómo funciona el debounce, cómo renderizar diferentes widgets en las sugerencias de búsqueda, cómo el frontend puede interactuar con el backend. Se encontraron muchas soluciones interesantes, incluido el renderizado del lado del servidor y los websockets.

Hemos realizado 21 entrevistas siguiendo este esquema. La audiencia era completamente diversa — hablemos de cómics:

1. «Raketa». Nunca se calma, se involucra en todo, y durante la entrevista te desbordará con un torrente de pensamientos que ni siquiera están directamente relacionados con la pregunta planteada. Si esto ocurriera en la universidad, sería una conocida tentativa de demostrar todos sus conocimientos, cuando lo único que recuerdas del tema que tocaste ayer por la noche es que decidiste no estudiarlo — de todos modos, no lo sacarás.
2. «Groot». Es bastante difícil establecer contacto con él, porque él es Groot. En la entrevista hay que calentar la conversación durante bastante tiempo, extrayendo respuestas palabra por palabra. Es bueno si simplemente está paralizado — de lo contrario, te será muy difícil en el trabajo diario.
3. «Drax». Antes trabajaba en el transporte de carga, y de programación solo aprendió JS en Stackoverflow, por lo que no siempre comprende de qué se está hablando en la entrevista. Sin embargo, es una buena persona, tiene las mejores intenciones y quiere convertirse en un gran frontend.
4. Y probablemente, «Star-Lord». En general, es un buen candidato, con quien se puede acordar y establecer un diálogo.

Al final de nuestras indagaciones 7 candidatos llegaron a la final, confirmando sus habilidades técnicas con una excelente tarea de prueba y buenas respuestas en la entrevista.

Ajuste cultural

Para la empresa: ¡Vas a trabajar con él! ¿Está realmente el candidato dispuesto a trabajar extremadamente duro para su desarrollo? ¿Realmente se integrará en el equipo?

Para el junior: ¡Vas a trabajar con ellos! ¿Está realmente la empresa lista para invertir en el crecimiento de los juniors, o simplemente te va a dejar todo el trabajo sucio por un salario bajo?

Cada junior, además del equipo del producto, cuyo líder debe aceptar su inclusión, llega a un mentor. La tarea del mentor es guiarlo a través de un proceso de incorporación y desarrollo de habilidades técnicas durante tres meses. Por eso, en cada ajuste cultural llegábamos como mentores y nos hacíamos la siguiente pregunta: «¿Asumiré la responsabilidad de desarrollar al candidato durante 3 meses según nuestro plan?»

Esta etapa se desarrolló sin particularidades y al final nos trajo 4 ofertas, de las cuales 3 fueron aceptadas, y los chicos se unieron a los equipos.

La vida después de la oferta

Para la empresa: ¡Cuida de tus juniors o lo harán otros!

Para el junior: AAAAAAAAAAAAAA!!!

Cuando un nuevo empleado llega, es necesario hacer el onboarding: introducirlo en los procesos, explicarle cómo funciona todo en la empresa y en el equipo, y cómo debe trabajar en general. Cuando llega un junior, es necesario entender cómo desarrollarlo.

Cuando pensamos en esto, elaboramos una lista de 26 habilidades que, en nuestra opinión, debe tener un junior al final del periodo de onboarding de tres meses. Esto incluyó hard skills (según nuestra pila tecnológica), conocimientos sobre nuestros procesos, Scrum, infraestructura y arquitectura del proyecto. Los agrupamos en una hoja de ruta, distribuida a lo largo de 3 meses.

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

A cada junior le asignamos un mentor, quien trabaja con él de manera individual. Dependiendo del mentor y del nivel actual del candidato, las reuniones pueden ser de 1 a 5 veces por semana, cada una de 1 hora. Los mentores son voluntarios, son frontenders proactivos que quieren hacer algo más que solo escribir código.

Parte de la carga de los mentores es asumida por cursos sobre nuestra pila tecnológica — Dart, Angular. Los cursos se llevan a cabo regularmente para grupos pequeños de 4-6 personas, donde los chicos estudian sin interrumpir su trabajo.

Durante 3 meses, recopilamos periódicamente retroalimentación de los juniors, sus mentores y líderes, y ajustamos el proceso de manera individual. 1-2 veces durante el período se realiza una evaluación de las habilidades adquiridas, y se lleva a cabo una evaluación similar al final; en base a ellas se forman recomendaciones sobre qué aspectos deben mejorarse.

Conclusión

Para la empresa: ¿Vale la pena invertir en juniors? ¡Sí!

Para el junior: Busquen empresas que seleccionen cuidadosamente a los candidatos y sepan cómo desarrollarlos.

En 3 meses, revisamos 122 encuestas, 54 tareas de prueba y realizamos 21 entrevistas técnicas. Esto nos trajo 3 juniors excelentes, quienes ahora han completado la mitad de sus hojas de ruta de onboarding y aceleración. Ya están cerrando tareas reales en nuestro proyecto, donde solo en el frontend hay más de 2,000,000 de líneas de código y más de 400 repositorios.

Nos dimos cuenta de que el embudo para juniors puede y debe ser suficientemente complejo, pero al final solo pasan por él aquellos chicos que realmente están listos para trabajar muy duro e invertir en su desarrollo.

Ahora nuestra tarea principal es completar las hojas de ruta de desarrollo de tres meses para cada junior, trabajando de manera individual con un mentor y en cursos generales, recopilando métricas, feedback de los líderes, mentores y de los propios chicos. A partir de esto, se podrá considerar finalizado el primer experimento, hacer conclusiones, mejorar el proceso y reiniciarlo para seleccionar nuevos candidatos.

Fuente: habr.com