Коротка відповідь. 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.

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

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

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

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

Якщо у твоїй команді нема сильного ревʼю і рости нема від кого – це вирішувано: як працює code review з ментором.

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 рівня Senior – зовнішня перевірка знімає ілюзії в обидва боки. За потреби додай глибини в системному дизайні: frontend system design.

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

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