Comments 245
>Наличие Git также большой плюс. Он показывает уровень подготовки, прогресс и задачи, с которыми вы работали. Мои разработчики запрашивают Git даже у джунов. И на собеседовании задают вопросы по нему. Почему это так сделал? Почему выбрал такое решение?
Такое ощущение что абзац написал человек далекий от разработки:) В нескольких предложениях подряд перепутать Git и GitHub
Зря вы так. Я лично это понял как собирательное название для публичных git-репозиториев. Кроме GitHub, есть еще как минимум GitLab и BitBucket.
Это и называется пет-проектом.
А если я такой стапер, что проект буду вести под SVN - то всё, не считается? :)
И как это на практике звучит:
Собеседующий - Ок, со скилами понятно, а что на счет Гит, сколько их у тебя
Мидл разработчик со стажем - ???
Пет-проект не обязательно имеет репозиторий, не обязательно под системой контроля версий и не обязательно вообще имеет открытый код.
На практике это звучит так: Где можно было бы посмотреть ваш код в открытом доступе?
"Не обязательно под системой контроля версий" – всё-таки немножко чересчур.
ЗЫ: Интересно, что будет лет через 20-30 таким же само собой разумеющимся, как использование VCS?
Да ладно, многие pet-проекты у меня в систему контроля не включались, так как ежедневного дифференциального бекапа dar-ом для них достаточно.
Ваши проекты - Ваши правила. Но мне такое решение кажется странным. 1. Гит не требует, чтобы был сервер. Хотите хранить локально - храните только локально. 2. Не включались - не поздно включить. git init - все, что требуется по минимуму. Будет ли там один коммит или 1000 - собеседующему, по большому счету, без разницы. Он будет смотреть на финальный итог. 3. Выполнение сознательного коммита имеет перед автоматической архивацией то преимущество, что код к коммиту вы будете как-то готовить: коммит - это некоторое подведение итогов. Поэтому ручные коммиты позволят поддерживать ваши проекты в относительной чистоте даже если они хранятся локально, и их никто, кроме вас не видит.
Не надо меня агитировать за VCS. Там где это действительно необходимо, я пользуюсь или SVN, или git. Но если весь проект состоит из нескольких десятков строк для восьмибитного МК в двух файлах (*.c + *.h), которые пишутся за один вечер для души, то никакого смысла в создании репозитория для него я не вижу. В таких проектах, обычно, разводить плату и паять дольше, чем программировать. А сваливать в один репозиторий совершенно разношерстный код - тоже не удобно.
Будет ли там один коммит или 1000 - собеседующему, по большому счету, без разницы. Он будет смотреть на финальный итог.
Простите, но нет.
Поясню. К примеру, если я вижу, что у проекта 1 коммит и потом он выброшен на гит(хаб) - значит, человек зафиксировался и закончил. Остановился.
Если я вижу, что там 100-1000 коммитов на протяжении некоторого времени - месяцев, лет - то я понимаю, что человек развивал свой проект, по мере того, как изменялись требования и хотелки.
Я могу "покататься" между определенными коммитами взад-вперед, и увидеть прогресс. Задачи, модули, код, который добавлялся. Если там была доска с issues/tasks - еще более круто, видно, как задачи появлились (и от кого), как они закрывались. Были ли публичные (от сторонних людей) Pull Request'ы.
Короче, я с вами ну прямо сильно не согласен :)
А если у меня в открытом доступе только C/C++/Assembler для МК (хобби), а в закрытом - T-SQL/PgSQL/PgPerl/MDX/DAX/ClickHouse/C#/R/Python ?
Разговаривать надо с соискателем, а код в открытом доступе - опция
Настоящие старперы (как я) используют VSS.
Настоящие старперы плюются от sourcesafe и с гордо поднятой головой используют perforce )))
winrar
и хорошо если с датой-временем в имени архива!
(а если ну_теперь_точно_точно_работает_после_правок.rar, то это жопа)
new-new-2-site.rar тоже ничего
А так с данными даты и времени в названии файла можно и гит написать)
а как же префиксы?
A_110_rabotaet.rar
B_19_dobavil_feature.rar
..
ZZ_122_vrode_ok.rar
del
Dar в дифференциальном режиме )
Если приличный шанс, что современный молодой сеньор уже не осилит в SVN :)))
Никогда не видел != не осилит ;)
в целом, SVN сильно проще гита. Особенно для мелкой команды, а ещё лучше для одного (есть там проблемки с merge, но и в гите часто это сводится к ручному мержу).
Отличия там принципиальные - на уровне доступа. Нельзя поработать с свн в оффлайне, но и уволенный сотрудник на локальной машине получит только "срез", без всей истории как у гита. С другой стороны, смерть центрального хранилища для свн это стоп разработка по сути, гиту же - берём любую машину где есть последняя ревизия, несколько git remote на смену репы, пуш - есть новое место. Потом всем обновить - пушим давно закоммиченное и работаем дальше.
с третьей - про..теряли ноут - если был гит то может быть масса закомиченного но не пушнутого, с свн факт коммита = пуш (именно поэтому в свн реально нужно работать строго в ветках, если людей больше одного)
"А если я такой стапер, что проект буду вести под SVN " - git появился всего лишь на год позже SVN, если что. Так что он не менее "ископаемый"
А чем плох SVN для больших проектов? Спрашиваю без сарказма, так как на работе он самый, а в институте заставляли вести свой Github. И SVN показался даже намного проще
Он прощает меньше ошибок при последовательности коммитов и прочих изменений, чаще выбрасывая конфликты.
В частности (когда-то так было, сейчас не знаю - там на этот счет что-то вроде бы исправляли), но если попытаться слить совершенно идентичные по коду ветки, когда эта идентичность получалась разными путями -- то Git совершенно свободно такое обрабатывает (одинаковый же код - значит можно слить без проблем), а SVN вываливал целую пачку конфликтов.
Поэтому, когда просят ссылку на профиль Github или на конкретные проекты там же, а получают ссылку на Gitlab/BitBucket - это норм, потому что контекст понятен из вопроса, а когда просят ссылку на git, можно просто порофлить чуточку. Какой гит и почему на него должна быть ссылка?)
*git, держите :)
git - система контроля версий
github - кроме того, что это репозиторий, это на текущий момент еще и code review, а с github actions уже почти CI тулза.
Это даже хуже, чем перепутать Java и JavaScript.
Наличие Git также большой плюс.
году эдак в 2010 интересовался этим вопросом: дай думаю посмотрю на хх.ру как с этим дела обстоят… смотрел ребят по 200-250 тыр.… итого: у 2х-3х в резюме были ссылки на git* и послужной список у всех был не короткий… так что «Наличие Git также большой плюс. » только в научных статьях по подготовке резюме встречал, а в жизни «всё немного разнообразнее»
С такими статьями было бы весело, если бы существовал условный профсоюз джунов, который объявил бы забастовку года эдак на 3 - просто обвалилось бы количество новых людей в индустрии до нуля. Интересно было бы посмотреть, появлялись бы статьи "джуны не нужны" после этого.
А забастовка против чего? Что их на работу не берут? Нас не берут на работу. по этому мы не пойдем к вам на работу и будем 3 года жить на солнечной энергии? Ну это странно,
А что джуны будут кушать все эти 3 года? К тому же за время этой забастовки цены на джунов постоянно будут повышаться, и я не уверен, что у всех джунов хватит силы воли жертвовать собственными интересами в угоду общественно-джуновским
К тому же за время этой забастовки цены на джунов постоянно будут повышаться
Не будут (точнее, будут не постоянно, а, вероятно, под конец этой забастовки, когда нехватка мидлов вырастет до такого уровня, что будут готовы вместо них брать джунов). Будут расти цены на мидлов (ведь пополнения нет).
И что самое неприятное – в первую очередь такая забастовка ударит по фирмам, которые готовы нанимать и учить джунов.
А что джуны будут кушать все эти 3 года?
Пойдут в другие специальности, есть много разного. К примеру, квалифицированных сварщиков всегда не хватает. Всё равно за время "забастовки" они до мидлов не дорастут.
Пойдут в другие специальности, есть много разного.
Т.е. в разработку они не вернутся, значит забастовка будет бессрочной. В итоге они пожертвуют своей карьерой для следующего поколения джунов, так что ли?
Почему "для следующего поколения джунов"? Просто пожертвуют. Точнее, поменяют карьеру в IT на другую, на IT свет клином не сошёлся.
Имею в виду - нафига им это делать? Если бы они умели и хотели заниматься чем-то еще, они бы так и поступили
Ну, если туда можно наняться и там платят – то почему нет?
Если бы они умели и хотели заниматься чем-то еще, они бы так и поступили
Жизнь заставит – научатся и захотят. Не стОит их недооценивать.
Я их не недооцениваю. А вот вы, кажется, переоцениваете привлекательность it - если за время "забастовки" они получат другую профессию, зачем бы им потом ее менять, снова начиная с начала?
Незачем. Я про это и говорю: будет у нас меньше джунов-программистов (раз на них спрос низкий), но больше специалистов в других областях.
Ну или иначе можно сформулировать: чем устраивать забастовку на три года (джуну-то) – лучше поменять профессию. Может, за эти три года до мидла-сварщика дорастёшь.
Правда, всё это ведёт к "трагедии общин" – новым мидлам-программистам будет неоткуда взяться (все "собирают урожай" мидлов, но никто не заботится о "поле", на котором они растут). Но это забота не джунов, а фирм по разработке ПО.
Тут такое дело, что скорее всего джунов будут набирать из ВУЗов и профильных колледжей, так как это наименее рискованная категория, а "вАйтишники" пойдут обратно работать в продажи или таки дорастут до сеньора-сварного.
Это да.
Я говорил про гипотетическую (фантастическую, откровенно говоря) ситуацию "забастовки джунов" – когда нанять их станет вообще невозможно (из колледжей сразу будут уходить на переподготовку в сварщики). Т.е. три года без новых джунов в разработке. Когда будет, как в лазере – инверсия населённостей уровней :-)
Т.е. в разработку они не вевернутся
Откуда это следует? Будут брать джунов — уберут в гараж сварочные маски, и пойдут на собеседования в IT.
Ну хоть статья и имеет немного агрессивный оттенок в начале, но прямо сказано, что:
В общем, в этой статье разберу причины, почему джунов все еще не хотят брать на работу. И расскажу, как должен развиваться начинающий разработчик, чтобы быть конкурентоспособными. В конце — бонус от меня и команды Holyweb.
И дальше перечислены пункты,которые будущему кандидату стоит подправить перед подачей отклика на вакансию.
По опыту набору Junior разработчиков к себе в команду могу сказать,что в идеале у кандидата не будет выполнено каких-то пунктов. Мало pet projects, не сразу прикрепил ссылки на репозиторий и etc. И это абсолютно нормально, окончательная полировка специалиста будет во время практики в команде. И в итого можем получить специалиста под свой стэк с опытом, хоть и пришлось вложить в это сил. Ну и кандидата в сферу подарили, что она жила и процветала.
Причина подмена понятий джун и стажер. Джун готов не дорого выполнить простую задачу, то есть принести денег нанимателю. А стажера надо учить, это убыток для предпринимателя. Но могенники от курсов так и говорят: "три месяца и джун". Хотя так не бывает.
Это вы подменяете понятия. Нет такой характеристики уровня опыта "стажер". Стажер это тот, кто проходит стажировку. Если в компании нет стажировки, нет и стажеров. "Junior" переводится как "младший", и все разработчики без опыта входят в эту категорию, так как по определению не могут быть старшими.
Минусующим без аргументов рекомендую прочитать вот эту статью с описанием уровней опыта (на том языке, в котором появились эти термины):
Understanding Junior, Mid-Level, and Senior Developers
(подсказка: там нет никаких стажеров)
А также словарь русского языка:
http://www.gramota.ru/slovari/dic/?word=%D1%81%D1%82%D0%B0%D0%B6%D0%B5%D1%80&all=x
СТАЖЁР — Тот, кто проходит стажировку где-л.
https://slovar.cc/rus/inostr-nov/1431043.html
СТАЖЁР ( фр. stagiaire) — лицо, проходящее испытательный стаж.
https://dic.academic.ru/dic.nsf/ushakov/1040986
СТАЖИРО́ВКА — Прохождение испытательного стажа на какой-нибудь работе.
там нет никаких стажеров
Цитата из приведённой вами статьи: "A good junior developer is a specialist who has completed courses or an internship".
В американских реалиях понятие intern очень близко по сути к стажёру. Настолько, что в reverso в трети случаев переводится именно так.
И, в целом, в указанной вами статье как раз говорится, что (хороший) джун должен иметь "the ability to solve simple tasks, but with support" и "basic knowledge of the profession".
Таким образом, заявляя, что все разработчики без опыта входят в категорию джунов, вы, по сути, противоречите собственным источникам. Потому что даже способность решать простейшие задачи и наличие базовых знаний о профессии не появляются из ниоткуда - это тоже знания и навыки, которые требуют приобретения. И вот здесь как раз появляется категория интернов/стажёров, из которых очень скоро получаются джуны.
Надо признать, что в некоторых направлениях разработки стажёры будут неотличимы от джунов - в конце концов, понятия "простая задача", "базовое знание" и даже "разработчик" довольно растяжимы. Но отрицать их существование - слишком категорично.
Хотя, тот, кому вы отвечали, на мой взгляд тоже слишком категорично высказался по поводу доходов, убытков и потребностей в обучении у джунов.
Цитата из приведённой вами статьи: "A good junior developer is a specialist who has completed courses or an internship".
Я как раз так и сказал — стажер это тот, кто проходит стажировку (an internship). Пока он проходит стажировку, он intern, когда закончил, уже не intern. Но если он не проходил стажировку, он все равно junior developer.
При этом стажировку могут проходить и опытные специалисты (под руководством более опытных).
в указанной вами статье как раз говорится, что (хороший) джун должен иметь
Там также говорится "they lack a little experience". Я не говорил, что джун не должен это иметь.
Потому что даже способность решать простейшие задачи и наличие базовых знаний о профессии не появляются из ниоткуда — это тоже знания и навыки, которые требуют приобретения.
Это делается в университете и при выполнении собственных проектов. Если человек умеет программировать, но у него нет опыта работы, это Junior. Просто по определению слова "Junior", его придумали, чтобы обозначать эту категорию работников. Если человек не умеет программировать, его вообще нельзя назвать developer, и понятие "junior/middle/senior" к нему неприменимо.
Но отрицать их существование — слишком категорично.
Я не отрицал, я сказал, что понятие "стажер" не является общепринятой характеристикой уровня опыта. Оно существует параллельно им и связано с процессом прохождения стажировки.
Ну, как бы да. "Стажëр" не является общепринятой характеристикой уровня опыта. Потому, что это человек вообще без опыта и знаний. Это российские реалии: ваш оппонент - не единственный, кто делит джунов на непосредственно джунов и стажëров. Причина банальна: джун может решить поставленную задачу по написанию кода. За N попыток, с помощью наставника. Стажëр вообще не знает, что ему делать, как начать писать код или куда ему думать, чтобы решить проблему. Увы, такие люди приходят и из ВУЗов.
«Junior» переводится как «младший», и все разработчики без опыта входят в эту категорию, так как по определению не могут быть старшими.То ли логическая ошибка, то ли сознательная манипуляция.
Junior developer == младший разработчик. То есть пусть и младший, но всё-таки разработчик. А человек совсем без опыта не является разработчиком. Ни старшим, ни младшим, никаким.
Поэтому да, джуниор это человек хотя бы с небольшим, но опытом. Умеющий решать несложные, но всё-таки задачи. И уже обладающий минимальной самостоятельностью.
Нет, разработчик (программного обеспечения) это тот, кто умеет разрабатывать программы (то есть программировать). Если человек не умеет программировать, он не является разработчиком, если умеет, является. Независимо от того, сколько у него официального опыта работы.
Developer
"a person or company that creates new products, especially computer products such as software"
Junior
"0–3 years’ experience"
Junior developer
"0 – 1.5 years of experience"
это тот, кто умеет разрабатывать программы (то есть программировать)Если программировать == уметь разрабатывать программы (а не просто знать синтаксис), то я именно это и написал. Умение это появляется после участия в решении реальных задач. Опыт не обязан быть записанным в трудовой книжке, но он должен быть реальным.
Пресловутые курсы такого опыта не дают, как правило. Сферический пет-проект в вакууме скорее всего тоже (ну блин не бывает такого, что человек нигде и ни с кем не работал, но запилил в одно лицо что-то серьезное). Универ — там когда как, по-разному бывает.
Умение это появляется после участия в решении реальных задач.
Нет, после участия в решении реальных задач появляется опыт решения реальных задач. А опыт программирования появляется после участия в программировании, даже если это не реальные задачи. Может сделать тестовое задание, значит умеет программировать, несмотря на то, что это не реальная задача.
И выполнить тестовое ещё не значит уметь программировать на уровне, достаточном для работы. Если речь идет о молодежи, от тестового обычно не ожидают идеального исполнения (лично я не ожидаю). Как правило, цель посмотреть на стартовые данные и понять, насколько человек перспективен/безнадежен.
Там фигурирует слово «разработка». Разработка — это промышленный процесс
Ну давайте еще и на это цитату из словаря приведу.
Разработка программного обеспечения — это род деятельности (профессия) и процесс, направленный на создание и поддержание работоспособности, качества и надежности программного обеспечения.
Вики
Разработка программного обеспечения — деятельность по созданию нового программного обеспечения.
Программное обеспечение — программа или множество программ, используемых для управления компьютером.
Про промышленность ничего не говорится.
И выполнить тестовое ещё не значит уметь программировать на уровне, достаточном для работы.
Неважно, что он не умеет программировать на уровне, достаточном для работы в вашей компании. Важно, что его можно назвать junior developer, даже если у него еще нет официального опыта работы. Разрабатывать умеет, значит developer, мало опыта, значит junior.
Всё верно, разработка это деятельность по созданию ПО. Но включает она не только написание буковок кода. Я всю дорогу пытаюсь донести мысль, что это более комплексный процесс, включающий анализ требований (да, у джуна он тоже есть, на своем уровне), взаимодействие с коллегами разных специализаций, выполнение регламентов и пр. И вот всё это приходит с реальным опытом.
Ну а я пытаюсь донести мысль, что даже если человек знает эти вещи неидеально, а "на своем уровне", то он все равно разработчик. "Junior/middle/senior" это и есть обозначения этого уровня. А по вашим словам получается, что разработчиками можно называть только senior-ов с опытом работы не менее 10 лет, потому что у остальных опыта мало, и это "всё" пришло еще не всё.
Стандартная классификация в IT: junior — коммерческого опыта нет или менее года, начинающий разработчик; middle — опыт 1-3 года, участие хотя бы в одном проекте, разработчик с небольшим опытом; senior — более 3 лет, квалифицированный специалист.
"и все разработчики без опыта входят в эту категорию"
Только вы джуном без опыта работы не устроитесь (ну в России по крайней мере). Может с точки зрения терминов они и входят, но на практике джуном без хотя бы минимального опыта (3-6 месяцев, а лучше год) не берут. Поэтому этот пробел и заполняется словом "стажер", потому что других не придумали еще, может введут чего со временем
Ну так это проблема компаний, которые не берут. Я вообще не очень понимаю, зачем для этого надо придумывать дополнительный термин. Не соответствует требованиям, значит не соответствует требованиям, хоть джун, хоть не джун. Такое ощущение, что это используется как какое-то моральное оправдание "Мы джунов берем, мы хорошие, а те кого не берем, они не джуны, они стажеры".
Нет никакой проблемы у компаний и не должны они ни перед кем оправдываться, хотят берут, хотят нет. Есть противоречие в том что джун - человек без опыта и что нет, практически, ни одной вакансии на джуна, где этот опыт не требуется. И чтобы это противоречие как-то для себя закрыть люди и используют термин стажер
разработчики без опыта входят в эту категорию
Разработчик без опыта, это нью град, а джун, это как раз разработчик с опытом, но небольшим, например с годом опыта.
"New graduate" входит в понятие "junior". При этом junior developer может и не быть недавним выпускником, но быть тоже без опыта.
Junior C++ Software Developer — New Graduate
Нет, не входит. Когда я нанимаю человека, мне всегда важно, есть у человека хоть какой-то опыт или нет.
но быть тоже без опыта.
Не может. Его могут взять на роль джуна, но пока его не взяли (мы же это тут обсуждаем), он не джун.
Входит, я же привел ссылку на вакансию. Она для Junior и New Graduate одновременно.
Вот еще ссылки 1, 2.
Умеет разрабатывать и имеет опыт от 0 до 2 лет это определение термина "Junior developer". Это просто факт, это единственная причина появления этого термина, непонятно, почему надо делать вид, что это не так. Junior/Middle/Senior это общепринятые термины, 4-го общепринятого термина в этом контексте не употребляется.
Входит, я же привел ссылку на вакансию. Она для Junior и New Graduate одновременно.
Нет, не входит. Сходите по ссылке, которую я привел выше и почитайте про контрпример. И зачем бы в вашей вакансии нужно было употреблять оба термина, если это одно и то же..
И не нужно мне давать ссылки на неизвестные бложики. Для компаний эта разница есть и она существенная. Существенная настолько, что они пишут это в вакансиях.
Умеет разрабатывать и имеет опыт от 0 до 2 лет это определение термина "Junior developer".
Нет. Джуном можно оставаться и с 10 годами опыта. Про 0 читайте выше.
Это просто факт
Это просто ваше неверное понимание ситуации. Но мне надоел этот бессмысленный спор. За сим откланяюсь.
Сходите по ссылке, которую я привел выше
Там нет контрпримера для Junior, там вообще про Junior ничего нет. Там говорится, что New Grad это кто недавно выпустился или собирается. Это не противоречит моим словам.
И зачем бы в вашей вакансии нужно было употреблять оба термина, если это одно и то же..
Как раз затем, что одно это подмножество другого, второй термин уточняет первый. Если бы были разные, это было бы бессмысленно, так же как "Junior С++ Developer — Senior".
И не нужно мне давать ссылки на неизвестные бложики.
Тред на HN с 2 комментариями это конечно солиднее)
Это просто ваше неверное понимание ситуации.
Это не только мое понимание ситуации, о чем и говорят приведенные мной ссылки.
Для компаний эта разница есть и она существенная.
Я ничего не говорил про то, что она несущественная. Опыт работы N лет это такой же существенный фактор, как знание языка X или фреймворка Y. Чтобы указать это требование в вакансии, нет необходимости менять общепринятые границы слова Junior.
Все эти джуны-синьоры - это слишком неформальные термины, каждый их как хочет - так и понимает.
И все-таки чаще всего мне встречалось понятие слова "джун" как "начинающий неопытный разработчик, требующий постоянного контроля и наставничества". Самостоятельно джун может решать задачи только в духе "сделать кнопку для тривиальной фичи", и то после того, как ему расскажут и покажут все.
И да, это убыток, так как опытный разработчик часто сделал бы все быстрее и лучше сам, чем объяснять то же самое джуну.
Учить джуна нужно только если его наняли на позицию мидла. А джун умеет выполнять работу джуна за зарплату джуна. То есть приносит прибыль а не убыток. На вакансию мидла не стоит нанимать джуна, тут будет убыток на обучение, чтобы небыло убытка нужно нанимать мидла.
На первый взгляд в этой логике есть резон.
Только вот в нормальных, интересных проектах я почти никогда не встречал "работу для джуна" - т.е. такие задачи, которые джун, с одной стороны, способен делать относительно самостоятельно (потому что если его активно менторить, то никакой прибыли там точно не будет), а с другой стороны то, как он их решит не нанесёт проекту ущерб/тех.долг, который с гаком сожрёт всю прибыль уже в следующие пару месяцев.
Я допускаю, что такие проекты существуют, вероятно там много однотипных простых задач при решении которых качество кода не имеет большого значения… Только вот я не зря упомянул "нормальные, интересные проекты" - в такой проект где есть прибыль от джунов не пойдут работать квалифицированные разработчики… а, значит, джунам не у кого будет учиться даже самостоятельно, при том что, как мы уже выяснили, менторить их никто не планирует… так что, внезапно, джун, который в принципе планирует вырасти до зарплаты миддла в такой проект тоже не пойдёт (ну, дольше чем на 2-3 месяца, пока не разберётся что тут происходит).
Странно, но почему не вы не считаете, что внутри одного проекта могут быть как "нормальные, интересные" задачи, так и достаточно тупая и ограниченная работа?
Ну не совсем так. Видел несколько раз на зрелых проектах. Там оставались несколько сеньоров и куча джунов. Сеньёрам интересные, сложные задачи, проработка архитектуры и постановка задач для джунов, а последним - куча простых, атомарных задач не требующих каких-то особых навыков и контроль, ревью и помощь от более опытных колег. Проблема в таком проекте - нет потребности в мидлах. И как следствие, когда Джун растёт у него один путь: менять работу.
Согласен. Даже за полгода-год обучения на курсах можно стать максимум потенциальным стажёром. Джуном - после такого же срока работы на реальных проектах.
А стажера надо учить, это убыток для предпринимателя.
Любого специалиста надо учить, как минимум особенностям вашего проекта. Поэтому на больших проектах даже Senior-специалисту на первое время выделяют наставника.
Тут тоже подмена понятий. Учить делать работу, и погружение в проект или онбординг на новом месте, это сильно разные вещи. Последние нужно и senior'у.
Нет, это одинаковые вещи, связанные с изучением новой информации. Изучить, как что-то делается в языке, в библиотеке, или в проекте, принципиально ничем не друг от друга отличается. Просто предполагается, что язык разработчик должен знать.
Вот устроились вы программистом на PHP, а через месяц на проекте внедрили Go для части функционала. Что-то для вас изменится в подходах к изучению? Нет, так же откроете документацию и будете разбираться, как и с основным проектом.
Логично, потому что мой уровень будет недотягивать до джуна на Go. Или начну писать на Go, простое и плохо, если у меня есть уровень джуна на Go.
Не переживайте, хорошо на го писать невозможно. :)
:) Зря вы так, джависты привносят ООП и патерны банды 4х, все обвешивая интерфейсами, функциональщики пишут простые микросервисы и быстрые, где просто ООП, ORM и т.п. не нужны. И это все весьма быстро и стабильно работает. :)
Го имеет к функциональному программированию даже меньше отношения, чем джава. О чём вы?
Как вы считаете, чистая функция возможна на Go?
Из головы - чистая функция возможна на любом известном мне ЯП, включая го и упомянутую выше джаву. Возможность написать оную не является критерием того, что язык способствует функциональному подходу в программировании.
Вот то, что в го нельзя делать иммутабельные поля структур, и делать финальные переменные не-примитивных типов (const там есть только для литералов примитивных типов - даже не вызовов функций), куда больше мешает писать на го в функциональном стиле.
Я бы вообще сказал, что го максимально далёк от современного ФП, дальше всех из всех современных - в смысле относительно новых - языков, активно применяющихся в промышленной разработке.
Согласен, с константами и константными аргументами при передачу в функцию не очень, но можно по значению передать, горантировав неизменость. Наверно правильнее мне было сказать "процедурному програмированию". Да и микросервисы c GRPC и JRPC способствуют. :)
Процедурному - да, но процедурно программировать опять же никто не мешает на той же джаве.
Микросервисы с невыразительным write-only кодом с корявой или отсутствующей обработкой ошибок, которому способствует го - это плохо. GRPC можно и в других, более адекватных ЯП использовать.
Ошибки могут оборачиватся по цепочке и так выходят на верхние слои, где цепочка разворачивается. Что плохого? То что выглядит не try-catch, но вполне работает. На худой конец и panic ловится в defer...
Плохо то, что язык (и используемые коммьюнити инструменты и практики) не предоставляет механизмов предоставления информативных ошибок, с которыми удобно работать в коде программы. Исключения удобны как раз тем, что вы можете ловить конкретные, вам позволяет делать это система типов, и также можете информировать при желании, какие именно ошибки могут быть штатно выкинуты наружу. И исключения - ещё не лучший механизм, так-то.
Изучить, как что-то делается в языке, в библиотеке, или в проекте, принципиально ничем не друг от друга отличается.
Отличается. В случае проекта - мы большей частью изучаем(исключение - когда все пишется 'с нуля'), как в проекте что-то делать принято, чтобы делать это так же. Чтобы каши из разных способов делания одного и того же не создавать.
Когда же изучаешь язык или библиотеку - то просто необходимо попробовать так и эдак, посмотреть, что получилось, решить для себя, какой из способов лучше и когда что применять. В частности пробуешь совсем экзотические и странные способы, которые в реальном боевом коде скорее всего применять не будешь -- просто для того чтобы посмотреть 'что получится' и для того, чтобы свойства/устройство библиотеки было нагляднее и лучше в голове уложилось.
Возможно, более наглядное объяснение - это разница между изучением обычного (человеческого, на котором говорят) языка и изучением того, как тот язык, что знаешь, для написания текстов по конкретной теме использовать.
Джун значит молодой. А интерн значит стажёр. У врачей ординатура занимает 2 года. У технарей обычно необычней. Чтобы успешно закончить аспирантуру наукой желательно заниматься со 2-3 курса.
Хватит обесценивать понятие "пет-проекта". Очередной "давайте напишем авторизацию на спринг-буте" - не пет проект. "Я научу вас формошлепать на анугляре" - не пет проект. Это, грубо говоря, детская раскраска. Контуры уже проведены - осталось фломастерами поработать. Так-то и литкодинг можно громко назвать "пет-проектом". Да, такие вещи необходимы, но раньше мы их скромненько называли "примерами".
Пет проектами в свое время были например nginx и scala. То есть люди в свободное время трудились первопроходцами, а не пирамидки из кубиков собирали.
Совет "начать пет-проект" тоже глупость несусветная. Сначала нужно увидеть какую-то проблему в своей рутине или в индустрии в целом, а потом иметь достаточный скилл, чтобы предложить новое решение проблемы. И это будет пет-проект
Пет проектами в свое время были например nginx и scala
TempleOS, вот это я понимаю пет-проект
Да берешь любую мелочевку (тудушник, финмониторинг семейный) и пилишь. Нет такой фиговины "искаропки" которая полностью бы удовлетворяла.
Так что если есть осознание нужности петпроекта, то можно его сразу начинать выбрав любую софтину, которой ты пользуешься, но в ней чего-то не хватает. Если она опенсорсная — еще лучше. Можно форкнуть и даже не слать MR в головную ветку.
Да, это не продашь, даже не соберешь миникомьюнити, так как на рынке все поделено и править баги, которые у тебя не воспроизводятся даже для знакомых лениво. Но это будет пет, это будет твой код, который можно показать на собеседовании, и это будет штука "по индивидуальной мерке".
К сожалению, в 99,99% случаев воннаби-джун будет делать такой пет, срисовывая один из миллиона туториалов в интернете - или, хуже того, все туториалы разом.
Если у меня на главной странице репозитория возникнут подозрения, что "пет-проект" джуна - очередной такой "а давайте перепишем туториал, переименовав только доменные объекты", я не стану даже смотреть на код, потому что с огромной вероятностью голова при написании кода включалась только, как подставка для глаз при копипасте из туториала.
Пет это не написанное, это используемое лично. Или хотя бы пишущееся с целью личного использования. "а давайте перепишем туториал, переименовав только доменные объекты" — это не жизнеспособный объект.
А вот "моя домашняя бухгалтерия" — жизнеспособный. Даже если половина там вообще мастерами платформы сделана через некст-некст-некст. Вторая то половина допилена так, чтобы мне удобно было. Причем удобнее, чем 1С: Деньги.
Но скорее всего в таком пете способности к написанию хайлоада не продемонстрируешь.
Сути дела это никак не меняет: если человек пишет, пусть даже и искренне для себя, что-то по туториалам из сети с минимумом личных усилий и рисёрча (раз мы говорим о начинающем изучать программирование без реального опыта), это не показывает его способности и знания.
БольшАя часть работающих уже ненулевое количество лет программистов тоже способности к написанию хайлоада никак не демонстрирует, если честно.
Если он не пишет иначе — это как раз показывает его способности и знания.
Он может найти туториал и дернуть из него нужный кусок.
Когда он придет в вашу компанию с большим легаси проектом (или не легаси) он точно так же будет дергать похожие вещи из соседних кусков проекта, туториалов и SO. Отличные навыки для джуна.
Как в анекдоте про научные уровни — диплом это компиляция из научрука, кандидатская — из литературы, вот в докторской можно и от себя что-то написать.
Он может найти туториал и дернуть из него нужный кусок.
Во-первых, к сожалению, как правило дёргают туториал плюс-минус целиком.
Во-вторых, человек, навыки которого ограничиваются "может дёрнуть кусок из туториала, но не может проанализировать, разобраться, написать своё" - это терпимый стажёр, может быть, но даже на джуна такой кандидат восторгов не вызовет, потому что люди с головой и знаниями есть, и они куда лучше, чем вот это вот
- Если пет используется в повседневной жизни, то там точно есть места в которых разобрался и подпилил под себя.
- "но не может проанализировать, разобраться, написать своё" из п.1 это не так. Ну и проанализировать, разобраться — это мидл и выше. А самое смешное, это то что в 80% после "проанализировать, разобраться" будет "и дернуть из проекта/туториала/SO" даже у мидла. (Сеньер или по памяти напишет, или шаблон вставит).
Если пет используется в повседневной жизни, то там точно есть места в которых разобрался и подпилил под себя.
Нет, не точно. :)
Ну и проанализировать, разобраться — это мидл и выше
Нет, способность это делать - минимальные требования к тому, чтобы человек фулл-тайм занимался чем-то, кроме крудошлёпства.
"Сначала нужно увидеть какую-то проблему в своей рутине или в индустрии в целом, а потом иметь достаточный скилл, чтобы предложить новое решение проблемы."
Короче, нескоро или вообще никогда. Сначала накроет рутиной, потом дети-ипотеки, а потом уже и лет под сраку. Имхо, лучше делать, пока хочется -- и как можется.
Ну и сколько ты написал "nginx и scala" во времена своего джуниорства?1
Да, есть такое дело. Поставьте себя на место того, в чью команду попадает джун. Теперь у тебя, как у тимлида, помимо своих задач, есть еще буйный зверь на коротком поводке, в которого вливать, дрессировать и вытирать сопли еще минимум полгода, тратя на это силы и время. При этом объяснять начальству, что этот +1 к команде если и сказался на приросте общей производительности, то, вообще-то, отрицательно. Тут обычно никто ничего такого слышать в приницпе не желает, и в итоге ты херачишь и за себя и за того парня, с натужной улыбкой на губах и единственной мыслью "ну, все же когда-то были джунами..."
Потом проходят полгода-год, и джун уже что-то может. Даже, может, неплохо может, но вот проблема: он же не дурак, и понимает, что он теперь стоит на рынке больше. Ты идешь к начальству и говоришь, что: "...крутой чел, накиньте ему деньжат...уйдет же.." А тебе говорят, что "...пусть проявит себя... пусть подождет до следующего повышения..." и проч. хрень. А круче всего обычно слушать: "да на такие деньги мы могли бы и не джуна взять!". Да, блин, могли. И так и надо было сделать, и не есть никому мозги!
Денег в итоге не дают, и джун уходит на двойную зарплату, потому что ты хорошо отработал. И за себя и за джуна и за наставника. Но... нафига?
Всё так, но именно во втором абзаце вы и обозначаете:
А круче всего обычно слушать: "да на такие деньги мы могли бы и не джуна взять!"
Т.е. проблема-то не в том, кто вырастил специалиста (он, безусловно, крут), а в том, кто так распорядился кадрами и инвестициями в них.
Начальство думало, что джун останется потому, что "это честь работать в компании, которая его вырастила", хотя само при этом исходило только из корыстных побуждений.
Ну так инвестиция - это когда вы сперва несете убытки, а затем получаете прибыль, их компенсирующую.
Если же джуну потом повысить зарплату до рынка - то получается, что сперва вы получили убытки, а потом не получили ничего - могли бы сразу взять миддла по рынку.
А по факту джуну надо будет давать выше рынка, чтобы удержать. Потому что джуну еще все интересно и хочется попробовать другие работы и технологии, так что он изначально будет мотивирован свалить от вас после пары лет. Потому что есть условные сберы-яндексы, пылесосящие кадры, с которыми вы не сможете конкурировать в деньгах, хипстерности офиса и пафосности строчки в резюме.
Ну и нафига оно? Сперва нести убытки, чтобы потом еще и доплачивать ему выше рынка чтобы удержать?
Не, это вы чтобы сманить мидла, получающего по рынку* должны заплатить ему выше рынка (и продолжать так платить, пока он у вас работает). А джуну вы можете поднять до рынка и сэкономить.
*под рынком понимается средний оклад работающего на такой должности или оффер на который ведется не работающий в данное время кандидат, а не средний оффер, на который удается сманить работающего на насиженном месте.
С вашей точки зрения это описано так, будто тимлид сам этого джуна притащил и всем объясняет, почему он нужен и почему надо ему платить. Но вообще нормальная позиция должна идти от обратного - компания решила нанимать джунов как долговременную инвестицию, ибо не может позволить себе нанимать нормальных миддлов в команду. Да, для тимлида это всё равно геморрой, но если некое начальство это ещё и не устраивают - пусть забирают обратно, не тимлид его нанимал. Если же начальство сплошь из идиотов, а тимлид молодец - так ему и самому лучше найти другую контору, скорее всего, на нём тоже экономят.
Но вообще нормальная позиция должна идти от обратного - компания решила нанимать джунов как долговременную инвестицию, ибо не может позволить себе нанимать нормальных миддлов в команду.
Имхо, это как раз ненормальная позиция. Если компания не может себе позволить нанимать нормальных миддлов, то она тем более не потянет нанимать и растить джунов.
Из моего опыта, если завязываться на долгосрочную перспективу, схема должна быть такой: на старте компания берет только сеньоров, чем больше вырастает, тем менее опытных людей может себе позволить.
Я, разумеется, говорю про ситуацию, когда работа идет над более или менее сложным продуктом, и целью является написание и долгосрочное его сопровождение. Компаний с политикой "денег нет, наймем одного джуна и пусть он будет фуллстэком, а там разберемся" я стараюсь избегать.
Код пиши нормальный, умник. Берёшь Джуна, говоришь делай так же, как у нас и всё норм. Если у тебя код нормальный, чистый, ясный, архитектура понятная, то джун прекрасно справляется. А если твой проект рассыпается от любого тычка, примеров нормального кода нет, непонятно куда смотреть и зачем, то нечего жаловаться. Ещё и джуну мозги сломаешь, он на следующий проект придёт и будет такую же трешанину писать.
Если тимлид не может выбить заслуженное повышение подчинённому, он не дорабатывает. Если тимлид может, а это просто начальство такое недалекое, то его везде с руками оторвут и он сможет быстро найти работу с более дальновидным начальством.
С джунами не хотят связываться просто в силу того, что новичок это долговременная инвестиция, бенефит которой уйдет другой компании. В ситуации, когда среднее время работы в IT компании 2-3 года, а на "ветеранов", работающих на одном месте 5-6 лет смотрят как на случайно выживших, скорее всего невостребованных на рынке труда, ламантинов, вкладываться в подготовку человека, который начнет приносить ощутимую пользу только через несколько лет, смысла нет. Все равно уйдет, и спасибо если не к конкурентам. Лучше искать полгода, но найти человека. который начнет работать просто полистав пару дней onboard-доку.
Это сложившиеся реалии рынка. Новичкам можно пожелать только терпения и упорства, через барьер поиска первой-второй работы пробиться трудно, но возможно. Джуном был каждый профи.
PS.
Лайфхак: если вы очень сильно хотите попасть в какую-то конкретную компанию, предложите работодателю поработать тест-драйв — поработать 1-2 недели бесплатно без оформления.
Это нарушение ТК, тащемта. Нормальную компанию такие предложения могут только отпугнуть.
С джунами не хотят связываться просто в силу того, что новичок это долговременная инвестиция, бенефит которой уйдет другой компании. В ситуации, когда среднее время работы в IT компании 2-3 года, а на "ветеранов", работающих на одном месте 5-6 лет смотрят как на случайно выживших, скорее всего невостребованных на рынке труда, ламантинов, вкладываться в подготовку человека, который начнет приносить ощутимую пользу только через несколько лет, смысла нет.
Отчасти справедливо, но только отчасти.
Да, это так для значительной доли IT компании, где используется "конвейерная разработка" с использованием типовых инструментов. Где не надо вникать в предметную область и во всякие тонкости архитектуры. Да, сейчас такого много. И тут, действительно, джуны без опыта особо и не нужны - есть варианты найти человека, который начнет "гнать код" с первых дней трудоустройства. А с учетом того, что джунов без опыта сейчас навалом...
Но это не весь IT рынок. Есть места, где первые 2-3 года человек только растет от простых задач к сложным. И только после этого становится полностью самостоятельным разработчиком. Но это не те области, в которые на курсах готовят. Хотя работу джуном тут найти проще - никто не расчитывает на моментальную отдачу, есть время на обучение и погружение.
Я другое не могу понять, в чем проблема заключить контракт на какой-то срок, например на полгода или год? и при расторжении( например заявление по собственному), на работника сыпятся кары египетские, в виде штрафа за расторжение контракта и тд. Логично, что не каждый согласится на такие условия, но нам все джуны города и не нужны
PS.
Это нарушение ТК, тащемта. Нормальную компанию такие предложения могут только отпугнуть.
Оформить на этот период стажировку. Не знаю как в РФ, у нас в стране ( Молдова ) это делается гораздо проще, даже без трудовой книжки и тд, а зп при удачном завершении можно прописать как премирование, что даже налоги не нужно будет выплачивать с этого
Я другое не могу понять, в чем проблема заключить контракт на какой-то срок, например на полгода или год?
Полугода-года все таки, в общем случае, слишком мало для роста джунир->специалист. А заключать кабальные договоры на несколько лет... Эпоха рабовладения все-таки прошла.
Оформить на этот период стажировку.
По ТК РФ стажировка должна быть оплачена. Понятно, что можно попробовать обойти, но это серое поле, на котором можно найти себе проблем. Зарплата за пару недель не стоит того, тут важнее само принципиально решение работодателя, - работаем с новичками или нет.
Оформить на этот период стажировку. Не знаю как в РФ, у нас в стране ( Молдова ) это делается гораздо проще, даже без трудовой книжки и тд, а зп при удачном завершении можно прописать как премирование, что даже налоги не нужно будет выплачивать с этого
Любая известная мне стоящая того, чтоб в неё устраиваться, компания будет бежать от кастомных серых схем непонятно ради чего и зачем, как от огня.
До короны найм начинающих бы довольно логичным под специфические задачи в многолетних проектах. Брали одного такого в каждую команду. Задача была проста - скинуть примитивный кодинг и чёрную работу на джунов, чтоб освободить опытных. Никто не сидел с ними, разве что на код ревью. Пол года они таким образом самообучались и плавно вливались в обычную работу.
Я уже лет 10 не хочу в джуны. Программирование как хобби и осталось. По возрасту все равно не возьмут ни в джуны, ни в стажеры.
А я бы посоветовал сходить на собеседования, с десяток хотя бы, оценить свой уровень и уровень вопросов. Главное при этом - не ставить никаких ожиданий, но постарайтесь не ходить в компании, которые выглядят как не имеющие IT-ценностей.
Собеседования - дичайший стресс, без шуток, но нередко оказывается, что имеющиеся знания недооценивают, и тем самым упускают возможности.
В фильме Не шутите с Зоханом есть примерно такой диалог
- Есть одно место, вон там. Салон Рафаелы.
- Хорошее место?
- Нет, дуратское, но они тебя возьмут.
Может быть стоит в начале устроиться туда, где устроят и твои скромные навыки. Это поможет не умереть с голоду.
- Это же на палестинской стороне улицы!
- Ты хочешь воевать, или стричь волосы?!
- Волосы стричь
В общем на мой взгляд, в начале нужно свои амбиции придерживать.
Может быть стоит в начале устроиться туда, где устроят и твои скромные навыки. Это поможет не умереть с голоду.
Амбиции придерживать можно, но время не резиновое, за его потерю никто не заплатит.
Если человек готов рассматривать фронтенд как хобби, то, полагаю, от голода он в данный момент не умирает.
Устраиваться куда попало - можно, но чем более упоротая контора, тем меньше там проработаешь, а такие "скачки" в резюме будут смотреться скорее негативно.
для джуна важен начальный "стаж", там хоть на почту, хоть на завод, лишь бы хоть как-то профильно было. У меня первая работа на заводе и была, что-то типа "инженер-электроник", по сути эникей, зп 5к. Если год отработал то это уже не "свечка" а вполне рабочее место. Свечка это "не прошел испытательный срок", хотя тут обоим сторонам выгоднее просто "забыть" такого сотрудника. Даже если это не сотрудник не прошёл, а компания. Да, и так бывает - "я просто не хочу тут работать".
О собеседованиях думаю с ужасом, поэтому решила, что фронтенд будет просто хобби
Поддерживаю комментатора выше - попробуйте сходить на собеcедования. Для того, чтобы перестать бояться собеседований, нужно на них ходить. Это я понял, когда после многих лет, проведённых в одной фирме, решил всё-таки сменить и проект, и фирму сразу. И вот втянулся, после первых 3-5-7 собеседований уже намного легче.
Ходите на собеседования. Узнаете хотя бы, какие направления ещё учить.
Короче джуны они как дети, в целом никому не нужны, потому что налогов не платят, и прибыли не приносят – одни расходы. Вот было бы круто, если бы люди рождались сразу взрослыми, а желательно еще и сразу с образованием :) Интересно, откуда возьмутся мидлы, если совсем никто не будет брать джунов?
Фриланс или своё дело.
А там дальше насмотренность (в случае с фрилансом - точно) даст определенные плоды.
Своё дело - там, может быть, сложно стать миддлом с общепринятыми подходами, зато кто скажет, что ты лох и неудачник, если у тебя своя контора (которая не обанкротилась)? Даже если там будет лютейший говнокод в основе бизнеса :)
На фрилансе нужно стартовать с хороших отзывов, получить которые без опыта то ещё приключение. Плюс, фрилансер, это человек, который варится в собственном соку, вероятность того, что кто-то будет делать ревью его кода и говорить, где он принял не лучше решение — минимальна.
P. S. Если ты успешен в ведении бизнеса, то не очень понятно зачем потом идти работать в компанию другого бизнесмена, да и не любят таких, знаю по опыту дальнего родственника — год искал работу, а в итоге оказалось проще найти денег на новый бизнес, тем более что сумма дохода в случае успеха побольше зарплаты мидла.
На фрилансе нужно стартовать с хороших отзывов, получить которые без
опыта то ещё приключение. Плюс, фрилансер, это человек, который варится в
собственном соку, вероятность того, что кто-то будет делать ревью его
кода и говорить, где он принял не лучше решение — минимальна.
Даже на freelance.habr.ru полно заданий типа сделать пару страниц сайта за 100 рублей или спасибо. Можно хотя бы с этого начинать.
Вот бы сейчас где-нибудь посмотреть пропорцию тех, кто пришел в профессию с фриланса, и тех, кто пробился через первичное собеседование, и начал расти в профессии.
Неплохой стратегией выглядело бы обучение студентов с реальной практикой на предприятиях (где для этого заготовлены специальные проекты), но как же это утопично звучит.
Фриланс или своё дело.
И то и другое сейчас одновременно затруднилось и потеряло переспективы всвязи с понятно чем.
Короче джуны они как дети, в целом никому не нужны
Но только до начала призыва.
нунуну, этак вы договоритесь, что и дети никому не нужны : "от них же никакой прибыли, одни расходы"
Ну, тащем-то чайлдфри не на пустом месте появились
Жду пока появится общество "Рожать в России - признак садизма"
Мне уже под 40 и ни разу не слышал, чтобы кто-то в окружении обсуждая рождение детей задавался вопросом - а захотят ли эти дети жить в России. Все размышления только в формате хочу ли я детей. Это печально.
То, что вы этого не слышите, не значит, что этого нет. Более того (ну, теперь с моей точки зрения) - часть людей уезжает именно из-за детей и их будущего.
Жду пока появится общество "Рожать в России - признак садизма"
Таких людей я многократно видел в интернетах, и есть такие среди знакомых моих знакомых. Уехали и родили детей (там), а в России жили - не хотели их даже ээ зачинать? В общем, делать.
Разве вечная проблема "Мы их обучим, а они уйдут / Мы их не обучим, а они останутся" имеет решение? :)
Щедро платить, например)
А, извините, за что? Выше описывался случай, когда взяли джуна, полгода учили его себе в убыток, он набрался знаний и уверенности в себе и попросил х*2 зарплату. Вопрос: почему не брать сразу профицитных людей на х*2 зарплату?
По моему опыту, свой человек нужен довольно редко. Например, свой квалифицированный сервисник нужен или если очень высокая цена простоя, или если очень много оборудования - в любом случае, когда приходящий сервисник или сервис-контракт банально дороже. И такого человека имеет смысл растить. А если и текучка большая, и особой нужды в разработчике нет, то, может, вообще зааутсорсить? С админами как-то так и разобрались, хотя еще лет 10 тому каждый владелец офиса считал, что ему обязательно нужна каморка с обитающим там на фуллтайме небритым мужиком.
Тогда небритые люди в растянутых свитерах были дешевле, а услуга админ-как-сервис только зарождалась
Вопрос: почему не брать сразу профицитных людей на х*2 зарплату?
Если рассматривать ситуацию с нуля, то смысла нет. Но джун-то уже есть, почему нельзя ему повысить зарплату? Это что-то из серии эффективного менеджмента класса "за что нанимался, за столько и паши" и "никогда не обсуждай зарплату с коллегами"?
А вообще ощутимый плюс в том, что не нужно посвящать нового человека в корпоративные секреты, выдавать доступы, забирать их потом, проверять насколько хорошо человек понимает задачи... нанять плохого разработчика очень легко, а если джун продержался достаточно времени, чтобы обоснованно просить повышения, то он скорее всего не плохой разработчик.
То есть повышая зарплату бывшему джуниору, который явно себя перерос, мы имеем явный плюс в его мотивации и лояльности. А увольняя его и нанимая другого человека мы имеем геморрой и неизвестность.
Вопрос: почему не брать сразу профицитных людей на х*2 зарплату?Потому что их не найти, уже давно все трудоустроены?
Тема с джунами уже множество раз поднималась, и единственный реальный способ удержать джуна — это начать платить ему по рынку после того, как он прокачается. Иных вариантов просто не существует.
А профит — это лояльный работник, которому вы хорошее повышение дали, который в курсе процессов компании. И которого вы в принципе уже нашли, а не полгода безрезультатно ищете.
Неоднократно говорилось, что джун - это инвестиция, со своими рисками и сроками окупаемости. Понятно, что если "купить" нельзя, то приходится или "делать" и удерживать, или пересматривать критерии нужности, но если "купить" таки можно, то зачем делать?
если "свободного газа" на рынке не хватает, то возникает забавная ситуация — рыночная цена как средний оклад Х, но на этот Х почти все трудоустроены. Чтобы купить=переманить нужно платить хотябы 1.3Х. Означает ли это, что рыночная цена 1.3Х?
Ну а взять джуна и поднять ему зарплату когда вырастет до мидла позволяет сэкономить бонус за переманивание, те самые 30%.
Согласен, но тут альтернативные затраты против 1,3х это зарплата стажера и пропорциональная потраченному рабочему времени часть зарплаты ментора. Смотреть надо, что ещё сказать.
Но есть ещё два варианта развития событий:
Стажер вырос не до миддла, а до джуна, а зарплату попросил миддловскую.
Из-за популярного мифа "чтобы постоянно профессионально расти, надо менять работу раз в год-два" можно потерять воспитанника уже после повышения зарплаты, но до возврата инвестиций.
Ну скорее из за реалий "устроится на большую зп проще чем выбить своевременную прибавку".
На меньшую зп уходят редко и значит кто-то другой был готов платить больше за этого кадра, значит слабо повысили.
Работодателю разрушить миф Но.2 ничего не стоит, кроме как проглотить свои собственные надуманные ограничения. Но это значит, что линейный менеджер должен не зассать, а пойти к начальнику или даже к начальнику начальника и попросить своим личным согласованием разрешить текущему джуну поднять зп до мидла, нежели нанимать мидла за полтора ценника. Очевидно, что хороших менеджеров, которые не ссут открывать дверь начальства с ноги и требовать необходимое в разы меньше, чем мидлов.
>лет 10 тому каждый владелец офиса считал, что ему обязательно нужна каморка с обитающим там на фуллтайме небритым мужиком.
На мой взгляд дело в технологии древних и общем уровне технической грамотности населения. Сейчас все по-другому.
1. Windows 10 гораздо живучее чем xp, покупается вместо с ноутбуком/пк. Сейчас у компаний на это есть деньги.
2. Файлопомойка сейчас в облаках за условные 700р/месяц
+300р за бакапы недельные.
3. Офис установить - по ссылке образ скачать, двойной щелчок, далее далее готово. ключ только введи. Куча бесплатных аналогов и онлайн версий.
4. У каждой бабы Клавы смартфон. может она не прошьет его под рут, но средняя секретарша и бухгалтерша уже не боится этих ПК шайтан коробок.
Вопросы из :
-Ой тут что то вылезло на английском.
Плавно перетекают в :
-Я нажимала так так и после было так. а теперь сяк. Сделай чтобы было опять так.
5. 1с в облаке.
У сбиса техподдержка по удаленке. Все чинит сама, только обратись.
Онлайн банки некоторые также.
6. Вирусы добрее. Сейчас вирус тебя монетизирует включая в ботнет. Раньше вирус тер тебе виндовс.
7. Сайт на хостинге, сделан этими же специалистами хостинга. Там же почта за +500р/месяц.
8. Первоначальная настройка всего этого специалистом дешевле чем средняя месячная зарплата в усть-зажопинске.
Это 90% того что надо фирме рога и копыта.
Со всякими автокадами и фотошопами посложнее, но если даже среднего специалиста по проектированию оставить в условиях отсутствия бородатого мужика в свитере то окажется что он может установить себе инструмент сам.
Я много таких фирм вижу. Мелким ООО или фирмам с низкими техническими запросами от пк (вроде тех что я перечислил выше) админ нужен разве что сильно иногда приходящий. Руководители сейчас это понимают.
Я нажимала так так и после было так. а теперь сяк. Сделай чтобы было опять так.
Латентный тестировщик детектед. У обычного человека это "раньше было иначе, как именно и когда - не помню, но сделай как было" ;)
Руководители сейчас это понимают.
Имхо, это ключевой момент. Я думаю, что через какое-то время люди начнут понимать, когда им нужен программист и какой.
хотя еще лет 10 тому каждый владелец офиса считал, что ему обязательно нужна каморка с обитающим там на фуллтайме небритым мужиком.
Лет 10 назад не так был развит наемный приходящий админ, и уж тем более компания, которая такое предоставляет.
Лет 10 назад уже можно было в магазине купить готовый собранный комп, но не всегда и не везде. А 20 лет назад так и вообще практически ТОЛЬКО самосбор, и без мужика в подсобке собрать было заметно дороже, если в конторе хотя бы 50-100 компов.
Лет 10 назад стоимость такого мужика была заметно дешевле, и требования к мужику заметно меньше, чем сейчас.
Не выход, всегда найдется тот, кто заплатит больше. Вопрос времени. Кто ищет, тот всегда найдет.
Яндекс давно это знает, огромное количество устарешей проприетарщины там - не от тупости руководства и перестраховки, а один из способов удержания.
Лояльность компании не совсем так работает. Пока твоя работа даёт тебе всё, что тебе нужно, ты на ней останешься чисто по привычке. Многие люди даже остаются на заведомо невыгодных работах просто потому, что боятся уйти в неизвестность. Чаще всего это происходит с первой-второй работой как раз, как у джунов.
А эти мифические люди, которые по мановению брови уходят к конкуренту, который больше заплатил... они как суслики, вроде бы существуют и все о них пишут, но я ни разу не видел их вживую.
90% текучки у нас — это люди, не справлявшиеся с задачами.
Пока твоя работа даёт тебе всё, что тебе нужно, ты на ней останешься чисто по привычке.
Так не часто и не у всех. У меня тоже примерно такая сейчас, но это просто повезло.
А эти мифические люди, которые по мановению брови уходят к конкуренту,
который больше заплатил... они как суслики, вроде бы существуют и все о
них пишут, но я ни разу не видел их вживую.
Они уходят не по мановению брови. Уходу предшествует целый комплекс проблем - начиная с непризнания заслуг руководством и кончая работой в коллективе, который тебе чужд. Зарплата - это лишь порог ухода, не более. Если разница в зарплате большая - перейти легче, если малая - то сложнее. Гораздо проще принять решение уйти в Интел с х1.5, чем в "Серожопов и К" с х1.2.
90% текучки у нас — это люди, не справлявшиеся с задачами.
С учетом контекста статьи - я правильно понимаю, что у вас остается только 1 джун из 10, остальных либо увольняют, либо они уходят сами?
С учетом контекста статьи - я правильно понимаю, что у вас остается только 1 джун из 10, остальных либо увольняют, либо они уходят сами?
Это не про джунов, а про разрабов в целом) И нет, неправильно. Смысл был в том, что те, кто уходят, уходят не из-за з/п, а потому что их увольняют из-за несоответствия должности.
Эмм... То есть из 10 разработчиков - не джунов - оставивших вашу компанию, 9 были уволены по несоответствию должности? Это даже для торговли перебор, а уж для ИТ...
Там у вас на выходе люди с автоматами стоят, или, с поправкой на 21 век, очень большой пакет акций? Поделитесь секретом, пожалуйста.
P.S. Я подсознательно понимаю, что Вы имели в виду что-то другое, но читается именно вот так :)
нюанс: "Серожопов и К" как раз легко может предложить х2, а вот интел - даже -х2 (в 2 раза меньше), вот только после интела сильно больше перспектив. Крупные фирмы часто по низу рынка и даже ниже дают, зная что и так отбоя от кандидатов не будет. Имя, карьерный рост, перспективы вне компании.
ЗЫ если увольняют 90% то это скорее неадекватное начальство. Или "отказывается работать 7 дней в неделю по 12 часов", при этом не считают зазорным звонить ночами; или к основной работе навязывают тьму другой работы, включая ремонт принтеров, техники, услуги грузчиков, курьеров итд. Так что или реальная текучка многократно ниже, или что-то недоговаривают.
А, ещё это может быть место типа "службы поддержки сбера" и прочие "магазин на диване". Или 1хбет. В общем, прямо или косвенно связано с обманом людей. И да, люди оттуда бегут по моральным принципам.
Я еще ни разу не видел людей ушедших из-за их высоких моральных принципов. Тех кто пытались строить из себя таковых - да, но реально тех кого все устраивало и тут "прощай жестркий мир" не видел. Были истерички, позеры, плохие работники, неудовлетворенные зарплатой и тд.
"принципы" могут быть про разное, плюс не всегда сразу известно куда идёшь. Одно дело когда это те же ставки, там всё добровольно, а платят хорошо, и другое - идти в "поддержку сбера" осознанно и добровольно. Разумеется, не настоящую поддержку, а мошенником. Хотя по своему опыту - сначала прикрыли колцентры в тюрьмах и интенсивность упала, а сейчас таких звонков стало 1 в месяц, как оказалось что большинство колцентров на территории соседней страны (когда им годами промывали мозги что это "наши враги" - то вроде и благое дело делаешь) и приняли меры.
Ну и я сомневаюсь что "истерички-позеры" дают 90% текучки. Как минимум, тогда это очень большой вопрос к HR, но скорее в такие фирмы просто брали всех кто готов работать за копейки, без отбора, бывают и такие.
При нормальном ведении линкедина и опыте работы от полугода, тебе начнут в личку написывать hr. И если устраивался с зп в 600-700 евро, по предлагать будут порядка 1000-1200.
С опытом в полтора-два года, будет как в тиндере у красивой девушки - только успевай свайпать, и предлагать будут уже 1.5-2х.
О, это я. Больше меня в отделе получал только начальник отдела, и коллектив был хороший поэтому я деградировал делая странички на джанге.
Ну с джунами действительно сложно угнаться по деньгам. Уже через полгода он стоит раза в 1.5 больше чем вы его брали. И это без учёта инфляции. Плюс ему уже намного проще найти работу т.к. есть полгода опыта. Через год он вполне может найти работу с x2-x3 от стартовой зп.
Если говорить про PHP, остановитесь на фреймворках Laravel или Lumen — для старта этого будет более, чем достаточно.
Не надо Lumen. Авторы фреймворка официально просят больше не использовать его.
Просто джунам надо просить меньше денег. А пока вы из группы людей "хочу сотку на старте" вы никому не нужны
джунам надо просить меньше денег
Всегда удивляет такая логика. Вот стоит человек на заводе и перекладывает детали с одной ленты конвейерной на другую, его труд примитивный и его можно заменить роботом который будет делать это даже быстрее и лучше, поэтому если человека не заменили это означает только одно, он стоит дешевле гораздо чем робот и сопутствующее его обслуживание. То же самое с джунами, если труд джуна настолько примитивный, что его можно автоматизировать почему этого еще не сделали? Если все-таки он не настолько примитивный, то платить нужно как положено. Если вы нанимаете человека потому, что он просто дешевый как китайский кроссовок, вы ему показываете свое отношение к нему, и не надо удивляться, что он сбежит когда к нему другой работодатель отнесется к нему с интересом и предложит больше денег.
не забывайте про сложность работы. допустим есть задача подвинуть визуальные элементы на пару пикселей, но из-за допустим UI-фреймворка — это работа представляется не сложной, а муторной. там могут быть специфические методы, которые по-своему двигают элементы. А у вас на фирме сплошные сеньоры, которые класть хотели на такую работу, и начальник сам понимает, что часы работы сеньора выделять на такую второстепенную задачу это не разумное выделение средств. Поэтому на такую работу можно нанять джуниора на мин зарплату, подобные задачи просты, и не должны потреблять денег, в добавок человек ознакомится с проектом и архитектурными ращениями, что в следствии чего сможет потребовать повышение.
Это как работа верстальщика страниц, там сложно вырасти до сеньора так как сама работа не располагает сложностью, но спецы браться за неё тоже не будут
И так просят мало, лишь бы взяли, и на 30к соглашаются.
Английский. Онлайн-курсы на английском - дешевые, и по уровню сильно превосходят отечественные. Лучше параллельно работать над фундаменталкой - Линукс с сетями. У кучи народа, далеко не джунов, с этим всем дичайшие проблемы. Пригодится в любом случае.
Можете присоседиться к предпенсу в своей комнате и работать на пару - с него предметная область и консультации, с вас поиск в англоязычном интернете, освоение новых небольших тем и подчистка мелких задач, документирование. Как только он поймет, что на вас можно сгрузить кучу мелкой (для него) работы - считайте, что удержались, он вас уже ни за какие коврижки не сдаст.
Другая картина: квартира, та же задача. Раздражение ментора, потому что вы обращаетесь, когда он максимально занят.
В нашей компании у ментора в такой ситуации нет права быть раздражённым, потому что "помочь новичку" — это конкретная задача, на которую выделяется время. Более того, это не для джунов, это для любого человека, который пришёл в компанию "только вчера". Как часть т.н. onboarding. Если я скажу начальству, что задача задерживается, т.к. я помогал новому разработчику, он поймёт и будет только рад, т.к. в его понимании — это освобождает от тупых вопросов его самого. Обратная сторона — если время будет тратиться очень часто, то нового разработчика всё-таки уволят, потому что мы джунов не нанимаем и об этом во второй половине поста.
А уж если заранее известно, что вы нанимаете человека без опыта, но при этом освоиться ему люди должны помогать в своё свободное время, никак не прописанное в распорядке дня, то что-то пошло серьёзно не так.
А ещё есть чудесная практика парного программирования через зум, когда один человек пишет, а другой на ходу делает ревью. Это хорошо работает даже для опытных программистов, например если ты фуллстэк и въезжаешь в какую-то принципиально новую для себя технологию, гораздо удобнее будет если тебя в неё посвятит человек для которого это главное или вообще единственное направление. У меня так было например со стэком Elixir+Ecto+LiveView.
В общем, это было о хорошем, а теперь о плохом.
У нас джунов не хотят брать не потому, что они чего-то не знают, а потому, что по определению начальства, джун — это человек, который думает о выполняемой задаче на принципиально неправильном уровне. То есть, он думает не о том, что делает (бизнес-логику и внешний вид), а о том, как пишет код. Это те самые джинны, которые выполняют желания слишком буквально, порождая недоработки и баги. Они не думают о том, как выглядит и работает существующая логика, бывшая до них. Честно говоря это может прозвучать грубо, но по-моему иногда они не думают вообще.
На случай, если этот коммент каким-то чудом будет читать человек, которому это когда-нибудь пригодится в работе, приведу парочку примеров типичных косяков джуниора в моём понимании (на самом деле эти косяки в нашей компании допускали люди, которые формально джуниорами не являлись и получали з/п от условных 2000$). Некоторые существенные, некоторые нет, но все из них отнимают время команды на фидбек от QA+заказчика, открытие багов, переоткрытие задач и т.п.
Кастомный кликабельный UI-элемент, в котором не будет прописано user-select: none или cursor: pointer, даже если во всей остальной платформе в подобных случаях оно прописано.
Отсутствующий эффект ховера или нажатия, если его нет в дизайне.
(Большинству дизайнеров пофиг с большой колокольни на ховеры, это не их уровень высоты художественного видения, так сказать)Невнимательное чтение чужого кода при рефакторинге или переписывании, отсутствие тестирования совместимости с предыдущим кодом на всех промежуточных этапах. Конкретно этот пункт связан с записью JSON-данных в БД, но может произойти где угодно, где есть какие-то исторические вещи, с которыми нужно сохранять совместимость.
Цельный пулл реквест, содержащий одну фичу с нуля, которая не работает end-to-end. Например, фича регистрации через емейл, где емейл тупо не приходит или приходит в сильно поломанном виде. Или фича входа через OAuth, которая падает в 500 при попытке залогиниться через гугл. Это как правило указывает на то, что человек работает в режиме райт-онли и даже отдалённо не пытается свою логику тестировать, и ему норм.
Подпункт: реализация REST API условного микросервиса по спеку, по которому в этот API будут обращаться другие сервисы. Почему пункт здесь? А потому, что реализовано было абсолютно не по спеку, а по какому-то внутреннему пониманию программиста, и этого никто не замечал пока не пришли ко мне с "ничего не работает".
Боязнь задавать вопросы заказчику, дизайнеру и т.п. при явных несхождениях каких-то новых фич со старыми. Например, если заказчик скинул иконку, которая ни к селу ни к городу, она будет воткнута прям в таком виде, несмотря на то, что на самом деле имелось в виду что её надо использовать как референс и найти что-то похожее, но более уместное.
Дети не нужны, вот подростки и взрослые - это ок, а детей больше не будем делать.
Ну как бы да, рождаемость ниже уровня воспроизводства в технологически развитых обществах.
Ага, мантры, что технологическое развитие порождает еще больше технологических (и не очень) рабочих мест почему-то не работает.
Разве? Так то население Земли растёт, и все в основном чем-то заняты. В основном не канавы копают.
Растет в основном за счет Африки и ЮВА. Вы точно уверены, что там "не канавы копают", а занимаются НИОКР и производством мерседесов?
А вот в технологически развитых странах высок уровень безработицы среди молодежи, в ЕС, например, 13.3 %. И это при их низкой рождаемости. А если бы была высокая? И нет ли здесь связи между низкой рождаемостью и отсуствием достойного трудоустройства для молодежи? На эти вопросы не принято отвечать.
Хах) В компаниях, которые работают на аутсорс очень часто стараются быстро запромоутить способного джуна, потому что так от компании-заказчика можно будет стряхнуть больше денег за него. Знаю случаи, когда за чуть больше чем 4 года ребята становились сеньорами
Наверно зависит от страны. В Корее, как мне кажется, берут всех подряд (если это конечно не samsung с lg), но с испытательным сроком 3 месяца.
Сейчас хотела бы вернуться в Россию, но вот такие статьи про требования к джунам и общее пренебрежение к "не звездам" напрочь убивают желание вообще идти на собеседование. Хотя по текущей должности я далеко не джун.
Ну если джуны не нужны, нанимайте мидлов и синьеров, делов-то. Да?
Кстати, кто шутит тут про детей - это ж никакие не шутки. Как только дети перестали быть дополнительными руками на поле, их тут же перестали рожать каждый год. Теперь ребенка заводят, когда есть средства на такую роскошь.
Джунов тоже стоит заводить только если у вас все обмазано CI, тестами и качественным код-ревью - чтобы молодой не имел даже шанса что-то сломать, но имел шанс быстро учиться. А кто заводит джунов в голозадом стартапе, которому без году неделя, - тот делает на самом деле хуже и себе и джунам.
Так-то по вашей аналогии с доп руками можно набирать тучу джунов, когда на проекте полный разброд и одна нянька (если повезет) - тогда получаем, что со временем на этих джунах уже и проект держится, и CI поднимается, и ТП выстроена, и мониторинги с алертами и т.п. Главное чтобы по той же вашей аналогии, эти джуны никуда не могли/не хотели уйти с этого проекта, тогда все будет тоже в шоколаде)
Проблемы в ошибочном подходе к найму. Грубо говоря - некоторые работодатели пытаются посадить джунов не на их место, а потом удивляются, почему они плохо работают и не приносят прибыль.
Джуниор - это начинающий специалист, т. е. сотрудник низкой квалификации (по меркам специальности, конечно). Соответственно и нанимать его нужно на ту работу, для которой хватит и низкоквалифицированной рабочей силы. Если на проекте есть мастер ("мидл" или "сеньор"), то джун может быть подмастерьем, просто парой рук. Если проект в принципе предполагает много однотипных действий, то джуны могут образовать целый отдел под руководством опытного. Потом он по мере работы так или иначе наберётся опыта и потихоньку, сначала просто щупая, потом пробуя сделать и наконец делая сложные вещи, станет специалистом средней, а затем и высокой квалификации.
Джун - это не инженер-рукожоп и не мидл-нуб.
... «Я отдал деньги, у меня будет программа и наставник, который меня проконтролирует». Это тупиковый подход...
Полная чушь.
Качество преподавания на курсах конечно низкое, но если человек говорит что ему нужен наставник проконтролировать - он имеет ввиду правильность выполнения заданий. Наставник для джуна это бесценный ресурс. В поиске вы максимум получите ответ на вопрос "как делать?", наставник ответит "как делать правильно".
Вы с высоты опыта если что-то гуглите, то запрос по классике в себе уже содержит половину ответа. А начинающий сформулирует как сформулирует и получит то что получит.
...Длительность некоторых курсов составляет 10-16 месяцев. За это время в коммерческой разработке можно стать хорошим специалистом. Тем более существует много бесплатных курсов, которые можно проходить, работая над коммерческим проектом...
Вопрос всей статьи как попасть в коммерческую разработку, а тут совет - попасть. Логика где-то здесь закончилась.
С такими перлами, плюс вся критика выше, как эта статья ещё в плюсе - непонятно
Позволю себе оспорить многие положения данной статьи.
1) Джун не приносит прибыль компании. Иногда его работа выходит в ноль, но чаще это минус.
Джуны бывают разные. Это первое. Второе - джун обычно стоит на порядок меньше, чем опытный разработчик (например, в 2 а то и в 3 раза дешевле). Так что это утверждение, как минимум, спорное, а я бы даже сказал, неверное.
2) Вторая важная часть удаленки — это доверие. Представьте, вы джун в офисе и вам дают сложную «боевую» задачу. Вы сидите над дней с утра до вечера, советуетесь с ментором. Project-менеджер видит процесс и думает про вас: «У него не получается, но он старается. Дадим ему шанс»
Обычно стартовые задачи для джуна дают попроще, особенно если проект большой и ему требуется ознакомиться с ним. В основном, именно из-за последнего возникают трудности.
Раздражение ментора - тоже не всегда. Вообще, практика менторства и преподавания для разработчиков - весьма важный скилл, полезный. Но это тема отдельной статьи.
3) Джуны не могут определиться со стеком. Учат все подряд — фронт, бэк, мобильную разработку, и не специализируются на чем-то одном. В итоге на собеседовании быстро выявляются поверхностные знания
Не так уж и плохо. Как я уже писал выше, джуны (как и их уровень подготовки) бывают разные. Возможно, что хорошей подготовки мало... Есть такое термин, как "Т-человек", видел где-то в статье про Valve. Общая ИТ-эрудиция и опыт в каком-то минимум одном направлении. У джуна его еще нет, но общая эрудированность в стеке - это очень хорошо.
4) Ваша способность взаимодействовать проверяется через навык самопрезентации и умение четко излагать свои мысли. Их можно наработать только практикой
Хех. В процессе обучение они также нарабатываются, если что.
5) Наличие Git также большой плюс. Он показывает уровень подготовки, прогресс и задачи, с которыми вы работали. Мои разработчики запрашивают Git даже у джунов. И на собеседовании задают вопросы по нему.
Странно было бы, если бы его не было.
Самый короткий коммент к статье:
Если глаз не горит, ничего не выйдет.
Я бы хотел посмотреть эфир живьём/в записи, но нет твиттера. В телеге где-то будет анонс?
Спасибо
Джунам нужны менторы: они не самостоятельны, не умеют писать качественный код и взаимодействовать с окружением, не понимают принципов командной разработки. Компания вынуждена тратить время опытных разработчиков на обучение такого специалиста.
Это характеристика несамостоятельного человека, а не джуна. Нормальный джун, даже если он многого не знает, сам все загуглит и напишет решение, задавая вопросы коллегам только по архитектуре либо по каким то совсем специфичным вещам
Это к сожалению работает только для пет-проектов в которых у тебя нет ограничения по времени. При работе на дядю всегда есть строгие временные рамки и ты не можешь тратить время на изучение какой-нибудь новой для тебя фигни неделю.
Самый простой пример из мира веб-разработки: ты перед наймом на работу изучал React, может даже сделал пару страничек чтобы понять как это всё работает, а реальное продуктовое приложение построено с использованием не только реакта, но и Redux, причём скажем с RxJS и всё это образца года этак 2017. По своему опыту скажу что в таком проекте непонятно абсолютно всё.
А если там ещё какое-нибудь Immutable.js (никогда не пользуйтесь этим, кстати, очень медленная либа) то придётся ещё и изучать map/reduce, и на эти фокусы и пинг-понг во время код-ревью уйдёт ещё одна неделя.
Джун/не джун а не задавать вопросы коллегам — плохая практика.
Упал у меня эластик (одна нода, никаких реплик) на днях и не поднимается (один индекс ред и все тут). Почитал, попинал, добавил памяти — на соседней машине оживает, на целевом сервере — нифига.
Пошел к опытным в этом ребятам. Оказалось, что элестик в режиме вин сервиса не смотрит в свою папочку config, а настраивается через спец гуй (куда в итоге пишет — хз, в командной строке сервиса вроде ничего не поменялось, в конфиге тоже). И этот свой кейс чую в обзорах эластика, в основном акцентирующих внимание на распределенку, терабайты в индексах и никакой винды в округе я искал бы до посинения.
Опишите ваше био (стек, опыт, где учитесь / работаете) и оставьте ссылку на текущее резюме. Итоги подведем 25 июля.
Основной стек: python+django/flask+postgresql/sqlite.
Основная проблема в том, чтобы найти работу для меня - то что я - несовершеннолетний школьник, хотя при этом не отстаю от людей, которые только кончили вуз. С этим стеком опыт работы 3 года.
https://career.habr.com/pzrnqt1vrss
тг: @pzrnqt1vrss
Пытался я попасть на стажировку по Java. Сложилось такое чувство, что на оную попасть сложнее, чем на «реальную работу». И на какой-либо фидбек по отправленным тестовым надеяться не приходится, ведь желающих — море. Может, конечно, это я не дотягиваю, придумываю себе, но как-то так.
Где вы собираетесь брать мидлов?
Вы точно из этой сферы? Так не профессионально путать джунов и интернов еще надо постараться.
У вас видимо отстойные hr которые так же путают интернов и джунов.
Опишите ваше био (стек, опыт, где учитесь / работаете) и оставьте ссылку на текущее резюме.
По образованию журналист, пытаюсь сменить сферу деятельности на frontend-разработку. HTML, CSS, Javascript, немного React. Учеба - курсы+google и youtube. Основную проблему вижу в отсутствии опыта разработки. https://drive.google.com/file/d/1SwoUVMJ70Uz9PEucUpmUcn9FIJ3ytu6I/view?usp=sharing
меня как человека, который уже через неделю будет пытаться найти работу во фронте такие статьи одновременно вгоняют в тоску и проявляют еще большее желание просидеть в документации перед сном, чтоб отсеять негативные мысли
Часто бывает так. Нанимают джуна, тот наладил, сотворил творение и увольняют его.
Зачем содержать типа, при этом своего подсосывают изначально, как помошник. А потом оказывается этот помошник - родственник.
Раньше было деление на кодер и програмист. Это 2 разные работы. Сейчас считается, что сеньор - опытный джун, что по мне это тоже две разные работы. Как архитектор и каменщик.
В итоге у нас сеньоры - это мегаджуны с развитой чуйкой и высокими когнитивными способностями уровня, как найти багу в чужом велосипеде.
Мегаджун способен быстро и качественно сделать унитаз в центре кухни, чтоб и слив работал и воняло не сильно. Сеньор ляжет костьми, но поставит унитаз в туалет.
Ну всё таки джун не стажёр. Он должен уметь решать корректно поставленную сеньором задачу. А если сеньор будет делать всё сам, то это крайне неэффективная работа, не сильно лучше одиночного миддла. В том , то и квалификация сеньора, что он должен понимать, что можно доверить другому, а что нужно делать только самому.
Вот стажёр это да, человек, который знает только в "общем" , а конкретные задачи может решить не сразу.
После прочтения создается впечатление, что статья целиком эталон инфоцыганцины в вакууме. Советы из разряда "хорошо кушай и какай после обеда". Похоже, что единственная цель статьи пропиарить себя, и культивировать синдром самозванца у начинающих разработчиков, чтобы купить их подешевле или продать что-то по дороже.
Здравствуйте, небольшая опечатка в тексте.
Вы сидите над дней с утра до вечера, советуетесь с ментором.
над дней -> над ней
Предлагаю отменить джунов. Мидлов и сеньоров клонировать.
Так почему джуны все-таки не нужны?