Comments 201
а что мешает получать опыт на пет-проектах? приходящий начинающий писатель который ничего не написал, смотрится в бизнесе странновато
Не pet проектах хорошо набивать руку когда есть уже опыт работы, например хочу я разобраться с Dart/Java/Go, но у меня уже есть опыт в .Net, поэтому в свободное от работы время, я могу поковырять ту или иную технологию\язык.
В статье я затрагиваю тему людей без опыта, для них порог вхождения будет намного выше чем для опытного разработчика, про временные затраты я вообще молчу. Плюс откуда человек знает что сейчас модно-стильно-молодёжно в продакшене? Что начать изучать, как начать? В универах толковых преподавателей (с неустаревшим продакшен опытом) не так уж и много, поэтому выбрать свою стезю - зачастую дело фортуны. А если человек не из ИТ вуза?
Плюс цель статьи - дать понять другим менеджерам, что найм людей без опыта - это не ой-ой-ой, страшна, а вполне себе обыденность, которую делают другие.
да вроде чтобы узнать что "модно-стильно-молодежно", достаточно просто посмотреть список требований в вакансиях на любом работном сайте, понятно что для человека без опыта будет вход выше чем для того кто с опытом, но потому и надо выделиться на фоне остальных "без опыта", а если он приходит "вы мне заплатите, научите и тогда может быть я начну работать", это надо иметь очень большой бизнес и очень много много (!) лишних денег чтобы перебором просевать такой материал
p.s.
на тему трудоустройства, еще старая история еще в советской технике молодежи вспоминается часто, даже специально картинку вырезал
Я бы тоже такого умельца нанял, т.к. большой любитель инвестировать в людей. Но, к сожалению, иногда не смотрят на потенциал, а лишь на опыт, т.к. потенциал надо развить, а бабло надо зарабатывать сейчас, срочно и быстрее-быстрее. Капитализм, однако.
как то на одном медицинском форуме где обсуждались поборы, спрашивал людей представляющихся врачами - "а что будет если больной откажется платить?", один из них сказал - "тогда заведующий отделением запишет такого больного в маленькую черную книжечку и его будут отдавать новичкам", чем то имхо совпадает с ИТ - если есть деньги, то врядли захочешь чтобы проблему решали люди без опыта, а то украсишь их кладбище
Список требований != с чем будет работать.
К тому же каждое отдельное требование для новичка вполне может оказаться равно году изучения технологии или больше.
но тогда получается что этот год его будет за свои деньги обучать наниматель, а если у нанимателя есть выбор не тратить столько денег и времени, то приходим к логическому заключению что если есть возможность, то он не будет их тратить
с обучением у работодателя возникнут риски, что человек получив запись о "практике" и "обучении" в резюме, уйдет на 10-15% больше денег к другому работодателю, который просто воспользуется полученным продуктом и получается первый работодатель будет работать на второго, а учить за свои чтобы в конце поднять денег за то что сам научил, в чем выгода?
Также не факт, что у новичка нет другой другой работы(жить тоже на что-то надо, пока учишься). Вот и сравниваем несколько несчастных часов вечером за вычеьлм времени в пути на работу и обратно и полноценный рабочий день в течении ты можешь выучить гораздо больше.
+100!
каждое отдельное требование для новичка вполне может оказаться равно году изучения технологии или больше
Ну прям, год! Современный джун это !jun.equals(valueOf("zerro")). (наПримереJava) он неплохо знает Core, включая Concurrency и Reflection, освоил начала БД до степени постых JOIN, и в Spring уже потыкался. Да и вообще, если чел осилил курсы Java-developer (а это в среднем год пахать) значит он уже мотивирован и обучаем.
Так что никакой не год. Через 2-3 недели интенсива с хорошим наставником и наш джун уже худо-бедно говнокодит (принцип "делай как я") на искомой технологии, а через месяц-полтора за ним уже надо проверять не больше чем за мидлами.
КМК человек имел ввиду год - если без ментора\наставника, поэтому в вашем примере с ментором-то оно быстрее будет. Бесспорно.
Тут надо смотреть что автор понимает под "технология". Если это "вэб-разработка", то тут и всей жизни может не хватить чтобы освоить всё-всё что входит в это название.
А если взять отдельно стоящий Hibernate, например, то лично я (самодельный джун из палаты мер и весов с курсов) уже через несколько дней изучения начал писать библиотечку для себя. И со второго раза (по мере изучения переписывал) написал вполне работающий экземпляр. Конечно, на тот момент я уже знал кое-что по базам данных, умел писать запросы и сравнивал свои "ручные" результаты с теми что мне выдавал Hibernate.
Но и БД я изучал не год, а пару-тройку месяцев (параллельно с Java). Конечно, я не знаю большей части возможностей Habernate. Но и неправильно говорить что меня надо год учить, а до того толку от меня нет. Есть толк! Есть вполне рабочий код. И да, с хорошим наставником он наверняка был бы лучше :)
Ну, тут просто могут быть разные взгляды на вещи. Я вот прямо сейчас наблюдаю разницу между вхождением в проект синьора, и вхождением туда же миддла пару лет назад. Толк есть от обоих. И приносить пользу оба начинают примерно через одинаковое время. Только усилий по их сопровождению требуется сильно разное количество. Упрощенно, если синьору без опыта в проекте можно поставить задачу на высоком уровне, и он автономно принесет результат через неделю, который нужно будет слегка подпилить напильничком там и сям, то миддл будет приставать каждый день, а результат не будет учитывать что-то достаточно важное (что синьор при этом не упустит, и о чем спросит сам).
>Есть вполне рабочий код.
Ну и в этом случае вопрос обычно в том, как легко это будет потом сопровождать. И как рабочий код реагирует на ошибки, например. Опять же, условный пример — если джун просто напишет i= Integer.valueOf(string), то синьор сразу напишет обработку ошибки. И эта ошибка таки вылезет рано или поздно в эксплуатации. Т.е. разница между ними — в подходе к ситуациям за пределами happy path (который и у джуна обычно достаточно рабочий), к обработке нестандартных ситуаций.
разницу между вхождением в проект синьора, и ... миддла
Я и не собираюсь спорить с тем что от более опытного человека на проекте больше пользы чем от менее опытного. Я возражаю против мысли "год учить и только потом будет толк". Нет, толк наступит раньше и будет нарастать пааастэпэнна :)
если джун просто напишет i= Integer.valueOf(string), то синьор сразу напишет обработку ошибки
Писать обработку ошибок учат на всех курсах, кроме, возможно самых чепушильных (я таких не встречал). И проверять входные параметры в методах. И как это сделать наиболее компактным способом (прописать контракт, сделать блок try-catch). И даже написать условие так:
if ("abc".equals(someString) {...}
а не наоборот, что позволит избежать NPE во многих случаях. Другое дело что в учебных задачах на это забивают (а если нет, то в обсуждении вой и слёзы: валидатор совсем охренел, у меня на компе всё работатет!!!1). Но я на каком-то тестовом так делал и проверяющему прям понравилось :)
Если это частая проблема, то этому стоит уделить внимание на собесе, типа: давай запишем условие... ага, а что тут может пойти не так?... а как можно улучшить?
Так я такого и не говорил, если вы еще раз перечитаете именно мой коммент.
>Писать обработку ошибок учат на всех курсах
Ну вот факт налицо — вроде и учат, а в тоже время, заметное отличие синьора от джуна в реальной жизни часто выражается именно в этом. Если вы этот этап прошли — вы вероятно уже в какой-то степени опытный.
>if («abc».equals(someString) {...}
Ну вот я на автомате всегда пишу так. Но не замечал, чтобы так делали многие. Наоборот, многие предупреждения идеи игнорируют, в то время как там бывает много полезного.
На курсах он пахал с нуля или почти с нуля. И кандидатом в джуны он стал только ближе к их окончанию. В начале "карьеры" он бы даже не рассматривался в качестве потенциального сотрудника. В комментарии речь идёт обучении неким "технологиям" и вряд ли это цикл FOR или даже коллекции. Предполагается что человек это умеет (ЯТД).
Современный джун ... неплохо знает Core, включая Concurrency и Reflection, освоил начала БД до степени постых JOIN, и в Spring уже потыкался.
... осилил курсы Java-developer (а это в среднем год пахать)
Ну так и возьмем за пример ровно рабочий год, т.е. 12 месяцев по 160 часов.
Ну для работника всё-таки есть отпуск, поэтому для работника рабочий год - это всего 11 месяцев, ну да ладно. Для работника ещё есть идеальный рабочий день, который никак не 8 рабочих часов, а где-то 7-6, причем 7 в лучшем случае, если всё в компании проходит без сильного отвлечения от рабочего процесса. А то бывает и 5 именно рабочих часов в день - в зависимости от бюрократии компании, ну да и это тоже ладно.
Хотя получается, что по длительности рабочего дня месяц работы сотрудника - это всего (возьмем 6 часов в день как довольно реалистичный вариант) 120 часов. А с учетом отпуска - 110 рабочих часов. Ну это просто чтобы можно было сравнить исходные 160 часов и реальные 110. Вероятно, наш студент не занимается бестолковой перепиской с заказчиком, но и эффективно работать мозгами он все 8 часов в день не сможет, так что исходные 160 часов превратить в реальные 160 часов у него не получится.
Итак, новичок решил изучать Java на курсах прямо с нуля - переменная, простейшие конструкции, цикл и т.д. Попробую оценить, сколько времени он потратит на изучение каждой темы.
1 месяц - Простейшие операции
2 месяца (итого 3) - несложные задачи с применением ООП
1 месяц (итого 4) - коллекции + стримы
1 месяц - базы данных, операции выборки и обновления, DML с минимумом DDL, никакой нормализации
1-2 месяца (итого 6-7) - spring с базами данных
1 месяц - потыкаться в IDE + git + maven / gradle (минимум месяц! вполне возможно, что 2, а при возникновении проблем без наставника и 3 месяца потратит)
ИТОГО уже потрачено 8 месяцев
По паре месяцев возьму на Concurrency и Reflection, вот все 12 месяцев и исчерпаны.
На Reflection можно взять 0.5-1 месяца, если студент решит, что это ему не надо. Но тогда в ответку этот же месяц легко улетит на практику с junit / testng. Короче говоря, эти 12 месяцев - впритык, если нигде не тормознет и не застрянет. Застрять без наставника довольно легко.
Попробуйте теперь представить, что конкретно из коллекций он неплохо помнит, а что помнит только на уровне проходили, кажется. И что он вообще не вспомнит, даже если проходили. Аналогично попробуйте оценить его знания в Concurrency и ответить на вопрос - он действительно
неплохо знает ... Concurrency и Reflection
или все равно максимум - максимум happy path сделает нормально, а в целом именно что повторит "делай как я". А чуть в сторону от уже известных задач - и новую тему заново надо объяснять, у вас не так?
через месяц-полтора за ним уже надо проверять не больше чем за мидлами.
не больше чем за мидлами - ну да, здорово, толковые вам джуны попадают.
главное что можно собрать информацию по требованиями к стеку с десятка компаний и вычленив наиболее востребованное, подготовиться до уровня "когда пригласят на собеседование", что увеличит шансы на найм
Не трогайте джангу(/фласк/fastapi) Ее как в микросервисах так и монолитом можно использовать. Если возникнет проблема, то точно дело не в ней, а в общей архитектуре / бизнес логике.
Во фронтовых делах не силен, но думаю реакт(/вью/ануляр) туда же - это же просто либа. Если разраб её лучше знает/умеет чем jquery, то преступления точно не будет. Да и быстрее получится.
Единственный кейс, который на вашей стороне это сайт-визитка, которая на gitpage влезет (хотя и там react прикрутить можно).
На самом деле я просто не могу принять теорию необходимости того или иного инструмента в проекте (кроме явных перегибов типа хадупа и оракла в пет-проектах). В самом простом вопросе - что использовать: монгу или постгрес - каждый пытается навязать свое любимое, хотя полноценно использовать можно любой из них в любых проектах.
.
Лучшие и самые толковые преподаватели в Универе отличались еще и некоторой узконаправленностью. Человек много лет вспахивает какую-то борозду. Она ему интересно, у него в ней огромный опыт, в нише вспахивания этой борозды у него нет конкурентов, он выпускает топовые работы и это ласкает его ЧСВ.
И каким бы он мега толковым не был, широкая картина мира у него может просто отсутствовать. Потому что не нужна она ему.
Студент же, имея такого толкого преподавателя максимум что сможет через его руку куда-то попасть. Но такой преподаватель не расскажет, что важно или что не важно. Он немножко ученый, он не знает, как мир устроен дальше того, что он сам делает.
Но ровно поэтому вовлечениние студентов в работу должны заниматься не конкретные преподаватели, а выстроенный процесс контакта вуза с производтсвом.
А что значит - а если он не из it вуза?
Я имею ввиду то, что те кто не оттуда составляют очень слабую конкуренцию тем кто оттуда.
Их и так много и именно они 5лет учились и ежедневно делали что-то, либо кодили либо изучали академическую теорию. На 3-4 курсе уже многие из ни работают официально. У остальных есть законченный дипломная работа и несколько курсовых проектов. Каждый год выпускаются сотни новых.
Неужели они все исчезают как вода в песке и нужно искать на стороне?
Я учился в профильном вузе. У нас до финиша дошло только 50% численности людей начавших обучение: кто-то понял что ИТ не для него и подался в повара, кто-то ушёл работать грузчиком на рынок, один правда сделал свою компанию, но последний случай единичный.
И такая статистика держится из года в год.
Рынок растёт каждый год где-то на 30-40%. Да и регион у нас - 80% аутсорс, поэтому да, нужно постоянно искать.
А что если чувак учиться под крылом ментора (код ревью, советы, задании и т.д.) например на бекэнд 4 года паралельно с универом? Будет университетский бэкграунд + те самые пет проекты с ментором на гитхабе. Учитывая то что чувак уже до начала универской умеет писать проекты (писать, настраивать пайплайн, деплоить) и знает определенный стэк технологии.
P.S. этот чувак я
В пет проект нет ни взаимодействия с командой, ни жестких дедлайной, ни код ревью, ни приоритетов и требований от бизнеса и т.п.
То есть, научится как-то писать код можно, но это лишь очень небольшая часть работы программиста.
ИМХО, часто лучше взять хорошего командного игрока, хорошо умеющего работать с запросами клиентов, соблюдать сроки, умеющего писать понятный код и т.д., чем в разы более производительного (знающего технологии), но который вообще не умеет работать с людьми, код совершенно нечитаемый, постоянно со всеми спорит, не соблюдает никаких сроков и т.д.
нанимают ведь не команду, нанимают разработчика и по пет-проекту видно что он умеет, это сразу много больше и выгоднее чем брать "кота в мешке", помню как студент один работу искал в игровой индустрии, он ходил и показывал демку которую дома сделал и она даже какое то место на одном из конкурсов заняла, он был нарасхват
ИМХО, часто лучше взять хорошего командного игрока, хорошо умеющего работать с запросами клиентов, соблюдать сроки, умеющего писать понятный код
если разработчик приходит "голенький" на собеседование, то соответствие приведенным списком требованиям вообще только опытным путем можно будет за свои деньги выяснить
то соответствие приведенным списком требованиям вообще только опытным путем можно будет за свои деньги выяснить
Не совсем, обычная беседа позволяет выяснить очень многое. Небольшое тестовое задание может показать насколько человек умеет в понятный код. Скажем, любая другая работе (даже чернорабочим на стройке или эникейщиков), тоже многое может сказать о человеке (особенно, если попросить его рассказать о начальнике/коллегах).
Я не спорю, с пет проектов лучше, чем без него, но это не главный критерий. Общая адекватность и умение учится намного важнее.
Ну вы немножко преувеличиваете масштабы проблемы.
Пет проект можно делать и не в одиночку, а с командой единомышленников. Там и взаимодействие и со сроками команда будет подгонять.
А если человек со всеми спорит, не соблюдает договоренностей, то это просто характер такой и от опыта не зависит.
Проходил мимо, просто зацепился взглядом:
То есть, научится как-то писать код можно, но это лишь очень небольшая часть работы программиста.
В корне не согласен. Да, нам последние 5 лет промывают мозг важностью софтскиллов, приводя жуткие примеры в виде безумных гениев, которые хорошо знают паттерны и архитектуру, но мямлят исключительно матюгами и оскорблениями.
Но, как правило это не так, и обычный среднестатистический человек без проблем освоит и взаимодействие с командой и дедлайны, и ревью с приоритетами. В то время как хорошо написать расширяемый компонент уже требует специфического опыта, который можно получить в том числе и на пет проекте.
ИМХО, часто лучше взять хорошего командного игрока, хорошо умеющего работать с запросами клиентов, соблюдать сроки, умеющего писать понятный код и т.д., чем в разы более производительного (знающего технологии), но который вообще не умеет работать с людьми, код совершенно нечитаемый, постоянно со всеми спорит, не соблюдает никаких сроков и т.д.
Ага, вот именно, если бросаться в крайности — согласен. Конечно общительный чел лучше хиккана. Только непонятно почему вы "умеющего писать понятный код" занесли в софтскиллы, пет проекты очень помогают развитию понятного кода, особенно когда не "написал и забыл", а через года этак три разбираешь свое же.
ну так вот, если взять без крайностей, речь идет о выборе между человеком который лучше кодит, чем общается, но при этом опрятен, вежлив и приятен в общении или же проактивным супер-инициативным, но неважно кодящим сотрудником, то возникает вопрос- вы точно программиста ищете?
Читал комментарии и хотел ровно то же самое написать, пока не увидел ваш комментарий :)
Тоже не понимаю почему надо противопоставлять хард и софт скиллы.
Мне кажется, наоборот - если человек пишет красивый код, то и одеваться может опрятно, и общаться, и вообще в жизни порядок вероятнее.
Экзотические экземпляры паноптикума IT - это какая-то мифология, как бухгалтеры из анекдотов.
почему надо противопоставлять хард и софт скиллы.
Для начала, софт скиллы очень размытое понятие, одни понимают под этим душу компании, который квасит со всеми каждый вечер, другие просто адекватного человека.
Я бы говорил не о софт скилах, а умение работать в команде, понимать требования заказчика, адекватно общаться с тестировщиками, клиентами, коллегами, ответственность и т.д. Черт с ним, как человек одет и что сидить у себя в уголке, не с кем не обшаясь кроме работу, не это основное для работы в команде…
Экзотические экземпляры паноптикума IT — это какая-то мифология
Полбеды если человек интроверт и общается коротко и по делу или носит кильт с майкой-алкоголичкой на работу. С этим вполне можно работать адекватному тим лиду.
Хуже, если он не отвественный, не принимающий критику, фанатик каких-нибудь технологий, упрямый или считающий себя самым умным или хитрым, либо просто слишком ленивый.
Увы, по своему опыту обучения начинающих, я бы сказал, что среди тех кто вообще в первый раз в жизни работает — адекватных от силы половины.
Это сложно понять тем кто давно работает. Банально приходить на офис в указанное время и уходить не раньше чем через 8 часов — для бывшего студента/школьника, привыкшего забивать на пары, не то чтобы подвиг, но что-то героическое в этом есть. (с)
умение работать в команде, понимать требования заказчика, адекватно общаться с тестировщиками, клиентами, коллегами, ответственность и т.д.
Это вообще-то и есть soft skills. Скилы работы с другими людьми.
1. Софт скилс продажника — умение продать что угодно, делать презентации, войти в доверие, работать с клиентами/боссами, быть душой любой компании и т.п.
2. Скилы командного игрока — тут человек может быть и закомплесованным, зажатым, но при этом адекватно общается (по делу с другими ИТшниками) — хотя в почте/мессанджерах, понимает требования заказчика и может объяснить свои идеи, написать понятную документацию, способен принимать критику и менять свою позицию,
Это достаточно разные навыки — более того человек может быть отлично уметь продавать свои идеи, но совершенно не способным воспринимать критику или быть способным менять свое мнение (некоторые навыки командного игрока могут быть даже вредными для продажника — например, способность поменять свое мнение при определенных аргументах).
Для программиста неплохо иметь скилы из первой группы (но в принципе, можно быть отличным специалистов и без них), но жизненно необходимо из второй.
Да, на разных позициях нужны разные наборы из soft skills. Так же как и на разных позициях - нужны разные наборы hard skills, например backend умеет в базы и т.д, а fullstack знает browser api - но и то и другое это hard skills. Но есть общие для всех пересечение - алгоритмы и структуры данных, или git там.
Так же и с софт скиллами, их много разных, все что связано с работой с другими человеками это категория мягких скиллов.
Разделение, которое даете вы - ролевое, но чем, например, навык продать новую технологию команде - это навык продажника, а не командный навык для tech lead ? Границы очень размыты, и разделение по ролям, скорее путает.
Тоже что мешает стать водителем, играя в симуляторы автогонщика — это достаточно разные виды опыта.
Интересно, что же мешает? Я вот не вижу особых отличий в технике управления (как человек который участвовал в любительских соревнованиях по автоспорту).
Пилоты самолётов сначала тренируются на симуляторах.
Профессиональные автогонщики тоже тренируюся на симах.
Как это работает: симулятор Red Bull Racing (motorsport.com)
Существует GT Academy - проект по переходу геймеров в профессиональный автоспорт.
Meet the Gran Turismo Player Now Driving Race Cars for Real - GameSpot
Человеку без опыта крайне сложно придумать - а чем себя занять то. Т.к. опыта нет, нет и широкого взгляда на мир - и нет понимания проблем, какие можно решить петом, даже пусть и во второй раз.
Насчет петов вообще забавно. Почему у токарей при приеме на работу нет диалога типа: «вы в свободное от работы время читаете книги, катаетесь на велосипеде и играете в шахматы, а не точите валы по приколу на своем домашнем станке? Да вы нам не подходите, если вы сами для себя работу не делаете, то и для нас не будете!» — ведь сегодня хоббийное оборудование можно разместить даже в квартире.
В токари нанимают джунов, не окончивших профильное ПТУ? При найме токаря тестовое задание или первый день не показывает всё, что умеет новичок?
Ну как же, помню, как Егор Тимурович Гайдар говорил, что ПТУ нам не нужны. Государство не должно их содержать, их надо закрыть. Опираться же на рыночные механизмы. Если бизнесу потребуются токаря, то этот бизнес сам создаст нужные ему ПТУ и будет обучать специалистов.
В России программист обучается дома или на рабочем месте. Причём хорошо обучившийся дома джун требует для превращения в мидла ещё года два на производстве. В каких-то компаниях есть для них работа и тогда их находят, просеивают и берут.
В большинстве компаний банально нет задач для джунов. Да, иногда кажется, что вроде объём работы есть, но начинаешь разбираться и понимаешь, что 3-5% этой работы имеет повышенные требования и её не отделить от остального "джуновского" блока - и берёшь мидла.
В общем, место джуна - на "галере". Там из него за 3-4 года сделают хорошего разработчика. Это давно известная истина, которую многие не хотят принять.
По поводу же образования и найма людей, вышедших из ВУЗов опять буду банален. Я видел много хороших программистов, окончивших информационные факультеты топовых ВУЗов, но все эти люди самоучки и ВУЗ ничего или почти ничего не дал им в плане профессии. Им дают большой объём знаний, но эти знания в реальной работе не нужны.
А вот важных навыков им не дают. Например, им не дают навыков борьбы с ошибками. Как не дают им навыков работы с шаблонами проектирования, фреймворками (как классом инструментария), базами данных, таск-трекерами, стилями кодирования, другими разработчиками. Они умеют программировать сложные эффективные алгоритмы, но в фреймворке тонут - он ведь большой и сложный. Они знают теорию оптимизации расчёта кривых, но не могут писать Unit-тесты. Их учат быть учёными, а в работе от них нужно писать CRUD-ы с валидацией значений и перекладкой данных между системами, базами и очередями.
Токарь также мог отучиться в ПТУ спустя рукава, еле-еле на тройки. Я повторю:
И тем не менее, позиция «мы не наймем токаря, если он дома не делает хоббийные проекты — ведь раз он не хочет делать для себя, он и на нас работать не будет» выглядит дико. Почему же инженеров-программистов так пинают?
Токаря проверят на испытательном, программиста — тоже. А вот этот барьер с пет-проектами — есть только у программистов. Я повторю еще раз: речь шла не о петах, как дополнительном свидетельстве квалификации, а именно в виде «должен сам хотеть, должен сам гореть, иначе он и у нас в конторе работать на будет (т.е. будет просиживать штаны)». Т.е. программист для такого нанимателя — это машинка, которая должна 24/7 думать о работе. А если у тебя еще и жизнь есть — значит, ты не такой какой-то. Почему у токаря не так?
Как не дают им навыков работы с шаблонами проектирования, фреймворками (как классом инструментария), базами данных, таск-трекерами, стилями кодирования, другими разработчиками
Дают. Шаблоны — это есть в курсе про углубленное ООП; курс по базам данных — один из самых серьезных, в том числе по практике. Стиль кодирования — еще с первого семестра, работа с другими разработчиками — групповые задания.
Вот и фильтруют хоть по каким метрикам.
Так это подходит под «посмотреть на петы, как примеры его работы, его квалификации». А разговор шел о том, что если человек не горит профессией 24/7 и не точит дома валы и втулки — то он «не такой» и такого брать не будем. Принцип галеры, пмсм — выжать в ноль и выбросить, когда выгорит.
Да, так. Причем по хорошему это должен быть опыт работы в реальном секторе. Ну я имею ввиду, что если человек делает на работе сайты, то скорее всего ему придет в голову делать пет проект новый фреймворк для сайтов, которых и так как грязи. А вот тут был на днях пост о по, которое по показателям каких то датчиков определяет степень износа двигателя жд локомотива. Человек, всю жизнь делающих веб сайты в жизни до такого не додумается.
Ну код такого самоучки будет малопонятен другим и в целом плох, т.к. будут отдельные фрагменты когда которые работают, и автор в них давно не глядел. Либо наоборот автор будет помешан на чистоте кода. Дальше пет проекты тяготеют к средствам разработки вроде Delphi , а бизнесу нужен Rust . Ну хорошо, человек будет специально кодить на Rust свой пет-проект. Но так как у него цели других , он будет всё равно создавать по другой логике и для других целей, чем бизнес-проект.
его код будет думаю лучше чем код того кто вообще ничего не делал и только "теоретически что то знает", так как штука всеж практическая и главное что этот код будет видно, а не придется с ним ознакомиться "только после найма", так же будет видно и сделанные решения и главное что будет еще и что обсудить на собеседовании
Зависит от самой деятельности зачастую, но на пет проектах чаще всего нет вызовов, которые приходится принимать в реальности, поэтому даже до мидла вырасти очень тяжело. С другой стороны наличие своих осмысленных (это очень важно) проектов, а не дефолтных с янде с практикума, говорит о перспективности кандидата.
Лучшая возможность написания открытого кода, которую можно предложить случайно взятому разработчику — это исправление известных багов в публичных проектах. Пет-проекты ради пет-проектов не нужны. Если нужна отсутствующая в природе, но реалистичная функциональность — то да, но не более.
Расти эффективнее всего — на работе. Отличиться начинающему лучше всего теоретической выучкой. Так во всех прикладных областях (инженеры, медики, юристы), с чего бы программирование как-то отличалось? Мой совет начинающим был бы расти вширь как можно больше на книгах и курсах, и с этим идти на собеседования. Но из-за обилия неадекватных интервью совет не очень рабочий, по-видимому.
"В наши дни одна из самых больших проблем для IT специалиста — начать профессиональную карьеру" — наши дни это последние 20 лет имеются в виду, верно?
Таких как вы - один на 100. Из этой сотни пет-проект будет у 10, и у 8 из этих 10 - лучше бы его не было.
А мне из этой сотни нужно ну скажем 20 человек набрать (мы каждый год набираем пачку джунов собственно, чтобы растить себе сеньёров-помидоров). Так что пет-проект хорошо, но иногда хорошее знание теории (язык, паттерны, и как бы это не банально звучало - алгоритмы) ещё лучше.
начать карьеру в ИТ было сложно в середине 90-х, тогда конторы были еще забиты народом выброшенным из ВПК и средний возраст разработчиков был лет под сорок, так что легко до собеседования можно было ждать месяца три, но с начала 2000-х спрос был взрывной (со спадами на лопанье дот.комов и финансовые кризисы) и рынок в целом работника, а не работодателя
Для людей без опыта, но даже с профильным образованием - всё так же сложно.
Вы рассуждаете про рынок опытных людей, здесь бесспорно рынок сотрудника, а не работодателя.
есть много маленьких контор "рога и копыта" где можно получить год+ опыт и строить карьеру последовательно за копейки, но забываем озвучить основную реальную проблему - "как начать карьеру без опыта, сразу получая денег как с опытом", на деле в это ведь упирается, а не в отсутствие мест
Хм, может в некоторых регионах и так, но в Питере точно ситуация не такая. Из всех однокурсников/одноклассников ни у кого не было проблем с поиском работы. Один даже просто в один день забил полностью на универ (3 курс) и уехал в Амстердам.
У нас на работе есть такое понятие, что "не все должны быть академиками", как раз по той причине, что академики между собой подерутся. Количество ведущих инженеров (в руках которых выработка концепций, принятие решений и отвественность за эти решения) должно по минимуму или с небольшим запасом перекрывать количество текущих проектов, остальные люди должны быть просто "руками", руки при этом бывают для черновой работы ("джуны", или среди конструкторов те, кто просто чертит, пишет, паяет, собирает, вносит правки и делают другую нудную конструкторскую работу, которой в практике конструирования может быть больше половины), бывают "руки" для чистовой работы ("мидлы", или среди наших конструкторов те, кто в рамках проекта может самостоятельно вести какую-то подсборку). Если все будут излишне амбициозные, то принимать решения можно будет только по результатам дуэли, по другому не договориться.
Такой подход удобен всем - мелкие набираются опыта, смотрят на старших и растут, старшие не отвлкаются на рутину и используют свой ментальный ресурс на решение реальных проблем.
О, это ещё в "Мифическом человеко-месяце" было. В команде 1 главный программист, 1 программист-помощник, и человек 7 "свиты" - всякие документоведы (которых сейчас системы контроля версий заменили). Думает одна голова, остальные помогают делать.
Классика - один программист решит задачу за один час, два программиста - за два часа, и так далее.
Похожий эффект может быть, но тогда через пол года у тебя не будет второго такого человека
Кроме того, концептуальная проблема - что один такой человек хоть и показывает, условно, 100% эффективности, его нельзя смасштабировать на 200% никак
Если же с масштабированием люди будут показывать пусть и меньшую эффективность, но показывать, то набрав еще 1 ты получишь 130%, набрав 2-х - 150% и т/д, набрав команду - все же получишь требуемые 200%, пусть и ценой усложнения коммуникаций
Но стоит этому программисту заболеть, уйти отпуск или уйти из компании и его производительность станет 0%, а если потеря 1 мидла из 5 и производительность будет 80% (или даже больше, так как на короткое время они могут работать продуктивнее), плюс намного легче будет восстановить знания и умения, что легко может окупить в 2,5 раз более высокие траты на зарплату.
Поэтому часто бизнесу выгоднее платить больше, но снизить bus factor. Опять-таки найти нового обычного мидла или обычного синьора на рынке труда — просто, а вот супер-пупер звезду с производительностью в 5x — очень сложно.
академики между собой подерутсяЕсли вы про тип характера, который можно назвать «академик», то возможно, но таких можно в больших количествах и не нанимать. Если просто про большой опыт и ума палата, то обычно не подерутся, а договорятся.
Утилизация. Людей без опыта сложнее утилизировать.
В крематории людей без опыта ничуть не сложнее утилизировать. Кстати, на обычном кладбище тоже. Проблема решена!
Вы, конечно, извините, но попахивает не умозаключениями менеджера проектов, а страданиями очередного желающего «войти в айти, потому что там много платят»: «я окончил шестинедельный курс, почему меня не берут в Netflix?»
Есть куча компаний, которые и джунов нанимают, и стажеров. А Netflix, судя по их капитализации, не нуждается в советах со стороны.
Netflix - edge case, я в статье указал что они могут себе позволить + краткая выжимка про бабло в моём канале, я запасусь попкорном и буду наблюдать.
Таких компаний с капитализацией как у Netflix'a - раз-два и обчёлся, а компаний с понтами круче чем у нетфликса - чуть ли не каждая третья.
Не брать джунов без опыта и потом страдать от нехватки кадров - очень распространённая менеджерская болезнь, наверное по статистике поспорит с геморроем. Людей которые понимают зачем брать джунов без опыта - в разы если не на порядки меньше. И статья в первую очередь писалась для менеджеров, чтобы поменять их мировоззрение.
Стартапу как раз выгодно нанимать сеньоров, причём не бумажных, а настоящих. Потому что платить ему раза в три больше, а его производительность выше в 10 раз (на эту тему у Джоэля, кстати, тоже было где-то).
А проблемы роста обычно связаны прежде всего с неумением эффективно масштабироваться, которое приводит к избыточному найму; вспоминаем кейс с Xsolla: если они могут уволить 150 человек и ничего не встанет колом - то нахрена их нанимали-то? А когда вместо 5 человек начинается найм 50, которые в итоге делают ту же работу - ну, да, тут одними сеньорами не обойдёшься, это очевидно. Что-то мне подсказывает, что Netflix давно прошёл кризис роста и эффективно масштабироваться умеет.
Стартапу - выгодно. Netflix - не стартап.
Netflix масштабируется как и Google - за счёт огромного количества бабла, не денег, а именно бабла. Они эффективны? Возможно да, а возможно и нет, просто доходы настолько умопомрачительные что можно сорить деньгами налево и направо. Притом эффективность и доходы тут слабо связаны, они прочно заняли нишу по созданию уникального контента, как когда-то Google со своей рекламой. Опыт Google показывает что бизнес модель у них прибыльна, но не эффективна, если посмотреть на их проекты за последние 10 лет, успешных и прибыльных очень мало. Они вытягивают за счёт рекламы.
Да и зачем Netflix'у выстраивать процессы, если можно кинуть денег значительно выше рынка, выстроить корпоративную культуру соковыжималки и драть во все щели за невыполнение показателей и сроков. Отличный подход, но нужно немерено денег.
XSolla - продуктовая компания, они просто посчитали эффективность своих сотрудников и выпилили неэффективных. Обычная оптимизация расходов. У них прибыль не зависит от head count'a, поэтому их поведение вполне логично, эффективно и прагматично.
Про стартапы было в контексте кучи компаний с понтами. Уж кто больше всех понтуется так это стартапы.
Про ксоллу - для того, чтобы выпилить 150 неэффективных сотрудников, надо сначала нанять 150 неэффективных сотрудников. А если неэффективных сотрудников порядка 20% (я вообще не понимаю, куда им столько, это сраный платежный агрегатор, типичный бесконтрольный найм после инвестраунда), то в консерватории что-то не так.
Давайте ещё раз. То, что хороший сеньор зарабатывает в 3-4 раза больше джуниора, а его эффективность в 8-10 раз выше, мы уже установили. Спрашивается, зачем нанимать не сеньоров? Единственная причина - потому что столько сеньоров хрен найдёшь. Тогда тут есть два варианта: обходиться меньшим числом разработчиков, не распыляясь на все подряд, либо нанимать кого попало и стараться растить. Во втором варианте ваши рассуждения справедливы. Но куда эффективнее пойти по первому пути. Если получится, конечно. У Гугла не получится, они слишком большие, ну так они и нанимают всех подряд. У Нетфликса, видимо, получается. А ксолла могла бы пойти по первому пути, но пошла без явной нужды (сраный агрегатор, Карл!) по второму, результат мы видим.
Смотря что за проект. Если таких задач 90%, то конечно. В какой-нибудь сраной студии так и есть. Но там и сеньор не нужен. А в продуктовой разработке такого не особо много и сеньору проще это сделать за 5 минут (а при грамотной архитектуре так и будет), чем ревьюить и учить джуна.
Понятно, что есть всегда всякая фигня, типа блога на вордпрессе, но там и роста не будет. Да и аутсорсить такое надо.
Короче, мифический человекомесяц, уже тут упоминали.
Ну да.
>А в продуктовой разработке такого не особо много
Зависит от продукта. Форм вполне может быть много, и с этим ничего не сделаешь. И там может быть достаточно тривиальная логика типа валидации, которую вы не сделаете раз и навсегда для всех полей всех форм. За пять минут — это одно поле, а если их сотни — то это уже 500 минут. И она в общем случае не поддается кодогенерации, потому что все равно поля-то разные, и где-то так или иначе нужно описать, что делать с каждым. Упростить это можно, а вот убрать совсем — я не знаю такого способа.
>Да и аутсорсить такое надо.
А что это меняет? Все равно аутсорсеров должен кто-то направлять.
про рутинные задачи - отчасти, если это бойлерплейт - можно воспользоваться кодогенерацией, фреймворками, а если просто дублирование кода - может, пора рефакторить?
Была задача переписать отчеты с делфи на веб. Каждый отчет это несколько десятков параметров входных, несколько десятков полей в отчете. Отчетов этих штук 30-40. Даже если тратить по 1 дню на каждый, то это порядка 2 месяцев.
Невижу смысла держать сеньоров на этой задаче, у них будет сравнимая производительность с джунами, особенно после первых 3-4 отчетов.
Была форма на делфи+какая-то делфовая либа для для отчетов. Стал сайт+birt для отчетов.
Нужно 2 скрипта-первый который перегоняет делфовые формы на веб, валидацию для полей из делфи на js. Не слышал о таком конвертере, выглядит как очень нетрививальная задача.
Второй для перегонки из формата отчетов определнной либ в биртовый формат отчетов. Уверен что такого нету. Думаю на его написание уйдет больше времени чем на создлание отчета.
Т.е. по-моему мнению, нет, задача конвертации и тестирования значительно объемнее чем создание отчетов заного, я бы не был готов взять написать и оттестировать это за месяц.
Давайте ещё раз. То, что хороший сеньор зарабатывает в 3-4 раза больше джуниора, а его эффективность в 8-10 раз выше, мы уже установили.
Воу-воу-воу. Полегче с цифрами. Я конечно понимаю что статистика - та ещё продажная девка, а комменты на хабре бумага всё стерпит, но нет. Как правило эффективность коррелирует с ЗП. Поэтому если сеньор получает в 4 раза больше джуна, то и эффективнее он будет где-то в 4 раза. Я, кстати, не понимаю зачем пытаться меряться цифрами которые никто не мерял и нет точных данных, да и выборок\исследований никто не проводил. Поэтому давайте согласимся на том что: "сеньор эффективнее джуна".
Единственная причина - потому что столько сеньоров хрен найдёшь.
Я бы сказал это одна из причин. КМК там их целый ряд: и хрен найдёшь, и они дорожают, и на всех не хватит, и со временем закончатся. Пожалуй ограничусь одним словом - дефицит.
Тогда тут есть два варианта: обходиться меньшим числом разработчиков, не распыляясь на все подряд, либо нанимать...
It depends как говорится. Если у вас стабильно движущийся продукт, который эволюционирует себе спокойно, то да, ваши рассуждения верны. Аутсорс - сразу мимо, там рост прибыли на headcount завязана. Если вернуться к активно растущим компаниям, они просто упрутся в потолок: просто включите воображение и представьте, Netflix вычерпал всех сеньоров с рынка (понимаю что это невозможно, но предлагаю просто представить), новых сеньоров никто не готовит; всё, компания упёрлась в потолок своего развития, они не могут дальше генерировать рост прибыли. Понимаю что ситуация в принципе невозможна, но когда-то и полёт в космос был за гранью фантастики, а то и вообще на костёр можно было угодить.
нанимать кого попало и стараться растить
Звучит не очень. Не знаю как у вас, но у нас студентов профильных ВУЗов брать не хотят. Понимаю что студент - сомнительное вложение, но я как человек преподававший, могу сказать что там очень много толковых и умных ребят. Я пожалуй останусь в этом плане оптимистом, т.к. у меня был очень положительный опыт.
А ксолла могла бы пойти по первому пути, но пошла без явной нужды (сраный агрегатор, Карл!) по второму, результат мы видим.
У вас какие-то личные счёты к ним? XD
Спасибо вам. Вы подкинули мне идею для одного интересного исследования.
Поэтому если сеньор получает в 4 раза больше джуна, то и эффективнее он будет где-то в 4 раза. Я, кстати, не понимаю зачем пытаться меряться цифрами которые никто не мерял и нет точных данных, да и выборок\исследований никто не проводил. Поэтому давайте согласимся на том что: "сеньор эффективнее джуна".
Учитывая что у меня есть доступ к разным портфолио проектов с хорошими метриками эффективности + если наложить это на финансовую составляющую, получится хорошее исследование. Понятно что детали не опубликую, NDA, но финальные цифры - интересно будет глянуть. Ловите плюс в карму вам за идею. :)
Про «в 10 раз» я по своему опыту утверждаю. Более того, крутой senior в разы эффективнее среднего. Я работал в куче проектов как внештатный специалист, и разницу эту видел неоднократно.
Как вы будете это исследовать, я не знаю. Очень сложно придумать адекватную метрику. Топовый специалист отличается тем, что он не поленился вникнуть в domain, сходу поймёт проблемы постановки задачи, сразу задаст правильные вопросы, при этом видит не тупо код, открытый в ide, а понимает высокоуровневую и низкоуровневую архитектуру проекта, и решит задачу оптимальным образом в короткие сроки. Тут как в том анекдоте, когда 1 доллар за удар кувалдой, и 99 за знание куда ударить.
Встретить такого специалиста на проекте и поработать с ним - огромное счастье. Там, где обычно подолгу объясняешь свои идеи, с такими людьми понимание с полуслова. И сравнить с другими сложно - они-то вон кучу кода написали, куча колов была, куча переписок, бурная деятельность, а этот просто нашёл эффективное решение с минимумом трудозатрат и реализовал небольшим объемом кода. Как понять, было ли такое решение для вышеупомянутых задач?
Вы мне сейчас не сеньора описали. В моей картине мира - это такой уже матёрый архитектор, такие понятно что в 10 раз эффективнее будут, но и они - штучные экземпляры, да и зп у них будет раз в 10 больше чем у джуна, а то может и поболее. Так что про корреляцию опыта и ЗП, КМК я ближе к истине. XD
В статье и в рассуждениях я всё таки опирался на опытных разработчиков. Для меня сеньор - человек с 3-7 годами опыта, знающий досконально один (максимум три) ЯП и умеющий очень хорошо в пару тройку смежных технологий. Это очень высокоуровневое описание, но думаю для контекста - достаточно.
Архитектор - это такой термин, сложный. Видится такой чувак, который занимается paperwork-ом, пишет спецификации, по которым кодят индусы в Бангалоре. Это не для каждого, дятел должен долбить, иначе нет смысла в жизни дятла. По факту почти все такие чуваки, с которыми я пересекался, были формально senior-ами (иногда тимлидами). И самые эффективные команды, которые я видел, состояли из пары таких чуваков, пачки generic сеньоров, ну и может миддла-другого на задачи, которые не то, что попроще, а скорее несрочные.
Всегда интересовало, а кто же тогда те, у кого 15-20+ лет опыта? А их вообще-то очень много, средний возраст программиста не 23 года :)
То есть как бы странные критерий очень.
Уровень квалификации - это количество скилла, а не количество отработанных лет.
Промежуток времени в 5-7 лет я бы рассматривал как усредненный показатель, когда специалист выходит на уровень квалификации сеньора, сохраняя при это энтузиазм. 90% уверенности, что для всех, кто работает более 10 лет, работа - это уже просто плавание по течению, где много рутины, и опыт собираешь по крупицам.
Если, конечно, ты не меняешь стек и развиваешься экстенсивно. Да и смена стэка, надо полагать, дает временный эффект, особенно, когда за плечами опыт более 5-7 лет.
Ну я бы сказал, что сеньор, который знает только один стек, - это очень специфический такой сеньор, не уверен, что он им является, узкий специалист подобен флюсу. Может, у меня ожидания завышены, но для меня сеньору стек должен быть в некоторых пределах не важен - хоть что делать, быстро и хорошо. Скорее предметная область может быть важна. А для этого надо в жизни разное попробовать, и 5-7 лет тут мало.
Я это честно выбросил, и взял просто готовый компонент, которых к тому времени в интернете было штук пять пригодных для нашей платформы (я просто знал, что они уже лет 10 как существуют). И за два дня прикрутил к проекту, и сделал прототип.
Как вы оцените разницу в нашей эффективности? Раз в 15 же, не меньше, правда? Я за два дня сделал тоже самое (взял готовое), что другой человек за месяц сделать не смог как следует. При этом предложенное мной решение было лучше по многим параметрам, т.е. сэкономило компании много денег еще потом, на следующих этапах.
И заметьте — это всего-лишь играл роль мой опыт. Т.е. я даже ничего не программировал, ну там написал строк 30 интеграции, не более. Я просто знал решение заранее, потому что сталкивался с такими задачами в каждом втором проекте ранее.
Так что я бы допустил, что на конкретной задаче матёрый синьор с опытом может быть эффективнее вообще в любое число раз.
Опыт работы с каким-то конкретным решением может оказаться у любого, это может быть ситуация «просто повезло».
Senior в таком случае, даже не обладая информацией, предположит, что решение задачи в обобщенном виде уже существует, за пару минут нагуглит и ещё за пару минут оценит нагугленное в контексте пригодности к решаемой задаче. Да и хороший middle уже должен это уметь.
У меня был случай из немного другой серии, но в чем-то похожий. У разработчика, нанятого для написания клиента к серверному АПИ на еще одном языке по существующей документации и референсной имплементации на другом языке, была подзадача, которую он стал решать с помощью одной относительно известной библиотеки, которая архитектурно гибкая и расширяемая, но очень слабо задокументированная несмотря на многолетнюю историю. Разработчик несколько дней провозился с написанием обертки вокруг этой библиотеки, написал много кода, не очень получалось, и начал жаловаться, просить изменить серверный АПИ. Я хоть и библиотеку эту раньше не видел, и вообще на этом языке программирования почти не писал, просто погуглил (сначала, конечно, посмотрев в исходники библиотеки, чтобы сформулировать запрос в гугл в соответствующих терминах) и нашёл слабо задокументированную фичу, которая решает ключевую проблему в одну строку кода, погуглил ещё чуть-чуть и полностью решил стоявшую подзадачу в где-то строк 20 кода. Ушло у меня на это все часа два, включая время на установку IDE и прочего инструментария. Хотя на самом деле мне тоже повезло, ведь я искал не готовую фичу, а соответствующий плагин для библиотеки или способ его написать; с другой стороны, то, что я в таких поисках наткнулся на готовую фичу - вполне закономерно.
И вот фиг его знает, как наличие таких скиллов проверить.
Может, разумеется. Но опыт мне подсказывает, что в среднем чем выше уровень — тем больше шансов, что опытный найдет решение вот таким вот образом, тупо поискав. Просто потому, что он годами читал какие-то блоги, новости и пр., и что-то там запоминал для себя.
Это совершенно не значит, что производительность синьора будет всегда на порядок выше, чем у джуна. Суть моего примера скорее в том, что попадаются задачи, на которых эта разница просто зашкаливает.
имхо, финансовая составляющая - не совсем корректный показатель. В финансовом плане, имхо, важнее не столько качественно реализовать, сколько придумать то, что нужно людям.
Вы считаете, что если есть работына N сеньоро-часов, то и надо нанимать сеньора.
Если у вас что-то сеньор сделает в 8 раз больше джуна за 4 раза больше денег, то это не означает он вам все задачи сможет так закрыть.
Во-первых, не везде его производительность будет в 8 раз больше.
Во-вторых, там, где его производительность будет в 8 раз больше, ему может быть не очень интересно ровно по тем же причинам, что и восьмикратная эффективность -- он 100 раз уже решал такую задачу.. И проработает н таких задачах у вас такой сеньор не очень долго.
Не очень понятно, а чего тут теоретизировать? Одни хотят, чтобы можно было меньше платить, но при этом больше бы делали.
Другие наоборот. Спорить о том, что важнее как-то глупо.
Netflix стал успешен благодаря умению принимать правильные бизнес-решения: однажды медиаплатформа поняла, что производить контент самим дешевле, чем платить за готовый. Но производство кино это технология, которой больше ста лет. Там можно нанять топовых сценаристов, а продакшен заказать «под ключ». Потому что там не нужно изобретать ничего нового. Как отследить зрительский интерес, как написать хороший сценарий, как правильно делать сторибординг, снимать, монтировать, как играть роль — всё это тысячи раз прописано, на рынке множество профессионалов, а понять качество продукта можно просто посмотрев готовый материал. Ничего этого сегодня в IT нет — «поставь камеру вот так, а свет вот так, и будет хорошо» — таких решений просто нет. Сейчас IT это на 90% инженерная отрасль, где все задачи так или иначе нужно проектировать и реализовывать. Современное производство кино давно достигло уровня конвейера, там, чтобы достигнуть приемлемых результатов, надо просто не замахиваться на шедевры, а соблюдать сто раз прописанные правила. И телеэкран, и киноэкран за сто лет почти не поменялись. В разработке подобного уровня правил нет: отрасль вечно молодая, а технологии меняются непрерывно.
И если вам кажется, что менеджеры, достигшие успеха, не делают ошибок в смежных областях — есть много примеров, когда это было не так.
Не брать джунов без опыта и потом страдать от нехватки кадров - очень распространённая менеджерская болезнь
И не только айтишная. Это "болезнь" всего российского бизнеса. Можно посмотреть на тот же производственный сектор, где тоже все хотят инженеров с опытом. Не любят у нас особо вкладывать деньги в развитие людей, все хотят чтобы рисковал кто-то другой. В принципе это даже можно понять. Только вот нытье по-поводу того, что людей не хватает при таком подходе начинает раздражать. Netflix хотя бы не ноет.
очень мудрое и своевременное замечание, если закрыть доступ свежей крови, система вымрет
Ради интереса попробуйте создать резюме с востребованным стеком, но только в одном укажите что хотите на джун позицию, а в другом на мидл - и опыт укажите граничный - чуть больше года, что в одном, что в другом резюме. Я думаю , после этого вы сможете найти ответ на вопрос - нанимают ли джунов хотя бы примерно так же как и мидлов. Думаю, вас удивит результат))
Смех смехом, но в Индии так и поступают. Там ещё и резюме всей деревней пишут по принципу:
- О, я помню мой дедушка рассказывал мне сказку и там было такое слово - ActiveX.
- Конечно же пиши его в своём резюме!
Всем надо подаваться на мидла? Мидл это новый джун?
А так оно и есть, формы научился верстать и уже миддл. Знать что-то про сборку мусора? Многопоточность? Шутите, батенька, це вопросы для синьора.
Тот, кто в одном месте сеньор, в другом может на джуна с трудом потянуть. ;)
Знаете подлинную проблему сеньоров на проектах? От них ожидают, что они знают всё. Психологически им труднее всех - они достигли формального потолка развития в профессии.
Им расти нужно куда-то, а они уже носят самое гордое звание из всех возможных. Даже если станут знать вдвое больше, чем с момента становления сеньорами - их будут продолжать звать сеньорами. Я уже потихоньку ввожу в практику другие названия, форсируя идею, что Илон Маск был прав с необходимостью более ярких и привлекательных званий. Например, себя я зову исключительно Automation QA Emperor.
можно устроить деноминацию званий, как во времена Империи - полковник переводится в гвардию капитаном, бо полковник Гвардии - сама Матушка Императрица )) "У себя на галере, Владислав, вы были синьор, а у нас тут в яндфлексе будете Гвардии джун второго класса!"
ну если серьезно, то варианты перехода из начальников отдела разработки в средние миддлы в Яндексе я видел...
Monseigneur еще можно.
Это проблема только в крупняках с формальными грейдами и прочим буллшитом.
Нормальным людям насрать на звания, не в армии.
Проблема в том, что к этим "званиям" часто косвенно привязана зарплата.
Обычно на рынке джуниор получает X денег, миддл 2Х денег, сеньор 3Х денег, а потом уже начинается как у боксеров - сверхтяжелый вес. И дальше уже непонятно от чего будет зависить зарплата. Т.е. пока есть грейды есть какие-то референсные значения, а как сеньорам быть - хз.
Очень просто, от взаимных договоренностей. Это ещё «торг» называется.
Ну а потом приходит в такую компанию крутой спец, с 10х производительностью, как из моего комментария выше. Менеджмент собрался на совещание и чешет репу: максимальный грейд сразу давать нельзя, остальные не поймут, ну давайте ему топового миддла поставим для начала, но нагрузим как сеньора и посмотрим. Кандидат выслушивает такое предложение, смотрит на это всё, говорит - а пошли бы вы в жопу со своими играми, и уходит на следующее собеседование.
В итоге топовые специалисты туда попадают только с приобретением и мержем другой компании, там «сохранение звания при переходе в армию союзника» проблем не вызывает. Часто только ради этого и покупают.
В мелких конторах все инженеры, и раз нет субординации можно гнобить друг друга и устраивать весёлые срачи? XD
ну так можно назваться техлидом, архитектором...
есть же ещё lead developer и principal developer
Это все подразумевает взятие на себя некоторых функций менеджера, и пересекается с teamlead. А что делать с теми, кто этого не хочет, но программирует лучше остальных senior-ов?
я имел в виду не тимлидство, а что-то как здесь https://github.com/avito-tech/playbook/blob/master/developer-profile.md#lead
Начало за здравие а аргументация за упокой.
Мы нанимаем топ рынка. Не тешьте себя иллюзиями
Нанимать топ рынка(пусть будет топ 5%) проще простого. Просто берем 95% перцентиль по зп на позицию и все резюме которые просят ниже отправляем в мусорную корзину. Точно так же можно нанимать топ по репутации stackoverflow. А вот нанимать топ по навыку программированию уже нереально потому что этого топа не существует и вообще функция compareTo не определена.
Положительную репутацию со стороны сотрудников. Вы не морозите людей вечно, а в случае необходимости ротируете их в разумные сроки.
Так вы получаете возможность ротировать джунов в мидлов. Если вы не нанимаете джунов принципиально то и ротировать их нет нужды в связи с отсутствием. Иными словами наличие джунов никак не решает проблему ротации более опытных кадров.
Положительную репутацию со стороны начальства. Руководство зачастую нацелено на рост и развитие бизнеса, и подготовка кадров помогает справляться с кадровым голодом.
Сдается мне что вышестоящему начальству глубоко наплевать как вы решаете кадровый голод, через хайринг или обучение. Их интересует результат и затраченные средства. Поэтому что-бы это было плюшкой требуется дополнительно постулировать что обучение выгоднее чем хайринг. Для каких то компаний это так и есть но в общем случае это утверждение спорное.
Инженеры занимаются задачами, соответствующими их уровню. Очень часты ситуации, когда нанимают сеньора и дают ему примитивную, монотонную работу, которая никак не применяет и не развивает его навыки. Думаете долго такой человек у вас проработает? Наймите лучше джуна.
Это действительно плюс, такое встречается, особенно в аутсорсе/аутстафе, где инженеры имеют минимум полномочий для автоматизации подобной рутины.
Эффективно решаете проектные проблемы. У вас есть пул людей, поэтому вы в противоположность вашим коллегам решаете ваши проблемы самостоятельно, а не вечно ноете и срываете сроки, разводя лапками.
А вот тут подмена одного тезиса другим. Наличие пула людей это действительно хорошо но наличие джунов в команде != наличию пула.
Положительная репутация. На самом деле это огромный плюс в репутацию компании - найм людей без опыта.
Значимый плюс это только для людей без опыта. Для остальных этот плюс где-то на уровне показателя процента "зеленой" электроэнергии используемой компанией.
Сотрудники, которых компания взрастила или наняла без опыта в самом начале карьерного пути, намного лояльнее относятся к компании, чем нанятые и опытные сотрудники.
Безусловно да. Но только лишь при условии правильной системы вознаграждения в компании. Сейчас в 99% компаний проще всего увеличить себе зп уволившись с нее и устроившись по новой.
учитывая разницу в rate card (очевидно, что за джуна платят меньше), маржинальность на более дорогих профессионалах ниже.
Людей без опыта сложнее утилизировать. Зачастую сталкиваются с ситуацией, где все хотят сеньоров с вот такущим списком знаний и умений
Вот оно что. Речь в статье действительно про аутсорс. Ну тогда можно сократить всю статью до 1 пункта - "лучше продать синьора и джуна чем одного синьора", к такому уже трудно будет что-то добавить.
Интересная ситуация с непосредственным руководством - иногда тимлиды бывают против, мотивируя тем, что упадёт производительность отдельного сотрудника, да и вообще Баба Яга против.
такой сотрудник уже выгорел, токсичен или уже начинает просто саботировать проект, как правило активное противодействие в проектных инициативах - хороший маркер чтобы присмотреться к сотруднику.
Поэтому по итогу: такой лид не выбирается наставником, ангажируем кого-то другого, а за лидом пристальный надзор.
Понятно, берем человека на карандаш за несогласие с партийной линией.
но ты же коммунист
Вы допускаете ошибку - у вас система статична, у меня - нет. Тот кто вчера был джуном, через год-другой становится мидлом, мидлы вырастают в сеньоров и т.д.
Так вы получаете возможность ротировать джунов в мидлов.
Нет, при условии выше. Ротация будет overqualified мидлов(возможно сеньоров) на мидлов.
Сдается мне что вышестоящему начальству глубоко наплевать как вы решаете кадровый голод, через хайринг или обучение. Их интересует результат и затраченные средства.
Всё зависит от степени кадрового голода и тут все средства хороши, когда идёт активный рост или нужно искать новые источники, когда привычные и старые вычерпаны. Тут и обучение, и хайринг и покупка компаний, всё будет работать, вплоть до "дети зачатые на корпоративе считаются сотрудниками компании". Бизнес не будет брезговать ни чем, главное чтобы всё было в рамках законов.
А вот тут подмена одного тезиса другим. Наличие пула людей это действительно хорошо но наличие джунов в команде != наличию пула.
Нанять мало, их растить надо и развивать. Опять же я не рассматриваю статичную систему, поэтому не сразу, но пул толковых специалистов за несколько лет можно сформировать и это только если опираться на найм джунов и обучение их с нуля. Можно быстрее, но это через найм только.
Безусловно да. Но только лишь при условии правильной системы вознаграждения в компании. Сейчас в 99% компаний проще всего увеличить себе зп уволившись с нее и устроившись по новой.
Про пересмотр ЗП согласен, но значит я вхожу в этот 1%, т.к. мои сотрудники спокойно могут прийти и сказать что хотят больше, а зачастую я поднимаю им зп заранее, ну или моё начальство меня подгоняет, что давно кому-то не пересматривал. XD
Вот оно что. Речь в статье действительно про аутсорс.
Если вы считаете, что в продуктовых компаниях нет утилизации, ресурсного менеджмента и проектных менеджеров, которые крутят носом при виде резюме джуна, предложенного на проект. Не смею вас разубеждать. Лучше оставаться в розовых очках и думать что в продуктовых компаниях всё стильно\модно\молодёжно, нет жёсткого BDSM с легаси, которое приносит прибыль бизнесу, а разработчики какают радугой.
Понятно, берем человека на карандаш за несогласие с партийной линией.
Выше написал же: "такой сотрудник уже выгорел, токсичен или уже начинает просто саботировать проект, как правило активное противодействие в проектных инициативах - ... маркер ". Я конечно понимаю что для некоторых сидеть на проекте вечно и токсично ныть на всех вокруг - норма, но лучше "поднять руку" и спокойно ротироваться с проекта, как я говорю: "никто не прибит гвоздями". Хотя есть люди которым пофиг: токсичные ли у них сотрудники, разваливается ли у них проект. Само пройдёт. Возможно. Как-нибудь.
но в вашей не статичной системе вчерашние джуны почему-то продолжают работать у вас, хотя это совершенно не гарантировано.
Как удерживать сотрудников и делать чтобы они не уходили - отдельная тема разговора и она больше про People Management. Но это вполне посильная задача.
А поделитесь размышлениями.
Кроме держать зарплату не просто выше рынка - а выше тех, кто выше рынка (ну и не создавать на ровном месте проблем) я особо вариантов не вижу. А при таких вводных можно и только сеньоров нанимать.
Можно, конечно, стать суперкрутой компанией, куда все будут стремиться не только за деньги, но это не тот рецепт, который можно легко реализовать.
Подписывайтесь, запилю. ;)
Финансы на самом деле очень важны, но их значимость можно значительно понизить при принятии решения о переходе в другую компанию. Расскажу как это делать.
Вы допускаете ошибку - у вас система статична, у меня - нет. Тот кто вчера был джуном, через год-другой становится мидлом, мидлы вырастают в сеньоров и т.д.
Каким образом моя(да и почему она моя? давайте называть ее системой netflix) система статична? Она точно так же предполагает ротацию, только исключает ступеньку джуниоров.
Нет, при условии выше. Ротация будет overqualified мидлов(возможно сеньоров) на мидлов.
Ротация будет абсолютно одинаковой в обоих случаях, как горизонтальная так и вертикальная. Вся разница только в том что будет первой ступенькой ротации: джуны или люди с опытом.
Всё зависит от степени кадрового голода и тут все средства хороши, когда идёт активный рост или нужно искать новые источники, когда привычные и старые вычерпаны. Тут и обучение, и хайринг и покупка компаний, всё будет работать, вплоть до "дети зачатые на корпоративе считаются сотрудниками компании". Бизнес не будет брезговать ни чем, главное чтобы всё было в рамках законов.
Я не спорю про то что все средства хороши. Но что бы безапелляционно утверждать что это будет плюсом для начальства свыше, нужно обосновать финансовую состоятельность этой затеи а не просто огульно утверждать. Без цифр на руках можно этот пункт написать и в обратную сторону. Смотрите:
Положительную репутацию со стороны начальства. Руководство зачастую нацелено на рост и развитие бизнеса, резкий старт людей имеющих опыт в программировании вкупе с меньшими затратами на их супервайзинг позволяет быстрее включать их в работу и добиваться ключевых метрик развития продукта.
Запишите в минусы?
Если же у вас есть явные цифры о том что обучение выгоднее то сама статья сокращается до:
Q: Нанимать готовых специалистов или обучать? A: Обучать - потому что это финансово выгоднее, вот цифры.
Нанять мало, их растить надо и развивать. Опять же я не рассматриваю статичную систему, поэтому не сразу, но пул толковых специалистов за несколько лет можно сформировать и это только если опираться на найм джунов и обучение их с нуля. Можно быстрее, но это через найм только.
Пул толковых специалистов может у вас быть точно так же если вы нанимаете синьоров и архитектов. Это и найм джуниоров абсолютно ортогональные вещи по смыслу.
Если вы считаете, что в продуктовых компаниях нет утилизации, ресурсного менеджмента и проектных менеджеров, которые крутят носом при виде резюме джуна, предложенного на проект.
Если я утверждаю что в аутсорсе есть огромный стимул к найму джунов то как из этого вытекает ваше предположение о том что я считаю что в продуктовых компаниях менеджеры рады джунам? Как раз ровно наоборот я считаю из своего опыта, что в продуктовых компаниях гораздо менее лояльны к хайрингу джунов. У них нету вышеописанной мотивации аутсорсеров продавать джунов хоть тушкой хоть чучелом, у них совершенно другие способы заработка и наборы KPI.
Выше написал же: "такой сотрудник уже выгорел, токсичен или уже начинает просто саботировать проект, как правило активное противодействие в проектных инициативах - ... маркер "
Ну да, именно что написали. Написали что если лид высказался против найма джунов то значит он выгорел и его нужно скрутить в бублик(sic!) и вообще явно дали понять что его мнение не так уж тут и важно. Особенно забавно это воспринимать вместе с последующим пунктом "не переусердствуй".
Нанимать топ рынка(пусть будет топ 5%) проще простого. Просто берем 95% перцентиль по зп на позицию и все резюме которые просят ниже отправляем в мусорную корзину. Точно так же можно нанимать топ по репутации stackoverflow. А вот нанимать топ по навыку программированию уже нереально потому что этого топа не существует и вообще функция compareTo не определена.
Функция compareTo по навыку программирования (вообще) нужна только премиум-бодишопу (условному, настоящий бодишоп будет продавать индусов под видом сеньоров).
А по конкретному набору скиллов, нужных для работы над конкретным продуктом, достаточно 10 минут собеседования, чтобы понять, что человек подходит. Конечно, собеседование длится дольше, но за 10 минут уже понятно на самом деле, просто уже видишь этого клевого чувака у себя в команде.
Если «ну вроде ниче», но уверенности нет - не нанимать. Лучше ошибиться в эту сторону.
вот когда ты будешь сеньор с зарплатой от $1000 тогда и приходи
Это где такие смешные зарплаты у сеньоров? В бангалоре?
Может, это в секунду)
-Скажите, порудчик, как вам удаётся с такой лёгкостью нанимать сеньёров?
-Очень просто, корнет, подходите к любому сеньёру и говорите - мсье, позвольте вас нанять за 1000$.
-За 1000$!? Но так же можно и по морде получить!
-Можно и по морде, а можно и нанять.
2005й год. Беларусь. На тот момент - хорошие деньги.
Задача любого бизнеса успеть заработать на сотруднике больше, чем ему заплатили за время, пока он не уволился.
Это прекрасно умеет делать Макдоналдс. Берет джунов/стажеров и ведет их по карьерной лестнице. Кое-кто доходит до менеджерских должностей и в целом неплохо себя чувтсвует.
Проблема в том, что никто не умеет так вести джунов, да еще и зарабатывать на них.
хаотичный набор мыслей. тяжелый слог "умственногорассуждения"
ключевое - для чего эта статья? для кого? ответ - очередное сотрясение воздуха в попытке изменить мышление тех кто даже хабр не читает , не то что такие статьи
В любой беловоротничковой сфере такие же проблемы, ИТ тут не уникальна
Пет проекты должны быть имхо, и не важно спрашивает их работодатель или нет.
Пет проект - это как высшее образование) Оно вроде бы и не нужно, но быть должно)) Опять же, это не показатель того что ты гений, просто если ты не осилил пет-проект - то и на работе вряд ли от тебя будет толк. Конечно, бывают исключения - Б. Гейтс и тд
Но, знаю ребят, кто свои пет-проекты умудрился монетизировать и заработать с этого (не много конечно, но все-таки приятно - тут самое главное +100500 к мотивации)
А я знал когда-то человека, который не брал программистов, отвечающих на вопрос о хобби — "прогрммирую". Он считал их слишком токсичными людьми.
У нас в городе на заре галеростроения был случай - в какой-то конторе взяли HR которая загонялась по всяким психологическим тестам, но понятно что образования в этой сфере у неё не было, как итог они сначала отсеивали ребят по принципу: "ой, ну этот не саксефулли пассед вис этот тестик, он нам фулли донт матч". Как итог галера на дне, про капитана - не знаю, не интересен, может где рыб и крабов кормит, а может где и барабаном задорно ритм отбивает.
вопрос о хобби
30 сантиметров. …В диаметре.
И что? Его правота налицо, собственно.
проблема с пет проектами в том что на них нужно время. А если именно вкалываешь на работе а не приходишь попить смузи с ребятами с прикольными стрижками то сил на еще програмирование нет. Хочется и от работы отдохнуть и с семьей время провести.
Пет проекты это больше для молодых специалистов или студентов у которых есть силы и время приходя после работы забурится в изучение чего-то нового до 2 ночи а с утра быть огурчиком на работе.
проблема с джунами, как её видят менеджеры, в другом. На период обучения они обходятся компании дороже миддлов/сеньоров, по соотношению k = результативность*качество/доллар. А когда они наконец дорастают до миддлов, могут и свалить в условный нетфликс на x2. А если этому плавно перерастающему в миддла джуну платить как в нетфликсах, то можно было вместо него нанять миддла и получить желаемый k сразу.
И эта логика отлично работает в начинающих конторах, где порог входа в проект минимален. А вот в большом проекте, где надо уметь ориентироваться в архитектуре и знать местные апи/инструментарий/процессы - там всё становится хитрее. Выросший в компании джун будет ценнее миддла со стороны просто потому, что второму всё равно придется долго впитывать то самое сакральное знание.
Тестовое джунам еще и тем хорошо, что позволяет пополнять им GitHub. Не у всех есть идеи для pet project, а тут хоть что-то. Может и перерасти во что-то интересное: я так начал с примеров автотестов на API ХаХару, а на выходе получился дашборд с аналитикой для локального рынка труда.
Не у всех есть идеи для pet projecthsto.org/webt/wm/4x/np/wm4xnpw012-bbqzbuvf9hobuk3k.png
Собак и детей можно брать из приюта. Например, чтобы не возиться с лужами по всему дому и спать по ночам. Но, почему-то так делают не все.
После прочтения заголовка в мыслях возникла картинка где сеньоры в первый рабочий день дерутся за место главного сеньора в команде, при чем не как котики, а на ножах или как в темном рыцаре, когда джокер сломал кий и дал двум бандюгам со словами "у нас только одно место".
В результате в такой компании в основном оказываются миддлы, назвавшие себя "сеньорами"(разоблачение невыгодно никому). Значительная часть из них выполняет работу джуна и валит при первом удобном случае.
В наши дни одна из самых больших проблем для IT специалиста - начать профессиональную карьеру.
Если получилось разобраться на уровне начинающего (git, php\java, linux, etc), любые курсы программирования из серии "Евгения Попова" помогут в этом деле.
А дальше все просто для начинающего разработчика.
Откладываем влажные мечты про "делать мир чуточку лучше за 300кк$\наносек" и (!!!) устраиваемся юнгой на любую галеру куда возьмут, на любых условиях хоть за дошик, хоть за черный нал, хоть за 50% от зп, и (!!!) гребем, гребем, гребем, просто гребем все что можно, самые отстойные задачи, которые никто не хочет делать считайте своим бинго, тут важно, во-первых получить тот самый заветный (1-3 года опыта) увидеть реальные проекты и поработать с ними, нахвататься "модных" словечек, баек и вообще погрузиться в этот самый интерпрайз и т.д., все это нужно чтобы было что рассказать на ближайшем собеседовании и показать что ты "в теме" и вообще молодец, отличник, комсомолец, так же можно провернуть трюк с заведением ООО и формальным трудоустройством, что даст запись 1-3 года опыта, но "реальный" опыт все равно нужен, потому что без него не получится и двух слов связать про разницу между абстрактным классом и интерфейсом, а речь должна "идти от самого сердца".
В самом начале будет получаться ничего и вообще никак, будет злость на себя и весь мир, что все сложно, синдром самозванца посетит не раз, факапы, штрафы, буллинг, сталкинг, прессинг, гулаг, могут даже в чем то начать обвинять, важно понимать чем ниже прайс, тем меньше вы должны что-то принимать близко к сердцу, и т.д. это нормальный процесс, считайте это испытанием своей веры в то, что вы программист, этот путь пройдут только сильные духом. Главное чтобы вся эта грязь не засела в вас.
При этом очень важный момент, в отрыве от кранчей и овертаймов, 4-6 часов каждый день надо добавлять на изучение технологий в которых вы еще не разбираетесь, читать на первых порах можно ру ресурсы, далее переходить на en какой-нибудь medium, смотреть воды, обязательно как минимум делать get started и пытаться что-то добавить свое.
Мотать срок так придется от года до трех, а дальше уже можно начинать "делать мир чуточку лучше за S.O.L.I.D.ный прайс", S.O.L.I.D. вообще хорошие практики, есть шанс сразу попасть в адекватную контору, но это скорее исключение из правила.
Все это возможно если город 500к+ населения, иначе переезд.
Так что никакой проблемы нет, вообще нет, надо только снять "розовые очки" и начать работать.
Мы шли по пути набора на junior позиции и выращивания из них специалистов, но столкнулись с проблемами:
Значительные усилия и время тратятся специалистами уровня senior для обучения, тем самым отвлекая их от задач бизнеса;
В среднем до уровня middle сотрудник вырастает за 1,5-2 года;
После того как сотрудник понимает, что его уровень близок к middle, он старается перейти на более интересные ему задачи. Теперь ставшие для него рутинными задачи выполняются с нежеланием. При том что 70% задач это как раз такие.
Через некоторое время сотрудника достигшего уровня middle хантят другие компании. Т.к. у нас современный стек, то такие специалисты сейчас популярны. Лояльность к компании не имела решающего фактора, для того чтобы остаться.
И да, у нас уютный офис, хорошая команда профессионалов и отлаженные процессы, как и в большинстве современных ИТ компаний.
Значительные усилия и время тратятся специалистами уровня senior для обучения, тем самым отвлекая их от задач бизнеса;
Я такие задачки выдаю как дополнительное развлечение, либо для сверхпродуктивных людей, которые за 4ч успевают сделать то что другие делают день, а то и два; или это может забирать часть личного времени, в обмен на финансовое вознаграждение, такая подработка.
В среднем до уровня middle сотрудник вырастает за 1,5-2 года;
Да, цифры очень похожие.
После того как сотрудник понимает, что его уровень близок к middle, он старается перейти на более интересные ему задачи. Теперь ставшие для него рутинными задачи выполняются с нежеланием. При том что 70% задач это как раз такие.
На мой взгляд тут надо уже готовить следующих джунов, а новоявленным мидлам выдавать другие задачи. Но всё это требует активного роста бизнеса.
Через некоторое время сотрудника достигшего уровня middle хантят другие компании.
Здесь нужно удерживать сотрудника, обычно это целый комплекс мер и мероприятий.
Стало интересно: а нанимать миддлов специально для обучения молодняка, а не отвлекать тех, кто должен работать над задачами, -- не рентабельно?
И, извиняюсь за наивный вопрос, но при невозможности открыть на базе компании training center, не проще ли на входе отправлять новичков на какие-нибудь короткие образовательные курсы? Мне не понятно, почему не выгодно выращивать спеца внутри компании: да, сначала тратишься, но потом он прокачивается и начинает приносить прибыль. А даже если его схантят, это плюс в копилку индустрии, текучка кадров это стандартная история в любой сфере.
Выделять опытных сотрудников на позиции с отрывом от производства - вполне себе рентабельно и даже не мидлов, но это дорогое удовольствие, только большие компании себе такое позволить могут, там за счёт объёма общей выручки закрываются траты на обучение.
А о компании эти миддлы что будут знать? Что они будут знать о проектах и их потребностях?
>почему не выгодно выращивать спеца внутри компании
Ну я могу предположить, почему это сложно. Меня регулярно пробовали в компании заманить преподавать внутри. Я отказываюсь всегда, по таким простым причинам:
— эта работа предполагает 100% занятость, а у меня нет в сутках 48 часов
— а если я занимаюсь ей половину времени, страдает основная работа.
Ну т.е. это либо достаточно тяжело, либо вы начинаете терять квалификацию, отдаляясь от своего основного проекта и работы. Немногие на такое готовы. Да и вообще далеко не всем нравится преподавать.
Обучение на курсах мы практически не используем. Чтобы хорошо усвоить материал курса, на него нужно прийти уже с практически знаниями в изучаемой области. С другой стороны, человеку, погрузившемуся в изучаемую область курсы мало полезны, т.к. в большинстве их уровень достаточно базовый и при этом сильно обобщённый, отличающийся от того что действительно есть в компании.
У нас есть junior позиции, но их мало. Мы сделали значительный акцент на автоматизацию и закрыли большую часть задач для которых требовался такой уровень. Мы так же скорректировали подход к подбору на junior позиции, выбирая людей с хорошо выраженными парадигмой Win – Win, развитием и результативностью. Поиск таких сотрудников — это отдельный вопрос.
Хотелось бы добавить, что если мы говорим не о больших компаниях, а о маленьких в регионах, то проблема в том, что они берут джунов, но не умеют с ними работать. По факту им нужны мидлы, но финансы не позволяют их нанимать, поэтому они берут джунов и ожидают, что они сразу будут закрывать задачи. В итоге мы получаем, что требования для джунов в таких местах завышены.
Пардон, а скока лет назад это было? Я такие зарплаты получал примерно в 2004 году в Москве. Ну и тогда я был синьором, да. А сегодня эта сумма вообще не синьорская зарплата, на мой взгляд, причем уже возможно нигде, потому что удаленка с тех пор сильно развилась.
Браво маэстро, проблема того что всем нужны мидлы с огромным стеком или сеньеры очень большая в России и когда тебя берут на позицию Trainee с зарплатой ниже стипендии, то ты не пойдешь на нее потому что просто на просто умрешь с голода и без денег сидя месяц а то и два на стажировке, в неуверенности даже возьмут тебя в компанию или нет.
"Джун учится работать. Миддл - работает. Синьор - учится не работать")
Для успешной реализации чего-то крупного с элементами уникальности, необходима разносторонняя команда, чтобы джуны тоже были, задавали "тупые" вопросы, которые, иногда, порождают интересные идеи и вырастают в крутую реализацию.
История из собственной жизни - чуть больше 3-х лет назад мне позвонили из одной компании и предложили работу разработчика сетевых сервисов. Возраст на тот момент 40+, опыта коммерческой разработки нет, компания пишет на Go - я писал на C (не модный и не молодежный) и в основном вещи для сетевой инфраструктуры сотового оператора (в котором тогда работал уже почти 7 лет), что такое Go вообще не знал до этого звонка. По модной классификации - джун--. Сходил, поговорил, вышел на работу. Втянулся, стал потихоньку писать. На данный момент свой уровень оценить сам я не смогу, но собеседования я уже сам провожу и коллеги периодически обращаются за советом. Так о чем я вообще? Джуны могут быть тоже разными - и это очень хорошо видно на собеседованиях. Под словом "джун" я в данном контексте понимаю человека без опыта разработки или с минимальным опытом. Одни например пытаются понять (или найти где-то) например как и почему сделаны какие-то вещи в языке именно так как сделаны, а не по другому. Понять концептуальные особенности языка чтобы правильно применять его сильные стороны и обойти слабые. Другие просто пытаются из готовых фреймворков что-то сляпать не разбираясь как и что внутри работает. Третьи (часто в телеграме очень попадается такое в профильных чатах) вообще пишут "посоветуйте интересный фреймворк вроде вот такого - чтобы поизучать". И опыт тут совсем не имеет значение, значение имеет заинтересованность в знаниях и какое-то базовое образование, которое дает университет (и уровень которых к сожалению падает сейчас). Вот по этой причине скорее всего и не берут дунов - тех кто хочет разобраться очень мало.
Мы нанимаем только сеньоров