Поделюсь своими мыслями о том, как проходят интервью и что на них обсуждается. Подчеркну, что я буду рассуждать в проекции веб-разработки, но, вероятно, это можно применить на любую область.
Оговорюсь сразу - у меня нет огромного опыта прохождения интервью: всего довелось присутствовать на 7-10. К этому добавляются интервью знакомых, которыми они поделились, а также те, что лежат на просторах интернета (например, на YouTube).
Типы вопросов
Я предпочитаю делить вопросы на некоторые категории.
Теоретические вопросы.
Обычные вопросы по теории, на которые надо дать определенный ответ или точно описать технологию или подход. Так проверяются знание и понимание основных концепций и принципов разработки, и всё это обычно можно погуглить или прочесть в Википедии.
Это может быть:
Что такое ООП?
Что такое паттерн MVC?
Что такое event loop?
Что такое http?
Что такое атака типа XSS?
Что такое DOM/BOM/Telebom загорелся кошкин дом?
Задачки-забиячки.
Задачи с подковырками на знание специфического поведения языка или библиотеки. Встречаются вопросы о том, как использовать определенные функции, методы или конструкции языка. Как правило, 95%-99% из того, что будет представлено кандидату, он никогда не увидит в продакшн коде. А самое бесячее - это когда на экране происходит миллиард всего, и где-то на какой-то строчке хитро спрятана ловушка (неправильный синтаксис или внезапная операция над переменной). Эдакие задачки на внимательность.
Это может быть:
Что выведет console.log() в N ситуации?
Что будет содержать переменная в данном случае?
Будет ли здесь ошибка?
Промис с цепочкой в 100 вызовов then, catch, finally, что будет в последнем then.
Адский экспрешен, который в жизни не встретить, по типу ('aboba' == !typeof '123' != 123), и что он даст.
Что будет, если два раза сделать bind на функции с разными объектами?
И тому подобная ересь на знание всех пограничных случаев.
Вот пример сборника подобных задач: (гитхаб)
Алгоритмические задачи.
Обычно вам предлагается решить определенную задачу или проблему с использованием алгоритмов и структур данных. Это может быть алгоритм на обычную сортировку массива, бинарный поиск или алгоритм на поиск узла связанного списка, на котором происходит зацикливание списка. Сложность задач сильно варьируется от компании и интервьюеров. Также здесь не исключены задачи, которые вы никогда в жизни не встретите: на практике такие бывают 1 к 100. Просто вчера интервьюер увидел вот такой прикольный алгоритм и пошел спрашивать его у кандидатов.
Задачи в контексте какого-то фреймворка или библиотеки.
Эти вопросы представляют собой задачи, связанные с использованием определенного фреймворка или библиотеки. В основном это задачи в вакууме и придуманных ситуациях. Также задачки-забиячки не исключены и тут. Но иногда просят сделать действительно что-то похожее на мини-таску на 15-20 минут, чтобы посмотреть, как вы пользуетесь данным инструментарием.
Вопросы о решении проблем.
Вас просят рассказать о том, как бы вы решали определенную проблему или ситуацию, возникающую в процессе разработки. Обычно придумывать что-то абстрактное и не нужно (хотя и можно), поэтому в ход идут проблемы, которые возникали у людей, вас собеседующих.
Это может быть:
Нам надо хранить много данных на стороне клиента, что будем делать?
Надо организовать хранение паролей в БД, как сделаем?
Нужно сделать красивую анимацию, как реализуем?
Нужно сделать много вычислений на стороне клиента, как поступим?
Оценка реакции на нестандартные ситуации .
Суперредкие вопросы. Вас ставят в определенную ситуацию и слушают, как бы вы ее разрешали и что делали. Скорее всего, эти вопросы направлены на то, чтобы понять, как вы действуете в команде, знаете ли вы, к кому можно обратиться.
Это может быть:
Случился баг на проде и теперь сайт полностью лежит. Что вы будете делать?
Каждые 5 минут падает сервер или база данных, что делать?
Не работает конкретное поведение, как предполагалось в браузере/интерфейсе, что делать?
Тестировщик Василий завел 100 багов без описания и прикрепил к вам, ваши действия?
А в чем, собственно говоря, проблема-то?
Проблема для меня в том, что выглядит это всё, как какой-то тест, экзамен вроде ЕГЭ. То, где мы выбираем ответ, ставим галочку. И можем либо ответить правильно, либо неправильно. Эти тесты не похожи на то, с чем вы столкнетесь в реальности. Мы в вебе даже шутим: «Есть два вида JavaScript - для собеседований и для работы».
Это похоже на конкурс «Кто больше всего зазубрил». Возникает такое чувство, что все эти справочники и документации нужны для того, чтобы их один раз выучить и не открывать никогда, а делать всё по памяти за отведенное количество времени.
Но ведь главное, чтобы у разработчика было пассивное знание о том, какие бывают проблемы, разновидности API, методологии, библиотеки и т.д.. И когда он будет перебирать в голове варианты решения, он вспомнит, что вроде бы такой-то инструмент это делает или такой-то API может то-то, обратится к документации и применит его.
В реальности абсолютное знание всех аспектов труднодостижимо (невозможно!). Всегда с чем-то придется столкнуться впервые и пойти в гугл, с нуля изучая вопрос.
Как пример. Я предполагаю (когда-то читал доку или по логике вещей догадываюсь), что в библиотеке React Router Dom есть какой-то способ взаимодействовать с параметрами поиска в строке состояния браузера. Я иду, открываю документацию и уже конкретно ознакамливаюсь с подробностями использования и применения данного функционала, заодно это попадает в мою память на определенное время.
Зачем держать в голове всё-всё, когда есть справочники, документации и заметки? Мы запоминаем только то, с чем мы чаще всего взаимодействуем. Если мне надо сделать какую-то навигацию по DOM дереву, а я уже 100 лет этого не делал, конечно же, я не вспомню всех методов навигации, я открою справочник, посмотрю и выберу нужные мне вещи, заодно и в памяти это освежится.
Люди ходят в разные компании именно на интервью, чтобы набить руку на прохождение собеседований, решают сотни задач на литкоде, чтобы префайром бахнуть любой алгоритм, который его попросят написать. Есть разные сборники вопросов и типичных задач для собеседований не только для разных языков и технологий, но и для разных компаний. Вот шуточное (или нет?) видео про то, как программисты чрезмерно готовятся к собеседованию: (видео).
Я, конечно, не против того, чтобы люди решали алгоритмы и что-то учили, но чтобы это не выглядело, как бездумное запоминание ради прохождения собеса, без осознания того, для чего вообще всё это придумывалось и зачем всё это нужно. Это не похоже на диалог двух инженеров, которые используют определенные инструменты для решения определенных задач, обсуждают проблемы и их решения (за исключением двух последних категорий вопросов, и то не всегда они есть или являются таковыми).
Я понимаю: данные типы вопросов никуда не денутся; они нужны для проверки, что человек не полный ноль, если вы собеседуете стажера или джуниора. Но и в таком случае нужно вести диалог, который бы раскрывал понимание языка/инструмента/подхода кандидатом.
Поэтому, когда в описании позиции для разработчика с 3-6 годами опыта написано: «...для вас event loop и потеря контекста не должно быть пустым звуком, а конкретными терминами...», это для меня выглядит, как если бы в описании вакансии водителя говорилось: «Для вас педали газа и тормоза не должны быть пустым звуком, а конкретными частями автомобиля». Ну, тут еще, возможно, HR описание делал без консультации, такое встречается регулярно.
Конечно, нужен отдельный разговор про накручивание опыта работы и про то, что на интервью с опытом работы в 5 лет тебя спрашивают: «Что такое коллекция Set?». Да и в принципе никто не гарантирует, что человек с 3-6 годами реального опыта работы будет знать на этот опыт работы. Можно же не развиваться и не учиться, кто заставляет-то?
Так, а как надо-то тогда?
Еще раз оговорюсь, что всё это мои мысли и мое мнение. И вообще, кто я такой, чтобы кому-то что-то говорить, как им нужно делать, подумаешь, ферзь тут нашелся.
В первую очередь, нужно больше разговорных вопросов, где можно что-то обсудить и понять, как кандидат мыслит, как он пытается найти решение какой-то проблемы или рассуждает, проблема ли это вовсе.
Вместо вопроса «Что такое event loop?», можно задать вопрос: «Как ты думаешь, зачем нам вообще нужен этот event loop? Без него никак вообще? Какие проблемы он решает?». Вы не будете слушать очередное до смерти зазубренное определение про очереди макротасок и микротасок и стек выполнения, а вы услышите, как видит это кандидат, понимает ли он концепцию event loop'а.
Вместо вопроса «Как нам установить куки?» - «Для чего нам нужны куки? Зачем их придумали? Какой пласт потребностей они закрывают?».
Вместо вопроса «Что такое http протокол?» - «Зачем нам нужен http протокол? Зачем там какие-то хедеры, зачем там какие-то еще методы http существуют? Для чего его вообще придумали?»
Вместо вопроса «Что такое связный список? Напиши мне реализацию связного списка» - «Использовал ли ты связный список? Зачем нам нужен связный список? Где его можно применить, в каких ситуациях?»
Принцип понятен. Разговариваем с кандидатом и слушаем, как он рассуждает и какие решения предлагает, какие выводы делает. Ясное дело, что кандидат с какими-то ситуациями мог и не сталкиваться и что-то не знает, невозможно всё постичь. Тут важнее понять ход мыслей человека: просто ли он зазубрил какие-то определения или осмыслил то, что использует.
Конечно же, не все вопросы должны быть такими. Тут надо держать баланс. Главное, спросить кандидата по всем аспектам, а не завершать собеседование после первого вопроса на решение сложного алгоритма, который интервьюер и сам никогда в жизни не использовал. Знаю людей, которые проходили подобные алгоритмические интервью в серьезные компании, предварительно прорешав пару десятков задач (подготовясь, так сказать). Но это были слабые кандидаты в простом использовании технологий/библиотек/фрейморков, хотя их особо по ним и не спрашивали. Алгоритм решили, а значит, и так норм. Нет, не норм. Нельзя делать акцент на конкретно одной вещи.
Насчет алгоритмов тут отдельная история. Весь смысл же в том, чтобы посмотреть, как кандидат размышляет и как он пытается решить этот алгоритм, а не как быстро он его решит и каким у него выйдет так называемая Big O. Или я чего-то не догоняю, и все классные люди пишут легко любые алгоритмы, не используя никакую справочную информацию? По-моему, некоторые алгоритмы годами придумывались и улучшались, а не за 15-20 минут.
Также не понимаю, зачем спрашивать узконаправленные вещи и требовать их знание. На каком-то проекте N есть неосновная библиотека Х, и мало того, что требуют ее знание в вакансии, так еще и могут пару вопросов о ее использовании задать на собеседовании. Я понимаю еще спрашивать про основную используемую библиотеку или фреймворк (а-ля React, Angular, Vue и тд.), но требовать знание кучи библиотек с работой с глобальным состоянием, формами, запросами и т.д.? Я же не учу в свободное время все библиотеки подряд и могу просидеть на проекте с определенным набором инструментов долгое время, а потом начать искать другой проект с другим инструментарием. Получается, мне надо обязательно быть знакомым со всем, что использует искомый мной проект?
Логика должна быть в том, что я в первую очередь — инженер, который ознакомится и начнет использовать любой инструмент. Как я могу овладеть каким-то инструментом, не поработав с ним? Идти пилить пет-проект? Так некоторые требуют именно коммерческий опыт. А потом проходит время и никто уже не пользуется таким инструментарием, и твои знания устарели, иди новый пет-проект собирай. Так может важнее база и умение адаптироваться, а не погоня за бесконечно выходящими библиотеками?
А как же осуществляется переход внутри компаний на новые инструменты? Ищут людей с улицы сразу со знаниями? Нет. Знаю, что берут людей внутри компании (конечно, речь не про все компании), кто хотел бы поработать с новым инструментом, дают им какое-то время на подготовку, и потом они делают проект. Предварительно отдельный человек проводит исследование инструментов, взвешивает их плюсы и минусы и потом помогает остальным, если у них возникают трудности в использовании. Тут скорее требование к знаниям диктуется бизнесом, потому что кому интересно платить за человека, который потратит время на изучение инструмента и дальнейшее его использование (даже во время онбординга), если можно сразу найти того, кто с ним работал.
Как по мне, надо спрашивать самые основы, а со второстепенными инструментами разработчик ознакомится по ходу дела. Если он хороший инженер, для него не составит труда прочитать документацию и посмотреть примеры использования в документации/кодовой базе проекта. Ситуация похожа на замкнутый круг с требованием к новичкам коммерческого опыта работы, когда для такого опыта нужно сначала устроиться в компанию.
Надо отметить, что из 10 кандидатов выберут того, кто знает больше остальных, тут уже ничего не поделать. Или нет? Смотря какие вопросы задавались кандидатам. Если вопросы по типу, что я описал выше - в виде экзамена-теста, то да, выбор будет сделан очевиднейшим образом. А если вопросы с рассуждением и логикой, то тут можно и посмотреть, действительно ли кандидат понимает, что он использует, или просто выучил синтаксис.
Так и к чему это всё?
Это всё больше поток мыслей. Но и также просьба к разработчикам, чтобы они не забывали: в первую очередь они — инженеры, которые решают проблемы, а не болванки по типу чата GPT, в которые загрузили определенные знания и больше они ничего не могут, кроме как бездумно их использовать.
