Дедовщина на собеседованиях 🤔

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

Ты всё это каким-то образом проходишь и устраиваешься в компанию. 😎

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

И ты начинаешь задалбливать следующих кандидатов примерно так же, как когда-то задалбливали тебя. 🤦‍♂️

Ведь это прям прямая аналогия с дедовщиной в армиях, innit?
Человек, который сам прошёл через унижения, тупые задачи, устои и правила, со временем может начать воспринимать их как нормальную часть системы:
• «Все через это проходили»;
• «Меня это сделало сильнее»;
• «Я выдержал - значит, и ты должен».

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

Выглядит будто с собеседованиями происходит что-то похожее.

Причём проблема даже не обязательно в желании самоутвердиться. Люди могут искренне считать процесс правильным именно потому, что сами когда-то его прошли.

Если я смог пройти - значит, хороший инженер тоже должен.

Хотя на самом деле это доказывает только одно: инженер научился проходить такой формат интервью.

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

И вот тут, я считаю, хороший интервьюер отличается от инженера.
Его задача - не придумать интервью, которое сложно пройти. Его задача - за 45–60 минут получить как можно больше полезного сигнала о кандидате и принять максимально адекватное решение. Это далеко не одно и то же.

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

Также тебе могут говорить, что, прежде чем начать нормально зарабатывать, нужно выстрадать, прочитать N-ное количество книг и бесплатно поработать «ради опыта».

Ведь они так прошли свой путь, а значит, и ты обязан(а) его выстрадать.

Никогда такого не было, и вот опять 🤦‍♂️

Собеседования собеседованиями, но давай немного отвлечемся и посмотрим на моего псыну 🐕😜

Твоё интервью может пойти не по плану 🤔

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

Разговор у нас был получился довольно странный.

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

Окей, следующий вопрос, подумал я.

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

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

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

Считаю, что хороший интервьюер иногда должен уметь просто помолчать и дать кандидату подумать.
Пусть он(а) ошибётся. Посмотреть, заметит ли он(а) ошибку сам. Если не заметит - дать небольшую подсказку и посмотреть, что он(а) с ней сделает.

Мораль сей басни такова 🧐:
Даже если ты готов(а) на 100%, это ещё не значит, что интервью будет пройдено. Поэтому при поиске работы «не класть все яйца в одну корзину» или, если переформулировать, не подаваться только в одну компанию - единственно верная тактика.

Да и стресса будет меньше, если знаешь, что попыток может быть несколько.

Чем отличается Middle, Senior и Staff на примере Google?

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

Возьмём для примера 🔠0️⃣0️⃣🔠🔠🔠.

🔤4️⃣ a.k.a. Middle Software Engineer

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

Это видно и по интервью: основной упор на миддла идёт на алгоритмы + поведенческое, а отдельного полноценного дизайна систем обычно вообще нет. Скажу сразу, это только у Google нет дизайна систем на миддла, в остальных компаниях он всё же есть, но требования не слишком жёсткие ☕️.

🔤5️⃣ a.k.a. Senior Software Engineer

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

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

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

🔤6️⃣ a.k.a. Staff Software Engineer

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

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

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

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

Из этого следует:

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

Java умерла, учим Go?

Довольно часто натыкаюсь на мнение, что сейчас надо срочно учить Go - мол, зарплаты выше, возможностей больше, а Java потихоньку умирает. У меня в резюме есть оба языка, поэтому я решил проверить это на цифрах. Посмотрел на рынки Великобритании 🇬🇧, Польши 🇵🇱, США 🇺🇸, России 🇷🇺 и Казахстана 🇰🇿.

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

🇬🇧 Великобритания

Вакансии взяты с IT Jobs Watch за 6 месяцев до 24 сентября 2026 года:

• Java - 3 049 объявлений.
• Go - 486.

Java упоминается примерно в 6 раз чаще. Медиана указанной годовой зарплаты - £70 000 у Java против £80 000 у Go, то есть разница около 14%.
Но устойчивого наступления Go не видно: по сравнению с аналогичным периодом 2025 года Go-объявлений стало почти вдвое меньше 🔽, а Java - примерно на 2,5% меньше.

Источники:
• Java
• Go

🇵🇱 Польша

На Just Join IT за 2025 год Java-вакансий примерно в 7,5 раза больше. А вот с зарплатами интереснее - средние значения по зарплате:

• Java - 15 950 PLN в месяц.
• Go - 22 250 PLN тоже в месяц.

То есть Go-разработчик получает почти на 40% больше.
Но если сравнить Senior Java с Senior Go, получаем 23 250 против 25 000 PLN до налогов. Это уже +7,5%. Для Senior на B2B разница составляет +5,4%.

Источники:
• Количество и доли вакансий
• Зарплаты по категориям и грейдам
• Методология

🇺🇸 США

На O*NET / Lightcast взяты объявления за 2025 год:

• Java упоминается в 25%.
• Go - в 5%.

То есть Java встречается примерно в пять раз чаще.

А на DevITJobs взята медиана для Senior:

• Java - $122 700 в год.
• Go - $156 200 в год.

Здесь разница уже +27%, даже внутри одного грейда.

Источники:
• O*NET / Lightcast
• DevITJobs - Senior Java
• DevITJobs - Senior Go

🇷🇺 Россия

Медианные зарплаты по Хабр Карьере (в рублях):
• 2023 - 230 000 (Java) / 271 000 (Go).
• 2024 - 258 000 (Java) / 300 000 (Go).
• 2025 - 270 000 (Java) / 320 000 (Go).
• 2026 - 279 000 (Java) / 325 000 (Go).

В этих срезах Go выше на 16–19%, но разрыв не увеличивается год за годом.

Источник: Хабр Карьера
• Второе полугодие 2023 года
• Второе полугодие 2024 года
• Второе полугодие 2025 года
• Первое полугодие 2026 года

🇰🇿 Казахстан

Для Казахстана я не нашёл никаких опросов, кроме опроса Kolesa Group среди backend-разработчиков. В нём:

• 2024: Java - 28%, Go - 33%.
• 2025: Java - 24%, Go - 32%.

Go здесь встречается чаще, но использование языка ≠ количество вакансий. Это опросы, а не статистика найма.

Источники: Kolesa Group
• Исследование за 2024 год
• Исследование за 2025 год
• График с долями языков за 2024 год

Что в итоге?

Выглядит так, что «Go хорошо оплачивается» и «Java умирает» - два разных утверждения.

По Великобритании 🇬🇧, Польше 🇵🇱 и США 🇺🇸 Java встречается в вакансиях примерно в 5-7,5 раза чаще. То есть по количеству возможностей рынок Java всё ещё заметно больше.
При этом Go действительно часто показывает более высокие зарплаты. Но когда начинаешь сравнивать разработчиков одного уровня, разница может заметно сокращаться.
Поэтому я бы не делал из этих цифр вывод, что надо бросать Java и срочно переучиваться на Go. Скорее вывод другой: Go - более нишевый рынок, который может хорошо платить, а Java - значительно более широкий рынок с большим количеством вакансий.

Что думаешь по этому поводу?

Performance review, она же оценка эффективности сотрудника, в компании типа Google

Немного контекста вначале:

Если ты еще не работал(а) в большой корпорации, то, возможно, performance review было только где-то на слуху. В компаниях поменьше этот процесс часто устроен проще: ты выполняешь свои обязанности, а потом в какой-то момент приходишь к менеджеру и говоришь, что стал(а) сильнее как специалист и хотел(а) бы получить больше ответственности, новый проект, стажеров в команду и, конечно же, повышение зарплаты 🤑.

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

Во время performance review ты получаешь оценку своей работы по определенной системе:

1️⃣Ниже ожиданий
2️⃣Оправдал ожидания
3️⃣Превзошел ожидания

Performance review также может влиять на твою компенсацию: базовую зарплату, годовой бонус и акции. Повышение зарплаты каждый год, конечно же, в контракте не прописано, но все надеются на лучшее 😂.

Немного про акции:

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

Получается что-то вроде скользящего окна: сначала у тебя есть акции на четыре года вперед → проходит год → часть акций становится твоей → тебе могут выдать новый пакет → и снова появляется новая порция акций.

Важно понимать, что это не гарантировано. Размер нового пакета зависит от компании, твоего performance, уровня и, возможно, силы земли 🥒.

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

Вернемся к самому ревью:

Допустим, ты Senior Software Engineer 😨.

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

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

Когда подходит формальный review:

1️⃣Ты заполняешь self-review, он же самоотчет эффективности.

Здесь ты подробно расписываешь, что сделал(а), над чем работаешь и что стоит исправить или улучшить.

2️⃣Дальше в игру вступает peer feedback, он же оценка тебя коллегами.

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

3️⃣После этого менеджер формирует свою оценку.

Она основывается не только на self-review и peer feedback, но и на собственных наблюдениях менеджера за твоей работой в течение года. В теории self-review, отзывы от коллег и оценка менеджера должны складываться в одну объемную картину, которая не противоречит сама себе. После этого может проходить отдельный этап - calibration. Менеджеры и руководители обсуждают оценки сотрудников, чтобы привести их к более единому стандарту и сопоставить результаты людей одного уровня.

После ревью:

В итоге ты получаешь рейтинг, который может повлиять на деньги, которые ты получишь.
А дальше цикл повторяется: новые проекты → новый feedback → новый self-review → новая оценка → новая компенсация.

То есть performance review - это формализованный процесс, который связывает между собой твою производительность, твой карьерный прогресс и твою компенсацию.

Также, ходят мнения, что performance review сделан, чтобы ты не ходил(а) каждые три месяца к менеджеру за повышением зарплаты 🤣.