Оффер сразу после мок собеса / Собеседование Frontend React
Запись слепого мок-собеседования Frontend React-кандидата с техническими вопросами, задачей на исправление React-компонента и обсуждением командной работы. В конце интервьюер даёт субъективную оценку уровня и разбирает ответы кандидата.
Это мок-собеседование на позицию Middle Frontend-разработчика: интервьюер не знает резюме и стаж Дмитрия, а проверяет JavaScript, CSS, TypeScript, React, практическое исправление компонента и поведенческие ответы. Кандидат уверенно отвечает на значительную часть вопросов, но получает подсказки и корректировки по позиционированию в CSS, параметрам TypeScript и зависимостям useEffect с мутируемыми объектами. В финале Айнур субъективно оценивает кандидата как Middle+ и говорит, что взял бы его в рамках эксперимента; это не реальный оффер или решение конкретной компании.
Формат намеренно исключает стаж и резюме: технический уровень оценивают по рассуждению о JavaScript, CSS, TypeScript, React и по работе с проблемным кодом.
Для справочника «английское название города → русское» обсуждают предварительное преобразование массива в Map или объект, чтобы получать значение по ключу за O(1), а не каждый раз линейно искать в массиве.
В TypeScript важно различать необязательный параметр `arg?: string` и обязательный параметр типа `string | undefined`: второй нужно передать при вызове, пусть даже со значением `undefined`.
Ручные DTO для контрактов фронтенда и бэкенда полезны, но интервьюер советует генерировать TypeScript-типы из спецификации API, чтобы контракт не расходился из-за человеческого фактора.
При `useEffect` объект в массиве зависимостей сравнивается по ссылке; мутация вложенного поля без новой ссылки не даёт ожидаемого срабатывания. В разговоре рассматривают сериализацию и deep compare как варианты, но кандидат не формулирует готовое решение сразу.
В практической React-задаче нужно починить добавление, удаление и переключаемую сортировку списка, затем разделить ввод и список на компоненты, чтобы ввод не перерисовывал независимый список.
Для списка нужны устойчивые уникальные ключи, а поле ввода с кнопками логично оформить как форму; индекс допустим лишь в статичном списке без перестановок.