Какие задачи на собеседовании тебе нравятся и какие пригодятся в работе?

Что проверяют

Есть ли у вас осознанная позиция и умеете ли вы отличать задачи для собеседования от задач в работе. Вопрос часто задают тем, кто сам будет собеседовать, и следом спрашивают: «а какую задачу вы бы дали кандидату на нашу позицию?».

Как отвечать

Назовите конкретный тип задач, объясните, почему он вам нравится, и честно сопоставьте с работой:

• алгоритмические в духе LeetCode: тренируют мысль о сложности и граничных случаях, но в ежедневной фронтенд-работе встречаются редко. Полезны на уровне хэш-таблиц, обходов и O(n) против O(n²) на больших списках;
• практические на JS: debounce, throttle, свой Promise.all, глубокое копирование. Это прямо переносится в работу, и видно, понимает ли человек замыкания и асинхронность;
• event loop: порядок вывода с setTimeout, промисами и queueMicrotask. Полезны, если за ними следует разговор о том, почему подвисает интерфейс;
• задача на компонент: список с загрузкой, состоянием ошибки и отменой запроса через AbortController. Самая близкая к жизни: гонки запросов, лишние ререндеры, устаревшее замыкание в useEffect;
• ревью кода и поиск бага: формат, который часто недооценивают. Он показывает, как человек читает чужой код, а в работе этим заняты не меньше, чем написанием своего;
• фронтенд system design: как устроить ленту с виртуализацией, кэшем и оптимистичными обновлениями.

Хороший ответ звучит примерно так: «больше всего люблю задачи на компонент с асинхронностью, на них видно реальное мышление; алгоритмика полезна, но в меру». Опирайтесь на свои собеседования: какая задача запомнилась и чему научила.

Где спотыкаются

Ругают алгоритмические задачи целиком. Это звучит как оправдание, особенно если следом дадут именно такую.

Отвечают про рабочие задачи вообще: «люблю верстать интерфейсы и оптимизировать». А вопрос про формат собеседования.

Говорят, что им нравится всё. Позиции нет, и интервьюеру нечего обсуждать дальше.