186

Ответ на пост «ИТ Пузырь»2

Прочитал пост и 200+ комментов, которые на сейчас есть. Вроде никто не указан на важное — реально выросла потребность в разработчиках. Это одна из причин драйва зарплат — конкуренция работодателя за кадры, т.к. предложение меньше спроса.


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


А дальше проблема — никто не умеет поточно готовить крутых специалистов. Программы в институтах устаревают ещё к моменту формирования. Технологии быстро изменяются. Хороший разработчик, став преподавателем, быстро теряет технический скилл и отстаёт от рынка. Более того, нередко хороший разработчик не является хорошим педагогом, потому что это совсем другая область деятельности. Уметь донести материал, уметь построить лекцию, уметь проверить знания (в условиях, когда студенты всеми силами пытаются халявить) сложно.


Условно, middle python разработчик решил пойти преподавать. У него года два или три займёт получить опыт преподавателя, и, возможно, он станет хорошим преподавателем. Но он уже на 2-3 года устарел по технологиям. Да, изменилось не всё. У нас всё ещё семиуровневая модель в интернете. Но всё поменялось вокруг.


И зарплаты у преподавателей такие себе. Например, возьмём топ технических вузов. Пусть будет №13 по рейтингу — МИРЭА. Смотрим их зарплаты — старший преподаватель до 30 лет будет получать 127к в месяц. Это 110к на руки. А после 31 года уменьшится стимулирующая надбавка за молодость и зп упадёт до 107к (93к на руки). Вспомним рейтинг зарплат с хабра за 1 полугодие 2022 года? Медианная зарплата разработчика в Москве 180к.


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


Большой спрос на ИТ-специалистов пытаются закрыть платные курсы. Типа вместо полезной математики и кучи бесполезного типа философии в институте мы даём только профильное, поэтому и в срок до года можно уложиться. Но, к сожалению, высокая цена не является гарантией качества. Более того, посмотрите вакансии спецов, которых набирают на курсы для code review или преподавания. Там опять зарплаты ниже, чем у разработчиков. Что в результате? В среднем мы имеем либо совсем инфоцыганские курсы, либо дорогие курсы со средним материалом. Я сейчас про курс "с нуля до middle", с ними основные проблемы. Есть исключения. Например, есть небольшие курсы по отдельным технологиям, которые вполне могут быть оправданы.


Институты и хорошие курсы (платные или бесплатные) держатся на тех активистах, которые и разработку продолжают, и хотят делиться знаниями. Если знаете таких активистов, скажите им спасибо :)


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


А ещё растёт потребность в управленческих должностях (team lead и прочие ребята). С их подготовкой вообще ужас — им нужен опыт управления людьми. А где его взять? Как создать условия, чтобы после института/курса на выходе был team lead с реальным опытом руководства несколькими командами? Переквалификация разработчиков в team lead имеет кучу неприятных побочных эффектов. Разработчик привык управлять послушным компьютером, а тут непослушные и недетерминированные люди. Ужас.


Даже область HR стагнирует. Они совсем не умеют подбирать кадры.


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


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


Что сделал я для исправления ситуации? В телеграмм-канале devfm разбираем разные нюансы из жизни разработчика на Python и не только. Стримы по программированию, что такое WSGI, как спроектировать сервис, чему стоит научиться в вузе. По пятницам у нас культурный код с фильмами, книгами и всяким разным.

Правила сообщества

Публиковать могут пользователи с любым рейтингом. Однако!


Приветствуется:

• уважение к читателям и авторам

• конструктивность комментариев

• простота и информативность повествования

• тег python2 или python3, если актуально

• код публиковать в виде цитаты, либо ссылкой на специализированный сайт


Не рекомендуется:

• допускать оскорбления и провокации

• распространять вредоносное ПО

• просить решить вашу полноценную задачу за вас

• нарушать правила Пикабу

Вы смотрите срез комментариев. Показать все
0
Автор поста оценил этот комментарий

А кстати какие вопросы вы на собесах задаете?
Я вот гоняю по трассировке одного небольшого цикла, есть небольшое тестовое задание(для тех в чьих скиллах сильно не уверен), задачи на собесах тоже не люблю, они сильно оторваны от реальности.

Собственно цикл:
for (var i = 0; i < 4; i += 1) {

setTimeout(() => console.log(i), 0);

};


На мой взгляд вполне годно для вопроса.

Ну и опыт, к моему удивлению многие кандидаты даже не могут достойно рассказать чем занимались и что интересного они писали.
раскрыть ветку (29)
3
Автор поста оценил этот комментарий

Хм, где-то недавно видел такой код. В плане на него могут наткнуться именно в контексте подготовки к собесу.


Пытаюсь переосмыслить опыт собеседований, поэтому текущее предложение может быть нерелевантным. Сейчас я бы делал так:

1. Для джуна — live coding по его специальности объёмом 10-30 строк. Представьте, что он уже ваш коллега и ему надо выдать подзадачу. Можно пользоваться интернетом и чем угодно, надо решить задачу. Например, сделать http-endpoint или консольное приложение. Полученный код обсудить. Указать на проблему и уточнить пути решения. Если есть портфолио/опыт каких-то, пусть и учебных проектов — обсудить их. Внимание обращать на мотивацию, особенно в стиле "захотелось вот эту штуку прикрутить".

2. Для миддла — дать 10-30 строк на code review из недавнего в команде (с упрощением и вырезанием специфики). Без хитрых неочевидностей внутри, типа что будет в результате all([bool(5.0), int(False)]). Надо понять, что делает код и указать на проблемные места. Дальше пробежаться по нужным технологиям (типа по обязательным вроде docker и что нужно по вакансии типа kafka). Обсуждение его проектов, внимание на взаимодействие в команде, хотя бы уровня постановки задачи (что умеет уточнять) и реакции на критику.

3. Для сеньора такое же code review, но тут важно, как он донесёт мысль и будет аргументировать свою точку зрения. Токсичный отзыв о коде должен насторожить, т.е. code review должен быть не только про технологии, но и про взаимодействие с людьми, которые этот код писали. Дальше system design на основе его опыта, а не в вакууме. Обсуждение задач, которые недавно стояли в команде.


Понятия не имею, как собеседовать team lead.

раскрыть ветку (5)
1
Автор поста оценил этот комментарий

10-30 строк в лайвкодинге, хм трудно уложить хоть что-то в подобное, впрочем джуну пожалуй и не нужно знать архитектурные заморочки.

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

Спасибо за инфу, интересный подход )

раскрыть ветку (4)
1
Автор поста оценил этот комментарий

Если джун умеет код писать, то это уже за счастье. Какая архитектура :)


В моей области (python backend + немного data science) докер обязательная штука. Не в плане чего-то сложного, а простое применение — понимать про порядок слоёв, про создание dev-контейнера вместо перестроения каждый раз и всё такое. То есть как git — уметь применять на базовом уровне

раскрыть ветку (3)
1
Автор поста оценил этот комментарий

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

Ведь архитектурные ошибки имеют куда больший эффект, правильно построенная архитектура приложения решает тонны вопросов и проблем.

Докер не везде используется просто. Я например с ним сталкивался один раз, когда поднимал текущий фронт и настраивал nginx конфиги, собственно и с полной конфигурацией nginx я первый раз столкнулся, раньше это сделали девопсы.
Это не особо сложно, просто об этом быстро забываешь ибо делаешь это один раз, а потом оно работает и все.

раскрыть ветку (2)
0
Автор поста оценил этот комментарий

Архитектура важна. Но её джуны могут её не знать, поэтому спрашивать не имеет смысла


В моей области докер нужен, поэтому спрашиваем

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

да согласен, джунам не особо нужна.

2
Автор поста оценил этот комментарий
Задача довольно банальна. Я дошел до уровня архитектора и каких только собеседований не проходил. Самое сложное было в Майкрософте. Самые дикие и тупые - в Деливери и Яндекс.
Да и что рассказывать об опыте? Чаще всего это стандартный код - мало кто может похвастаться инновациями. Да и тот же NDA.
Я вот активно пишу на 6 языках и еще на трёх по чуть-чуть. И чаще всего ничего нового
раскрыть ветку (6)
1
Автор поста оценил этот комментарий

я тоже смотрю в сторону архитектуры активно, 6 языков - ну у меня пока стэк:
React js, соответственно TS, ну и прочий фронтовый стэк, думаю вы и так знаете.
Ну и много опыта на бэке с C#, .net, .net core, EF, SQL(не в формате тупой запрос, а я действительно неплохо знаю SQL) это кстати чего многие на бэке не знают.

Не так давно улыбался когда один рассказывал мол - я не знаю SQL дальше базовых Select, ведь у шарпа есть LINQ и EF, мол при наличии ORM не нужно знание сырого SQL, видно парень даже не знает во что преобразуется запросы LINQ to entity, почему там так важен порядок и почему хорошее знание SQL может сильно помочь с оптимизацией LINQ запросов. Да и вопросы индексации ORM не решает.

Об опыте - да банально, прикольные фичи. У меня вот когда я был джуном была система логирования которую я встроил в приложение, по своей инициативе, очень интересная фича была, мидл - целый блок интеграции с jira через кафку.
на уровне мидла же уже фронт - там вообще приложение в пром с нуля вытолкал я в соло )

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

раскрыть ветку (5)
2
Автор поста оценил этот комментарий
Я только за последние 5 лет сделал кучу таких фич, от синхронизации контрактов между сервером и мобилками на основе гита (на js) и заканчивая самостроящимся реакт приложением на основе конфигов (вплоть до цвета кнопки).
SQL и noSQL считаю мастхев для бакенда.
Но вот есть у меня опыт работы с одной легаси системой, которая регулировала все доступы и всех пользователей, включая разрешения и почту, синхронизации с другими для одной компании мирового масштаба. Там даже видно было как они работают со странами под санкциями. Но как только я начну рассказывать подробности - придется говорить кто это, а по NDA я это делать не могу. Да и подробности, хоть и технические, могут легко им навредить.

Но вот среди знакомых у меня много тех, кто такого не делал.
раскрыть ветку (4)
1
Автор поста оценил этот комментарий

"У меня есть проекты под NDA" != "У меня только проекты под NDA". Кроме того, многие штуки являются общими принципами system design, эти принципы и можно обсудить.


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

раскрыть ветку (3)
1
Автор поста оценил этот комментарий
Задачи есть. Но я уже как 10 лет работаю полностью под NDA. Только недавно у меня появилась возможность и послабления кое-что рассказывать и делиться. Плюс свои рабочие проекты
раскрыть ветку (2)
1
Автор поста оценил этот комментарий

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

раскрыть ветку (1)
1
Автор поста оценил этот комментарий
На самом деле много чего, например, я репортил 3 года назад баг хрома, который его роняет и все еще не исправлен. Причём баг банальный, но GC его упорно не видит.
Буквально 5 лет назад я не мог вообще ничего шарить. Сейчас могу чуть больше)
1
Автор поста оценил этот комментарий

За такие вопросы, бить надо

раскрыть ветку (3)
0
Автор поста оценил этот комментарий

Не прошли behavioral interview за токсичность :)

раскрыть ветку (1)
0
Автор поста оценил этот комментарий

Обычно если такие вопросы, бехевиара там точно нет:))

0
Автор поста оценил этот комментарий

хах, вам перезвонят XD

0
DELETED
Автор поста оценил этот комментарий

Что есть трассировка пришлось гуглить:) Тот момент что setTimeout выведет последнее значение i из цикла, тоже не сразу стало очевидно)) Да ещё и 4...


Минус в том что далеко не каждый месяц или даже год setTimeout приходится использовать, за разработку предыдущего проекта(2 года работы) не использовал его ни разу:)

раскрыть ветку (11)
1
Автор поста оценил этот комментарий

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

На самом деле сменить var на let и все будет замечательно, но надо также понимать сколько переменных будет создано и в каких рамках )

Из перлов - мужик сказал вернет true, я как бы ожидал всего, но чтобы true XD

Достаточно это увидеть, даже если неправильно оттрассировал в моем понимании, не заметил - это бывает, это нормально, тем более на собесах все нервничают.

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

Я согласен, код далек от реальности, но я вот думаю, мб не как трассировку его давать, а как рассуждение что делает этот код. Чтобы было видно что человек понимает как работает стэк вызовов, очередь задач и замыкания на практике потому что это важно на самом деле, а сталкиваешься с этим обычно на больших конструкциях, которые в собес не пихнешь. Для мидла имхо это нужно. Джун может и не знать.

Мне честно говоря весьма трудно проводить собесы, у меня на фронт 1.5 года опыта и раньше я никого не вел, так что вживаюсь в новую роль, надеюсь джун сможет у меня научится некоторым плюшкам, как минимум стейт менеджер стал для него открытием XD

Но все же недостаток опыта сказывается, местами жутко подгорает на кривость жыэс в сравнении с шарпами, в общем мышление бэка я полностью так и не изгнал )

раскрыть ветку (10)
1
DELETED
Автор поста оценил этот комментарий

Фронт 12 лет, хотя плотно JS использую лет 6 только, до этого в основном верстка и минимум jquery.  Тем ни менее, задачи такого рода меня легко свалят, нужно повторять базовые вещи:)


В данном случае, краткая функция передаваемая в setTimeout области видимости не имеет, то есть область у неё от setTimeout. Для setTimeout это текущая итерация цикла.


var i будет виден за пределами цикла, то есть при взятии его после завершения цикла, значение будет последним.


let имеет область видимости внутри цикла, вызываемый setTimeout в замыкании запомнит текущее значение let.


Эх... Надо повторять матчасть))

раскрыть ветку (5)
1
Автор поста оценил этот комментарий

код просто мелкий но много в себе содержит, много вопросов намешано.

Собеседования это диалог имхо - главное чтобы было видно как человек мыслит, многие дают ответ формата 1,2,3,4 но на самом деле главное смогут ли они понять почему он не верный когда я обращаю внимание на var, хотя многие воспримут как провал, трудно людей на собесах успокоить)

Я сам такой же, на собесах ничо промямлить не могу, память как рукой стирает ._.

раскрыть ветку (4)
1
DELETED
Автор поста оценил этот комментарий

Показательные, да, различия между var и let. Не сразу очевидно, что var обновится в замыкании. Замыкание же указывает на условия при итерации цикла.


Действительно, может поставить в тупик, особенно на нервах.


Составил для себя тестовый пример:


С let:


let arr = [];

for(let i = 0; i < 4; i++){

arr.push( {"a": () => console.log(i)} )

}


for(let obj of arr){ obj.a(); } //0, 1, 2, 3



с var:


let arr = [];

for(var i = 0; i < 4; i++){

arr.push( {"a": () => console.log(i)} )

}

for(let obj of arr){ obj.a(); } //4, 4, 4, 4

раскрыть ветку (3)
2
Автор поста оценил этот комментарий

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

раскрыть ветку (2)
1
DELETED
Автор поста оценил этот комментарий

php после js такой милый и приятный язык, писал на нем несколько лет:) Жаль что там требуется куча дополнительных навыков, для нормального уровня:)

0
Автор поста оценил этот комментарий

А на фронте не считается?

0
Автор поста оценил этот комментарий

А код надо в голове выполнить, или за компом?

раскрыть ветку (3)
0
Автор поста оценил этот комментарий

вот этот в голове, потому он и маленький и простенький и без наворотов.

За компом имхо - лайвкодинг больше зайдет, да и в целом не представляю лайвкодинг без IDE, разве что специфика компании такая.

Хотя если как рассуждение в формате поскакали по брейкпоинтам - хммм, мб, но не слишком ли просто тогда?

раскрыть ветку (2)
1
Автор поста оценил этот комментарий

Просто нюансы областей видимости без компа можно и не вспомнить в стрессе.


Я про livecoding с IDE, причём в любой.


Ужас, как много начинающих разрабов нынче не умеют в debug вообще и брейкпоинты в частности

раскрыть ветку (1)
1
Автор поста оценил этот комментарий

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

А так не знаю, смотря где дебажить, на фронте с дебагом проще обычно, а вот бэк - там да, те же самые коварные ORM. У меня на первой работе был тех. лид, он шарпы дебажил вплоть до IL кода, потрясный мужик.

Про дебаг я вот этот мемас люблю.

Иллюстрация к комментарию
Вы смотрите срез комментариев. Чтобы написать комментарий, перейдите к общему списку

Темы

Политика

Теги

Популярные авторы

Сообщества

18+

Теги

Популярные авторы

Сообщества

Игры

Теги

Популярные авторы

Сообщества

Юмор

Теги

Популярные авторы

Сообщества

Отношения

Теги

Популярные авторы

Сообщества

Здоровье

Теги

Популярные авторы

Сообщества

Путешествия

Теги

Популярные авторы

Сообщества

Спорт

Теги

Популярные авторы

Сообщества

Хобби

Теги

Популярные авторы

Сообщества

Сервис

Теги

Популярные авторы

Сообщества

Природа

Теги

Популярные авторы

Сообщества

Бизнес

Теги

Популярные авторы

Сообщества

Транспорт

Теги

Популярные авторы

Сообщества

Общение

Теги

Популярные авторы

Сообщества

Юриспруденция

Теги

Популярные авторы

Сообщества

Наука

Теги

Популярные авторы

Сообщества

IT

Теги

Популярные авторы

Сообщества

Животные

Теги

Популярные авторы

Сообщества

Кино и сериалы

Теги

Популярные авторы

Сообщества

Экономика

Теги

Популярные авторы

Сообщества

Кулинария

Теги

Популярные авторы

Сообщества

История

Теги

Популярные авторы

Сообщества