{"id":14292,"url":"\/distributions\/14292\/click?bit=1&hash=23aed192f809013ec1c0769a11eb00fbed4dd7038bbe5f8e3db447db2e792dcd","title":"\u0421 \u043d\u0430\u0447\u0430\u043b\u0430 \u0433\u043e\u0434\u0430 \u043a\u0430\u0440\u0442\u043e\u0439 \u00ab\u0425\u0430\u043b\u0432\u0430\u00bb \u043e\u043f\u043b\u0430\u0442\u0438\u043b\u0438 40 \u043c\u043b\u043d \u043f\u043e\u043a\u0443\u043f\u043e\u043a","buttonText":"","imageUuid":""}

За 3 месяца с трудоустройством: почему выпускников ИТ-курсов не берут на работу

Как стать востребованным программистом за 6 мес с доходом от 100 тыс, а то 500? Ответ прост: никак. Подобные обещания — лишь маркетинговая уловка. Однако спрос на ИТ-курсы растёт, и ежемесячно на рынок выходят сотни никому не нужных выпускников. Поговорим, почему они часто даже не попадают на собеседование, что не так с онлайн-курсами и в каких случаях они всё-таки могут быть полезны.

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

Сотрудник должен приносить компании определённый вэлью, иначе нет смысла его держать, а для этого нужен реальный опыт коммерческой разработки. Можно провести параллель с вузами: если вы отучились пять лет на юриста, вы ещё не стали востребованным юристом. После восьми лет в медакадемии и двух в ординатуре вы не сможете сразу же проводить нейрохирургические операции. И так же никто не доверит реальный проект человеку, прошедшему 3–6–12 месяцев ИТ-курсов.

Любое образование даёт знания, которые надо учиться применять на простых задачах. Чтобы найти такие задачи, можно устроиться на начальную позицию в маленькое агентство, заняться фрилансом, а если повезёт, попасть на стажировку в крупную компанию. Но не претендовать на роль джуна и зарплату от 100 тысяч, не найти работу уже во время учёбы и не точно дорасти до уровня мидла за год.

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

Кодинг под пальмами

За последний год число ИТ-специалистов на рынке заметно выросло. Это не значит, что дефицит кадров на рынке закончился: компании по-прежнему дерутся за мидлов и сеньоров. Зато выпускников онлайн-курсов становится всё больше, а работодатели не готовы их нанимать. Часто компании даже не приглашают таких кандидатов на собеседование: после энного количества неудачных технических интервью эйчары уже не хотят тратить время на соискателей, которые с большей долей вероятности отвалятся. Репутация онлайн-курсов среди работодателей становится всё хуже, но вместе с тем их популярность парадоксально растёт.

В первую очередь это связано с ореолом элитарности, который окружает профессию айтишника. Баснословные деньги, удалённая работа под пальмами, зарплата в долларах и прочие привилегии — за этой красивой картинкой и приходит на курсы большинство клиентов. Тем более что события последних лет, начиная с пандемии, заставляют людей задумываться о получении востребованной цифровой профессии, которая даст им уверенность в завтрашнем дне. Так, с января по июнь прошлого года 100 тысяч россиян изменили профобласть в своём резюме на ИТ.

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

Но соблазнившись красивой картинкой, люди часто забывают про саму суть профессии. Им неинтересна разработка сама по себе: они не хотят ночами писать коды, искать баги, ломать голову над задачами, смотреть многочасовые мануалы — их привлекает только внешняя сторона. Мало кто задумывается, что ИТ — профессия не для каждого, впрочем, как и любая другая. Это серьёзный интеллектуальный труд, который требует огромных стараний, времени и постоянного обучения в попытке не отстать от рынка. И хорошо, если человек осознаёт это ещё в процессе обучения. Но многие сталкиваются с суровой реальностью только тогда, когда выходят на рынок и начинают поиски работы.

Сомнительные гарантии

Конечно, далеко не все могут поверить школам на слово, что после окончания курса их ждёт быстрый карьерный взлёт. Поэтому компании используют своего рода «доказательные» месседжи:

  • гарантируем трудоустройство или вернём деньги;
  • почитайте истории успеха наших выпускников;
  • 85% наших выпускников нашли работу.

Давайте разберём в порядке очерёдности. Во-первых, гарантировать трудоустройство не может никто, а возврат денег, как правило, оговаривается в договоре с огромным количеством условий, «но» и звёздочек.

Во-вторых, историй успеха, как правило, единицы, и на каждую из них приходятся десятки и сотни неудач.

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

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

Хеппи-энд

Закончу на светлой ноте. На рынке действительно есть много хороших курсов (хотя плохих, наверное, всё-таки больше). Есть классные преподаватели, качественный контент и сильное комьюнити. Такие курсы помогают получить нужные знания и навыки, набить руку на учебных проектах и познакомиться с интересными людьми. Главное — не забывать, что даже самый хороший курс никогда не станет настоящим входом в профессию.

О том, как развиваться в ИТ, что будет дальше с рынком и зарплатами, зачем айтишникам нетворкинг, как их нанимать и о многом другом, я рассказываю в своём телеграм-канале «Демченков вещает». Это канал про HR, ИТ, HR в ИТ, и вообще, там интересно и весело :)

0
177 комментариев
Написать комментарий...
Борис Д

Я не очень понимаю современных реалий. Кого именно все подразумевают под термином «программист»? Ремесленника-клепателя формочек? Винтика на конвейере, выполняющего определенный набор операций?

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

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

Ответить
Развернуть ветку
Иван Иванов

Вы забыли, нужен ещё навык компиляции и выполнения машинного кода в голове (для верстания формочек для джуна с зп 50 тр, разумеется)

Ответить
Развернуть ветку
Борис Д

Знание о машинных кодах входит в изучение микропроцессорных систем.

И я не говорю об опыте разработки подобных низкоуровневых проектов, но без базового представления о том, как там всё внутрях работает по мне такой программист - не программист.

Верстальщика формочек я бы программистом также назвал бы с большой натяжкой. Для такого «программиста» шаг влево-вправо - и он уже беспомощен.

Ответить
Развернуть ветку

Комментарий удален модератором

Развернуть ветку
Всеволод Севостьянов

И много вы там будете в крудах оптимизировать? Бизнесу нет времени ускорять код веб сервисов ассемблерными вставками, максимум который надо знать разработчику - выравнивание, потоки и как память устроена в ос. Если мы про веб говорим. Эмбеддед имеет другие требования но там нет например необходимости знать архитектурные паттерны для сервисов. Так что довольно глупо равнять всех по одной гребенке

Ответить
Развернуть ветку
Bo.G

вы бредите, батенька. бизнесу в лице менеджеров, генерирующих тонны говноактивностей надо почаще "давать по рукам" чтобы они головой думали, а не жопой.. чем в свое время и занимался будучи разработчиком.
понимание физических процессов позволяет спроектировать правильную, с зарасом развития арзитектуру. информационная система это не один проект. это стстема. и в системе нужно знать как и что работает.
иногда и ассемблерные вставки, и пара правильных строк кода могут разгрузить сервер на 80%, или грамотно спректированное отношение в БД, грамотно разбитле по физической модели с учётом аппаратного комплекса.
а чтобы так сделать нужнл понимать, как работает железо иначе вы получите лотерею сегодня работает, а завтра кластер серверов не справляется.
а это все - минимум деньги. затраты на железо и инфраструктуру.

Ответить
Развернуть ветку
говнокот

интересно, а что за позиция такая, которая занимается ассемблерными вставками для разгрузки сервера на 80%? можно подробнее?

Ответить
Развернуть ветку
Bo.G

покажите где написаны эти две фразы вместе в контексте прямой зависимости?
или вам нужно обязательно раскрыть семантическую структуру предложения?я так полагаю, в вашем восприятии - на каждый "чих" нужна отедльная позиция в штатном расписании?
ведь в вашем мире крутых птичьих языков, наверняка не слышали про то, что это может, да и должен делать практически любой программист (нормальный, я имею ввиду. знакомый более, чем с 1 системным ЯП и использующим его в практике).
отдельная позиция не нужна. есть задачи разработки интеграционных решений (самых дорогих), где типовые схемы обмена могут не работать корректно.
есть задачи системной разработки специализированных элементов (общения с оборудованием)
про задачи разработки семантических моделей БД я не говорю.
почему происходит лавиннобразный рост времени отклика к серверу БД при, вроде бы, одинаковых условиях нагрузочного режима? Откуда берутся взаимные блокировки, как правильно разбить данные (и почему правильно будет так, а не эдак)...
потому что надо знать как работает железо. все эти сказки про СХД, массивы и прочие чудеса разбиваются о суровую реальность. Все - имеет свои ограничения, правила функционирования и рекомендации по эксплуатации. И все это надо знать. или, хотя бы понимать принципы.

Ответить
Развернуть ветку
Всеволод Севостьянов

Вы либо диванный теоретик, либо работаете в эмбеде, в любом случае по этим топикам нам нечего обсуждать, тут налицо непонимание:)

Ответить
Развернуть ветку
Bo.G

ну конечно. это "сильный" аргумент. обсуждать действительно нечего, раз нет понимания основ.

Ответить
Развернуть ветку
говнокот

«чтобы грамотно спроектировать отношение в бд … нужно понимать как работает железо»
ясно…
У Вас определенно талант, хочу сделать Вам оффер. Не хотите поработать у нас в роли продажника ИТ курсов?

Ответить
Развернуть ветку
Bo.G

мне просто интересно, что же вам ясно? какие знакомые слова вы для себя нашли..

Ответить
Развернуть ветку
говнокот

Я не знал, что чтобы предотвратить deadlock нужно понимать как работает железо. Спасибо за наводку.

Ответить
Развернуть ветку
Bo.G

дедлок, как правило, возникает при
неправильно спроектированной физической
структкре, когда достаточно длинные, как правило,
гетерогенные (например в storedproc иои трггеррах используются запросы к внешним
источникам, данных. например шине данных или микросервису.
что в сложных продуктах сплошь и рядом. или наблюдается
лавиннобразный рост нагрузки вследствие того, что данные должным образом не
декомпозированы (бывает перебор в обе стороны), не распределены по логическим единицам - табличным пространствпм, а те,
в свою очередь по физическим файлам и дискам) транзакции.
так вот, неправильно спроектированные структуры данных
(в простонародье - таблицы), индексные структуры, ограничения и линки (сетевой транспопт)
в высоконагруженных системах способны творить чудеса.
работает себе система и тут прилетает регламентный запрос из внешней системы,который нельзя
игнорировать. и все... блокировка вам обеспечена со всеми вытекаюшими, вплоть до физического возгорания серверов
(я не говорю про рассыпавшиеся диски)
не забываем, что все это работает в связке и образование
очереди в одной системе влечет коллапс остальных.
порой, достаточно проанализировать, например, распрелеление данных
в отношении и правильно разнести горизонтально сократив в разы их кардинальность
как всё встает на свои места, или написать "пару строк" хинтов с
адаптировав типовой запрос.
и это касается только мизерной части всего этого добра.
конечно, для микро БД всем жтим можно пренебречь.
Но когда у тебе карлинальность в сотни миллионов кортежей и
интенсивность запростов 200-300 в секунду. говнокодить без понимания
настоятельно не рекомендуется. иначе, есть неиллюзорный риск про.. того, что
система ляжет с корраптом редо логов.
про фронт тоже отдельная песня..

Ответить
Развернуть ветку
говнокот

-

Ответить
Развернуть ветку
174 комментария
Раскрывать всегда