Помните раньше была такая штука как собеседование по теории? Когда просто задают вопросы а-ля “как работает хеш таблица” или “а что там происходит при коллизиях”? Так вот, оказывается, такое и сейчас есть.
Вообще, тема собеседований мне весьма не чужда, я даже когда-то готовил людей к прохождению этих самых собеседований, причем весьма успешно. Так вот, формат таких теоретических собеседований мне никогда не нравился. А теперь, в эпоху AI он и вовсе потерял какой бы то ни было смысл. Почему? Потому, что кандидату, в целом, ничего не стоит посадить рядом с собой какую-нибудь нейронку на церебрас + live модельку, которая будет слушать и выпуливать ответы даже на самые сложные вопросы быстрее, чем интервьюер закончит задавать вопрос. Более того, такие персональные агенты-помощники вот-вот вообще станут нормой (это если вдруг вы до сих пор относитесь к такому как к читерству). Собсна, при должной сноровке не сложно запромптить агента так, чтобы он вылавливал всевозможные уловки (а-ля чего это вы мне в третий раз одно и то же спрашиваете разными словами) и вообще вел себя как живой.
Но как тогда? Есть радикальное мнение, что испытательный срок - это лучшее “собеседование”, причем не 3-месячный, а куда более быстрый (сейчас с агентами, в принципе, за неделю-две уже можно делать выводы об адекватности кандидата). Ну ок, каждого же не будешь брать на платную испыталку - согласен. Что тогда? Мне очень нравятся два формата на собесах:
Обсуждение опыта: задач, которые кандидат решал ранее и особо запоминающихся проблем/граблей, которые возникали на этом пути (ок, такое и с нейронкой можно провернуть, но явно будет сильно сложнее сделать это органично).
И второй формат: вот удивитесь, но это лайв код ревью*. И это как раз тот формат, который не просто позволяет проверить знание той самой теории, но и понимание этой теории на практике. Ну, например, есть у вас тот самый блок вопросов про хеш-таблицы/dict (допустим, вы считаете понимание его строения важным), напишите в коде кейс с коллизией или кейс с overridden
GetHashCode() => 0и спрашивайте, что там в представленной портянке на 100 строк не так (спойлер: там все не так). Ну, или у вас есть странный вопрос про отличиеThreadотTask- ну, бахните в кодеThread.Startс каким-нибудьasync voidиawait’ом внутри и смотрите что на это кандидат скажет, ну и так далее. А если на ваш теоретический вопрос не получается придумать практический кейс тогда это хороший повод задуматься о целесообразности такого вопроса. Еще, раньше подобные примеры портянок было не просто придумывать и я на РФ рынке встречал всего пару компаний, которые такие штуки делали. Сейчас же, как вы понимаете, такие задачки очень здорово можно нагенерить вместе с нейронкой - берете этот пост, описание вашей вакансии, описание компании и отправляете это все гпт 6 про с просьбой сгенерить такую портянку на часовое интервью. Ну ок, вы мне скажете, что мешает (сильной) нейронке поревьюить код и найти в нем все проблемы? То, что в любом ревью важен контекст, а контекст надо догадаться сначала уточнить и в зависимости от контекста важность той или иной проблемы будет отличаться (мы же помним как хорошо нейронки могут бесконечно находить проблемы). Проблемный код в этом случае выдается кандидату всей портянкой и в нем может быть как много проблем, так и наоборот практически не быть. Здесь еще важно отметить сам процесс - кандидат сразу побежал ошибки искать или сначала попытался понять а что вообще происходит и для чего. Ну и в целом, идеально когда вайб-кандидат не готов к такому формату и тогда его (обычно простой) live-агент просто будет хвататься за первую попавшуюся на экране проблему не вдаваясь особо в контекст и в ее важность. Короче, в таком сетапе обмануть систему становится сильно сложнее.
* Речь, конечно, идет о кейсах, когда по классике нанимают конкретного специалиста на конкретный стэк, а не агентного инженера-агностика.
А как у вас в компании поменялась механика собеседований? И спрашиваете ли еще в принципе про условное устройство хеш-таблиц или у вас уже AI-native полным ходом и все подкапотные детали - это что-то из разряда знаний ассемблера?)
Больше и чаще пощу в своем тг-канале AI-Driven Development.
Комментарии (12)
stiz
07.10.2026 03:00Лучший способ - это пригласить в офис и посадить за комп. Да, будет некоторое волнение и дискомфорт, но тут всё зависит от интервьюера и его умения расположить собеседника к себе.
Borelli
07.10.2026 03:00Шта?! Берите двойной листочек и ручку, сейчас напишем контрольную по коду. Всё происходит в комнате где стол, два стула и из электрического - выключатель на стене для света)
eximus
07.10.2026 03:00<sarcasm_on>
Всё происходит в комнате где стол, два стула и из электрического - выключатель на стене для света)
Воу, воу, воу, полегче! А то пойдёт электрификация
по плану ГОЭЛРОвсего в комнате и сначала один, а потом и оба стула станут... электрическими?<sarcasm_off>
dvvarna
07.10.2026 03:00Именно так, на некоторых собеседованиях, предлагают писать код на листочке.
И это пипец как выбивает из колеи, ведь на листочке нет ни просто автозавершения, ни тем более предложений от ИИ, который по контексту пытается сразу код предложить.
freeg0r
07.10.2026 03:00"в комнате где стол, два стула и из электрического..." лампа направленная тебе в лицо
gravitytimewheel
07.10.2026 03:00последнее интервью это live coding в .... Codex, крупная компания в Заливе. Проверяют кругозор, умение концептуально разбираться в том что получилось, собесы проходят уже на уровне оценки общего мышления и коммуникаций, может это и исключение но скорее всего к этому приходит, читайте книжки, качайте не скилы а общий интеллект
shabrak
07.10.2026 03:00Не важно какая эпоха AI не AI, проблема экзаменационных собеседований всегда была одна - к ним нужно готовиться, а это значит, что к ним МОЖНО подготовиться . А если к вашему собеседованию можно подготовиться, это плохое собеседование.
A1x_Deb0
07.10.2026 03:00проблема экзаменационных собеседований всегда была одна - к ним нужно готовиться,
Проблема собеседований - что вы ищите при собеседовании?
Когда компьютеры были большими а литературы мало - все свое носили с собой. Это были дорогие знания - алгоритмы, сортировки и прочее нюансы. Профессионалам было о чем поговорить.
Когда цена доступа к знаниям упала,информация доступнее, компьютеров стало больше, появились "свободные" вычислительные ресурсы - можно их было инвестировать в "ускорить железо" и "ускорить бизнес". Но все равно люди понимали как работает железо, зачем всякие трюки с выравниванием размера структур в памяти.
Вспоминаем новость - В Cloudflare сэкономили 100 ТБ оперативной памяти, оптимизировав кэш DNS‑резолвера 1.1.1.1 . У меня другой вопрос - а как их умудрились сожрать ? Одна фраза " инженеры обратили внимание на особенности ... " объясняет. Но их же (команду) кто-то собеседовал ? Лет 20..25 назад если ты не мог в голове прикинуть размер данных в памяти и с учетом этого писать оптимизированный код - ты мог просто не пройти собеседование. Лет 15 назад, когда ты обозначал эти нюансы, на тебя уже смотрели как на блаженного.а это значит, что к ним МОЖНО подготовиться .
Повторю вопрос - а к чему готовиться ?! .Net пишут 20+ лет, с кучей нюансов. А Вы уверены, что ВЫ поймете объяснение того, КОГО будете собеседовать или ваша реакция будет 'Что он несет ..'? А человек из любопытства разобрался в исходниках.
Собеседование на архитектуру ? Сколько типовых архитектурных решений предлагает AWS и Azure ? Сотни под разные бизнес задачи.
Azure Pattern catalog на текущий момент предлагает 43 Cloud design patterns. Сколько из них за полтора часа собеседования успели обсудить? сколько из них в вашем решении ? Сколько надо времени, что бы разобраться прочитать описание именно того шаблона, что именно есть у вас, если человек не сталкивался ? 5 минут ? А вот полезет ли человек читать и разбираться если не знает - это вопрос.
>А если к вашему собеседованию можно подготовиться, это плохое собеседование.
Вы ищете органический "горячий кэш" набитый последними модным данными ? Или вы ищете механизм эффективной трансформации знаний и опыта в решение вашей бизнес проблемы ?
Судя по собеседованиям 90+% ищут именно "органический горячий кэш набитый последними модными данными" объясняя "Так он же будет три дня подкачивать\выравнивать скил за мой счет ... "
Plesser
07.10.2026 03:00Да пусть использует AI. Поставить ему задачу, где человек должен прежде чем писать что AI продумать всю архитектуру того что хочет получить и поставить это грамотно AI. Например, пусть кандидат предложит и опишет архитектуру ПО для магазина, или банка. Или чего то еще.
semmaxim
07.10.2026 03:00Обсуждение опыта - это ловушка с положительной обратной связью. Если брать только с хорошим/интересным опытом на самые вкусные вакансии (которые и дадут такой опыт), то люди с "обычным" опытом никогда уже не наберут хороший.
HakerZz
Идея с живым код-ревью нравится, особенно оценка того, какие вопросы кандидат задаёт до поиска ошибок. Но почему уточнение контекста должно стать существенным препятствием для агента? Можно ведь заранее попросить его выяснять требования, ранжировать риски и предлагать проверки.
Я бы попробовал открыто разрешить ИИ на таком интервью, а затем изменить одно условие задачи и попросить кандидата пересмотреть решение: какие замечания теперь несущественны, что требует исправления и каким тестом это проверить. Отдельно — попросить объяснить, с каким советом модели он не согласен и почему.
Как вы оцениваете результаты код-ревью: по числу найденных проблем или по качеству аргументов и приоритетов? И пробовали ли сравнивать этот формат с разрешённым ИИ и без него?