# Middle → Senior Frontend: компетенції, докази й план росту на 90 днів

> Що насправді відрізняє Senior від Middle: технічна глибина, компроміси, ownership і комунікація. Skill matrix для самооцінки, як збирати докази росту і реалістичний план на 90 днів.

- Автор: Юра Скиба (https://cookiesoftware.io)
- Опубліковано: 2026-09-24
- Категорія: Співбесіди та кар’єра
- Canonical: https://cookiesoftware.io/blog/middle-to-senior-frontend

---

**Коротка відповідь.** Senior – це не «Middle плюс три роки стажу» і не знання ще п'яти бібліотек. Це зміна масштабу відповідальності: ти відповідаєш не за задачу, а за результат; не за свій код, а за якість рішень команди; не за «працює», а за «працює, підтримується і не стріляє в ногу через пів року». Нижче – з чого складається цей перехід, як чесно оцінити себе і що робити наступні 90 днів.

## «Senior» означає різне в різних командах

Почнімо з незручної правди: єдиного стандарту Senior не існує. У продуктовій компанії з двома фронтендерами Senior – це людина, яка сама тримає весь фронтенд. У великій компанії з сотнею інженерів – та, що впливає на рішення кількох команд. В аутсорсі – та, кого не страшно поставити перед клієнтом.

Тому перший крок – не універсальний роадмап, а питання: **Senior де саме?** Відкрий 5–7 вакансій рівня Senior у компаніях, куди ти реально хочеш, і випиши вимоги, що повторюються. Це твій орієнтир, а не список зі статті (включно з цією).

Попри різницю, є ядро, яке повторюється майже скрізь. Його і розберемо.

## Технічна глибина: не «більше інструментів», а «розумію чому»

Middle знає, **як** зробити. Senior розуміє, **чому саме так** – і коли робити інакше.

Практична різниця на прикладах:

- Middle: «використовую `useMemo`, щоб не було зайвих обчислень». Senior: «спочатку виміряв у Profiler, знайшов реальне вузьке місце, і лише тоді мемоізував – бо мемоізація сама має ціну».
- Middle: «підключив React Query, бо всі так роблять». Senior: «нам потрібні кешування і синхронізація серверного стану, і ось чому вбудованих засобів не вистачило».
- Middle: «тести написані». Senior: «тестова стратегія така: критична бізнес-логіка покрита юнітами, ключові флоу – інтеграційними, і ось що ми свідомо не тестуємо».

Помітна закономірність: у кожній парі Senior-версія містить **компроміс і його ціну**. Уміння сказати «це рішення коштує нам X, зате дає Y, і в нашому контексті це виправдано» – найбільш упізнавана ознака рівня. Детальніше про те, як аргументувати архітектурні рішення на співбесіді, є окремий розбір: [React-архітектура для Senior](/blog/senior-react-architecture).

## Code review: з «перевіряють мене» на «росту через ревʼю інших»

На рівні Middle ревʼю – це те, що проходять. На рівні Senior – інструмент, яким піднімають планку команди.

Що змінюється на практиці:

1. **Дивишся на рішення, а не на стиль.** Форматування ловить лінтер; твоя робота – помітити проблему з межами компонентів, стан, який житиме не там, де треба, відсутній edge case.
2. **Пояснюєш «чому», а не лише «що».** Замість «перенеси в окремий хук» – «ця логіка вже дублюється у двох місцях, третє буде за тиждень; винесемо зараз, поки дешево».
3. **Розрізняєш блокер і смак.** Senior явно позначає: це треба виправити до мержа, а це – моя думка, вирішуй сам. Команди, де кожен коментар – блокер, рухаються повільно й нервово.

Якщо у твоїй команді нема сильного ревʼю і рости нема від кого – це вирішувано: [як працює code review з ментором](/blog/code-review-z-mentorom).

## Ownership: відповідальність за результат, а не за задачу

Ownership – заїжджене слово, тому конкретизуємо через поведінку:

- Задача заблокована відповіддю від бекенду. Middle чекає. Senior пише в тред, пропонує контракт API, домовляється про мок і розблоковує себе й команду.
- Реліз пройшов, але метрика просіла. Middle: «моя частина працює». Senior лізе в моніторинг, бо результат фічі – це і є його робота.
- У коді жила стара болячка, всі про неї знали. Senior не обов'язково лагодить сам – але заводить тікет, оцінює вартість і доносить до того, хто пріоритезує.

Жоден із цих пунктів не потребує дозволу чи титулу. Саме тому найнадійніший шлях до підвищення – **спочатку поводитися як Senior, потім отримати лейбл**, а не навпаки.

## Комунікація: рішення, які пережили обговорення

Senior-інженера видно в тому, як він пише і говорить:

- Пропозиція зміни – це не «давайте перепишемо на X», а короткий документ: проблема → варіанти → рекомендація → ціна.
- Незгода з рішенням – аргументи в обговоренні, а після ухвалення – підтримка рішення команди, навіть якщо обрали не твій варіант.
- Статус без нагадувань: люди, що залежать від тебе, дізнаються про ризик зриву терміну від тебе, а не з факту зриву.

Це навички, які тренуються так само, як код: наступний design-документ напиши за структурою вище і попроси фідбек.

## Skill matrix: інструмент рефлексії, не прохідний бал

Таблиця нижче – для чесної самооцінки. Це не стандарт індустрії і не чекліст найму: у твоїй компанії акценти будуть іншими. Мета – знайти 2–3 виміри, де розрив найбільший.

| Вимір | Типова Middle-поведінка | Типова Senior-поведінка |
|---|---|---|
| Постановка задачі | Бере готову задачу з тікета | Уточнює проблему, іноді змінює саму постановку |
| Архітектура | Слідує чинним патернам проєкту | Пропонує зміни патернів і аргументує ціну |
| Якість | Пише тести до свого коду | Формує тестову стратегію частини продукту |
| Перформанс | Виправляє, коли повільно | Закладає бюджети й міряє до того, як стало повільно |
| Ревʼю | Проходить ревʼю | Піднімає рівень команди через ревʼю |
| Комунікація | Відповідає, коли питають | Проактивно знімає ризики й розблоковує інших |
| Вплив | Своя задача | Результат фічі / напряму |

Оціни кожен рядок за трьома станами: «ще ні», «іноді», «системно». Прогалини зі стовпця «системно» – і є твій план.

## Докази: підвищення не відбувається у твоїй голові

Поширений сценарій: людина реально працює на Senior-рівні, але на перформанс-ревʼю це неможливо показати, бо доказів ніхто не збирав. Рішення просте й нудне – **brag document**: один файл, куди щотижня дописуєш 2–3 рядки.

Що записувати: рішення, які ти запропонував і які ухвалили; інциденти, які ти зловив або розрулив; людей, яким допоміг (онбординг, ревʼю, менторинг); метрики до/після твоїх змін. Через пів року в тебе буде не «я ніби виріс», а конкретний список для розмови про підвищення – або сильні пункти для CV, якщо рости доведеться через зміну компанії.

## План на 90 днів

Реалістичний, без «стань іншою людиною за квартал»:

**Дні 1–14 – діагностика.** Заповни skill matrix; збери вимоги з 5–7 реальних Senior-вакансій; обери 2–3 виміри з найбільшим розривом. Заведи brag document.

**Дні 15–60 – системна практика.** Один робочий приклад на тиждень у кожному з обраних вимірів: написав design-документ; провів глибоке ревʼю з поясненнями «чому»; сам виміряв і полагодив перформанс-проблему; розблокував чужу задачу. Кожен приклад – рядок у brag document.

**Дні 61–90 – перевірка ззовні.** Домов про пряму розмову з менеджером: «що мені бракує до Senior у нашій команді конкретно?» Порівняй відповідь зі своєю самооцінкою. Пройди [mock interview](/blog/mock-interview-yak-prokhodyt) рівня Senior – зовнішня перевірка знімає ілюзії в обидва боки. За потреби додай глибини в системному дизайні: [frontend system design](/blog/frontend-system-design-interview).

## Типові помилки на цьому переході

1. **Вчити ще один фреймворк замість глибини.** Список технологій у CV не робить Senior; глибина в наявному стеку – робить.
2. **Чекати, поки «дадуть» відповідальність.** Її беруть: пункти з розділу про ownership не потребують дозволу.
3. **Рости мовчки.** Без brag document і розмов із менеджером твій ріст невидимий.
4. **Плутати Senior із «роблю все сам».** Навпаки: що вищий рівень, то більше результату ти створюєш через інших – ревʼю, менторинг, рішення.
5. **Порівнювати себе з абстрактним ідеалом.** Порівнюй із вимогами конкретних команд, куди хочеш.