Pep не одобряет твоё сообщение

теперь одобряет

Один важный текст, утащил с Пикабу.
Почему трудно устроиться программистом? Взгляд со стороны руководителя.


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


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


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

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


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


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



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

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

Примерно так проходит ещё примерно год-полтора - вот уже скоро он станет полноценным миддлом, и можно вздохнуть спокойно. Он протягивает нам заявление на увольнение.

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

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

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

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


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

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

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

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

в теории реально, советую заюзать для этого эмуляцию браузера с помощью Selenium, а так разбираться в закрытом API, которое инста использует для получения фоточек - слишком муторно и дорого, плюс там может стоять какой-то механизм защиты от подобного рода парсинга. А ещё мб это то что тебе нужно https://stackoverflow.com/questions/37875945/is-there-still-a-way-to-fetch-instagram-feed-without-using-access-token-now-06

@backinblacknext, ты там сегодня вакансию скидывал и тебя не устраивала сотка на джуна. Почитай, интересно будет

+100

Вы увеличили карму Vadim Apenko до 4764.72 (+8.18)

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

Можно bs4

Нужен ментор!

Если я челику дам админку в приложении на хероку, то он сможет изменить тип дино?

Не free, а hobby например

Здравствуйте, вот такая задача.

У меня есть список
list1=['привет', 'давай', 'как']

А также есть ещё один список со словарями


list2=[{'title':{'name':'привет'}, 'count':10},{'title':{'name':'как'}, 'count':5}, {'title':{'name':'давай'}, 'count':10}...... Тут могу быть и другие славори. С title.name не находящиеся в 1 списке]

Требуется в соответствии со списком 1. Найти значение count из списка 2. Опираясь на переменную name находящуюся в title.

И вывести вначале суму всех значений count.

А потом строку вида

Привет-10
Давай-10
Как-5

в списке2 каждое слово только 1 раз встречается?

Да

Аннотация типов в питоне влияет на производительность? (не в скомпилированном виде)