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

Оце найнеприємніше. Людина після курсів, самонавчання або кількох пет-проєктів дивиться на слово технічна співбесіда і в голові одразу з’являється якась бездонна шафа: алгоритми, бази даних, HTTP, Git, ООП, JavaScript, SQL, тестування, фреймворки, типи даних, архітектура, задачки, питання з підступом, а ще якийсь сеньйор із холодним обличчям, який зараз спитає те, чого ви точно не вчили. І людина робить майже автоматичний висновок: треба довчити все.

Погана новина: все не довчиш.

Хороша: на junior-співбесідах майже ніколи не питають справді все. Зазвичай перевіряють набір повторюваних тем: чи є база, чи ви розумієте свої інструменти, чи можете пояснити логіку, чи не сиплетеся на простих речах, чи здатні думати вголос, чи є в голові хоч якась структура, а не купа уламків після курсів. І от саме тут новачки часто програють не тому, що нічого не знають, а тому, що не розуміють карту перевірки.

Я б не радив готуватися до технічної співбесіди як до лотереї. Це поганий формат. Нерви з’їдає, користі мало. Розумніше зібрати нормальну сітку тем, пройтись по ній, зробити заготовки відповідей, кілька mock interview, розібрати слабкі місця — і вже тоді йти в ринок. Не як на страту. Як на перевірку гіпотези.

Що зазвичай перевіряють у новачка на технічній співбесіді

У більшості junior-інтерв’ю є одна проста логіка: роботодавець не чекає від вас рівня сильного middle. Він хоче зрозуміти, чи ви не випадкова людина, чи зможете вчитися в команді, чи не треба буде пояснювати кожну таску з нуля, чи вмієте ви нормально говорити про те, що вже робили. І це дуже твереза рамка.

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

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

1. Основи мови або основного інструмента

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

Без цього ніяк.

2. Git і робота з кодом або артефактами

Навіть новачка часто питають, що таке commit, branch, merge, pull request, conflict. Не тому, що всі хочуть Git-гуру. А тому, що в реальній команді без Git ви як людина без адреси доставки: наче існуєте, але куди вас підключити — незрозуміло.

3. HTTP, клієнт-сервер і базове розуміння вебу

Особливо для Frontend, Backend, QA і навіть аналітиків у продуктах. Що таке request і response, які бувають статус-коди, чим GET відрізняється від POST, що таке API, JSON, cookies, authentication на базовому рівні. Це не екзотика. Це робоча кухня.

4. Бази даних і SQL

SQL часто питають навіть там, де кандидат думає, що воно йому майже не треба. Простий SELECT, WHERE, JOIN, GROUP BY, агрегатні функції, різниця між INNER JOIN і LEFT JOIN, що таке primary key. Для Data Analyst це серце маршруту. Для QA — дуже бажана база. Для Backend — обов’язково. Для Frontend — не завжди глибоко, але розуміння даних не заважає нікому.

5. Алгоритмічне мислення на простому рівні

У новачків рідко вимагають олімпіадні трюки, якщо це не окрема компанія з жорстким фільтром. Але прості задачі на масиви, рядки, пошук, фільтрацію, підрахунок, сортування, умови — нормальна історія. Тут перевіряють не геніальність, а здатність розкласти задачу і не впасти обличчям у клавіатуру після першого уточнення.

6. Проєкти в резюме

Це болюче місце. Дуже. Якщо в резюме написано pet project, але кандидат не може пояснити, чому зробив саме так, які були проблеми, що б переробив, де зберігаються дані, як працює логіка, що було найскладніше — проєкт перетворюється з аргументу на декорацію. А декорації на співбесіді швидко здуваються.

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

Теми відрізняються. І це добре, бо не треба вчити однаково все для всіх. Нормальна підготовка починається з ролі, а не з панічного списку всіх IT-знань.

Ось тут і починається економія. Якщо ви готуєтесь на Junior QA, вам не треба вчити React так, ніби ви frontend. Якщо ви аналітик, вам не треба зубрити глибоку backend-архітектуру. Якщо ви frontend, вам не треба впадати в нескінченний SQL як у нову релігію. Досить того, що реально підсилює вашу роль і проходження співбесіди.

Типові помилки новачків у підготовці до технічних тем

• Вчать усе підряд. Це виглядає серйозно, але швидко перетворюється на кашу.
• Не тренують відповідь голосом. У голові ніби знаєте, а на співбесіді речення розпадається.
• Не розбирають свої проєкти. А саме їх часто питають найдетальніше.
• Ігнорують прості теми. Бо здається, що треба готувати щось складне. Потім сипляться на базі.
• Не роблять mock interview. І вперше чують свої слабкі місця вже на реальній співбесіді, де ставка вища.

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

Як готуватися розумніше: не зубрити, а збирати відповіді

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

Проста формула відповіді

• Що це таке простими словами.
• Для чого використовується.
• Маленький приклад.
• Типова помилка або обмеження.
• Як ви з цим стикалися в проєкті або практиці.

Наприклад, якщо питають про REST API, не треба одразу лізти в пишномовну лекцію. Достатньо пояснити: клієнт відправляє запит, сервер повертає відповідь, часто у JSON, є методи GET, POST, PUT, DELETE, статус-коди показують результат, у моєму пет-проєкті я тягнув список задач через GET і додавав нову через POST. Все. Живо. Зрозуміло.

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

Скільки тем треба підготувати перед першими співбесідами

Я б дивився не в кількості сторінок, а в кількості сильних відповідей. Для старту часто вистачає 30–50 базових питань по вашій ролі, якщо вони не просто прочитані, а реально проговорені. Плюс 2–3 детально розібрані проєкти. Плюс кілька моків. Плюс чесна таблиця слабких місць.

Оця різниця між читав і готовий — величезна. Курси часто дають перше. Ментор і моки допомагають дотягнути до другого і третього.

Як ментор допомагає з технічними темами

Ментор не повинен просто переказувати вам документацію. Це слабкий формат. Хороший ментор робить інше: бере вашу роль, ваш рівень, ваше резюме, ваші проєкти, вашу тривогу і збирає з цього робочий маршрут під співбесіди. Не абстрактний. Ваш.

• Відсікає теми, які зараз не критичні.
• Показує, де база справді дірява.
• Допомагає зібрати відповіді на часті питання.
• Проводить mock interview і дає не загальне «підтягнися», а конкретний розбір.
• Перевіряє, як ви пояснюєте свої проєкти.
• Допомагає не тільки пройти співбесіду, а й не впасти на випробувальному терміні.

І так, іноді це може коштувати 1–2 майбутні зарплати. Але різниця в тому, що ви платите не за ще одну пачку відео, яку будете дивитися вночі з відчуттям провини. Ви отримуєте людину, якій вигідно, щоб ви дійшли. Маршрут. Зворотний зв’язок. Корекцію. Нормальну людську опору.

Це інша угода.

Що робити вже цього тижня

1. Випишіть свою цільову роль: Junior Frontend, Junior QA, Python Backend, Data Analyst або іншу.
2. Зберіть 30 частих технічних питань саме під цю роль.
3. На кожне питання зробіть відповідь за формулою: визначення, застосування, приклад, помилка, зв’язок із вашим проєктом.
4. Окремо розберіть 2 свої проєкти: що зробили, чому так, які були складнощі, що б покращили.
5. Запишіть себе на відео або аудіо, коли відповідаєте на 5 питань. Неприємно? Так. Корисно? Дуже.
6. Проведіть хоча б один mock interview або зовнішній розбір із ментором чи сильним спеціалістом.

Після цього технічна співбесіда перестає бути магічною кімнатою страху. Вона стає списком перевірок. Не завжди приємних. Але зрозумілих.

Висновок

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

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