We don’t hire junior developers or interns…if you don’t get a puppy, you don’t have to clean up its messes.
~Netflix
В наши дни одна из самых больших проблем для IT специалиста - начать профессиональную карьеру. Многие из нас прошли путь "первого трудоустройства" и не знаю как вы, а мне довелось услышать такую фразу от рекрутера: "вот когда ты будешь сеньор с зарплатой от $1000 тогда и приходи".
В Российской Империи дворянство решало подобный вопрос весьма прозаично. Детей записывали в армию с самого рождения, поэтому, когда приходило время нести бремя военной службы, детишки уже служили в чинах.
16 лет спустя
Пройдя путь в кровавом энтерпрайзе от джуниора до руководителя проектов в 60(+) человек, я хочу изложить своё видение на вопрос о найме сотрудников без опыта и тех нюансах, с которыми сталкивается наниматель. Сознательно опущу ряд деталей, иначе эта статья рискует разрастись в огромное чтиво, а зовут меня не Фредерик Брукс.
Ай нет
Начнём с отговорок, которыми унижают себя менеджеры и компании:
Мы нанимаем топ рынка. Не тешьте себя иллюзиями, возможно вы нанимаете хороших и отличных специалистов, но проблемы найма топа уже обсуждались не раз и не два. (блог Joel Spolski)
Bring on strong people who already have a good amount of experience who can fully own an area themselves and pay them much better than their competitors would (at least in salary terms). (Netflix) - Политика компании - нанять топ людей чтобы они сами маслали вёслами. Я с уважением отношусь к компании Netflix и сам периодически смотрю их сериалы, но как по мне это выглядит как пирамида на галере. Рухнет?
Может да, а может и нет, время покажет. Но проблемы выгорания и быстрого ухода сотрудников из Netflix уже обсуждались.
-
Типичное:
У нас нет ресурсов\времени для найма\обучения джуниоров.
У нас нет шанса допустить ошибку, ставки слишком высоки.
Нам необходимо сделать базовый продукт до того, как нанимать людей без опыта.
Зачем мне это надо?
Какие плюшки вы с этого как проектный менеджер получаете:
Положительную репутацию со стороны сотрудников. Вы не морозите людей вечно, а в случае необходимости ротируете их в разумные сроки.
Положительную репутацию со стороны начальства. Руководство зачастую нацелено на рост и развитие бизнеса, и подготовка кадров помогает справляться с кадровым голодом.
-
Улучшаете мотивацию сотрудников.
Ваши сотрудники понимают, что есть механизм ротаций и когда освобождается та или иная позиция, высока вероятность что эту позицию займёт кто-то из существующих и эффективных сотрудников. Это решение для вас как для руководителя обойдётся дешевле в сравнении с внешним наймом кота в мешке. Как-нибудь отдельно мы проговорим за Succession Planning.
Инженеры занимаются задачами, соответствующими их уровню. Очень часты ситуации, когда нанимают сеньора и дают ему примитивную, монотонную работу, которая никак не применяет и не развивает его навыки. Думаете долго такой человек у вас проработает? Наймите лучше джуна.
Эффективно решаете проектные проблемы. У вас есть пул людей, поэтому вы в противоположность вашим коллегам решаете ваши проблемы самостоятельно, а не вечно ноете и срываете сроки, разводя лапками.
Всё вышеизложенное зачастую положительно сказывается: на вашей финансовой компенсации, карьерном росте и в случае outsource'a положительном отношении к вам заказчиков.
Здесь важно отметить, что вам понадобится поддержка руководства и его заинтересованность в вопросе найма людей без опыта.
Поэтому давайте разберём что получает компания\бизнес:
Положительная репутация. На самом деле это огромный плюс в репутацию компании - найм людей без опыта. Сотрудники, которых компания взрастила или наняла без опыта в самом начале карьерного пути, намного лояльнее относятся к компании, чем нанятые и опытные сотрудники.
Решение кадровых вопросов. У вас есть люди для роста и развития бизнеса. Закроете вы вопрос полностью или частично - зависит от ваших аппетитов и скорости роста бизнеса.
-
Уменьшение издержек. В 90% случаев люди с более низким тайтлом наиболее маржинальны, чем люди с более высоким. Как раз поэтому и существует понятие Seniority Pyramid'а, а не перевёрнутая пирамида, ромбик и прочее непотребство. Плюс надо считать маржинальность сотрудников, большое количество дорогих сотрудников с низкой маржинальностью - не лучшая ситуация. Для примера обратимся к одному порталу с ЗП в нашем регионе (информация взята из открытого источника, почему-то в выборке нет позиции senior, поэтому для ориентира взял через позицию - lead):
Js. SE ~ $690
Lead SE ~$3650
Как видим ЗП отличается в 5 раз, поэтому даже учитывая разницу в rate card (очевидно, что за джуна платят меньше), маржинальность на более дорогих профессионалах ниже. Почему не нужно забивать весь проект полностью джунами или полностью сеньорами, рассмотрим чуть ниже.
Проблемы
Утилизация. Людей без опыта сложнее утилизировать. Зачастую сталкиваются с ситуацией, где все хотят сеньоров с вот такущим списком знаний и умений. Никто не знает зачем, но очень надо.
Staffing и Seniority Pyramid'а. Одни джуны в проекте - плохо, не вывезут. Слишком матёрая и звёздная команда - на старте хорошо, в более поздних стадиях плохо, им станет скучно и скорее всего "передерутся". Мне несколько раз доводилось наблюдать со стороны когда на проекты набирались минимум сеньоры, как итог вместо разработки постоянные разборки в стиле чей код лучше и какой паттерн подходит в тот или иной ситуации, но не обсуждение бизнес фичей и их имплементация.
-
Отсутствие наставников и менторов. Как правило людям нравится обучать других, особенно если: это поощряется финансово, не отнимает очень много времени и непосредственное руководство не против.
Финансовую составляющую решить, как правило не представляет проблемы: есть различные, прекрасные инструменты квартальных\полугодовых\годовых бонусов, можно найти и другие способы, оглянитесь по сторонам их множество.
Время наставников - с этим сложнее, нужно подбирать людей, которым это интересно или которые хотят строить карьеру. Это является прекрасным способом для карьерного развития - столько раз объяснял, что сам всё понял(с) -, но не стоит заставлять людей или активно забирать их личное время - выгорят и уйдут.
Интересная ситуация с непосредственным руководством - иногда тимлиды бывают против, мотивируя тем, что упадёт производительность отдельного сотрудника, да и вообще Баба Яга против. Лечится по-разному: бывает достаточно объяснить зачем это нужно компании, проекту, сотруднику. Если человек продолжает упорствовать, можно "скрутить в бублик"(с). Вы спросите: "поменять тимлида на джуна без опыта, чел, ты совсем кукухой поехал?". Теперь внимательно следим за руками - как показывает практика если Баба Яга против, то такой сотрудник уже выгорел, токсичен или уже начинает просто саботировать проект, как правило активное противодействие в проектных инициативах - хороший маркер чтобы присмотреться к сотруднику. Поэтому по итогу: такой лид не выбирается наставником, ангажируем кого-то другого, а за лидом пристальный надзор.
Не переусердствовать. Этот пункт упоминается выше, но подчеркну его ещё раз. Не заставляйте насильно людей и не навязывайте им наставничество. У человека должен быть отклик в душе, заинтересованность чтобы этим заниматься. Предлагайте, мотивируйте.
Как строить процесс
На самом деле многое придумано до нас. Берём за основу модель обучения для людей без опыта - те же университеты, 4-5 лет нам не надо, поэтому ужимаем продолжительность под наши нужды и программу.
-
Выставляем критерии для входа (например):
Нужно ли нам наличие каких-то базовых знаний?
Насколько нам важна быстрая обучаемость?
И т.д.
Согласно списку критериев ранжируем людей и отсеиваем.
-
Тестовое? Я не сторонник тестовых заданий для собеседований, когда нужно писать долго и муторно до того, как позовут на собеседование. Но для людей без опыта тестовое - хороший инструмент, он позволяет:
Понять, насколько человек работоспособен.
Понять человеку что он будет делать и насколько это ему подходит.
Обучаем. Как правило занятия делятся на теорию и практику (лекции и лабы, всё как в университете).
Проверка. Рекомендую проверять как в процессе, так и делать финальную проверку. Например, насколько вовремя человек сдаёт практические занятия и затем выдать какое-то тестовое финальное задание над которым нужно попыхтеть некоторое время.
Успешно прошли все этапы? Отправляем причинять непоправимую пользу.
Дальше уже можно тюнинговать этот процесс:
Иногда делают несколько циклов обучения. Например, человек обучается писать код, потом его доучивают под определённый проект, такой удлинённый onboarding. И обе эти фазы они похожи, различаются: программы и наставники.
Знаю, что есть компании, которые используют различные сервисы для изначального отбора или вместо входного тестового - тот же codewars. Кто-то активно сотрудничает с различными платными и не очень обучающими курсами и вытягивает людей оттуда с минимальной доводкой, кто-то организует свои собственные курсы и готовит людей от и до.
Людей очень часто объединяют в команды и ознакамливают со SCRUM'ом для выполнения практических заданий в ходе обучения.
Если готовят по нескольким направлениям - Dev+QA+BA, то их миксуют вместе и получается задорная команда.
Здесь стоить учитывать основное - по максимуму автоматизируем процесс и стараемся сдвинуть затраты на кого-то другого. ◕‿↼
Отчасти тема уже затрагивалась в моём канале и многие начинают менять свой подход.
Комментарии (200)
anonymous
00.00.0000 00:00
vedenin1980
26.08.2021 18:54+19Тоже что мешает стать водителем, играя в симуляторы автогонщика — это достаточно разные виды опыта.
В пет проект нет ни взаимодействия с командой, ни жестких дедлайной, ни код ревью, ни приоритетов и требований от бизнеса и т.п.
То есть, научится как-то писать код можно, но это лишь очень небольшая часть работы программиста.
ИМХО, часто лучше взять хорошего командного игрока, хорошо умеющего работать с запросами клиентов, соблюдать сроки, умеющего писать понятный код и т.д., чем в разы более производительного (знающего технологии), но который вообще не умеет работать с людьми, код совершенно нечитаемый, постоянно со всеми спорит, не соблюдает никаких сроков и т.д.
raydac
26.08.2021 19:02нанимают ведь не команду, нанимают разработчика и по пет-проекту видно что он умеет, это сразу много больше и выгоднее чем брать "кота в мешке", помню как студент один работу искал в игровой индустрии, он ходил и показывал демку которую дома сделал и она даже какое то место на одном из конкурсов заняла, он был нарасхват
ИМХО, часто лучше взять хорошего командного игрока, хорошо умеющего работать с запросами клиентов, соблюдать сроки, умеющего писать понятный код
если разработчик приходит "голенький" на собеседование, то соответствие приведенным списком требованиям вообще только опытным путем можно будет за свои деньги выяснить
vedenin1980
26.08.2021 19:12+3то соответствие приведенным списком требованиям вообще только опытным путем можно будет за свои деньги выяснить
Не совсем, обычная беседа позволяет выяснить очень многое. Небольшое тестовое задание может показать насколько человек умеет в понятный код. Скажем, любая другая работе (даже чернорабочим на стройке или эникейщиков), тоже многое может сказать о человеке (особенно, если попросить его рассказать о начальнике/коллегах).
Я не спорю, с пет проектов лучше, чем без него, но это не главный критерий. Общая адекватность и умение учится намного важнее.
Graphite
26.08.2021 23:21даже чернорабочим на стройке
Хех, я работал во время учебы, причем фактически за еду - кормили там хорошо да и вообще экономия на еде, однако. Пройдет хайп на ИТ - снова пойду, корона не упадет.
GospodinKolhoznik
26.08.2021 20:16+2Ну вы немножко преувеличиваете масштабы проблемы.
Пет проект можно делать и не в одиночку, а с командой единомышленников. Там и взаимодействие и со сроками команда будет подгонять.
А если человек со всеми спорит, не соблюдает договоренностей, то это просто характер такой и от опыта не зависит.
Smerig
27.08.2021 16:28Ну да, можно еще всяких экхотических условий напридумывать. В итоге окажется, что индустрию движут пет проекты.
GospodinKolhoznik
28.08.2021 09:57Окажется? Оно так всегда было.
Все прорывы совершались в любительских проектах just for fun. А корпорации по большей части заняты тем, чтобы лицензиями обмазываться и друг с другом судиться, им не до развития индустрии.
Fen1kz
27.08.2021 05:12+2Проходил мимо, просто зацепился взглядом:
То есть, научится как-то писать код можно, но это лишь очень небольшая часть работы программиста.
В корне не согласен. Да, нам последние 5 лет промывают мозг важностью софтскиллов, приводя жуткие примеры в виде безумных гениев, которые хорошо знают паттерны и архитектуру, но мямлят исключительно матюгами и оскорблениями.
Но, как правило это не так, и обычный среднестатистический человек без проблем освоит и взаимодействие с командой и дедлайны, и ревью с приоритетами. В то время как хорошо написать расширяемый компонент уже требует специфического опыта, который можно получить в том числе и на пет проекте.
ИМХО, часто лучше взять хорошего командного игрока, хорошо умеющего работать с запросами клиентов, соблюдать сроки, умеющего писать понятный код и т.д., чем в разы более производительного (знающего технологии), но который вообще не умеет работать с людьми, код совершенно нечитаемый, постоянно со всеми спорит, не соблюдает никаких сроков и т.д.
Ага, вот именно, если бросаться в крайности — согласен. Конечно общительный чел лучше хиккана. Только непонятно почему вы "умеющего писать понятный код" занесли в софтскиллы, пет проекты очень помогают развитию понятного кода, особенно когда не "написал и забыл", а через года этак три разбираешь свое же.
ну так вот, если взять без крайностей, речь идет о выборе между человеком который лучше кодит, чем общается, но при этом опрятен, вежлив и приятен в общении или же проактивным супер-инициативным, но неважно кодящим сотрудником, то возникает вопрос- вы точно программиста ищете?
knagaev
27.08.2021 15:52Читал комментарии и хотел ровно то же самое написать, пока не увидел ваш комментарий :)
Тоже не понимаю почему надо противопоставлять хард и софт скиллы.Мне кажется, наоборот - если человек пишет красивый код, то и одеваться может опрятно, и общаться, и вообще в жизни порядок вероятнее.
Экзотические экземпляры паноптикума IT - это какая-то мифология, как бухгалтеры из анекдотов.
vedenin1980
27.08.2021 17:13+2почему надо противопоставлять хард и софт скиллы.
Для начала, софт скиллы очень размытое понятие, одни понимают под этим душу компании, который квасит со всеми каждый вечер, другие просто адекватного человека.
Я бы говорил не о софт скилах, а умение работать в команде, понимать требования заказчика, адекватно общаться с тестировщиками, клиентами, коллегами, ответственность и т.д. Черт с ним, как человек одет и что сидить у себя в уголке, не с кем не обшаясь кроме работу, не это основное для работы в команде…Экзотические экземпляры паноптикума IT — это какая-то мифология
Полбеды если человек интроверт и общается коротко и по делу или носит кильт с майкой-алкоголичкой на работу. С этим вполне можно работать адекватному тим лиду.
Хуже, если он не отвественный, не принимающий критику, фанатик каких-нибудь технологий, упрямый или считающий себя самым умным или хитрым, либо просто слишком ленивый.
Увы, по своему опыту обучения начинающих, я бы сказал, что среди тех кто вообще в первый раз в жизни работает — адекватных от силы половины.
Это сложно понять тем кто давно работает. Банально приходить на офис в указанное время и уходить не раньше чем через 8 часов — для бывшего студента/школьника, привыкшего забивать на пары, не то чтобы подвиг, но что-то героическое в этом есть. (с)
Crafter2012
30.08.2021 17:48умение работать в команде, понимать требования заказчика, адекватно общаться с тестировщиками, клиентами, коллегами, ответственность и т.д.
Это вообще-то и есть soft skills. Скилы работы с другими людьми.
vedenin1980
30.08.2021 18:00+1Да, но понимаете есть 2 вида софт скилс (если говорить о обычной позиции, без ролей менеджера/начальника — там свои навыки):
1. Софт скилс продажника — умение продать что угодно, делать презентации, войти в доверие, работать с клиентами/боссами, быть душой любой компании и т.п.
2. Скилы командного игрока — тут человек может быть и закомплесованным, зажатым, но при этом адекватно общается (по делу с другими ИТшниками) — хотя в почте/мессанджерах, понимает требования заказчика и может объяснить свои идеи, написать понятную документацию, способен принимать критику и менять свою позицию,
Это достаточно разные навыки — более того человек может быть отлично уметь продавать свои идеи, но совершенно не способным воспринимать критику или быть способным менять свое мнение (некоторые навыки командного игрока могут быть даже вредными для продажника — например, способность поменять свое мнение при определенных аргументах).
Для программиста неплохо иметь скилы из первой группы (но в принципе, можно быть отличным специалистов и без них), но жизненно необходимо из второй.Crafter2012
30.08.2021 19:00Да, на разных позициях нужны разные наборы из soft skills. Так же как и на разных позициях - нужны разные наборы hard skills, например backend умеет в базы и т.д, а fullstack знает browser api - но и то и другое это hard skills. Но есть общие для всех пересечение - алгоритмы и структуры данных, или git там.
Так же и с софт скиллами, их много разных, все что связано с работой с другими человеками это категория мягких скиллов.
Разделение, которое даете вы - ролевое, но чем, например, навык продать новую технологию команде - это навык продажника, а не командный навык для tech lead ? Границы очень размыты, и разделение по ролям, скорее путает.
dikey_0ficial
27.08.2021 09:18на эту тему я как-то видел по телевизору эксперимент — людям давали играть в симуляторы гонщика и дальнобойщика на протяжении двух недель, а затем давали поездить по-настоящему. В итоге с инструктором "гонщик" проехал трассу, а "дальнобойщик" перевёз груз
beeruser
27.08.2021 17:36Тоже что мешает стать водителем, играя в симуляторы автогонщика — это достаточно разные виды опыта.
Интересно, что же мешает? Я вот не вижу особых отличий в технике управления (как человек который участвовал в любительских соревнованиях по автоспорту).
Пилоты самолётов сначала тренируются на симуляторах.
Профессиональные автогонщики тоже тренируюся на симах.
Как это работает: симулятор Red Bull Racing (motorsport.com)
Существует GT Academy - проект по переходу геймеров в профессиональный автоспорт.
Meet the Gran Turismo Player Now Driving Race Cars for Real - GameSpot
kotandvla
27.08.2021 06:55+2Человеку без опыта крайне сложно придумать - а чем себя занять то. Т.к. опыта нет, нет и широкого взгляда на мир - и нет понимания проблем, какие можно решить петом, даже пусть и во второй раз.
MacIn
27.08.2021 13:39+1Во второй раз просто не всегда интересно решать что-то, особенно если понимаешь, что это точно работа в стол.
Насчет петов вообще забавно. Почему у токарей при приеме на работу нет диалога типа: «вы в свободное от работы время читаете книги, катаетесь на велосипеде и играете в шахматы, а не точите валы по приколу на своем домашнем станке? Да вы нам не подходите, если вы сами для себя работу не делаете, то и для нас не будете!» — ведь сегодня хоббийное оборудование можно разместить даже в квартире.GreyStrannik
27.08.2021 14:16+1В токари нанимают джунов, не окончивших профильное ПТУ? При найме токаря тестовое задание или первый день не показывает всё, что умеет новичок?
artemt
27.08.2021 15:06+1Ну как же, помню, как Егор Тимурович Гайдар говорил, что ПТУ нам не нужны. Государство не должно их содержать, их надо закрыть. Опираться же на рыночные механизмы. Если бизнесу потребуются токаря, то этот бизнес сам создаст нужные ему ПТУ и будет обучать специалистов.
fzn7
27.08.2021 16:15+130 лет спустя бизнес в РФ продолжает нещадно эксплуатировать трудовые ресурсы не обращая внимания на необходимость вкладываться в возобновление человеческого капитала. На волне демографического кризиса начинают рождаться подобные статьи с попыткой переосмыслить эти людоедские практики, что приятно
MacIn
27.08.2021 16:50+1Подождите, программист обучается в колледже или ВУЗе, токарь — в ПТУ. При найме программисту еще тестовое дадут, тогда как токаря примут по корочкам, а потом будут смотреть, как он себя покажет на испытательном. Т.е. здесь у токаря тоже преимущество. Про пет-проджекты — речь шла о любых программистах, не только джунах с курсов. Обычно на этот вопрос парируют тем, что мол в других профессиях для деятельности нужна организация или оборудование. Но вот в такой сфере, как металлообработка, вполне могут быть «домашние» проекты. И тем не менее, позиция «мы не наймем токаря, если он дома не делает хоббийные проекты — ведь раз он не хочет делать для себя, он и на нас работать не будет» выглядит дико. Почему же инженеров-программистов так пинают?
GreyStrannik
27.08.2021 22:05-1В России программист обучается дома или на рабочем месте. Причём хорошо обучившийся дома джун требует для превращения в мидла ещё года два на производстве. В каких-то компаниях есть для них работа и тогда их находят, просеивают и берут.
В большинстве компаний банально нет задач для джунов. Да, иногда кажется, что вроде объём работы есть, но начинаешь разбираться и понимаешь, что 3-5% этой работы имеет повышенные требования и её не отделить от остального "джуновского" блока - и берёшь мидла.
В общем, место джуна - на "галере". Там из него за 3-4 года сделают хорошего разработчика. Это давно известная истина, которую многие не хотят принять.
По поводу же образования и найма людей, вышедших из ВУЗов опять буду банален. Я видел много хороших программистов, окончивших информационные факультеты топовых ВУЗов, но все эти люди самоучки и ВУЗ ничего или почти ничего не дал им в плане профессии. Им дают большой объём знаний, но эти знания в реальной работе не нужны.
А вот важных навыков им не дают. Например, им не дают навыков борьбы с ошибками. Как не дают им навыков работы с шаблонами проектирования, фреймворками (как классом инструментария), базами данных, таск-трекерами, стилями кодирования, другими разработчиками. Они умеют программировать сложные эффективные алгоритмы, но в фреймворке тонут - он ведь большой и сложный. Они знают теорию оптимизации расчёта кривых, но не могут писать Unit-тесты. Их учат быть учёными, а в работе от них нужно писать CRUD-ы с валидацией значений и перекладкой данных между системами, базами и очередями.
MacIn
28.08.2021 03:03+1Вы написали очень много, но совершенно отвлеченно, можно было короче: «токаря учат всему и так, а программистов — никак».
Токарь также мог отучиться в ПТУ спустя рукава, еле-еле на тройки. Я повторю:И тем не менее, позиция «мы не наймем токаря, если он дома не делает хоббийные проекты — ведь раз он не хочет делать для себя, он и на нас работать не будет» выглядит дико. Почему же инженеров-программистов так пинают?
Токаря проверят на испытательном, программиста — тоже. А вот этот барьер с пет-проектами — есть только у программистов. Я повторю еще раз: речь шла не о петах, как дополнительном свидетельстве квалификации, а именно в виде «должен сам хотеть, должен сам гореть, иначе он и у нас в конторе работать на будет (т.е. будет просиживать штаны)». Т.е. программист для такого нанимателя — это машинка, которая должна 24/7 думать о работе. А если у тебя еще и жизнь есть — значит, ты не такой какой-то. Почему у токаря не так?Как не дают им навыков работы с шаблонами проектирования, фреймворками (как классом инструментария), базами данных, таск-трекерами, стилями кодирования, другими разработчиками
Дают. Шаблоны — это есть в курсе про углубленное ООП; курс по базам данных — один из самых серьезных, в том числе по практике. Стиль кодирования — еще с первого семестра, работа с другими разработчиками — групповые задания.Vilaine
28.08.2021 06:56Да ладно токаря, для всех специалистов с высшим образованием считается нормой получить сначала самые широкие теоретические знания (и отсев если будет, то именно по этим в основном теоретическим знаниям), а уже потом считатся, что он начнёт получать реальный опыт с начальных должностей. Медики, инженеры, юристы, все так. Кто из них в свободное время вечером должен получать практический опыт (а не углублять знания)? Я думаю, разработчиков просто очень много, особенно на вайтишников — ставки велики. Вот и фильтруют хоть по каким метрикам.
MacIn
28.08.2021 18:00Вот и фильтруют хоть по каким метрикам.
Так это подходит под «посмотреть на петы, как примеры его работы, его квалификации». А разговор шел о том, что если человек не горит профессией 24/7 и не точит дома валы и втулки — то он «не такой» и такого брать не будем. Принцип галеры, пмсм — выжать в ноль и выбросить, когда выгорит.
Alexrook
27.08.2021 20:16+1По своему опыту напишу, с какими проблемами столкнулся при выборе пет-проекта. Изначальная хотелка лишь одна - чтобы это было хоть кому-то нужно. И речь не о миллионах благодарных пользователей, а хотя бы о паре десятков.
Но когда начинаешь копать ту или иную тему, во-первых, кажется, что все, чтобы ты не придумал, уже есть. Иногда погуглив буквально пару минут, ты уже видишь, что ту или иную проблему уже решили на каждом популярном языке, а то и не раз. Во-вторых, ты понимаешь, что твой «говнокод» (я реально смотрю на мир) не сделает твое решение лучшим и даже не приблизит его к оным. Даже если ты находишь какую-то нишу, то как правило, она тебя не очень интересует, да и 99% людей. Это обычно что-то очень узкоспециализированное. Если ты и находишь какую-то потребность со стороны пользователей, то обычно речь идет о каким-то серьезном продукте, который в одиночку просто не потянуть. В результате ты изобретаешь велосипед, то есть делаешь то, что никому не надо. Мотивация падает с каждым новым днем работы над таким проектом и чаще всего ты его даже не заканчиваешь. А опять возвращаешься просто к маленьким экспериментам для закрепления пройденного материала. Понятно, что это тоже полезно, в этом случае ты никогда не получишь опыт построения архитектуры более-менее крупного проекта.
В результате плюнул на желание устроиться разработчиком. Пошел в очередной раз на обычную работу. И уже реализовал первый работающий пет-проект, который реально пригодился коллегам и сэкономил кучу времени. Жаль только что никто не может оценить, показать на ошибки или наоборот похвалить, так как мои коллеги не связаны с IT миром и могут только выразить свое мнение следующим образом - «Ух ты, работает, а мы хотели вручную все это делать». При всех минусах, ощущения совершенно другие. Все-таки, когда знаешь, что работаешь не просто так, а на чью-либо пользу, появляется и мотивация и желание. В этом случае не просто доделываешь проект, но еще и стараешься его всячески улучшить, хотя тебя уже останавливают и твердят - «Да ладно, ладно, и так хорошо, большего и не надо».
Остается ждать еще подобных моментов, когда твои знания в разработке могут кому-то пригодится.
Забыл еще один момент, который останавливает. Это то, что чтобы раздать даже бесплатное приложение для той же iOS (были неплохие идеи именно мобильных приложений, которые я могу сделать более качественными и удобными, чем уже имеющиеся бесплатные), будь добр, заплати $100 баксов. И ладно, если бы это был разовый платеж. Каждый год отдавать по сотне просто за возможность представить свои бесплатные приложения людям… такое себе.
GospodinKolhoznik
28.08.2021 17:58Да, так. Причем по хорошему это должен быть опыт работы в реальном секторе. Ну я имею ввиду, что если человек делает на работе сайты, то скорее всего ему придет в голову делать пет проект новый фреймворк для сайтов, которых и так как грязи. А вот тут был на днях пост о по, которое по показателям каких то датчиков определяет степень износа двигателя жд локомотива. Человек, всю жизнь делающих веб сайты в жизни до такого не додумается.
nmrulin
27.08.2021 11:23Ну код такого самоучки будет малопонятен другим и в целом плох, т.к. будут отдельные фрагменты когда которые работают, и автор в них давно не глядел. Либо наоборот автор будет помешан на чистоте кода. Дальше пет проекты тяготеют к средствам разработки вроде Delphi , а бизнесу нужен Rust . Ну хорошо, человек будет специально кодить на Rust свой пет-проект. Но так как у него цели других , он будет всё равно создавать по другой логике и для других целей, чем бизнес-проект.
raydac
27.08.2021 11:46+3его код будет думаю лучше чем код того кто вообще ничего не делал и только "теоретически что то знает", так как штука всеж практическая и главное что этот код будет видно, а не придется с ним ознакомиться "только после найма", так же будет видно и сделанные решения и главное что будет еще и что обсудить на собеседовании
x67
27.08.2021 12:59Зависит от самой деятельности зачастую, но на пет проектах чаще всего нет вызовов, которые приходится принимать в реальности, поэтому даже до мидла вырасти очень тяжело. С другой стороны наличие своих осмысленных (это очень важно) проектов, а не дефолтных с янде с практикума, говорит о перспективности кандидата.
Vilaine
28.08.2021 00:35-1Что за пет-проекты у каждого разработчика, да ещё и во множественном числе?
Лучшая возможность написания открытого кода, которую можно предложить случайно взятому разработчику — это исправление известных багов в публичных проектах. Пет-проекты ради пет-проектов не нужны. Если нужна отсутствующая в природе, но реалистичная функциональность — то да, но не более.
Расти эффективнее всего — на работе. Отличиться начинающему лучше всего теоретической выучкой. Так во всех прикладных областях (инженеры, медики, юристы), с чего бы программирование как-то отличалось? Мой совет начинающим был бы расти вширь как можно больше на книгах и курсах, и с этим идти на собеседования. Но из-за обилия неадекватных интервью совет не очень рабочий, по-видимому.
Bellerogrim
26.08.2021 18:49+5"В наши дни одна из самых больших проблем для IT специалиста — начать профессиональную карьеру" — наши дни это последние 20 лет имеются в виду, верно?
rinat_crone
26.08.2021 19:35+2не знаю, у кого как, но у меня и 20 лет назад очередь стояла из клиентов (это мне 13 лет было, на секундочку). Пет проекты рулят, как тут верно ребята выше говорят.
Pavel1114
27.08.2021 04:07-1Поддерживаю. Проблема немного преувеличена. Её не то чтобы нет, но, если сравнивать с другими профессиями, она незначительна. В IT в крайнем случае можно какое то время поработать во фрилансе, а рынок труда не ограничен родным городом.
st__shadow
27.08.2021 11:41+1Таких как вы - один на 100. Из этой сотни пет-проект будет у 10, и у 8 из этих 10 - лучше бы его не было.
А мне из этой сотни нужно ну скажем 20 человек набрать (мы каждый год набираем пачку джунов собственно, чтобы растить себе сеньёров-помидоров). Так что пет-проект хорошо, но иногда хорошее знание теории (язык, паттерны, и как бы это не банально звучало - алгоритмы) ещё лучше.
raydac
27.08.2021 00:48+3начать карьеру в ИТ было сложно в середине 90-х, тогда конторы были еще забиты народом выброшенным из ВПК и средний возраст разработчиков был лет под сорок, так что легко до собеседования можно было ждать месяца три, но с начала 2000-х спрос был взрывной (со спадами на лопанье дот.комов и финансовые кризисы) и рынок в целом работника, а не работодателя
Mephistophele Автор
27.08.2021 11:43+1Для людей без опыта, но даже с профильным образованием - всё так же сложно.
Вы рассуждаете про рынок опытных людей, здесь бесспорно рынок сотрудника, а не работодателя.
raydac
27.08.2021 12:52есть много маленьких контор "рога и копыта" где можно получить год+ опыт и строить карьеру последовательно за копейки, но забываем озвучить основную реальную проблему - "как начать карьеру без опыта, сразу получая денег как с опытом", на деле в это ведь упирается, а не в отсутствие мест
Mephistophele Автор
27.08.2021 13:17Есть компании - рога и копыта, они берут за пачку дошика. В статье я нигде не говорил: "ой не идите туда" или про "желание многа и сразу зарабатывать". У нас даже такие компании с пачкой роллтона (про дошик я молчу, ибо это дорага-богата) хотят нанимать только сеньоров.
flashmozzg
29.08.2021 15:07Хм, может в некоторых регионах и так, но в Питере точно ситуация не такая. Из всех однокурсников/одноклассников ни у кого не было проблем с поиском работы. Один даже просто в один день забил полностью на универ (3 курс) и уехал в Амстердам.
snuk182
26.08.2021 21:48+2Классика - один программист решит задачу за один час, два программиста - за два часа, и так далее.
SadOcean
30.08.2021 13:34Похожий эффект может быть, но тогда через пол года у тебя не будет второго такого человека
Кроме того, концептуальная проблема - что один такой человек хоть и показывает, условно, 100% эффективности, его нельзя смасштабировать на 200% никак
Если же с масштабированием люди будут показывать пусть и меньшую эффективность, но показывать, то набрав еще 1 ты получишь 130%, набрав 2-х - 150% и т/д, набрав команду - все же получишь требуемые 200%, пусть и ценой усложнения коммуникацийvedenin1980
30.08.2021 13:45Есть вторая, концептуальная проблема, положим 1 крутой супер ведущий программист выдает столько же производительности (100%) сколько 5 мидлов, при зарплате 2 мидлов. Казалось бы бизнес экономит 3 зарплаты мидлов (или в 2,5 раза меньше тратит на ту же производительность), но…
Но стоит этому программисту заболеть, уйти отпуск или уйти из компании и его производительность станет 0%, а если потеря 1 мидла из 5 и производительность будет 80% (или даже больше, так как на короткое время они могут работать продуктивнее), плюс намного легче будет восстановить знания и умения, что легко может окупить в 2,5 раз более высокие траты на зарплату.
Поэтому часто бизнесу выгоднее платить больше, но снизить bus factor. Опять-таки найти нового обычного мидла или обычного синьора на рынке труда — просто, а вот супер-пупер звезду с производительностью в 5x — очень сложно.
mphys
26.08.2021 19:00+4У нас на работе есть такое понятие, что "не все должны быть академиками", как раз по той причине, что академики между собой подерутся. Количество ведущих инженеров (в руках которых выработка концепций, принятие решений и отвественность за эти решения) должно по минимуму или с небольшим запасом перекрывать количество текущих проектов, остальные люди должны быть просто "руками", руки при этом бывают для черновой работы ("джуны", или среди конструкторов те, кто просто чертит, пишет, паяет, собирает, вносит правки и делают другую нудную конструкторскую работу, которой в практике конструирования может быть больше половины), бывают "руки" для чистовой работы ("мидлы", или среди наших конструкторов те, кто в рамках проекта может самостоятельно вести какую-то подсборку). Если все будут излишне амбициозные, то принимать решения можно будет только по результатам дуэли, по другому не договориться.
Такой подход удобен всем - мелкие набираются опыта, смотрят на старших и растут, старшие не отвлкаются на рутину и используют свой ментальный ресурс на решение реальных проблем.
Akon32
26.08.2021 20:54-2О, это ещё в "Мифическом человеко-месяце" было. В команде 1 главный программист, 1 программист-помощник, и человек 7 "свиты" - всякие документоведы (которых сейчас системы контроля версий заменили). Думает одна голова, остальные помогают делать.
Ktator
26.08.2021 19:35+4Утилизация. Людей без опыта сложнее утилизировать.
В крематории людей без опыта ничуть не сложнее утилизировать. Кстати, на обычном кладбище тоже. Проблема решена!
Wan-Derer
27.08.2021 14:00+1Чтобы джуна утилизировать, его надо сначала декомпозировать. И то, и другое - уголовка. Не делайте так, пожалуйста!
symbix
26.08.2021 20:32+4Вы, конечно, извините, но попахивает не умозаключениями менеджера проектов, а страданиями очередного желающего «войти в айти, потому что там много платят»: «я окончил шестинедельный курс, почему меня не берут в Netflix?»
Есть куча компаний, которые и джунов нанимают, и стажеров. А Netflix, судя по их капитализации, не нуждается в советах со стороны.
Mephistophele Автор
26.08.2021 20:59+1Netflix - edge case, я в статье указал что они могут себе позволить + краткая выжимка про бабло в моём канале, я запасусь попкорном и буду наблюдать.
Таких компаний с капитализацией как у Netflix'a - раз-два и обчёлся, а компаний с понтами круче чем у нетфликса - чуть ли не каждая третья.
Не брать джунов без опыта и потом страдать от нехватки кадров - очень распространённая менеджерская болезнь, наверное по статистике поспорит с геморроем. Людей которые понимают зачем брать джунов без опыта - в разы если не на порядки меньше. И статья в первую очередь писалась для менеджеров, чтобы поменять их мировоззрение.
symbix
26.08.2021 21:30+7Стартапу как раз выгодно нанимать сеньоров, причём не бумажных, а настоящих. Потому что платить ему раза в три больше, а его производительность выше в 10 раз (на эту тему у Джоэля, кстати, тоже было где-то).
А проблемы роста обычно связаны прежде всего с неумением эффективно масштабироваться, которое приводит к избыточному найму; вспоминаем кейс с Xsolla: если они могут уволить 150 человек и ничего не встанет колом - то нахрена их нанимали-то? А когда вместо 5 человек начинается найм 50, которые в итоге делают ту же работу - ну, да, тут одними сеньорами не обойдёшься, это очевидно. Что-то мне подсказывает, что Netflix давно прошёл кризис роста и эффективно масштабироваться умеет.
Mephistophele Автор
26.08.2021 22:35Стартапу - выгодно. Netflix - не стартап.
Netflix масштабируется как и Google - за счёт огромного количества бабла, не денег, а именно бабла. Они эффективны? Возможно да, а возможно и нет, просто доходы настолько умопомрачительные что можно сорить деньгами налево и направо. Притом эффективность и доходы тут слабо связаны, они прочно заняли нишу по созданию уникального контента, как когда-то Google со своей рекламой. Опыт Google показывает что бизнес модель у них прибыльна, но не эффективна, если посмотреть на их проекты за последние 10 лет, успешных и прибыльных очень мало. Они вытягивают за счёт рекламы.
Да и зачем Netflix'у выстраивать процессы, если можно кинуть денег значительно выше рынка, выстроить корпоративную культуру соковыжималки и драть во все щели за невыполнение показателей и сроков. Отличный подход, но нужно немерено денег.
XSolla - продуктовая компания, они просто посчитали эффективность своих сотрудников и выпилили неэффективных. Обычная оптимизация расходов. У них прибыль не зависит от head count'a, поэтому их поведение вполне логично, эффективно и прагматично.
symbix
26.08.2021 22:57+4Про стартапы было в контексте кучи компаний с понтами. Уж кто больше всех понтуется так это стартапы.
Про ксоллу - для того, чтобы выпилить 150 неэффективных сотрудников, надо сначала нанять 150 неэффективных сотрудников. А если неэффективных сотрудников порядка 20% (я вообще не понимаю, куда им столько, это сраный платежный агрегатор, типичный бесконтрольный найм после инвестраунда), то в консерватории что-то не так.
Давайте ещё раз. То, что хороший сеньор зарабатывает в 3-4 раза больше джуниора, а его эффективность в 8-10 раз выше, мы уже установили. Спрашивается, зачем нанимать не сеньоров? Единственная причина - потому что столько сеньоров хрен найдёшь. Тогда тут есть два варианта: обходиться меньшим числом разработчиков, не распыляясь на все подряд, либо нанимать кого попало и стараться растить. Во втором варианте ваши рассуждения справедливы. Но куда эффективнее пойти по первому пути. Если получится, конечно. У Гугла не получится, они слишком большие, ну так они и нанимают всех подряд. У Нетфликса, видимо, получается. А ксолла могла бы пойти по первому пути, но пошла без явной нужды (сраный агрегатор, Карл!) по второму, результат мы видим.
300KpS
26.08.2021 23:27+1Единственная причина - потому что столько сеньоров хрен найдёшь.
Не единственная, если вы читали что-то по программной инженерии. Там же сказано следующее - любой большой, сколь угодно инновационный продукт содержит в себе много рутинных, простых, но объёмных задач. И вот какое дело - во-первых, сеньорам не интересно "формочки клепать и json'чики перекладывать", во-вторых, даже если и было бы интересно, зачем их, дорогих специалистов, пускать на выполнение этих задач, если с этими же задачами справятся менее опытные и более дешёвые разрабы. А потом эти же люди, набив руку, имеют шанс трансформироваться в более опытных
symbix
26.08.2021 23:44+1Смотря что за проект. Если таких задач 90%, то конечно. В какой-нибудь сраной студии так и есть. Но там и сеньор не нужен. А в продуктовой разработке такого не особо много и сеньору проще это сделать за 5 минут (а при грамотной архитектуре так и будет), чем ревьюить и учить джуна.
Понятно, что есть всегда всякая фигня, типа блога на вордпрессе, но там и роста не будет. Да и аутсорсить такое надо.
Короче, мифический человекомесяц, уже тут упоминали.
sshikov
27.08.2021 12:11>Смотря что за проект.
Ну да.
>А в продуктовой разработке такого не особо много
Зависит от продукта. Форм вполне может быть много, и с этим ничего не сделаешь. И там может быть достаточно тривиальная логика типа валидации, которую вы не сделаете раз и навсегда для всех полей всех форм. За пять минут — это одно поле, а если их сотни — то это уже 500 минут. И она в общем случае не поддается кодогенерации, потому что все равно поля-то разные, и где-то так или иначе нужно описать, что делать с каждым. Упростить это можно, а вот убрать совсем — я не знаю такого способа.
>Да и аутсорсить такое надо.
А что это меняет? Все равно аутсорсеров должен кто-то направлять.
dimkrayan
27.08.2021 00:03+1про рутинные задачи - отчасти, если это бойлерплейт - можно воспользоваться кодогенерацией, фреймворками, а если просто дублирование кода - может, пора рефакторить?
Shatun
27.08.2021 14:38-1Была задача переписать отчеты с делфи на веб. Каждый отчет это несколько десятков параметров входных, несколько десятков полей в отчете. Отчетов этих штук 30-40. Даже если тратить по 1 дню на каждый, то это порядка 2 месяцев.
Невижу смысла держать сеньоров на этой задаче, у них будет сравнимая производительность с джунами, особенно после первых 3-4 отчетов.
S-e-n
27.08.2021 16:27А скриптом нельзя?
Shatun
27.08.2021 16:38+1Была форма на делфи+какая-то делфовая либа для для отчетов. Стал сайт+birt для отчетов.
Нужно 2 скрипта-первый который перегоняет делфовые формы на веб, валидацию для полей из делфи на js. Не слышал о таком конвертере, выглядит как очень нетрививальная задача.
Второй для перегонки из формата отчетов определнной либ в биртовый формат отчетов. Уверен что такого нету. Думаю на его написание уйдет больше времени чем на создлание отчета.
Т.е. по-моему мнению, нет, задача конвертации и тестирования значительно объемнее чем создание отчетов заного, я бы не был готов взять написать и оттестировать это за месяц.
Mephistophele Автор
26.08.2021 23:39+2Давайте ещё раз. То, что хороший сеньор зарабатывает в 3-4 раза больше джуниора, а его эффективность в 8-10 раз выше, мы уже установили.
Воу-воу-воу. Полегче с цифрами. Я конечно понимаю что статистика - та ещё продажная девка, а
комменты на хабребумага всё стерпит, но нет. Как правило эффективность коррелирует с ЗП. Поэтому если сеньор получает в 4 раза больше джуна, то и эффективнее он будет где-то в 4 раза. Я, кстати, не понимаю зачем пытаться меряться цифрами которые никто не мерял и нет точных данных, да и выборок\исследований никто не проводил. Поэтому давайте согласимся на том что: "сеньор эффективнее джуна".Единственная причина - потому что столько сеньоров хрен найдёшь.
Я бы сказал это одна из причин. КМК там их целый ряд: и хрен найдёшь, и они дорожают, и на всех не хватит, и со временем закончатся. Пожалуй ограничусь одним словом - дефицит.
Тогда тут есть два варианта: обходиться меньшим числом разработчиков, не распыляясь на все подряд, либо нанимать...
It depends как говорится. Если у вас стабильно движущийся продукт, который эволюционирует себе спокойно, то да, ваши рассуждения верны. Аутсорс - сразу мимо, там рост прибыли на headcount завязана. Если вернуться к активно растущим компаниям, они просто упрутся в потолок: просто включите воображение и представьте, Netflix вычерпал всех сеньоров с рынка (понимаю что это невозможно, но предлагаю просто представить), новых сеньоров никто не готовит; всё, компания упёрлась в потолок своего развития, они не могут дальше генерировать рост прибыли. Понимаю что ситуация в принципе невозможна, но когда-то и полёт в космос был за гранью фантастики, а то и вообще на костёр можно было угодить.
нанимать кого попало и стараться растить
Звучит не очень. Не знаю как у вас, но у нас студентов профильных ВУЗов брать не хотят. Понимаю что студент - сомнительное вложение, но я как человек преподававший, могу сказать что там очень много толковых и умных ребят. Я пожалуй останусь в этом плане оптимистом, т.к. у меня был очень положительный опыт.
А ксолла могла бы пойти по первому пути, но пошла без явной нужды (сраный агрегатор, Карл!) по второму, результат мы видим.
У вас какие-то личные счёты к ним? XD
flashmozzg
29.08.2021 15:19+1Поэтому если сеньор получает в 4 раза больше джуна, то и эффективнее он будет где-то в 4 раза
Есть задачи, для которых сколько джунов ни добавляй, быстрее качественный результат не получишь.
Mephistophele Автор
26.08.2021 23:45Спасибо вам. Вы подкинули мне идею для одного интересного исследования.
Поэтому если сеньор получает в 4 раза больше джуна, то и эффективнее он будет где-то в 4 раза. Я, кстати, не понимаю зачем пытаться меряться цифрами которые никто не мерял и нет точных данных, да и выборок\исследований никто не проводил. Поэтому давайте согласимся на том что: "сеньор эффективнее джуна".
Учитывая что у меня есть доступ к разным портфолио проектов с хорошими метриками эффективности + если наложить это на финансовую составляющую, получится хорошее исследование. Понятно что детали не опубликую, NDA, но финальные цифры - интересно будет глянуть. Ловите плюс в карму вам за идею. :)
symbix
26.08.2021 23:53+3Про «в 10 раз» я по своему опыту утверждаю. Более того, крутой senior в разы эффективнее среднего. Я работал в куче проектов как внештатный специалист, и разницу эту видел неоднократно.
Как вы будете это исследовать, я не знаю. Очень сложно придумать адекватную метрику. Топовый специалист отличается тем, что он не поленился вникнуть в domain, сходу поймёт проблемы постановки задачи, сразу задаст правильные вопросы, при этом видит не тупо код, открытый в ide, а понимает высокоуровневую и низкоуровневую архитектуру проекта, и решит задачу оптимальным образом в короткие сроки. Тут как в том анекдоте, когда 1 доллар за удар кувалдой, и 99 за знание куда ударить.
Встретить такого специалиста на проекте и поработать с ним - огромное счастье. Там, где обычно подолгу объясняешь свои идеи, с такими людьми понимание с полуслова. И сравнить с другими сложно - они-то вон кучу кода написали, куча колов была, куча переписок, бурная деятельность, а этот просто нашёл эффективное решение с минимумом трудозатрат и реализовал небольшим объемом кода. Как понять, было ли такое решение для вышеупомянутых задач?
Mephistophele Автор
27.08.2021 00:30Вы мне сейчас не сеньора описали. В моей картине мира - это такой уже матёрый архитектор, такие понятно что в 10 раз эффективнее будут, но и они - штучные экземпляры, да и зп у них будет раз в 10 больше чем у джуна, а то может и поболее. Так что про корреляцию опыта и ЗП, КМК я ближе к истине. XD
В статье и в рассуждениях я всё таки опирался на опытных разработчиков. Для меня сеньор - человек с 3-7 годами опыта, знающий досконально один (максимум три) ЯП и умеющий очень хорошо в пару тройку смежных технологий. Это очень высокоуровневое описание, но думаю для контекста - достаточно.
symbix
27.08.2021 00:47+2Архитектор - это такой термин, сложный. Видится такой чувак, который занимается paperwork-ом, пишет спецификации, по которым кодят индусы в Бангалоре. Это не для каждого, дятел должен долбить, иначе нет смысла в жизни дятла. По факту почти все такие чуваки, с которыми я пересекался, были формально senior-ами (иногда тимлидами). И самые эффективные команды, которые я видел, состояли из пары таких чуваков, пачки generic сеньоров, ну и может миддла-другого на задачи, которые не то, что попроще, а скорее несрочные.
PleaseKING
27.08.2021 06:00Всегда интересовало, а кто же тогда те, у кого 15-20+ лет опыта? А их вообще-то очень много, средний возраст программиста не 23 года :)
То есть как бы странные критерий очень.
ryanl
27.08.2021 11:44Уровень квалификации - это количество скилла, а не количество отработанных лет.
Промежуток времени в 5-7 лет я бы рассматривал как усредненный показатель, когда специалист выходит на уровень квалификации сеньора, сохраняя при это энтузиазм. 90% уверенности, что для всех, кто работает более 10 лет, работа - это уже просто плавание по течению, где много рутины, и опыт собираешь по крупицам.
Если, конечно, ты не меняешь стек и развиваешься экстенсивно. Да и смена стэка, надо полагать, дает временный эффект, особенно, когда за плечами опыт более 5-7 лет.
PleaseKING
27.08.2021 19:18Ну я бы сказал, что сеньор, который знает только один стек, - это очень специфический такой сеньор, не уверен, что он им является, узкий специалист подобен флюсу. Может, у меня ожидания завышены, но для меня сеньору стек должен быть в некоторых пределах не важен - хоть что делать, быстро и хорошо. Скорее предметная область может быть важна. А для этого надо в жизни разное попробовать, и 5-7 лет тут мало.
sshikov
27.08.2021 17:09Ну вот хотите пример? Была у меня как-то на проекте задача сделать отчеты, которые бы генерировались в Word. И работа над ней выглядела так — ее дали человеку, формально архитектору, а по факту — опытный разработчик. Он ее мусолил месяц, и выдал что-то невнятное, непригодное к применению. Выдал мне — чтобы сделать прототип отчета.
Я это честно выбросил, и взял просто готовый компонент, которых к тому времени в интернете было штук пять пригодных для нашей платформы (я просто знал, что они уже лет 10 как существуют). И за два дня прикрутил к проекту, и сделал прототип.
Как вы оцените разницу в нашей эффективности? Раз в 15 же, не меньше, правда? Я за два дня сделал тоже самое (взял готовое), что другой человек за месяц сделать не смог как следует. При этом предложенное мной решение было лучше по многим параметрам, т.е. сэкономило компании много денег еще потом, на следующих этапах.
И заметьте — это всего-лишь играл роль мой опыт. Т.е. я даже ничего не программировал, ну там написал строк 30 интеграции, не более. Я просто знал решение заранее, потому что сталкивался с такими задачами в каждом втором проекте ранее.
Так что я бы допустил, что на конкретной задаче матёрый синьор с опытом может быть эффективнее вообще в любое число раз.symbix
28.08.2021 08:47Опыт работы с каким-то конкретным решением может оказаться у любого, это может быть ситуация «просто повезло».
Senior в таком случае, даже не обладая информацией, предположит, что решение задачи в обобщенном виде уже существует, за пару минут нагуглит и ещё за пару минут оценит нагугленное в контексте пригодности к решаемой задаче. Да и хороший middle уже должен это уметь.
У меня был случай из немного другой серии, но в чем-то похожий. У разработчика, нанятого для написания клиента к серверному АПИ на еще одном языке по существующей документации и референсной имплементации на другом языке, была подзадача, которую он стал решать с помощью одной относительно известной библиотеки, которая архитектурно гибкая и расширяемая, но очень слабо задокументированная несмотря на многолетнюю историю. Разработчик несколько дней провозился с написанием обертки вокруг этой библиотеки, написал много кода, не очень получалось, и начал жаловаться, просить изменить серверный АПИ. Я хоть и библиотеку эту раньше не видел, и вообще на этом языке программирования почти не писал, просто погуглил (сначала, конечно, посмотрев в исходники библиотеки, чтобы сформулировать запрос в гугл в соответствующих терминах) и нашёл слабо задокументированную фичу, которая решает ключевую проблему в одну строку кода, погуглил ещё чуть-чуть и полностью решил стоявшую подзадачу в где-то строк 20 кода. Ушло у меня на это все часа два, включая время на установку IDE и прочего инструментария. Хотя на самом деле мне тоже повезло, ведь я искал не готовую фичу, а соответствующий плагин для библиотеки или способ его написать; с другой стороны, то, что я в таких поисках наткнулся на готовую фичу - вполне закономерно.
И вот фиг его знает, как наличие таких скиллов проверить.
sshikov
29.08.2021 14:06+1>это может быть ситуация «просто повезло».
Может, разумеется. Но опыт мне подсказывает, что в среднем чем выше уровень — тем больше шансов, что опытный найдет решение вот таким вот образом, тупо поискав. Просто потому, что он годами читал какие-то блоги, новости и пр., и что-то там запоминал для себя.
Это совершенно не значит, что производительность синьора будет всегда на порядок выше, чем у джуна. Суть моего примера скорее в том, что попадаются задачи, на которых эта разница просто зашкаливает.
dimkrayan
27.08.2021 00:10+1имхо, финансовая составляющая - не совсем корректный показатель. В финансовом плане, имхо, важнее не столько качественно реализовать, сколько придумать то, что нужно людям.
northzen
27.08.2021 02:55Вы считаете, что если есть работына N сеньоро-часов, то и надо нанимать сеньора.
Если у вас что-то сеньор сделает в 8 раз больше джуна за 4 раза больше денег, то это не означает он вам все задачи сможет так закрыть.
Во-первых, не везде его производительность будет в 8 раз больше.
Во-вторых, там, где его производительность будет в 8 раз больше, ему может быть не очень интересно ровно по тем же причинам, что и восьмикратная эффективность -- он 100 раз уже решал такую задачу.. И проработает н таких задачах у вас такой сеньор не очень долго.
Не очень понятно, а чего тут теоретизировать? Одни хотят, чтобы можно было меньше платить, но при этом больше бы делали.
Другие наоборот. Спорить о том, что важнее как-то глупо.
trankov
26.08.2021 23:53+1Netflix стал успешен благодаря умению принимать правильные бизнес-решения: однажды медиаплатформа поняла, что производить контент самим дешевле, чем платить за готовый. Но производство кино это технология, которой больше ста лет. Там можно нанять топовых сценаристов, а продакшен заказать «под ключ». Потому что там не нужно изобретать ничего нового. Как отследить зрительский интерес, как написать хороший сценарий, как правильно делать сторибординг, снимать, монтировать, как играть роль — всё это тысячи раз прописано, на рынке множество профессионалов, а понять качество продукта можно просто посмотрев готовый материал. Ничего этого сегодня в IT нет — «поставь камеру вот так, а свет вот так, и будет хорошо» — таких решений просто нет. Сейчас IT это на 90% инженерная отрасль, где все задачи так или иначе нужно проектировать и реализовывать. Современное производство кино давно достигло уровня конвейера, там, чтобы достигнуть приемлемых результатов, надо просто не замахиваться на шедевры, а соблюдать сто раз прописанные правила. И телеэкран, и киноэкран за сто лет почти не поменялись. В разработке подобного уровня правил нет: отрасль вечно молодая, а технологии меняются непрерывно.
И если вам кажется, что менеджеры, достигшие успеха, не делают ошибок в смежных областях — есть много примеров, когда это было не так.
M_AJ
27.08.2021 10:16+3Не брать джунов без опыта и потом страдать от нехватки кадров - очень распространённая менеджерская болезнь
И не только айтишная. Это "болезнь" всего российского бизнеса. Можно посмотреть на тот же производственный сектор, где тоже все хотят инженеров с опытом. Не любят у нас особо вкладывать деньги в развитие людей, все хотят чтобы рисковал кто-то другой. В принципе это даже можно понять. Только вот нытье по-поводу того, что людей не хватает при таком подходе начинает раздражать. Netflix хотя бы не ноет.
Tschumin
27.08.2021 16:23+1очень мудрое и своевременное замечание, если закрыть доступ свежей крови, система вымрет
Mephistophele Автор
26.08.2021 23:42+1Смех смехом, но в Индии так и поступают. Там ещё и резюме всей деревней пишут по принципу:
- О, я помню мой дедушка рассказывал мне сказку и там было такое слово - ActiveX.
- Конечно же пиши его в своём резюме!dimkrayan
27.08.2021 00:11видимо, там надо читать резюме наоборот: чем меньше ненужных технологий - тем лучше.
Mephistophele Автор
27.08.2021 18:12-1C Индией своя специфика работы. Страна специфичная, но очень разношёрстная и интересная, а наши стереотипы о качестве их сотрудников уже давно неактуальны.
WraithOW
27.08.2021 12:33Всем надо подаваться на мидла? Мидл это новый джун?
А так оно и есть, формы научился верстать и уже миддл. Знать что-то про сборку мусора? Многопоточность? Шутите, батенька, це вопросы для синьора.
anonymous
00.00.0000 00:00ZloyGremlinJE
26.08.2021 22:58+1Ради интереса попробуйте создать резюме с востребованным стеком, но только в одном укажите что хотите на джун позицию, а в другом на мидл - и опыт укажите граничный - чуть больше года, что в одном, что в другом резюме. Я думаю , после этого вы сможете найти ответ на вопрос - нанимают ли джунов хотя бы примерно так же как и мидлов. Думаю, вас удивит результат))
symbix
26.08.2021 23:03+3Тот, кто в одном месте сеньор, в другом может на джуна с трудом потянуть. ;)
luch_kot
26.08.2021 20:54+2Знаете подлинную проблему сеньоров на проектах? От них ожидают, что они знают всё. Психологически им труднее всех - они достигли формального потолка развития в профессии.
Им расти нужно куда-то, а они уже носят самое гордое звание из всех возможных. Даже если станут знать вдвое больше, чем с момента становления сеньорами - их будут продолжать звать сеньорами. Я уже потихоньку ввожу в практику другие названия, форсируя идею, что Илон Маск был прав с необходимостью более ярких и привлекательных званий. Например, себя я зову исключительно Automation QA Emperor.
300KpS
26.08.2021 21:07Можно взять армейскую ранговую систему - что-то типо Lieutenant Senior, Captain Senior, Major Senior
fedorez
27.08.2021 00:58+1можно устроить деноминацию званий, как во времена Империи - полковник переводится в гвардию капитаном, бо полковник Гвардии - сама Матушка Императрица )) "У себя на галере, Владислав, вы были синьор, а у нас тут в яндфлексе будете Гвардии джун второго класса!"
ну если серьезно, то варианты перехода из начальников отдела разработки в средние миддлы в Яндексе я видел...
symbix
26.08.2021 21:21+10Это проблема только в крупняках с формальными грейдами и прочим буллшитом.
Нормальным людям насрать на звания, не в армии.
koreychenko
26.08.2021 21:36Проблема в том, что к этим "званиям" часто косвенно привязана зарплата.
Обычно на рынке джуниор получает X денег, миддл 2Х денег, сеньор 3Х денег, а потом уже начинается как у боксеров - сверхтяжелый вес. И дальше уже непонятно от чего будет зависить зарплата. Т.е. пока есть грейды есть какие-то референсные значения, а как сеньорам быть - хз.
mapron
26.08.2021 23:25+1Просто грейды с чиселками, вроде они есть почти в каждой компании. Linear Developer, L1-L15 грейды. усё. Можешь 30 лет в компании работать и так и не получить максимальный грейд сеньора.
symbix
27.08.2021 00:31Ну а потом приходит в такую компанию крутой спец, с 10х производительностью, как из моего комментария выше. Менеджмент собрался на совещание и чешет репу: максимальный грейд сразу давать нельзя, остальные не поймут, ну давайте ему топового миддла поставим для начала, но нагрузим как сеньора и посмотрим. Кандидат выслушивает такое предложение, смотрит на это всё, говорит - а пошли бы вы в жопу со своими играми, и уходит на следующее собеседование.
В итоге топовые специалисты туда попадают только с приобретением и мержем другой компании, там «сохранение звания при переходе в армию союзника» проблем не вызывает. Часто только ради этого и покупают.
Mephistophele Автор
26.08.2021 23:16В мелких конторах все инженеры, и раз нет субординации можно гнобить друг друга и устраивать весёлые срачи? XD
symbix
26.08.2021 23:20А в крупных конторах дедовщина и можно гнобить только тех, кто ниже по званию^W грейду? :)
Mephistophele Автор
26.08.2021 23:56Ниже не интересно, это наоборот фундамент, а вот выше - самое-то. XD
youlose
28.08.2021 15:46есть же ещё lead developer и principal developer
symbix
28.08.2021 15:54Это все подразумевает взятие на себя некоторых функций менеджера, и пересекается с teamlead. А что делать с теми, кто этого не хочет, но программирует лучше остальных senior-ов?
youlose
28.08.2021 19:41+1я имел в виду не тимлидство, а что-то как здесь https://github.com/avito-tech/playbook/blob/master/developer-profile.md#lead
symbix
29.08.2021 01:40Так - да! Вообще хороший документ, мне нравится. Если ещё и практике все так, вообще отлично
Tsimur_S
26.08.2021 21:32+2Логическая ошибка у вас
Еще лучше будет продать двух джунов как сеньоров и сеньора(как не важно, главное неотрицательная маржа).
Tsimur_S
26.08.2021 21:17+4Начало за здравие а аргументация за упокой.
Мы нанимаем топ рынка. Не тешьте себя иллюзиями
Нанимать топ рынка(пусть будет топ 5%) проще простого. Просто берем 95% перцентиль по зп на позицию и все резюме которые просят ниже отправляем в мусорную корзину. Точно так же можно нанимать топ по репутации stackoverflow. А вот нанимать топ по навыку программированию уже нереально потому что этого топа не существует и вообще функция compareTo не определена.
Положительную репутацию со стороны сотрудников. Вы не морозите людей вечно, а в случае необходимости ротируете их в разумные сроки.
Так вы получаете возможность ротировать джунов в мидлов. Если вы не нанимаете джунов принципиально то и ротировать их нет нужды в связи с отсутствием. Иными словами наличие джунов никак не решает проблему ротации более опытных кадров.
Положительную репутацию со стороны начальства. Руководство зачастую нацелено на рост и развитие бизнеса, и подготовка кадров помогает справляться с кадровым голодом.
Сдается мне что вышестоящему начальству глубоко наплевать как вы решаете кадровый голод, через хайринг или обучение. Их интересует результат и затраченные средства. Поэтому что-бы это было плюшкой требуется дополнительно постулировать что обучение выгоднее чем хайринг. Для каких то компаний это так и есть но в общем случае это утверждение спорное.
Инженеры занимаются задачами, соответствующими их уровню. Очень часты ситуации, когда нанимают сеньора и дают ему примитивную, монотонную работу, которая никак не применяет и не развивает его навыки. Думаете долго такой человек у вас проработает? Наймите лучше джуна.
Это действительно плюс, такое встречается, особенно в аутсорсе/аутстафе, где инженеры имеют минимум полномочий для автоматизации подобной рутины.
Эффективно решаете проектные проблемы. У вас есть пул людей, поэтому вы в противоположность вашим коллегам решаете ваши проблемы самостоятельно, а не вечно ноете и срываете сроки, разводя лапками.
А вот тут подмена одного тезиса другим. Наличие пула людей это действительно хорошо но наличие джунов в команде != наличию пула.
Положительная репутация. На самом деле это огромный плюс в репутацию компании - найм людей без опыта.
Значимый плюс это только для людей без опыта. Для остальных этот плюс где-то на уровне показателя процента "зеленой" электроэнергии используемой компанией.
Сотрудники, которых компания взрастила или наняла без опыта в самом начале карьерного пути, намного лояльнее относятся к компании, чем нанятые и опытные сотрудники.
Безусловно да. Но только лишь при условии правильной системы вознаграждения в компании. Сейчас в 99% компаний проще всего увеличить себе зп уволившись с нее и устроившись по новой.
учитывая разницу в rate card (очевидно, что за джуна платят меньше), маржинальность на более дорогих профессионалах ниже.
Людей без опыта сложнее утилизировать. Зачастую сталкиваются с ситуацией, где все хотят сеньоров с вот такущим списком знаний и умений
Вот оно что. Речь в статье действительно про аутсорс. Ну тогда можно сократить всю статью до 1 пункта - "лучше продать синьора и джуна чем одного синьора", к такому уже трудно будет что-то добавить.
Интересная ситуация с непосредственным руководством - иногда тимлиды бывают против, мотивируя тем, что упадёт производительность отдельного сотрудника, да и вообще Баба Яга против.
такой сотрудник уже выгорел, токсичен или уже начинает просто саботировать проект, как правило активное противодействие в проектных инициативах - хороший маркер чтобы присмотреться к сотруднику.
Поэтому по итогу: такой лид не выбирается наставником, ангажируем кого-то другого, а за лидом пристальный надзор.
Понятно, берем человека на карандаш за несогласие с партийной линией.
но ты же коммунист
anonymous
00.00.0000 00:00Mephistophele Автор
26.08.2021 23:13Вы допускаете ошибку - у вас система статична, у меня - нет. Тот кто вчера был джуном, через год-другой становится мидлом, мидлы вырастают в сеньоров и т.д.
Так вы получаете возможность ротировать джунов в мидлов.
Нет, при условии выше. Ротация будет overqualified мидлов(возможно сеньоров) на мидлов.
Сдается мне что вышестоящему начальству глубоко наплевать как вы решаете кадровый голод, через хайринг или обучение. Их интересует результат и затраченные средства.
Всё зависит от степени кадрового голода и тут все средства хороши, когда идёт активный рост или нужно искать новые источники, когда привычные и старые вычерпаны. Тут и обучение, и хайринг и покупка компаний, всё будет работать, вплоть до "дети зачатые на корпоративе считаются сотрудниками компании". Бизнес не будет брезговать ни чем, главное чтобы всё было в рамках законов.
А вот тут подмена одного тезиса другим. Наличие пула людей это действительно хорошо но наличие джунов в команде != наличию пула.
Нанять мало, их растить надо и развивать. Опять же я не рассматриваю статичную систему, поэтому не сразу, но пул толковых специалистов за несколько лет можно сформировать и это только если опираться на найм джунов и обучение их с нуля. Можно быстрее, но это через найм только.
Безусловно да. Но только лишь при условии правильной системы вознаграждения в компании. Сейчас в 99% компаний проще всего увеличить себе зп уволившись с нее и устроившись по новой.
Про пересмотр ЗП согласен, но значит я вхожу в этот 1%, т.к. мои сотрудники спокойно могут прийти и сказать что хотят больше, а зачастую я поднимаю им зп заранее, ну или моё начальство меня подгоняет, что давно кому-то не пересматривал. XD
Вот оно что. Речь в статье действительно про аутсорс.
Если вы считаете, что в продуктовых компаниях нет утилизации, ресурсного менеджмента и проектных менеджеров, которые крутят носом при виде резюме джуна, предложенного на проект. Не смею вас разубеждать. Лучше оставаться в розовых очках и думать что в продуктовых компаниях всё стильно\модно\молодёжно, нет жёсткого BDSM с легаси, которое приносит прибыль бизнесу, а разработчики какают радугой.
Понятно, берем человека на карандаш за несогласие с партийной линией.
Выше написал же: "такой сотрудник уже выгорел, токсичен или уже начинает просто саботировать проект, как правило активное противодействие в проектных инициативах - ... маркер ". Я конечно понимаю что для некоторых сидеть на проекте вечно и токсично ныть на всех вокруг - норма, но лучше "поднять руку" и спокойно ротироваться с проекта, как я говорю: "никто не прибит гвоздями". Хотя есть люди которым пофиг: токсичные ли у них сотрудники, разваливается ли у них проект. Само пройдёт. Возможно. Как-нибудь.
dimkrayan
27.08.2021 00:20+1но в вашей не статичной системе вчерашние джуны почему-то продолжают работать у вас, хотя это совершенно не гарантировано.
Mephistophele Автор
27.08.2021 11:47Как удерживать сотрудников и делать чтобы они не уходили - отдельная тема разговора и она больше про People Management. Но это вполне посильная задача.
dimkrayan
27.08.2021 12:06+1А поделитесь размышлениями.
Кроме держать зарплату не просто выше рынка - а выше тех, кто выше рынка (ну и не создавать на ровном месте проблем) я особо вариантов не вижу. А при таких вводных можно и только сеньоров нанимать.
Можно, конечно, стать суперкрутой компанией, куда все будут стремиться не только за деньги, но это не тот рецепт, который можно легко реализовать.
Mephistophele Автор
27.08.2021 12:34-1Подписывайтесь, запилю. ;)
Финансы на самом деле очень важны, но их значимость можно значительно понизить при принятии решения о переходе в другую компанию. Расскажу как это делать.
mitekgrishkin
29.08.2021 00:04Что такого может произойти, что сотрудник, решивший перейти в другую компанию за более длинным рублем, решил, что деньги ему и не так важны? Вы там что, присылаете отрубленную конскую голову?
Mephistophele Автор
29.08.2021 00:06Со мной люди работают которым x2 предлагали, от их текущей зп и там позиции весьма топовые предлагались, например Principal Solution Architect.
Tsimur_S
27.08.2021 00:33+1Вы допускаете ошибку - у вас система статична, у меня - нет. Тот кто вчера был джуном, через год-другой становится мидлом, мидлы вырастают в сеньоров и т.д.
Каким образом моя(да и почему она моя? давайте называть ее системой netflix) система статична? Она точно так же предполагает ротацию, только исключает ступеньку джуниоров.
Нет, при условии выше. Ротация будет overqualified мидлов(возможно сеньоров) на мидлов.
Ротация будет абсолютно одинаковой в обоих случаях, как горизонтальная так и вертикальная. Вся разница только в том что будет первой ступенькой ротации: джуны или люди с опытом.
Всё зависит от степени кадрового голода и тут все средства хороши, когда идёт активный рост или нужно искать новые источники, когда привычные и старые вычерпаны. Тут и обучение, и хайринг и покупка компаний, всё будет работать, вплоть до "дети зачатые на корпоративе считаются сотрудниками компании". Бизнес не будет брезговать ни чем, главное чтобы всё было в рамках законов.
Я не спорю про то что все средства хороши. Но что бы безапелляционно утверждать что это будет плюсом для начальства свыше, нужно обосновать финансовую состоятельность этой затеи а не просто огульно утверждать. Без цифр на руках можно этот пункт написать и в обратную сторону. Смотрите:
Положительную репутацию со стороны начальства. Руководство зачастую нацелено на рост и развитие бизнеса, резкий старт людей имеющих опыт в программировании вкупе с меньшими затратами на их супервайзинг позволяет быстрее включать их в работу и добиваться ключевых метрик развития продукта.
Запишите в минусы?
Если же у вас есть явные цифры о том что обучение выгоднее то сама статья сокращается до:
Q: Нанимать готовых специалистов или обучать? A: Обучать - потому что это финансово выгоднее, вот цифры.
Нанять мало, их растить надо и развивать. Опять же я не рассматриваю статичную систему, поэтому не сразу, но пул толковых специалистов за несколько лет можно сформировать и это только если опираться на найм джунов и обучение их с нуля. Можно быстрее, но это через найм только.
Пул толковых специалистов может у вас быть точно так же если вы нанимаете синьоров и архитектов. Это и найм джуниоров абсолютно ортогональные вещи по смыслу.
Если вы считаете, что в продуктовых компаниях нет утилизации, ресурсного менеджмента и проектных менеджеров, которые крутят носом при виде резюме джуна, предложенного на проект.
Если я утверждаю что в аутсорсе есть огромный стимул к найму джунов то как из этого вытекает ваше предположение о том что я считаю что в продуктовых компаниях менеджеры рады джунам? Как раз ровно наоборот я считаю из своего опыта, что в продуктовых компаниях гораздо менее лояльны к хайрингу джунов. У них нету вышеописанной мотивации аутсорсеров продавать джунов хоть тушкой хоть чучелом, у них совершенно другие способы заработка и наборы KPI.
Выше написал же: "такой сотрудник уже выгорел, токсичен или уже начинает просто саботировать проект, как правило активное противодействие в проектных инициативах - ... маркер "
Ну да, именно что написали. Написали что если лид высказался против найма джунов то значит он выгорел и его нужно скрутить в бублик(sic!) и вообще явно дали понять что его мнение не так уж тут и важно. Особенно забавно это воспринимать вместе с последующим пунктом "не переусердствуй".
symbix
26.08.2021 23:33+1Нанимать топ рынка(пусть будет топ 5%) проще простого. Просто берем 95% перцентиль по зп на позицию и все резюме которые просят ниже отправляем в мусорную корзину. Точно так же можно нанимать топ по репутации stackoverflow. А вот нанимать топ по навыку программированию уже нереально потому что этого топа не существует и вообще функция compareTo не определена.
Функция compareTo по навыку программирования (вообще) нужна только премиум-бодишопу (условному, настоящий бодишоп будет продавать индусов под видом сеньоров).
А по конкретному набору скиллов, нужных для работы над конкретным продуктом, достаточно 10 минут собеседования, чтобы понять, что человек подходит. Конечно, собеседование длится дольше, но за 10 минут уже понятно на самом деле, просто уже видишь этого клевого чувака у себя в команде.
Если «ну вроде ниче», но уверенности нет - не нанимать. Лучше ошибиться в эту сторону.
Tsimur_S
27.08.2021 00:49Функция compareTo по навыку программирования (вообще) нужна только премиум-бодишопу
Функция compareTo нужна, как минимум, для того что бы определить топ программистов по навыку программирования. Без нее нету самой возможности существования топа. С какой целью и кому нужен этот топ уже дело десятое.symbix
27.08.2021 02:11Это подход математика из того анекдота - «вы находитесь на воздушном шаре». Вы формально точно так же правы, но в реальной жизни обычно начинают с целей. ;)
thatsme
26.08.2021 21:34+4вот когда ты будешь сеньор с зарплатой от $1000 тогда и приходи
Это где такие смешные зарплаты у сеньоров? В бангалоре?
GospodinKolhoznik
26.08.2021 21:55+10-Скажите, порудчик, как вам удаётся с такой лёгкостью нанимать сеньёров?
-Очень просто, корнет, подходите к любому сеньёру и говорите - мсье, позвольте вас нанять за 1000$.
-За 1000$!? Но так же можно и по морде получить!
-Можно и по морде, а можно и нанять.
koreychenko
26.08.2021 21:39Задача любого бизнеса успеть заработать на сотруднике больше, чем ему заплатили за время, пока он не уволился.
Это прекрасно умеет делать Макдоналдс. Берет джунов/стажеров и ведет их по карьерной лестнице. Кое-кто доходит до менеджерских должностей и в целом неплохо себя чувтсвует.
Проблема в том, что никто не умеет так вести джунов, да еще и зарабатывать на них.
gholla
26.08.2021 22:30+1хаотичный набор мыслей. тяжелый слог "умственногорассуждения"
ключевое - для чего эта статья? для кого? ответ - очередное сотрясение воздуха в попытке изменить мышление тех кто даже хабр не читает , не то что такие статьи
KoteMilote
26.08.2021 22:44В любой беловоротничковой сфере такие же проблемы, ИТ тут не уникальна
Mephistophele Автор
26.08.2021 22:45В любой сфере такие же проблемы. Беловоротничковые сферы тут не уникальны.
Gam0ver
26.08.2021 22:46+1Пет проекты должны быть имхо, и не важно спрашивает их работодатель или нет.
Пет проект - это как высшее образование) Оно вроде бы и не нужно, но быть должно)) Опять же, это не показатель того что ты гений, просто если ты не осилил пет-проект - то и на работе вряд ли от тебя будет толк. Конечно, бывают исключения - Б. Гейтс и тд
Но, знаю ребят, кто свои пет-проекты умудрился монетизировать и заработать с этого (не много конечно, но все-таки приятно - тут самое главное +100500 к мотивации)
Bellerogrim
26.08.2021 23:13А я знал когда-то человека, который не брал программистов, отвечающих на вопрос о хобби — "прогрммирую". Он считал их слишком токсичными людьми.
Mephistophele Автор
27.08.2021 00:02+2У нас в городе на заре галеростроения был случай - в какой-то конторе взяли HR которая загонялась по всяким психологическим тестам, но понятно что образования в этой сфере у неё не было, как итог они сначала отсеивали ребят по принципу: "ой, ну этот не саксефулли пассед вис этот тестик, он нам фулли донт матч". Как итог галера на дне, про капитана - не знаю, не интересен, может где рыб и крабов кормит, а может где и барабаном задорно ритм отбивает.
polearnik
27.08.2021 11:00+1проблема с пет проектами в том что на них нужно время. А если именно вкалываешь на работе а не приходишь попить смузи с ребятами с прикольными стрижками то сил на еще програмирование нет. Хочется и от работы отдохнуть и с семьей время провести.
Пет проекты это больше для молодых специалистов или студентов у которых есть силы и время приходя после работы забурится в изучение чего-то нового до 2 ночи а с утра быть огурчиком на работе.
Vilaine
28.08.2021 01:05-1Какие пет-проекты стоит делать в мире, где почти всё тривиальное уже реализовано?
Antervis
27.08.2021 02:27+3проблема с джунами, как её видят менеджеры, в другом. На период обучения они обходятся компании дороже миддлов/сеньоров, по соотношению k = результативность*качество/доллар. А когда они наконец дорастают до миддлов, могут и свалить в условный нетфликс на x2. А если этому плавно перерастающему в миддла джуну платить как в нетфликсах, то можно было вместо него нанять миддла и получить желаемый k сразу.
И эта логика отлично работает в начинающих конторах, где порог входа в проект минимален. А вот в большом проекте, где надо уметь ориентироваться в архитектуре и знать местные апи/инструментарий/процессы - там всё становится хитрее. Выросший в компании джун будет ценнее миддла со стороны просто потому, что второму всё равно придется долго впитывать то самое сакральное знание.
conopus
27.08.2021 07:41Тестовое джунам еще и тем хорошо, что позволяет пополнять им GitHub. Не у всех есть идеи для pet project, а тут хоть что-то. Может и перерасти во что-то интересное: я так начал с примеров автотестов на API ХаХару, а на выходе получился дашборд с аналитикой для локального рынка труда.
atomlib
27.08.2021 11:11+1Не у всех есть идеи для pet project
hsto.org/webt/wm/4x/np/wm4xnpw012-bbqzbuvf9hobuk3k.pngconopus
27.08.2021 11:18Собак и детей можно брать из приюта. Например, чтобы не возиться с лужами по всему дому и спать по ночам. Но, почему-то так делают не все.
Vilaine
28.08.2021 01:11+1Это не пет-проекты, а литкод на максималках. Решение уже много раз решенных задач исключительно ради тренировки навыков программирования. Я думаю, с какого-то момента (после тривиальных задач) для Вселенной будет полезнее, если это время уйдёт на стажировку на реальной работе.
ehots
27.08.2021 11:03После прочтения заголовка в мыслях возникла картинка где сеньоры в первый рабочий день дерутся за место главного сеньора в команде, при чем не как котики, а на ножах или как в темном рыцаре, когда джокер сломал кий и дал двум бандюгам со словами "у нас только одно место".
Mephistophele Автор
27.08.2021 11:51Если долго держать на проекте, то так и будет. Звёздная команда нужна только на старте.
nmrulin
27.08.2021 11:27-1В результате в такой компании в основном оказываются миддлы, назвавшие себя "сеньорами"(разоблачение невыгодно никому). Значительная часть из них выполняет работу джуна и валит при первом удобном случае.
shurkandak
27.08.2021 11:30+3В наши дни одна из самых больших проблем для 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к+ населения, иначе переезд.
Так что никакой проблемы нет, вообще нет, надо только снять "розовые очки" и начать работать.
Zeratyl06
27.08.2021 11:52+4Мы шли по пути набора на junior позиции и выращивания из них специалистов, но столкнулись с проблемами:
Значительные усилия и время тратятся специалистами уровня senior для обучения, тем самым отвлекая их от задач бизнеса;
В среднем до уровня middle сотрудник вырастает за 1,5-2 года;
После того как сотрудник понимает, что его уровень близок к middle, он старается перейти на более интересные ему задачи. Теперь ставшие для него рутинными задачи выполняются с нежеланием. При том что 70% задач это как раз такие.
Через некоторое время сотрудника достигшего уровня middle хантят другие компании. Т.к. у нас современный стек, то такие специалисты сейчас популярны. Лояльность к компании не имела решающего фактора, для того чтобы остаться.
И да, у нас уютный офис, хорошая команда профессионалов и отлаженные процессы, как и в большинстве современных ИТ компаний.
Mephistophele Автор
27.08.2021 11:58Значительные усилия и время тратятся специалистами уровня senior для обучения, тем самым отвлекая их от задач бизнеса;
Я такие задачки выдаю как дополнительное развлечение, либо для сверхпродуктивных людей, которые за 4ч успевают сделать то что другие делают день, а то и два; или это может забирать часть личного времени, в обмен на финансовое вознаграждение, такая подработка.
В среднем до уровня middle сотрудник вырастает за 1,5-2 года;
Да, цифры очень похожие.
После того как сотрудник понимает, что его уровень близок к middle, он старается перейти на более интересные ему задачи. Теперь ставшие для него рутинными задачи выполняются с нежеланием. При том что 70% задач это как раз такие.
На мой взгляд тут надо уже готовить следующих джунов, а новоявленным мидлам выдавать другие задачи. Но всё это требует активного роста бизнеса.
Через некоторое время сотрудника достигшего уровня middle хантят другие компании.
Здесь нужно удерживать сотрудника, обычно это целый комплекс мер и мероприятий.
Zeratyl06
27.08.2021 13:01Здесь нужно удерживать сотрудника, обычно это целый комплекс мер и мероприятий.
Согласен, но ресурсы каждого тимлида и в целом у небольших компаний ограничены, а амбиции у сотрудника на старте обычно завышены.
Mephistophele Автор
29.08.2021 00:08По моим наблюдениям амбиции завышены когда человек мидла получили или вот-вот получит. Но это уже так, частности.
nstpnkn
27.08.2021 18:15Стало интересно: а нанимать миддлов специально для обучения молодняка, а не отвлекать тех, кто должен работать над задачами, -- не рентабельно?
И, извиняюсь за наивный вопрос, но при невозможности открыть на базе компании training center, не проще ли на входе отправлять новичков на какие-нибудь короткие образовательные курсы? Мне не понятно, почему не выгодно выращивать спеца внутри компании: да, сначала тратишься, но потом он прокачивается и начинает приносить прибыль. А даже если его схантят, это плюс в копилку индустрии, текучка кадров это стандартная история в любой сфере.Mephistophele Автор
27.08.2021 18:18Выделять опытных сотрудников на позиции с отрывом от производства - вполне себе рентабельно и даже не мидлов, но это дорогое удовольствие, только большие компании себе такое позволить могут, там за счёт объёма общей выручки закрываются траты на обучение.
sshikov
27.08.2021 18:24+1>нанимать миддлов специально для обучения молодняка
А о компании эти миддлы что будут знать? Что они будут знать о проектах и их потребностях?
>почему не выгодно выращивать спеца внутри компании
Ну я могу предположить, почему это сложно. Меня регулярно пробовали в компании заманить преподавать внутри. Я отказываюсь всегда, по таким простым причинам:
— эта работа предполагает 100% занятость, а у меня нет в сутках 48 часов
— а если я занимаюсь ей половину времени, страдает основная работа.
Ну т.е. это либо достаточно тяжело, либо вы начинаете терять квалификацию, отдаляясь от своего основного проекта и работы. Немногие на такое готовы. Да и вообще далеко не всем нравится преподавать.
Zeratyl06
27.08.2021 22:19Обучение на курсах мы практически не используем. Чтобы хорошо усвоить материал курса, на него нужно прийти уже с практически знаниями в изучаемой области. С другой стороны, человеку, погрузившемуся в изучаемую область курсы мало полезны, т.к. в большинстве их уровень достаточно базовый и при этом сильно обобщённый, отличающийся от того что действительно есть в компании.
У нас есть junior позиции, но их мало. Мы сделали значительный акцент на автоматизацию и закрыли большую часть задач для которых требовался такой уровень. Мы так же скорректировали подход к подбору на junior позиции, выбирая людей с хорошо выраженными парадигмой Win – Win, развитием и результативностью. Поиск таких сотрудников — это отдельный вопрос.
RTK
27.08.2021 11:52+2Хотелось бы добавить, что если мы говорим не о больших компаниях, а о маленьких в регионах, то проблема в том, что они берут джунов, но не умеют с ними работать. По факту им нужны мидлы, но финансы не позволяют их нанимать, поэтому они берут джунов и ожидают, что они сразу будут закрывать задачи. В итоге мы получаем, что требования для джунов в таких местах завышены.
sshikov
27.08.2021 16:57>вот когда ты будешь сеньор с зарплатой от $1000 тогда и приходи
Пардон, а скока лет назад это было? Я такие зарплаты получал примерно в 2004 году в Москве. Ну и тогда я был синьором, да. А сегодня эта сумма вообще не синьорская зарплата, на мой взгляд, причем уже возможно нигде, потому что удаленка с тех пор сильно развилась.Mephistophele Автор
27.08.2021 18:14sshikov
27.08.2021 18:19+1Либо хабр глючит, либо браузер. Не вижу я такого коммента с ответом. Но поиском нашел. Да, 2005, вполне совпало с моими ощущениями.
NBSoyu
27.08.2021 18:15+1Браво маэстро, проблема того что всем нужны мидлы с огромным стеком или сеньеры очень большая в России и когда тебя берут на позицию Trainee с зарплатой ниже стипендии, то ты не пойдешь на нее потому что просто на просто умрешь с голода и без денег сидя месяц а то и два на стажировке, в неуверенности даже возьмут тебя в компанию или нет.
melvladimir
27.08.2021 22:04"Джун учится работать. Миддл - работает. Синьор - учится не работать")
Для успешной реализации чего-то крупного с элементами уникальности, необходима разносторонняя команда, чтобы джуны тоже были, задавали "тупые" вопросы, которые, иногда, порождают интересные идеи и вырастают в крутую реализацию.
andrewz13
28.08.2021 00:23+1История из собственной жизни - чуть больше 3-х лет назад мне позвонили из одной компании и предложили работу разработчика сетевых сервисов. Возраст на тот момент 40+, опыта коммерческой разработки нет, компания пишет на Go - я писал на C (не модный и не молодежный) и в основном вещи для сетевой инфраструктуры сотового оператора (в котором тогда работал уже почти 7 лет), что такое Go вообще не знал до этого звонка. По модной классификации - джун--. Сходил, поговорил, вышел на работу. Втянулся, стал потихоньку писать. На данный момент свой уровень оценить сам я не смогу, но собеседования я уже сам провожу и коллеги периодически обращаются за советом. Так о чем я вообще? Джуны могут быть тоже разными - и это очень хорошо видно на собеседованиях. Под словом "джун" я в данном контексте понимаю человека без опыта разработки или с минимальным опытом. Одни например пытаются понять (или найти где-то) например как и почему сделаны какие-то вещи в языке именно так как сделаны, а не по другому. Понять концептуальные особенности языка чтобы правильно применять его сильные стороны и обойти слабые. Другие просто пытаются из готовых фреймворков что-то сляпать не разбираясь как и что внутри работает. Третьи (часто в телеграме очень попадается такое в профильных чатах) вообще пишут "посоветуйте интересный фреймворк вроде вот такого - чтобы поизучать". И опыт тут совсем не имеет значение, значение имеет заинтересованность в знаниях и какое-то базовое образование, которое дает университет (и уровень которых к сожалению падает сейчас). Вот по этой причине скорее всего и не берут дунов - тех кто хочет разобраться очень мало.
raydac
а что мешает получать опыт на пет-проектах? приходящий начинающий писатель который ничего не написал, смотрится в бизнесе странновато
Mephistophele Автор
Не pet проектах хорошо набивать руку когда есть уже опыт работы, например хочу я разобраться с Dart/Java/Go, но у меня уже есть опыт в .Net, поэтому в свободное от работы время, я могу поковырять ту или иную технологию\язык.
В статье я затрагиваю тему людей без опыта, для них порог вхождения будет намного выше чем для опытного разработчика, про временные затраты я вообще молчу. Плюс откуда человек знает что сейчас модно-стильно-молодёжно в продакшене? Что начать изучать, как начать? В универах толковых преподавателей (с неустаревшим продакшен опытом) не так уж и много, поэтому выбрать свою стезю - зачастую дело фортуны. А если человек не из ИТ вуза?
Плюс цель статьи - дать понять другим менеджерам, что найм людей без опыта - это не ой-ой-ой, страшна, а вполне себе обыденность, которую делают другие.
raydac
да вроде чтобы узнать что "модно-стильно-молодежно", достаточно просто посмотреть список требований в вакансиях на любом работном сайте, понятно что для человека без опыта будет вход выше чем для того кто с опытом, но потому и надо выделиться на фоне остальных "без опыта", а если он приходит "вы мне заплатите, научите и тогда может быть я начну работать", это надо иметь очень большой бизнес и очень много много (!) лишних денег чтобы перебором просевать такой материал
p.s.
на тему трудоустройства, еще старая история еще в советской технике молодежи вспоминается часто, даже специально картинку вырезал
Mephistophele Автор
Я бы тоже такого умельца нанял, т.к. большой любитель инвестировать в людей. Но, к сожалению, иногда не смотрят на потенциал, а лишь на опыт, т.к. потенциал надо развить, а бабло надо зарабатывать сейчас, срочно и быстрее-быстрее. Капитализм, однако.
raydac
как то на одном медицинском форуме где обсуждались поборы, спрашивал людей представляющихся врачами - "а что будет если больной откажется платить?", один из них сказал - "тогда заведующий отделением запишет такого больного в маленькую черную книжечку и его будут отдавать новичкам", чем то имхо совпадает с ИТ - если есть деньги, то врядли захочешь чтобы проблему решали люди без опыта, а то украсишь их кладбище
Jsty
Список требований != с чем будет работать.
К тому же каждое отдельное требование для новичка вполне может оказаться равно году изучения технологии или больше.
raydac
но тогда получается что этот год его будет за свои деньги обучать наниматель, а если у нанимателя есть выбор не тратить столько денег и времени, то приходим к логическому заключению что если есть возможность, то он не будет их тратить
Cost_Estimator
Не скажите. Наниматель потратит на обучение меньше времени, т.к. у него уже есть понимание, чему именно учить новичка. Последний же даже в рамках одной технологии будет хватать много лишнего и тратить лишнее время.
raydac
с обучением у работодателя возникнут риски, что человек получив запись о "практике" и "обучении" в резюме, уйдет на 10-15% больше денег к другому работодателю, который просто воспользуется полученным продуктом и получается первый работодатель будет работать на второго, а учить за свои чтобы в конце поднять денег за то что сам научил, в чем выгода?
Cost_Estimator
Так и синьор может уйти. Он ведь тоже учится, причем более крутым фичам и за бóльшие деньги. Любой может уйти, получив запись "О практике и обучении". Но если это мешает работодателю получать выгоду от наемного сотрудника здесь и сейчас, может ему самому стать наемным?
raydac
может конечно и даже непременно уйдет, но в первую очередь следующему работодателю надо будет поднимать много приличнее денег чтобы его переманить, а во вторую очередь его не придется обучать этот год два основам и можно будет сконцентрироваться на бизнес-задачах
Dartjek
Также не факт, что у новичка нет другой другой работы(жить тоже на что-то надо, пока учишься). Вот и сравниваем несколько несчастных часов вечером за вычеьлм времени в пути на работу и обратно и полноценный рабочий день в течении ты можешь выучить гораздо больше.
bubn0ff
+100!
Wan-Derer
Ну прям, год! Современный джун это !jun.equals(valueOf("zerro")). (наПримереJava) он неплохо знает Core, включая Concurrency и Reflection, освоил начала БД до степени постых JOIN, и в Spring уже потыкался. Да и вообще, если чел осилил курсы Java-developer (а это в среднем год пахать) значит он уже мотивирован и обучаем.
Так что никакой не год. Через 2-3 недели интенсива с хорошим наставником и наш джун уже худо-бедно говнокодит (принцип "делай как я") на искомой технологии, а через месяц-полтора за ним уже надо проверять не больше чем за мидлами.
Mephistophele Автор
КМК человек имел ввиду год - если без ментора\наставника, поэтому в вашем примере с ментором-то оно быстрее будет. Бесспорно.
Wan-Derer
Тут надо смотреть что автор понимает под "технология". Если это "вэб-разработка", то тут и всей жизни может не хватить чтобы освоить всё-всё что входит в это название.
А если взять отдельно стоящий Hibernate, например, то лично я (самодельный джун
из палаты мер и весовс курсов) уже через несколько дней изучения начал писать библиотечку для себя. И со второго раза (по мере изучения переписывал) написал вполне работающий экземпляр. Конечно, на тот момент я уже знал кое-что по базам данных, умел писать запросы и сравнивал свои "ручные" результаты с теми что мне выдавал Hibernate.Но и БД я изучал не год, а пару-тройку месяцев (параллельно с Java). Конечно, я не знаю большей части возможностей Habernate. Но и неправильно говорить что меня надо год учить, а до того толку от меня нет. Есть толк! Есть вполне рабочий код. И да, с хорошим наставником он наверняка был бы лучше :)
sshikov
>Но и неправильно говорить что меня надо год учить, а до того толку от меня нет.
Ну, тут просто могут быть разные взгляды на вещи. Я вот прямо сейчас наблюдаю разницу между вхождением в проект синьора, и вхождением туда же миддла пару лет назад. Толк есть от обоих. И приносить пользу оба начинают примерно через одинаковое время. Только усилий по их сопровождению требуется сильно разное количество. Упрощенно, если синьору без опыта в проекте можно поставить задачу на высоком уровне, и он автономно принесет результат через неделю, который нужно будет слегка подпилить напильничком там и сям, то миддл будет приставать каждый день, а результат не будет учитывать что-то достаточно важное (что синьор при этом не упустит, и о чем спросит сам).
>Есть вполне рабочий код.
Ну и в этом случае вопрос обычно в том, как легко это будет потом сопровождать. И как рабочий код реагирует на ошибки, например. Опять же, условный пример — если джун просто напишет i= Integer.valueOf(string), то синьор сразу напишет обработку ошибки. И эта ошибка таки вылезет рано или поздно в эксплуатации. Т.е. разница между ними — в подходе к ситуациям за пределами happy path (который и у джуна обычно достаточно рабочий), к обработке нестандартных ситуаций.
Wan-Derer
Я и не собираюсь спорить с тем что от более опытного человека на проекте больше пользы чем от менее опытного. Я возражаю против мысли "год учить и только потом будет толк". Нет, толк наступит раньше и будет нарастать пааастэпэнна :)
Писать обработку ошибок учат на всех курсах, кроме, возможно самых чепушильных (я таких не встречал). И проверять входные параметры в методах. И как это сделать наиболее компактным способом (прописать контракт, сделать блок try-catch). И даже написать условие так:
if ("abc".equals(someString) {...}а не наоборот, что позволит избежать NPE во многих случаях. Другое дело что в учебных задачах на это забивают (а если нет, то в обсуждении вой и слёзы: валидатор совсем охренел, у меня на компе всё работатет!!!1). Но я на каком-то тестовом так делал и проверяющему прям понравилось :)
Если это частая проблема, то этому стоит уделить внимание на собесе, типа: давай запишем условие... ага, а что тут может пойти не так?... а как можно улучшить?
sshikov
>Я возражаю против мысли «год учить и только потом будет толк».
Так я такого и не говорил, если вы еще раз перечитаете именно мой коммент.
>Писать обработку ошибок учат на всех курсах
Ну вот факт налицо — вроде и учат, а в тоже время, заметное отличие синьора от джуна в реальной жизни часто выражается именно в этом. Если вы этот этап прошли — вы вероятно уже в какой-то степени опытный.
>if («abc».equals(someString) {...}
Ну вот я на автомате всегда пишу так. Но не замечал, чтобы так делали многие. Наоборот, многие предупреждения идеи игнорируют, в то время как там бывает много полезного.
sshikov
Если он уже год пахал на курсах — честно ли считать, что он все освоил за 2-3 недели?
Wan-Derer
На курсах он пахал с нуля или почти с нуля. И кандидатом в джуны он стал только ближе к их окончанию. В начале "карьеры" он бы даже не рассматривался в качестве потенциального сотрудника. В комментарии речь идёт обучении неким "технологиям" и вряд ли это цикл FOR или даже коллекции. Предполагается что человек это умеет (ЯТД).
sshikov
Ну да, в такой постановке согласен.
raydac
главное что можно собрать информацию по требованиями к стеку с десятка компаний и вычленив наиболее востребованное, подготовиться до уровня "когда пригласят на собеседование", что увеличит шансы на найм
Archancler
Не трогайте джангу(/фласк/fastapi) Ее как в микросервисах так и монолитом можно использовать. Если возникнет проблема, то точно дело не в ней, а в общей архитектуре / бизнес логике.
Во фронтовых делах не силен, но думаю реакт(/вью/ануляр) туда же - это же просто либа. Если разраб её лучше знает/умеет чем jquery, то преступления точно не будет. Да и быстрее получится.
Единственный кейс, который на вашей стороне это сайт-визитка, которая на gitpage влезет (хотя и там react прикрутить можно).
На самом деле я просто не могу принять теорию необходимости того или иного инструмента в проекте (кроме явных перегибов типа хадупа и оракла в пет-проектах). В самом простом вопросе - что использовать: монгу или постгрес - каждый пытается навязать свое любимое, хотя полноценно использовать можно любой из них в любых проектах.
AllexIn
.
northzen
Лучшие и самые толковые преподаватели в Универе отличались еще и некоторой узконаправленностью. Человек много лет вспахивает какую-то борозду. Она ему интересно, у него в ней огромный опыт, в нише вспахивания этой борозды у него нет конкурентов, он выпускает топовые работы и это ласкает его ЧСВ.
И каким бы он мега толковым не был, широкая картина мира у него может просто отсутствовать. Потому что не нужна она ему.
Студент же, имея такого толкого преподавателя максимум что сможет через его руку куда-то попасть. Но такой преподаватель не расскажет, что важно или что не важно. Он немножко ученый, он не знает, как мир устроен дальше того, что он сам делает.
Но ровно поэтому вовлечениние студентов в работу должны заниматься не конкретные преподаватели, а выстроенный процесс контакта вуза с производтсвом.
centroid
А что значит - а если он не из it вуза?
Я имею ввиду то, что те кто не оттуда составляют очень слабую конкуренцию тем кто оттуда.
Их и так много и именно они 5лет учились и ежедневно делали что-то, либо кодили либо изучали академическую теорию. На 3-4 курсе уже многие из ни работают официально. У остальных есть законченный дипломная работа и несколько курсовых проектов. Каждый год выпускаются сотни новых.
Неужели они все исчезают как вода в песке и нужно искать на стороне?
Mephistophele Автор
Я учился в профильном вузе. У нас до финиша дошло только 50% численности людей начавших обучение: кто-то понял что ИТ не для него и подался в повара, кто-то ушёл работать грузчиком на рынок, один правда сделал свою компанию, но последний случай единичный.
И такая статистика держится из года в год.
Рынок растёт каждый год где-то на 30-40%. Да и регион у нас - 80% аутсорс, поэтому да, нужно постоянно искать.
Adilet-novichok
А что если чувак учиться под крылом ментора (код ревью, советы, задании и т.д.) например на бекэнд 4 года паралельно с универом? Будет университетский бэкграунд + те самые пет проекты с ментором на гитхабе. Учитывая то что чувак уже до начала универской умеет писать проекты (писать, настраивать пайплайн, деплоить) и знает определенный стэк технологии.
P.S. этот чувак я
Mephistophele Автор
Значит у чувака всё будет пучком.