Comments 177
Промпт, видимо, был такой: "напиши статью про проблемы найма из-за того, что на рынке полно "волков", которые нарисовали себе опыт и знание технологий".
Пруфы?
Я 2 месяца писал её.
Я почти год проводил собеседования, насмотрелся на людей.
Очень мало технической конкретики, кроме SQL-табличек ничего нет. Статья упоминает задачи на code review и написание кода, но ни одного примера нет, а это было бы интересно на техническом ресурсе. Ситуация же с наймом известна и такая уже несколько лет, ничего нового статья не сообщает. Примеры диалогов с кандидатом-вруном, увиливающим от ответа - это в любой школе подглядеть можно. Из-за этого текст полон воды и повторения одного и того же разными словами. Ну и по стилю жёстко отдаёт нейронкой.
Если что, то мой стек примерно такой же, как ваш. Задачу на написание кода я даю такую: написать самый простейший publish-subscribe, ожидаю что-то типа guava event bus, а если напишут что-то типа spring ApplicationListener - я охренею. Обычно начинают писать кафку. Задача на code review - я написал классик, который сопоставляет заказы на покупку и продажу, на 15 строк примерно, его ревьюим.
Вы правы. Статья больше про советы. Она и так объёмная. Конкретные задачи думал выложить отдельной статьёй. Но это тоже непросто, куски кода большие.
Как я упоминал, у меня не сколько задачи, сколько шаблоны задач, которые я могу адаптировать под людей. Все вариации я не перечислю при всём желании. Код показал для примера, чтоб была понятна примерная сложность задач. Ничего космического. Микросервис не надо писать за полчаса.
Нейронкой (алисой) я смягчал стилистику и правил опечатки только, ничего больше.
Почему кажется, что отдаёт нейронкой? Написаны конкретные действия и советы.
Что именно и в какой школе поглядеть можно? Я воспроизвёл реальные диалоги, они слишком абсурдны, чтобы быть придуманными. Проведя пару сотен собеседований, можно набрать много такого материала.
Очень мало технической конкретики
Cкажем прямо, статья написана только ради того, чтобы обгадить вкатунов-"волчат".
Статья не техническая, а околотехническая, хабы - найм и наниматели. Конкретные задачи и разбор стоят отдельной статьи, раз есть интерес у людей. Ну и удваивать размер статьи не стоит деталищацией примеров - сложнее чтать будет.
Статья для того, чтоб обгадить мошенников - плохо? На самом деле там конкретные рецепты и кейзы, если читать после первой картинки.
А чем по вашему плох ApplicationListener в спринговом приложении ?
Он не плох, он прекрасен. Я имел в виду "охренею" в хорошем смысле. Мне очень нравится дизайн, когда тип получаемого события указывается как generic-параметр интерфейса и всё, этого достаточно. Я не стал смотреть, как оно работает, я знаю, как я бы это сделал, это красивая идея. Если до этого додумается человек на собеседовании, то я приятно удивлюсь и буду о нём очень высокого мнения.
Разметка очень похожа на LLM, мой мозг после первых пары абзацев пометил как LLM и отказался читать дальше.
А чем именно похоже? Я проверял опечатки и сгладил стилистику алисой, но там непринципиальные изменения, имхо, вышли.
Структурирование, склонность к выделению жирным типа важных мест.
Блин, а я очень долго писал тезисы, чтоб потом развернуть их, чтоб было понятнее, а не просто завязка-конфликт-кульминация-развязка. Оказывается, не надо было.
Вот я тоже так пишу обычно: сначала заголовки–тезисы и структура, потом уже подробности и текст. Но я и есть нейросеть—почти сорок лет уже её тренирую.
И я так же писал-пишу эти статьи, от h1 к h2 и h3, а потом и абзацы получаются. Некоторые считают, что структурированное последовательное изложение - удел нейронок. Печально.
Ну тут скорее совокупность с выделениями, просто структурировано просто маячок, а когда по тексту жирным выделяются фразы, это уже для меня ллм детектед.
Люди вскоре поделятся (уже делятся) на 2 категории - кто может читать "нейрослоп" и кто не может. Нейронка уже работает как валидатор и корректор стиля и семантики (типа, валидации грамматики и пунктуации в офисных пакетах). Но она же добавляет свой собственный стиль и свои собственные термины. Люди, по сути, через нейронки согласуют свой образ мышления. Причём на разных языках. Это круто. Но не все смогут.
Пыхтение, паника, опровержение ©
тут в соседней статье человек под ваш стек сидит без работы
Увы, команда набрана. Помимо стека много других аспектов есть.
Спасибо, почитаю.
найм джунов почти везде приостановлен
Пообщался. У него не совсем наш стек. Да и дело не в стеке, а в формальном опыте, по регламентам компании, в которой работаю, а также многих других, есть некий порог, требования к образованию. Пообщаемся ещё, может помогу консультациями.
Последние неск. лет почти нет вакансий джунов, по крайней мере по сравнению со старшими уровнями, довольно печально.
Очень жаль что вы не озвучили эти аспекты в своём списке требований, раз теперь выясняется что формальные технические требования не являются решающими.
Вы же понимаете что это та самая проблема на которую жалуются соискатели?
Нет, эти требования ставятся для фильтрации до того, как я получаю резюме. Скрининг типа, или проще, разговор с эйчаром. Это вне скоупа моей статьи. Так же как и отказ СБ при наличии судимостей. Понятно, что во многих компаниях это стопающий фактор, и в статье я не освещал его.
А соискатели много на что жалуются. Статья не совсем об этом, а взгляд "с другой стороны баррикад".
Хорошая статья. Спасибо.
Великолепная и практичная статья. Live-coding, код-ревью, SQL, импровизация собеседующего на техническом интервью - работающие инструменты отбора. Оценка технических навыков и реального опыта в первую очередь.
Идеальный кандидат 25-30 лет.... Пара па па па... Пам
У руководителей было такое мнение. Удалось доказать, что не правы. Сейчас в команде есть несколько человек постарше.
Тоже сразу возраст подметил. Вы спрашиваете очень много (и вижу, что это обосновано высоким уровнем разработки в компании), причём времени на подумать и вспомнить, очевидно, нет (2 часа всего на всё про всё). Человек до 30, конечно, может иметь такую квалификацию и уверенность в обсуждаемых темах, но, по моему мнению, это больше исключение. Скорее всего, те, с которыми вам будет "интересно" поговорить - люди за (возможно, далеко за) 30. Вы и сами-то, поди, не "29-летний сеньор".
Всё так. Но входные данные (до процесса рефакторинга отбора) были как я описал. Почти все, кого я высоко оценил, были 40+. Но это не обратный эйджизм. Самые 2 крутых рок-звезды были лет 25-27. Сейчас в стриме работает парень не старше 25, который основные секции прошёл не хуже сеньоров. Архитектурные секции конечно не проходил, незачем. Конечно, это удача и редкость.
Кстати, смешно, но я никогда не был сеньором. Что на делфи - при росте из мидла сразу в управление выпал (давно было), что сейчас - дали лида минуя просто сеньора. Наверно не надо слишком серьёзно относиться к этим английским (испанским) званиям.
Тоже заметил на собесах, что осознанность в ответах на системном дизайне начинается примерно с 10 лет опыта и выше. ВУЗ заканчивают в 22 - то есть это от 32-35 лет
Для остальных тоже есть выбор - эйджизм или пенсия? Что-то из этого наверняка подойдёт )
А потом вк лежит, амазон лежит, гугл лежит🤣 Нам нужен опыт 10 лет, кандидаты до 30.
А можно, пожалуйста, нахрен убрать хаб Java для этой ни разу не технической статьи?
Будьте так любезны. В этом хабе очень хочется читать технические статьи, а не репортажи из зоопарка. Благодарю за сотрудничество.
Убрал сразу после вашего коммента, спасибо. Изначально больше кода было, подсократил, нудная и большая статья получалась
А люди не проверяют хабы, и не читая плюсуют. Около 7 плюсов за сегодня. Забавно.
А можно нахрен убрать Ваш тупой высер, не нравиться не читай, абсолютно бесполезный комментарий.
Хаба джава нет, но кто плюсует? Боты? Чукчи-не-читатели? Чудеса. После моего коммента о том, что убрал хаб джавы ещё два плюса. То есть, гипотетически, человек заходит в хаб по найму и плюсует за то, чтоб скрыть из хаба java.
"волки", очевидно) под этой статьей почти все комменты "за" (особенно те, которые выше) люто минусуются (мне и в карму пара минусов прилетела), любое возражение - заплюсовывается. Ладно хоть на Хабре хватает "мужиков", которые вывели в плюс вашу статью.
Для тех, кто пользуется RSS-агрегаторами изменение списка хабов после публикации уже ничего не изменит. Они, если следили за хабом Java через RSS, будут по-прежнему видеть вашу статью в списке.
с 10-летним опытом не могут написать работающий код в реальном времени
Так вы каждый день по 4 собеса проводите, а я по 1-4 года в одной компании работаю, и ненавижу собесы, т.к это стресс ) плюс, задача может быть нетипичной для меня - и это двойной стресс. При этом в рабочем процессе, решая повседневные бизнес-задачи, я очень быстро пишу код (разумеется, после того как я в голове сформировал рабочее решение в спокойной обстановке). Все по-разному переносят стресс - но этот факт, конечно, никому из интервьюеров не интересен )
У меня такая-же фигня когда искал работу дважды за последние 5 лет. На самом интервью можешь тупо забыть термин, как только интервью заканчивается, так он выскакивает в памяти. Или задачку, знаешь, что такое уже решал, а решить не можешь, как интервью заканчивается, сразу в голове решение.
В обоих случаях лечилось только кучей интерью, когда к стрессу привыкаешь и на каждом следующем чуть-чуть полегче, ну и когда уже от кого-то оффер получаешь, а интерью еще с другими есть, то уже на расслабоне и от них получаешь тоже, потом выбираешь.
Знаете, мне в таких случаях помогает пофигизм. Предыдущую работу искал полгода. Не торопился. Предложения были. Даже пришлось для фильтрации ценник поднять (немного помогло). Всё было не так и не то, потом устал стрессовать, включилось то ли второе дыхание, то ли пофигизм. В итоге выбирал из 4 офферов.
А специально готовиться... Наверно надо. Наверно правильно. Но если есть работа, если ответственно хочется относиться - просто некогда. То времени, то ресурсов не хватает.
То есть мы пришли к тому, что к стрессовому решению задачек "специально готовиться наверное надо". Таким образом, в очередной раз подтверждаем, что прохождение собеса - это отдельный навык, к которому надо готовиться и тренировать. Я категорически с этим не согласен, конечно, т.к. это не коррелирует со здравым смыслом ) человек должен идти вперёд, а не вечно готовиться к собесам - быть творцом, а не дрессированной обезьяной. Все же, что-то не так с современным наймом.
Я не спорю, что написание кода за зарплату и написание на интервью разные навыки. Я говорю о том , что коррелируются. Если человек проектирует и пишет реактивные сервисы, то какую-то сортировку массива примитивами или фильтрацию стрима напишет. И я утверждал, что не надо мучать искусственными алгоритмами или написанием микросервиса на собеседовании.
Искусственные задачи заставляют и кандидатов тратить время на ерунду, добавляют стресса, не показывают пригодность к конкретному проекту. Я об этом и писал несколько раз (не понимаю, почему так сильно заминусили).
Да, найм странный и не всегда логичный. Зачастую есть корпоративные правила, какой-то чек-лист на моменты в процессе интервью. Кто платит, тот ставит условия, сейчас такой тренд- двадцать этапав, двадцать согласований, литкод, 300 топ вопросов потджаве. Компании перестраховываются, уменьшают риски, делают дороже найм. Но именно через такие процессы большинство находят работу, нет смысла ужасаться несправедливости.
Опыт выполнения чего-то не означает любовь к этому.
Стресс очевиден и понятен. Очень вощможен даже с обоих сторон. Это обязательно надо учитывать при проведении интервью. Цель не унизить человека, а найти. Кажется, отказ от чтения опросника, внимательный разговор о прошлом опыте помогают снизить градус накала. Даже формирование вопросов, постановка задач для людей, прошедших горнило зеленого финтеха и не прошедших - могут быть разные. Я стараюсь учитывать бэкграунд: помимо условных задач на АБС есть похожие для логистики, продаж. По сути одно и то же, но визуально разная предметная область.
О стрессе я в статье не упомянул, но это важный фактор. Я видел и как интервьюверы стрессовали. Обычно это нивелирует возраст.
Разумеется, я ожидаю, что при live coding человек без пятилетнего опыта прохождения собеседований сморозит чушь или будет тупить, проявит себя на четверть компетенций. Всегда использую экивоки. Пока не используются прямые подсказки это не идет "в минус". Есть другие задачи и другие формулировки.
Золотые слова.. Знаю кучу людей, которые блестяще решают алгоритмы на доске, но в реальном проекте пишут нечитаемую лапшу. И наоборот: тихие технари, которые теряются на публике, но тащат на себе весь бэкенд
Могу рассказать про самый крутой собес в своей жизни в 2020-м. Парень, который его проводил сейчас работает в fb (инфраструктурная разработка), задолго до нашего сотрудничества - в yandex (помню, у него три любимых языка: js, py, и как вы думаете что ещё?.. perl)
Ну так вот задал он мне одну единственную задачку и дал открытую на своем ноуте ide без подсветки синтаксиса (это правда мелочь, не знаю зачем вспомнил). Задача простая с анаграммами, да были разговоры про js но без двухчасового вымораживания - через 20 минут мы с ним пили кофе на первом этаже; через пару дней оффер на 30К больше, чем я ожидал - и конец истории.
Выявить опыт можно, отслеживая ход мысли. И для этого просто надо пообщаться, задавая правильные вопросы, а не сидеть и смотреть на камеру собеседника и гадать, юзает он ии или нет
Да, для начала разговора достаточно простой задачи или куска кода на ревью. Если первое пытаются решить с агентами, то второе - увы. Хотя тут бывают и ложноотрицательнве результаты, не во всех компаниях есть ревью кода. Для меня это не ставит красный флаг.
Я к тому и веду, что "двухчасовая душнилка" совершенно не обязательна после "начала разговора" - это говорит о том, что нет опыта выявлять спеца за 20 минут. Вот вся проблема современного найма.
Есть опыт выявлять. А есть правила и регламент, спущенный сверху. Почему вы думаете, что опыт выявлять слабых и мошенников позволяет нарушать правила холдинга? А еще, внезапно, в холдингах записывается видео со встречи. Может полезно, может бесполезно - такие правила.
Есть одна китайская поговорка "Следи за тем что ты ешь, и у тебя изменится походка". Слепое следование регламентам делает найм хуже и приводит его то состояние в котором он сейчас - "такие правила". Кстати, впервые слышу про "правила" - занимающий должен задавать правила, т.к. его экспертное мнение решает, а не чье либо еще. Но если нет своего опыта - наверное, кроме следования "правилам" ничего не остается, чтоб выглядеть на видео встреч покладистым и "правильным" в глазах тех кто что-то "спустил сверху"
Спасибо, годная статья.
Очень перекликается с моим опытом проведения собесов в 2024. Хоть и LLM тогда были попроще и менее популярны, и волки не такие шерстяные, но вот с 10-15 годами опыта в финтехе не суметь join с group by по паре таблиц сделать - это прям классика.
Если компания большая, то человек занимается однообразной деятельностью, и не обязательно он раз в час пишет по select-у
Правильно. Но если пишет, что работал с БД, то будет просьба написать запрос из двух строк и трех полей. А иначе не надо в резюме указывать облако тегов, о многих из которых и не слышал.
Разумеется, у большинства рутина и копипаста. Но слово онбоксинг или gc должны объяснить хоть как-то, так?
Что-бы вы понимали в слове рутина, иногда из года в год. По крайней мере чел не быстро про это вспомнит.
Ну про что-то другое вспомнит? То, с чем каждый день работает- вспомнит? Не зря же в начале секция с влпросами по текущему или наиболее интересному проекту. Человек сам выбирает, о чем говорить, выбирает темы. А дальше можно обсудить нюансы и работу соображалки, так?
Я в статье писал, что нет у меня опросника, вопросы для каждого кандидата формулирую исходя из его ответов. Разве это не покрывает описанный вами кейс?
Ну я его тоже с ходу не напишу, а опыта у меня полно, просто много опыта с kv, зато сразу расскажу что это тяжёлая операция и без индексов по ключам группировки ещё и дорогая. Но синтаксис sql уже не помню.
Наверное, в таком случае вы не будете подаваться на вакансию с требованием "strong SQL skills" с резюме в котором много SQL на последних местах работы.
Нет, тем более, мне больше нравится NoSQL, но и при этом если дать мне пару дней, то я прекрасно справлюсь с тем чтобы сложные запросы сынженерить, ведь я же примерно понимаю во что это превращается на низком уровне.
Так что я при этом вполне способен тянуть бэки где есть SQL и не просто в режиме ключ значение.
Ну подсказки же могут быть. Рассказать голосом, какой должен быть алгоритм, - тоже вариант, хотя и не такой блестящий. Ну или перевести разговор в плоскость noSQL - почему и нет. Но из сотен людей никто не смог про noSQL ничего рассказать. И про РСУБД тоже мало кто мог говорить.
в резюме опыт работы подчёркивается какими-то корпоративными и экономическими показателями. Разработчик повысил довольство клиентов всей компании на 2% - не верю! Это показатель подразделения или направления бизнеса. Разработчики зачастую таких показателей не видят.
Не исключено, что HR и агентства, которые были входом в вашу воронку фильтровали резюме как раз-таки (в том числе) по наличию этих цифр, обязательно выраженных клиентских метриках.
Буквально в каждой статье рекрутеров на Хабре - рассуждения про то, что плохо, негодно писать "улучшил вот это и вот это", обязательно должно число!
Иногда в этих статья даже примеры есть - ровно такие, какими вы (да и я) недоволен.
Зачастую по примерам понятно, что рекрутер сгенерировавший/скопировавший этот пример, не пытался даже задуматься над тем, что же за этим числом скрытно и реалистично ли оно.
NB: Безусловно, если есть аналитика, позволяющая влияние задачи на деньги увидеть - это прекрасно и почему бы не указать это. Вот только даже в тех компаниях, где такая аналитика есть и считается, не каждая команда разработки в принципе может на деньги напрямую вот так повлиять.
Да, видел такие вредные советы по правке резюме. Не следовал. Видел результаты, они забавные. При уточнении у кандидата методик подсчёта или источника цифр-терялся. Порицаю ложь-выпендрёж.
Если речь идёт не о внутреннем проекте, где хоть как-то можно оценить цифровые результаты, а о внешнем заказчике, то метрики выглядят нелепо и заведомо лживо.
На своем личном примере , я как разраб понятия не имею, насколько там возросла прибыль или сократились издержки у одной из госконтор, куда мы в пром ввели свой проект в свое время. И не могу об этом знать точно. Посему фразы "увеличил прибыль на 17.8%" путем внедрения проекта X от претендующего на позицию разработчика умиляют. Но если ХРюш действительно это цепляет и выделяет тебя среди других кандидатов, то увы.
Так-то это со всяких фаангов пошло и речь у них шла не про довольство клиентов, а, например, сделал оптимизацию того-то и того-то. И тут встает вопрос: а как вы узнали, что после оптимизации стало лучше? В данном случае цифры помогут ответить на вопрос, например, TP95 у запросов был 1 секунду, стал 100 миллисекунд. Или количество запросов к бд сократилось со столькито до столько, и тд.
Это потом уже тупые курицы без понимания предметной области начали нести про важность цифр во всякой фигне.
Ну и я, честно, не особо понимаю таких ачивментов в резюме, даже для фаангов. Оптимизации того, что тормозит это просто трудодни, как их все упомнить? Для новичков, наверное, важно.
Я вот тоже так думал, когда работал в стартапах и собеседовал кандидатов. Мол, что за фигня - я лично сколько лет работаю, а понятия не имею, как конкретно мой код повлиял (или не повлиял) на бизнес-метрики.
Но не везде так. В биг техе зачастую наоборот - не столько важно, что ты там оптимизировал, насколько технически крутое решение запилил. Ты конечный результат покажи, выраженный в числах - доход для компании, количество пользователей или тот же самый customer satisfaction.
Более того, сам когда собеседовался в HubSpot (не биг тех, но все же довольно крупная контора), одной из причин отказа прозвучало "не смог внятно описать, как фича Х, про которую ты рассказывал на собеседовании, повлияла на бизнес".
Я не утверждаю, что это правильно и так и надо - но так есть, по крайней менее в ряде компаний.
То, что такие вещи (особенно в бигтехах) озвучиваются - не обязательно означает, что они используются.
В компании, где я сейчас работаю - каждое ревью вижу посты от HR-ов про то, как правильно заполнять ревьюшницу (нельзя писать внедрил штуку, которая решила проблемы соседних команд - обязательно нужны цифры! Мол, разработал и внедрил штуку, которая уменьшила TTM фичей продукта на столько-то процентов).
Спрашиваю постоянно в комментариях к этим постам, мол, покажите эту чудесную аналитику и методологию, по которой разработчик (не лид, не руководитель направления или CTO) может посчитать такую метрику (особенно учитывая, что за полугодовой период, предполагается, надо успеть штуку и разработать, и внедрить, и собрать достаточно данных для получения чиселки). При наших процессах и задачах, конечно.
Правда ли, что в большом и страшном холдинге сущесвтует в принципе хотя бы одна команда разработчиков, которая вот такие вот "цели" делает и вот так вот считает?
HR'ы мне говорят, что вообще-то должно быть просто посчитать по Jira, и намекают на то, что я глупый какой-то, раз таких очевидных вещей не понимаю.
Я им отвечаю, что если это и правда так просто посчитать, то наверное рано или поздно в компании найдётся хотя бы один живой разработчик, который и правда такое видел/делал вживую, ответит на мой комментарий и я буду очень рад у него этому научиться.
Пока таких не находится.
---
Впрочем, в прошлые года ситуация была гораздо хуже - примеров для разработчиков не было вообще, был вебинар про заполнение ревьюшницы, абсолютно все разбираемые примеры в которой были построены по схеме "привлечь X продаж в таком-то квартале". Что хорошо ложится на SMART. Но есть нюанс - b2b-продажами занимаются только продажники и в одном конкретном бизнес-юните холдинга. Вопросы "из зала" встречались искреннем недоумением, мол, ну а что вы не можете просто на свою работу перенести, почему вы вообще нас спрашиваете?
---
В другом российском бигтехе - встречал ситуацию, когда инфраструктурные разработчики делали штуку, позволяющую аналитикам запустить некоторые штуки, мотивирующие людей, работающих с приложением, заработать больше денег себе и компании (пытаюсь сейчас быть максимально расплывчатым, понимаю, что выглядит смешно). И аналитики прямо могли провести эксперимент и посчитать, мол, да, смотрите, +1 процент к прибыли бизнес-юнита за счёт этой штуки получился. Ура. На ревью, емнип, это тоже было отражено.
Это замечательно, когда такие цифры есть. Но мне непонятно, как эти цифры вообще говорят что-то о разработчике.
Допустим, я линейный разработчик в команде, которая делала это - каково моё возможное влияние на то, что мы получили +1 процент к прибыли? Рядом с этой командой сидит другая - точно такая же, они с таким же усердием делают для тех же аналитиков другую функциональность (эксперименты с которой стат значимого плюса в итоге не дали) - почему я, как разработчик, лучше чем они?
Как в этой ситуации я при могу быть лучше как разработчик, относительно непродуктовой команды, которая пилит платформу и библиотеки, позволяющие в принципе нашей продуктовой команде быстро собирать эти фичи?
Что вообще говорит о разработчике вот это "+1% к денежкам" в этой ситуация, кроме "находился в команде, которой повезло / лид+скип которой были удачливыми и прозорливыми"?
В разрезе того же самого бигтеха - разработчик зачастую сам решает, над чем работать. Чем старше должность, тем больше это прямо ожидается от него. И этот выбор, приоритизация - как раз основаны на том, как мы подвинем топлайн метрики. Каждый сам себе немножко (или даже множко) продакт менеджер.
Что вообще говорит о разработчике вот это "+1% к денежкам"
Как минимум, что разработчик понимает конечный эффект своей работы. Что позволяем ему более эффективно приоризировать ее.
Ну и да, денежки как метрика в большей степени относятся к продуктовым командам. У инфрастуктурных/платформенных команд другие цели и метрики. Но они тоже есть!
Давай подойдем с другой стороны. Написал я в резюме что-то типа "запилил такую-то клевую библиотеку, все супер-оптимально и красиво, вот такие и таки технологии под капотом". И что? Может, она никому в итоге не нужна оказалась - и я просто прожигал деньги компании.
Ну и да, денежки как метрика в большей степени относятся к продуктовым командам. У инфрастуктурных/платформенных команд другие цели и метрики. Но они тоже есть!
Это очень интересно! Без подколлов, мне искренне хочется работать в компании с нормальными измеримыми целями и выстроенными процессами (но каждый раз заносит не туда). Вполне возможно, у меня сложился слишком циничный взгляд на вещи построенный по паре точек из множества.
Расскажете? Какую метрику вы считали в качестве цели для мидла в непродуктовой команде в бигтехе? Разумеется, NDA-деталей и упоминаний конкретных компаний не прошу. Буду рад услышать либо про свой личный опыт мидла/сениора, либо со стороны личного опыта лида, менеджерящего мидла/сениора.
Опыт вида "лично не делал, но на калибровках видел, как лично знакомый лид лично знакомому мидлу такую вот цель ставил и на моих глазах через неё защищал оценку" - тоже буду рад услышать.
Но чур без каких-либо ссылок на выступления на конференциях, теоретические статьи про best practices и официальные рекомендации от hr'ов и консалтинга.
Давай подойдем с другой стороны. Написал я в резюме что-то типа "запилил такую-то клевую библиотеку, все супер-оптимально и красиво, вот такие и таки технологии под капотом". И что? Может, она никому в итоге не нужна оказалась - и я просто прожигал деньги компании.
Написал я в резюме "написал фичу, разблокирующую нашей компании несколько контрактов, в сумме на N миллионов" и что? Может быть в итоге я там техдолга наворотил такого, что меня другие разработчики и эксплуатация ещё лет десять вспоминать нехорошим словом будут, а один контрактов обернулся из-за проблем неустойкой на сумму большую, чем было разблокировано?
К сожалению у собеседующего в общем нет другого механизма "проверить" написанный пункт (что в случае с цифрами, что в случае без цифр) - кроме как задать уточняющие вопросы (в том числе "а как ты понял, что эта штука правда принесла пользу?").
А с уточняющими вопросами - кто знает? На вопрос "почему вот эта работа помогла предотвратить несколько инцидентов" я могу ответить довольно легко.
Возвращаясь к моему примеру про +1%:
На уточняющий вопрос "а как посчитано, что вот эта ваша штука добавила N денег?" на самом деле мне будет очень трудно ответить. Если бы я умел хорошо и быстро рассказывать как это считали, как сегментировали пользователей для стат.теста, учтены ли штуки вроде канибализации продукта - в моём резюме было бы не слово "разработчик", а слово "аналитик данных", например). И зарплата обсуждалась бы другая, как и скоуп задач.
Как минимум, что разработчик понимает конечный эффект своей работы. Что позволяем ему более эффективно приоризировать ее.
С одной стороны - согласен.
С другой стороны - в моём конкретном примере, где же всё-таки применить разработчику свой навык по приоретизации?
Представьте, деньги принесли какие-то "удачно предлагаемые пользователю" скидки.
Две команды сидящие за соседними столами фигачат инфраструктуру для сервиса, которая позволит аналитикам проверить N "гипотез")
Вот одна команда, допустим, сделала пробрасывание местоположения челика во все сервисы, связанные со скидками, биллингом, профилем, пробрасывание местоположение в аналитические логи по всем событиям и прочее.
Вторая команда - сделала что-то про связывание профиля челика с какими-то другими продуктами, с которыми можно интегрироваться и откуда тоже можно какие-то сигналы полезные извлечь.
Работа обоих команд позволила аналитикам провести полтора десятков экспериментов:
А что если подсовывать пользователю какие-то бонусные штуки по местоположению? (тут, допустим, пяток гипотез проверили)
А что если подсовывать какие-то бонусные штуки по сигналу от интеграций второй команды? (тут, допустим, пяток гипотез проверили)
И, допустим, 5-ок гипотез, для проверки которых требовалась инфраструктура написанная обоими командами.
Вот проверили они и 14 гипотез не прокрасились в зелёный, а одна прокрасилась. Допусьтим, та, которая только на гео-инфраструктуру опиралась.
Где тут разработчик мог что-то приоритезировать? В этой ситуации ни разработчик, ни аналитик, ни продакт, ни кто-либо из топов не мог заранее угадать, какая гипотеза прокрасится в зелёный. Напротив, если предположить, что где-либо в корпорации есть хотя бы один человек, который мог бы заранее это угадывать - всех поувольнять надо было бы)
Спасибо за конструктивные вопросы.
Какую метрику вы считали в качестве цели для мидла в непродуктовой команде в бигтехе?
Сам пока только в продуктовой команде работал. Рассматриваю переход в инфра команду, общался с ними про метрики - говорят, раньше измеряли сэкономленные инженеро-часы (есть даже формулы для этого), и они признают, что было неидеально. В поиске других метрик.
На вопрос "почему вот эта работа помогла предотвратить несколько инцидентов" я могу ответить довольно легко
Вполне себе показательная метрика. Не деньгами едиными :).
Если бы я умел хорошо и быстро рассказывать как это считали, как сегментировали пользователей для стат.теста, учтены ли штуки вроде канибализации продукта - в моём резюме было бы не слово "разработчик", а слово "аналитик данных", например
Ну вот я, допустим, вполне могу рассказать, как считались результаты моих экспериментов, где упрощения и недостатки (их хватает :) ) - хотя и не аналитик.
Где тут разработчик мог что-то приоритезировать? В этой ситуации ни разработчик, ни аналитик, ни продакт, ни кто-либо из топов не мог заранее угадать, какая гипотеза прокрасится в зелёный.
Немножно не так. Тут результатом может быть "создали возможность проведения Х экспериментов аналитиками". И приоритизация тут предполагает понимание, зачем эта фича аналитикам, и почему лучше сосредоточиться на ней, а не на другой фиче, которую кто-то еще из соседней команды тоже просил.
И снова - я не топлю за то, что такая система оценки работы программиста (и как следствие - указание этих результатов в резюме) самая правильная. Я про то, что такая система реально есть, и существуют компании, для которых именно такой формат резюме имеет смысл.
И приоритизация тут предполагает понимание, зачем эта фича аналитикам, и почему лучше сосредоточиться на ней, а не на другой фиче, которую кто-то еще из соседней команды тоже просил.
Это же ровно то, что я и пытаюсь проиллюстрировать исходным примером - в рассматриваемой ситуации формулировка "сделал штуку, которая была важна для вот такой-то и такой-то команды" отражает доступную разработчику приоритезацию в этой ситуации. И импакт от работы разработчика.
Формулировка "+1% к прибыли", хотя и ложится красиво на рекомендации - не отражает по сути ничего)
Спасибо за статью, побольше бы таких! И вопросы с подвохом, как в примере, с таблицами в Эластике - идеальны, переходы на другие языки ТОП. Еще лучше для нейронок - переводить на определения с двойным значением для IT: про деревья, велосипеды и костыли, песочницы и горлышки.
сейчас Elastic Search потеряло популярность, более популярный форк называется иначе
Lucene же надо говорить )))
Понимание JVM
А вот эта максимально абстрактная вещь что вообще означает? Что хотите от кандидата? Зачем ему "понимать" JVM, чтобы что? Чтобы экономил на спичках? Чтобы знал недокументированные возможности? Или просто красиво рассказал про создание кастомного GC, который один шут будет стандартным?
Каких вы там мошенников вычисляете? Пообщались, посмотрели трудовую книжку. Всё.
Да. Но именно я не могу. И на техн. интервью трудовые не приносят. А вы на каждое интервью приносите трудовую? Не слышал никогда о таких требованиях к собеседованию.
Что мешает попросить электронную трудовую?
Вы тут волков ищете, но по факту волки - рекрутеры, которые сломали найм из за своей недалёкости. И завышенные требования по тех.части. И швец, и жнец. На дуде игрец.
У меня нет например электронной трудовой.
Я не имею права запрашивать персональные данные, трудовую и прочее. Регламенты.
Этим занимаются или должны заниматься hr.
Выгрузку СТД-СФР может сделать любой, у кого есть доступ в госуслуги. Она подписана электронной подписью, поэтому её корректность легко проверить на тех же госуслугах, некоторые HRM системы делают это даже автоматически. В тех компаниях, которые уже адаптировались к новым реалиям найма, её запрашивают или в самом начале работы с кандидатом вместе с согласием на сбор, обработку и хранение его ПДн или после первичного собеседования с hr'ом, но до технического.
Человек должен дать разрешение, а компания иметь документ для подписи. По закону это сложно. А в черных компаниях давно не работаю.
Зачем вы спрашиваете меня про процессы, которые настраивают департаменты персонала и СБ, а не лиды? Было бы что-то иначе у нас в холдинге- и статья была бы другая.
Человек должен дать разрешение, а компания иметь документ для подписи. По закону это сложно. А в черных компаниях давно не работаю.
Это сейчас работает например в ВК и Сбере, вроде не очень чёрные компании. Наверняка к этому со временем придут вообще все, так как процессы найма неизбежно приводят к работе с персональными данными кандидата, разрешения на которое он явно не давал.
Зачем вы спрашиваете меня про процессы, которые настраивают департаменты персонала и СБ, а не лиды?
Во времена моего лидства я добивался изменений в процессах, которые влияют на мою работу. Убирал из требований критерии, мешающие нанимать хороших специалистов, добавлял проверки, позволяющие с минимальными усилиями отсеивать обманщиков, изменял процесс собеседований, чтобы сделать их менее стрессовыми для кандидатов и при этом более стойкими к взлому, и т.д. и т.п. По статье у меня сложилось впечатление, что вы тоже влияете на процессы найма, а не просто пересказываете, как кто-то другой их у вас организовал.
Где в статье завышенные требования?
А кто-нибудь знает откуда их начали называть «волки»?
Сами? Маркетинг?
Это придумал их предводитель https://nazarov.community/volchistost-v-it
Сильный текст — спасибо за честность и инженерный подход. Очень откликается тезис «не под чек‑листы, а под продукт»: кастомные задачи, live‑coding и особенно code review как главный фильтр — ровно то, что действительно отсеивает «облако тегов» и показывает мышление. Понравилось, как вы обходитесь с ИИ: не демонизируете, а проверяете авторство и способность валидировать решения. Отдельный респект за динамическое интервью — подстройка глубины вопросов и терминологии под рассказ кандидата работает куда лучше «топ‑300».
Кейсы живые, считывается реальный «фронт» найма 2024–2025 и тот самый разрыв между резюме и навыками. Воронка прозрачна и честна; видно, почему ставка на code/design review окупается в проде, где важны кросс‑ревью и работа с чужим кодом.
Будет круто увидеть продолжение с примерами «семейств» задач и критериями оценки (без спойлеров), а ещё — как ваши оценки коррелируют с онбордингом через 3–6 месяцев. Но уже сейчас статья — must‑read для тимлидов и тех, кто строит найм как продукт: гипотеза → эксперимент → калибровка → результат. Спасибо, очень полезно и мотивирует подтянуть собственные процессы.
90% едва дотягивают middle-
около 10% middle-/middle+/senior- – потенциально наш кандидат
Каким образом у вас бьются эти цифры между собой? В итоге на рынке по ощущениям сколько middle-/middle/middle+?
После сотен собеседований образовалась какая-то статистика, и мы получили вывод: разрыв между ожиданием и реальностью большой.
Так а может быть дело не в кандидатах, а в ожиданиях? Возможно, что некий реальный middle, - это достаточно хороший специалист, чтобы не сидеть без работы, и его нет на открытом рынке? Или, как минимум, найм таких специалистов должен быть проактивный (headhunting - какой-то прям)?
Я не видел рынок, я видел резюме от HR, это другая выборка. Они не давали резюме джунов- зачем мне, если вакансии такой нет?
Цифры бьются так: только с каждым десятым можно было поговорить нормально, остальные или не могли о своей текущей работе рассказать, или не могли рассказать что значат термины, которые у них в резюме (если упрощать). Только каждый десятый проходил все или большинство секций интервью. Остальные могли раньше уйти или, например, писать двухстрочный запрос час. И только примерно каждый десятый проходил нужные секции хоть как-то (об этом воронка отбора). Из них примерно четверть или меньше проходило по верхней планке, а не нижней. Вот так бьется.
Резюме было очень много. Может они и не сидели дома - это не знаю. Проактивные HR тоже были одно время. Эффективность не буду оценивать. Я не ходил на рынок, не стоял у метро с плакатом и не шерстил линкедин, только принимал поток резюме от кадров. У них на входе он был ещё больше.
Миддл, который не может написать 2 строчки на джаве и 2 на сиквеле- не миддл.
Возможно, где-то есть какой-то выдуманный кем-то миддл, статья не о них, а о потребностях бизнеса и реалиях.
Миддл, который не может написать 2 строчки на джаве и 2 на сиквеле- не миддл.
С этим никто не спорит.
только с каждым десятым можно было поговорить нормально
То есть после отсева со стороны HR, квалификация, соответствующая требованиям вакансии, была только у 10% соискателей. И то не каждого из них можно взять на работу, насколько я понял.
Проблема не в HR, а в новой реальности, где мошенники адаптируются быстрее бизнеса.
Нет, проблема не в этом, а в том, что на рынке нет квалифицированной рабочей силы в избытке. Вы же сами говорите про соотношение 1 из 10. А на ваши потребности как бизнеса такой штуке, как экономика, абсолютно по боку. Компании либо джуновские позиции должны открывать и растить в мидлы, либо создавать такие условия, что работающие кадры будут готовы сменить компанию.
И дело тут не в волках, овцах или курах. Они никак не влияют на количество соискателей, соответствующих требованиям вакансии. Вы же не по CV берете на работу, а после 2-3-4 стадий собесов. Количество соискателей на входе влияет только на процесс найма, но никакого отношения к качественному составу рабочей силы не имеет.
А говорить про процесс найма смысла нет, толпа на входе - это норма для любой отрасли, где есть зп выше средней и удаленка. Вы откройте вакансию менеджера по продажам чего-либо на удаленке с доходом от 150к и посмотрите, сколько вам откликнется людей.
Нет, проблема не в этом, а в том, что на рынке нет квалифицированной рабочей силы в избытке
Нужной квалификации, а не какой-то другой. Увы. Думаю, у всех так- хорошие спецы редки и сидят в тёплом месте. Но если (субъективно) раньше просто мало народу откликались, то теперь надо фильтровать шум.
Галеры позакрывались, а там волки и джуны, которых продавали как архитекторов.
растить в мидлы
Я согласен. Бизнес - нет.
Они никак не влияют на количество соискателей, соответствующих требованиям вакансии.
Соответствующих.
А нарисованные резюме путают и отвлекают.
Вы же не по CV берете на работу, а после 2-3-4 стадий собесов
У нас фактически 1. Разговор с C-руководителем редко фильтрует. В этом и сложность- за два часа получить столько же информации, сколько другие холдинги получают за 20 часов.
А говорить про процесс найма смысла нет, толпа на входе - это норма для любой отрасли, где есть зп выше средней и удаленка.
Первое да, второе нет. Гибрид - требование с самых верхов.
Вы откройте вакансию менеджера по продажам чего-либо на удаленке с доходом от 150к и посмотрите, сколько вам откликнется людей.
Ничего подобного нет и не предвидится пока. По крайней мере по моим данным. Но мысль понятна. Только у ваших аргументов сильная сторона удалёнка, а наша компания такого предложить не может.
Ничего подобного нет и не предвидится пока. По крайней мере по моим данным. Но мысль понятна. Только у ваших аргументов сильная сторона удалёнка, а наша компания такого предложить не может.
Вакансия на 150k в комфортном офисе с печеньками (уж это-то у вас есть?) всё равно сильно выигрывает у кассы Пятёрочки за 50k
Спасибо за статью. Кажется вы, в отличии от "среднего по хабру", вместо охоты решили попробовать отрефакторить процесс собеседования. И сначала сложилось приятное впечатление, когда вы начали с того, что уходите от "шаблонных интервью". Но далее. Может я слишком придираюсь или что-то не вижу между строк, но статья соткана из противоречий, особенно если приложить ваши комментарии.
И у меня получается вывод, что на интервью вы будете в течении 2 часов:
Перебивать меня, чтоб "вывести из колеи"
Ловить на использовании англицизмов
Требовать "конкретики" о прошлых проектах (которые в целом чем выше грейд кандидата, тем более вероятно были под NDA)
Возможно мои ответы опубликуете на хабре со смешной картинкой (хоть и обезличенные)
И я даже не готов сказать, что это однозначно плохо. Просто маячки. И примеры глупых ответов, которые вы привели. Такие кандидаты были же и 10 лет назад, разве нет? Также были люди с 10-летним опытом условно "перекладывание джейсонов".
Табличка странная. Как может быть средний опыт 3-25. Получается 14? Средний возраст 23-60 это выходит 41.5?
Последнее. Очень сильно не согласен с тем, что "последней "линией обороны" бизнеса от немотивированных трат становится техническое интервью". Испытательный срок все-таки?
Ловить на англицизмах это вообще сюр. Вся документация на английском, термины на английском. Требовать русских аналогов для deployment или commit это какое-то особое извращение или проверка на стрессоустойчивость?)
Кто требует? Где это написано? Не надо в фарс превращать.
Если человек говорит паттерн абстрактная фабрика, то, очевидно, можно задать вопрос про 4 альтернативы. Если человек сыплет терминами, можно уточнять и проводить разговор в этом ключе. А вот если скажет англицизмы фасад и прокси, пусть продолжает и расскажет разницу. Никто не запрешает термины. Но мало их написать в резюме.
И у меня получается вывод, что на интервью вы будете в течении 2 часов:
Не совсем.
Во-первых, у людей разный темперамент. Кому-то подсказать нужно, а с кем-то - помолчать и не мешать думать. Стараюсь замечать и использовать. Соответственно, разное поведение. Ну и мне позволяет на пятой встрече не заснуть.
Во-вторых, перебивать имеет смысл, если 4 фразы подряд повторяются в пятый раз. Явно надо переворачивать пластинку. Вы перефразируете неправильный ответ 5 раз, чтоб запутать? Да, перебью значит.
В-третьих. Что значит ловить на англицизмах? Яму с кольями вырыть и растяжки установить? Если весь рассказ или ответ из нагромождения терминов и латинских букв- конечно надо уточнить. Человек или заучил термины, или американец. Разве не нужно проверять понимание используемых слов?
В четвёртых, можно рассказать о проекте без NDA, о выдуманном или пет-проекте. Вы же не думаете, что я щаставляю нарушать закон.
В пятых, в NDA прям у всех прописано, что нельзя говорить об использовании РСУБД? Вот у вас в NDA есть такой пункт? У меня нет. А у кого есть? Обычные синхроны-асинхроны обычно без NDA. Лично из моего опыта, об этих латинских буквах (возможно, без понимания смысла) говорили только трое, мы меняли тему разговора на проектирование опенсорсной платформы, например. Не было проблемой. Была проблема в том, что под видом NDA не могли написать запрос к базе, потому что в ндашном проекте тоже использовался sql. И интервью они провалили не секреткой, а неспособностью за пару часов написать пару строк.
Да, если написано в резюме сеньор, нарисовано 20 лет опыта, ответы стоят того, чтоб их цитировать - почему и нет. Приходить на собеседование на джависта и рассказывать про питон и кресты - это анекдот, достойный освещения. Может, не надо рисовать резюме и придумывать, потея, глупые отмазки?
Понял, спс за разъяснения.
Тогда у меня другой вывод. Все правила и этапы - условны. Подстраиваемся по ходу собеседования к кандидату и используем древний русский метод "жопой чую". Если красных флагов накапливается слишком много - отказ.
Я даже не критикую этот метод. Наоборот. Можно использовать другие слова, например, опыт, насмотренность, интуиция и т.п. Но по факту сводится к gut feeling.
Вожможно, что это единственный работающий метод. А все эти структурирования нужны только для докладов на конференциях и начальству.
Да, с одной стороны для отчётности чекплинты. С другой стороны умение слушать и подстраиваться. Ровно об этом статья.
Ну кстати, вот эти чекпоинты, этапы тех. интервью ещё как подскпзка о чём поговорить. Надо рассматривать человека и его опыт с разных сторон. Настройка этих этапов позволяет такое делать, немного даже автоматизировать мышление. Не надо придумывать, чтоб ещё такого спросить, омобенно если собеседникзамолкает внезапно.
Табличка странная. Как может быть средний опыт 3-25. Получается 14? Средний возраст 23-60 это выходит 41.5?
Это не строгая статистика. Может получается 14,может, 42. Что это дает? Взяли двух с пятилетним, двух с двадцатилетним опытом. Вам это о чем-то говорит? Неточный термин, хорошо. Что дальше?
Последнее. Очень сильно не согласен с тем, что "последней "линией обороны" бизнеса от немотивированных трат становится техническое интервью". Испытательный срок все-таки?
Ни разу не видел, чтоб работал. Да и сложно использовать. Написали план на исп. срок. Пришел аджайл и все перетасовал. Сделано треть задач, еще пару частично. Каждый спринт или суперспринт переписывать план? Как и кто сравнивает сложность и успешность выполнения запланированных и фактических задач? Ни разу не видел, не слышал, чтоб были такие процессы.
Исп. срок работает при водопадах, при аджайле он требует отдельно выделенного секретаря-бюрократа, процессов на уровне холдинга.
Не думаю, что я преувеличил.
Вам это о чем-то говорит? Неточный термин, хорошо. Что дальше?
Просто маячки, как я и упомянул. Вы по маячкам строите впечатление о кандидате, а я о вас.
По испытательному сроку. Мой опыт полностью противоположный. Я не готов его обобщать на всех и подчеркиваю это. Моё дело как тимлида понять: норм ли новый сотрудник или нет. И если я за 3 месяца не распознаю раздолбая тогда у вас могут возникнуть резонные вопросы о моей компетенции? И тогда ну хз, получается условные "волки" - красавцы, чё.
Распознавал, но более высокие руководители могут не принять решение о расторжении договора. Как я и писал, может быть бюрократия и желание её избежать. Не у всех тимлидов есть функция увольнения.
Да, в компаниях с раздутой бюрократией и не настроенными процессами волки могут устроиться. Я сам в сбере не мог полгода телефон получить, через который подключаться на дейли. Я работал в коллективе, где люди целыми днями писали служебки и объяснительные, без реальной работы. Еще до мейнстрима. Не работаешь - не ошибаешься - получаешь премию за работу без ошибок. Пусть в таких компаниях они и работают, подальше от меня.
Я, кстати, ничего не продаю, не собеседуюсь, чтоб рисовать какое-то впечатление о себе, я не на конкурсе джавистов года. Я поделился опытом, результатами, рассказал о процессах.
Возможно, кому-то поможет меньше сил тратить на найм персонала.
Вы усложняете задачи - они лучше зубрят. Вы даете лайв-кодинг - они натаскиваются на паттерны. В итоге страдают нормальные интроверты-разработчики, которые просто хотят писать код, а не участвовать в театральной постановке "Угадай что задумал интервьюер"
Да, меня эти тренды бесят. Поэтому я даю однострочные задачи. Люди сами усложняют.
Поэтому не требую знания англицизмов из шаблонов, а проверяю понимание. Просто общение.
Факт. Мы сейчас в найме столкнулись с тем что смена задач очень быстро палится, буквально через час после собеседования в "комнату" набегает с десяток человек чтобы скопировать код. Единственный вариант это больше времени уделять опыту.
Это очень хороший сборник кейсов, понравилось 🔥 С удивлением прочитал комментарии, даже немного удивительно, что многие не верят в реальность и распространенность проблемы с такими кандидатами. Мне каждый пример отзывался, а на моменте:
— А что она делала?
— Там была микросервисная архитектура, гейтвей, всё в кубе, сообщения отправляли по кафке.
в голос посмеялся, потому что вот только на прошлой неделе через 15 минут после начала остановили собес. Ровно такая же картина, вроде слова правильные, но сказаны бездумно и вразнобой. Кандидат отнекиваться не стал, но и согласиться духу не хватило.
Пожалуй, поделюсь с нашим кружком интервьюеров. Спасибо за материал!
Около трёх лет назад тоже столкнулся с волками, взял пару, хорошо прошли собес, потом уже мне подкинули видео про них, и я всё понял =). Одного "волка" выпилил, он вообще ничего не хотел, второго поставил на крыло - работает, сейчас уже крепкий джун. По итогу я отказался от списка вопросов и перешёл к формату беседы по резюме кандидата. В профессии давно, могу обсуждать разные темы, и это, на мой взгляд, наиболее эффективно. Спросить, а что это была за система, что делала, как делала, а какие технологии были, а как в рамках технологии делали то или иное. Если человек реально работал с чем-то, с разным уровнем, это сразу понятно. В формате беседы можно косвенно коснутся множества тем. Конечно, без раскрытия NDA.
Неплохое полотно, даже несмотря на AI generated
Лучший мой собес прошёл в два этапа.
На первом был начальник отдела, поспрашивал про опыт и всякую типичную штуку про жизнь в работе и вне еë. Мин 20.
На втором тех спец поспрашивал точечно про стек, как я его использовал. Мин 15-20.
И всё) Сказали подходишь, но на испыте длиною в месяц будет смешная зп.
Проблема была только в том, что таких как я, скорее всего, было много. Дальше наниматель уже просто каким-то образом вытянул жребий.
Не взяли. А я бы пошёл. Я уверен, что пройду испыт и готов месяц поработать за сбережения. Зато не тратить этот месяц на стресс-собесы.
2 часа опросов, допросов, лайвкодинга ну перебор же
Перебор 10 встреч по 2 часа. Я старался исключить такую необходимость. Вы же знаете, как проходит найм в зеленых и желтых банках?
От C-руководителей есть набор требований к сотруднику и интервью. За 15 минут не уложиться. Нарушать регламент тоже нельзя.
В маленьких компаниях и, иногда, в госах, такого нет. В Москве почти всегда минимум 2-3 встречи.
Мы у себя облаке ограничивались двумя: техсобес 2 часа и маленькая встреча с C-руководителем. На мой взгляд, хорошая экономия времени.
У вас наверно другой стек. У джавистов такого не встречал ни разу. Много времени сам тратил на собесы.
А когда работал дельфистом или sqlистом такой фигни не было, но, возможно, дело не в технологиях, а в том, что это было давно.
2 встречи суммой на 2.5 часа - это очень быстро. Особенно для вакансии холдинга.
Погодите, а более популярный форк от elastic search - это open search? Или какой?
Не в защиту волков, но) Сколько же проблем из-за того, что монополистом в области отбора стал ХХ. Взгляните даже на критерии в статье, идеальный кандидат: опыт 5–6 лет, возраст 25–30 лет (не хватает только пола).
Почему-то все винят волков, а страдают по итогу "нормальные разрабы". Волки - это не причина, это следствие. Следствие того, что:
в большинстве случаев HR в IT не имеют навыков и инструментов, чтобы отделить таких осознанных мошенников от честных людей.
То есть вы либо содержите, либо нанимаете людей, которые эвристически вам перекладывают резюме из одной корзины в другую. А далее автор только подтверждает, что отбор кандидатов - это считай подбрасывание монетки: сначала HR отшили всех у кого нет "экономических показателей", а потом автор из оставшихся ищет:
в резюме опыт работы подчёркивается какими-то корпоративными и экономическими показателями.
Простые же работяги понабрались этих советов от тех самых "HR без навыков оценки", чтобы их потом на тех.собесе валили)
Да, вам могут не нравится волки, но похоже рынок они начинают менять, от дуратских задач стали отказываться:
Почему не Leetcode и не «топ-300 вопросов по Java»
Но с большего, подход автора мне нравится и если собесы и дальше будут двигаться в сторону "больше говори, меньше делай", то может и закончится весь этот цирк(
del
Никогда не понимал, почему таких людей называют "волками". Волк в природе это супер профи. Команда из трех волков это отряд спецназа с четким разделением ролей. Можно глянуть видео с уличных камер на севере РФ, как два волка и волчица утаскивают огромного алабая в лес, предварительно обманув его. Я нигде такой слаженной командной работы не видел.
В комментариях под этим постом уже был ответ.
Бизнес, ничего больше. Чем красивше чушь назовут- тем дороже продадут. Их главный продажник мошеннических схем придумал. А на интервью приходят не то чтоб прям волки, а, скорее, куропатки.
Два года набирать людей в сферу которая каждые пол года меняет парадигму разработки - сильно, зато волков отсеяли, для бизнеса же важно не деливери, а что бы команда сильная была
Если почитать хоть что кроме комментариев, написано, что набор не в сферу, а в конкретный бизнес, менялась ли там парадигма вы не знаете. А если почитать еще внимательнее- там конкретный срок написан, а не 2 года. Вы точно не ошиблись статьей для такого комментария?
Для бизнеса важно учитывать то, что он сам посчитает нужным, а не то, что указывают комментаторы не прочитав и не поняв статью. Например, есть операционные и репутационные риски, SLA, доступность например, пять девяток. И бизнес минимизирует такие риски, если посчитает нужным.
Проблема не волков, а рекрутеров и тех кто проверяет резюме, чего заказывали того вам и приносят, хотели % в резюме, получите довольство клиентов 2%, какое довольство и как его добились не важно, очевидно что в резюме у нормального разработчика не будет никаких процентов, потому что их элементарно никто никогда не считает, какой бы не был продукт, акселерацией занимаются в последнюю очередь, то есть фактически никогда, обычно просто меняют старый фреймворк или непопулярную библиотеку на новые, но если у тебя нет процентов в резюме, рекрутер или его ллмка просто тебя скипнет. Людям с реальным опытом разработки и управления - вкатунов по резюме очень легко отсеять, все пункты что вы указали в нормальном резюме разработчика очень хорошо прослеживаются, докер, монолит, спринг. Если хотите спринг, то так и пишите в вакансии, что без спринга собеседований не будет, то же и с остальными технологиями, люди сто раз подумают, надо ли откликаться (хотя там на hh автоотклик сейчас, но это проблема hh). Сам спринг копнуть, да это же элементарно, даже лив-кодинг не нужен чтобы понять когда человек писал на спринге. Монолит - чем вас монолит на спринге не устраивает? Мы хотим в микросервисы, а для чего вы хотите микросервисы, чтобы просто было или может вас именно парадигма разработки интересует, с ddd, tdd, bdd, tbd? Agile? Scrum? А user-story вы там собирались рассматривать? Я думаю вы об этом даже не задумывались, иначе в статье всё это было. Пока конструктива по теме волков, даже как их правильно отсеивать я не увидел, всё что вы описали решается не на техничке, а на этапе скрининга и ознакомления с резюме. Если рекрутинговое агенство не может наладить ллм чтобы решить эти проблемы, то зачем оно вообще надо? Защищать волков мне не охота, но вот то что из за рекрутеров нормальные люди по полтора года не могут найти работу - сильно раздражает и вам даже когда сказали что в соседнем топике человек по вашему профилю работу ищет, вы сразу начали выворачиваться, мол команда уже набрана, там человек не нашего профиля, а какого не нашего я вам не скажу, с судимостью, но без судимости. В общем смешно, работодатели сговорились с рекрутерами и просто решили прогнуть рынок, нашли волков и скидывают на них всю ответственность.
В статье написаны сроки, когда я набирал. И окончание набора не 26 год. Те, кто читал всю статью, знают. Сейчас у меня другая должность. Также в статье указан грейд специалистов, там не джуны. Те, кто читали статью, знают. В статье указано, что у нас нет удалёнки, а человеку нужна удаленка.
Ни я, ни мои коллеги не требовали у hr отбирать резюме по каким-то процентам. Но такие резюме есть. Аргумент про проценты несостоятелен.
В предположительно нарисованных резюме тоже всё есть про скрам, докер и многопоточку. БЯМ по этим признакам не отфильтрует подделки. Зачастую резюме максимально похожие по оформлению бывают. Только общение вскрывает правду. И наверно не всю.
В статье нет про аджайл, проверки службой безопастностью, не рассказаны дополнительные требования холдинга. Не потому, что не знаю их, а потому что не посчитал нужным упоминать. Статья и так большая, и многим лень её прочитать дальше картинки. То аджайл требуют, то куски кода. Хороший повод заминусить. Но статья о том, о чем я хотел сообщить, а не о том, что хочется вам.
В общем сплошные фантазии, чтоб выразить свою неприязнь и самоутвердиться. Не надо так.
Вы пожалуйста по себе не судите других, сплошные фантазии, неприязнь и самоутверждение за счёт других это ваша статья. Ваши аргументы касательно моих аргументов несостоятельны, где доводы? Вы просто выдумали оценочное суждение с потолка, без каких либо фактов. Мои аргументы основанны на личном опыте периодических поисков и просмотров видео с разборами резюме, пришлось потратить время на менторов, потому что попасть на техническое интервью, с 10 годами опыта, последние несколько лет, просто невозможно. Когда за 2 месяца откликаешься на 400 вакансий и даже до скрининга добираешься дай бог в 30 из них, а техничек нет вообще ни одной, а потом слушаешь вот таких псевдоруководителей, которые рассказывают сказки про то как на рынке одни только волки и как все работяги только и ждут как налюбить бедного работодателя, становится просто смешно. Без процентов резюме разработчиков просто скипают, иначе бы их не было во всех резюме у волков и каждый ментор бы не добавлял бы их всем подряд, я себе их не ставлю, и видимо зря, потому что уже сто раз переделал резюме и последние два года ничего не меняется, для справки - я указывал только реальный опыт, но теперь рекрутеры отслеживают все версии резюме и когда я каждый раз меняю своё резюме, чтобы быть наиболее подходящим под стек который сейчас ищу, для ии автофильтров я начинаю выглядеть лжецом и накрутчиком. До 23 года у меня конверсия скринингов была 50-60% от количества откликов, тех собесов 100%, не было ни одного скрининга чтобы меня не позвали на тех интервью, то есть 100 раз откликнулся, 60 раз пообщался с рекрутером и 60 раз отсобеседовался на техничке, сейчас все рекрутеры вытирают об меня ноги, как и об других работяг, спасибо! Вы жалуетесь на волков, но в том что к вам попадают стерильные выдуманные резюме вина рекрутеров, а не волков. Про аджайл ваши комментарии просто смехотворны, "я не посчитал нужным их упоминать", вы сами даже не в курсе зачем вам аджайл и микросервисы, о ловле каких волков тут может идти речь? Вся ваша статья сплошная фикция, с приёмами от хитрых рекрутеров, которые ни в чём не разбираются и перекладывают из пустого в порожнее, нормальный лид с опытом разработки такую статью никогда бы не написал, потому что на техничке никакие методы ловли волков не нужны, всё и так можно выяснить из разговора, какой бы ты не был ментор от бога, ты никогда не научишь человека ориентироваться в предметной области по бумажке, хоть ты тресни, это мышление приходит только с опытом разработки, а вопросов которые могут поставить в тупик даже знающего человека - миллион. А если вы в конце спросите, раз рекрутеры такие говно, как тогда получать в руки нормальные резюме? Я вам отвечу - идите на хх и отсматривайте их ручками, потому что все эти нарисованные резюме видно из далека, они прям как под копирку, менторы вообще не парятся делать что то новое, у одно ментора может быть сто человек и у них у всех будет одинаковое резюме, слово в слово, только чтобы пройти атс. Как для вакансий сейчас текст генерирует ИИ, так и для резюме сейчас текст генерирует ИИ, всё это нейрослоп без полезной смысловой нагрузки и отличить резюме реального человека в этой гигантской куче дерьма интуитивно очень легко.
Почему я назвал вашу статью фантазией и фикцией, потому что пару лет назад мы в конторе искали мне напарника и при просмотре резюме (70-80 человек) была точно такая же ситуация, идентичная вашей таблице - ожидания vs реальность, один в один, мы правда не смотрели на возраст, эйджизм осуждаем, но почти ни один из них не добрался до скрининга, потому что я просматривал все их резюме ручками. Если бы я искал человека на ответственную позицию, я бы никогда не позволил прийти на собеседование человеку с сомнительным резюме. И теперь вы в статье утверждаете что сто человек псевдосеньёров смогли выдумать себе 5-6 лет релевантного опыта, возраст 25-30 лет это как раз столько, и что из СТА резюме, которые вам принесли рекрутеры, у вас ни одно не вызвало вопросов, что все кто пришли к вам на интервью оказались волками? Звучит как абсолютный бред. Волки были всегда, из тех 70~ резюме, которые мне пришлось фильтровать, два оказались хорошими, ещё 5 нормальными, остальные были доморощенные волки и просто те кто откликнулся на удачу, я смог их всех отфильтровать с первого взгляда, просто посмотрев на резюме, в итоге из 70~ откликов было только 7 собесов. Вырубите резюме по автооткликам на хх и сходите ручками посмотрите на людей, пригласите их на собеседование в офис, если так уж боитесь что за человека собес будет проходить ментор или ИИ, но вы же всего этого не сделаете, ведь проще имитировать поиски людей и жаловаться на волков.
На возраст не смотрели, это было требование не от нас. Я тоже просматривал резюме, были очень слабые. Когда удалось убрать ограничение резюме стало больше, они стали интереснее.
Нет, не все оказались, в статье иначе написано. Было много откровенно слабых, в частности не способных рассказать про аббревиатуры, насыпанные в резюме. Сразу вопросы, зачем писать в резюме того, что не знаешь.
В офис не приглашали не потому что лень было, а потому что работаем в рамках правил холдинга. Требование на онлайн/офлайн встречу выставляю не я.
Видимо руководитель проекта и главный архитектор подходят под возраст до 35 лет, и не понимают что в 50 лет можно соображать лучше и работать быстрее чем люди меньших значений особенно когда у тебя (STEM образование), но что же может случится когда самим будет за 35-40-45, поглупеете?
Для чего ярлыки попугайчики, волчата? Это ощущение мнимого превосходства как в армии? Это пагубная привычка людей описывать образами животных, исходя из оценки особенностей ожидаемого поведения. Плюс с учётом контекста статью можно было озаглавить следующим образом: " Как два барана расширяли стадо".
Оба абзаца - намеки на пересмотр фундамента мыслей и оценки, сама статья приятно читаема)
Часто корень проблемы не в самих кандидатах, а в формате интервью. Классические "top-300 вопросов" удобны интервьюеру, но по факту проверяют память и заученные паттерны, а не способность разбираться в реальных рабочих задачах.
Жёсткая воронка с live-coding и код-ревью действительно отсеивает поверхностные знания, но она тоже не панацея. Если задачи оторваны от реального стека и контекста, можно легко отфильтровать не только "волчат", но и сильных практиков, которые просто не поняли, что от них хотят.
Лучше всего вскрывает уровень не сама задача, а момент, когда кандидат объясняет, почему он принял именно такое решение. Тут шаблоны быстро заканчиваются, а мышление становится видно сразу.
Почти полностью согласен. Именно в этом я видел свою задачу: шаблонность повернуть в сторону человекоориентированности и ориентированности на цели конкретной команды.
Live coding максимально, насколько возможно в жёстких рамках интервью, ушел дальше от академических абстракций и литкода, упрощён настолько, чтоб можно было обсудить алгоритмы и посмотреть мышление кандидата. И это матчится с реальной имплементацией спроектированных интерфейсов. И это может требовать абстрактного мышления, ровно как и понимание системных подходов.
Ревью кода - отдельная тема. Скажу только, код не оторван от реальности, но учитывает NDA.
Читаю такие статьи, и странное чувство возникает - по описанным критериям я волк: я не расскажу в деталях, как работает JVM, так как в работе мне это не нужно. Про сборщик мусора могу только предполагать, что он освобождает память при выходе из скоупа. Про kafka в деталях не расскажу, т.к. она используется, и я просто дорабатывал немного консьюмеров и продьюсеров в коде, а когда настраивал - сделал это один раз под задачу, и сейчас повторно в этом надо будет разбираться заново. group by в SQL по памяти не напишу, хотя знаю, что это, просто от силы за всё время работы такое требовалось раз 5. Задачу на кодинг без подсказок IDE в блокноте под стрессом решу не идеально. Так что по всем критериям я волк.
Но в то же время у меня 18 лет опыта, честное универское образование. Во всех фирмах, где я работал и работаю нет никаких нареканий, успешно проходил испытательные сроки, вывозил самые сложные задачи.
Вот я и не могу понять, то ли со мной что-то не так, то ли с системой оценки кандидатов.
А в резюме в навыках вы укажете "знание SQL и Kafka"? Одна из претензий к "волкам" в том, что у них в резюме указаны навыки, которыми они не владеют. Когда у человека в резюме написано "хирург", а по факту от только карандаши скальпелем точил, это несколько разочаровывает.
Однажды мне предстояло разрабатывать Android-приложение на Kotlin, да к тому же руководить командой. С Kotlin и в целом с Android у нас опыта не было, следовательно в резюме бы я эти навыки написать не смог, и формально на позицию не подходил. Тем не менее приложение с ML под капотом мы успешно запилили и вывели на рынок. Такой вот парадокс.
И что указывать в резюме? Только сильные навыки? Я 12 лет писал на плюсах, но после 4-летнего перерыва забыл, как класс объявить. Так мне и плюсы тогда не указывать? Потом за 5 минут контекст погрузил, вспомнил и написал.
Так что сложный вопрос, как нанимать. Я убеждён, что человека надо смотреть в деле. Но с другой стороны, когда сотни откликов, всех на испытательный срок не примешь. Пока склоняюсь к тому, что связи и рекомендации будут иметь роль при поиске сотрудников/работы.
Да, всё так. Об этом статья. И хирурга от повара можно отличить в разговоре, даже если у обоих владение ножом в резюме.
Есть ещё такое когнитивное искажение: когда ты сам подготовил вопросы и знаешь на них правильные ответы, то кажешься себе умным, а те, кто ответов не знают - глупые. Замечал это, когда принимал экзамены в университете и искренне не понимал, как можно не знать ответов на такие очевидные (для меня) вопросы.
Это я к тому, что если на собеседовании кандидат не знает ответов на ВАШИ вопросы, это ещё не означает, что он не компетентен.
А если не знает ответ даже после 6 подсказок? А если вместо вопроса дать два других, и тоже с подсказками - они могут указать на незнание?
Мне кажется, система вопросов на экзамене другая. Не ответил- сразу минус, и по 6 подсказок не дают.
Я не утверждал, что неправильный ответ на вопрос это провал собеседования. Наоборот, я несколько раз писал, что вопросы переформулирую, подсказываю сначала экивоками, потом более явно. Я также писал, что решение об аппруве принимается комплексно на основе всех секций. Я писал, что нерешенная задача может быть поводом дать другую задачу, и все они однострочные.
На экзамене разве такой же подход?
На экзамене задача тоже решается в одну строку?
Мне кажется, сравнение некорректно.
Проблема то возникла из-за отсутствии вакансии на джунов, которые самыми первыми попали на утиль...
В целом всегда относился к ним нейтрально. Неспособные люди никогда не пройдут дальше испытательного срока. И нужно решать корень проблемы, а не ее последствия.
Меня больше в нынешнем найме тригеррит фильтры по возрасту, полу, и т.д, которые якобы незаконные, но представленны прямо в самих этих сайтах:)
Добрый день! Деятельность "волков" не одобряю, их секту не рекламирую. Я сам не из мира программирования, поэтому ситуация находится немного в стороне от вас. Вы говорите, что бизнесу стало тяжело найти квалифицированных специалистов.
Со стороны знакомых программистов я слышал три тезиса:
HR'ы перекручивают опыт так, что по факту бизнесу требуется всего-лишь жарить яичницу за зарплату, конечно, квалифицированного повара но при этом формально требуются скиллы шеф-повара ресторана Мишлен. Правда ли это? И почему бизнес в таком случае позволяет выкручивать тестикулы потенциальным сотрудникам а потом недоволен что не хватает кадров?
Галеры занимаются тем же самым волчарством, продавая своих сотрудников под видами сеньоров. Это так?
Я слышал, что воронки от HR лютая вещь сама по себе: где автофильтры и ИИ подобно сцене из "Волк с Уолл-Стрит" выкидывают 90% "неудачников". Это правда?
На мой взгляд, правдоподобный ответ на ваш вопрос дан в этом комментарии. Если кратко - инфляция опыта обусловлена реакцией рынка на накручивание опыта.
Это так. Лично видел продажу джунов в качестве мидлов и даже едва-мидлов в качестве крепких сеньоров, причём видел с обеих сторон процесса. И с последствиями таких махинаций сталкиваться тоже приходилось, к несчастью.
К сожалению, тоже встречается. Частоту явления объективно оценить не могу, но кажется, что большинство рекрутеров кропотливым отбором не занимаются.
Гелеры немного потопли за последние пару лет.
Бизнес зачастую хочет универсального бойца переключать между проектами. Будет ли-вопрос другой. Но требования могут выставляться.
Не знаю. У нас воронка у HR не такая жёсткая, насколько известно. Наличие В. О., прописки в Мск и по мелочам. На некоторые вакансии нижний порог по суммарному опыту.
"не хочу давать никому шанс и обучать, мне нужны только крепкие, сильные и идеальные, все вкатуны - лесом, все мечтатели - лесом, я помидор и таким буду, а платить буду как джуну"...
Да пошёл ты н*****
Обычно если мне в джиу-джицу попадаются такие люди, не зависимо от специальности, я точно так же рвзмазываю из мечты о спорте.))
З.ы.: К хорошим людям у меня вообще индивидуальный подход, люблю и пылинки сдуваю.
Волки не пройдут