{"id":36985,"date":"2019-10-31T22:15:09","date_gmt":"2019-10-31T19:15:09","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-priruchit-dzhuniora\/"},"modified":"2019-10-31T22:15:09","modified_gmt":"2019-10-31T19:15:09","slug":"kak-priruchit-dzhuniora","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/kak-priruchit-dzhuniora","title":{"rendered":"\u00bfC\u00f3mo domesticar a un junior?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u00bfC\u00f3mo entrar en una gran empresa si eres un junior? \u00bfC\u00f3mo contratar a un junior competente si eres una gran empresa? A continuaci\u00f3n, compartir\u00e9 nuestra historia sobre la contrataci\u00f3n de principiantes para el frontend: c\u00f3mo desarrollamos las pruebas de habilidades, nos preparamos para realizar entrevistas y establecimos un programa de mentor\u00eda para el desarrollo y la incorporaci\u00f3n de nuevos talentos, adem\u00e1s de por qu\u00e9 las preguntas est\u00e1ndar de entrevistas no funcionan.<\/p>\n

\"\u00bfC\u00f3mo
\nYo estoy intentando domesticar a un junior<\/i>
\n<\/a><\/noindex>
\n\u00a1Hola! Me llamo Pavel, hago frontend en el equipo de Wrike. Estamos creando un sistema para la gesti\u00f3n de proyectos y el trabajo colaborativo. He estado en el mundo web desde 2010, trabaj\u00e9 3 a\u00f1os en remoto para el extranjero, particip\u00e9 en varias startups y di un curso sobre tecnolog\u00edas web en la universidad. En la empresa, participo en el desarrollo de cursos t\u00e9cnicos y del programa de mentor\u00eda de Wrike para juniors, as\u00ed como en su reclutamiento directo.<\/p>\n

\u00bfPor qu\u00e9 decidimos contratar juniors en primer lugar?<\/h3>\n

\nHasta hace poco, est\u00e1bamos contratando desarrolladores de frontend de nivel medio o senior, que fueran lo suficientemente independientes como para llevar a cabo tareas del producto despu\u00e9s de la incorporaci\u00f3n. A principios de este a\u00f1o, entendimos que quer\u00edamos cambiar esta pol\u00edtica: en un a\u00f1o, el n\u00famero 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\u00eda duplicarse nuevamente. Hay mucho trabajo, pocas manos libres y a\u00fan 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\u00e1bamos listos para invertir en su desarrollo.<\/p>\n

\u00bfQu\u00e9 es un junior?<\/h3>\n

\nEsta es la primera pregunta que nos hicimos. Existen diferentes criterios, pero el principio m\u00e1s simple y claro es el siguiente:<\/p>\n

A un junior se le tiene que explicar qu\u00e9 caracter\u00edstica y c\u00f3mo implementarla. A un medio se le tiene que explicar qu\u00e9 caracter\u00edstica se necesita, y \u00e9l mismo se encargar\u00e1 de la implementaci\u00f3n. Un senior, por su parte, te explicar\u00e1 por qu\u00e9 esa caracter\u00edstica no deber\u00eda hacerse en absoluto.<\/p><\/blockquote>\n

De un modo u otro, un junior es el desarrollador que necesita consejos sobre c\u00f3mo implementar una soluci\u00f3n u otra. De esto decidimos partir:<\/p>\n

    \n
  1. Un junior es alguien que quiere desarrollarse y est\u00e1 dispuesto a trabajar mucho para ello;<\/li>\n
  2. No siempre sabe en qu\u00e9 direcci\u00f3n quiere desarrollarse;<\/li>\n
  3. Necesita consejos y busca ayuda externa: de su l\u00edder, mentor o en la comunidad.<\/li>\n<\/ol>\n

    \nAdem\u00e1s, ten\u00edamos algunas hip\u00f3tesis:<\/p>\n

      \n
    1. Para el puesto de junior habr\u00e1 una tormenta de respuestas<\/i>. Hay que filtrar las respuestas aleatorias ya en la etapa de env\u00edo del curr\u00edculum;<\/li>\n
    2. El filtro inicial no ayudar\u00e1<\/i> \u2014 necesitamos m\u00e1s tareas de prueba;<\/li>\n
    3. Las tareas de prueba asustar\u00e1n a todos<\/i> \u2014 no son necesarias.<\/li>\n<\/ol>\n

      \nY, por supuesto, ten\u00edamos un objetivo: 4 juniors en 3 semanas<\/b>.<\/p>\n

      Con esta comprensi\u00f3n comenzamos a experimentar. El plan era simple: empezar con un embudo lo m\u00e1s amplio posible y tratar de ir estrech\u00e1ndolo gradualmente para manejar el flujo, pero sin reducirlo a 1 candidato por semana.<\/p>\n

      Publicamos la vacante<\/h3>\n

      <\/p>\n

      Para la empresa<\/b>: \u00a1Habr\u00e1 cientos de respuestas! Piensa en el filtro.<\/p>\n

      Para el junior<\/b>: No tengas miedo del cuestionario antes de enviar el curr\u00edculum y la tarea de prueba, es una se\u00f1al de que la empresa se preocupa por ti y ha configurado bien el proceso.\n<\/p><\/blockquote>\n

      \nEn el primer d\u00eda recibimos alrededor de 70 curr\u00edculos de candidatos 'con conocimientos de JavaScript'. Y luego m\u00e1s. Y m\u00e1s. F\u00edsicamente no pudimos invitar a todos a una entrevista en la oficina y elegimos a los chicos con los proyectos m\u00e1s interesantes, un GitHub activo o al menos experiencia. <\/p>\n

      Pero la principal conclusi\u00f3n que hicimos el primer d\u00eda fue: la tormenta hab\u00eda comenzado. Era hora de a\u00f1adir un formulario de cuestionario antes de enviar el curr\u00edculum. Su tarea era filtrar a los candidatos que no estaban dispuestos a hacer un m\u00ednimo esfuerzo para enviar su curr\u00edculum, y a aquellos que no dominaban los conocimientos y el contexto al menos en la medida suficiente para buscar las respuestas correctas. <\/p>\n

      Inclu\u00eda preguntas est\u00e1ndar sobre JS, maquetaci\u00f3n, web, Computer Science \u2014 las sabe cualquier persona que tenga una idea de lo que se pregunta en una entrevista para frontend. \u00bfCu\u00e1l es la diferencia entre let\/var\/const? \u00bfC\u00f3mo aplicar estilos solo para pantallas que tengan menos de 600px de ancho? No quer\u00edamos hacer estas preguntas en la entrevista t\u00e9cnica, la pr\u00e1ctica mostr\u00f3 que la gente puede responder a ellas despu\u00e9s de 2-3 entrevistas, sin entender realmente de desarrollo. Pero s\u00ed pudieron mostrarnos inicialmente si el candidato comprende, en principio, el contexto.<\/p>\n

      En cada categor\u00eda preparamos de 3 a 5 preguntas y d\u00eda a d\u00eda cambiamos su conjunto en el formulario de respuesta, hasta que eliminamos las m\u00e1s f\u00e1ciles y las m\u00e1s dif\u00edciles. Esto permiti\u00f3 reducir el flujo: en 3 semanas obtuvimos 122 candidatos<\/b>, con los que se pod\u00eda trabajar m\u00e1s adelante. Eran estudiantes de IT; chicos que quer\u00edan pasar del backend al frontend; trabajadores o ingenieros de entre 25 y 35 a\u00f1os que quisieron cambiar radicalmente de profesi\u00f3n y dedicaron diferentes esfuerzos a la autoeducaci\u00f3n, cursos y pasant\u00edas.<\/p>\n

      Conozc\u00e1monos mejor<\/h3>\n

      <\/p>\n

      Para la empresa<\/b>: La tarea de prueba no asusta a los candidatos, sino que ayuda a acortar el embudo.<\/p>\n

      Para el junior<\/b>: No copies y pegues las pruebas; se nota. \u00a1Y mant\u00e9n tu GitHub en orden!\n<\/p><\/blockquote>\n

      Si hubi\u00e9ramos invitado a todos a la entrevista t\u00e9cnica, tendr\u00edamos que realizar aproximadamente 40 entrevistas por semana solo para juniors y solo en frontend. Por eso decidimos probar la segunda hip\u00f3tesis sobre la tarea de prueba.<\/p>\n

      Lo que era importante para nosotros en la prueba:<\/p>\n

        \n
      1. Construir una buena arquitectura escalable, pero sin sobreingenier\u00eda;<\/li>\n
      2. Es mejor tomarse m\u00e1s tiempo y hacerlo bien, que hacer algo r\u00e1pido y enviarlo con el comentario 'definitivamente lo terminar\u00e9';<\/li>\n
      3. El historial de desarrollo en git es parte de la cultura de ingenier\u00eda, la iteratividad en el desarrollo y el hecho de que la soluci\u00f3n no est\u00e9 plagiada descaradamente.<\/li>\n<\/ol>\n

        \nCoincidimos en que quer\u00edamos ver un problema algor\u00edtmico y una peque\u00f1a aplicaci\u00f3n web. Los problemas algor\u00edtmicos estaban preparados al nivel de laboratorios de los cursos iniciales: b\u00fasqueda binaria, ordenaci\u00f3n, verificaci\u00f3n de anagramas, trabajo con listas y \u00e1rboles. Al final nos decidimos por la b\u00fasqueda binaria como la primera opci\u00f3n de prueba. La aplicaci\u00f3n web deb\u00eda ser un tres en raya utilizando cualquier framework (o sin \u00e9l).<\/p>\n

        Casi la mitad de los candidatos restantes completaron la tarea de prueba; recibimos soluciones 54 candidatos<\/b>. Un incre\u00edble insight: \u00bfcu\u00e1ntas implementaciones de tres en raya listas para copiar hay en la red? <\/p>\n

        \u00bfCu\u00e1ntas?<\/b>En realidad, parece que solo hay 3. Y en la gran mayor\u00eda de las soluciones estaban precisamente esas 3 variantes.
        \nLo que no me gust\u00f3:<\/p>\n