Комментарии 52
Я-бы добавил несколько аргументов за:
- Джуниоров можно научить тому стеку который вам нужен, а не тому который популярен
- Обратная мотивация — если ментор добровольно принял на себя эту роль — джуниор(ы) с горящими глазами будут его мотивировать
Несколько против:
- Период окупаемости — в зависимости от кривой обучения, они начинают быть выгодными позднее чем сформировавшийся сотрудник
- Не все могут и/или хотят менторить, может оказаться что вашей команде таких людей просто нет.
И о собеседованиях:
ИМХО, в джуниорах самое важное, это их мотивация (а.к.а горящие глаза) и обучаемость, проверить эти факторы по резюме практически невозможно так что, для себя, я выработал следующую методику:
Со всеми, кто подходит по формальным требованиям ( город, например ) проводится микро-интервью по скайпу/телефону, буквально на 15 минут, в течении которых здаютися вопросы "почему IT" — узнать по мотивацию и пару вопросов на умение обучаться. Вида "сложный вопрос для которого не хватает знаний" -> "выдать недостающие знания" -> "смотреть смог-ли сформулировать ответ на изначальный вопрос" — оценить способность обучаться, а дальше уже обычное собедование, если все хорошо.
Джуниоров можно научить тому стеку который вам нужен, а не тому который популярен
Встречал ситуацию, когда джуниоры в ответ на такое начинали сваливать. Мотивируя это тем, что им нужно строить карьеру, а для этого нужен востребованный на рынке стек. А засесть за что-то малопопулярное и тупиковое — это потратить зря время и проиграть в конкурентной борьбе другим.
Зачем нужны джуниорыПриведённые аргументы в целом разумны и правильны. Но есть одно серьезное «но».
Почему-то в очень многих головах сегодня понятие «джуниор» приравнивается к понятию «новичок». Очень часто с этим приходится сталкиваться. И автор доклада, кажется, тоже этим грешит.
Я видел на ютубе ролики, где девочка сразу после вайтишных курсов считала себя джуниором, а ещё через год уже крутила носом, мол, «я уровень джуниора переросла». Это что получается, годовалый вайтишник — уже мидл что ли? Но это же нонсенс.
Джуниором человек становится после 0,5-1 года реального опыта. А до того это новичок, стажер, трейни, называйте как хотите.
Нельзя забывать, что в словосочетании junior developer есть второе слово. Джуниор это пусть и младший, но разработчик — человек, который уже что-то умеет разрабатывать и обладает какой-то минимальной самостоятельностью.
Пожалуста, прекратите девальвировать термин, и многие из описанных вопросов решатся сами собой.
Я бы сделал критерием перехода от стажера к джуну прибыльность. Как только человек даёт прибыль больше, чем проедает — он джун. С важным условием: прибавляя к его з/п трудозатраты коллег, которые его менторят и, возможно, что-то доделывают за ним.
Увы, такие метрики нелегко подcчитываются и не публикуется. Но бывает, их можно приблизительно узнать в приватных разговорах с тимлидами и владельцами бизнесов.
dom1n1k Поддерживаю Ваши мысли.
Ей-богу, еще года 3 назад интернатура в "средних" компаниях вообще не практиковалась. Сейчас же, получить боевой опыт в пол года или год — проще простого. Но даже этот опыт, не позволит называть себя/кадра специалистом в области. Как правило (в моей практике есть исключения) молодые бойцы приходят с базовыми знаниями ЯП. Одного ЯП. Это прискорбно. Никто не хочет выходить из своей зоны комфорта. Кодил в универе на питоне — пойду искать интернатуру на питоне. Показывают на интернатуре плюсы — он бежит. Побежит туда, где ему комфортно. Большинство ребят идут в профессию, только потому что думают, то что здесь "сладко".
Sergey1001 Вы тоже правы, эти все звезды, это все — субъективно. Инженер должен оцениваться уровнем своей квалификации, но не как "выслугой". Ну а джуны с нулевым опытом — интерны.
Джуниором человек становится после 0,5-1 года реального опыта. А до того это новичок, стажер, трейни, называйте как хотите.
Почему-то очень многие люди выдумывают свои трактовки терминов, лишь бы был повод обосновать свое решение "мы хотим брать опытных, а опыт им пусть другие дают за свой счет". Работника надо называть стажер или трейни, если у вас на работе проводятся стажировки и тренинги, а он их участник. Если он у вас работает за зарплату на таких же условиях, как остальные разработчики, значит он junior разработчик, даже если он работает первый месяц. И да, он находится на это уровне в среднем пару лет, потом становится middle.
мы хотим брать опытныхПолгода — это не «опытный». Это просто человек, которому не нужно объяснять совсем уж элементарное, и который не обходится в несколько раз дороже своей з/п. То есть не работает в минус.
Первые полгода-год стажа — это всегда по факту оплачиваемая стажировка, даже если официально это так не называется.
Неважно, сколько у него опыта. Если он умеет написать работающую программу в соответствии с требованиями, значит он junior developer, а никакой не стажер. Любая лаба в универе это и есть написание программы в соответствии с требованиями. Само слово junior как раз и обозначает начальный уровень опыта специалиста, закончившего учебное заведение. До этого он студент.
Мне непонятно, зачем надо менять изначальный смысл слова junior и придумывать еще каких-то стажеров, которыми оказываются 100% выпускников, и которые при этом не участвуют ни в какой стажировке.
Первые полгода-год стажа — это всегда по факту оплачиваемая стажировка
Первые полгода-год стажа — это работа junior разработчика. Само слово junior подразумевает, что у него меньше опыта, чем у среднего специалиста, и чтобы дойти до уровня среднего специалиста, он должен его получить. Что он и делает эти полгода-год.
То есть не работает в минус.
Если у вас сотрудник работает в минус, значит вы можете уволить его совершенно без вреда для проекта. Если же это не так, значит вы неправильно конвертируете приносимую сотрудником пользу в деньги.
Если у вас джуны приносят прибыль с места возможны 3 варианта.
- Вы и ваша компания научилась сверхбыстро адаптировать джунов так, чтобы они быстро и хорошо решали задачи. Тогда ваша компания должна быть лидером рынка и зарабатывать много денег.
- Вы даете джунам самые простые задачи и таких задач у вас много. Тогда вы занимаетесь чем то не особо сложным.
- Вы не считаете косвенные затраты на работу джуна. Тогда наверное получается что на регулярах и сеньорах вы получаете прибыль меньше.
Есть ещё один вариант — вы лукавите) Но я даже боюсь представить, зачем это вам может быть нужно.
Горящие глаза могут быть по другой причине, а если и по этой, то не значит, что они не загорятся уже завтра на другое.
Побуду адвокатом дьявола.
Зачем брать джуниора и иметь все эти проблемы, если можно взять миддла с заниженной самооценкой, нагружать его как миддла и платить как джуниору?
Главная проблема джуниоров в том, что они сваливают. Поработают годик у вас, наберутся опыта, потратят вам кучу нервов и ресурсов на исправление косяков, поднимут свою стоимость на рынке труда, а потом бац — и упорхнут куда-нибудь на условия получше.
И да, если вы не гугл-яндекс, то всегда найдется кто-то, кто даст условия лучше. Небольшие компании весьма ограничены в ресурсах и не могут джуниорам давать супер-зарплаты (да и какой смысл, если джуниор не будет эту зарплату отрабатывать?), а офис какого-нибудь ИП Пупкин всегда будет хуже, чем офис крупной конторы. Плюс у джуниоров часто есть желание попробовать себя в большой и известной конторе, вкусить прелести кровавого энтерпрайза, попробовать поработать "по-взрослому".
Причем вероятно, что через несколько лет такие люди уже будут выть от этого энтерпрайза, так как ничего хорошего в нем, как правило, нет. Но для начала им все-таки хочется попробовать и убедиться в этом на своем опыте.
В итоге джуниор — это большие издержки и инвестиции, и при этом большой риск того, что они никогда не окупятся и весь профит достанется кому-то другому.
Я достаточно поработал со студентами (так как работаю в универе в лаборатории, делающей всякие урбанистично-айтишные штуки на заказ), и решил что все, хватит. Теперь только люди с опытом, уже понявшие чего они хотят от работы и карьеры.
Так что джуниоры — они хороши для крупных контор (где есть ресурсы, менторы и возможность дать суперпривлекательные условия), а не для мелких-средних.
Это все же проблема не джунов, а компаний, которые их нанимают. Потому что сначала зовут вчерашних студентов, на собеседовании рассказывают про то, как они «предпочитают выращивать своих специалистов, а не брать со стороны», а потом через полгода-год выясняется, что ты как-то слишком сильно вырос, а ни новых задач, ни повышенной (хотя бы на уровне чуть-меньше-рынка) оплаты тебе не полагается. И вот что в такой ситуации предлагаете делать?
Винить людей в том, что они хотят работать и получать за это достойную оплату — контрпродуктивно.
а потом через полгода-год выясняется, что ты как-то слишком сильно выросЯ не знаю вас лично, может быть вы исключение, которые действительно иногда случаются.
Но в большинстве случаев в реальности эта фраза означала бы что-то типа: «наконец-то перестал жечь тоннами время ментора, теперь ему можно хоть что-то поручить и начать, наконец, окупать инвестиции нескольких месяцев».
Проблема в том, что первые несколько месяцев новичок мало того, что не окупает даже собственную зарплату, но в реальности обходится в несколько раз дороже её, поскольку прямо и косвенно тратит время коллег.
Но по-честному сказать «а давай мы тебе сейчас дадим чисто символическую стипендию, а потом 2-3 раза хорошо повысим с интервалами в полгода» не получается — никто не пойдет на такие условия, у всех самомнение, все хотят «достойную оплату».
потом 2-3 раза хорошо повысимменя вполне бы устроил. Но этого не произошло. Потому что брали не джуна на вырост, а человека, который задешево сможет закрывать несложные таски. Собственно, почти весь отдел из таких и состоял, и все примерно в одно время всё поняли и с интервалом в два-три месяца ушли.
В этом я и вижу главную проблему — иногда компаниям не нужен рост сотрудника, им нужен вечный вчерашний студент, готовый работать за миску супа. Но ищут, почему-то, джуна на вырост.
Опять же, я понимаю, что единственный личный пример — далеко не показатель, и, быть может, это мне так не повезло. К сожалению, второй раз я джуном уже стать не смогу
вариант с «потом 2-3 раза хорошо повысим» меня вполне бы устроил.Вы пропустили первую часть фразы про символическую стипендию, а она там ключевая. Покажу на примере (всё очень утрированно, цифры условны):
Приходит студент, ему дают 500 баксов. Первые полгода он приносит пользы на -500 баксов (то есть фактически ему платят как бы 1000), вторые полгода идут примерно в ноль, после года он наконец выходит в стабильный плюс. Именно в этот момент джун обижается, что его не ценят и уходит.
Мой гипотетический вариант такой: дорогой студент, давай на старте мы дадим тебе 100 (чисто чтобы тебе хватало на проезд и перекус), через полгода сделаем 400, ещё через полгода 700, еще через полгода 1000.
Что это могло бы дать? Более честные отношения. Новичок не получает денег, которых он не стоит и более адекватно оценивает свой прогресс. Компания несет меньшие риски.
Но как мы понимаем, в реальной жизни так не бывает. Новичок хочет з/п с самого начала. А компания вынуждена рисковать, что эти инвестиции не окупятся никогда (и частенько так и происходит). Что делать в такой ситуации? Я не знаю, жизнь сложная штука. :)
Естественно будут люди, которые скажут «да я вообще без зп пол года работал». Видимо на старте у них была отличная помощь финансовая, а не только их огромное желание.
В итоге имеем то что имеем: новичок насколько месяцев живет не на зарплату, а на субсидию. Но не понимает этого (или не хочет понимать) и обижается что его не ценят, ведь он же вырос! А фактически — наконец дорос до той з/п, которую ему дали изначально.
Кстати, это похоже на проблему с декретами (а точнее, с советским трудовым законодательством) — при всем уважении к материнству, почему частный работодатель должен оплачивать чьего-то ребенка? Пусть муж оплачивает.
почему частный работодатель должен оплачивать чьего-то ребенка?
Так вроде отпуск по уходу за ребенком оплачивается из ОМС. Поправьте меня, если не так.
100 долларов может не хватить.
Проблема в том, что первые несколько месяцев новичок мало того, что не окупает даже собственную зарплату, но в реальности обходится в несколько раз дороже её, поскольку прямо и косвенно тратит время коллег.
Приведите пожалуйста пару примеров, что вы под этим подразумеваете?
Но даже после нескольких итераций исправлений, как правило, результат всё равно оказывается ниже качеством, чем если бы его изначально делал опытный исполнитель. Это даёт отложенный эффект — больше работы тестировщикам, менеджерам, поддержке и так далее.
Это все справедливо для любого нового человека на проекте, даже если он senior. Потому что новый сотрудник не знает ваш проект. Серьезно, что вы такого рассказываете джуниорам, что не связано с проектом, да еще в таком количестве? И почему некачественный код проходит код-ревью и попадает на тестирование и в продакшн?
Я вот например до первой работы не знал, как пользоваться системой контроля версий. Тимлид один раз показал как коммитить и пару раз как разрешать конфликты. Такие вещи не должны занимать много времени.
Нет, сеньору можно дать задачу в общих чертах и он сам разберется.
Джуниору нужно буквально тыкать во все подряд. Сам он НЕ разберется. Ну или будет делать это оооочень долго.
Джуниор не способен решать комплексные задачи, часто говнокодит, изобретает велосипеды и просто зависает на каких-то казалось бы элементарных вещах (но которым в вузике не учили). Джуниор еще не знает тысячи и одной проблем инструментов своих. Там где сеньор, встретив какую-нибудь проблему с конфигурацией или неожиданное поведение кода, просто поморщится, вспомнит аналогичный случай из практики и быстро поправит, джуниор может зависнуть на несколько дней. Ну или начнет постоянно отрывать сеньора.
Так и не надо давать джуниору комплексные задачи. На то он и джуниор.
проблему с конфигурацией или неожиданное поведение кода
вспомнит аналогичный случай из практики и быстро поправит
Ну или начнет постоянно отрывать сеньора
Джуниор встретил неожиданное поведение кода. Спросил наставника-сеньора. Сеньор вспомнил аналогичный случай из практики, сказал джуниору как поправить, джуниор быстро поправил. Где тут необходимсть постоянно отрывать сеньора?
Вам тот же вопрос. Приведите пожалуйста примеры, что конкретно вы в таком объеме рассказываете джуниорам, что это заметно влияет на работу команды?
Где тут необходимсть постоянно отрывать сеньора
Да вот же она, вы ее и описали. Такие проблемы у джуна возникают регулярно. А отрыв от работы, как мы помним — это не те полминуты, что нужны на ответ на вопрос, а гораздо больше (время на вход в поток обратно).
Я просто довольно много тратил времени на объяснение им каких-то технологий, с которыми они не работали до этого (да банальный спринг-гибернейт-грейдл — все эти аннотации и конфигурации, в которых поначалу черт ногу сломит). На ревью кода и объяснение всяких косяков — в коде джуна будет гораздо больше проблем, чем в коде опытного, а объяснения требуются более подробные — чтобы он понял, почему это плохо и почему так не надо делать. На объяснения им, почему тащить все новые и хайповые технологии в проект — плохая идея и т.п. В целом я старался действительно растить из них специалистов — т.е. не просто говорить как надо, а объяснять и приводить примеры, почему именно так. На это уходит много времени.
Часто джуны не видят каких-то совершенно очевидных решений. Просто потому, что многие из них по сути не умеют еще программировать. Они научились каким-то шаблонным и простым вещам, но все, выходящее за пределы — где надо хоть чуть-чуть мозг включить — поначалу ставит их в ступор.
В итоге почти всегда я бы быстрее сам сделал задачу. Но нет, рассказывал и объяснял, чтобы потом они могли справляться сами. Но потом неизбежно наступал этот счастливый момент — и они сваливали в другие конторы, как я уже выше писал.
(время на вход в поток обратно).
Заметное количество времени нужно тем, кто входит в поток через кофемашину на другом этаже здания.
Вы сами так или иначе будете отвлекаться. В такие моменты можно и спросить у подопечного "как успехи".
Я просто довольно много тратил времени на объяснение им каких-то технологий, с которыми они не работали до этого
Многословными объяснениями вы можете делать только хуже. Я довольно часто за коллегами замечал, что они могут говорить одно и то же разными словами пол часа, если их не прервать.
Некоторые другие коллеги могут в своем повествовании пытаться объяснить вообще все. А это тоже бесполезно. Сначала надо объяснить как чем-то пользоваться. Как пользоваться градлом? находишь в идее панель build, тыкаешь там зеленую кнопку и оно собирается.
в коде джуна будет гораздо больше проблем, чем в коде опытного
Поэтому нужно уметь ограничивать свой перфекционизм, в т.ч. на ревью. Иначе вы и при ревью опытных будете скатываться в обсуждение и доделки всяких мелочей.
Плюс, иногда нужно не предупреждать ошибки, а давать джунам ошибиться самостоятельно, и потом указывать на проблемы.
Но нет, рассказывал и объяснял, чтобы потом они могли справляться сами.
Рассказ и объяснение не вырабатывают самостоятельность. Если слишком много водить за руку, то вы скорее выучите беспомощность.
Самостоятельность тренируется наводящими вопросами и побуждением к самостоятельным пробам и ошибкам.
проблему с конфигурацией или неожиданное поведение кода
Такие проблемы у джуна возникают регулярно.
Если у вас на проекте регулярно возникают проблемы с конфигурацией или неожиданное поведение кода, то джуниоры тут ни при чем.
Если же у джуниора регулярно возникают вопросы, не связанные с проектом, значит надо отправлять его гуглить.
Если поведение стандартное для знающего специалиста, но неожиданное для джуниора, то это можно объяснить в нескольких словах и сказать что надо поискать в интернете, если нужны подробности. Таких ситуаций не должно быть много, обычно языки, фреймворки и библиотеки все-таки стараются делать более-менее понятными для программистов.
У джуниора должны быть стандартные простые задачи, которые можно сделать по аналогии с существующим кодом, там просто не должно быть ситуаций, которые вызывают много вопросов.
это не те полминуты, что нужны на ответ на вопрос, а гораздо больше (время на вход в поток обратно)
Такая ситуация будет с любым новым человеком. У джуниора больше вопросов, да, но в моем понимании их не должно быть настолько много, чтбы наставник постоянно выходил из потока. Вот я и пытаюсь выяснить, что именно они такого спрашивают.
Я просто довольно много тратил времени на объяснение им каких-то технологий, с которыми они не работали до этого
В целом я старался действительно растить из них специалистов
Ну так это ваше решение было, проводить обучение подробнее, чем это нужно для решения задач, джуниоры в этом не виноваты.
все эти аннотации и конфигурации, в которых поначалу черт ногу сломит
В плане выполнения задач, которые поручают джуниору, это сводится к "Посмотри как сделано вот тут, тебе надо сделать аналогично". Знание того, как это устроено внутри, сродни знанию ассемблера или устройства компилятора. Да, в какой-то момент это понадобится, но это будет после того, как он научится это уверенно использовать. А в идеале он сам заинтересуется и погуглит. Чтобы написать #include в коде на С++, не обязательно знать, какие процессы при этом происходят, можно просто написать и продолжить делать задачу. Нет, это не monkey-кодинг, это нормальный процесс получения опыта, нельзя узнать все сразу, значит какое-то время надо работать без знания некоторых вещей.
значит надо отправлять его гуглить.
И легко получить ситуацию, когда джун впадает в ступор на несколько дней (!). Потому что нагуглить сходу не получается, а спросить снова он стесняется чтобы не показать себя глупым. В итоге сроки продолбаны, задача не выполнена, джун демотивирован.
Так надо же контролировать выполнение задачи. Если джуны сами по себе работают, и никто их не проверяет, понятно, что много времени будет уходить впустую. Просто зачем так делать.
"Отправлять гуглить" означает не сказать "ищи сам", а сказать "ищи то-то и то-то". Просто мне кажется, если джун постоянно тратит дни на изучение вопросов по языку программирования, значит он не умеет на нем программировать, и брать его не надо. А если он умеет написать код и проверить его работоспособность, значит изучение возникающих по ходу дела нюансов не будет сильно влиять на работу. Это ж то же самое, как периодически заглядывать в документацию к используемой библиотеке "а как там это делается".
Так надо же контролировать выполнение задачи
Ну так вот это в том числе при работе с джунами и занимает много времени. Потому что задачи приходится самому дробить, детально описывать и контролировать в мелочах.
Ну у вас как-то получается либо несколько дней не проверять, либо каждую мелочь контролировать. Есть же промежуточные варианты.
Но бесспорно то, что разъяснения и контроль нужны и на них уходит значительное время. Чуть больше или меньше, но в любом случае много. Что тут ещё обсуждать?
Так а я их и не виню. Понятно, что человек всегда ищет где лучше. Но этот момент и отталкивает большинство компаний от работы с джунами — и тут уж не надо винить работодателей.
А платили мы вполне рыночно. Но всегда найдется кто-то, кто готов заплатить больше или у кого офис лучше, или имя более известное.
А оказывается у джунов много преимуществ. Я задавала себе вопрос — почему не хотят взять и выучить новичка под себя? Ведь это выгодно. А оказывается не хотят обучать, потому что все рано или поздно уходят и компания снова столкнется с проблемой нехватки кадров.
В целом, думаю, что все зависит от задач, которые необходимо выполнять. Если простые, джуниорские задачи нужно выполнять постоянно, то джунов можно постоянно набирать, менять и т.д. Если надежда только на рост кандидата, тогда джун не подойдет.
А как показывает опыт, то компаний, где постоянно нужно выполнять простые задачи, очень мало.
Поэтому, ответ на вопрос «как работать с джуниорами?» будет — «также, как и со всеми остальными, но убедившись предварительно что это правильные люди».
Ну вот главное отличие, с которым я согласен, уже озвученное выше в комментариях: миддл-синьор начинают приносить компании пользу сразу (ну почти, в курс проекта надо войти, но это обычно занимает не более нескольких дней, ну недели-две если проект сложный). Джун начнет приносить компании пользу, окупающую его зарплату, только через несколько месяцев или полгода. До этого он будет приносить проблемы и убытки в виде отрывания от работы других сотрудников.
Хочу обратно в джуны, чтобы ментор и посильные задачи и обратная связь, а не и вот это вот всё.
Добавочные пункты к статье:
- Ставить дедлайны и приоритеты выполняемой задаче -> Дисциплинирует и учит оценивать свое время;
- Если джун приходит с вопросом по задаче — спрашивать, что он уже пробовал сделать для решения задачи и что из этого получилось;
- Спрашивать, как джуниор понял поставленную задачу, т.к. может быть ситуация, что вы поняли друг-друга вроде правильно, а вот не тут то было;
Использовать многоуровневую архитектуру;
Обеспечить расширяемость решения;
Использовать паттерны проектирования;
Использовать юнит-тесты;
Логирование системных ошибок;
Сохранять результат подсчета частоты нахождения слов на странице в базу данных.
Вопрос — где найти компанию, где предлагают в качестве тестового сверстать кнопку?)
ps задание с грехом пополам сделал, но не приняли :)
Как работать с джуниорами?