Від нуля до Senior — чесний шлях навчання
Побудовано навколо 4 треків і 5 рівнів, з реалістичними строками, конкретними проєктами та помилками, які роблять усі. Кожен крок посилається на курси і статті, з якими можна працювати вже цього тижня.
Ще не знаєте, який шлях обрати?
Оберіть одну з двох стартових точок до того, як зафіксуватися на треку.
Оберіть свій трек
Чотири дуже різні роботи. Оберіть ту, що пасує до того, як ви хочете проводити робочий день. Змінити можна потім — більшість інженерів так і роблять раз-два.
Розробка фронтенду
~2.5–4 роки (Початковий → Senior)
Розробка бекенду
~3–5 років (Початковий → Senior)
Наука про дані та машинне навчання
~3–5 років (Junior → Senior — Data рідко стартує з Beginner)
DevOps / SRE
~4–6 років сумарно (у DevOps зазвичай ідуть після 1–2 років backend або sysadmin)
Розробка фронтенду
~2.5–4 роки (Початковий → Senior)
Початківець
Зазвичай: 4–8 тижнів Джерело: Stack Overflow Developer Survey →
Початківець
Зазвичай: 4–8 тижнів Джерело: Stack Overflow Developer Survey →
Які навички ви освоїте
- Основи HTML та CSS
- Основи JavaScript
- Маніпуляція DOM
- Адаптивний дизайн
Ви готові до наступного рівня, коли
- Зробили з нуля сайт-портфоліо з 1–2 сторінок і задеплоїли (Vercel / Netlify підійдуть)
- Спокійно читаєте і правите HTML/CSS у DevTools браузера
- Можете написати обробник кліку на vanilla JS без копіпасту
- Сайт нормально виглядає на телефоні — розумієте box model і flexbox
- Запушили код на GitHub і репо не викликає у вас сорому
Що побудувати
Конкретні проєкти — і що саме вони вас навчать.
- Персональний сайт-портфоліо (навчить: деплой, адаптивність, базовий JS)
- Невелика landing-сторінка, що завантажує і показує дані з API (навчить: fetch, async, рендеринг DOM)
Пройдіть ці курси
Вступ до HTML & CSS
Вивчайте основи HTML та CSS і створюйте сучасні адаптивні вебсторінки з нуля.
Вступ до HTML5 та CSS3
Вивчайте сучасні стандарти HTML5 та CSS3: семантичну розмітку, Canvas, мультимедіа, WebSockets, WebStorage, анімації, трансформації та адаптивний дизайн.
Вступ до JavaScript
Вивчайте JavaScript з нуля: синтаксис, логіку, масиви, функції, об’єкти, події, DOM, AJAX та збереження даних на клієнті. Надійний фундамент для фронтенд-розробки.
Прочитайте
Глибокого розбору для цього рівня поки немає. Відкрити весь блог →
Поширені помилки на цьому етапі
- Витрачати 6 місяців на туторіали, не побудувавши нічого справжнього — tutorial hell тут вбивця №1
- Пропускати основи CSS, бо "Tailwind розбереться" — пошкодуєте на першому нетривіальному лейауті
- Дивитися туторіали по React, ще не вміючи написати обробник кліку на vanilla JS
- Ставитися до сайту-портфоліо як до одноразового — це артефакт, за яким вас будуть наймати
Що компанії очікують на цьому рівні
- Портфоліо з 2–3 проєктів, що клонуються і запускаються з вашого GitHub
- HTML/CSS, написані без StackOverflow на співбесіді зі скриншерингом
- Впевненість у DevTools браузера — inspect, console, network
- Базовий Git: clone, branch, commit, push. Просунуте вивчите на роботі.
Молодший
Зазвичай: 3–6 місяців Джерело: Stack Overflow Developer Survey →
Молодший
Зазвичай: 3–6 місяців Джерело: Stack Overflow Developer Survey →
Які навички ви освоїте
- Основи React
- Життєвий цикл компонента
- Основи керування станом
- Інтеграція з API
Ви готові до наступного рівня, коли
- Запустили React-додаток з 3+ компонентами, інтеграцією з реальним API і живим URL
- Можете пояснити різницю useState та useEffect своїми словами — без жаргону
- Впевнено читаєте джерела бібліотек на GitHub, навіть якщо не все розумієте
- Хоча б раз працювали в командному Git-флоу: branch, PR, відповіді на review
- Прочитали хоча б одну статтю типу "Коли НЕ варто використовувати AI" і маєте обґрунтовану думку
Що побудувати
Конкретні проєкти — і що саме вони вас навчать.
- Невеликий React-додаток, що працює з реальним публічним API (навчить: компоненти, стан, fetch, обробка помилок)
- За вихідні перепишіть своє початкове портфоліо на React + TypeScript (навчить: рефакторинг, типи, навіщо потрібен JSX)
Пройдіть ці курси
React.js: основи
Створюйте сучасні інтерактивні UI з React. Вивчайте компоненти, хуки, управління станом, маршрутизацію, API інтеграцію та деплой реальних проектів. Наступний крок після JavaScript.
TypeScript: майстерність
Від JavaScript до production-рівня TypeScript. Система типів, дженерики, декоратори, strict mode, розширені utility types та інтеграція TypeScript у реальних проектах.
Поширені помилки на цьому етапі
- Міняти фреймворк кожні 2 тижні (Vue → React → Svelte → Solid → ...) — оберіть один і довезіть щось до кінця
- Сприймати TypeScript як "просто JS з типами" — справжня цінність у дисципліні проєктування
- Не вчити базу платформи (event loop, делегування подій, рендеринг браузера)
- Будувати лише TODO-додатки. Зробіть щось із серверними даними та чужим API.
Що компанії очікують на цьому рівні
- Хоча б один задеплоєний React-додаток, який ви розумієте від і до — і можете пояснити на співбесіді
- Впевненість хоча б в одному підході до CSS (Tailwind / CSS modules / styled-components)
- Читання документації — це ваш дефолтний крок при затинанні, а не питання команді
- Ви можете пояснити, ЧОМУ обрали бібліотеку, а не просто "я її використав"
Середній рівень
Зазвичай: 6–12 місяців Джерело: Stack Overflow Developer Survey →
Середній рівень
Зазвичай: 6–12 місяців Джерело: Stack Overflow Developer Survey →
Які навички ви освоїте
- Просунуті патерни React
- Оптимізація продуктивності
- Тестування (Jest, React Testing Library)
- Інструменти збірки (Webpack, Vite)
Ви готові до наступного рівня, коли
- На роботі або реальному проєкті довели фічу з нуля: вимоги → дизайн → ship → багфікси
- Відрефакторили чужий React-компонент так, що нічого не зламалось (і команда подякувала)
- Вмієте дебажити performance через Chrome DevTools — Profiler, Network, Coverage
- Рев'юїли PR в справжній команді, і ваші рев'ю — не тільки nitpick'и
- Маєте думку про state management, яку можете захистити кодом, а не відчуттями
Що побудувати
Конкретні проєкти — і що саме вони вас навчать.
- Повнофункціональний SPA з авторизацією, роутингом, optimistic UI та реальною тестовою пірамідою (навчить: ship на production-рівні)
- Невелика бібліотека багаторазових компонентів + Storybook (навчить: дизайн API, доступність, документація)
Прочитайте
-
AI-інструменти, які має використовувати кожен розробник у 2025
Не хайп-список. Практичний розбір того, які AI-інструменти реально економлять час, які — крадуть, і як побудувати воркфлоу, що робить вас вимірно швидшими.
-
Claude Code у production: чого я навчився за 6 місяців
Пів року Claude Code як основного інструменту — які воркфлоу реально економлять час, які тихо його з'їдають, і яку конфігурацію більшість команд так і не налаштовують.
-
Контекст-інжиніринг: дисципліна, яка у 2026 році замінює prompt engineering
Prompt engineering ніколи не був справжнім умінням. Після двох років у продакшені з AI-фічами скажу прямо: на результат впливає інше — контекст-інжиніринг. Стан, інструменти, пошук, історія та обмеження, зібрані у вікні моделі в потрібну мить. Архітекторський погляд.
-
Від C# до AI-агентів: шлях .NET-розробника до розробки на Claude
Ви вже знаєте C#, ASP.NET Core та вмієте запускати production-бекенди. Ось як перевикористати ці навички для серйозних AI-агентів на Claude — не викидаючи свій стек.
Поширені помилки на цьому етапі
- Over-engineering: Redux store + saga middleware для тристорінкового додатка
- Взяти нову бібліотеку замість написання 30 рядків простого коду
- Не писати тести, бо "це ж фронтенд" — фронтенд-баги найпомітніші для користувача
- Стати "тільки React-розробником" — стеки змінюються, вчіть платформу, HTTP, браузер
Що компанії очікують на цьому рівні
- Сильний React + TypeScript, але без поклоніння React — можете перейти на інший фреймворк, якщо команді потрібно
- Здоровий інстинкт тестування: unit + integration, в ідеалі — пара e2e на критичні сценарії
- Можете спроєктувати невелику фічу без сеньора за плечем
- Адекватний code review — конструктивно пушбекаєте погані PR
Старший
Зазвичай: 1–2 роки
Старший
Зазвичай: 1–2 роки
Які навички ви освоїте
- Проєктування фронтенд-архітектури
- Масштабування продуктивності
- Лідерство команди
- Рішення з системного дизайну
Ви готові до наступного рівня, коли
- Спроєктували frontend-архітектуру для нетривіального продукту (від 3 інженерів на ній)
- Зробили технологічний вибір, який команда все ще використовує через рік — і вмієте пояснити, чому
- Провели junior'а або mid-інженера через реальне плато росту
- Перестали писати тикети "бо хочу" — пишете, бо це правильний наступний крок
- Комфортно сказати "ця ідея неправильна" PM'у або дизайнеру, обґрунтовано
Що побудувати
Конкретні проєкти — і що саме вони вас навчать.
- Проєктування масштабованої frontend-архітектури для мульти-командного продукту (навчить: межі модулів, build-пайплайни, володіння design system)
- Провести frontend-команду через критичну міграцію (навчить: планування, trade-offs, менторинг під тиском)
Прочитайте
-
Контекст-інжиніринг: дисципліна, яка у 2026 році замінює prompt engineering
Prompt engineering ніколи не був справжнім умінням. Після двох років у продакшені з AI-фічами скажу прямо: на результат впливає інше — контекст-інжиніринг. Стан, інструменти, пошук, історія та обмеження, зібрані у вікні моделі в потрібну мить. Архітекторський погляд.
-
Evals у 2026: тест-сьют для систем, які не детерміновані
Ваша AI-фіча працювала вчора і ламається сьогодні. Ні код, ні промпт, ні модель не змінювалися. Так виглядає життя без evals. Це третя опора тріади spec → context → evals — і дисципліна, яку більшість команд пропускає.
-
OpenSpec у 2026: операційна система spec-driven development
Шість тижнів тому я поставив @fission-ai/openspec. Учора відвантажив зміну на чотирнадцять файлів за дев'яносто хвилин зі двохсотрядкової специфікації, у brownfield-кодовій базі, яку троє інженерів правлять два роки — без мерж-конфліктів, без ескалацій рев'ю. Це сеньорний архітектурний розбір того, чому OpenSpec — перший SDD-інструмент, який не розвалюється під продакшен-реальністю.
-
Як пройти System Design співбесіду: плейбук senior-інженера
Більшість порад щодо system design — теоретичний шум. Це повторюваний фреймворк, який я використовую для оцінки кандидатів — і яким ви можете користуватися, щоб пройти будь-яку system design співбесіду на mid або senior.
Поширені помилки на цьому етапі
- Вірити, що ваш титул робить вашу думку правильною — ні. Правильною її робить обґрунтування.
- Надто інвестувати у стек, з якого почали — Senior — це розширення стека, а не звуження
- Уникати "людських" задач — це 80% senior-роботи
- Не коучити juniors. Плато якості вашої команди — це ваше плато.
Що компанії очікують на цьому рівні
- Можете спроєктувати і володіти frontend-архітектурою через декілька репозиторіїв / команд
- Здорова технічна комунікація: документи, RFC, асинхронне письмо — не тільки розмови
- Підсилюєте команду — juniors помітно ростуть, коли ви приєднуєтесь
- Комфортні з невизначеністю — продукти і вимоги змінюються, ви адаптуєтеся без паніки
Експерт
Зазвичай: 2+ роки
Експерт
Зазвичай: 2+ роки
Які навички ви освоїте
- Інновації у фреймворках
- Технічна стратегія
- Глибока доменна експертиза
- Вплив на індустріальні стандарти
Ви готові до наступного рівня, коли
- Задавали технічний напрямок через 2+ команди (або свою масштабовану команду) на квартал або більше
- Можете провести годинну технічну розмову з senior'ом з peer-компанії на серйозному рівні
- У вас є публічний артефакт, на який посилаються інші — open-source, доповідь, статті
- Допомогли декільком Senior'ам пройти їх підвищення
- Комфортно бути "найменш технічною" людиною в кімнаті, коли це правильно
Що побудувати
Конкретні проєкти — і що саме вони вас навчать.
- Внесок у великий frontend-фреймворк або його екосистему (навчить: open-source code-review на світовому рівні)
- Спроєктувати і написати публічну специфікацію наступного покоління патерну у вашій компанії (навчить: технічна комунікація на рівні індустрії)
Прочитайте
-
Контекст-інжиніринг: дисципліна, яка у 2026 році замінює prompt engineering
Prompt engineering ніколи не був справжнім умінням. Після двох років у продакшені з AI-фічами скажу прямо: на результат впливає інше — контекст-інжиніринг. Стан, інструменти, пошук, історія та обмеження, зібрані у вікні моделі в потрібну мить. Архітекторський погляд.
-
Evals у 2026: тест-сьют для систем, які не детерміновані
Ваша AI-фіча працювала вчора і ламається сьогодні. Ні код, ні промпт, ні модель не змінювалися. Так виглядає життя без evals. Це третя опора тріади spec → context → evals — і дисципліна, яку більшість команд пропускає.
-
OpenSpec у 2026: операційна система spec-driven development
Шість тижнів тому я поставив @fission-ai/openspec. Учора відвантажив зміну на чотирнадцять файлів за дев'яносто хвилин зі двохсотрядкової специфікації, у brownfield-кодовій базі, яку троє інженерів правлять два роки — без мерж-конфліктів, без ескалацій рев'ю. Це сеньорний архітектурний розбір того, чому OpenSpec — перший SDD-інструмент, який не розвалюється під продакшен-реальністю.
-
Як пройти System Design співбесіду: плейбук senior-інженера
Більшість порад щодо system design — теоретичний шум. Це повторюваний фреймворк, який я використовую для оцінки кандидатів — і яким ви можете користуватися, щоб пройти будь-яку system design співбесіду на mid або senior.
Поширені помилки на цьому етапі
- Повністю уникати IC-роботи — технічна авторитетність на цьому рівні швидко тане
- Відмовлятися писати код, "бо я Expert" — писати варто, і добре
- Вважати свій підхід єдино правильним — індустрія вже двічі пішла вперед
- Оптимізувати видиму роботу замість роботи з високим leverage
Що компанії очікують на цьому рівні
- Задає і захищає технічну стратегію функції
- Довіряють прийняття рішень, що впливають на 6+ місяців roadmap'у
- Зовнішня присутність (статті, доповіді, OSS) АБО еквівалентний внутрішній вплив
- Визнана експертиза в індустрії хоча б в одній вузькій сфері
Розробка бекенду
~3–5 років (Початковий → Senior)
Початківець
Зазвичай: 4–8 тижнів Джерело: Stack Overflow Developer Survey →
Початківець
Зазвичай: 4–8 тижнів Джерело: Stack Overflow Developer Survey →
Які навички ви освоїте
- Основи HTTP та REST
- Основи C# та .NET
- Основи ООП
- Основи баз даних (SQL)
- Контроль версій (Git)
Ви готові до наступного рівня, коли
- Побудували і задеплоїли невеликий CRUD-додаток з нуля — список книг, трекер задач, що завгодно з базою даних
- Впевнено пишете базовий SQL: SELECT, JOIN, WHERE, GROUP BY без копіпасту
- Можете пояснити, що таке HTTP-запит — метод, headers, body, статус-код
- Працювали з Git у справжньому flow: branch, commit, push у публічний репозиторій
- Знаєте різницю між value і reference-типами в C# (і чому це важливо)
Що побудувати
Конкретні проєкти — і що саме вони вас навчать.
- Простий консольний додаток на C#, що робить щось корисне (навчить: типи, керування потоком, обробка помилок)
- Невеликий CRUD-додаток із SQL-базою — книги / контакти / задачі (навчить: основи ORM, дизайн схеми, базові запити)
Пройдіть ці курси
Вступ до програмування на C#
Почніть з нуля та вивчайте C# крок за кроком: від базових конструкцій мови до ключових типів, ООП, колекцій, дженериків, делегатів, подій та обробки помилок. Надійний фундамент для подальшої .NET backend-розробки.
Вступ до SQL
Вивчайте SQL з нуля: запити, проєктування баз даних, індекси, JOIN-и, підзапити та збережені процедури.
Git та контроль версій
Опануйте Git з основ: коміти, гілки, злиття, rebase, вирішення конфліктів, GitHub-воркфлоу та основи CI/CD. Кожному розробнику це потрібно.
Прочитайте
-
Від C# до AI-агентів: шлях .NET-розробника до розробки на Claude
Ви вже знаєте C#, ASP.NET Core та вмієте запускати production-бекенди. Ось як перевикористати ці навички для серйозних AI-агентів на Claude — не викидаючи свій стек.
-
C# чи Python у 2025: що вчити першим?
Чесна оцінка senior-інженера: як обрати між C# та Python як першу серйозну мову — на основі даних ринку праці, кривої навчання та довгострокового впливу на кар'єру.
-
Як пройти System Design співбесіду: плейбук senior-інженера
Більшість порад щодо system design — теоретичний шум. Це повторюваний фреймворк, який я використовую для оцінки кандидатів — і яким ви можете користуватися, щоб пройти будь-яку system design співбесіду на mid або senior.
Поширені помилки на цьому етапі
- Намагатися побудувати архітектуру мікросервісів раніше, ніж напишете один робочий ендпоінт
- Пропускати SQL, бо "ORM сам все зробить" — коли ORM ховає повільний запит, чинити його доведеться через SQL
- Сприймати Git як кнопку "зберегти" — вчіть branching і читання diff'ів рано, від цього залежать ваші майбутні PR
- Запам'ятовувати синтаксис замість розуміння потоку — код читається знизу вгору, а не зверху вниз
Що компанії очікують на цьому рівні
- Портфоліо з 2–3 проєктів, які можна клонувати і запустити — хоча б один зі справжньою базою
- Впевненість писати базовий SQL на співбесіді зі скриншерингом, без StackOverflow
- Базовий Git-flow — clone, branch, commit, push, відповіді на PR-коментарі
- Можете прочитати stack trace і знайти рядок, де впало — не панікувати при його вигляді
Молодший
Зазвичай: 3–6 місяців Джерело: Stack Overflow Developer Survey →
Молодший
Зазвичай: 3–6 місяців Джерело: Stack Overflow Developer Survey →
Які навички ви освоїте
- Основи ASP.NET Core Web API
- Маршрутизація, контролери, DTO
- Основи Entity Framework Core
- Автентифікація та авторизація (JWT)
- Async/await та програмування на задачах
Ви готові до наступного рівня, коли
- Запустили REST API з авторизацією, реальною БД і хоча б одним integration-тестом
- Впевнено пишете async/await, не плутаючись у порядку виконання
- Можете дебажити Web API запит: від контролера через сервіс у репозиторій, з брейкпоінтами
- Рев'юїли чужий PR і дали хоча б один корисний коментар, не косметичний
- Достатньо розумієте DI, щоб додати новий сервіс, не копіюючи з іншого файлу
Що побудувати
Конкретні проєкти — і що саме вони вас навчать.
- REST API на ASP.NET Core + EF Core, JWT-автентифікація, задеплоєний десь насправді (навчить: повний stack однієї людини, справжня авторизація, справжня БД, справжній деплой)
- Сервіс керування користувачами або задачами з мінімум одним foreign-key зв'язком і трьома захищеними ендпоінтами (навчить: дизайн схеми, захист маршрутів, відповіді про помилки)
Пройдіть ці курси
Вступ до Entity Framework
Вивчайте основи Entity Framework, моделювання даних, запити та практичні приклади для сучасних .NET застосунків.
Вступ до ASP.NET Core
Вивчіть основи ASP.NET Core, сучасну backend-розробку, DI, маршрутизацію, контролери, REST API та розгортання.
Вступ до MongoDB
Вивчайте MongoDB з нуля: концепції NoSQL, документи й колекції, запити, індекси, агрегація та транзакції. Практичний старт для backend та data engineering.
Node.js та REST API
Будуйте production-готові REST API на Node.js та Express. Асинхронні патерни, middleware, JWT-аутентифікація, інтеграція з базами даних, обробка помилок та деплой.
Прочитайте
-
Від C# до AI-агентів: шлях .NET-розробника до розробки на Claude
Ви вже знаєте C#, ASP.NET Core та вмієте запускати production-бекенди. Ось як перевикористати ці навички для серйозних AI-агентів на Claude — не викидаючи свій стек.
-
C# чи Python у 2025: що вчити першим?
Чесна оцінка senior-інженера: як обрати між C# та Python як першу серйозну мову — на основі даних ринку праці, кривої навчання та довгострокового впливу на кар'єру.
-
Як пройти System Design співбесіду: плейбук senior-інженера
Більшість порад щодо system design — теоретичний шум. Це повторюваний фреймворк, який я використовую для оцінки кандидатів — і яким ви можете користуватися, щоб пройти будь-яку system design співбесіду на mid або senior.
Поширені помилки на цьому етапі
- Класти бізнес-логіку в контролери — контролери маршрутизують, сервіси роблять роботу, репозиторії спілкуються з даними
- Ловити кожен виняток через загальний try/catch — нехай виняток долетить туди, де знають, як з ним працювати
- Не писати тести, бо "команда напише потім" — не напише. Додайте хоча б один integration-тест на ендпоінт.
- Сприймати EF Core як магію — коли запит повільний, треба прочитати згенерований SQL
Що компанії очікують на цьому рівні
- Хоча б один задеплоєний REST API на ASP.NET Core, який можете провести по коду на співбесіді
- Впевнені основи OOP та async — пояснюєте різницю Task і Task<T>, value vs reference-типів
- Читання документації — дефолтний крок при затинанні, а не питання команді
- Базове розуміння pipeline'у запиту: middleware, фільтри, model binding
Середній рівень
Зазвичай: 6–12 місяців Джерело: Stack Overflow Developer Survey →
Середній рівень
Зазвичай: 6–12 місяців Джерело: Stack Overflow Developer Survey →
Які навички ви освоїте
- Clean Architecture та багаторівневий дизайн
- Продуктивність EF Core та міграції
- Кешування (Redis / Valkey)
- Черги повідомлень (RabbitMQ, основи Kafka)
- Модульне та інтеграційне тестування (xUnit, NUnit)
- CI/CD-конвеєри для .NET-сервісів
Ви готові до наступного рівня, коли
- На роботі або в реальному OSS-проєкті довели фічу з нуля: вимоги → дизайн → ship → on-call, коли вона впала
- Відрефакторили нетривіальний шматок чужого коду так, що не стало гірше — команда помітила
- Можете дебажити повільний EF Core запит, читаючи згенерований SQL і додаючи правильний індекс
- Рев'юїли PR у справжній команді, і ваші рев'ю цінують — а не пропускають
- Маєте думку про Clean Architecture / DDD, яку захищаєте кодом, а не блогами
Що побудувати
Конкретні проєкти — і що саме вони вас навчать.
- Мікросервіс на .NET з базою, кешем, чергою повідомлень, observability та CI/CD (навчить: мислення production-форми — що змінюється, коли сервісів 3+, а не 1)
- Відрефакторити фічу існуючого моноліту в чистий модульний слайс з тестами (навчить: інкрементальний рефакторинг під тиском — єдиний вид, що має значення у справжніх командах)
Пройдіть ці курси
C# Pro: Просунуте програмування та системний дизайн
Опanuйте розширені можливості C# та .NET: колекції, рефлексія, асинхронність, потоки, GC, серіалізація, TPL, функціональне програмування і синхронізація ядра Windows.
Патерни проєктування в C#: від теорії до практики
Опanuйте класичні патерни проєктування GoF у C#. Навчіться застосовувати породжувальні, структурні та поведінкові патерни для створення чистої, гнучкої та підтримуваної архітектури.
Основи архітектури Backend-систем
Практичний курс з архітектурного мислення backend-розробника. Ви навчитеся проєктувати масштабовані системи, обирати між монолітом і мікросервісами, створювати чисті API та мислити як production-інженер.
AI-розробка на .NET
Інтегруйте AI у .NET-застосунки через OpenAI та Azure OpenAI API. Будуйте інтелектуальні функції: чат, резюмування, embeddings, семантичний пошук і RAG-пайплайни — на C# і ASP.NET Core.
Прочитайте
-
Контекст-інжиніринг: дисципліна, яка у 2026 році замінює prompt engineering
Prompt engineering ніколи не був справжнім умінням. Після двох років у продакшені з AI-фічами скажу прямо: на результат впливає інше — контекст-інжиніринг. Стан, інструменти, пошук, історія та обмеження, зібрані у вікні моделі в потрібну мить. Архітекторський погляд.
-
Від C# до AI-агентів: шлях .NET-розробника до розробки на Claude
Ви вже знаєте C#, ASP.NET Core та вмієте запускати production-бекенди. Ось як перевикористати ці навички для серйозних AI-агентів на Claude — не викидаючи свій стек.
-
C# чи Python у 2025: що вчити першим?
Чесна оцінка senior-інженера: як обрати між C# та Python як першу серйозну мову — на основі даних ринку праці, кривої навчання та довгострокового впливу на кар'єру.
-
Evals у 2026: тест-сьют для систем, які не детерміновані
Ваша AI-фіча працювала вчора і ламається сьогодні. Ні код, ні промпт, ні модель не змінювалися. Так виглядає життя без evals. Це третя опора тріади spec → context → evals — і дисципліна, яку більшість команд пропускає.
Поширені помилки на цьому етапі
- Карго-культ Clean Architecture у сервісі з 3 ендпоінтів — шари існують, щоб керувати складністю, а не додавати її
- Мікросервісити все підряд — більшість команд краще доставляє на чистому модульному моноліті, ніж на погано обмеженому мікро-зоопарку
- Кешувати все скрізь — кеш = інвалідація = проблема, що просто чекає
- Пропускати observability "поки не знадобиться" — до того моменту дебажите в темряві з logs.txt і надією
Що компанії очікують на цьому рівні
- Сильний .NET + EF Core, зі справжнім розумінням clean architecture та design patterns — не просто з підручника
- Здоровий інстинкт тестування: unit + integration, базовий contract testing для міжсервісних викликів
- Можете спроєктувати невелику фічу без сеньора за плечем, включно зі схемою БД і планом відкату
- Адекватний code review — конструктивно пушбекаєте погані PR, менторите junior'ів через рев'ю
Старший
Зазвичай: 1–2 роки
Старший
Зазвичай: 1–2 роки
Які навички ви освоїте
- Проєктування архітектури .NET-систем
- Оптимізація під високі навантаження та профілювання
- Спостережуваність (логування, трейсинг, метрики)
- Domain-Driven Design (DDD), CQRS, event-driven системи
- Лідерство бекенд-команди та якість коду
Ви готові до наступного рівня, коли
- Спроєктували backend-архітектуру для нетривіального продукту (від 3 сервісів або 5 інженерів)
- Зробили технологічний вибір, який команда все ще використовує через рік — і вмієте пояснити trade-offs
- Провели junior'а або mid-інженера через реальне плато — вони випустили щось, чого не могли до цього
- Перестали писати тикети "бо хочу" — пишете, бо це правильний наступний крок для системи
- Комфортно сказати "ця ідея неправильна" PM'у, дизайнеру або іншому senior'у — обґрунтуванням, не статусом
Що побудувати
Конкретні проєкти — і що саме вони вас навчать.
- Спроєктувати backend-архітектуру для мульти-сервісного продукту, включно зі стратегією БД, observability, планом деплою (навчить: мислення в категоріях failure modes, а не happy path)
- Провести критичну міграцію — заміна движка БД, апгрейд фреймворку, винесення з моноліту — з вимірюваним планом відкату (навчить: планування, комунікація, менторинг під тиском)
Пройдіть ці курси
1:1 Розбір Backend та Архітектури
Персональна 1:1 сесія з фокусом на архітектуру: виявлення ризиків, розбір компромісів і визначення конкретних наступних кроків. Аналізуємо backend-архітектуру, код і готовність до production.
Побудова LLM-застосунків: RAG та агенти
Будуйте production AI-застосунки на основі великих мовних моделей. Vector databases, RAG, автономні агенти, виклик інструментів, оцінка та патерни деплою.
Розробка на Claude API: production AI-застосунки з Anthropic SDK
Опануйте Claude API від Anthropic: messages API, prompt caching, tool use, extended thinking, стрімінг, batch-обробка, files, citations та vision. Будуйте економічні production AI-функції в будь-якому backend.
Побудова агентів на Claude Agent SDK
Проєктуйте та запускайте власних AI-агентів на Claude Agent SDK. Будуйте agent loops, визначайте інструменти, керуйте пам'яттю і суб-агентами, оцінюйте поведінку та деплойте мультиагентні системи для реальних інженерних задач.
Прочитайте
-
Claude Code у production: чого я навчився за 6 місяців
Пів року Claude Code як основного інструменту — які воркфлоу реально економлять час, які тихо його з'їдають, і яку конфігурацію більшість команд так і не налаштовують.
-
Контекст-інжиніринг: дисципліна, яка у 2026 році замінює prompt engineering
Prompt engineering ніколи не був справжнім умінням. Після двох років у продакшені з AI-фічами скажу прямо: на результат впливає інше — контекст-інжиніринг. Стан, інструменти, пошук, історія та обмеження, зібрані у вікні моделі в потрібну мить. Архітекторський погляд.
-
Evals у 2026: тест-сьют для систем, які не детерміновані
Ваша AI-фіча працювала вчора і ламається сьогодні. Ні код, ні промпт, ні модель не змінювалися. Так виглядає життя без evals. Це третя опора тріади spec → context → evals — і дисципліна, яку більшість команд пропускає.
-
OpenSpec у 2026: операційна система spec-driven development
Шість тижнів тому я поставив @fission-ai/openspec. Учора відвантажив зміну на чотирнадцять файлів за дев'яносто хвилин зі двохсотрядкової специфікації, у brownfield-кодовій базі, яку троє інженерів правлять два роки — без мерж-конфліктів, без ескалацій рев'ю. Це сеньорний архітектурний розбір того, чому OpenSpec — перший SDD-інструмент, який не розвалюється під продакшен-реальністю.
Поширені помилки на цьому етапі
- Сприймати system design як трофей — архітектура існує, щоб вирішувати реальні проблеми команди, а не прикрашати ваше резюме
- Надто інвестувати у стек, з якого почали — Senior — це розширення (інші мови, інші парадигми), а не звуження
- Уникати "людських" задач — це 70% senior-роботи і та частина, яка визначає, чи станете Staff
- Не коучити junior'ів на справжніх PR. Плато якості команди — це ваше плато.
Що компанії очікують на цьому рівні
- Можете проєктувати і володіти backend-архітектурою через декілька сервісів, з правдоподібною історією failure mode'ів
- Здорова технічна комунікація: документи, RFC, асинхронне письмо — команда діє за вашим текстом без вас у кімнаті
- Підсилюєте команду — junior'и помітно ростуть, коли ви приєднуєтесь, mid-level'и просуваються швидше
- Комфортні з невизначеністю: продукти і вимоги змінюються, ви адаптуєтеся без втрати якості
Експерт
Зазвичай: 2+ роки
Експерт
Зазвичай: 2+ роки
Які навички ви освоїте
- Стратегія платформи та архітектури для .NET-екосистеми
- Великомасштабні розподілені системи на .NET
- Технічне лідерство на рівні кількох команд
- Визначення інженерних стандартів та кращих практик
- Вплив на спільноту: open-source, доповіді, менторинг
Ви готові до наступного рівня, коли
- Задавали технічний напрямок через 2+ команди (або свою масштабовану команду) на квартал або більше
- Можете провести годинну технічну розмову з senior'ом з peer-компанії — і піти, дізнавшись щось нове
- У вас є публічний артефакт, на який посилаються: OSS, доповідь або широко цитований внутрішній RFC
- Допомогли декільком Senior'ам пройти підвищення — вони називають вас причиною
- Комфортно бути "найменш технічним" у кімнаті, коли це правильно — і найтехнічнішим через 30 хвилин
Що побудувати
Конкретні проєкти — і що саме вони вас навчать.
- Визначити бачення .NET-платформи для компанії — які сервіси використовують які патерни, чому і як команди onboard'яться (навчить: стандарти як multiplier, а не constraint)
- Розвинути ключовий OSS або внутрішній фреймворк, прийнятий декількома командами — артефакт, що переживає вашу роль у компанії (навчить: дизайн API на масштабі, дисципліна deprecation)
Пройдіть ці курси
Побудова MCP-серверів та AI Tool Integrations
Опануйте Model Context Protocol (MCP) — відкритий стандарт Anthropic для підключення AI-моделей до зовнішніх інструментів. Будуйте MCP-сервери, підключайте API до Claude.
Spec-Driven Development: від філософії до робочої моделі
Навчіться писати специфікації, яким агенти справді коряться, випускати код як кеш довговічної специфікації і керувати тріадою spec→context→evals на реальних кодових базах. Vendor-agnostic, tool-agnostic, brownfield-ready — методологічний курс, що поєднується з будь-яким agentic-стеком.
OpenSpec на практиці: production spec-driven workflows для AI coding agents
Операціоналізуйте SDD з OpenSpec — open-source spec framework, що ставиться до специфікацій як Git до коду. Опануйте /opsx:propose, /opsx:apply та /opsx:archive на справжній brownfield-кодовій базі. CI-гейти, мульти-інженерна колаборація, retrofitting legacy-специфікацій і workflow-ритуали, що приживаються.
Прочитайте
-
Контекст-інжиніринг: дисципліна, яка у 2026 році замінює prompt engineering
Prompt engineering ніколи не був справжнім умінням. Після двох років у продакшені з AI-фічами скажу прямо: на результат впливає інше — контекст-інжиніринг. Стан, інструменти, пошук, історія та обмеження, зібрані у вікні моделі в потрібну мить. Архітекторський погляд.
-
Evals у 2026: тест-сьют для систем, які не детерміновані
Ваша AI-фіча працювала вчора і ламається сьогодні. Ні код, ні промпт, ні модель не змінювалися. Так виглядає життя без evals. Це третя опора тріади spec → context → evals — і дисципліна, яку більшість команд пропускає.
-
OpenSpec у 2026: операційна система spec-driven development
Шість тижнів тому я поставив @fission-ai/openspec. Учора відвантажив зміну на чотирнадцять файлів за дев'яносто хвилин зі двохсотрядкової специфікації, у brownfield-кодовій базі, яку троє інженерів правлять два роки — без мерж-конфліктів, без ескалацій рев'ю. Це сеньорний архітектурний розбір того, чому OpenSpec — перший SDD-інструмент, який не розвалюється під продакшен-реальністю.
-
Як пройти System Design співбесіду: плейбук senior-інженера
Більшість порад щодо system design — теоретичний шум. Це повторюваний фреймворк, який я використовую для оцінки кандидатів — і яким ви можете користуватися, щоб пройти будь-яку system design співбесіду на mid або senior.
Поширені помилки на цьому етапі
- Повністю уникати IC-роботи — технічна авторитетність на цьому рівні швидко тане. Пишіть код добре, щомісячно.
- Відмовлятися писати код "бо я Expert" — у момент, коли не можете прототипувати, ваш design-фідбек стає розмитим
- Вважати свій стек універсальною відповіддю — індустрія вже хоча б раз пішла вперед від вашої улюбленої парадигми
- Оптимізувати видиму роботу замість роботи з високим leverage — робота без release note часто важливіша
Що компанії очікують на цьому рівні
- Задає і захищає технічну стратегію backend-функції
- Довіряють рішення, що впливають на 6+ місяців roadmap'у і витримують перевірку від VP'ів та інших Expert'ів
- Зовнішня присутність (статті, доповіді, OSS) АБО еквівалентний внутрішній вплив (architecture council, hiring bar, ментор-пул)
- Визнана індустріальна експертиза хоча б в одній вузькій сфері — розподілені системи, продуктивність, безпека тощо
Наука про дані та машинне навчання
~3–5 років (Junior → Senior — Data рідко стартує з Beginner)
Молодший
Зазвичай: 3–6 місяців Джерело: Stack Overflow Developer Survey →
Молодший
Зазвичай: 3–6 місяців Джерело: Stack Overflow Developer Survey →
Які навички ви освоїте
- Python для аналізу даних
- Pandas та NumPy
- Візуалізація даних
- SQL-запити
- Основи статистики
Ви готові до наступного рівня, коли
- Очистили і проаналізували справжній публічний датасет від CSV до графіка, який зрозумілий іншій людині
- Впевнено пишете SQL глибше SELECT — joins, віконні функції, базова оптимізація
- Написали Python-скрипт, що читає, трансформує і записує дані без копіпасту зі StackOverflow
- Можете пояснити різницю між mean, median і mode без Wikipedia
- Запушили свій аналіз на GitHub з README, за яким може пройти інша людина
Що побудувати
Конкретні проєкти — і що саме вони вас навчать.
- Проєкт з аналізу публічного датасета (Kaggle, відкриті дані) — очищення, аналіз, візуалізація, висновки (навчить: pandas, matplotlib, справжній цикл аналізу)
- Невеликий дашборд, що забирає live-дані з API і оновлюється (навчить: основи ETL, планування, презентація даних поза notebook)
Пройдіть ці курси
Основи Python
Вивчайте Python з нуля: змінні, типи даних, функції, ООП, робота з файлами, модулі та практичні скрипти. Ідеальний перший крок для backend, data та AI-кар'єри.
Вступ до SQL
Вивчайте SQL з нуля: запити, проєктування баз даних, індекси, JOIN-и, підзапити та збережені процедури.
Поширені помилки на цьому етапі
- Пропускати SQL, бо "я буду використовувати pandas" — коли датасет 50ГБ, pandas падає, а SQL — єдиний варіант
- Збирати Streamlit-дашборд раніше, ніж зрозуміли, який інсайт ви доставляєте
- Сприймати Jupyter-notebook як production-код — це пісочниця, а не deliverable
- Пропускати статистику, бо "модель сама розбереться" — кожна помилка моделі — це замаскована помилка статистики
Що компанії очікують на цьому рівні
- Портфоліо з 1–2 проєктів на GitHub зі справжньою data-роботою — Kaggle це старт, а не фініш
- Впевнений SQL на співбесіді зі скриншерингом, не тільки однорядкові notebook-фрази
- Можете пояснити, ЧОМУ обробляли дані саме так — а не просто що обробили
- Базовий git-flow, можете прочитати чужий notebook і переробити його в скрипт
Середній рівень
Зазвичай: 6–12 місяців Джерело: Stack Overflow Developer Survey →
Середній рівень
Зазвичай: 6–12 місяців Джерело: Stack Overflow Developer Survey →
Які навички ви освоїте
- Основи машинного навчання
- Scikit-learn
- Оцінка моделей
- Feature engineering
- Конвеєри обробки даних
Ви готові до наступного рівня, коли
- На роботі або в реальному проєкті довели ML-фічу з нуля: дані → модель → deploy → моніторинг
- Можете дебажити модель, що "стала гіршою в продакшені", читаючи дані, а не перетренувати наосліп
- Побудували хоча б один ETL/ELT-пайплайн, що працює за розкладом і відновлюється після збоїв
- Рев'юїли чужу data-роботу, і фідбек не був косметичним
- Маєте думку про класичний ML vs LLM-для-цієї-задачі, яку захищаєте кодом
Що побудувати
Конкретні проєкти — і що саме вони вас навчать.
- Натренувати, оцінити і задеплоїти невелику ML-модель за HTTP API — включно з /predict ендпоінтом з retry/timeout (навчить: що "деплой ML" — це здебільшого звичайна backend-робота)
- RAG-прототип: завантажити корпус, embed-ити, зберегти, retrieval, відповідь (навчить: vector DB, конструювання промптів, evaluation)
Пройдіть ці курси
Prompt Engineering та автоматизація з AI
Навчіться ефективно працювати з AI-моделями: пишіть якісні prompts, будуйте автоматизовані workflows за допомогою Cursor, Copilot та API-інструментів.
AI-розробка на .NET
Інтегруйте AI у .NET-застосунки через OpenAI та Azure OpenAI API. Будуйте інтелектуальні функції: чат, резюмування, embeddings, семантичний пошук і RAG-пайплайни — на C# і ASP.NET Core.
Прочитайте
-
AI-інструменти, які має використовувати кожен розробник у 2025
Не хайп-список. Практичний розбір того, які AI-інструменти реально економлять час, які — крадуть, і як побудувати воркфлоу, що робить вас вимірно швидшими.
-
Claude Code у production: чого я навчився за 6 місяців
Пів року Claude Code як основного інструменту — які воркфлоу реально економлять час, які тихо його з'їдають, і яку конфігурацію більшість команд так і не налаштовують.
-
Контекст-інжиніринг: дисципліна, яка у 2026 році замінює prompt engineering
Prompt engineering ніколи не був справжнім умінням. Після двох років у продакшені з AI-фічами скажу прямо: на результат впливає інше — контекст-інжиніринг. Стан, інструменти, пошук, історія та обмеження, зібрані у вікні моделі в потрібну мить. Архітекторський погляд.
-
Від C# до AI-агентів: шлях .NET-розробника до розробки на Claude
Ви вже знаєте C#, ASP.NET Core та вмієте запускати production-бекенди. Ось як перевикористати ці навички для серйозних AI-агентів на Claude — не викидаючи свій стек.
Поширені помилки на цьому етапі
- Тягнутися до LLM там, де 50 рядків scikit-learn вирішать задачу дешевше, швидше і надійніше
- Вважати accuracy єдиною метрикою — production ML живе або вмирає на latency, cost і failure mode'ах
- Пропускати дисципліну eval-set — кожне твердження "модель чудова" без eval-set — це маркетинг
- Не версіонувати дані — коли модель ламається, треба знати, на яких даних вона навчалась
Що компанії очікують на цьому рівні
- Сильний Python + SQL зі справжнім розумінням ML lifecycle (не "ноутбук → PowerPoint")
- Здорові основи evaluation: train/val/test, leakage, базові порівняння
- Можете спроєктувати невелику ML-фічу без сеньора за плечем — включно з даними, моделлю і serving
- Адекватний code review — пушбекаєте погану data-роботу так само, як поганий код
Старший
Зазвичай: 1–2 роки
Старший
Зазвичай: 1–2 роки
Які навички ви освоїте
- Просунуті алгоритми ML
- Глибоке навчання
- Оптимізація моделей
- Технології Big Data
- Дослідницька робота
Що побудувати
Конкретні проєкти — і що саме вони вас навчать.
- Складна ML-система
- Керування командою data science
Експерт
Зазвичай: 2+ роки
Експерт
Зазвичай: 2+ роки
Які навички ви освоїте
- Інновації в AI
- Лідерство у дослідженнях
- Проєктування алгоритмів
- Галузеві дослідження
- Технічна стратегія
Ви готові до наступного рівня, коли
- Задавали data/ML технічний напрямок через 2+ команди на квартал або більше
- Можете провести годинну технічну розмову з senior data-людиною з peer-компанії
- Публічний артефакт: стаття, OSS, доповідь або широко цитований внутрішній RFC
- Допомогли декільком Senior'ам пройти підвищення у data-організації
- Комфортно сказати "ми не повинні це будувати", коли дані не підтримують ідею
Що побудувати
Конкретні проєкти — і що саме вони вас навчать.
- Опублікувати research-статтю, технічний пост або OSS-внесок, на який посилаються інші практики (навчить: ясність на рівні, де рухається індустрія)
- Визначити AI/data-платформу компанії — який стек, які контролі, яка eval-дисципліна (навчить: стандарти як multiplier; зробити 30 інженерів на 10% кращими — більше, ніж 1 на 50%)
Пройдіть ці курси
Побудова MCP-серверів та AI Tool Integrations
Опануйте Model Context Protocol (MCP) — відкритий стандарт Anthropic для підключення AI-моделей до зовнішніх інструментів. Будуйте MCP-сервери, підключайте API до Claude.
Побудова агентів на Claude Agent SDK
Проєктуйте та запускайте власних AI-агентів на Claude Agent SDK. Будуйте agent loops, визначайте інструменти, керуйте пам'яттю і суб-агентами, оцінюйте поведінку та деплойте мультиагентні системи для реальних інженерних задач.
Прочитайте
-
AI-інструменти, які має використовувати кожен розробник у 2025
Не хайп-список. Практичний розбір того, які AI-інструменти реально економлять час, які — крадуть, і як побудувати воркфлоу, що робить вас вимірно швидшими.
-
Claude Code у production: чого я навчився за 6 місяців
Пів року Claude Code як основного інструменту — які воркфлоу реально економлять час, які тихо його з'їдають, і яку конфігурацію більшість команд так і не налаштовують.
-
Контекст-інжиніринг: дисципліна, яка у 2026 році замінює prompt engineering
Prompt engineering ніколи не був справжнім умінням. Після двох років у продакшені з AI-фічами скажу прямо: на результат впливає інше — контекст-інжиніринг. Стан, інструменти, пошук, історія та обмеження, зібрані у вікні моделі в потрібну мить. Архітекторський погляд.
-
Від C# до AI-агентів: шлях .NET-розробника до розробки на Claude
Ви вже знаєте C#, ASP.NET Core та вмієте запускати production-бекенди. Ось як перевикористати ці навички для серйозних AI-агентів на Claude — не викидаючи свій стек.
Поширені помилки на цьому етапі
- Обирати інструменти за hype, а не за тим, що команді потрібно і що зможе підтримувати
- Уникати бізнес-розмов — на цьому рівні "модель чудова" нічого не означає без business impact'у
- Вважати свій підхід єдино правильним — індустрія вже хоча б раз пішла від вашої улюбленої парадигми
- Оптимізувати видиму роботу замість leverage-роботи (eval pipeline'и > flashy нова модель)
Що компанії очікують на цьому рівні
- Задає і захищає data/ML технічну стратегію функції
- Довіряють рішення на 6+ місяців roadmap'у, що витримують перевірку від VP'ів
- Зовнішня присутність (статті, доповіді, OSS) АБО еквівалентний внутрішній вплив
- Визнана індустріальна експертиза хоча б в одній сфері — recsys, LLM-агенти, time series тощо
DevOps / SRE
~4–6 років сумарно (у DevOps зазвичай ідуть після 1–2 років backend або sysadmin)
Середній рівень
Зазвичай: 6–12 місяців Джерело: CNCF Annual Survey →
Середній рівень
Зазвичай: 6–12 місяців Джерело: CNCF Annual Survey →
Які навички ви освоїте
- Контейнеризація Docker
- Основи Kubernetes
- CI/CD-конвеєри
- Адміністрування Linux
- Основи мереж
Ви готові до наступного рівня, коли
- Провели справжній сервіс від local dev до production: Dockerfile, CI, deploy, monitoring — без копіпасту з туторіалу
- Впевнено читаєте логи контейнера і kubectl describe для діагностики CrashLoopBackOff
- Написали хоча б один CI-пайплайн самі, не лише змінювали існуючий
- Розумієте різницю між liveness і readiness probes і коли що застосовується
- Маєте думку про Helm vs Kustomize, яку захищаєте справжнім конфігом, який писали
Що побудувати
Конкретні проєкти — і що саме вони вас навчать.
- Взяти справжній backend-сервіс і провести через повний pipeline: Dockerfile → CI build → push → deploy → health check (навчить: справжній production-цикл, а не шматки в ізоляції)
- Налаштувати моніторинг і алертинг на невеликому кластері — отримати хоча б один справжній алерт, потім затюнити (навчить: alert fatigue — це реально; якість > кількість)
Прочитайте
-
Claude Code у production: чого я навчився за 6 місяців
Пів року Claude Code як основного інструменту — які воркфлоу реально економлять час, які тихо його з'їдають, і яку конфігурацію більшість команд так і не налаштовують.
-
Spec-Driven Development: коли специфікація стає кодовою базою
Я вже два місяці не написав жодної функції руками — і кодова база ніколи не була здоровішою. Ось як spec-driven development змінив те, що у 2026 означає «інженерна робота», правила, які тримають дисципліну чесною, і місця, де вона все ще ламається.
Поширені помилки на цьому етапі
- Тягнутися до Kubernetes там, де звичайна VM з systemd вирішить задачу за 1/10 операційної вартості
- Сприймати CI/CD як "налаштував і забув" — pipeline'и потребують обслуговування, як будь-який код
- Зберігати секрети в env-змінних у CI-логах — failure mode = "ваші AWS-ключі на Pastebin"
- Пропускати on-call досвід — DevOps без on-call — це теорія; on-call — де ви дізнаєтесь, що справді ламається
Що компанії очікують на цьому рівні
- Реально шипали в production — не "я вчив Kubernetes на домашньому кластері"
- Впевнено працюєте хоча б з одним cloud provider'ом глибоко (AWS, GCP або Azure) — а не з усіма трьома поверхово
- Впевнені основи Linux: ssh, права на файли, systemd, базова мережа
- Спочатку docs, потім тімбілд — ви не живете в чаті #help-devops
Старший
Зазвичай: 1–2 роки
Старший
Зазвичай: 1–2 роки
Які навички ви освоїте
- Просунутий Kubernetes
- Infrastructure as Code (Terraform, Ansible)
- Моніторинг та логування
- Безпека і відповідність вимогам
- Стратегії масштабування
Ви готові до наступного рівня, коли
- Спроєктували і експлуатували інфру, від якої залежать 3+ інженери, з правдоподібною історією failure mode'ів
- Зробили infra-вибір, який команда все ще використовує через рік — Terraform-розклад, K8s-топологія, стратегія деплою
- Провели junior або mid DevOps-інженера через реальне плато — тепер вони володіють шматком інфри
- Написали хоча б один runbook, за яким хтось інший о 3 ночі підняв систему без дзвінка вам
- Комфортно сказати "це потрібно переписати, а не заліпити" з готовим cost-benefit аналізом
Що побудувати
Конкретні проєкти — і що саме вони вас навчать.
- Спроєктувати і запустити multi-cluster setup зі справжнім IaC, ротацією secret'ів та incident-playbook'ами (навчить: мислення в категоріях "дзвінок о 3 ночі"; design для failure case)
- Провести критичну інфра-міграцію — перехід у cloud, апгрейд K8s, переробка monitoring'у — з вимірюваним планом відкату (навчить: планування, менторинг, комунікація коли системи під загрозою)
Прочитайте
-
Claude Code у production: чого я навчився за 6 місяців
Пів року Claude Code як основного інструменту — які воркфлоу реально економлять час, які тихо його з'їдають, і яку конфігурацію більшість команд так і не налаштовують.
-
Контекст-інжиніринг: дисципліна, яка у 2026 році замінює prompt engineering
Prompt engineering ніколи не був справжнім умінням. Після двох років у продакшені з AI-фічами скажу прямо: на результат впливає інше — контекст-інжиніринг. Стан, інструменти, пошук, історія та обмеження, зібрані у вікні моделі в потрібну мить. Архітекторський погляд.
-
Evals у 2026: тест-сьют для систем, які не детерміновані
Ваша AI-фіча працювала вчора і ламається сьогодні. Ні код, ні промпт, ні модель не змінювалися. Так виглядає життя без evals. Це третя опора тріади spec → context → evals — і дисципліна, яку більшість команд пропускає.
-
OpenSpec у 2026: операційна система spec-driven development
Шість тижнів тому я поставив @fission-ai/openspec. Учора відвантажив зміну на чотирнадцять файлів за дев'яносто хвилин зі двохсотрядкової специфікації, у brownfield-кодовій базі, яку троє інженерів правлять два роки — без мерж-конфліктів, без ескалацій рев'ю. Це сеньорний архітектурний розбір того, чому OpenSpec — перший SDD-інструмент, який не розвалюється під продакшен-реальністю.
Поширені помилки на цьому етапі
- Карго-культ "best practices" без розуміння, чому команда обрала попередній варіант
- Надто інвестувати в observability-tooling, ігноруючи питання: на які алерти команда має реально прокидатися
- Уникати сторони developer experience — DevOps, що дратує розробників, обходять, а не приймають
- Сприймати cost як чиюсь проблему — Senior DevOps, що не говорить у доларах, застрягає на Senior
Що компанії очікують на цьому рівні
- Можете проєктувати і володіти інфрою через кілька сервісів і кластерів, з правдоподібним disaster-recovery планом
- Сильна технічна комунікація: docs, RFC, runbook'и — команда діє за вашим текстом о 3 ночі
- Підсилюєте команду — junior DevOps-інженери помітно ростуть, коли ви приєднуєтесь
- Комфортно говорите в доларах і надійності з leadership, а не лише в YAML з інженерами
Експерт
Зазвичай: 2+ роки
Експерт
Зазвичай: 2+ роки
Які навички ви освоїте
- Хмарна архітектура
- Інновації в інфраструктурі
- Лідерство команди
- Оптимізація витрат
- Disaster Recovery-стратегії
Ви готові до наступного рівня, коли
- Задавали інфраструктурну стратегію через 2+ команди (або свою масштабовану команду) на квартал або більше
- Можете провести годинну технічну розмову з senior platform-людиною з peer-компанії
- Публічний артефакт, на який посилаються: OSS, доповідь або широко цитований внутрішній RFC щодо platform/infra design
- Допомогли декільком Senior'ам пройти підвищення у platform-організації
- Комфортно бути "найменш технічним" у кімнаті, коли це правильно, і найтехнічнішим — коли потрібно
Що побудувати
Конкретні проєкти — і що саме вони вас навчать.
- Визначити cloud/platform-стратегію компанії — які сервіси, які контролі, який cost ceiling, який failure budget (навчить: стандарти як multiplier через кілька команд)
- Провести infra-команду через великий зсув — multi-cloud, FinOps-перепланування, security-overhaul — що переживає зміну leadership (навчить: стійкий design; що тримається, коли stakeholders змінюються)
Прочитайте
-
Контекст-інжиніринг: дисципліна, яка у 2026 році замінює prompt engineering
Prompt engineering ніколи не був справжнім умінням. Після двох років у продакшені з AI-фічами скажу прямо: на результат впливає інше — контекст-інжиніринг. Стан, інструменти, пошук, історія та обмеження, зібрані у вікні моделі в потрібну мить. Архітекторський погляд.
-
Evals у 2026: тест-сьют для систем, які не детерміновані
Ваша AI-фіча працювала вчора і ламається сьогодні. Ні код, ні промпт, ні модель не змінювалися. Так виглядає життя без evals. Це третя опора тріади spec → context → evals — і дисципліна, яку більшість команд пропускає.
-
OpenSpec у 2026: операційна система spec-driven development
Шість тижнів тому я поставив @fission-ai/openspec. Учора відвантажив зміну на чотирнадцять файлів за дев'яносто хвилин зі двохсотрядкової специфікації, у brownfield-кодовій базі, яку троє інженерів правлять два роки — без мерж-конфліктів, без ескалацій рев'ю. Це сеньорний архітектурний розбір того, чому OpenSpec — перший SDD-інструмент, який не розвалюється під продакшен-реальністю.
-
Як пройти System Design співбесіду: плейбук senior-інженера
Більшість порад щодо system design — теоретичний шум. Це повторюваний фреймворк, який я використовую для оцінки кандидатів — і яким ви можете користуватися, щоб пройти будь-яку system design співбесіду на mid або senior.
Поширені помилки на цьому етапі
- Повністю уникати hands-on роботи — Expert platform-інженери, що не можуть прототипувати, втрачають авторитет за рік
- Відмовлятися писати IaC "бо я Expert" — ваш design-фідбек стає розмитим у момент, коли перестаєте
- Вважати свій стек універсальним — що працює на 50 інженерах, не працює на 5 або 500
- Оптимізувати видиму роботу замість невидимої-але-leverage-ної (deprecation cleanup, що запобігає 3 інцидентам)
Що компанії очікують на цьому рівні
- Задає і захищає platform/infra технічну стратегію функції
- Довіряють рішення, що впливають на 6+ місяців platform roadmap'у і витримують перевірку від VP'ів
- Зовнішня присутність (доповіді, OSS, статті) АБО еквівалентний внутрішній вплив (architecture council, SRE bar, platform RFC'и)
- Визнана індустріальна експертиза хоча б в одній сфері — networking, observability, FinOps, security тощо
Реалістичні загальні строки
Скільки насправді займає перехід в IT? Чесна відповідь: залежить. Ось типовий діапазон за даними публічних опитувань і нашими спостереженнями за самонавчанням.
Розробка фронтенду
~2.5–4 роки (Початковий → Senior)
Розробка бекенду
~3–5 років (Початковий → Senior)
Наука про дані та машинне навчання
~3–5 років (Junior → Senior — Data рідко стартує з Beginner)
DevOps / SRE
~4–6 років сумарно (у DevOps зазвичай ідуть після 1–2 років backend або sysadmin)
Помилки, які роблять усі
Не залежать від треку. Якщо уникнете цих п'яти, навчатиметеся швидше за 80% людей, яких зустрінете на мітапах.
-
Tutorial hell
Дивитися 100 годин туторіалів, не побудувавши нічого самостійно. Після кожного курсу має залишатися проєкт, який можна показати. Якщо закінчили курс без артефакту — курсу не було, ви подивились фільм.
-
Гонка за фреймворками
Стрибати з React на Vue на Svelte на Solid кожні два тижні "щоб знайти правильний". Правильний — той, на якому ви щось випустили. Оберіть популярний дефолт, побудуйте на ньому 6 місяців, потім майте думку. Не раніше.
-
Все будувати "в стіл"
Ваше портфоліо у 2026 — це ваш GitHub, а не CV. Рекрутери і hiring manager'и тиснуть "Подивитись на GitHub" раніше, ніж читають буліти. Якщо ваші проєкти не публічні — навіть сирі — вони не рахуються. Публічне > вилизане.
-
Пропускати фундамент у гонитві за модним
Стрибати в LLM-агентів, не вміючи написати чисту функцію. Будувати mesh з мікросервісів, не розуміючи одного HTTP-запиту. Нудний фундамент (HTTP, SQL, event loop, базові структури даних) накопичується на 30 років. У трендів період напіврозпаду 2 роки.
-
Вчитися наодинці
Найшвидше навчаються ті, хто пише код у парі, публічно постить прогрес, ставить "дурні" питання в Discord і отримує code review від тих, хто трохи попереду. Вчитися наодинці — приблизно вдвічі повільніше, ніж ті самі години з однією людиною, якій можна поставити питання.