Contratación para en Yandex continúa. Vai en cinco direccións: backend, ML, desenvolvemento móbil, frontend e análise. Neste blog, noutros blogs sobre Habré e máis aló, podes atopar moitas ideas sobre o funcionamento das prácticas. Pero moito neste proceso segue sendo un misterio para os que non traballan na empresa. E se miras desde o punto de vista dos xestores de desenvolvemento, aínda xorden máis preguntas. Como realizar correctamente as prácticas, como maximizar a utilidade mutua cun interno, como coñecelo en tres meses e ensinarlle todo o que precisa para seguir traballando?
Cinco de nós preparamos este artigo. Presentámonos: Ignat Kolesnichenko do servizo de tecnoloxía de computación distribuída, Misha Levin do servizo de intelixencia de máquinas Market, Denis Malykh do servizo de desenvolvemento de aplicacións, Seryozha Berezhnoy do departamento de desenvolvemento da interface de busca e Dima Cherkasov do grupo de desenvolvemento antifraude. Cada un de nós representa a súa propia área de prácticas. Todos somos directivos, necesitamos internos e temos algunha experiencia traballando con eles. Contámosche algo desta experiencia.
Entrevista previa a prácticas
Varias entrevistas técnicas agardan aos candidatos. O éxito nunha entrevista depende menos das habilidades blandas (a capacidade de comunicarse de forma eficaz) e máis das habilidades duras (habilidades en matemáticas e programación). Non obstante, os xestores avalían ambos.
Ignat:
Aínda que unha persoa sexa moi legal, pero absolutamente pouco comunicativa, non poderá aplicar todas as súas habilidades. Por suposto, prestamos atención a isto, pero este non é un motivo para non contratar a alguén para unhas prácticas. En tres meses, todo pode cambiar e, ademais, a túa primeira impresión pode resultar incorrecta. E se todo é correcto, terás que explicarlle á persoa, buscar outros comandos. Para os internos, as habilidades de comunicación definitivamente non son un factor clave. Aínda así, as habilidades profesionais son moito máis importantes.
Denis:
Gústame a xente que conta historias, de boa maneira. É interesante unha persoa que poida dicir como el e o seu equipo trataron heroicamente con algúns fakap. Comezo a facer preguntas de seguimento cando xorde unha historia como esta. Pero isto ocorre raramente se simplemente pide "contar algo interesante nos teus proxectos".
Un candidato dixo unha vez unha frase marabillosa, que incluso escribín: "Evite resolver problemas tediosos".
Dado que hai pouco tempo para a comunicación, o entrevistador trata de obter información útil sobre o candidato cada minuto da reunión. É xenial que o interno descubrise de antemán que detalles da súa experiencia (non do seu currículo) podería compartir. Esta debe ser unha historia curta estrictamente ao punto.
Denis:
Presto atención se unha persoa di que probou moitos idiomas e enfoques. As persoas cunha perspectiva máis ampla veñen con solucións máis elegantes no modo de combate. Pero esta é unha vantaxe ambigua. Podes aprender, pero non aprendes nada.
O tempo para as historias descritas por Denis adoita quedar só na entrevista final. Ata entón, é necesario demostrar os coñecementos fundamentais e prácticos que servirán de base para o traballo futuro. E, por suposto, terás que escribir o código nun encerado ou nun anaco de papel.
Misha:
Comprobamos os coñecementos da teoría da probabilidade e da estatística matemática. Observamos se a persoa ten experiencia traballando con métricas, con algoritmos de aprendizaxe automática, coa configuración dos seus parámetros, con reciclaxe, etc. Agardamos que a persoa poida escribir código o suficiente como para ser analista.
Denis:
Os que veñen a unha entrevista saben sobre todo idiomas: en Ekaterimburgo temos unha boa escola de idiomas básicos, bos institutos. Pero para ser honesto, un candidato en prácticas con boas habilidades duras é un caso raro, polo menos no noso barrio de Epsilon. Por exemplo, Swift. Implica un traballo moi complexo con cordas, e hai poucas persoas que poidan traballar con elas desde a cabeza. O ollo chama inmediatamente a túa atención. Adoito dou tarefas nas entrevistas relacionadas co procesamento de cadeas. E en todo este tempo só houbo unha persoa que foi capaz de escribir un código Swift de inmediato, nun anaco de papel. Despois diso, fun dicindo a todos que alguén finalmente puido resolver este problema en Swift nun anaco de papel.
Proba de algoritmos durante unha entrevista
Este é un tema separado porque os candidatos aínda teñen unha pregunta: por que sempre avaliamos o coñecemento de algoritmos e estruturas de datos? Mesmo os futuros desenvolvedores móbiles e desenvolvedores front-end son sometidos a tales probas.
Misha:
Durante a entrevista estamos seguros de dar algún tipo de problema algorítmico. O candidato debe descubrir como implementalo en Python, preferiblemente sen erros. Debe entender como comprobar o seu programa e corrixilo vostede mesmo.
A experiencia en algoritmos é útil por tres razóns. En primeiro lugar, obviamente será necesario en problemas algorítmicos, que non ocorren a miúdo, pero suceden. En segundo lugar, o desenvolvedor poderá resolver de forma máis eficaz os problemas relacionados cos algoritmos, aínda que non requiran profundar nos propios algoritmos (e xa hai bastantes deles). En terceiro lugar, se non che ensinaron algoritmos na universidade, pero aínda sabes como traballar con eles, iso caracterízache como unha persoa curiosa e aumentará a túa autoridade aos ollos do entrevistado.
Denis:
Unha gran parte do desenvolvemento móbil é a mestura JSON. Pero unha vez cada seis meses hai casos nos que se necesitan algoritmos. Actualmente estou debuxando bonitos mapas para Yandex.Weather. E nunha semana tiven que implementar o algoritmo de suavización, o algoritmo de Sutherland-Hodgman e o algoritmo de Martínez. Se unha persoa non soubese o que era un hashmap ou unha cola de prioridade, estaría atascado con el durante moito tempo e non estaría claro se o tería xestionado ou non sen axuda externa.
Os algoritmos son a base do desenvolvemento. Isto é o que axuda a un programador a ser un desenvolvedor. Non importa o que fagas. Tamén son necesarios en proxectos sinxelos, onde o traballo principal consiste en "traducir JSON". Aínda que non escriba os propios algoritmos, pero utilice implicitamente algunhas estruturas de datos, é mellor entendelos. En caso contrario, acabarás con aplicacións lentas ou incorrectas.
Hai programadores que se desenvolveron académicamente: entraron na universidade, estudaron cinco anos e recibiron unha especialidade. Coñecen os algoritmos porque lles ensinaron. E entón o propio coñecemento dos algoritmos non caracteriza os horizontes dunha persoa de ningún xeito; este horizonte debe ser probado doutro xeito.
E hai persoas autodidactas, das que me conto. Si, formalmente teño unha educación informática, un diplomado en enxeñaría de software. Pero as persoas autodidactas aprenderon a programar "a pesar diso". Non tiñan un programa universitario. Normalmente non están familiarizados cos algoritmos, porque nunca se enfrontaron á necesidade de estudalos. E cando esa persoa entende os algoritmos, significa que pasou tempo e os entendeu. Despois de graduarme na universidade, decateime de que tiña puntos cegos en termos de algoritmos fundamentais - o feito é que a miña especialidade foi aplicada. Fun e estudei cursos en liña da Universidade de Princeton, o coñecido Robert Sedgwick. Descubríno e fixen todos os meus deberes. E cando unha persoa conta unha historia similar durante unha entrevista, inmediatamente me interesa, teño ganas de traballar con el ou polo menos de continuar a conversa.
Ignat:
Cando entrevistas a un interno, nalgúns aspectos esperas aínda máis que dun desenvolvedor experimentado. Estamos a falar da capacidade de resolver problemas algorítmicos, escribir rapidamente polo menos algún código correcto. O candidato a prácticas aínda está na universidade. Hai só un ano faláronlle todo sobre os algoritmos en detalle. Espérase que poida reproducilos. Se unha persoa é axeitada e escoitou as conferencias con atención, simplemente saberá todo, obtelo da caché.
Que tarefas resolve o estudante?
Normalmente, o programa de prácticas pode ser descrito e discutido durante as entrevistas finais. Só ao comezo do traballo, a un pasante pódeselle asignar tarefas de formación, cuxos resultados non se utilizarán na produción. Ademais, a probabilidade de recibir tales tarefas é pequena. Na maioría das veces, os proxectos de combate prodúcense a partir do atraso, é dicir, aqueles recoñecidos como dignos de atención, pero non son prioritarios e "separables", para que outros compoñentes non dependan da súa implementación. Os xestores tentan distribuílos para que o estudante coñeza diferentes partes do servizo e traballe no mesmo entorno con outros membros do equipo.
Ignat:
Son tarefas moi útiles. Quizais non aumenten a utilización do clúster nun 10% ou aforren á empresa un millón de dólares, pero farán felices a centos de persoas. Por exemplo, actualmente temos un interno que traballa co noso cliente para executar operacións nos nosos clústeres. Antes de comezar, a operación debe cargar algúns datos no clúster. Isto adoita levar entre 20 e 40 segundos, e antes de que ocorrese en silencio: lanzábao na consola e sentábase alí mirando unha pantalla negra. O estudante veu e fixo a función en dúas semanas: agora podes ver como se cargan os ficheiros e que está a pasar. A tarefa, por unha banda, non é difícil de describir, pero, por outra banda, hai algo no que afondar, que bibliotecas mirar. O mellor é que o fixeches, pasou unha semana, resultou ser en clusters, a xente xa o está a usar. Cando escribes unha publicación na rede interna, din grazas.
Misha:
Os alumnos preparan modelos, recollen datos para eles, elaboran métricas e realizan experimentos. Aos poucos, simplemente comezamos a darlle máis liberdade e responsabilidade: comprobamos se pode manexalo. Se si, pasa ao seguinte nivel. Non asumimos que cando entra un interno, saben como facelo todo. O xestor axúdalle a descubrilo, dálle unha ligazón a un recurso interno ou a un curso en liña.
Se un en prácticas se mostra no seu mellor momento, pode darlle algo de prioridade, importante para o departamento ou outros servizos.
Dima:
O noso pasante agora está a facer modificacións importantes no antifraude. Este é un sistema que combate unha gran variedade de abusos e fraudes nos servizos de Yandex. Nun principio pensamos en dar cousas pouco complexas e pouco importantes para a produción. Tentamos pensar con antelación nas tarefas do pasante, pero despois vimos que a persoa estaba "en chamas", resolvendo os problemas rapidamente e ben. Como resultado, comezamos a encargarlle o lanzamento da loita contra a fraude para novos servizos.
Ademais, hai unha pequena posibilidade de recibir unha tarefa á que os compañeiros non abordaron previamente debido ao seu volume.
Dima:
Hai un sistema antigo e outro novo, aínda non completo. É necesario pasar dun a outro. No futuro, este é un proxecto importante, aínda que cunha gran incerteza: cómpre comunicarse moito, ler un código herdado incomprensible. Na entrevista final, dixémoslle sinceramente ao interno que a tarefa era difícil. El respondeulle que estaba preparado, chegou ao noso equipo e todo lle saíu. Descubriuse que ten as calidades non só de desenvolvedor, senón tamén de xestor. Estaba preparado para andar, descubrir, facer ping.
Mentorización dun interno
Un interno necesita un mentor para mergullarse nos procesos. Esta é unha persoa que é consciente non só das súas propias tarefas, senón tamén das tarefas do interno. Establécese unha comunicación regular co mentor; sempre podes acudir a el para obter consello. O mentor pode ser o líder do grupo (se é un grupo pequeno) ou un dos compañeiros, membros habituais do equipo.
Ignat:
Intento aparecer polo menos cada dous días e preguntarlle como está o interno. Se vexo que estou atascado, intento axudalo, pregúntolle cal é o problema e desenvolo con el. Está claro que isto quita a miña enerxía e fai que o traballo de pasante non sexa tan integralmente eficaz; tamén estou a perder o tempo. Pero isto permítelle non atascarse en nada e obter resultados. E aínda é máis rápido que se o fixera eu. Eu mesmo necesito unhas 5 horas para a tarefa. O en prácticas farao en 5 días. E si, pasarei 2 horas durante estes 5 días para conversar co interno e axudar. Pero aforrarei polo menos 3 horas, e o interno estará encantado de que lle deran algúns consellos e axuda. En xeral, só precisa comunicarse de preto, observar o que fai a persoa e non perder o contacto.
Serioza:
O estudante está constantemente en contacto co seu mentor e comunícase con el varias veces ao día. O mentor revisa o código, fai a programación de pares co interno e axuda cando xorde algún problema. Deste xeito, combinando a axuda dun mentor e tarefas de combate reais, formamos desenvolvedores front-end.
Dima:
Para evitar que un en prácticas sexa abandonado, discutimos quen o orientará mesmo antes de contratalo. Esta é tamén unha gran actualización para o propio mentor: preparación para o papel de xefe de equipo, proba da capacidade de ter presente tanto a súa propia tarefa como a do alumno. Hai xuntanzas periódicas, ás que ás veces vou para min mesmo, para estar informado. Pero é o mentor quen se comunica co interno con bastante regularidade. Pasa moito tempo ao principio, pero paga a pena.
Non obstante, ter un mentor non significa que todos os problemas que xurdan se resolvan a través del.
Misha:
É habitual que as persoas que se enfrontan a un problema pidan consello aos veciños e compañeiros e busquen axuda rapidamente. Canto máis rápido crece unha persoa, máis veces necesita acudir aos seus compañeiros para aprender algo. Mesmo é útil simplemente aprender sobre as tarefas doutras persoas para que poidas crear outras novas. Cando un pasante é capaz de chegar a un acordo, entender o que é importante para a outra parte e chegar a resultados nun equipo, crecerá moito máis rápido que alguén para o que o director debe facer todo isto.
Serioza:
Hai documentación, pero a maior parte da información pérdese no aire. Se o absorbes no inicio da túa carreira, é unha vantaxe adicional e podemos centrar a persoa no que necesita aprender.
O pasante ideal é alguén que se adestra durante varios meses, convértese nun programador júnior, despois só un programador, despois un líder de equipo, etc. Isto require un arquetipo de estudante que non se avergoña de preguntarlle se algo non está claro para el, pero tamén é capaz de traballar independentemente. Se lle dixeron que podía ler sobre el nalgún lugar, iría, lería e realmente volvería con novos coñecementos. Pode cometer erros, pero non debe cometer erros máis dunha vez, como máximo dúas veces, no mesmo lugar. O pasante ideal debe desenvolverse, absorber todo como unha esponxa, aprender e crecer. O que se senta e intenta descubrir todo por si só, pasa moito tempo mirando e non fai ningunha pregunta, é pouco probable que se acostume.
Fin de prácticas
Antes de comezar a traballar, asinamos un contrato de duración determinada con cada estudante. Por suposto, as prácticas son pagas, formalizadas de acordo co Código de Traballo da Federación Rusa, e o pasante ten os mesmos beneficios que calquera outro empregado de Yandex. Despois de tres meses, o programa remata; entón trasladamos moitos dos internos ao persoal (con contrato indefinido).
Por unha banda, é importante para o xestor que o desenvolvedor cumpra o seu mínimo interno. Aquí é onde se conduce o estudante, comezando pola entrevista. Non obstante, este é só o comezo da historia. Para nós, un pasante é sempre un candidato potencial para o persoal. O programa mínimo dun xestor é identificar desde o primeiro momento a unha persoa que, despois de tres meses, non terá vergoña de recomendar a outros departamentos. O programa máximo é mantelo no mesmo equipo, contratándoo como persoal. Asemade, temos en conta que un alumno de segundo ou terceiro curso -aínda que se fixera en prácticas- terá que continuar os seus estudos nunha universidade co inicio do curso académico.
Serioza:
En primeiro lugar, os alumnos son un potencial de recursos humanos para nós. Estamos tentando facer crecer persoas dentro de Yandex para que se adapten perfectamente ás nosas tarefas. Dámoslles de todo, dende unha cultura de comunicación e interacción en equipos ata un coñecemento enciclopédico sobre todos os nosos sistemas.
Ignat:
Cando asumimos un pasante, inmediatamente probamos que se una ao noso equipo. E como regra xeral, o único obstáculo é a falta de praza. Tentamos contratar bastantes mozos como internos. Se unha persoa ten cinco anos de experiencia de desenvolvemento, chega a Yandex e é un pasante ao nivel, entón, por desgraza, para nós isto significa que aínda que é un gran rapaz, xa que consegue un traballo en Yandex con cinco anos de experiencia, non poderá converterse nun programador senior. Normalmente é unha cuestión de velocidade: un crecemento lento no pasado significará un crecemento lento aquí. Si, ás veces a comprensión de que unha persoa non está á altura da tarefa chega só despois de tres meses. Pero isto é bastante raro. En máis da metade dos casos, estamos preparados para contratar persoal. Na miña memoria, nunca houbo unha situación na que unha persoa completase con éxito unhas prácticas, pero non puidese aprobar unha entrevista para un posto a tempo completo.
Misha:
Ofrecemos a todos os pasantes exitosos que permanezan na empresa. Despois dunhas prácticas, adoitamos asumir máis da metade a xornada completa. As prácticas de verán son máis difíciles porque moitas veces acoden a nós estudantes de terceiro e cústalles compaxinar traballo e estudo.
Dima:
Digamos que o estudante fai un gran traballo e ten moitas perspectivas de converterse nun bo programador, aínda que non teña suficiente experiencia neste momento. E supoñamos que non hai praza para un contrato indefinido. Entón todo é sinxelo: teño que ir ao meu director e dicirlle: esta é unha persoa moi xenial, debemos mantelo por todos os medios, ofrécémoslle algo, busquemos un lugar para colocalo.
Historias sobre internos
Denis:
A rapaza que fixo prácticas connosco en 2017 era de Perm. Este está a 400 quilómetros de Ekaterimburgo ao oeste. E todas as semanas viña a nós desde Perm en tren ata a Escola de Desenvolvemento Móbil. Ela viña durante o día, estudaba pola noite e volveu pola noite. Apreciando tal celo, convidámola a traballar, e pagou a pena.
Ignat:
Hai varios anos participamos nun programa de intercambio de prácticas. Foi interesante traballar con rapaces estranxeiros. Pero os aprendices de alí non son máis fortes que, por exemplo, do ShAD ou da Facultade de Informática. Parece que a EPFL está entre as 20 mellores universidades de Europa. Nese momento, como entrevistador aínda pouco experimentado, tiña esta expectativa: incrible, estamos entrevistando a xente da EPFL, van estar super chulos. Pero as persoas que recibiron unha educación básica sobre codificación aquí -incluso nas principais universidades rexionais- resultan ser bastante á altura.
Ou outra historia. Agora teño un rapaz no meu equipo, é moi novo, duns 20 anos. Traballa en San Petersburgo, veu para unhas prácticas. É moi chulo. Ti, como de costume, dáslle problemas a unha persoa, el resolve, e un mes despois vén e dille: Resolvínos, miro, e parece que a túa arquitectura está mal construída. Imos refacelo. O código será máis sinxelo e claro. Eu, por suposto, disuadíno: a cantidade de traballo é grande, non hai beneficios para os usuarios, pero a idea soa absolutamente razoable. A persoa descubriu un proceso complexo multiproceso e suxeriu melloras, quizais inoportunas, a refactorización en aras da refactorización. Pero en canto queiras complicar este código, aínda podes facer esta refactorización. De feito, pasaron varios meses e asumimos esta tarefa. Contrateino encantado. Non todos somos xenios. Podes vir, descubrir algo e sinalar os nosos problemas. Isto é apreciado.
Misha:
Temos internos tan ideais. A pesar da súa falta de experiencia, ven a tarefa non só a nivel técnico, senón tamén a nivel global. Ofrecen melloras fundamentais. Entenden como traducir problemas do mundo real ao mundo técnico sen perder o seu significado. Pregúntanse cal é o obxectivo final, se paga a pena investigar agora en detalles ou se poden cambiar completamente o enfoque da tarefa ou mesmo a formulación do problema. Isto significa que teñen o potencial de ser varios niveis máis altos. Para ir deste xeito, só precisan actualizar algunhas habilidades e ferramentas internas. Ademais lanzar varios proxectos exitosos.
Fonte: www.habr.com