company_banner

Как работать с джуниорами?

    Если попробовать ответить на вопрос в заголовке одним предложении, то получится — доверять, но проверять. Доверьте джуниорам какую-то работу, проверьте, помогите, повторите цикл. Но это грубое и упрощённое правило, потому что в работе с джунами возникает так много тонкостей, что об этом нужно рассказывать обстоятельно.



    Рассказывать будет Серёжа Попов, CEO Лига А. и директор по талантам в HTML Academy. В Лига А. работа с джуниорами поставлена на поток: половина фронтендеров компании — это выпускники HTML Academy. Выпускники приходят в компанию на стажировку, где им помогают развиваться, а 95% тех, кто после стажировки ищет другую работу — трудоустраивается.

    Серёжа уже больше 3 лет выполняет роль наставника для джуниор-фронтендеров и научился работать с ними так, чтобы новички быстро росли до крутых специалистов и приносили пользу компании. Нюансами, принципами, правилами и секретами работы, он поделился в докладе на TeamLead Conf 2020, а мы расшифровали.


    Кроме цикла «дать задачу, проверить, помочь» джуниоров нужно: уважать, напоминать, контролировать, думать, что говорить, правильно расставлять задачи, помогать развиваться, указывать на ошибки, но объяснять, быть снисходительным и подбадривать, учить других работать с джуниорами, думать над тоном обратной связи…

    Об этих и других принципах и правилах работы с джуниорами, я расскажу подробно и по порядку. Эти принципы могут быть полезны не только в работе с джунами, но в целом, с кандидатами, которые хотят трудоустроиться в вашу компанию.

    Зачем нужны джуниоры


    Перед тем как рассказать о работе с новичками, расскажу, зачем они вообще нужны. Есть несколько причин (или проблем на рынке).

    Разработчики зажрались дорожают. Зарплаты специалистов высоки, а вместе с ними и стоимость простых задач. Но кто-то должен делать простые задачи. Отдавать их разработчику, который хочет 250 тыс в месяц, — слишком дорого. 

    Если простую задачу ценой в 1000 рублей выполняет человек со ставкой 2500 рублей в час — что-то пошло не так. Поэтому здесь не обойтись без джуниоров — они сокращают стоимость производства (продуктов, ПО). 

    Кадровый голод. По моему опыту, для продуктовых компаний меньше выражена проблема кадрового голода, хотя с каждым годом она становится острее. Но в непродуктовом сегменте, например, в диджитал, голод есть и его много. Там нужны специалисты дешевле, но когда они вырастают, то уходят туда, где платят больше. Джуниоры закрывают потребность в дешевых разработчиках.

    Развитие навыков управления. Когда я общаюсь с опытными руководителями, часто слышу советы в стиле «Заведи ребенка» или «Читай книги о воспитании детей». Причина в том, что джуниоры похожи на детей, а управлять взрослыми серьезными людьми, которые пишут код, достаточно просто — они часто сами знают, что делать и как работать. Джуниоры как дети — после работы с ними ни один миддл не вызовет у вас проблем.

    Выращивание крепких специалистов. Я много общаюсь с представителями разных компаний и часто слышу, что вырастить специалиста внутри проще, чем найти разработчика на рынке. Когда я искал тимлида, в какой-то момент отчаялся настолько, что подумал: «Проще родить ребенка и воспитать из него тимлида». Но это долго — придется ждать 18 лет, до того, как я устрою его на работу.

    Чтобы столько не ждать, опытным путем в Лига А. выработали «инструкцию», как помогать джуниору расти в компании, так, чтобы не было мучительно больно. В «инструкции» несколько этапов, первый из которых — подготовка.

    Подготовка к джуниору


    Чтобы подготовиться, убедитесь, что у вас есть сформированные задачи и ментор.

    Сформированные задачи важны (или понимание, как их сформировать), потому что джуниор — это работник. Он не талисман, который ходит по офису и всех подбадривает, а сотрудник, который должен работать и выполнять задачи.

    Джуниор может выполнять что-то простое:

    • правки;
    • модификации готовых компонент;
    • создание простых компонент;
    • работать по инструкции или документации.

    Ребята, которые попадают к нам, делают простые вещи: вносят правки или собирают страницы по UI-kit. Потом растут и выполняют задачи сложнее, например, пишут простую логику.

    Когда джуниор будет работать над задачами, ему нужен ментор — наставник. В 2018 году я участвовал в ПК FrontendConf. Один из хороших докладов, который не прошел в программу из-за высокой конкуренции, назывался «Что делать, если мне подложили джуна?» Это то чувство, которое возникает у мидла, когда на него пытаются скинуть наставничество. Когда менторство навязывают против воли сотрудника — никто не будет доволен. Важно заранее все обсудить и назначить человека, который будет готов к нагрузке.

    Джуниор это не мидл. Ему нельзя поставить задачу с дедлайном через месяц — он её не сделает. Джуниора нужно постоянно контролировать. Для этого и нужен ментор, который помогает довести задачи до конца.

    • Помогает настроить окружение, потому что джуниор не разберется в том, как это делал сотрудник до него.
    • Определит и сформулирует задачу.
    • Оценит, как и когда джуниор её выполнит.
    • Поставит задачу.
    • Ответит на уточняющие вопросы и направит к решению.
    • Оценит качество выполнения и поймёт, что человек растет. 

    По этим характеристикам ментором должен быть мидл, тимлид, тимлид-мидл, двойной мидл — кто угодно, кто понимает, как работать в компании и что в ней происходит. Главное, что не джуниор — иначе будет два человека, которые не понимают, что происходит.

    Для джуниора должна быть работа и человек, который ее контролирует.

    Отбор


    Второй и самый важный этап, который все недооценивают. На этом этапе придётся научиться многим вещам:

    • привлекать поток джуниоров;

    • просеивать поток до собеседования;
    • собеседовать;
    • отсеивать тестовым заданием;
    • выбирать кандидатов.

    Привлечение


    Есть три способа: своими силами, силами образовательных площадок и с помощью своей школы.

    Своими силами: размещайте вакансии на специализированных площадках вроде hh.ru или Хабр Карьера. Осознанно подойдите к составлению вакансии — от неё зависит сколько нерелевантных откликов вы получите (а получите обязательно). 

    В описании вакансии не добавляйте лишнего. Если просто взять описание для мидла и заменить там одно слово — это не сработает. Джуниоры боятся таких вакансий, когда между словами «Привет» и «Печеньки» находится много незнакомых терминов. Поэтому для джуниоров важно указывать реальные задачи и стек, которые будет использовать человек. Если человек должен верстать — пишите, что кандидат должен знать HTML и CSS. Если надеетесь, что через полгода освоит React — не пишите об этом сейчас, спугнете.

    Образовательные проекты. Избавляют от первого уровня просева, потому что обычно имеют базу успешных выпускников и заинтересованы в их трудоустройстве.

    Своя школа. Например, так делает Яндекс — у них своя школа ШРИ Яндекса. Открывать свою школу — эффективный путь получения хороших начинающих специалистов. Но долгий, дорогой и сложный:

    • придётся разработать образовательную программу;
    • подготовить онлайн-платформу (или найти помещение, если это не онлайн-школа);
    • записывать видео;
    • тратить часы разработчиков;
    • вкладываться в маркетинг.

    Всё для того, чтобы привлечь толпу джуниоров, которые при этом учатся где-то ещё.

    Отсев потока


    После появления вакансии на площадках с работой, вы получите сотни откликов. Но вы не будете брать на работу всех, нужно как-то их отсеивать. Например, когда в Лига А. мы опубликовали вакансию «Начинающий Верстальщик», то получили 164 отклика. Из них до собеседования дошло 10 человек, а вышло на работу — 2.

    8 человек из 10 не дойдет до собеседования.

    Это усредненная статистика: по нашему опыту, по вакансиям Центра Карьеры HTML Academy и по статистике других работодателей. Вас тоже ждёт такая воронка, если не хотите брать на работу всех подряд.

    Будьте готовы просеивать — подготовьте себя и команду к тому, что будет много заявок, но низкая конверсия (как у нас или ещё ниже). У вас должно быть на это время, ресурсы и моральная готовность. После публикации вакансии поток заявок будет нескончаем — в какой-то момент придётся обрубить поток.

    Определите, на что будете обращать внимание. Только вы знаете, какого джуниора хотите найти. Отталкивайтесь от важных в вашей компании навыков и ценностей. Смотрите на подходящие навыки. Если нужен PHP-разработчик, не добавляйте в описание работу с HTML. Если ищете в штат, а в резюме соискателя написано «Только удаленка», то он не подходит. При этом не важно, насколько хорошо резюме — одного критерия достаточно. 

    Снизьте требования к качеству резюме. Несмотря на то, что образовательные проекты учат составлять резюме, в сети есть множество бесплатных материалов, как это делать. Даже существуют сервисы, которые за дополнительную плату доведут резюме до идеала. Несмотря на это, на рынке всё плохо с резюме у всех, а не только у джунов. Я ищу не только джуниоров, но и менеджеров, маркетологов, старших разработчиков, и на рынке почти никто не умеет составлять резюме. 

    Не ждите идеального резюме.

    Максимум, в резюме джуна будет написано, что месяц назад он клал кирпичи на стройке, а теперь дипломированный специалист по CSS.

    Не ждите идеала, а обращайте внимание на любую мелочь: на обучение, интересный опыт, наличие минимального портфолио и адекватные тексты о себе. Например, я часто вижу у молодых кандидатов в разделе о себе что-то вроде «лол, кек, чебурек» и сразу понимаю, что нам с ними не по пути.

    Собеседования


    Это стресс для джуниоров. Например, в Центре Карьеры мы постоянно трудоустраиваем выпускников и каждый день сотрудники начинают со звонков джуниорам, которые трясутся и не могут пойти на собеседование.
     
    Берите людей с запасом. Треть джунов не дойдет до назначенного собеседования: заболела кошка, трамвай сломался, передумал по дороге. У меня был случай, когда я видел из окна, как джуниор дошел до офиса, а у входа развернулся и ушел.

    Брать побольше людей придётся и для того, чтобы у вас был выбор. Но выбирать вам придется не между Ламборджини и Феррари, а между Ладой и Москвичом. 

    Не устраивайте стресс-интервью. Для джуниора любое собеседование — стресс-интервью, даже если вы будете его качать на руках и поить чаем с печеньками. Для проведения собеседования нужен особый навык, чтобы не напугать человека, а раскрыть.

    Именно по этой причине не приходите на собеседование всем отделом. Вы успеете посмотреть на человека, когда он выйдет на работу. Даже мидлов и сеньоров напрягает, когда на собеседование приходит 10 человек из CTO, CMO, CPO и старших разработчиков, а для джуниора это ад. Поэтому лучший формат — один на один. Проведите хотя бы первое собеседование в таком формате.

    Зовите больше кандидатов, но меньше коллег.

    Не давайте тестовое задание на собеседовании. Мы в Лига А. собираем истории от джуниоров о том, как у них проходит трудоустройство. Один из случаев: новичок пришел на собеседование, а интервьюер даёт ноутбук и говорит:

    — Сверстай по PSD.

    И уходит за чаем. Руки джуниора в этом время не слушаются, пальцы немеют, а ноутбук искрит от того, что на него падают капли пота. Джуниор не сделает тестовое задание на собседовании, потому что напуган.

    Но не отказывайтесь от технических вопросов: спросите, что такое HTML, CSS, как работает JavaScript, что такое браузер:) Но только если видите, что человека не трясет и он не упал в обморок.

    Смотрите на развитие и адекватность. Узнайте, как он учился и как узнает новую информацию. Если человек расскажет о важных для сообщества подкастах, митапах, конференциях, блогах, каналах на YouTube — это то, что нужно. Если отвечает: «Я диплом получил, зачем мне ещё учиться?», то до свидания.

    Желание обучаться — одна из ценностей компании, по которым мы также отбираем кандидатов. Ещё одна ценность — «горящие глаза». «Горящие глаза» подскажут, что человек готов работать. Не сам он горит, а только глаза. Сам он гореть будет, когда устроится на работу.

    Тестовое задание


    По нашему опыту тестовое задание лучше давать после собеседования. Сначала просеиваете поток, оставляете адекватных, и среди них отбираете тех, кто умеет что-то делать. Но у вас может быть по-другому.

    Упрощайте тестовое задание. Не давайте сложное, если хотите получить решения от кандидатов. Джуниоры с опаской подходят к решению задач, которые не решали. Если задание будет технически сложным — они к нему просто не приступят.

    Трое из четырех джуниоров не возьмутся за сложное тестовое задание.

    Разработайте простое задание, которое покажет вам необходимые компетенции кандидата, чтобы его мог сделать джуниор. Например, если ищете верстальщика — дайте задание сверстать кнопку, а если JavaScript-разработчика — сделать калькулятор тарифов. Слишком сложное задание отпугнет хороших кандидатов.

    Расписывайте задание максимально подробно и понятно. У джуниоров нет опыта, на который они могут опираться. Они не делали 10 000 тестовых заданий, не знают нюансов и тонкостей. Скорее всего, ваше будет одним из первых и джуниор будет делать то, что видит. Если нужен результат, опишите его максимально подробно.

    Указывайте сроки на выполнение. Но ставьте запас, потому что джуниоры работают медленнее. Если не поставите сроки, кандидат может делать задание месяцы. Например, так случилось с одним кандидатом, который прислал мне тестовое задание спустя месяц (притом хорошо выполненное). Но беда в том, что вакансию мы закрыли за две недели до этого.

    Ставьте сроки из расчёта 2 к 1. Джуниоры выполняют работу примерно в 2 раза медленнее. Если даёте тестовое задание на 2 часа, рассчитывайте, что джуниор выполнит его за 4.

    Даже в этом случае джуниор может не успеть. Договоритесь с кандидатом, что он отправит результат, независимо от степени готовности. Так вы хотя бы поймете примерный уровень человека.

    Контролируйте обратную связь. «Разнести в хлам» тестовое задание — не лучший способ давать обратную связь кому угодно, не только джуниорам. Написать, что всё сделано ужасно, может каждый. Верный путь — рассказать, в какую сторону расти, чтобы устроиться позже.

    Некоторые талантливые джуны после 2-3 коротких и гневных фидбеков перестают искать работу. Но это не проблема кандидатов — это проблема работодателя. Ведь это закономерно: работодатель пишет неправильную вакансию, неверно оценивает кандидатов и дает неправильное тестовое задание, а потом срывается на джуниоре, потому что тот не удовлетворяет требованиям мидла… Зачем? 

    Выбор кандидата


    Выбирайте несколько человек. Кадровый резерв в несколько кандидатов позволит избежать проблем: некоторые джуниоры не выходят на работу, кто-то отрабатывает меньше двух недель. «Запас» поможет не запускать поиск заново при форс-мажорах.

    Но не берите несколько человек с расчётом на то, что в конце останется только один. Это не игра на выживание.

    Берите на перспективу. Джуниор не выдаёт результат здесь и сейчас. Рассчитывайте на то, что он будет приносить пользу через полгода. 

    Не назначайте дату выхода больше, чем на неделю. Джуниор нервничает. За неделю он может перегореть, испугаться, найти новую профессию и просто не выйти на работу. В идеале — выводите на работу через пару дней.

    Хороший способ не нервничать — чем-то заняться: почитать о корпоративной культуре, познакомиться с продуктами, изучить code style. Дайте задание до выхода этими и другими способами подготовиться к работе.

    Держите контакт. Не бросайте человека до выхода на работу — периодически интересуйтесь, как у него дела. Эта поддержка поможет ему, а вы поймете, что надо искать нового, если человек перестанет отвечать. Например, одного из наших выпускников взяли на работу в другую компанию, а дату выхода назначили через месяц. Но за это время ему никто не позвонил, не написал и не напомнил, когда выходить на работу. Ожидаемо, что через месяц джуниор не вышел 

    Испытательный срок. Первые два месяца новичок работает на 200% своих возможностей, а дальше устаёт и раскрывает свои истинные таланты. Поэтому прописывайте время испытательного срока в три месяца — это оптимально.

    Добавьте результаты или критерии оценки испытательного срока, чтобы было проще увольнять, потому что не все джуниоры «одинаково полезны». Некоторые из них так юридически подготовлены, что вам будет трудно их уволить, даже если они не работали. С критериями в договоре это будет проще.

    Через две закрытые вакансии вы научитесь отбирать джуниоров.

    Работа


    Работа с джуниором начинается с онбординга — введения новичка в коллектив. В онбординге есть несколько критичных правил, которые важны не только для джуниоров.

    Онбординг


    Не бросайте в «мясорубку». Как избавиться от джуниора? Кидаете в него в первый день боевую задачу, например, развернуть окружение, и уходите. У него начинается паника. Приходите через неделю за результатом, а у вас «мёртвый» джуниор (если он еще не уволился) и невыполненная задача.

    Не оставляйте одного. Моя первая работа разработчиком в большой компании проходила в Veeam Software. Тогда мне не нравилось, что меня таскали на дурацкие планёрки: полно народу, все что-то говорят, какие-то странные люди по Skype разговаривают на английском, ничего не понятно, что происходит. Но сейчас я понимаю, что это помогло мне окрепнуть, «окунуться» в рабочий процесс и стать частью коллектива.

    Познакомьте джуниора с командой, расскажите к кому обращаться с вопросами — проведите по всем этапам онбординга, как и всех остальных. Привлекайте в командные процессы — если оставить джуниора одного, он не будет ничего делать, потому что не знает, что делать. Именно поэтому по нашей статистике 40% джуниоров уходят в течении двух недель, если их просто «бросают» в процесс. 

    Дайте время. Новая работа стресс для всех. Для джуниора новая работа — двойной стресс. Не выдавайте список задач с первого дня. Дайте привыкнуть, почувствовать компанию, познакомиться, прочитать регламенты.

    Когда джуниор привыкнет и успокоится, нагружайте работой. Не затягивайте онбординг на недели. Все-таки вы наняли разработчика — он должен работать.

    Процесс работы


    Прошла неделя, две — джуниор «окреп» и привык. Что изменилось в нашем подходе?

    Не бросайте в «мясорубку». Спустя неделю все равно не стоит бросать его «на передовую». Джуниор всё равно не даст вам тот же результат, что и мидл, при этом вы рискуете не получить результат и демотивировать человека. Ищите для него отдельные задачи, ставьте сроки с учетом скорости и следите за результатом.

    Не оставляйте одного. Всё также следите за джуниором, чтобы он не скучал, не перетруждался, отвечайте на вопросы и старайтесь «влить» в команду.

    • Берите на все командные и рабочие мероприятия даже в качестве слушателя.
    • Возьмите джуна в релиз — пусть сидит и смотрит, как все бегают «в огне». На третий релиз он начнет помогать.
    • Учите работать в команде. Джуниоры умеют писать код и работать с системой контроля версий, но не в команде. Будьте к этому готовы, учитывайте это и помогайте наладить взаимодействию.
    • Не позволяйте команде обижать джунов. Если у вас есть джуниор, значит он нужен. Следите, чтобы другие разработчики не грубили и не отказывали в помощи.
    • Не позволяйте джунам обижать команду. Когда джуниор не принимает правила работы, вступает в конфликты и споры со старшими специалистами, говорит:«Я д’Артаньян, а вы нет», и работа с ним превращается в ад — меняйте. За дверью стоит очередь из таких же. 
    • Не доверяйте. Настраивайте безопасное окружение, отдельные ветки, запрет на коммит в мастер — все на уровне системы, а не на честное слово. 

    Выдавайте чёткие инструкции. Чем понятнее будет сформулирована задача, тем выше шанс, что джуниор её сделает. Но когда он её делает, расспрашивайте новичка о том, как идет работа, чтобы он не успел «закопаться».

    Джуниор никогда не расспросит о задаче, не уточнит, а будет пытаться все решить сам. Когда джуниор сидит 3 дня над задачей и не задаёт вопросы — это обычная ситуация. Многие не умеют и боятся задавать вопрос. 

    Закопаться он может также потому, что не умеет оценивать сроки. Не доверяйте оценке джуниора. Он начинает точно оценивать сроки своей работы через полгода. До этого времени анализируйте его прошлые задачи и ставьте срок, исходя из них. Но продолжайте просить его оценивать себя самостоятельно, пусть учится.

    В то же время, не беспокойте джуниора слишком часто. Джуниоры работают медленнее — в 1,5-2 раза медленнее, по статистике Лига А., HTML Academy и других проектов на выборке в 500 джунов. Учитывайте это при постановке задач и планировании. Если джуниор будет систематически не успевать за вашими сроками, это будет его демотивировать. 

    Джуниор трепетно относится к результату своей работы. Например, они могут реагировать так:

    — Как вы посмели провести код-ревью моего кода! Я не привык к тому, что мне указывают на мои ошибки!

    Это выдержка из рабочего чата от разгневанного джуниора. Джуниоры не привыкли к разбору их кода, в отличии от опытных разработчиков. 

    Когда он выполнит работу — выдавайте максимум обратной связи. Фидбек и помощь нужны и опытным разработчикам, что говорить о неопытных.

    • Для каждого джуниора код-ревью это стресс. Проводите код-ревью и тестирование проектов «нежно»: указывайте на ошибки, но не уничтожайте человека резкостью.
    • Старайтесь не только указывать на ошибки, но и хвалить — это мотивирует.
    • Корректно формулируйте ошибки и способы их исправления. Джуниор может переделать весь блок, потому что решит, что ошибку можно исправить только так.

    В ваших интересах, чтобы джуниор быстрее развивался и стал приносить максимум пользы.

    Мотивация


    Через выполненные задачи. Джуниоры понимают, что они в начале своего пути и каждая новая задача — «путь к успеху». Ничто так не вдохновляет в начале пути, как ощущение того, что работа получается.

    Через доверие. Джуниоры знают, как сложно найти работу и начать работать в сфере, поэтому благодарны. Если они у вас, они уже мотивированы. Но доверие нужно развивать и увеличивать. 

    Через рост. Через рост в должности и задачах джуниор чувствует, что в него верит команда. Если человек 2 месяца будет править текст, его это перестанет мотивировать. Выдавайте более амбициозные задачи через некоторое время.

    Никто не хочет быть вечным джуном.

    Не держите джуна долго в статусе начинающего специалиста, растите внутри компании. Через 3-6 месяцев новичок вырастает в крепкого специалиста.

    Но всё это работает при наличии зарплаты. Джунам надо платить деньги. Возможны бесплатные стажировки, но без денег джун долго не протянет.

    Что дальше?


    Подытожим как работать джуниорами: проявите терпение, научитесь отбирать среди сотни кандидатов, помните об особенностях, чтобы понимать, как они могут влиять на работу. Доверяйте, растите, не бросайте, мотивируйте выполненными задачами и растите доверие.

    Не бойтесь джуниоров и процесса их поиска. У них есть плюсы.

    • Горящие глаза и способность давать результат. Если учтете все нюансы и выберете правильного человека, то результат будет.
    • Стартовая зарплата в два-три раза ниже рынка. 
    • Трудно мотивировать человека, который работает только за деньги. Джуниоров мотивируют не только деньги.
    • Нет предубеждений относительно рынка и компании. Для большинства джуниоров ваша компания будет первой. У него не будет опыта работы в других компаниях и будет проще их приучить к вашей культуре.

    Джунов много.

    Будет из кого выбрать. У вас не будет моей ситуации, когда 4 кадровых агентства искали мне сеньора 2,5 года. С джунами проще: заходите в метро, берете первого попавшегося человека — это готовый фронтендер-джуниор.

    Приготовьтесь к тому, что джуниоры будут:

    • бесить;
    • задавать тупые вопросы;
    • остро реагировать на критику;
    • медленно работать;
    • подвергать сомнению ваше доверие к ним;
    • бесить.

    Но если вы научитесь понимать их и направлять, то джуны будут: быстро расти, лояльны компании, которая дала им шанс, проникаться культурой и ценностями. 

    Если понравится — вы захотите ещё джуниоров. Лучший наставник для джуниора это бывший джуниор, поэтому они с радостью будут помогать обучать новичков. Но, как и все другие специалисты, они будут когда-то уходить — будьте готовы. Все уходят.

    Вторую TeamLead Conf в этом году мы снова проведем в Москве, 16 и 17 ноября. Это будет очная встреча со всеми атрибутами: спикерами на сцене, кулуарным общением, митапами-воркшопами и кофебрейками. 

    На осень мы выбрали такие темы: управление командой, бизнес-процессы, трансформационные изменения в людях и командах, коммуникация, работа над собой и личное развитие, развитие осознанности, инструментарий тимлида, работа с командой и новая культура в организации. Если у вас есть, что сказать по этому поводу, присылайте заявку на доклад. Как обычно, чем раньше это сделать, тем больше шансов попасть в программу конференции.

    Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

    Тестовое задание давать:

    • 35,2%до собеседования56
    • 41,5%после собеседования66
    • 23,3%никогда37

    Джуниоры…

    • 83,8%нужны145
    • 1,7%не нужны3
    • 14,4%бесят25
    Конференции Олега Бунина (Онтико)
    Конференции Олега Бунина

    Комментарии 51

      +6

      Я-бы добавил несколько аргументов за:


      • Джуниоров можно научить тому стеку который вам нужен, а не тому который популярен
      • Обратная мотивация — если ментор добровольно принял на себя эту роль — джуниор(ы) с горящими глазами будут его мотивировать

      Несколько против:


      • Период окупаемости — в зависимости от кривой обучения, они начинают быть выгодными позднее чем сформировавшийся сотрудник
      • Не все могут и/или хотят менторить, может оказаться что вашей команде таких людей просто нет.

      И о собеседованиях:
      ИМХО, в джуниорах самое важное, это их мотивация (а.к.а горящие глаза) и обучаемость, проверить эти факторы по резюме практически невозможно так что, для себя, я выработал следующую методику:
      Со всеми, кто подходит по формальным требованиям ( город, например ) проводится микро-интервью по скайпу/телефону, буквально на 15 минут, в течении которых здаютися вопросы "почему IT" — узнать по мотивацию и пару вопросов на умение обучаться. Вида "сложный вопрос для которого не хватает знаний" -> "выдать недостающие знания" -> "смотреть смог-ли сформулировать ответ на изначальный вопрос" — оценить способность обучаться, а дальше уже обычное собедование, если все хорошо.

        +1
        Джуниоров можно научить тому стеку который вам нужен, а не тому который популярен

        Встречал ситуацию, когда джуниоры в ответ на такое начинали сваливать. Мотивируя это тем, что им нужно строить карьеру, а для этого нужен востребованный на рынке стек. А засесть за что-то малопопулярное и тупиковое — это потратить зря время и проиграть в конкурентной борьбе другим.

        +5
        Зачем нужны джуниоры
        Приведённые аргументы в целом разумны и правильны. Но есть одно серьезное «но».

        Почему-то в очень многих головах сегодня понятие «джуниор» приравнивается к понятию «новичок». Очень часто с этим приходится сталкиваться. И автор доклада, кажется, тоже этим грешит.
        Я видел на ютубе ролики, где девочка сразу после вайтишных курсов считала себя джуниором, а ещё через год уже крутила носом, мол, «я уровень джуниора переросла». Это что получается, годовалый вайтишник — уже мидл что ли? Но это же нонсенс.

        Джуниором человек становится после 0,5-1 года реального опыта. А до того это новичок, стажер, трейни, называйте как хотите.
        Нельзя забывать, что в словосочетании junior developer есть второе слово. Джуниор это пусть и младший, но разработчик — человек, который уже что-то умеет разрабатывать и обладает какой-то минимальной самостоятельностью.

        Пожалуста, прекратите девальвировать термин, и многие из описанных вопросов решатся сами собой.
          +1

          А разве деление на джун/мидл/синьор вообще не субъективно? Некоторые после двух лет опыта ярлычок синьора навешивают. На этом фоне даже новичка с нулевым опытом назвать джуном будет корректно.
          Как по мне, если тебя взяли на оплачиваемую работу (не стажировку!), то пусть у тебя хоть один день опыта — ты джун.
          А вообще все эти названия чистое лукавство, software developer определяется только годами опыта, закрытыми проектами (если nda позволяет) и скиллом который проверяется на собеседовании.

            +1
            Да тут не субъективизмы даже, а эвфемизмы :) Первые месяцы работы по сути и являются оплачиваемой стажировкой, даже если вслух это никто не произносит.

            Я бы сделал критерием перехода от стажера к джуну прибыльность. Как только человек даёт прибыль больше, чем проедает — он джун. С важным условием: прибавляя к его з/п трудозатраты коллег, которые его менторят и, возможно, что-то доделывают за ним.

            Увы, такие метрики нелегко подcчитываются и не публикуется. Но бывает, их можно приблизительно узнать в приватных разговорах с тимлидами и владельцами бизнесов.
            –2

            dom1n1k Поддерживаю Ваши мысли.


            Ей-богу, еще года 3 назад интернатура в "средних" компаниях вообще не практиковалась. Сейчас же, получить боевой опыт в пол года или год — проще простого. Но даже этот опыт, не позволит называть себя/кадра специалистом в области. Как правило (в моей практике есть исключения) молодые бойцы приходят с базовыми знаниями ЯП. Одного ЯП. Это прискорбно. Никто не хочет выходить из своей зоны комфорта. Кодил в универе на питоне — пойду искать интернатуру на питоне. Показывают на интернатуре плюсы — он бежит. Побежит туда, где ему комфортно. Большинство ребят идут в профессию, только потому что думают, то что здесь "сладко".


            Sergey1001 Вы тоже правы, эти все звезды, это все — субъективно. Инженер должен оцениваться уровнем своей квалификации, но не как "выслугой". Ну а джуны с нулевым опытом — интерны.

              +1
              Джуниором человек становится после 0,5-1 года реального опыта. А до того это новичок, стажер, трейни, называйте как хотите.

              Почему-то очень многие люди выдумывают свои трактовки терминов, лишь бы был повод обосновать свое решение "мы хотим брать опытных, а опыт им пусть другие дают за свой счет". Работника надо называть стажер или трейни, если у вас на работе проводятся стажировки и тренинги, а он их участник. Если он у вас работает за зарплату на таких же условиях, как остальные разработчики, значит он junior разработчик, даже если он работает первый месяц. И да, он находится на это уровне в среднем пару лет, потом становится middle.

                0
                Так это не я выдумываю, это как раз новоизобретения последних лет, что вайтишник с нулем опыта уже джун :)

                мы хотим брать опытных
                Полгода — это не «опытный». Это просто человек, которому не нужно объяснять совсем уж элементарное, и который не обходится в несколько раз дороже своей з/п. То есть не работает в минус.
                Первые полгода-год стажа — это всегда по факту оплачиваемая стажировка, даже если официально это так не называется.
                  +2

                  Неважно, сколько у него опыта. Если он умеет написать работающую программу в соответствии с требованиями, значит он junior developer, а никакой не стажер. Любая лаба в универе это и есть написание программы в соответствии с требованиями. Само слово junior как раз и обозначает начальный уровень опыта специалиста, закончившего учебное заведение. До этого он студент.


                  Мне непонятно, зачем надо менять изначальный смысл слова junior и придумывать еще каких-то стажеров, которыми оказываются 100% выпускников, и которые при этом не участвуют ни в какой стажировке.


                  Первые полгода-год стажа — это всегда по факту оплачиваемая стажировка

                  Первые полгода-год стажа — это работа junior разработчика. Само слово junior подразумевает, что у него меньше опыта, чем у среднего специалиста, и чтобы дойти до уровня среднего специалиста, он должен его получить. Что он и делает эти полгода-год.

                    +1
                    То есть не работает в минус.

                    Если у вас сотрудник работает в минус, значит вы можете уволить его совершенно без вреда для проекта. Если же это не так, значит вы неправильно конвертируете приносимую сотрудником пользу в деньги.

                      +1

                      Если у вас джуны приносят прибыль с места возможны 3 варианта.


                      1. Вы и ваша компания научилась сверхбыстро адаптировать джунов так, чтобы они быстро и хорошо решали задачи. Тогда ваша компания должна быть лидером рынка и зарабатывать много денег.
                      2. Вы даете джунам самые простые задачи и таких задач у вас много. Тогда вы занимаетесь чем то не особо сложным.
                      3. Вы не считаете косвенные затраты на работу джуна. Тогда наверное получается что на регулярах и сеньорах вы получаете прибыль меньше.

                      Есть ещё один вариант — вы лукавите) Но я даже боюсь представить, зачем это вам может быть нужно.

                        0

                        Нет, есть еще 4 вариант, который я уже написал — вы неправильно конвертируете приносимую сотрудником пользу в деньги. Зачем вам джуны, если они бесполезны для вашего проекта? Раз нанимаете, значит они зачем-то вам нужны?

                          +1

                          Да, для того чтобы вкладывая в них время и деньги, со временем получить хороших спецов. Джуны — инвестиции в будущее. Если вы растете — необходимые инвестиции.

                          +1
                          Ещё один возможный вариант — человек немного теоретик.
                  0

                  Горящие глаза могут быть по другой причине, а если и по этой, то не значит, что они не загорятся уже завтра на другое.

                    +1

                    Побуду адвокатом дьявола.
                    Зачем брать джуниора и иметь все эти проблемы, если можно взять миддла с заниженной самооценкой, нагружать его как миддла и платить как джуниору?

                      +3

                      Главная проблема джуниоров в том, что они сваливают. Поработают годик у вас, наберутся опыта, потратят вам кучу нервов и ресурсов на исправление косяков, поднимут свою стоимость на рынке труда, а потом бац — и упорхнут куда-нибудь на условия получше.


                      И да, если вы не гугл-яндекс, то всегда найдется кто-то, кто даст условия лучше. Небольшие компании весьма ограничены в ресурсах и не могут джуниорам давать супер-зарплаты (да и какой смысл, если джуниор не будет эту зарплату отрабатывать?), а офис какого-нибудь ИП Пупкин всегда будет хуже, чем офис крупной конторы. Плюс у джуниоров часто есть желание попробовать себя в большой и известной конторе, вкусить прелести кровавого энтерпрайза, попробовать поработать "по-взрослому".


                      Причем вероятно, что через несколько лет такие люди уже будут выть от этого энтерпрайза, так как ничего хорошего в нем, как правило, нет. Но для начала им все-таки хочется попробовать и убедиться в этом на своем опыте.


                      В итоге джуниор — это большие издержки и инвестиции, и при этом большой риск того, что они никогда не окупятся и весь профит достанется кому-то другому.


                      Я достаточно поработал со студентами (так как работаю в универе в лаборатории, делающей всякие урбанистично-айтишные штуки на заказ), и решил что все, хватит. Теперь только люди с опытом, уже понявшие чего они хотят от работы и карьеры.


                      Так что джуниоры — они хороши для крупных контор (где есть ресурсы, менторы и возможность дать суперпривлекательные условия), а не для мелких-средних.

                        +1
                        Меня ваш комментарий прямо за живое задел, потому что сам был именно таким джуниором.

                        Это все же проблема не джунов, а компаний, которые их нанимают. Потому что сначала зовут вчерашних студентов, на собеседовании рассказывают про то, как они «предпочитают выращивать своих специалистов, а не брать со стороны», а потом через полгода-год выясняется, что ты как-то слишком сильно вырос, а ни новых задач, ни повышенной (хотя бы на уровне чуть-меньше-рынка) оплаты тебе не полагается. И вот что в такой ситуации предлагаете делать?

                        Винить людей в том, что они хотят работать и получать за это достойную оплату — контрпродуктивно.
                          +1
                          а потом через полгода-год выясняется, что ты как-то слишком сильно вырос
                          Я не знаю вас лично, может быть вы исключение, которые действительно иногда случаются.
                          Но в большинстве случаев в реальности эта фраза означала бы что-то типа: «наконец-то перестал жечь тоннами время ментора, теперь ему можно хоть что-то поручить и начать, наконец, окупать инвестиции нескольких месяцев».

                          Проблема в том, что первые несколько месяцев новичок мало того, что не окупает даже собственную зарплату, но в реальности обходится в несколько раз дороже её, поскольку прямо и косвенно тратит время коллег.
                          Но по-честному сказать «а давай мы тебе сейчас дадим чисто символическую стипендию, а потом 2-3 раза хорошо повысим с интервалами в полгода» не получается — никто не пойдет на такие условия, у всех самомнение, все хотят «достойную оплату».
                            +2
                            Я не предлагаю платить сразу как хорошему спецу, вариант с
                            потом 2-3 раза хорошо повысим
                            меня вполне бы устроил. Но этого не произошло. Потому что брали не джуна на вырост, а человека, который задешево сможет закрывать несложные таски. Собственно, почти весь отдел из таких и состоял, и все примерно в одно время всё поняли и с интервалом в два-три месяца ушли.

                            В этом я и вижу главную проблему — иногда компаниям не нужен рост сотрудника, им нужен вечный вчерашний студент, готовый работать за миску супа. Но ищут, почему-то, джуна на вырост.

                            Опять же, я понимаю, что единственный личный пример — далеко не показатель, и, быть может, это мне так не повезло. К сожалению, второй раз я джуном уже стать не смогу
                              0
                              вариант с «потом 2-3 раза хорошо повысим» меня вполне бы устроил.
                              Вы пропустили первую часть фразы про символическую стипендию, а она там ключевая. Покажу на примере (всё очень утрированно, цифры условны):
                              Приходит студент, ему дают 500 баксов. Первые полгода он приносит пользы на -500 баксов (то есть фактически ему платят как бы 1000), вторые полгода идут примерно в ноль, после года он наконец выходит в стабильный плюс. Именно в этот момент джун обижается, что его не ценят и уходит.

                              Мой гипотетический вариант такой: дорогой студент, давай на старте мы дадим тебе 100 (чисто чтобы тебе хватало на проезд и перекус), через полгода сделаем 400, ещё через полгода 700, еще через полгода 1000.
                              Что это могло бы дать? Более честные отношения. Новичок не получает денег, которых он не стоит и более адекватно оценивает свой прогресс. Компания несет меньшие риски.

                              Но как мы понимаем, в реальной жизни так не бывает. Новичок хочет з/п с самого начала. А компания вынуждена рисковать, что эти инвестиции не окупятся никогда (и частенько так и происходит). Что делать в такой ситуации? Я не знаю, жизнь сложная штука. :)
                                0
                                Насчет вашего гипотетического варианта: 100 и правда хватит на перекус и проезд, но ведь есть еще множество других трат, которые обязательны для жизни, и джун в итоге без «помощи родителей» или подработок (которые только будут утомлять, а не помогать в адаптации) просто не сможет отдавать себя работе полноценно. Вот как раз эти 400-500 и дают возможность просто существовать (кушать, жилье, проезд).
                                Естественно будут люди, которые скажут «да я вообще без зп пол года работал». Видимо на старте у них была отличная помощь финансовая, а не только их огромное желание.
                                  +1
                                  Понимаю. Собственно, в этом и состоит сложность ситуации — работнику действительно нужны средства к существованию, но непонятно, почему работодатель должен давать их за просто так. Он же их не печатает.
                                  В итоге имеем то что имеем: новичок насколько месяцев живет не на зарплату, а на субсидию. Но не понимает этого (или не хочет понимать) и обижается что его не ценят, ведь он же вырос! А фактически — наконец дорос до той з/п, которую ему дали изначально.

                                  Кстати, это похоже на проблему с декретами (а точнее, с советским трудовым законодательством) — при всем уважении к материнству, почему частный работодатель должен оплачивать чьего-то ребенка? Пусть муж оплачивает.
                                    0
                                    почему частный работодатель должен оплачивать чьего-то ребенка?

                                    Так вроде отпуск по уходу за ребенком оплачивается из ОМС. Поправьте меня, если не так.

                                      0
                                      Насколько я знаю, оплачивает работодатель, получая потом возмещение из ФСС. Только получается это возмещение с задержкой в несколько месяцев. Получается, что работодатель одновременно оплачивает декрет старой сотруднице + онбординг нового неопытного сотрудника, а работа пробуксовывает. Это бывает чувствительно для малого бизнеса.
                                        0

                                        Сейчас вроде переходят на прямые выплаты из ФСС, мне новость попадалась где-то.

                                  +1
                                  Курсы водителей троллейбусов. Кто проходит, подписывает обязательство, что проработает какое-то время. Можно сделать так же.
                                  100 долларов может не хватить.
                                    +1

                                    В ИТ сфере это очень много негатива вызывает. У нас сфера изначально высокомобильная и все к этому привыкли.

                                0
                                Проблема в том, что первые несколько месяцев новичок мало того, что не окупает даже собственную зарплату, но в реальности обходится в несколько раз дороже её, поскольку прямо и косвенно тратит время коллег.

                                Приведите пожалуйста пару примеров, что вы под этим подразумеваете?

                                  +2
                                  Неопытному сотруднику нужно ставить задачи намного подробнее, чем другим. Глубже декомпозировать и подробнее рассказывать. В ходе выполнения задачи отвечать на множество вопросов. Контролировать промежуточные результаты и объяснять как исправить косяки. Всё это время более опытных (более дорогих) сотрудников.
                                  Но даже после нескольких итераций исправлений, как правило, результат всё равно оказывается ниже качеством, чем если бы его изначально делал опытный исполнитель. Это даёт отложенный эффект — больше работы тестировщикам, менеджерам, поддержке и так далее.
                                    0

                                    Это все справедливо для любого нового человека на проекте, даже если он senior. Потому что новый сотрудник не знает ваш проект. Серьезно, что вы такого рассказываете джуниорам, что не связано с проектом, да еще в таком количестве? И почему некачественный код проходит код-ревью и попадает на тестирование и в продакшн?


                                    Я вот например до первой работы не знал, как пользоваться системой контроля версий. Тимлид один раз показал как коммитить и пару раз как разрешать конфликты. Такие вещи не должны занимать много времени.

                                      +1

                                      Нет, сеньору можно дать задачу в общих чертах и он сам разберется.
                                      Джуниору нужно буквально тыкать во все подряд. Сам он НЕ разберется. Ну или будет делать это оооочень долго.


                                      Джуниор не способен решать комплексные задачи, часто говнокодит, изобретает велосипеды и просто зависает на каких-то казалось бы элементарных вещах (но которым в вузике не учили). Джуниор еще не знает тысячи и одной проблем инструментов своих. Там где сеньор, встретив какую-нибудь проблему с конфигурацией или неожиданное поведение кода, просто поморщится, вспомнит аналогичный случай из практики и быстро поправит, джуниор может зависнуть на несколько дней. Ну или начнет постоянно отрывать сеньора.

                                        0

                                        Так и не надо давать джуниору комплексные задачи. На то он и джуниор.


                                        проблему с конфигурацией или неожиданное поведение кода
                                        вспомнит аналогичный случай из практики и быстро поправит
                                        Ну или начнет постоянно отрывать сеньора

                                        Джуниор встретил неожиданное поведение кода. Спросил наставника-сеньора. Сеньор вспомнил аналогичный случай из практики, сказал джуниору как поправить, джуниор быстро поправил. Где тут необходимсть постоянно отрывать сеньора?


                                        Вам тот же вопрос. Приведите пожалуйста примеры, что конкретно вы в таком объеме рассказываете джуниорам, что это заметно влияет на работу команды?

                                          +2
                                          Где тут необходимсть постоянно отрывать сеньора

                                          Да вот же она, вы ее и описали. Такие проблемы у джуна возникают регулярно. А отрыв от работы, как мы помним — это не те полминуты, что нужны на ответ на вопрос, а гораздо больше (время на вход в поток обратно).


                                          Я просто довольно много тратил времени на объяснение им каких-то технологий, с которыми они не работали до этого (да банальный спринг-гибернейт-грейдл — все эти аннотации и конфигурации, в которых поначалу черт ногу сломит). На ревью кода и объяснение всяких косяков — в коде джуна будет гораздо больше проблем, чем в коде опытного, а объяснения требуются более подробные — чтобы он понял, почему это плохо и почему так не надо делать. На объяснения им, почему тащить все новые и хайповые технологии в проект — плохая идея и т.п. В целом я старался действительно растить из них специалистов — т.е. не просто говорить как надо, а объяснять и приводить примеры, почему именно так. На это уходит много времени.


                                          Часто джуны не видят каких-то совершенно очевидных решений. Просто потому, что многие из них по сути не умеют еще программировать. Они научились каким-то шаблонным и простым вещам, но все, выходящее за пределы — где надо хоть чуть-чуть мозг включить — поначалу ставит их в ступор.


                                          В итоге почти всегда я бы быстрее сам сделал задачу. Но нет, рассказывал и объяснял, чтобы потом они могли справляться сами. Но потом неизбежно наступал этот счастливый момент — и они сваливали в другие конторы, как я уже выше писал.

                                            –1
                                            (время на вход в поток обратно).

                                            Заметное количество времени нужно тем, кто входит в поток через кофемашину на другом этаже здания.
                                            Вы сами так или иначе будете отвлекаться. В такие моменты можно и спросить у подопечного "как успехи".


                                            Я просто довольно много тратил времени на объяснение им каких-то технологий, с которыми они не работали до этого

                                            Многословными объяснениями вы можете делать только хуже. Я довольно часто за коллегами замечал, что они могут говорить одно и то же разными словами пол часа, если их не прервать.
                                            Некоторые другие коллеги могут в своем повествовании пытаться объяснить вообще все. А это тоже бесполезно. Сначала надо объяснить как чем-то пользоваться. Как пользоваться градлом? находишь в идее панель build, тыкаешь там зеленую кнопку и оно собирается.


                                            в коде джуна будет гораздо больше проблем, чем в коде опытного

                                            Поэтому нужно уметь ограничивать свой перфекционизм, в т.ч. на ревью. Иначе вы и при ревью опытных будете скатываться в обсуждение и доделки всяких мелочей.
                                            Плюс, иногда нужно не предупреждать ошибки, а давать джунам ошибиться самостоятельно, и потом указывать на проблемы.


                                            Но нет, рассказывал и объяснял, чтобы потом они могли справляться сами.

                                            Рассказ и объяснение не вырабатывают самостоятельность. Если слишком много водить за руку, то вы скорее выучите беспомощность.
                                            Самостоятельность тренируется наводящими вопросами и побуждением к самостоятельным пробам и ошибкам.

                                              –1
                                              проблему с конфигурацией или неожиданное поведение кода
                                              Такие проблемы у джуна возникают регулярно.

                                              Если у вас на проекте регулярно возникают проблемы с конфигурацией или неожиданное поведение кода, то джуниоры тут ни при чем.
                                              Если же у джуниора регулярно возникают вопросы, не связанные с проектом, значит надо отправлять его гуглить.
                                              Если поведение стандартное для знающего специалиста, но неожиданное для джуниора, то это можно объяснить в нескольких словах и сказать что надо поискать в интернете, если нужны подробности. Таких ситуаций не должно быть много, обычно языки, фреймворки и библиотеки все-таки стараются делать более-менее понятными для программистов.
                                              У джуниора должны быть стандартные простые задачи, которые можно сделать по аналогии с существующим кодом, там просто не должно быть ситуаций, которые вызывают много вопросов.


                                              это не те полминуты, что нужны на ответ на вопрос, а гораздо больше (время на вход в поток обратно)

                                              Такая ситуация будет с любым новым человеком. У джуниора больше вопросов, да, но в моем понимании их не должно быть настолько много, чтбы наставник постоянно выходил из потока. Вот я и пытаюсь выяснить, что именно они такого спрашивают.


                                              Я просто довольно много тратил времени на объяснение им каких-то технологий, с которыми они не работали до этого
                                              В целом я старался действительно растить из них специалистов

                                              Ну так это ваше решение было, проводить обучение подробнее, чем это нужно для решения задач, джуниоры в этом не виноваты.


                                              все эти аннотации и конфигурации, в которых поначалу черт ногу сломит

                                              В плане выполнения задач, которые поручают джуниору, это сводится к "Посмотри как сделано вот тут, тебе надо сделать аналогично". Знание того, как это устроено внутри, сродни знанию ассемблера или устройства компилятора. Да, в какой-то момент это понадобится, но это будет после того, как он научится это уверенно использовать. А в идеале он сам заинтересуется и погуглит. Чтобы написать #include в коде на С++, не обязательно знать, какие процессы при этом происходят, можно просто написать и продолжить делать задачу. Нет, это не monkey-кодинг, это нормальный процесс получения опыта, нельзя узнать все сразу, значит какое-то время надо работать без знания некоторых вещей.

                                                +1
                                                значит надо отправлять его гуглить.

                                                И легко получить ситуацию, когда джун впадает в ступор на несколько дней (!). Потому что нагуглить сходу не получается, а спросить снова он стесняется чтобы не показать себя глупым. В итоге сроки продолбаны, задача не выполнена, джун демотивирован.

                                                  –1

                                                  Так надо же контролировать выполнение задачи. Если джуны сами по себе работают, и никто их не проверяет, понятно, что много времени будет уходить впустую. Просто зачем так делать.


                                                  "Отправлять гуглить" означает не сказать "ищи сам", а сказать "ищи то-то и то-то". Просто мне кажется, если джун постоянно тратит дни на изучение вопросов по языку программирования, значит он не умеет на нем программировать, и брать его не надо. А если он умеет написать код и проверить его работоспособность, значит изучение возникающих по ходу дела нюансов не будет сильно влиять на работу. Это ж то же самое, как периодически заглядывать в документацию к используемой библиотеке "а как там это делается".

                                                    0
                                                    Так надо же контролировать выполнение задачи
                                                    Ну так вот это в том числе при работе с джунами и занимает много времени. Потому что задачи приходится самому дробить, детально описывать и контролировать в мелочах.
                                                      0

                                                      Ну у вас как-то получается либо несколько дней не проверять, либо каждую мелочь контролировать. Есть же промежуточные варианты.

                                                        +1
                                                        Вы спорите ни о чём. Обсуждать степень подробности разъяснений или точную частоту проверок можно бесконечно, особенно если без привязки к конкретным людям и ситуациям.
                                                        Но бесспорно то, что разъяснения и контроль нужны и на них уходит значительное время. Чуть больше или меньше, но в любом случае много. Что тут ещё обсуждать?
                                  +1

                                  Так а я их и не виню. Понятно, что человек всегда ищет где лучше. Но этот момент и отталкивает большинство компаний от работы с джунами — и тут уж не надо винить работодателей.


                                  А платили мы вполне рыночно. Но всегда найдется кто-то, кто готов заплатить больше или у кого офис лучше, или имя более известное.

                                  0
                                  Я сам сейчас стажёр. Просто у джунов-стажёров мало возможностей и вариантов, поэтому они и идут в первую попавшуюся организацию. Их можно понять.
                                  0
                                  Думаю, для многих работодателей будет полезна статья. Автору спасибо!
                                    +1
                                    До этого я была уверена, что джуны не нужны. Никто не хочет обучать, ждать, заморачиваться. Всем нужен результат сразу — им проще заплатить нормальному специалисту и получить результат.

                                    А оказывается у джунов много преимуществ. Я задавала себе вопрос — почему не хотят взять и выучить новичка под себя? Ведь это выгодно. А оказывается не хотят обучать, потому что все рано или поздно уходят и компания снова столкнется с проблемой нехватки кадров.

                                    В целом, думаю, что все зависит от задач, которые необходимо выполнять. Если простые, джуниорские задачи нужно выполнять постоянно, то джунов можно постоянно набирать, менять и т.д. Если надежда только на рост кандидата, тогда джун не подойдет.

                                    А как показывает опыт, то компаний, где постоянно нужно выполнять простые задачи, очень мало.
                                      –1
                                      Я вообще не считаю, что людей нужно делить на джунов/не джунов. Де-факто, есть лишь один навык: доведение дел до конца. Если человек систематически не доводит дела до конца, задача обучения этому навыку выходит вообще за рамки трудовой деятельности. Но если доводит, то появляется спектр времени, как долго у разных людей займет сделать одну и ту же задачу. И тут смысл делить людей на джунов и не джунов появляется только тогда, когда спектр задач однотипный. Но когда спектр задач однотипный, появляется проблема скуки. И в работе со скукой, в сущности, есть два пути: или руководитель превращается в массовика-затейника, или в сурового надсмотрщика. И сегодня руководитель-надсмотрщик уже мало кому интересен по всяким там причинам.
                                      Поэтому, ответ на вопрос «как работать с джуниорами?» будет — «также, как и со всеми остальными, но убедившись предварительно что это правильные люди».
                                        0

                                        Ну вот главное отличие, с которым я согласен, уже озвученное выше в комментариях: миддл-синьор начинают приносить компании пользу сразу (ну почти, в курс проекта надо войти, но это обычно занимает не более нескольких дней, ну недели-две если проект сложный). Джун начнет приносить компании пользу, окупающую его зарплату, только через несколько месяцев или полгода. До этого он будет приносить проблемы и убытки в виде отрывания от работы других сотрудников.

                                          +1
                                          От многих факторов зависит. Если в проекте бардак, то даже очень крутой спец не скоро станет окупаемым.
                                            –1
                                            миддл-синьор начинают приносить компании пользу сразу

                                            Только если проект типовой. Но вообще идея делать типовой проект — крайне сомнительная сама по себе.
                                          +3

                                          Хочу обратно в джуны, чтобы ментор и посильные задачи и обратная связь, а не и вот это вот всё.

                                            +3

                                            Добавочные пункты к статье:


                                            1. Ставить дедлайны и приоритеты выполняемой задаче -> Дисциплинирует и учит оценивать свое время;
                                            2. Если джун приходит с вопросом по задаче — спрашивать, что он уже пробовал сделать для решения задачи и что из этого получилось;
                                            3. Спрашивать, как джуниор понял поставленную задачу, т.к. может быть ситуация, что вы поняли друг-друга вроде правильно, а вот не тут то было;

                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                            Самое читаемое