Я Данил Соломин, лид команды фронтенд-разработки в компании-подрядчике «Газпром нефти» и ревьюер на курсе «Мидл фронтенд-разработчик» в Яндекс Практикуме. Однажды, проводя четвёртое за день собеседование на роль мидл фронтенд-разработчика, я поймал себя на мысли, что кандидаты допускают одни и те же ошибки. Что особенно печально, эти ошибки можно было бы легко исправить. 

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

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

1. Теоретические вопросы

2. Алгоритмическая секция

3. Задачи с использованием конкретной технологии (фреймворка)

4. Вопросы про опыт и общие знания

5. Архитектурная секция (дополнительно)

Теоретические вопросы

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

При этом я всё равно могу поделиться парой советов и взглядом изнутри. Не буду говорить о классических вопросах вроде принципов SOLID, которые все учат перед собеседованием и потом так же быстро забывают. Кажется, что с ними всё довольно понятно.

Собеседующий будет задавать вопросы, на которые вы не сможете дать ответ, и это нормально. Обычная тактика интервьюера — задавать вопросы до тех пор, пока кандидат может на них отвечать. Если вам попался опытный собеседующий, он точно сможет спросить о чём-то, на что у вас не будет ответа, ведь его задача — определить глубину ваших знаний, чтобы впоследствии оценить ваш грейд. Поэтому…

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

Пройдитесь по основным главам учебников и документаций перед интервью. Например, для JS я рекомендую этот учебник. Просто посмотрите глазами тему. Может быть, вы увидите что-то, что вы не знаете или забыли. Часто интервьюеры в поисках идей для вопросов сами смотрят в эти учебники и цепляют оттуда какие-то темы.

Если вы не знаете значения термина, лучше его не употреблять в ответах. Это может создать впечатление, что вы рассказываете о том, чего не знаете. Совет может показаться банальным, но я не раз видел, как кандидаты начинали рассуждать о свойстве display: flex; и упоминали наличие inline-flex. Но после не могли рассказать, в чём же его отличие от flex. 

Алгоритмическая секция

Кажется, для многих это самая нелюбимая секция, что лично для меня крайне удивительно. Возможно, такая нелюбовь исходит из убеждения, что эти задачи имеют мало общего с реальной разработкой. Но это не так.

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

Поделюсь парой советов, как можно думать над задачами и искать к ним подход.

Обращайте внимание на паттерны. У многих задач есть похожие паттерны — зная их, вы пройдёте 90% подобных задач. Чтобы научиться эти паттерны замечать, достаточно решать задачи на LeetCode или Codewars. Обращайте внимание на решения, пытайтесь применять общие принципы на новых задачах. Хорошие примеры таких решений: «скользящее окно», «метод двух указателей», «использование HashMap для решения» и другие.

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

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

К примеру, есть такой use-case:

const generator = new MyClass().getGenerator()
console.log(generator.next())

Кандидат, вместо того чтобы посмотреть на то, как тут использованы инструменты (классы, генераторы), начинает писать с нуля свою логику, которая его только сильнее путает. Не надо так :)

Предположим, вы решаете задачу с LeetCode про заполнение контейнеров водой. Если решить с наскока не получается, подумайте над самым простым решением, которое можно придумать.

Это может быть даже не верное решение. К примеру, можно перебрать всевозможные пары и выяснить, где больше площадь. Обсудите вариант с интервьюером, возможно, его устроит и такое решение.

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

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

Мыслите вслух. Когда сижу в качестве наблюдателя на интервью, часто вижу, что кандидат не объясняет своих намерений и начинает сразу решать задачу. При этом интервьюер имеет в голове решение и пытается вести кандидата по своей линии мысли.

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

Будет сильно проще, если вы поймёте друг друга и будете «идти по одной дороге». К тому же, если покажете, как умеете мыслить, вы произведёте сильно лучшее впечатление.

Задачи с использованием конкретной технологии (фреймворка)

Чем-то эта часть очень похожа на предыдущую, но всё же есть отличия. Задачи обычно легче, но основаны на применении конкретной технологии. Если не знать её или конкретный API, выкрутиться не выйдет.

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

Приведу пример, как обычно составляю задачи. Обычно, если задач несколько, открываю документацию технологии и сначала смотрю какие-то простые API, которые знакомы всем. 

Например, пусть это будет документация React. Иду и нахожу useRef. И обычно отталкиваюсь от этого. Начинаю «нанизывать» условие на этот useRef. В итоге получается, что вся задача сводится к хорошему пониманию одной конкретной темы. 

А так как я открыл всю документацию, на поздних этапах велик соблазн взять не самый популярный API. К примеру, я, в качестве эксперимента, решил как-то создать задачу на основе useImperativeHandle.

Из 20 человек, которым я предлагал подумать над этой задачей, справились двое. Обоих мы взяли на работу. В общем, если понимать конкретный API, задача решается в 10–15 строк.

Изучите типичные задачи и лайфхаки для вашей технологии. К большому сожалению, задачи типа «что выведет этот код в консоль» — не редкость, и на них приходится отвечать. По моему опыту такие вопросы контрятся только знанием ответов на эту или похожие задачи. Посмотрите на YouTube типичные примеры таких задач. Обычно этого хватает.

Немного более конкретных примеров: часто вижу оптимизационные задачи в React. К примеру, важно знать, как работает цикл React’а и какие есть приёмы по оптимизации. С ходу такую задачу не решить, надо просто знать. Хороший доклад на YouTube по этой теме: «Опасны ли перерендеры в React и как их избежать?»

Или на прошлом проекте у нас был NextJS, и по нему на интервью были вопросы. Постоянно видел, что кандидаты работали с NextJS, понимали, как на нём писать, но как только я начинал спрашивать вопросы на понимание важных процессов в Next, уже были проблемы. Ссылочка, чтобы посмотреть: «Next.js. Как ты вообще рендеришь?»

Вопросы про опыт и общие знания

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

В целом на этом этапе часто присутствуют главы отделов или лиды команд. Они довольно много решают, несут развёрнутый фидбэк HR’у и могут сказать как что-то принципиально хорошее, так и плохое.

Больше интересуйтесь миром IT. Тогда, даже если вы не использовали технологию на проекте, вы всё равно сможете о ней рассказать. К сожалению, других каких-то лайфхаков довольно мало. Поможет только постоянный нетворкинг с другими разработчиками, просмотр конференций, использование технологий на пет-проектах. 

Архитектурная секция

Под самый конец оставил секцию, которую мидл-разработчикам крайне редко приглашают пройти. Я решил и о ней тоже написать, так как она мало похожа на другие этапы. К сожалению, у себя эту секцию мы не проводим, поэтому буду судить только по опыту её прохождения в других компаниях.

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

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

• Высоконагруженные приложения. Программирование, масштабирование, поддержка, Клеппман М.

• Паттерны объектно-ориентированного проектирования, Гамма Э., Хелм Р., Джонсон Р., Влиссидес Д.

• и, конечно, Чистая архитектура. Искусство разработки программного обеспечения, Мартин Р.

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

Безопасность — это важно. Также необходимым я считаю выделить безопасность. Часто именно с ней возникает наибольшее количество проблем. Рекомендую почитать про основные виды атак — например, Web Security Academy, там очень много про безопасность, и при этом бесплатно — и быть готовым, к примеру, дискутировать насчёт необходимости использования CSRF-токена.

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

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