Дополнительные вопросы на IT-собеседовании

На любом собеседовании есть конкретные профильные вопросы, а также вопросы на общие темы. Если к конкретным техническим вопросам кандидат может подготовиться, изучая документацию, код и книги, то общие вопросы могут загнать его в ступор.

В этой статье на примере собеседования на должность разработчика React рассмотрены общеконцептуальные вопросы, которые, впрочем, с некоторыми изменениями могут быть заданы соискателю на любую другую IT-должность.

1. Какие инструменты в React вам нравятся больше всего?

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

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

Если вы скажете, что вам нравится Redux, потому что это предсказуемый контейнер состояний, вы должны быть готовы продолжить разговор о нем.

2. Какое ваше самое крутое приложение на React?

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

3. Какие трудности у вас возникают в разработке?

У большинства веб-разработчиков есть сложности, возникающие в каждом проекте. Например, оркестрирование анимации или сложные схемы маршрутизации. Можно часами рассуждать об изъянах библиотек и о том, что может не получиться в подобных задачах.

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

4. Какие инструменты вы используете для запуска проектов?

Ответить можно по-разному: начиная с инструмента create-react-app до кастомных конфигов webpack или менее известных пакетных менеджеров. Снова же, в ответе стоит упомянуть те вещи, которые вам наиболее удобны. С другой стороны, вещи, которые были услышаны от других или где-то прочитаны, будут не интересны интервьюеру, в отличие от мыслей и опыта кандидата. Например, вы можете сказать, что у вас лучше всего получается строить проекты вне зависимости от их размеров и подкрепить это утверждение несколькими аргументами.

5. Использовали ли вы какой-либо другой фронтенд фреймворк в продакшене?

Здесь логично было бы обсудить преимущества и недостатки React по сравнению с другими технологиями. Спрашивая это, интервьюер проверяет, насколько хорошо кандидат разбирается в общих паттернах фронтенд разработки. Большинство фреймворков решают похожие задачи, но разными путями. Если кандидат знаком с этими задачами и методами их решения, то освоить новую технологию для него не составит большого труда.

В ответе на вопрос можно сравнить виртуальный или реальный DOM, решения по управлению состояниями, схемами маршрутизации и внедрения зависимостей и ещё много других тем.

6. Как бы вы оптимизировали производительность приложения на React?

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

Разговоры о микро-оптимизациях и общих идеях показывают кандидата с худшей стороны, нежели разбор кейсов решения каких-либо конкретных решенных задач.

Если вы обладаете опытом оптимизации производительности, не стоит рассказывать об этом в общих фразах. Лучше расскажите о конкретных утилитах и методах, которые вы использовали.

7. Как вы работаете в команде?

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

Быть командным игроком очень важно, и подобный вопрос покажет, был ли у вас опыт командной работы. Если же вы не работали в команде до этого, вам действительно стоит открыто сказать об этом — взять новичка иногда выгоднее, чем прожженного ветерана, который не умеет находить общий язык с командой.

Выводы

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