Я уже давно видел ту статистику на another-it и проверил свой C# по России на xx (там поиск только в заголовке) - реально выдало около 300 вакансий, плюс минус.
В щасливые стародавние времена у меня по моим фильтрам так же по России (там куча всего было с NOT, но основное тот же C#) - выдавало 1000-1200 вакансий.
Так вам шашечки или ехать? Лучше вообще без шансов трудоустройства? И чем это отличается от времен до ковида?
Кстати, вспомнил, попалась вакансия типа с 32 откликами (вместо 300-500-1000) из условного Екатеринбурга. Там как раз было написано - работа в офисе, проживание в Екатеринбурге.
Я специально говорю что согласен на озвученную вилку (они в 95% ниже действительно рыночной зп), чтобы потом уже пытаться главным боссом договориться на нормальные деньги, если пройду все собесы.
И еще интересный момент - в обеих статьях вы рассказываете какие плохие кандидаты, в прошлой статье взяли джуна на требования мидла с целью «научим» (это как раз говорит о том что зарплата рыночная только в голове руководителя или кто там у вас зп определяет).
Так вот, если в итоге нанимают «плохих» кандидатов, то как компания вообще работает и как двигаются проекты? Если судить по тому как написано - так можно только в носу ковыряться. Это у вас там случаем не «завод, где ИТ - непрофильный, убыточный отдел»?
Интересно, но свою текущую компанию не нашел - продуктовая, но не биг тех. По описанию вроде похоже, но у нас нет метрик и процессы не очень. Не нравится, что продукты пилятся как лоскутное одеяло. Но в такой компании я в итоге работаю дольше всего - 6 год пошел, раньше было 2-3 года.
Я делал подобные штуки для прода. И я вообще вижу кривое задание. То как описано не заработает в проде, будет race condition за необработанные записи, потому что между условным статусом "новый" и "обработано" пройдет некоторое время.
Нужен либо дополнительный статус "в обработке", либо булева колонка "в обработке", а еще лучше lockID и lockExpirationDate. Там надо апдейтить записи в транзакции с блокировкой по строкам и проставлением статуса "в обработке", чтобы параллельный поток не взял в обработку записи, которые уже взял другой поток.
И уже на основе этого построить сначала правильный запрос в зависимости от БД - надо смотреть документацию. Запрос, в том числе, должен исключать записи со статусом "в обработке", а если сделали с колонкой lockExpirationDate - то и фильтр по ней. А потом уже думать над индексами. Ну и нагрузочные тесты.
Тем временем, Microsoft проводила масштабные увольнения: примерно 15 тысяч рабочих мест волнами с мая по июль 2025 года; скорее всего это было сделано, чтобы компенсировать прямые потери из-за CoreWeave перед следующей видеоконференцией о доходах.
Таки что увольнения все-таки из-за ЭйАй, только не в том виде как всем рассказывают?
Помусолить ее с чатом-гпт или любой другой ИИ-шечкой, по копипастить код руками, устать и задолбаться
Попробовать какой-нибудь агент, встроенный в IDE - например github copilot в режиме чата, понажимать tab, устать и задолбаться
Скачать и локально поставить Codex или аналог, подключить папку с проектом, сделать отдельную ветку в гите, скопипастить в чат описание задачи из таск трекера, немного причесать, вставить свои мысли, подсказки, ключевые точки (файлы, классы, методы) с которых стоит начать, попросить в первую очередь просканировать файлы и написать план
Одобрить или скорректировать план, запустить, пойти попить кофе, вернуться, восхититься, сделать код ревью, причесать, закомитить, отправить на ревью другому кожаному мешку
Profit
Ну а там уже дальше видно будет, всякие скилы покопать, и вот такие плагины/субагенты
Я не тим-лид, обширного опыта построения команд у меня нет, просто приходилось участвовать постольку-поскольку.
Давным-давно я официально был тех лидом пару лет и немного совмещал с тим-лидерством (не официально). Мне просто повезло с командой. И тогда же, в связи с некоторыми событиями пришлось осознать, что это две разные роли: компании, которые предлагали вакансий чистых тим-лидеров и собеседования - там совершенно другие вопросы, почти никакой техники, зато куча вопросов "а что бы вы сделали в такой ситуации {описание конфликта интересов в команде и/или с вышестоящим руководством}", на которые я не мог достойно ответить. Но таких компаний на самом деле меньшинство.
Есть 5+ летний опыт ведения продуктов, сначала в одиночку (не считая CTO), а затем в две команды со скрам мастером, продукт овнером (причем он пришел позже меня), на данный момент уже пятью программистами и 2-3 тестировщиками и недостатком ресурсов при этом (все у нас очень плотно, работы больше чем людей).
И я все еще не тим-лид и даже официально не тех-лид, просто ведущий разработчик, чтобы это не значило.
Из-за недостатка ресурсов - сразу видны проблемы с некорректным распределением обязанностей. Даже если бы у меня было желание именно тим-лидить, у меня тупо не было бы на это времени.
По моему мнению структура должна быть следующей:
Роль, которая управляет (лидит) людьми. Неважно как ее назовут (тим-лид или начальник отдела по старинке). Он нанимает, увольняет (кстати у тим-лидов зачастую таких щедростей нет, а значит и меньше рычагов влияния), он проводит 1-на-1, отслеживает настроения, думает как уладить конфликты, думает про мотивацию, обучение, выгорание, и все такое. У нас это CTO.
Роль, которая управляет (лидит) продуктом - это тот самый продукт овнер, выше я описывал то, чем он примерно должен заниматься, и я, до недавних пор, подобным занимался с продукт овнером на пару, но больше из-за того, что я был раньше. Сейчас с меня сняли эту когнитивную нагрузку
Роль которая управляет техническими решениями - опять же, не важно какое название (главный программист, тех-лид, архитектор). В начале это может быть один человек-оркестр (архитектор-программист-тестировщик). И у меня на этой позиции много работы - подумать как мы будем делать то, что хочет продукт-овнер, мониторить и тушить прод, разруливать выполнение крос-командных задач (всех пинать, чтобы задачи делались), оптимизировать, кодить непосредственно фичи, вытаскивать общие вещи на уровень компании, чтобы переиспользовать в других продуктах компании, придумывать как мы будем делать кросс-функционал типа сквозного логирования бизнес потоков через все продукты (у нас они связаны, там как-бы эко система и события перетекают из одного в другой). Ну и по мере развития продукта это потом можно разложить на отдельные роли и людей и появится команда аналитиков-программистов-тестировщиков. Что же касается взаимодействия с людьми - я могу пару-тройку раз сказать человеку что не так, но вряд ли это будет звучать мягко и дипломатично, и если ничего не меняется - я сообщаю 1-ой роли о проблемах
И главное - нужно разделить эти роли по разным людям. В целом совместить можно, но ничего хорошего не выйдет.
Я в какой-то момент (когда стартовал новый продукт) совмещал 2-ую и 3-тью роли. Когда клиентов пара-тройка - это возможно, когда их уже пара десятков, то слишком много времени уходит на саппорт, нет времени кодить фичи и там уже надо начинать строить отдел тех поддержки.
Что касается 1-на-1 - по моему, если отбросить всю мишуру, задача минимум чтоб не уволили, задача максимум чтоб повысили зп. У нас эти созвоны раньше были каждые полгода, сейчас кажется перешли на годовые. Так же у нас есть опросники, C-level опрашивают что хорошего/плохого скажешь о компании и что хорошего/плохого скажешь о {фио сотрудника}.
Короче, я с этой штукой сижу еще с net 5.0 на активном проекте в проде.
Просто по умолчанию сборка закоменчена в .csproj файле и не запускается, поэтому все хорошо.
Но если ее раскоментить...
Во-первых - раньше она дико тормозила, открываешь файл или пишешь символ в студии и оно подвисает на 1-2-3 секунды. Это крайне раздражает!
Во-вторых - сейчас, по прошествии стольких-то лет, стало вроде бы лучше (оптимизировали что ли), но теперь 12 ядерный проц грузится на 20% (и там висит в первых рядах RoslynCodeAnalisysService), коменчу сборку обратно и падает до 3-4%. На ноуте это будет жрать батарейку как не в себя.
В-третьих
Уберите комментарий и отлаживайте кодогенератор как и любой другой код на C#.
Я это прекрасно знаю и писал об этом в своей статье, но прикол в том, что это срабатывает через раз. Тупо просто не заходит, помогает перезагрузка студии например, или как потом выяснилось переключение Debug > Release > Debug.
В любом случай путь эскалации примерно такой: сами > обратиться к техническому авторитету (тех-лид / сениор) > обратиться к дипломату-психологу (тим-лид / начальник отдела).
Если это был локальный конфликт за табы/пробелы, то решат сами или с авторитетом, а если это было триггером в затянувшемся скрытом конфликте (один из них не моется и воняет) - тех лид тут не разрулит. Там может и растаскивать придется путем перевода в другую команду / отдел или увольнением.
К сожалению нет, я последний раз искал работу в 2020
Кстати в статье было бы интересно прочитать как работают pass key и one-time password
Я uuid / guid-ы храню /s
Я уже давно видел ту статистику на another-it и проверил свой C# по России на xx (там поиск только в заголовке) - реально выдало около 300 вакансий, плюс минус.
В щасливые стародавние времена у меня по моим фильтрам так же по России (там куча всего было с NOT, но основное тот же C#) - выдавало 1000-1200 вакансий.
Так вам шашечки или ехать? Лучше вообще без шансов трудоустройства? И чем это отличается от времен до ковида?
Кстати, вспомнил, попалась вакансия типа с 32 откликами (вместо 300-500-1000) из условного Екатеринбурга. Там как раз было написано - работа в офисе, проживание в Екатеринбурге.
Где-то я такое уже слышал, про недостаток 1 млн айтишников...
Вам что мало 1000 откликов на хх? 😅
О_О, я открыл ссылку на вакансию и оно перекинуло на away.vk.com сначала
Исключать резюме, где указаны только курсы в любом виде (как высшее, как место работы, как курсы)
Запрашивать и проверять подтверждение высшего образования
Запрашивать и проверять подтверждение опыта (трудовая книжка, договора, акты, оплаты, письма)
Просить приехать в офис для собеседования (даже для удаленной работы из других регионов - технически это можно сделать)
Проводить офф-лайн собес, там точно (не)будет видно всяких AI помощников.
Очередь FIFO
Думаю, комбинируя эти опции различным образом - каждый сможет найти для себя баланс количества входящих резюме и качества кандидатов.
Но это HR-ам действительно придется работать.
Главный вопрос - а переводчик с письменного врачебного языка на русский встроен? 😅
Вот с такого
В таком случае быть nice guy и работать в полсилы на двух аналогичных работах с клаудом под мышкой за две зп - выход 😏
Это уже набило оскомину, но дефицит низкооплачиваемых высококвалифицированных специалистов. В первой статье наняли джуна на роль мидла.
Я специально говорю что согласен на озвученную вилку (они в 95% ниже действительно рыночной зп), чтобы потом уже пытаться главным боссом договориться на нормальные деньги, если пройду все собесы.
Но это не соответствует тому, кого в итоге берут.
И еще интересный момент - в обеих статьях вы рассказываете какие плохие кандидаты, в прошлой статье взяли джуна на требования мидла с целью «научим» (это как раз говорит о том что зарплата рыночная только в голове руководителя или кто там у вас зп определяет).
Так вот, если в итоге нанимают «плохих» кандидатов, то как компания вообще работает и как двигаются проекты? Если судить по тому как написано - так можно только в носу ковыряться. Это у вас там случаем не «завод, где ИТ - непрофильный, убыточный отдел»?
Интересно, но свою текущую компанию не нашел - продуктовая, но не биг тех. По описанию вроде похоже, но у нас нет метрик и процессы не очень. Не нравится, что продукты пилятся как лоскутное одеяло. Но в такой компании я в итоге работаю дольше всего - 6 год пошел, раньше было 2-3 года.
Я делал подобные штуки для прода. И я вообще вижу кривое задание. То как описано не заработает в проде, будет race condition за необработанные записи, потому что между условным статусом "новый" и "обработано" пройдет некоторое время.
Нужен либо дополнительный статус "в обработке", либо булева колонка "в обработке", а еще лучше lockID и lockExpirationDate. Там надо апдейтить записи в транзакции с блокировкой по строкам и проставлением статуса "в обработке", чтобы параллельный поток не взял в обработку записи, которые уже взял другой поток.
И уже на основе этого построить сначала правильный запрос в зависимости от БД - надо смотреть документацию. Запрос, в том числе, должен исключать записи со статусом "в обработке", а если сделали с колонкой lockExpirationDate - то и фильтр по ней. А потом уже думать над индексами. Ну и нагрузочные тесты.
Таки что увольнения все-таки из-за ЭйАй, только не в том виде как всем рассказывают?
Когда будет очередная задача на работе, то
Помусолить ее с чатом-гпт или любой другой ИИ-шечкой, по копипастить код руками, устать и задолбаться
Попробовать какой-нибудь агент, встроенный в IDE - например github copilot в режиме чата, понажимать tab, устать и задолбаться
Скачать и локально поставить Codex или аналог, подключить папку с проектом, сделать отдельную ветку в гите, скопипастить в чат описание задачи из таск трекера, немного причесать, вставить свои мысли, подсказки, ключевые точки (файлы, классы, методы) с которых стоит начать, попросить в первую очередь просканировать файлы и написать план
Одобрить или скорректировать план, запустить, пойти попить кофе, вернуться, восхититься, сделать код ревью, причесать, закомитить, отправить на ревью другому кожаному мешку
Profit
Ну а там уже дальше видно будет, всякие скилы покопать, и вот такие плагины/субагенты
Я не тим-лид, обширного опыта построения команд у меня нет, просто приходилось участвовать постольку-поскольку.
Давным-давно я официально был тех лидом пару лет и немного совмещал с тим-лидерством (не официально). Мне просто повезло с командой. И тогда же, в связи с некоторыми событиями пришлось осознать, что это две разные роли: компании, которые предлагали вакансий чистых тим-лидеров и собеседования - там совершенно другие вопросы, почти никакой техники, зато куча вопросов "а что бы вы сделали в такой ситуации {описание конфликта интересов в команде и/или с вышестоящим руководством}", на которые я не мог достойно ответить. Но таких компаний на самом деле меньшинство.
Есть 5+ летний опыт ведения продуктов, сначала в одиночку (не считая CTO), а затем в две команды со скрам мастером, продукт овнером (причем он пришел позже меня), на данный момент уже пятью программистами и 2-3 тестировщиками и недостатком ресурсов при этом (все у нас очень плотно, работы больше чем людей).
И я все еще не тим-лид и даже официально не тех-лид, просто ведущий разработчик, чтобы это не значило.
Из-за недостатка ресурсов - сразу видны проблемы с некорректным распределением обязанностей. Даже если бы у меня было желание именно тим-лидить, у меня тупо не было бы на это времени.
По моему мнению структура должна быть следующей:
Роль, которая управляет (лидит) людьми. Неважно как ее назовут (тим-лид или начальник отдела по старинке). Он нанимает, увольняет (кстати у тим-лидов зачастую таких щедростей нет, а значит и меньше рычагов влияния), он проводит 1-на-1, отслеживает настроения, думает как уладить конфликты, думает про мотивацию, обучение, выгорание, и все такое. У нас это CTO.
Роль, которая управляет (лидит) продуктом - это тот самый продукт овнер, выше я описывал то, чем он примерно должен заниматься, и я, до недавних пор, подобным занимался с продукт овнером на пару, но больше из-за того, что я был раньше. Сейчас с меня сняли эту когнитивную нагрузку
Роль которая управляет техническими решениями - опять же, не важно какое название (главный программист, тех-лид, архитектор). В начале это может быть один человек-оркестр (архитектор-программист-тестировщик). И у меня на этой позиции много работы - подумать как мы будем делать то, что хочет продукт-овнер, мониторить и тушить прод, разруливать выполнение крос-командных задач (всех пинать, чтобы задачи делались), оптимизировать, кодить непосредственно фичи, вытаскивать общие вещи на уровень компании, чтобы переиспользовать в других продуктах компании, придумывать как мы будем делать кросс-функционал типа сквозного логирования бизнес потоков через все продукты (у нас они связаны, там как-бы эко система и события перетекают из одного в другой). Ну и по мере развития продукта это потом можно разложить на отдельные роли и людей и появится команда аналитиков-программистов-тестировщиков. Что же касается взаимодействия с людьми - я могу пару-тройку раз сказать человеку что не так, но вряд ли это будет звучать мягко и дипломатично, и если ничего не меняется - я сообщаю 1-ой роли о проблемах
И главное - нужно разделить эти роли по разным людям. В целом совместить можно, но ничего хорошего не выйдет.
Я в какой-то момент (когда стартовал новый продукт) совмещал 2-ую и 3-тью роли. Когда клиентов пара-тройка - это возможно, когда их уже пара десятков, то слишком много времени уходит на саппорт, нет времени кодить фичи и там уже надо начинать строить отдел тех поддержки.
Что касается 1-на-1 - по моему, если отбросить всю мишуру, задача минимум чтоб не уволили, задача максимум чтоб повысили зп. У нас эти созвоны раньше были каждые полгода, сейчас кажется перешли на годовые. Так же у нас есть опросники, C-level опрашивают что хорошего/плохого скажешь о компании и что хорошего/плохого скажешь о {фио сотрудника}.
ОО, меня тут заминусовали...
Короче, я с этой штукой сижу еще с net 5.0 на активном проекте в проде.
Просто по умолчанию сборка закоменчена в .csproj файле и не запускается, поэтому все хорошо.
Но если ее раскоментить...
Во-первых - раньше она дико тормозила, открываешь файл или пишешь символ в студии и оно подвисает на 1-2-3 секунды. Это крайне раздражает!
Во-вторых - сейчас, по прошествии стольких-то лет, стало вроде бы лучше (оптимизировали что ли), но теперь 12 ядерный проц грузится на 20% (и там висит в первых рядах RoslynCodeAnalisysService), коменчу сборку обратно и падает до 3-4%. На ноуте это будет жрать батарейку как не в себя.
В-третьих
Я это прекрасно знаю и писал об этом в своей статье, но прикол в том, что это срабатывает через раз. Тупо просто не заходит, помогает перезагрузка студии например, или как потом выяснилось переключение Debug > Release > Debug.
Не уверен, что всегда тех лид...
В любом случай путь эскалации примерно такой: сами > обратиться к техническому авторитету (тех-лид / сениор) > обратиться к дипломату-психологу (тим-лид / начальник отдела).
Если это был локальный конфликт за табы/пробелы, то решат сами или с авторитетом, а если это было триггером в затянувшемся скрытом конфликте (один из них не моется и воняет) - тех лид тут не разрулит. Там может и растаскивать придется путем перевода в другую команду / отдел или увольнением.