Константин Шибков (на Хабре sendelust)  —  эксперт Skillbox и Java-разработчик, который искренне любит собеседования. Не только проходить их сам, но и обсуждать чужие. Он расспрашивает знакомых, какие им попались задачи, а потом разбирает их вместе с участниками своего алгоритмического клуба JavaKeyFrame. Ведёт телеграм-канал «Три монитора», где делится личным опытом. Мы поговорили с Константином о том, почему техническое интервью — это не пытка, а интеллектуальное удовольствие, как проводить собесы по-человечески, зачем нужны задачки «на подумать» и почему иногда лучше не отвечать сходу, а сначала задать встречный вопрос.

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

— Ну, это всегда какой-то челлендж. Есть элемент соревнования: сможешь ли ты решить задачу, пройдёшь ли ты интервью. Это не про поиск работы. Мне интересно просто попробовать — а вот возьмут ли, а что там спросят. Иногда задачи попадаются нестандартные, и сам подход к ним бывает необычный. Это своего рода хобби — не то чтобы серьёзное, но точно увлекает.

— А есть примеры самых необычных заданий, которые тебе или участникам клуба попадались? Что прям запомнилось?

— Честно говоря, чего-то супернеобычного, наверное, не вспомню. Больше всего удивляет, когда... вообще ничего нет. Вот человек рассказывает: «Пришёл на собес, они такие — пойдём пообедаем. Сходили в кафешку, поболтали». И всё. Никаких задач, ничего. Вот это реально выбивает.

А вот когда дают задачи сложные или вообще непонятные, зачем они нужны — это уже другое удивление. Такое, скорее, отрицательное. Типа: «Ну и зачем это всё было? Зачем я сюда пришёл? Какой в этом смысл?» Такое чувство пустой траты времени.

— А встречались ли тебе или ребятам из клуба какие-то совсем упоротые или нелепо сложные задачи? Особенно, если это был джун или мидл?

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

Например, классический вопрос по Java: чем отличается ArrayList от LinkedList? Джун, допустим, скажет, что в одном случае это массив, а в другом — связанный список. А миддл объяснит, как это влияет на производительность, на какие кейсы подходит каждый, и почему LinkedList, несмотря на обещания, часто оказывается медленнее.

Я даже от HR слышал: у нас есть «правильный ответ для джуна» и «правильный ответ для мидла». Один вопрос — разный уровень глубины. Тут важно не просто «знать», а понимать, что с этим делать на практике.

— А что по алгоритмическим задачам? У тебя ведь клуб, где вы их регулярно решаете.

— Да, это отдельная тема. Сейчас такие задачи, наоборот, становятся всё популярнее. Хотя, что интересно — те компании, которые изначально и запустили эту волну, уже начинают от них отказываться. Говорят, что они неэффективны.

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

Но пользы от этого — спорный вопрос. Да, алгоритмы развивают мышление, да, они полезны в олимпиадной среде. Но в реальной работе их применяешь крайне редко. Чаще всего ты просто учишь эти задачи, чтобы пройти собес. А потом благополучно забываешь.

— И всё же — встречались задачки, которые запомнились?

— Да, иногда попадаются прям странные штуки. Был случай, когда задачу явно выдумали «от обратного»: сначала придумали красивое решение, потом вокруг него слепили условие. В итоге — суперспецифический случай с графами, какие-то циклы, неочевидные ограничения. И если ты не решал именно эту задачу, то будешь сидеть и долго ковыряться. Просто потому что это не про логику, а про угадайку.

А бывает наоборот: приходишь, и тебе попадается задача, которую ты уже решал. И тогда можно устроить мини-спектакль: «Ой, интересная задачка! А если так, то… А вот есть ещё такой вариант…» Хотя на самом деле ты просто знаешь ответ наизусть.

— Получается, алгоритмика — это такой маркер на упорство, а не на опыт?

— Именно. Это скорее проверка на то, насколько ты задротил перед собесом. Потому что по-настоящему оценить разработчика — это всё-таки задачи ближе к реальной жизни. Когда обсуждаешь код, паттерны, компромиссы — вот это интересно. А не угадайка на тему, сколько шагов от вершины A до вершины B в DAG.

— В идеальном мире каким должно быть техническое интервью? Какие задания на собесе — это ок, а какие нет?

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

Тут не надо писать код самому, что, кстати, для многих плюс. Лайвкодинг вызывает стресс. Тем более, если просят писать в браузере, где максимум — это подсветка синтаксиса. Ни автодополнения, ни проверки типов, ни удобной IDE. Хотя сейчас с этим полегче — часто разрешают писать в своей среде. Главное просят отключить ИИ-помощники, чтобы не мешали.

— А как ты относишься к тестовым заданиям?

— Я не против. Особенно на уровне джунов и мидлов. Для джуна — это практика, плюс остаётся артефакт, который можно показать другим. Но проблема в том, как эти задания обычно подаются. Ты что-то делаешь, отправляешь — и дальше тишина. Ну или тебе просто говорят: «Окей, теперь пойдём на собес», и всё. То, что ты сделал, вообще никак не обсуждается.

А вот когда задание — это основа интервью, это круто. Ты приходишь, открывают твой код и говорят: «Расскажи, почему ты сделал так, а не иначе». Тут видно, насколько ты в теме. Если ты понимаешь, о чём пишешь, можешь объяснить компромиссы, почему выбрал один подход, а не другой — это сразу говорит об уровне. Даже если решение простое, но ты можешь сказать: «Я бы использовал transactional outbox, но времени было мало, сделал проще» — это ценится.

— Что думаешь о критике тестовых — мол, «отнимают личное время», «никто не компенсирует» и т.п.?

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

Главное, чтобы задание было вменяемое. Не «напиши YouTube за выходные», а адекватное по объёму и сложности. И ещё важно — подготовить пул таких задач, а не выдавать всем одну и ту же. Вот, например, в «Яндексе» сейчас, по ощущениям, всем на одно направление дают одну и ту же задачу. Уже минимум пять человек получали её подряд.

— Случались казусы на собеседованиях?

— Да, вот был случай: мне дали задачу, всё пошло нормально. Интервьюер сказал: «Окей, вижу, почти готово, допиши, и закончим». Я закончил за 5 минут после окончания слота. Потом приходит фидбэк: всё супер, но не проходишь, потому что вышел за лимит. Это странно. Если время — критичный параметр, зачем давать продолжать? А если не критичный — зачем отклонять? Такое ощущение, что просто нужен был формальный повод.

— Что насчёт парного программирования на собесе?

— Это крутая практика. Особенно, если задача не алгоритмическая, а близкая к реальному коду. Лучше всего работает, когда кандидат — инициатор: «Давай попробуем вот так». А интервьюер направляет, иногда поправляет. Не сверху вниз, а как напарник. Это продуктивнее, потому что ты видишь, где у человека провалы, но не валишь его, а проходишь вместе, чтобы добраться до других областей знаний кандидата.

Кандидаты после такого формата тоже обычно в восторге. Потому что это не допрос, а взаимодействие.

— Правильно понимаю, что обсуждение кода и совместная работа на интервью — это менее стрессово?

— Конечно, менее стрессово. И, главное, — кандидат потом уходит с хорошим ощущением от собеса. Часто говорит: «Классный формат, я даже что-то новое узнал». А это уже показатель. Потратить 15 секунд, чтобы что-то объяснить человеку — нормально. А не так, как бывает: ты ответил — и тишина. Ни «да», ни «нет». Интервьюер просто говорит: «Окей, принято. Следующий вопрос». И ты сидишь, не понимаешь: ты вообще прав был или нет?

— То есть фидбэк должен быть в моменте?

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

— Что думаешь про теоретические собеседования? Сейчас их всё ещё много.

— Да, теоретических блоков сейчас не избежать. И часто это просто зубрёжка. Уже мемные вопросы: про @Transactional в Java, про ArrayList vs LinkedList, замыкания в JS, deadlock'и — ты их видишь и узнаешь сходу, потому что уже много раз решал. И дальше выдаешь шаблонный ответ, который точно удовлетворит.

Но ведь ценность таких вопросов — почти нулевая. Человек может вызубрить, но ничего не понять. Лучше показать ситуацию. Не спрашивать: «Чем отличается ArrayList?», а дать задачу, где он сам поймёт, в чём разница — потому что код не работает или работает слишком медленно. Вот тогда начинается мышление, а не отработка заученного.

— А что по задачам на code review?

— Это интересный формат, но он сложнее в подготовке. Чтобы сделать такое задание, нужно взять какой-то проект, «слегка его поломать», добавить неоптимальности, убрать читаемость. Но важно не переборщить — иначе получится код, который никто в жизни так не пишет. Был пример — в коде просто стояло деление на ноль. Это не тест, это пародия. И кандидат, даже если знает, что задача фейковая, начинает думать: «Наверное, я должен что-то найти…»

— То есть качественное задание — это отдельная работа?

— Да. Особенно если делать набор под разные темы. Сейчас, к счастью, есть ИИ — можно сгенерировать заготовки, потом адаптировать под нужные блоки: многопоточность, коллекции и т.д. Вместо вопроса «Что делает HashMap?» — покажи код, где она тормозит. Пусть человек разберётся.

— А System Design? Сейчас же часто появляется.

— Да, и тут та же беда. Берут задания из книжек — например, из «System Design Interview» Алекса Сюя. Я сам сидел на собесе, знал задачу и понимал, что от меня ждут конкретный рассказ по книге. Даже если я не до конца понимаю логику, но знаю, что вот «правильный ответ» — это то, что они хотят услышать. Польза? Спорно. А вот если сравнивать с другими форматами, то System Design хороший инструмент. Он позволяет узнать кругозор собеседуемого, знание технологий и их применимость в различных сценариях. Например, помнит ли про мониторинг. Кандидат, если он этим не занимался, скорее всего забудет об этом при проектировании.

— Получается, шаблонность — главный враг?

— Абсолютно. Когда вопрос шаблонный, ты либо даёшь заготовку, либо — не дай бог — ошибаешься в мелочи и получаешь минус. А хочется наоборот: чтобы человек мог показать, как он думает, как действует, как решает. Relevance оценки сильно падает, если ты просто копируешь задания из интернета.

— То есть лучший подход — реалистичный сценарий, приближённый к работе?

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

— И всё-таки, если вернуться к формату: какой, по-твоему, оптимальный?

— Мне нравится парное программирование. Когда кандидат инициирует, а интервьюер — как собеседник. Не как надсмотрщик, а как партнёр. Кандидат предлагает: «Давай вот так», интервьюер отвечает: «Слушай, в нашей практике обычно так-то, но окей». Такая модель помогает пройти слабые места и перейти к следующему слою. Это даёт понимание, а не стресс.

— У меня к тебе такой вопрос. Бывает, что тестовые делают за кандидата, на собесе — используют GPT или даже помощника в наушнике. В итоге, нанимают такого человека, а через месяц увольняют — потому что он ничего не умеет. Что думаешь об этом, и можно ли как-то такое отследить?

— Да, история не новая. Это всё уже было. Я ещё в универе помню: микронаушники, радиопередатчики — классика. Да и в советских фильмах эта тема встречалась. Так что сама по себе идея не нова.

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

— А у компании ведь тоже издержки: испытательный срок, зарплата, отступные, запись в портфолио...

— Ну да, если кандидат уходит или его увольняют через месяц — компания теряет время и деньги. Это цена ошибки. Но опять же — главное, на мой взгляд, не впадать в паранойю. Да, кто-то может воспользоваться ИИ, кто-то — «помощником» в ухо, но это заметно по поведению и эмоциональному настрою. Иногда, по поведению после каждого вопроса. Больше возникает вопросов, когда человек специально отказывается включать камеру и вести диалог с глазу на глаз.

Например, зависает на три минуты, «думает», а потом внезапно выдает почти готовый ответ. Или читает код на ревью — и тишина. Ты не понимаешь, он вникает, отвлёкся или ушёл за чайником. Интервью превращается в немую паузу. Как интервьюер, ты в этот момент теряешь контакт.

— Как с этим работать?

— Я всегда советую кандидатам проговаривать вслух, что они видят и как думают. Даже если просто читаешь код — озвучивай: «Так, этот метод, похоже, делает вот это... Здесь, кажется, используется такой-то паттерн…» Это сразу даёт понимание, как человек мыслит. И если ты ошибся — тебе подскажут. Это нормальный рабочий процесс, не экзамен.

Интервьюер в таком случае тоже получает информацию: как человек анализирует, как идёт по коду, где спотыкается, где понимает. А если он «читает молча» пять минут, потом выдаёт результат — ощущение, что перед тобой нейросеть, а не живой кандидат. Мы ведь не ждём, пока модель обработает всё целиком, мы читаем по строчке. Увидел проблему — остановился, обсудил. Это и есть живой разбор.

— Получается, даже если кто-то попытается «читерить», это скорее видно?

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

— То есть паниковать не надо. А что делать с тестовыми, чтобы избежать этой проблемы?

— Самое главное: тестовое задание должно разбираться на интервью. Не просто — отправил, посмотрели, забыли. А именно открыть, обсудить, спросить: «Почему ты сделал так? Что бы ты улучшил?» Тогда становится ясно, кто писал. Человек расскажет, как принимал решения. А если не может — ну, всё понятно.

— Ещё история. Рассказывали, что ходят кандидаты по собесам, собирают типовые вопросы, потом продают или раздают. И компании жалуются, что наняли человека, а он через месяц увольняется — потому что на собесе ему в наушник подсказывали.

— Знаешь, я не вижу в этом особой проблемы. Ну да, кто-то собирает вопросы. А у нас в клубе то же самое. У нас 300 человек, и мы делимся тем, что было на собесах. Это же не секретная информация, лично мне не говорили на собесе «Никому ничего не говори, что ты сегодня услышал». Ты пришёл, поделился: вот задачи, вот формат. Это нормально.

Это как с ЕГЭ: есть типовые задачи, они везде опубликованы. И никто не говорит: «Ой, вы сливаете экзамен, нельзя!» Готовься по ним — никто не запрещает.

— А если кто-то ещё и собес записывает?

— Да, есть и такие. Кто-то пишет видео, делает скринкаст, потом делится внутри комьюнити. Я тоже так делал — но всегда с анонимизацией: голоса на разные дорожки, лицо замазано, название компании не видно. Это полезно для подготовки, особенно для тех, кто вообще не представляет, что его ждёт в этой компании. И снова это не ухудшает будущий собес. Можно подметить интересные моменты, какой формат ответов нравится, а какие выглядят слабо. Я бы сравнил это с просмотром летсплея игры на твиче. Когда смотришь как в игрок разваливает оппонентов с одного пистолета – все просто и понятно. Но когда садишься сам, то не получается скопировать поведение и скилл. 

Mock-собесы — это хорошо, но у них есть один нюанс: человек приходит подготовленный, настраивает себя «не облажаться». И ты видишь картинку, где джун отвечает как мидл. Настоящее собеседование — другое. Там видно волнение, реальный уровень. Поэтому записи настоящих собесов — это отличная практика, если использовать их по уму, не для обмана.

— Но по закону ведь без согласия нельзя записывать...

— Мы же тут не в суде. Это не уголовное дело. Мы не выкладываем это на YouTube, не делаем публичный контент. Анонимизация, внутреннее использование — вот и всё. И главное — это помогает. Люди готовятся, понимают, что их ждёт, слышат, как отвечают другие. Это реальная польза.

— Но компании всё равно возмущаются: «Наши вопросы утекли!»

— Ну так пусть не дают всем одну и ту же задачу! Ситуация простая: приходит один человек — ему дают задачку. Второй — та же задачка. Пятый — угадай что? Та же самая.

Так может, не кандидаты виноваты, что делятся, а компании, которые не обновляют пул заданий? Даже в школе есть два-три варианта. Сделайте десять. Смешайте. Рандомизируйте. Добавьте вариативность. Или необходимы задания где не будет одного правильного ответа, как открытые вопросы.

— Получается, делиться задачами — это нормально?

— Конечно. В этом нет ничего плохого. Хочешь защищать задание — разнообразь задания. А то выходит, что кто-то «ворует» вопросы… Но давайте честно: компании сами у друг друга таскают формулировки, паттерны, подходы. Так что обвинять кандидатов — последнее дело.

— Если резюмировать: каким должен быть идеальный собес?

— Всё просто. Дают реальную задачу или фрагмент проекта. Кандидат её решает — или обсуждает код вместе с интервьюером. И по ходу получает обратную связь. Не после, не через неделю. А сразу. Это даёт опыт, понимание, и ощущение, что тебя слышат. Вот тогда это — нормальный, здоровый процесс, а не стресс и угадайка.

— Сейчас алгоритмы на собесах спрашивают реже. А вообще, как ты считаешь — их стоит спрашивать?

— Я бы сказал так: алгоритмы стоит спрашивать только тогда, когда они реально нужны в работе. Проблема ведь не в самих алгоритмах, а в их бездумном использовании. Иногда их ставят просто как дополнительный фильтр — и всё. Люди отказываются идти на собес не потому, что им компания не нравится, а потому что им не хочется проходить ещё один алгоритмический этап. Это особенно актуально для разработчиков с опытом — они далеки от этого формата.

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

— То есть это не всегда про навык, а про то, кто готов тратить на это время?

— Именно. Можно взять любого опытного разработчика, дать ему типовую алгоритмическую задачу — и если он давно этим не занимался, скорее всего, он её не решит. Это нормально. Он просто не тренировал этот скилл. Но это ничего не говорит о его навыках.

— И ты думаешь, алгоритмы иногда используют как инструмент давления в переговорах?

— Да, и это, честно говоря, самая неприятная сторона. Я прямо сталкивался с таким. Проходишь техническое собеседование хорошо, а потом тебе говорят: «Алгоритмическую часть прошёл слабовато, поэтому мы не можем предложить тебе максимум вилки. Дадим на 20% меньше». Это звучит как формальность, но влияет на условия.

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

— Но ведь многим разработчикам, алгоритмы не нужны вообще.

— Так и есть. И не только фронтендерам. Большинство бэкенд-задач тоже не требует сложных алгоритмов. Всё уже реализовано в библиотеках, фреймворках, SDK. Что-то с нуля пишут крайне редко.

Алгоритмы могут понадобиться, если ты занимаешься низкоуровневой оптимизацией, highload-решениями, распределёнными системами, где важен каждый процент производительности. Там — да, нужны. Но таких задач немного. Даже в Big Tech.

— То есть алгоритмы — это скорее маркер на «технаря», чем реальный рабочий навык?

— Да. И при этом ирония в том, что даже в Big Tech большинство команд не пишут алгоритмы каждый день. Это узкий сегмент. Но планка задана — и все начинают её копировать.

— С чем, по-твоему, связан этот тренд на алгоритмы?

— Он пошёл из Google, Meta (бывший Facebook, запрещён в РФ), Amazon — всей этой «MAANG» тусовки. Туда хочет попасть очень много людей. Если у тебя 100 кандидатов на 5 вакансий — ты ставишь фильтр. Вот вам алгоритмы. 90 пришли, 45 отвалились. Отлично.

Потом — system design. Потом — культурное интервью. И в итоге у тебя остаются те, кто прошёл все круги ада. Из них и выбираешь. Это простой способ сужать воронку.

— И это проще, чем готовить задания под реальные кейсы?

— Ну конечно. Ничего проще нет, чем взять задачу на массивы или строки и дать её кандидату. Вот тебе условие, вот тебе 30 минут. Даже готовиться не надо. Это как школьные уравнения. Захотел — придумал новое, поменял цифры — и вперёд.

Поэтому все и копируют друг у друга. Один формат пошёл — и все такие: «О, у Google работает. А давайте и мы так же».

— То есть идея в том, чтобы «быть как Google», но задачи в итоге не отражают реальность?

— Да. Копируют структуру, но забывают задаться вопросом: а нужны ли эти задачи именно вам? Это ключевой момент.

— Давай в конце коротко подведём итоги. Какие выводы ты для себя сделал как человек, который регулярно собеседует и сам ходит на собесы?

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

Один 

— То есть ты скорее за практику, чем за теорию?

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

— А алгоритмы, теоретические блоки, опросы?

— Я бы не называл это обязательным злом, но всё же это уже немного устарело. Лучше обсуждать, как человек принимал решения, как решал реальные задачи. Вместо «а как работает такая-то аннотация» — спросить: «А почему ты тут сделал так, а не иначе?» Это сразу показывает, как человек думает.

— Лайвкодинг — это всё ещё стресс. Как к нему относишься?

— Лично я — за, просто это мне нравится и у меня много опыта проведения вебинаров, стримов и воркшопов. Да, это стресс для многих. Но это тоже практика. Если формат адекватный, без давления и с нормальной коммуникацией, то он показывает не только технический уровень, но и софт-скиллы. А они сейчас реально важны.

— Что ещё бы ты добавил?

— Главное — гибкость. Хорошее интервью — это всегда живое взаимодействие, а не жёсткий чеклист. Нужно смотреть на кандидата, подстраиваться, уточнять. Если кандидат начинает рассказывать про какой-то интересный опыт — дай ему это сделать. Пусть покажет, как он рассуждает. Это даст больше понимания, чем список пройденных вопросов. Если собеседование и интервьюеры вызывают неприязнь, возможно вы идёте не в ту дверь :)

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