Новачок боїться технічної співбесіди не тому, що він нічого не знає

Часто він боїться іншого: що його зараз спитають щось випадкове, глибоке, підступне, з темного кутка документації, а він зависне і виглядатиме дурнем. Дуже знайома сцена. Людина пройшла курс, зробила пет-проєкт, трохи писала код, трохи читала SQL, трохи відкривала Git, а потім бачить вакансію Junior і думає: «Мене ж там рознесуть».

І починається погана магія. Відкривається десять вкладок: алгоритми, HTTP, Docker, React, SQL, патерни, ООП, тестування, REST, Git, soft skills. Потім ще одна добірка «1000 питань для junior». Після цього мозок перетворюється на шафу після переїзду: речей багато, знайти потрібне неможливо.

Я б не радив готуватися до технічної співбесіди як до лотереї. Це не казино. У junior-інтерв’ю є повторювана логіка. Зазвичай перевіряють не геніальність, а базу, мислення, здатність пояснювати свої рішення, розуміння власних проєктів і готовність вчитися в команді без постійного ручного водіння.

Це вже легше. Не легко. Але легше.

Що насправді хоче зрозуміти технічний інтерв’юер

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

Погано звучить не фраза «я цього ще не знаю». Погано звучить хаотична спроба зробити вигляд, що знаєте, коли по відповіді видно порожнечу. Інтерв’юери це чують майже одразу.

Універсальні теми, які часто питають у новачків

База мови або основного інструмента

Якщо ви йдете у Frontend, готуйтесь до JavaScript. Якщо в Python Backend — до Python. Якщо в QA — до принципів тестування, баг-репортів, чеклістів, API. Якщо в Data Analyst — до SQL, таблиць, метрик і логіки аналізу. Тут не треба вдавати маленького сеньйора. Але типи даних, функції, умови, цикли, помилки, базові структури, роботу з колекціями треба пояснювати спокійно.

Слабка відповідь виглядає так: «Ну, функція — це коли код працює». Начебто не зовсім неправда, але м’яса немає.

Сильніше: «Функція — це окремий блок коду, який отримує вхідні дані, виконує дію і може повертати результат. Наприклад, у мене в проєкті була функція, яка фільтрувала список задач за статусом». Просто. Живо.

Git і командна робота

Git питають майже всюди, бо без нього ви не дуже підключаєтесь до реального процесу. Commit, branch, merge, pull request, conflict, clone, pull, push — це не прикраса резюме. Це мінімальна грамотність.

Типова помилка: кандидат пише в резюме Git, а на питання «що таке merge conflict?» відповідає щось туманне про «коли гіт не працює». Краще чесно: «Це ситуація, коли дві зміни зачепили один і той самий фрагмент, і Git не може сам вирішити, яку версію залишити. Треба вручну переглянути конфлікт і закомітити виправлення».

HTTP, API і клієнт-сервер

Цей блок часто недооцінюють. А дарма. Навіть якщо ви не backend, вам корисно розуміти, що таке request, response, status code, JSON, GET, POST, PUT, DELETE, authentication, token, cookies. Для QA це щоденний хліб. Для Frontend — міст до API. Для Backend — взагалі кухня.

Питання може бути простим: «Чим GET відрізняється від POST?» Слабка відповідь: «GET отримує, POST відправляє». Нормальний старт, але краще додати: «GET зазвичай використовують для отримання ресурсу і він не має змінювати стан на сервері. POST часто створює новий ресурс або запускає дію. Наприклад, отримати список вакансій — GET, відправити форму відгуку — POST».

SQL і бази даних

SQL часто питають навіть у тих, хто думав, що омине цю тему боком. SELECT, WHERE, JOIN, GROUP BY, COUNT, SUM, primary key, foreign key, різниця між INNER JOIN і LEFT JOIN. Для аналітика це must have. Для backend — теж. Для QA — дуже сильний плюс. Для frontend — хоча б базове розуміння даних корисне.

Не треба одразу лізти в оптимізатор запитів. Але написати простий SELECT із фільтром і пояснити JOIN бажано без паніки.

Ваші проєкти

Ось тут новачки часто горять. У резюме написано: «зробив todo app, інтернет-магазин, Telegram bot, dashboard». А на співбесіді питають: «Чому ви обрали таку структуру? Як зберігаються дані? Яку помилку було найважче виправити? Що б переробили зараз?» І людина раптом розуміє, що проєкт вона ніби робила, але розповісти про нього як про живий досвід не може.

Пет-проєкт має бути не декорацією, а доказом мислення. Маленьким, але чесним.

Що питають залежно від ролі

Не треба готуватися однаково для всіх напрямів. Це типова пастка. Junior QA не має готуватися як frontend, а frontend не має закопуватися в статистику як аналітик. Роль звужує хаос.

Оця таблиця — не весь світ. Але вона дає рамку. А рамка для новачка іноді важливіша за ще один курс, бо без неї навчання розповзається як тісто на теплому столі.

Три помилки, через які підготовка стає болючою і довгою

Помилка 1. Вчити все підряд

Це виглядає відповідально. Насправді часто це страх, замаскований під старанність. Людина не знає, що саме питатимуть, і тому намагається закрити весь горизонт. Через два тижні вона вже втомлена, зла, винна перед собою і все одно не готова.

Помилка 2. Не говорити відповіді вголос

У голові відповідь здається нормальною. На голосі — каша. Це неприємно виявляти, але краще вдома, ніж на реальному техсобесі. Запишіть себе на диктофон, коли відповідаєте на 5 питань. Перший раз може бути кринж. Нічого. Зате чесно.

Помилка 3. Не робити mock interview

Mock interview — це не спектакль. Це технічний краш-тест без реальної ціни провалу. Після одного нормального моку часто стає видно більше, ніж після тижня самостійного читання: де ви плутаєтесь, де говорите надто загально, де проєкт не витримує уточнень, де резюме обіцяє більше, ніж ви можете пояснити.

Як зібрати базу відповідей без зубріння всього підряд

Я б діяв так. Не романтично, зате працює.

1. Виберіть одну цільову роль. Не три. Одну.
2. Зберіть 30–50 частих питань саме під неї.
3. На кожне питання зробіть коротку відповідь за формулою: що це, для чого, приклад, типова помилка, як це було у вашій практиці.
4. Окремо розберіть 2–3 проєкти з резюме.
5. Проведіть 1–2 mock interview.
6. Після кожного моку оновіть список слабких місць і не чіпайте зайві теми, поки не закрили головні.

Це вже схоже на маршрут. Не на нервове плавання в тумані, а на нормальну підготовку. І тут дуже добре видно, чому ментор іноді скорочує шлях: він не просто дає відповіді, а відсікає зайве, ставить черговість, ловить слабкі місця до того, як їх знайде роботодавець.

Приклад: як відповідати на технічне питання сильніше

Питання: «Що таке REST API?»

Слабко: «Це коли frontend спілкується з backend».

Не жахливо. Але дуже тонко.

Краще: «REST API — це спосіб організувати взаємодію клієнта і сервера через HTTP. Клієнт надсилає запит до певного ресурсу, сервер повертає відповідь, часто у JSON. Наприклад, GET /users може повернути список користувачів, а POST /users створити нового. У моєму проєкті я через fetch отримував список задач і показував його в інтерфейсі».

Бачите різницю? Тут є визначення, логіка, приклад і прив’язка до власного досвіду. Не лекція. Не вода. Відповідь.

Коли ментор реально доречний

Не завжди треба одразу купувати супровід. Якщо у вас є чітка роль, хороший план, кілька сильних друзів-розробників, які дадуть чесний фідбек, і ви вже робите моки — ви можете далеко пройти самі. Серйозно.

Але якщо ви третій місяць готуєтесь і не подаєтесь, не можете пояснити свої проєкти, не знаєте, які теми головні, після кожної відмови тікаєте в новий курс, тоді зовнішня рамка стає дуже раціональною. Ментор може допомогти зібрати roadmap, поправити резюме, сформувати легенду кандидата, провести технічний мок, розібрати HR-відповіді, побудувати воронку відгуків і підтримати на випробувальному терміні.

Це не чарівна паличка. Але це може бути помітно вищий шанс результату, умовно до 80%, якщо ви реально виконуєте роботу, а не просто грієтесь біля сильнішої людини. І так, супровід може коштувати 1–2 майбутні зарплати. Питання не в ціні самій по собі. Питання в тому, чи купуєте ви ще одну теорію без результату, чи живий маршрут із корекцією помилок.

Що зробити цього тижня без покупки

• Випишіть 20 вакансій на вашу роль і підкресліть повторювані вимоги.
• Зробіть список із 40 питань, які найчастіше збігаються з цими вимогами.
• На 10 питань запишіть відповіді голосом.
• Візьміть один проєкт із резюме і поясніть його за схемою: задача, стек, ваша роль, складність, рішення, що б покращили.
• Попросіть когось провести короткий мок на 30 хвилин. Якщо нема кого — запишіть себе самі і переслухайте без жалю, але й без самобичування.

Після цього страх не зникне повністю. І не треба чекати, що зникне. Але він стане конкретнішим. А конкретний страх уже можна розбирати, як баг у коді: відтворити, знайти місце, поправити, перевірити ще раз.

Коротко по-людськи

На технічних співбесідах у новачків найчастіше питають базу ролі, основи мови або інструмента, Git, HTTP, API, SQL, просту логіку задач і власні проєкти. Найбільша проблема не в тому, що цих тем неможливо вивчити. Проблема в хаосі: люди вчать усе підряд, не тренують відповіді голосом, не роблять mock interview і не розуміють, як виглядають очима інтерв’юера.

Я б не героїзував підготовку. Її треба не роздувати, а збирати. Роль, список питань, відповіді, проєкти, моки, резюме, воронка. Оце вже маршрут. А якщо самому його зібрати важко, ментор тут не як «ще один викладач», а як людина, яка допомагає не витратити пів року на блукання між страхом, курсами і випадковими порадами з інтернету.