Полчаса назад закончилось очередное первичное собеседование, на котором HR задавал странные вопросы: работали ли вы с Kubernetes, работали ли вы с Postgres, работали ли вы с Redis и тому подобное. На собеседованиях я всегда отвечаю честно: с Postgres и SQL работал достаточно плотно, а Redis и Kubernetes знаю лишь теоретически — понимание есть, пару раз пробовал в песочнице, но полноценного опыта нет. В целом, мне кажется, что на определённом уровне для разработчика уже не существует «сложного нового инструмента»: вопрос лишь в глубине понимания, которая пропорциональна времени, проведённому с ним.
Почему эти вопросы кажутся странными? Потому что непонятно, чего именно хочет HR. Уточнить уровень грейда? Он вряд ли поймёт это, ведь сам не разработчик. В итоге, чтобы пройти первый этап, нужно отвечать на всё «Да». Разберёмся что это значит:
Вы имеете большой опыт работы с ЯП, с основными его инструментами, разбираетесь в кэшировании, экспертно владеете SQL но не имеете опыта с Redis? Не проходите, т. к. разобраться с key-value RAM инструментом это, видимо, очень сложно для разработчика.
Или например вы знаете докер от начала до конца, создаёте контейнеры, docker-compose, возможно работали ещё с какими-либо системами контейнеризации/виртуализации, но так получилось, что не работали с Kubernetes. Тоже не проходите.
И более того, HR даже не понимает, что в его суждениях не так, он просто следует инструкции «Надо чтобы умел редис, кубер, постгрес». Можно предположить что будет, если бы назначили 2 этап собеседования с разработчиками, повезёт, чтобы попались толковые ребята, но часто бывает, что тебя собеседует старший разработчик, который и сам не очень компетентен. А бывает и такое, что в ходе разговора со «старшим программистом» над теоретической задачей ты предлагаешь объективно наиболее лучшее решение, а собеседник отказывается слышать о таком, потому что это не соответствует тому как его учили, не по канону это.
Был у меня аутсорс проект, на котором заказчик что‑то хотел сделать, ПМ и аналитик изложили всё совершенно по другому, понадобилось ещё 2 недели разбора, созвона, чтобы понять, что в итоге хотели делать то? На одном из созвонов пришлось ставить ультиматум: либо делаем всё нормально, либо не делаем совсем, на что ПМ в открытую высказал: да тебе не пофиг ли что делаем, давай, мол закроем задачу, а там дальше пусть сами разбираются. Можно закрывать глаза на это, если бы хоть минимально работающий продукт был, но там вообще ничего не работало.
Ну то есть безумие ситуации: Работник уговаривает надзирающего делать работу нормально, хотя наоборот должно быть. И с подобным я сталкивался, когда работал в большой компании, ПМ брал проект, забивал на него месяца на 3, то есть даже не знаешь, что какая‑то работа должна вестись по проекту. И спустя 3 месяца тебе предъявляют, почему ничего не сделано по проекту, и мол ты виноват.
Настолько всё стало абсурдом в IT‑трудоустройстве, наплыв непонятных людей, которые вообще к техническим специальностям отношения никакого не имеют. Вбухали денег в IT, так оно ведь лучше не стало, а наоборот.
Комментарии (23)
AdrianoVisoccini
12.11.2025 13:33Если честно, складывается ощущение, что вы просто не умеете вести переговоры, без обид
Выше описаны три ситуации - HR, пм+заказчик, пм. Во всех трех ситуациях нужно было просто говорить людям то, что они хотели услышать
зачем говорить HR что-то другое, если вы знаете что надо было сказать?
зачем ставить ультиматумы клиенту? Если стороны не смогли прийти к консенсусу это провал переговоров
с ПМом сложнее определить но если с вас спрашивают работу за 3 месяца а она не делалась то проблема в процессах и возможно вашем участии в них?
нет, это не виктим блейминг
ssw733 Автор
12.11.2025 13:33Наверное вы правы, с hr надо говорить то, что он хочет услышать, так и буду делать на последующих собеседованиях
С ПМ описаны краевые случаи, в которых компромиссов не удается найти
bighorik
12.11.2025 13:33По собесам поддерживаю - с такой ерундой на каждом втором собесе сталкиваться приходится. С тем же успехом могли бы гугл-опросник скидывать , где нужно везде "да" проставить
SolidSnack
12.11.2025 13:33Во всем поддерживаю автора! Надоели эти фильтры hr (бесполезные, о как неожиданно) и фейковые сеньеры, которые насидели свои должности, а по факту знаний как будто и не хватает, объективно
class_silver
12.11.2025 13:33Согласен, надоели. Но просто не надо в такие компании устраиваться. Собеседование не только для соискателя, но и для работодателя тоже. Кажется, все об этом забыли
SolidSnack
12.11.2025 13:33А другие это какие? Спросите на собеседовании кем они видят вас (программиста) через 3 года и инвестиций 3-4 миллиона в год (зп плюс налоги, на вскидку)
class_silver
12.11.2025 13:33В те, в который собесы проводит фейковый синьер. А для hr можно придумать список неудобных вопросов. Пусть тоже подумает немного. Я, например, часто спрашивал нужен ли команде вообще руководитель, на должность которого Вы меня собеседуете. Ну или такой - а кто раньше работал на этой должности, почему ушел? Давно уже не был на собесах, поэтому над развитием списка неудобных вопросов давно не работал
SolidSnack
12.11.2025 13:33А вы по названию компании определяете что сеньор фейковый или как? Никто вообще не говорил про трудоустройство, а только про собесы. Внутрении проблемы компании тоже заранее надо предвидеть?
posledam
12.11.2025 13:33HR задаёт вопросы, которые ему дали от команды разработки, куда ищут кандидата. Это простой фильтр на уровне анкеты, чтобы сузить поиск. Может оказаться и так, что тот же Redis в проекте используется не просто как примитивное Key-Value хранилище, а под высокими нагрузками, и надо иметь большой опыт работы с ним. Нюансов там хватает с головой. А может и достаточно будет понимания что это и для чего.
Не понимаю претензий к HR, вряд ли каждый разработчик согласится выполнять в полный рост работу HR, созваниваясь с десятками кандидатов фулл тайм. А если сотрудник HR будет разбираться в разработке на уровне мидла, зачем бы ему тогда работать HR-ом? У меня тоже есть претензии к качеству поиска, но идей, как это пофиксить тоже нет.
Насчёт претензий к заказчику тоже странная история. Кто платит, тот и заказывает музыку. Прекрасно понимаю стремление делать хорошо, качественно, правильно. Но если ваше видение усилий, которые нужно приложить на результат, категорически не сходится с видением заказчика, может вам не по пути? К чему ставить какие-то ультиматумы? Поверьте, есть множество историй, где тяп-ляп и в продакшен позволило выйти на рынок раньше остальных, тем самым сорвать куш. Может это тот случай, ну или заказчик в это свято верит.
ssw733 Автор
12.11.2025 13:33Вы абсолютно правы, претензия к HR лишь одна, что он не видит за внешним внутреннее. На собеседовании должен опытный разработчик в обязательном порядке. Другой вопрос, что наплыв кадров очень большой, и нужно какое-то первичное отсеивание, но вот таким методом как сейчас, ничего не работает
ED-209
12.11.2025 13:33Ну то есть безумие ситуации: Работник уговаривает надзирающего делать работу нормально, хотя наоборот должно быть.
Буквально сегодня такое словил.
Надзирающая сторона говорит: "Есть задача XYZ. Нужно сделать быстро." В задаче, в которой какого-то понимания с надзирающей стороны не было вообще.
Говорю: "Задачу XYZ быстро и, одновременно, нормально сделать нельзя. Могу сделать либо как правильно, либо никак.
Заработал дизлайк сразу, моментально :)
kalombo
12.11.2025 13:33Ну это с опытом придет и к вам и к автору - слышать, что вас просят.
Представьте, что вы наняли отделочника, обои поклеить по-быстрому, пусть чуть кривовато и чуть внахлёст на неровные стены. Вы с ними планируете полгодика пожить, если вам понравится, вы уже основательный ремонт сделаете потом с этими обоями. А отделчоник давай говорить, да вы неправильно живёте, да надо по технологии, всю мебель из квартиры вывезти, да на пару миллионов стены выровнять, да двери поменять, да пологода делать, а потом уже обои.
ssw733 Автор
12.11.2025 13:33Понимаю о чём говорите, думаю это не совсем та ситуация, ну лично у меня. Чрезмерно усложнять, если можно делать проще не нужно, но и делать абсолютно "фасад без начинки", что не будет абсолютно ничего работать тоже нельзя
SolidSnack
12.11.2025 13:33Иногда если тупо следовать тому что хочет заказчик может получится то чем он сам же не будет пользоваться (видел и такое)
Может технический специалист от части и нужен чтобы желания накладывать на тех ограничения? Подрегулировать желания под техническую реальность))
Такое ощущение если честно что программисты воспринимаются как-то не правильно, какие-то злодеи, делать как хочет человек (даже если это нереально) не хочет...Про какую-то архитектуру говорит...Когда уже всем начнут платить за количество кода, а не почасовую (Если что это реальная мечта некоторых глав ИТ отделов, которые я слышал сам лично...)
ssw733 Автор
12.11.2025 13:33Руководить разработчиками должен только разработчик)) Есть желание уйти из IT уже, пока совсем мозги не сварилсь, только куда не понятно
SolidSnack
12.11.2025 13:33Я вижу выход - работать на себя, развивать свое ИТ без сотни фреймворков и микросервисов, с хорошей архитектурой и предсказуемой разработкой. Нужно делать из ИТ конфетку, а не кусок...микросервиса...
А так я с вами солидарен, я понял что найм это вообще мимо меня всё, тоже уже думал сменить профессию, но уже слишком много времени отдано, да и как никрути нравится это дело)
ED-209
12.11.2025 13:33Руководить разработчиками должен только разработчик))
В идеальном мире, да.
Но, при этом, совсем не каждый разработчик хочет быть тимлид. Чем выше квалификация сотрудника именно как разработчика, тем ровно пропорционально меньше он подходит на роль TeamLead. Чаще происходит по-другому, переход идет либо по принудиловке ибо сказано/велено или же надо хоть как-то расти (супруга наседает, давай там это, пора уже быть начальником или кем там, короче в пиджаке и галстуке, чтоб нас на районе знали).
ssw733 Автор
12.11.2025 13:33Наверное потому что чем выше квалификация, тем чувствительнее сенсоры к людской тупости, и тем больнее плавать среди комерсов
ED-209
12.11.2025 13:33Это называется Agile Vs Waterfall.
По Agile, почему-то, что ни каждая вторая заметка или статья, так в комментариях постоянно лютый бешеный гнев, ненависть, спор и срач, а по классике берем методологию Waterfall - внезапно все отлично здорово и хорошо, люди улыбаются, машут друг другу руками, солнце лучиками светит, трава зеленая растёт.
Почему так? Agile же, очевидно, супер круто, здорово и быстро, а Waterfall логично медленно.
ssw733 Автор
12.11.2025 13:33Это ведь не от того что лично ты вредный какой-то, а действительно других путей решения нет. Мне думается проблема часто возникает между "не технарь" ПМ и "технарь" разработчик.
ED-209
12.11.2025 13:33Проблема, более чем часто возникает на стыке Продажники vs Технари. Первые пообещали и продали клиенту фичу A, B и C и оная точно будет готова к сентябрю, заключили железобетонный контракт, конечно же со штрафами, ежели не. А технарей, исполнителей, в лучшем случае, уведомили об этом в начале августа: "Вы уж там поднапрягитесь, сделайте, клиент как бы уже типа ждёт, замазано, ударили по рукам. Не подведите. Иначе прилетит всем, мы же пообещали, кровью договор подписали, вот сами смотрите. Ни разу ни врём, клиент денег заплатил, реально ждут к сентябрю".
Что самое любопытное, основные стейкхолдеры бизнеса обо всем этом ни сном, ни духом. Ну продукт продается, денежка капает, прибыль идёт. Все ребята, вся наша команда, абсолютно все молодцы! За здравие!
А по факту, продажники купаются в лаврах с закрытыми и сверх прибыльными овертаймами KPI (смог продать фичу клиенту в воскресенье, под кофе в стар бакс, учтите) и получают бешеные премии, а у разрабов пригорает каждый день. Сегодня кидаемся пилить фичу один, завтра же срочно переобуваемся и пилим фичу два.
ssw733 Автор
12.11.2025 13:33Всё так, и это очень большая проблема, которая своими последствиями выходит далеко за рамки работы. Да и сама проблема далеко не новая, все ведь давно всё понимают. Безумие позднего капитализма
filippov70
Сейчас надо искать работу через людей