Компания: МТС Веб-сервисы
Позиция: Middle+ Frontend (Vue), 200–280K 💚

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

Вопрос №1

Какой подход ты выбирал при миграции с Vue 2 на Vue 3?

Слабый ответ:

«Постепенно переписать всё на Vue 3 + TypeScript через Vue 2.7».

Ответ технически корректный, но слишком общий. В нём нет главного: как именно шла миграция, почему был выбран такой путь и как контролировались риски.

Сильный ответ:

Я выбирал поэтапную миграцию. Обычно сначала выделяли участки с понятными границами: отдельные страницы, фичи или модули с минимальной связанностью с legacy-частью. Это позволяло мигрировать систему постепенно и не останавливать продуктовую разработку.

На первом этапе выравнивали базу под миграцию: убирали самые проблемные места, снижали зависимость от mixins, выносили бизнес-логику из компонентов, наводили порядок в слоях данных и состояниях. После этого уже переводили части приложения на Composition API и TypeScript.

Такой подход давал несколько преимуществ:
— меньше риск сломать всё сразу
— проще локализовать ошибки
— можно катить изменения частями
— команда продолжает поставлять фичи параллельно с миграцией

В общем, “мигрировали итеративно, с контролем технического риска”.

Что здесь реально проверяют:
умеешь ли ты планировать сложные изменения, а не просто знаешь, что Vue 3 новее Vue 2.

Вопрос №2

Какие архитектурные улучшения были в проекте и как они применялись — поверх или во время миграции?

Слабый ответ:

«По большей части во время миграции. С монолита на модульную архитектуру».

Это не ошибка, но ответ слишком короткий. Он не раскрывает, что именно менялось в архитектуре и зачем.

Сильный ответ:

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

Например, если система была слишком монолитной, то в процессе миграции мы начинали разрезать её на более понятные модули или доменные зоны: отдельно выделяли UI-слой, работу с данными, бизнес-логику, сторы, API-клиенты. Это снижало связанность и делало код предсказуемее.

Также обычно пересматривали:
— структуру модулей и границы ответственности
— организацию состояния
— слой работы с API
— переиспользуемую логику
— общие UI-примитивы и паттерны композиции

То есть миграция была не отдельной задачей “обновить Vue”, а точкой входа для нормализации архитектуры.

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

Вопрос №3

Что ты считаешь важным знанием или навыком при работе с Vue?

Слабый ответ:

«Знание синтаксиса, новых фич, Teleport, Suspense, Composition API, composables, Vapor...»

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

Сильный ответ:

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

Во-вторых, важно понимать композицию приложения: где должна жить бизнес-логика, что оставить в компоненте, что вынести в composable, а что вообще должно быть на уровне сервисов или data layer. Именно это отличает поддерживаемый проект от набора компонентов, которые “как-то работают”.

В-третьих, важно понимать рендеринг и производительность:
как работают обновления, что даёт правильная декомпозиция, где появляются лишние перерендеры, как влияют вычисления в шаблоне, watchers, асинхронные компоненты, lazy loading, SSR и hydration.

И уже после этого идут сами фичи фреймворка: Composition API, Suspense, Teleport и экосистема вокруг Vue.

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

===================

Если нужен полный список задач, которые спрашивали в МТС, ставь 🔥

На связи тут @codepunks_bro