Технічна співбесіда backend — це той момент, коли роки написання коду зводяться до 60 хвилин розмови з незнайомою людиною. Ви точно знаєте як запустити Redis, писали SQL-запити сотні разів, але коли інтерв'юер каже "реалізуйте LRU-кеш" — в голові пустеля. Так буває у 7 з 10 кандидатів, яких ми бачимо. Технічне інтерв'ю — окрема навичка, яку треба тренувати окремо від написання реального коду.
У цьому гайді — структура підготовки від нуля до готовності: що перевіряють на кожному етапі, які задачі реально ставлять в українських компаніях у 2026, де тренуватись і як поводитись якщо не знаєш відповіді. Плюс покрокова схема і чекліст готовності.
Що перевіряють на технічній співбесіді Backend і чому це відрізняється від роботи у продакшні
Технічна співбесіда backend у 2026 складається з чотирьох незалежних блоків. Компанія може використовувати всі або вибірково — залежить від рівня і типу компанії (продуктова, аутсорс, стартап).
Алгоритми і структури даних
Масиви, хеш-таблиці, стеки, черги, дерева, графи. Типовий формат: "напишіть функцію яка..." Присутній у 90% продуктових і 60% аутсорсингових компаній.
Бази даних
SQL запити, пояснення EXPLAIN, індекси, транзакції, вибір між SQL і NoSQL. Питання по реальних сценаріях — "чому цей запит повільно виконується?"
Системний дизайн
Проектування масштабованих сервісів. Типово для Middle і Senior. "Спроектуйте систему нотифікацій для 10 млн користувачів."
Технологічний стек + soft skills
Питання по вашому стеку (Node.js, Java, Python, Go) і поведінкові питання: конфлікти в команді, складні рішення, помилки.
🎯 Швидка перевірка: що для вас найважче на технічному інтерв'ю?
Алгоритми і структури даних: що точно запитають — і що можна пропустити
Алгоритмічна частина технічної співбесіди backend лякає найбільше — але реально потрібен відносно вузький набір тем. За аналізом 80+ вакансій Junior і Middle Backend на DOU і Djinni за Q1 2026, ось розподіл частоти:
| Тема | Частота у UA компаніях | Пріоритет підготовки |
|---|---|---|
| Масиви і рядки (sliding window, two pointers) | 85% | 🔴 Обов'язково |
| Хеш-таблиці і словники | 80% | 🔴 Обов'язково |
| Стеки і черги | 65% | 🟡 Важливо |
| Двійкові дерева (обходи, BST) | 60% | 🟡 Важливо |
| Пошук і сортування (Binary search) | 55% | 🟡 Важливо |
| Графи (BFS/DFS) | 35% | 🟢 Middle+ |
| Динамічне програмування | 25% | 🟢 Middle/Senior |
Для Junior Backend достатньо впевнено знати перші чотири категорії. На LeetCode це відповідає задачам рівня Easy і Easy/Medium — близько 50–70 задач за тематичними блоками. NeetCode.io дає готовий план з 75 задач (так звана "Blind 75") саме у такій послідовності.
Junior — "Напишіть функцію яка визначає чи є у рядку всі унікальні символи." Рішення: хеш-сет за O(n). Типово для продуктових компаній.
Junior/Middle — "Дано список доменів з кількістю відвідувань (mail.google.com: 100). Порахуйте агреговані відвідування для кожного субдомену." Це реальна задача Karat — використовується при найманні для Atlassian, Indeed, Intuit.
Middle — "Реалізуйте rate limiter: не більше N запитів за M секунд для одного user_id. Яку структуру даних оберете?" Очікується sliding window + обговорення Redis для distributed варіанту.
Middle/Senior — "Таблиця events (user_id, event_type, created_at). Знайдіть users які зробили подію A, потім в межах 30 хв — подію B, але без події C між ними." Перевіряє window functions і розуміння часових SQL запитів.
Як розбирати задачу на live coding: покроковий приклад
Візьмемо класичну задачу яку ставлять на 80% Junior Backend-інтерв'ю: Two Sum — "дано масив чисел і ціль, знайдіть два числа які в сумі дають ціль, поверніть їх індекси."
seen = {}; for i, num in enumerate(nums): complement = target - num; if complement in seen: return [seen[complement], i]; seen[num] = i — після написання обов'язково перевірте на прикладі з умови вголос: "nums=[2,7,11,15], target=9 → complement=7, seen={2:0}, наступний 7, complement=2, є у seen → return [0,1]. Правильно."
Тижневий план підготовки по рівнях
| Тиждень | Junior (0–1 рік) | Middle (2–4 роки) |
|---|---|---|
| 1 | Arrays + Hash Maps: LeetCode #1, #217, #242, #49, #347 — по 5 задач/день | Системний дизайн: ByteByteGo — URL Shortener, Rate Limiter, Design a Chat System |
| 2 | Stacks + Queues: LeetCode #20, #155, #739 — плюс перший Pramp.com mock | Алгоритми: Graphs (BFS/DFS) + DP базові — LeetCode #200, #207, #322 |
| 3 | Binary Trees: LeetCode #104, #226, #572 — SQL: pgExercises.com розділи JOIN і агрегації | Mock-інтерв'ю: 3 сесії на Pramp.com — запис + аналіз де мовчали більше 10 сек |
| 4 | Повторення слабких місць + 2 mock-інтерв'ю + STAR кейси | Soft skills + питання для інтерв'юера + відгуки по компанії на DOU/Djinni |
Питання по базах даних: SQL, NoSQL і оптимізація на реальних прикладах
Питання по базах даних на технічній співбесіді backend — це майже гарантований блок для будь-якого рівня. Але формат різниться: Junior запитають написати запит, Middle — пояснити план виконання і знайти проблему, Senior — обрати між SQL і NoSQL для конкретного кейсу і обґрунтувати trade-offs.
JOIN (INNER, LEFT, RIGHT), GROUP BY з агрегатними функціями, підзапити та CTE, INDEX (як створити і коли допомагає), EXPLAIN для аналізу запиту, транзакції і рівні ізоляції.
Написати N+1 запит і не помітити, ігнорувати NULL у агрегаціях, не знати різниці між WHERE і HAVING, не розуміти коли індекс не використовується (через функцію у WHERE).
Для NoSQL — достатньо розуміти базові принципи: документна модель (MongoDB), ключ-значення (Redis), коли денормалізація краща за JOIN, і чому горизонтальне масштабування простіше у NoSQL. Питань на рівні адміністрування NoSQL на типовій Backend співбесіді не буде.
Розбір реального SQL питання з інтерв'ю
Ось типова задача яку ставлять Middle Backend у продуктових компаніях: "Є таблиці orders (id, user_id, status, created_at) і order_items (id, order_id, product_id, quantity, price). Знайдіть топ-5 користувачів за загальною сумою завершених замовлень за останні 30 днів."
SELECT user_id, SUM(price) FROM orders JOIN order_items ON orders.id = order_items.order_id WHERE status = 'completed' GROUP BY user_id ORDER BY SUM(price) DESC LIMIT 5;Проблема: немає фільтру по даті, агрегація по ціні не враховує кількість (quantity), і немає індексу — на великій таблиці буде full scan.
SELECT o.user_id, SUM(oi.quantity * oi.price) AS total_amount FROM orders o JOIN order_items oi ON o.id = oi.order_id WHERE o.status = 'completed' AND o.created_at >= NOW() - INTERVAL '30 days' GROUP BY o.user_id ORDER BY total_amount DESC LIMIT 5;Після написання правильний кандидат додає: "Для продакшну додам індекс на (status, created_at) — це покриє обидва фільтри. Якщо таблиця велика, розгляну партиціонування по created_at."
Саме останній коментар про індекс і партиціонування відрізняє Middle від Junior на цьому питанні — код однаковий, мислення різне.
🧠 Задача: який з цих запитів НЕ використає індекс на колонці created_at?
Системний дизайн: як відповідати на архітектурні питання без паніки
Системний дизайн — це блок який розрізняє Middle і Senior. На Junior рівні його рідко перевіряють глибоко, але базові поняття (навіщо кеш, що таке черга повідомлень, яка різниця між вертикальним і горизонтальним масштабуванням) запитують і у початківців.
Типове питання для Middle: "Спроектуйте систему скорочення URL (bit.ly)." Очікується не ідеальне рішення, а структурований підхід за 35–45 хвилин.
Скільки часу готуватись до технічної співбесіди?
Junior без досвіду: 4–6 тижнів по 1.5–2 год/день. Middle з 2+ роками досвіду: 2–3 тижні інтенсивної підготовки з акцентом на системний дизайн і алгоритми які рідко зустрічаються у реальній роботі (динамічне програмування, графи). Senior: 3–4 тижні з фокусом на leadership питання і архітектурні кейси на рівні компанії.
Live coding: як не провалитись коли на тебе дивляться
Live coding — написання коду в реальному часі у спільному редакторі. CoderPad, HackerRank, іноді Google Docs або навіть дошка. Найбільша помилка — мовчати. Якщо ви мовчите 5 хвилин, інтерв'юер не знає що відбувається у вашій голові: чи думаєте ви, чи зависли, чи взагалі зрозуміли задачу.
"Я бачу що нам потрібно знайти підмасив з максимальною сумою. Спочатку подумаю про brute force за O(n²), потім спробуємо Kadane's algorithm за O(n)..." — думайте вголос навіть якщо не впевнені.
Мовчати і просто набирати код. Починати кодити без уточнення вимог. Не перевірити edge cases (порожній масив, null). Не запропонувати тести після написання рішення.
Як тренуватись: Pramp.com — безкоштовні парні mock-інтерв'ю з іншими розробниками. Записуйте себе на відео поки вирішуєте задачу і слухайте — де ви замовкаєте? Саме ці паузи коштують вам офера на реальному інтерв'ю. Interviewbit дає задачі з таймером — симуляція реального формату.
Як звучить live coding коли кандидат завис: до і після
Інтерв'юер: "Дано рядок, знайдіть найдовшу підстроку без повторень."
[мовчанка 2 хвилини, кандидат щось набирає]
Кандидат: "Ось код..." [код не працює на edge case]
Інтерв'юер: "А що буде якщо рядок порожній?"
Кандидат: [пауза 30 сек] "Треба перевірити..."
Результат: відмова. Не через незнання — через відсутність комунікації.
Інтерв'юер: "Дано рядок, знайдіть найдовшу підстроку без повторень."
Кандидат: "Уточню: тільки ASCII чи Unicode? Гаразд. Sliding window: два покажчики left і right, множина для поточних символів. Якщо символ вже є — зсуваємо left. O(n) час і пам'ять. Edge case: порожній рядок → повертаємо 0."
[пише код коментуючи кожен рядок]
"Перевіряю на 'abcabcbb' вголос: right=a,b,c → множина={a,b,c}, right=a, вже є, left зсуваємо... max=3. Правильно."
Результат: оффер. Той самий алгоритм — інша подача.
Готові практикуватись? Знайдіть Backend вакансію на Hoorya
Перевірені вакансії з реальними технічними вимогами — щоб знати до чого готуватись конкретно.
Переглянути всі вакансії →Soft skills питання на тех. співбесіді Backend і як 5-хвилинна підготовка до них підвищує шанс на офер
Soft skills питання є майже завжди — навіть на чисто технічних співбесідах. Для Junior — це перевірка адекватності і здатності вчитись. Для Middle і Senior — здатність приймати рішення в умовах невизначеності, працювати з командою і донести технічне рішення нетехнічній аудиторії.
| Питання | Що насправді перевіряють | Рамка для відповіді |
|---|---|---|
| "Розкажіть про складний баг який ви вирішили" | Процес debugging, комунікацію, наполегливість | STAR: Ситуація → Задача → Дія → Результат |
| "Як ви поводитесь коли не згодні з рішенням команди?" | Вміння конструктивно конфліктувати | Озвучити аргументи → прийняти рішення команди → виконати |
| "Що б ви зробили по-іншому у своєму останньому проекті?" | Рефлексія, самокритика, ріст | Конкретна помилка + конкретний урок + що змінили |
| "Як ви пояснюєте технічні рішення нетехнічним колегам?" | Комунікаційні навички для роботи з PM/клієнтом | Конкретний приклад + аналогія яку ви використали |
Найпоширеніша помилка — давати абстрактні відповіді ("я завжди намагаюсь знайти компроміс"). Інтерв'юер чує це 20 разів на тиждень. Конкретний кейс з деталями завжди виграє у загальної фрази.
Слабка відповідь: "Якось у нас був складний баг з базою даних, я його знайшов і виправив."
Сильна відповідь (STAR): "На проекті онлайн-магазину раз на кілька днів падали замовлення — транзакція починалась але не завершувалась. Ситуація: баг був нестабільний, відтворити вручну не вдавалось. Дія: додав детальне логування на рівні БД і виявив що два запити з різних потоків намагались оновити один запис одночасно — race condition у оновленні статусу. Рішення: додав SELECT FOR UPDATE щоб серіалізувати доступ. Результат: 0 втрачених замовлень за наступні 3 місяці, і ми задокументували патерн для всієї команди."
Деталі (race condition, SELECT FOR UPDATE, конкретні наслідки) показують реальний досвід — загальна фраза не показує нічого.
💬 Яку відповідь дасте на питання "Що для вас найскладніше в роботі Backend розробника"?
✅ Чекліст готовності до технічної співбесіди Backend
Часті питання про технічну співбесіду Backend
Підготовка до технічної співбесіди: план який дає результат
На технічній співбесіді backend оцінюють мислення під тиском і вміння пояснити рішення — так само як і правильну відповідь. Розробники які мовчать 5 хвилин і потім видають ідеальний код програють тим хто думає вголос і помиляється по дорозі.
Діагностика
Зайдіть на LeetCode, виберіть тему Arrays і вирішіть 3 задачі Easy. Не гугліть — просто пишіть і дивіться де зависаєте. Це покаже реальний рівень.
SQL і системний дизайн
Зайдіть на pgExercises.com, пройдіть розділ JOIN. Потім відкрийте YouTube ByteByteGo і подивіться відео "Design a URL Shortener" — це базовий шаблон системного дизайну.
Перше mock-інтерв'ю
Зареєструйтесь на Pramp.com і запишіться на сесію. Записуйте себе на відео. Після — перегляньте де замовкали більш ніж на 10 секунд.
Підготуйте кейси і питання
Запишіть 2 STAR-кейси (складний баг + незгода з командою). Підготуйте 3 питання для інтерв'юера. Знайдіть відгуки про технічне інтерв'ю у вашій цільовій компанії.
Після першого тижня — повторюйте цикл: задачі → mock-інтерв'ю → аналіз слабких місць. Кандидати з правильною підготовкою отримують офери частіше за тих хто просто має більше досвіду.
Готовий до технічного інтерв'ю? Знайди роботу на Hoorya
Перевірені вакансії з чіткими технічними вимогами і реальними зарплатами. Без спаму і застарілих оголошень.
Переглянути всі вакансії →