Используем ИИ для подготовки к собеседованию

# План подготовки к собеседованию Senior Frontend (Vue.js + TS)

Стратегия подготовки: 10 часов, разбитых на 5 блоков. Упор на систематизацию, "подкапотную" работу и архитектуру.

---

## Блок 1: Глубокое погружение во Vue 3 и Архитектуру (2 часа)
*Цель: Показать понимание того, как работает реактивность, и умение строить масштабируемые приложения.*

### Теория (1 час)
*   **Reactivity System:** Как именно работает `Proxy` во Vue 3? Отличия `ref` vs `reactive` (deep vs shallow). Как работает Dependency Tracking?
*   **Composition API Patterns:** Паттерн "Composable" (hook) против Mixins (почему миксины плохи). Инверсия зависимостей через `provide/inject`.
*   **Architecture & FSD:** Изучить методологию **Feature-Sliced Design (FSD)** (упомянуто в вакансии как плюс). Слои: `app`, `pages`, `widgets`, `features`, `entities`, `shared`.
*   **State Management:** Pinia vs Vuex. Когда стейт-менеджер не нужен? (Ephemeral state vs Server state).

### Практика (1 час)
*   **Задача:** Спроектируйте (на бумаге или псевдокоде) архитектуру файловой структуры для интернет-магазина, используя принципы FSD.
*   **Кодинг:** Напишите сложный composable `useAsyncState`, который обрабатывает загрузку, ошибки и отмену запроса (AbortController), используя TypeScript Generics.

### Контрольные вопросы
*   *Чем `watchEffect` отличается от `watch`?*
*   *Как избежать потери реактивности при деструктуризации пропсов? (`toRefs`)*
*   *В чем плюсы и минусы FSD по сравнению с классической группировкой по типу файлов?*

---

## Блок 2: TypeScript (Strict) и Типизация Vue (2 часа)
*Цель: Доказать, что вы пишете типобезопасный код, который легко поддерживать.*

### Теория (45 мин)
*   **Utility Types:** `Pick`, `Omit`, `Partial`, `Record`, `ReturnType`.
*   **Advanced:** Generics, Discriminated Unions (очень важно для стейта), Type Guards (`is`), Type Narrowing.
*   **Vue + TS:** Типизация `props`, `emits`, `provide/inject`, типизация Pinia store.

### Практика (1 час 15 мин)
*   **Задача:** Создать компонент "Умная таблица" (Data Table). Она должна принимать массив объектов любого типа `<T>` и конфигурацию колонок, которая строго ссылается на ключи этого `T`.
*   **Рефакторинг:** Возьмите кусок JS-кода (например, обработка ответа API) и перепишите его на строгий TS с валидацией (можно использовать Zod, если знакомы, или просто Type Guards).

### Контрольные вопросы
*   *В чем разница между `interface` и `type`? Когда использовать `unknown` вместо `any`?*
*   *Как типизировать слот во Vue компоненте (Generic Components)?*

---

## Блок 3: Nuxt 3, SSR и Производительность (2 часа)
*Цель: Продемонстрировать знания серверного рендеринга и оптимизации (Core Web Vitals).*

### Теория (1 час)
*   **Rendering Modes:** SSR, CSR, SSG, ISR. В чем разница, когда что применять? Гидратация (Hydration) и проблемы с ней (Hydration Mismatch).
*   **Nuxt 3 Specifics:** `useAsyncData` vs `useFetch`. Server Routes (`/server/api`). Nitro Engine.
*   **Performance:**
    *   LCP (Largest Contentful Paint), CLS (Cumulative Layout Shift), INP (Interaction to Next Paint).
    *   Code Splitting (ленивая загрузка компонентов и роутов).
    *   Tree shaking.

### Практика (1 час)
*   **Аудит:** Откройте любой "тяжелый" сайт, запустите Lighthouse/Performance tab в DevTools. Найдите узкие места (Long Tasks, Layout Thrashing).
*   **Кодинг:** Напишите компонент, который загружает тяжелую библиотеку (например, для графиков или карт) только тогда, когда компонент попадает во viewport (`IntersectionObserver`).

### Контрольные вопросы
*   *Почему при использовании SSR нельзя обращаться к `window` или `document` в `setup`?*
*   *Как оптимизировать CLS при загрузке картинок или шрифтов?*

---

## Блок 4: Live Coding (Решение задач) (2.5 часа)
*Цель: Подготовиться к лайв-кодингу без алгоритмов (DOM, API, UI логика).*

### Типовые задачи для Senior Vue
1.  **Virtual Scroll:** Реализовать список из 100,000 элементов, который рендерит только видимую часть (без библиотек).
2.  **Tree View:** Рекурсивный компонент для отображения папок/файлов с возможностью сворачивания/разворачивания.
3.  **Debounced Search:** Поле ввода с автодополнением, кэшированием результатов и обработкой Race Conditions (когда второй запрос пришел раньше первого).
4.  **Modal Service:** Создать сервис для открытия модалок через JS (`openModal(component, props)`), используя `Teleport` и `h` (render function).

### Формат тренировки
*   Выберите 2 задачи.
*   Поставьте таймер на 30-40 минут.
*   Пишите код в чистом редакторе (или песочнице Vue SFC Playground), комментируя свои мысли вслух.

---

## Блок 5: System Design и Soft Skills (1.5 часа)
*Цель: Подготовиться к обсуждению опыта и проектированию систем.*

### Активности
1.  **System Design:** "Спроектируйте аналог Google Drive".
    *   *Фронтенд:* Как хранить состояние загрузки? Как реализовать Drag-n-Drop? Виртуализация списка файлов? Офлайн-режим?
2.  **Behavioral:** Подготовьте истории по методу **STAR** (Situation, Task, Action, Result):
    *   "Расскажите о самом сложном баге".
    *   "Как вы разрешили технический спор в команде?"
    *   "Пример неудачного архитектурного решения".
3.  **Code Review:** Представьте, что вы смотрите код джуниора. На что вы обратите внимание в первую очередь? (Безопасность, читаемость, перформанс).

# Блок 1: Глубокое погружение во Vue 3 и Архитектуру
**Время на выполнение:** ~2 часа
**Цель:** Освежить знания о внутренней работе Vue, разобраться с FSD и доказать умение писать сложные абстракции.

---

## Часть 1: Теория (1 час)

### 1. Система реактивности (Reactivity System)
Нужно четко понимать, как Vue отслеживает изменения. На собеседовании часто спрашивают "почему переменная изменилась, а компонент не перерендерился?".

*   **Что повторить:**
    *   **Proxy vs Object.defineProperty:** Почему Vue 3 перешел на Proxy? (Поддержка добавления свойств, массивов, Map/Set).
    *   **Ref vs Reactive:**
        *   `ref` везде? Или `reactive` для группировки? (Best practice: `ref` — стандарт де-факто для DX).
        *   Разница между `shallowRef` и `triggerRef` (оптимизация производительности).
    *   **Dependency Tracking:** Как работают `track` (get) и `trigger` (set).

*   **Материалы:**
    *   [Vue Docs: Reactivity in Depth](https://vuejs.org/guide/extras/reactivity-in-depth.html) — **Обязательно к прочтению**.
    *   [Vue Docs: Reactivity Fundamentals](https://vuejs.org/guide/essentials/reactivity-fundamentals.html) — Освежить нюансы `reactive()` limitations.

### 2. Composition API Паттерны
Переход от Options API к Composition API — это не просто смена синтаксиса, это способ переиспользования логики.

*   **Что повторить:**
    *   **Composables (Hooks):** Соглашения по именованию (`use...`), возврат refs.
    *   **Dependency Injection:** `provide` / `inject` с `InjectionKey` для строгой типизации. Как избежать "Prop Drilling".
    *   **Lifecycle Hooks:** Как они работают внутри `setup()`.

*   **Материалы:**
    *   [Vue Docs: Composables](https://vuejs.org/guide/reusability/composables.html)
    *   [Vuejs: Coding Better Composables](https://vueschool.io/articles/vuejs-tutorials/coding-better-composables-1-5-tips-to-write-better-composables/) (статья)

### 3. Архитектура Feature-Sliced Design (FSD)
Это стандарт для крупных фронтенд-проектов в СНГ. Показывает, что вы умеете мыслить модулями, а не просто "компонентами".

*   **Основные слои (снизу вверх):**
    1.  **Shared:** UI-кит, утилиты, API клиент (нет бизнес-логики).
    2.  **Entities:** Бизнес-сущности (User, Product, Cart).
    3.  **Features:** Действия пользователя (AddToCart, AuthByPhone).
    4.  **Widgets:** Самостоятельные блоки (Header, ProductList).
    5.  **Pages:** Страницы (композиция виджетов).
    6.  **App:** Глобальные настройки, роутинг, провайдеры.

*   **Правило:** Модуль может импортировать только "снизу", но не "сверху" или "сбоку" (из того же слоя).

*   **Материалы:**
    *   [FSD: Official Documentation](https://feature-sliced.design/)
    *   [FSD: Методология за 15 минут (Видео или статья)](https://habr.com/ru/articles/593575/)

---

## Часть 2: Практика (1 час)

### Задача 1: Архитектурное проектирование (FSD)
**Контекст:** Интернет-магазин электроники.
**Задание:** Напишите структуру папок (в виде дерева текста) для страницы "Карточка товара".

**Функционал страницы:**
1.  Отображение фото и характеристик товара.
2.  Кнопка "Добавить в корзину" (меняет состояние корзины).
3.  Блок "Похожие товары" (слайдер).
4.  Отзывы пользователей.

**Требование:** Распределите компоненты и логику по слоям: `pages`, `widgets`, `features`, `entities`, `shared`.

---

### Задача 2: Coding Challenge — `useAsyncState`
Напишите composable на TypeScript для выполнения асинхронных операций.

**Требования к реализации:**
1.  **Generics:** Функция должна быть типизирована. Принимает `Promise<T>` или функцию, возвращающую Promise.
2.  **Состояние:** Возвращает `{ state, isLoading, error, execute }`.
3.  **AbortController:** При повторном вызове `execute` предыдущий запрос должен отменяться (если он еще идет).
4.  **Options:** Принимает опциональный параметр `immediate: boolean` (запускать ли сразу).
5.  **Типизация:** `state` может быть `T | null`.

**Шаблон для старта:**
```typescript
import { ref, shallowRef } from 'vue';

type AsyncStateOptions = {
  immediate?: boolean;
}

export function useAsyncState<T>(
  promiseFactory: (signal: AbortSignal) => Promise<T>,
  options: AsyncStateOptions = {}
) {
  // Ваш код здесь
}
```

---

## Самопроверка (Чек-лист)
- [ ] Я могу объяснить разницу между `Ref` и `Reactive` на уровне реализации JS Proxy.
- [ ] Я понимаю, почему в FSD нельзя импортировать виджет в виджет.
- [ ] Я написал типизированный `useAsyncState` с отменой запроса.
- [ ] Я знаю, как типизировать `provide/inject`.

Извините за "битую" ссылку — видимо, я подставил ID другой статьи.

Я исправил файл `Блок_1_Vue_Architecture.md`, заменив ссылки на:
1.  **Официальную документацию FSD (на русском)** — это первоисточник, там всё изложено максимально точно.
2.  **Актуальную статью на Хабре** ("Разбираемся с FSD..."), которая хорошо объясняет концепцию.

Теперь материалы должны открываться корректно. Готовы переходить к следующему шагу или есть ещё вопросы по Блоку 1?

Отличный, структурированный ответ. Ты покрыл базу: переход на `Proxy`, механизм `track/trigger`, решение проблем Vue 2 (добавление свойств, работа с коллекциями) и оптимизацию через `shallow`. Это уверенный уровень Middle+/Senior.

Чтобы ответ звучал на "Strong Senior", я бы добавил (или был готов ответить на доп. вопросы) пару нюансов:
1.  **Ref vs Proxy:** `ref` для примитивов технически работает через геттеры/сеттеры (класс `RefImpl`), так как примитив нельзя обернуть в Proxy. Proxy включается только когда в `ref` кладут объект.
2.  **WeakMap:** Зависимости хранятся в `WeakMap` (где ключ — сам объект `target`), чтобы не мешать сборщику мусора очищать память, когда объект больше не используется.

Давай проведем **блиц-проверку** по "скользким" моментам реактивности, на которых часто ловят:

**Вопрос 1 (Деструктуризация):**
У нас есть код:
```javascript
const state = reactive({ count: 0, user: { name: 'Alex' } });
const { count, user } = state;
```
Почему `count` потеряет реактивность при изменении, а `user.name` — нет (если изменить `state.user.name`)? И как правильно деструктурировать `state`, чтобы сохранить реактивность?

**Вопрос 2 (Unwrapping):**
Почему в шаблоне (template) мы пишем `{{ count }}`, а не `{{ count.value }}`, а в скрипте обязаны писать `.value`? И что произойдет, если я положу `ref` внутрь `reactive` объекта — нужно ли будет писать `.value` при доступе к нему?

Попробуй ответить на эти два вопроса. Это закроет теоретическую часть по реактивности.

Решение хорошее, демонстрирует понимание асинхронности и Composition API.

**Плюсы:**
1.  **AbortController:** Логика отмены реализована верно. Отменяется предыдущий, создается новый, и результат игнорируется, если сигнал `aborted`.
2.  **Типизация:** Использованы дженерики `<T>`, корректно типизирован `error`.
3.  **Race Conditions:** Обработка `isLoading` и игнорирование результата при отмене (`if (signal.aborted)`) защищает от состояния гонки.

**Что можно улучшить (Feedback для Senior уровня):**

1.  **Проблема с `Promise`:**
    В сигнатуре `PromiseOrFactory<T>` разрешен просто `Promise<T>`.
    ```typescript
    type PromiseOrFactory<T> = Promise<T> | ((signal: AbortSignal) => Promise<T>);
    ```
    *Проблема:* Если передать уже созданный `Promise` (не функцию), его **нельзя отменить** (у него нет сигнала) и его **нельзя перезапустить** (он уже зарезолвлен или в процессе). Метод `execute` при повторном вызове будет просто ждать тот же самый промис.
    *Рекомендация:* Для переиспользуемого `useAsyncState` лучше принимать *только* фабрику `() => Promise`. Если нужно обрабатывать "уже запущенный" промис, это другой кейс (обычно `usePromise`).
    *Как исправить:* Оставить только `(signal: AbortSignal) => Promise<T>` в аргументах.

2.  **Обработка `AbortError`:**
    ```typescript
    } catch (err) {
      if (signal.aborted) return; // ...
    ```
    Это правильный код, но стоит помнить, что `fetch` при отмене кидает специфическую ошибку `AbortError`. В некоторых реализациях хорошим тоном считается прокидывать ошибку дальше, если это *не* ошибка отмены. Но для UI-хука "молчаливое" игнорирование отмены (как у тебя) — это правильное поведение.

3.  **Утечка памяти (Memory Leak) в `onUnmounted`:**
    Если компонент демонтируется (пользователь ушел со страницы), а запрос висит — он продолжит висеть и потом попытается обновить `state.value`, что может (в редких случаях) привести к ворнингам или лишней работе.
    *Рекомендация:* Добавить автоматическую отмену при анмаунте.

    ```typescript
    import { onUnmounted } from 'vue';
    // ... внутри функции ...
    onUnmounted(() => {
      if (abortController) abortController.abort();
    });
    ```

4.  **ShallowRef:**
    Ты использовал `shallowRef` для `state`. Это **отлично** для производительности, если `state` это большой массив или сложный объект, который мы меняем целиком. Это показывает знание оптимизаций.

**Итоговая оценка:** 8/10. Если добавить `onUnmounted` и убрать поддержку "голого" Промиса (оставив только фабрику) — будет идеальное Senior-решение.

Хочешь доработать код с учетом `onUnmounted` или перейдем к вопросу про архитектуру (FSD) и задачу с деревом файлов?

Принято. Это отличный способ закрепить нюансы. Буду давать задачи "с подвохом", которые часто встречаются на Senior собеседованиях.

### Задача 1: "Загадочный `watch`"

Представь, что у нас есть такой код компонента. Мы хотим отслеживать изменение свойства `count` в объекте `state`.

```typescript
const state = reactive({
  count: 0,
  data: { value: 10 }
});

// Вариант А
watch(state.count, (newVal) => {
  console.log('А сработал:', newVal);
});

// Вариант Б
watch(() => state.count, (newVal) => {
  console.log('Б сработал:', newVal);
});

state.count++;
```

**Вопрос:** Какой из вариантов (`А` или `Б`) сработает? Какой выдаст ошибку или предупреждение? Почему?

### Итоги по Блоку 1 (Vue Reactivity & Architecture)

**Твои результаты:**
1.  **Reactivity Fundamentals:** Отлично. Понимаешь Proxy, `track/trigger`.
2.  **Destructuring:** Отлично. Не путаешься в примитивах vs объектах.
3.  **Unwrapping (Ref in Reactive):** Есть пробел с коллекциями (`Map`, `Array`). Запомни: unwrap только в объектах по ключу.
4.  **Shallow APIs:** Отлично.
5.  **Readonly:** Отлично.

**Общая оценка:** Strong Senior (с маленькой помаркой по коллекциям, что простительно, так как редко используется).

**Рекомендация:**
Запомни кейс с `Map/Set` — это любят спрашивать, чтобы проверить глубину знаний ("а что если не просто объект, а Map?").