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

1️⃣ Что такое специфичность в CSS?

2️⃣ Расскажи про SCSS-миксины для медиа-запросов

3️⃣ Использовал сложные функции в SCSS и полифилы?

4️⃣ Как обеспечивается кросс-браузерная поддержка CSS?

5️⃣ Какие архитектуры CSS знаешь и какая нравится больше?

6️⃣ Чем отличаются способы объявления переменных в JS?

7️⃣ Какие способы копирования объекта в JS?

8️⃣ Как организована работа с асинхронным кодом в JS?

9️⃣ Какие браузерные хранилища существуют?

1️⃣0️⃣ Какие уязвимости знаешь и как с ними борешься?

1️⃣1️⃣ Как защититься от XSS?

1️⃣2️⃣ Какими React-хуками пользуешься чаще всего?

1️⃣3️⃣ Чем отличаются useMemo и useCallback?

1️⃣4️⃣ Что такое дженерики в TypeScript?

1️⃣5️⃣ Чем отличаются interface и type в TypeScript?

1️⃣6️⃣ Найди ошибки и реализуй компонент для отображения древовидной структуры:

import React from "react";

const exampleFiles = [
  {
    id: 1,
    name: 'src',
    children: {        
      {
        id: 2, name: 'components', children: [
          { id: 3, name: 'Button.tsx', children: [] }
        ],
      },
      { id: 4, name: 'index.ts', children: [] }
    }
  },
  {
    id: 5,
    name: 'README.md',
    children: []
  }
];

const FileStructure = () => {
  return (
    <div>
      {/* Отобразить дерево */}
    </div>
  )
}

export default FileStructure;

*********** Решение: ***********

const exampleFiles = [
  {
    id: 1,
    name: "src",
    children: [ 
      {
        id: 2,
        name: "components",
        children: [{ id: 3, name: "Button.tsx", children: [] }],
      },
      { id: 4, name: "index.ts", children: [] },
    ],
  },
  { id: 5, name: "README.md", children: [] },
];

const TreeNode = ({ node }) => (
  <li>
    {node.name}
    {node.children.length > 0 && (
      <ul>
        {node.children.map((child) => (
          <TreeNode key={child.id} node={child} />
        ))}
      </ul>
    )}
  </li>
);

const FileStructure = () => (
  <ul>
    {exampleFiles.map((node) => (
      <TreeNode key={node.id} node={node} />
    ))}
  </ul>
);

export default FileStructure;
******************** Разбор ********************
1. TreeNode — рекурсивный компонент: вызывает сам себя для каждого дочернего узла
​2. Базовый случай рекурсии (условие остановки) — children.length > 0
​3. Не забываем про key

1️⃣7️⃣ Виртуализация списков — зачем нужна и как реализуется?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Целью звонка было получить прямой фидбэк от рекуртеров, не перемешивая мнение с менторами или мной, поэтому ответы на вопросы дальше — это чистое мнение HR по поводу рынка и ответы на вопросы.

Отклики и перепиcки можно автоматизировать скриптами или через браузер Comet. Не обязательно делать это руками и тратить свое время.

Если вы ниже 100-й позиции в выдаче на hh — рекуртеры будут меньше писать. Желательно пользоваться фишкой выше чтобы постоянно быть в выдаче.

Фото и фон можно чуть подредачить в Photoshop/нейронкой. Не обязательно идти в студию)

Все сложные вопросы с оформлением, зарплатой лучше обсуждать на финальном этапе.

Сами проекты и их сложность рекуртеры не смотрят.