Привет! На связи Дима — Senior Frontend разработчик в Doubletapp. В этой статье я расскажу, как эффективно собесить фронтендеров. Мой стек — Vue, Nuxt, поэтому примеры будут на основе моего опыта, но текст подойдет для всех разработчиков и нанимающих менеджеров.
В этой статье
Много лет я работаю с разными форматами команд, включая аутстаф. Я провел и прошел более 80 технических собеседований. Эта практика показала, как сильно эволюционировали задачи разработчиков — и как медленно меняются подходы к их найму.
К 2026 году индустрия сильно изменилась. Инструменты стали мощнее, ИИ взял на себя рутину и написание шаблонного кода, а сложность систем выросла. Однако методы найма во многих компаниях остались прежними. Мы всё еще заставляем кандидатов проходить экзамен по билетам, проверяя их память, а не инженерные навыки и способность приносить пользу бизнесу.
Что я понял спустя 80+ собеседований?
Итог прост: нынешний формат технических интервью плохо предсказывает реальную эффективность сотрудника.
Мои выводы основаны на опыте участия в процессе с обеих сторон:
С позиции нанимающего (30+ интервью): я встречал кандидатов, которые безупречно отвечали на вопросы про контекст исполнения и прототипы, но не могли спроектировать архитектуру простого виджета. На выходе получались перегруженные God-компоненты, мутации props и непонимание реальных практических кейсов жизненного цикла компонентов Vue. Инженерная база у таких специалистов часто оказывалась близка к нулю при отличной теоретической подготовке, хотя списывать с GPT тогда еще не было особо популярно.
С позиции кандидата (50+ интервью): часто интервью напоминает экзамен по билетам в институте. Разработчику не только достаются рандомные билеты, так еще и приходится решать задачи, которых не существует в его рабочей реальности. Например, написание своей реализации eventListener-ов при найме на разработку интерфейсов для e-commerce, когда мы уже с Dom-ом напрямую особо не работаем. Это превращается в проверку на стрессоустойчивость, а не в оценку профессионализма.
Как собесят на рынке?
Сегодня рынок четко разделился на три сегмента, и во всех есть системные проблемы с оценкой кадров.
BigTech: крупные компании продолжают использовать формат MAANG с упором на алгоритмы и Live Coding на пустом листе. Безусловно, алгоритмы — это база, но часто после сложнейшего отбора разработчик попадает на проект, где его задачи сводятся к верстке стандартных форм. В итоге специфические знания, которые проверялись на входе, никак не используются в работе.
Средние компании: такие компании часто копируют эти практики без понимания контекста. Собеседование превращается либо в попытку решить оторванную от реальности задачу, либо в теоретический допрос по спецификации языка, которую кроме Мурыча (As For JS на YouTube) особо никто не читал.
Маленькие студии: собеседования вообще для галочки, и зачастую вопросы с первой страницы гугла.
Почему это все не работает
Я выделяю три основные проблемы текущих интервью:
Теоретические викторины: вопросы в духе «что вернет [] + {}» или детальный разбор Event Loop на уровне спецификации проверяют только память. В 2026 году большинство пограничных случаев закрываются фреймворками, линтерами и строгой типизацией. Мы проверяем эрудицию, хотя бизнесу нужен навык разработки.
Задачи на «велосипеды»: требование написать с нуля DeepClone или полифил для Promise.all не имеет смысла, когда под рукой есть оптимизированные нативные методы и библиотеки. Умение воспроизвести по памяти стандартный метод никак не гарантирует, что человек сможет спроектировать архитектуру приложения или грамотно декомпозировать сложную фичу.
Читерство: из-за таких рандомных и оторванных от реальности собеседований кандидатам ничего не остается, как использовать ИИ для прохождения собеседований.
Об этом поговорим поподробнее.
Фактор ИИ и «подготовленных» кандидатов
Сегодня прохождение стандартных интервью стало отдельным навыком, который действующим разработчикам просто некогда качать. Существует множество списков «Топ-100 вопросов», а использование GPT позволяет кандидатам давать правильные ответы, не обладая реальным опытом. Проблема таких списков в том, что они общедоступны и предсказуемы.
Если мы хотим нанять того, кто умеет работать, а не просто проходить интервью, задачи должны быть объемными, подготовленными и проверять мышление инженера. Только в живом обсуждении можно понять, насколько глубоко человек понимает процессы, а не просто воспроизводит заученный или сгенеренный текст.
Как проводить инженерное интервью: 4 принципа
Я считаю, что фокус должен сместиться на проверку мышления.
Быстрый фильтр на кругозор: вместо пытки теорией — короткий блиц. Понимает ли человек разницу между SSR и SPA? Знает ли о существовании Web Workers? Детали можно загуглить, важно понимание концепций и умение выбрать правильный инструмент.
Рефакторинг вместо написания с нуля: дайте кандидату работающий, но некачественный код (например, на старом Options API или с ошибками в реактивности). То, как человек читает и исправляет чужой код, говорит о его уровне гораздо больше, чем написание функции с чистого листа.
Реальная среда разработки: оценивайте кандидата в IDE или CodeSandbox. Не нужно тратить время на проверку того, помнит ли он синтаксис без подсказок. Важна логика, работа с асинхронностью и структура данных.
Проектирование систем (System Design UI): обсудите архитектуру реальной фичи. Например, реализацию бесконечной ленты с кешированием. Здесь важно услышать аргументацию: почему выбирается тот или иной стейт-менеджмент, как обрабатываются ошибки и как решение масштабируется.
Заключение
В эпоху развития ИИ ценность разработчика смещается от знания синтаксиса к умению проектировать решения. Для компаний это повод пересмотреть свои стандарты и начать искать инженеров, способных мыслить структурно. Такой подход (рефакторинг + проектирование + живое обсуждение) дает гораздо более точную оценку того, как человек будет работать с вашим кодом завтра.
А в этой статье я рассказал, что именно спрашивать на собеседованиях, чтобы нанять практиков, которые смогут быстро влиться в проект, а не теоретиков, которые умеют проходить собеседования с нейронкой.
Подписывайтесь на блог Doubletapp на Хабр!
Комментарии (50)
MartyMoog
02.03.2026 12:35Собесить - новое слово. Корень - бес...
Radisto
02.03.2026 12:35А со- это приставка, означающая совместно, вместе, кириллически ко- как коворкинг, копилот, коопрерация. То есть кобесить, потому что процесс выбешивает обе стороны и часто одинаково бесполезен для всех участников)))) Задорнов смотрит на меня с того света и улыбается: "мой урюк"
red_motif
02.03.2026 12:35Огромная проблема также состоит в том, что те, кто собеседуют разработчика на первых этапах чаще всего терминологию воспринимают как имена покемонов. Иногда даже имея хорошие навыки тяжело дойти до собеседования с командой, которой собственно требуется новый сотрудник. Однажды потратив более часа на рассказы о себе и вопросы о компании, в самом конце нашей первой встречи вдруг выяснилось, что у команды совершенно другое направление, а сама вакансия - одна на все команды (т.е. не отображает реально требуемые навыки для работы в определённой команде). Сие весьма печально и пока не понятно как с этим бороться. Жаль потраченного времени.
berendiaev
02.03.2026 12:35А в РФ многие ли занимаются сейчас многосекционным наймом?
Последний заход по собеседованиям заключался в триаде скрининг-техсобес-финалка. И это всем известные бигтехи РФ
Liubov2--2
02.03.2026 12:35Согласна с вами, собеседование начинается на этапе публикации вакансии, некоторые менеджеры просто не жалеют своего собственного времени или питают надежды "уговорить" кандидата на вакансию, которая заранее ему не подходит(
а сколько минут заняло у вас интервью?
dmvasiliev
02.03.2026 12:35Согласен с тезисом, что викторины по JS и «велосипеды» плохо предсказывают эффективность: рефакторинг и обсуждение архитектуры реальной фичи намного лучше показывают инженерное мышление.
Думаю, можно прямо разрешать пользоваться на собесе GPT, но просить кандидата объяснить, что он взял/отбросил и почему: это быстро отделяет “ходячую Википедию” от инженера.
quazar000
02.03.2026 12:35Не знаю, почему вы до сих пор нанимаете ходячие Википедии. Только что проходил пачку собесов. Большая часть из которых была в формате "Есть ли такой опыт? Если да, расскажите подробнее." И "Спроектируете мне, пожалуйста, /какой то простенький сервис/"
Безусловно, базовые вопросы тоже задают. Задают и банальные вопросы из списка 100 самых популярных вопросов на собесе.
Но вы же тоже смотрите на компанию, которая проводит собесы. Вероятно из двух компаний вы сами выберете ту, где собес был интереснее.
bossalex
02.03.2026 12:35Надо чтобы не тебя выбирали, а ты выбирал и прежде чем идти на опрос ваших знаний, важно узнать всё что вас интересует. И о чудо окажется что у вас не будет 30-100 опросов ваших знаний и умений. А останется 5-8 фирм которые подходят для тебя. Надо строить общение выясняя как ваш опыт может быть полезен проекту под который вас берут. А делать экзамен и тест на умение делать велосипеды и подвергать себя стрессу перекрёстного допроса это полный бред.
40kTons
02.03.2026 12:35Так ты слона не продашь (С)
Зачем оценивать свои скилы, выходить на рынок и обнаруживать, что в текущий момент по твоему стеку открыты десятка 3 вакансий, из которых 20 тебя не интересуют, если можно откликаться на всё подряд и потом писать статьи "я сделал 1000 откликов, но на работу не берут"
via-site
02.03.2026 12:35За 15 лет работы разработчиком и более 300 собеседований еще ни разу не попадал на адекватного интервьюера. Всегда была викторина с вопросами полностью оторванными от реальности. Экзаменатор вместо интервьюера. Часто замечал на лицах таких интервьюеров прищур и ехидную ухмылочку. Видимо в этот момент они особенно наслаждаются собой. При этом, лично я, всегда провожу собеседование в формате дружелюбного общения а не допроса с пристрастием. Всегда стараюсь максимально раскрыть опыт и навыки кандидата. Выяснить с чем именно он работал, что и как именно разрабатывал. Если человек не может детально рассказать чем он недавно занимался, значит с большей долей вероятности, скажем так, он сильно приукрашивает. Можно конечно же прикрыться NDA, но мне кажется для фронтенда это не особо актуально, тем более я интересуюсь только технической частью. По моим наблюдениям, очень мало людей с высоким уровнем глубокого мышления (deep thinking), большинство обладают более поверхностным, быстрым мышлением. Мне кажется для хорошего инженера лучше именно глубокое мышление.
Dhwtj
02.03.2026 12:35хорошего инженера лучше именно глубокое мышление.
Это такой тугодум интроверт, который плохо проходит собеседования, но хорошо работает?
Arhammon
02.03.2026 12:35Не хорошо - глубоко... Продуманное, проработанное решение иногда может быть уже не нужно...
ulisma
02.03.2026 12:35Как ни странно, да. Коммуникация лучше всего как раз у тех, кто не особо углубляется в тех. часть.
shadowphoenix
02.03.2026 12:35да, тоже замечал. Очень сильные ребята долго читают код перед тем, как провести ревью, медленно и коряво формулируют причины ошибок и улучшений, но если слушать, что хотели сказать, а не англоязычные теги, оказывается, что у них более взвешенное и глубокое мышление. В том году нанимал; оба сеньора, которые пришли, ни разу не сказали ни слово паттерн, ни его название. Но зато ошибку дизайна (BE) разглядели в первую очередь.
appet1te
02.03.2026 12:35Все скиллпоинты пошли в думалку. Бредоген не развился.
Так подумать, для болтолога было бы неплохо быть эмоциональным, далее чтобы связь между полушариями были посильнее(ибо центр речи в левом) и не думать.
А для мыслителя наоборот, он думает своими глубинными связями, еле еле эти монструозные штуки через мост между полушариями проходят. И если нашел суть, то скажет ее как-то.
И еще может быть это дихотомия: склонность к языкам <->склонность к абстракции. У кого хорошо с матаном и точными науками, сложность с изучением языков. У кого хорошо с языками, трудность в точных науках
Keeper22
02.03.2026 12:35Что делать тем, у кого хорошие способности как к математике, так и к (иностранным) языкам?
berendiaev
02.03.2026 12:35Вы наверное стопицотый, кто говорит про то, что нужно спрашивать про опыт, чем занимался и потом идти вглубь по нему. Я тоже считал раньше, что так будет лучше.
К сожалению, это утопия... Кандидаты могут рассказать что-то такое, с чем ты не работал и не знаешь нюансов. И приходится звать с собой на помощь коллегу, потому что одна голова хорошо, а две лучше. Если это происходит в бигтехах, то там собеседования потоком идут, у многих проведение собесов вписано в обязанности, не сказать что коллеги будут рады такому выключению из потока. Кроме того, крайне затруднительно написать хороший отчёт по такому собеседованию. Но это я про специфику больших компаний щас говорю.
А если начать спрашивать про конкретный опыт, который нужен именно для данной вакансии, то это быстро превратится в классическое собеседование, просто с выдумыванием вопросов на ходу.
CorwinH
02.03.2026 12:35Экзаменатор вместо интервьюера.
Чтобы понять, насколько кандидат разбирается в некой теме, нужно задавать всё более сложные вопросы, пока он ответит "не знаю". Со стороны может показаться, что интервьюер специально заваливает. Но на самом деле, ответ "не знаю" может не быть минусом для кандидата. Даже может быть плюсом - в зависимости от того, как это "не знаю" сформулировано.
botyzanzylyvseNIKI
02.03.2026 12:35Ага точно описал. Ждут ошибки. Вахтер-менеджер. Кстати это не только в разработке, поголовно в it какие то экзамены школьные на теорию.
бесят
francyfox
02.03.2026 12:35Сначала отсобесят впятером, потом камеру попросят покрутить, вдруг там не настоящие все. А вообще в некоторых компаний гит проверяют. Поэтому у некоторых разрабов появилась привычка скрывать все репы. Лайвкодинг не о чем, слишком маленький объем. А тестовое не все захотят сдавать. Идеальный вариант это песочница, оплачиваемое тестовое, испытательный срок. Но это же дорого... Нужно прорядить стадо
Dhwtj
02.03.2026 12:35Понимает ли человек разницу между SSR и SPA?
Автор сам понимает? )))
SSR и CSR - про место рендеринга. SPA и MPA - про навигацию. Четыре комбинации, все существуют. Next.js с SSR + hydration это SSR SPA.
shadowphoenix
02.03.2026 12:35Хороший вопрос! Я тоже спрашивал разницу между протоколами SOAP и REST.
codeforcoffee
02.03.2026 12:35Это классический вопрос когда надо отвечать "Да это вообще про разное". Буквально тоже самое что спросить, отличает ли человек тёплое и мягкое.
LeVoN_CCCP
02.03.2026 12:35Простите, а что это такое?:
DennisP
02.03.2026 12:35Так в самом первом предложении же указано, что автор работает в этом самом аутсафе
LeVoN_CCCP
02.03.2026 12:35Да, вот что значит читать статью пару часов с перерывами. Но за ссылку просто глаз зацепился, чуть ли не с "инвайтом" от автора.
DaggerMouse
02.03.2026 12:35УУУууу! Меня прям злит тайтл, википедии они нанимают. Словари вы нанимаете, у которых знаний как у попугая. Я когда в крупной российской компании пахал, наверное человек 400 отсобесил, и что важнее 30 человек собеседовали иногда со мной в паре, ощущение было, что я учил парного собеседующего с лычкой техлида тому, как строятся приложения и почему.
Инженерные навыки и способность приносить пользу это как раз то, что у вас чатжпт должен решать. А сильная теоретическая база, позволяющая моментально учуять, где чатжпт красиво написал вам дерьмо. Понять, зачем нужна была та переменная, которую создал, не использовал и теперь скромно предлагает удалить. Оценить, актуально ли решение чатажпт или натренировано десятилетиями говнокода в интернете.
fo_otman
02.03.2026 12:35Еще одна ошибка собеседующих - спрашивать про прошлый опыт. Мне может он не нравится и я хочу от него избавиться? В регионах, кроме Битрикса, ничего особо нет на рынке. Это не значит, что люди хотят дальше с ним работать. А опыт в других областях - нету. Опять этот проклятый замкнутый круг. Мы живем в 2026 году, господа! Технологии изучаются за полдня. ИИ, курсы, видео, github - все в свободном доступе. Вопросы для найма надо кардинально перерабатывать.
shadowphoenix
02.03.2026 12:35Вопросы для найма надо кардинально перерабатывать.
Предложения?
kneaded
02.03.2026 12:35Даже если накидаю, кто эти идеи всерьёз будет прорабатывать?
Я считаю давно назрела тема что-то вроде круглого стола, где компании между собой будут договариваться как лучше собеседовать. И экспертов с улицы приглашать.
А то щас так получается, что я условно вам одному расскажу, мы поспорим и разойдемся - смысл тратить время на предложения?
Предложений к слову на том же хабре полно - просто достаточно почитать статьи на тему найма
DipCoy
02.03.2026 12:35Вообще полностью согласен со всеми доводами автора. Сам страдаю от всех этих собесов из википедии и первой страницы гугла. И даже, к сожалению, сам вынужден проводить такие собесы, просто потому что часто ищем человека на аутстафф и ему придётся пройти ещё собеседование с клиентом, а там я точно знаю, что будет точно такой же оторванный от реальности собес. Вообще печаль-беда. Если провожу собеседование кандидата К СЕБЕ в команду, то тут больше поле, где можно разгуляться, там и вопросы можно задать близкие к реальности, и может даже задачу дать как раз на рефакторинг или проектирование.
А вот с аутстаффом так и не придумал, что бы такое сделать. Может у кого есть опыт решения этой проблемы?
OlegZH
02.03.2026 12:35... может даже задачу дать как раз на рефакторинг или проектирование.
И что Вы можете попросить сделать? Не придумаете чего мне на подумать (никуда не напрашиваюсь, для своего развития)? Буду Вам очень благодарен. (Если, кончено, возможно, что-то взять и сформулировать.)))
cheshirskins
02.03.2026 12:35"Крутые: с 2025 спрашиваем за AI". А что можно спрашивать на тему AI? Если просто пользоваться готовыми продуктами, а не самому участвовать в разработке искусственного интеллекта, то вроде бы ничего особо интересного нет
taras-m0
02.03.2026 12:35Спрашивающие хотят узнать что то новое, вот и спрашивают. Возможно у вас какие то новые инструменты или особые промпты.
Lashadkach
02.03.2026 12:35Этот пост показывает на сколько реально найм отстал от действительности.
С приходом ИИ фокус ещё больше смещается на инженерные навыки, но получить аудит от GPT по вопросу решения той или иной задачи в контексте проекта лично для меня теперь мастхев. Отсюда и мысль что подходы даже этой статьи с проверкой архитектурного мышления уже устарели, ведь ИИ снимают тонну когнитивной нагрузки генерируя идеи и спасают от выгорания. А что я увидел в статье? Проверки в редакторе кода, смешно ведь это подход буквально вчерашнего дня. Не хочу оскорбить автора, мне статья понравилась, просто хочу подметить насколько найм в ужасном состоянии.
Критикуешь - предлагай, да? Если уж и проводить собес, то делать это простой задачей. С ИИ, в удобной для кандидата среде, предупредив заранее и оценивать конечный результат, потраченное время, мышление, способность кода к масштабированию и читаемости. Но уж точно не заставлять писать что-то на бумажке или просто в ide и выдавать это за какой-то прорыв
Когда берут сварщика на работу его просят сварить 2 куска металла и наблюдают за его работой. И всё, остальное формальности. По работе кандидата всё сразу становится понятно, но почему-то в программировании модно на собеседованиях страдать ерундой. Ах да HR же надо чем то занимать
crawlingroof
Меня одного фраза "Как собесят" - бесит?!
Serg0077
Ну.. кого то и соБесят.
SystemOutPrintln
Собесят так, что аж бесит!
askv
В советское время собесом называли отдел соцобеспечения. Ну куда бабульки и все нуждающиеся ходили...
Oncenweek
Я так понимаю, что это слово в широкое употребление так и проникло - через иронию, когда бабульки еще ходили В собес, а вчерашние студенты уже ходили НА собес
Einherjar
Не прошел собес - пошел в собес
askv
собес в собес...