Нужно ли говорить на интервью, что ты уже решал эту задачу?

Допустим, на техническом интервью тебе дают знакомую задачу. Ты помнишь идею или даже готовое оптимальное решение. Стоит ли сразу сообщить об этом интервьюеру? 🤔

Я знаю людей, которые признавались. Иногда им оставляли ту же задачу, потому что интервьюеру было важно, как кандидат сможет объяснить решение - был важен ход мыслей. А иногда задачу сразу меняли - и новую кандидат либо решал успешно, либо не решал, и приходилось ждать cool-down-период 🧊, обычно длиною в год, чтобы попробовать свои силы ещё раз.

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

На интервью в Uber 🚘 мне однажды попалась задача, которую я действительно решал раньше. Я не стал об этом говорить: именно ради такой форы я и готовился. Однако, я знаю много людей, кто считает это нечестным и 100% признались бы, что решали задачу ранее.

Насчёт собеседований в Meta 🥸 я вообще молчу - если прорешать топ-50 вопросов, которые спрашивали за последний месяц, то вероятность, что попадётся знакомая задача, очень высокая. У меня, например, из 6️⃣ задач (по две задачи на интервью) попалось 5️⃣ из этого списка. 😕

Вернёмся к варианту, в котором ты не признаешься, что уже решал(а) эту задачу, несмотря на то что ты знаешь её решение. 🧠

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

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

А как правильнее поступать: честно признаться и рискнуть получить новую задачу или использовать результат своей подготовки - вечный вопрос, и каждый поступает так, как считает правильным.

Этично ли записывать собеседование, просто поставив кандидата перед фактом?

Не так давно у меня был звонок с рекрутером одной знаменитой российской компании. 🙄

Как только я зашел на звонок, сразу услышал автоматическое уведомление о том, что разговор записывается. И самое интересное, что мне не объяснили, зачем она нужна, кто потом сможет ее посмотреть и сколько вообще она будет храниться. Просто: This meeting is being recorded.

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

То есть, вопрос скорее не в том, нажал ли рекрутер кнопку записи, а в другом: зачем компании вообще нужна полная запись интервью?

Допустим, чтобы другой интервьюер мог пересмотреть разговор.

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

Потому что фразы: "мы вас уведомили" и "вы согласились" все-таки немного отличаются друг от друга.

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

Кстати, самое забавное было еще до этого звонка.

Я спросил рекрутера: "нужно ли мне прислать вам свое резюме❓"
На что получил ответ: "нет, у нас ваше резюме уже есть в базе 😅"

И тут появляется сразу следующий вопрос: А откуда оно там? Какая его версия? Сколько лет оно хранится? И что еще кроме резюме находится в этой базе?

В общем, чем больше думаю об этом, тем меньше меня волнует непосредственно кнопка записи. 🤦‍♂️

Гораздо интереснее другое: сколько наших данных хранится внутри компаний и зачем?

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

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

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

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

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

Ведь это прям прямая аналогия с дедовщиной в армиях, 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 - значительно более широкий рынок с большим количеством вакансий.

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