Не уверен, что это прочитают... Но все таки напишу. Я техлид в компании OneTwoTrip (не реклама, а для того чтобы вопросов не было) и сам занимаюсь набором сотрудников (2-3 интервью в неделю). Автор пишет "босс влетал в долги перед заказчиком", что сразу наталкивает меня есть на мысль о компаниях системных интеграторах, которые делаю заказы для кого-то. Скажу по собственному опыту - я очень осторожно (скорее даже негативно) отношусь к "выпускникам" таких компаний. Обычно (специфика такая уж) эти люди не пишут тесты (ну дедлайн - нет времени же), не пользуются статическими анализаторами кода (линтер и т.д), не выстраивают CI/CD, мало знают про паттерны и вообще пишут менее качественный код. А зачем если ты сдал проект и все? Ты можешь быть хоть 7 пядей во лбу, но ты не сможешь писать хороший код если тебе не будут давай, а только давить дедлайном. Это первая часть, вывод которой - мнение автора справедливо для типа компаний, которые работают НЕ на себя.
При поиске IT компании я рекомендую смотреть на те, у которых есть свой продукт. В таких компаниях рабочие процессы выстроены совсем по-другому. Долгоживущий проект требует качественной автоматизации (юниты, интеграц. тесты, автосборка, деплой), требует сложной собственной инфраструктуры и просто напросто больше и сложнее. В таких компаниях вы получите бесценный опыт. Если утрировать - там все устроено также как в Google.
И наконец к сути - что же с набором в такие компании? Джуны есть - их много - больше 20%. Почему не страдает качество - проект не однодневный. Процессы хорошо выстроены (обязательное ревью, дока, примеры, еженедельные презентации от других коллег). Основное условие - руководитель команды не должен меняться. Смотрю ли я на возраст? Да! Как бы несправедливо это не звучало, но да. Если это Джун, то тех кто моложе действительно легче обучить, а тех кто старше сначала "перевоспитать" (это не потому что он плохой, а потому что он привык по-другому. Но теперь то он в этой компании где надо не так как привык, а как просят.). У нас были разные люди - и Джун в 52 и сеньор в 23, но это скорее исключение. Курсы? Вообще никак не влияют, от слова совсем. Смотрю исключительно на знания. Получил их на курсах? Отлично! Где-то ещё получил? Без разницы. Можно ли "войти в IT"? Можно. У нас есть человек, который 9 лет работал в КБ "Сухого" - самолёты делал. Если у тебя есть знания и технический склад ума - все можно.
Ну и чтобы от поста было побольше пользы, что надо знать джуну при приеме? (Лично мой список)
1. Git - ну а как иначе?
2. Знания по БД (желательно и реляционным и Nosql). Понимание транзакций и нормальных форм - это очень важно для правильного проектирования хранилищ
3. Понимание как работает HTTP протокол - грубо говоря умение расписать цепочку от клика на фронте до запроса в базу.
4. Знакомство с паттернами проектирование конечно будет плюсом.
5. Естественно знание языка, на котором ты хочешь писать, на уровне Джун.
6. Желательно знание платформы (или фреймворка), на которой работает язык - базовые особенности, как устроен внутри.
Вот в принципе все. Получилось довольно много текста и не обо всем удалось написать, но слава богу есть комментарии )
Если программирование это ваше и вас прям прёт, когда вы создали что-то и оно работает и выполняет задачу - пробуйте )

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

Инфо-цыгане "а-ля курсы программистов".

Это стало действительно большой проблемой для IT-индустрии. Все курсы, которые предлагаются различными школами по изучению языка и получении "только нужных" навыков оказывают медвежью услугу. Когда люди идут куда-то учиться, мало кто начинает сильно выходить за рамки курса и это проблема. В зависимости от под-сферы, языка программирования или набора скилов для тренировки, в школах дают самые "популярные" и супер-практические задания, которые довольно легко сделать. Возьмем одну из самых моих больших болей - Python (язык очень люблю, боль в другом): поголовно все пишут блоги на Django, ботов для Телеги, простой кроулер и пресказание чего-нибудь, используя регрессию. А теперь спросите, кто из учеников прочитал просто документацию по языку программирования, на котором они все это реализовали? Может один-два человека. Почему? Потому что людям это скучно. Это не так должно работать. Вас должны научить пользоваться инструментом в достаточной мере, а не решать узко-специализированные задачи. И нет, я ничего не перепутал. Никого не хочу обидеть, сам был джуном когда-то, но нажимать на кнопочки можно научить обезьяну, это правда. А вот понимать, как лучше сделать и почему что-то происходит так, а не иначе, уже удел человека. Корочка подобных школ не даст вам глубоких знаний, они возможны только при самостоятельном изучении и общении с коллегами, даже если это общение происходит посредством кода. Поэтому, читайте документацию, пробуйте примеры из документации, пытайтесь объяснить эти примеры кому-нибудь (друзьям, детям, родителям) и докапывайтесь до любой мелочи - у вас цель - полнять, что происходит и как это все работает.

И народ, читайте об общих принципах и лучших практиках в вашей области - паттерны, подходы и т.д. Язык - это всего-то инструмент.

Джуны тоже не умеют плавать.

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

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

Проблемы джунов (и не только) - проблемы компании.

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

А теперь давайте я объясню сложность этой фразы, по шагам.

"которые хотят работать"

Убедитесь, что вы нанимаете человека, который готов делать то, что вы хотите ему предложить, но бесплатно при наличии у него другого пассивного дохода. Иначе "если бы человек получал $Х каждый месяц, которых бы ему хватало на жизнь, пошел бы он работать к вам делать то, что вы от него хотите, бесплатно?". Очередной шквал тапок полетит в стиле - "Ты что, хочешь работать беслатно?", "Я иду зарабатывать деньги", "Если бы у меня был пассивный доход, то я бы на пляже делал много чего и с кем" и прочее. Кидайте свои тапки, но вы будете неправы. Лично я не знаю ни одного человека, который бы не остался в сфере при наличии у него необходимого количества денег. Посыл здесь на самом деле другой - любите то, что вы делаете, а только потом получайте за это деньги. И задача работодателя распознать такое желание и не дать ему угаснуть. Это непосредственно связано со следующим пунктом.

"дайте им то, что они хотят"

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

Я не отрицаю важность зарплат, это неотъемлемая и неимоверная важная составляющая. Про себя могу сказать следующее - иногда я был гораздо счастливее, когда зарабатывал $, по сравнению с тем, когда зарабатывал $$$. Давайте своим сотрудникам возможность расти и юысть счастливыми. Это достигается различными способами и неправлены они должны быть индивидуально. Кому-то нужны сложные и новые задачи, кому-то возможность быть лидером, а кому-то благодарность.

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

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

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

Конечно, IT-компании требовали "от миддла и выше" всегда. Так почему же, если работодателям нужны миддлы, они столь неохотно берут джунов с целью вырастить его и получить лояльного работника? Основных причин две.

Первая - это тяжело. Многие компании действительно готовы брать джунов - проблема в том, что любой руководитель в команде разработки может позволить себе иметь лишь небольшое количество джунов. Основную часть сбалансированной команды должны составлять миддлы/сеньоры. Мой личный опыт показывает, что в нормальной команде разработки не должно быть более 20% джунов, иначе темп разработки просядет, а вероятность ошибки существенно возрастёт. Печальные примеры пренебрежения этим правилом, вероятно, известны и вам - в IT не раз случалось такое, что опытные разработчики уходили из-за плохих условий (или выгонялись из-за высоких запросов), а на их место приглашались малоопытные, и через какое-то время разработка попросту вставала, качество продукта резко падало, а босс влетал в долги перед заказчиком.

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

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

Почему так? Лучше всего показать на примере. Давайте представим себя на месте руководителя, и посмотрим, что будет, если мы возьмём джуна. И здесь нас ждут проблемы: работник, не добравшийся хотя бы до грейда джун+ - это работник, который пока что бесполезен. Его полезность заключается в перспективности - в расчёте, что он прокачается, и наше время и силы окупятся. А пока что наша задача - постоянно его обучать и приглядывать за ним, чтобы помочь ему избежать ошибок. Мы тратим не только своё время (стоящее денег, между прочим), но и время разрабов-наставников, и аналитиков, и тестировщиков. Из-за этого скорость разработки снижается, дедлайны... Дедлайны остаются, ибо они есть всегда. Мы ведь в курсе, что в отрасли вечный кадровый голод?)

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

- Что произошло? Давай обсудим варианты! Почему ты вдруг решил уволиться?

- Получил предложение от другой компании. Там обещают более высокую ЗП и более интересную работу, а так же стек покруче вашего.

Стоит ли объяснять, что это весьма неприятно? И наверняка многие из вас скажут - "значит, надо было создать такие условия, чтобы он остался". Конечно, мы стараемся, только вот если бы всё было так просто... И ЗП тут не первая из проблем. Возвращаемся на место руководителя.

Естественно, если это действительно стоящий работник, мы предложим ему больше денег, чтобы не отставать от конкурента. Если повезёт - разраб останется. Но, скорее всего, он просто уйдёт в отказ. Он хочет уволиться, "чтобы двигаться дальше". Ему хочется в новый коллектив, попробовать новый стек, ведь он хочет развиваться, а тут он уже всё видел! Объяснить, что у него и тут ещё полно пространства для развития? Что новый стек невозможно ввести на старых проектах, а эту новую HuyakHuyakJS планировалось опробовать на следующем проекте, который сейчас в пресейле? Что у конкурента тоже есть старые проекты? Увы, разработчик уже решил, а потому наши слова он пропустит мимо ушей.

В таких случаях мы стараемся разойтись на хорошем тоне. В конце концов, разраб нам ничего не обещал и гарантий не давал. Но осадочек, конечно, остаётся. Потом мы корим себя, ищем причины - как так случилось, где мы недосмотрели? Что предпринять, чтобы такое не повторялось? Платить столько денег, чтобы разрабы на сторону даже не смотрели? Мы не Гугл. Заниматься плотнее их обучением, чтобы они чувствовали заботу? Это было бы замечательно, но откуда на это время взять? Нам бы хоть штат до конца укомплектовывать. Постоянно выливать на разрабов новые технологии, чтобы они чувствовали, что у нас всё стильно-модно-молодёжно? Мы бы рады, но чтобы новый проект начать, надо старые закрыть. Так что мы будем делать?

Правильно! Мы идём к HR открывать вакансию, где пишем новую ЗП, и описываем кандидатам наш новый запускаемый проект - теперь с новомодной HuyakHuyakJS, всё, как вы хотели, стильно-модно-молодёжно! И да, нам желательно найти миддла!

Думаю, многие руководители (и не только в IT) сталкивались с подобным. Это случай из моей практики. По различным подсчётам коллег, в течение двух лет уходят от половины до 2/3 джунов. Конечно, не все работники уходят вот так, как в истории выше. Случается, что проблема в семье, переезд. Нередко случается, что джун просто не справляется с работой и не способен держать темп развития - как я уже говорил, входной порог в IT высок, а насколько приспособлен к программированию человек, заранее сказать сложно даже по высшему образованию. Когда у меня случается, что разраб не справляется с работой, я стараюсь найти ему место в отделе попроще.

Ох, ну и простыню я уже накатал. Закругляемся!

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

Надеюсь, вам было интересно представить себя на месте работодателя. Кто знает, может, однажды вам и представлять ничего не понадобится. А пока что - желаю вам успехов в обретении работы своей мечты. Не прощаюсь ;)