Оксана Куценко QA Tech Lead у Pin-up.tech

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

Я проводила десятки інтерв’ю з QA-інженерами різного рівня — від джуніорів, які щойно закінчили курси, до мідлів і сеньйорів з роками досвіду. І з часом я зрозуміла одну просту річ: важливо не те, скільки термінів знає кандидат, а як він мислить, аналізує ситуацію й комунікує.

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

Дуже часто джуніори, які чесно зізнаються, що чогось не знають, але логічно міркують і ставлять уточнювальні запитання — залишають набагато краще враження, ніж більш досвідчені кандидати, які дають «загуглені» відповіді без розуміння базису, на якому вони побудовані.

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

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

СТРУКТУРА ІНТЕРВ'Ю

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

Етап інтерв’ю	Мета	Що включає / Зміст	Ключові акценти (highlight’и)
1. Вступна розмова	Створити комфортну атмосферу, зібрати первинний контекст	▪️ Представлення ▪️ Загальна бесіда про досвід, мотивацію Опис вакансії та очікувань	▪️ Вміння формулювати думки ▪️ Відкритість ▪️ Здатність тримати діалог
2. Теоретична база	Перевірити розуміння основ QA	▪️ Питання про баги, види тестування, життєвий цикл дефекту ▪️ Класичні терміни (напр., severity vs priority)	▪️ Пояснення «своїми словам» ▪️ Приклади з практики ▪️ Розуміння взаємозв’язків
3. Практичні ситуації (case-based)	Перевірити мислення в умовах невизначеності	▪️ Сценарії: баг на проді, продукт без документації, суперечка з девом	▪️ Уточнювальні запитання ▪️ Системність дій ▪️ Підхід до аналізу контексту
4. Технічні інструменти	Визначити реальний досвід користування	▪️ Postman, DevTools, SQL, Jira ▪️ Запитання «як саме використовували»	▪️ Приклади з проєктів ▪️ Не просто «використовував», а «для чого» ▪️ Вміння пояснити дії
5. Критичне мислення	Побачити глибину аналітичного підходу	▪️ Завдання без одного правильного варіанту ▪️ Edge cases, нестандартні сценарії	▪️ Уміння ставити запитання ▪️ Мислення «що піде не так» ▪️ Врахування користувацького контексту
6. Комунікація та soft skills	Перевірити взаємодію з командою, здатність до конструктивного діалогу	▪️ Питання про спілкування з девами, фідбек, конфлікти	▪️ Вміння аргументувати ▪️ Повага, відкритість до фідбеку ▪️ Командність
7. Відкрита частина / Reverse interview	Надати кандидату простір проявити інтерес	▪️ Можливість поставити свої запитання	▪️ Інтерес до продукту / процесів ▪️ Здатність бачити себе частиною команди

ТИПИ ЗАПИТАНЬ, ЯКІ Я ВИКОРИСТОВУЮ

БАЗОВА ТЕОРІЯ ТЕСТУВАННЯ: НЕ ЗУБРІННЯ, А РОЗУМІННЯ

«Я не шукаю завчену ISTQB-термінологію, мені важливо побачити, що людина розуміє, як ці поняття працюють на практиці».

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

Приклади питань:

Що таке баг?
Більшість кандидатів кажуть: «це помилка в програмі» — і на цьому зупиняються. А я чекаю, що людина скаже щось на кшталт:
«Баг — це розбіжність між фактичним і очікуваним результатом. Він може бути як функціональним, так і візуальним, або ж впливати лише в специфічних умовах».
Які бувають види тестування і чим вони відрізняються?
Мені важливо, щоб кандидат не просто назвав види (functional, regression, smoke, exploratory), а пояснив їх суть:
- Functional — перевірка, що функції працюють згідно з вимогами.
- Regression — перевірка, що нові зміни не зламали вже існуючий функціонал.
- Smoke — базова перевірка, що система загалом працює (наприклад, можна залогінитися).
- Exploratory — тестування без чітких сценаріїв, щоб знайти нестандартні помилки.
Чим відрізняється severity від priority?
Це одне з улюблених питань на співбесідах, і тут я дуже швидко бачу, хто дійсно працював з баг-трекером.
Гарна відповідь звучить так:
«Severity — це наскільки серйозно баг впливає на функціональність. Priority — це наскільки швидко його треба виправити з погляду бізнесу чи клієнта. Наприклад, баг із критичним severity може мати низький priority, якщо він трапляється в дуже рідкісних умовах».

На що я звертаю увагу:

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

Порада студентам: не намагайтеся завчити всі терміни. Краще розберіться, як це працює у реальному житті. Уявіть, що ви пояснюєте ці речі другу, який не з IT — якщо зможете це зробити, значить, ви дійсно розумієте.

ПРАКТИЧНІ СИТУАЦІЇ (CASE STUDIES): ТЕСТУВАЛЬНИКА ВИДНО В ДІЇ

«Найкраще видно рівень кандидата, коли він потрапляє в умовну "робочу ситуацію" — не просто відповідає, а діє як інженер».

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

Навіщо це потрібно?

Перевірити практичне мислення: як людина міркує в умовах невизначеності.
Побачити структурність дій: чи є в кандидата системний підхід.
Почути уточнювальні запитання: як людина аналізує контекст перед діями.

Ситуація	Формулювання	Що шукаю / хочу почути	Хороша відповідь
Баг на проді, але не відтворюється у вас	Користувачі скаржаться на помилку у продакшені, але у вашому середовищі все працює. Ваші дії?	▪️ Чи перевіряє кандидат середовища, конфігурації, мову/таймзону ▪️ Чи аналізує логи, мережеві запити, консоль ▪️ Чи зважає на умови відтворення: роль, браузер, авторизація	Я спробую зібрати більше контексту: на якому користувачі, в якому браузері чи ОС. Перевірю, чи однакова версія на проді й тесті. Подивлюсь логи, спробую повторити баг в умовах, наближених до продакшену. Якщо не вдасться — звернуся до продактів або клієнтів за деталями.
Продукт без документації	Ви отримали продукт без специфікацій. З чого почнете тестування?	▪️ Чи починає з UI і функціонального аналізу ▪️ Чи планує комунікацію з BA, девами, PO ▪️ Чи згадує про створення власної документації (mind map, чекліст)	Я спочатку пройду всі основні сценарії вручну, створю картинку того, як працює система. Далі поспілкуюся з бізнес-аналітиком або розробниками. Почну складати свою базу знань і чеклісти. Якщо є схожі фічі — використаю як референс.
Баг від клієнта без підтвердження	Клієнт повідомляє про баг, але у вас немає підтверджень. Як перевірите, чи це справді проблема?	▪️ Чи збирає додаткову інформацію (кроки, дані, браузер, скріншоти) ▪️ Чи комунікує ввічливо, професійно ▪️ Чи відтворює баг в окремому середовищі або edge-case умовах	Я подякую клієнту за зворотний зв’язок і попрошу уточнення: коли виникає баг, що саме робили. Перевірю логи. Спробую відтворити кейс у схожих умовах (той самий браузер, дані, сценарій). Якщо не знайду підтвердження — повідомлю, що триває дослідження; можливо, це edge-case або проблема з даними.

На що я звертаю увагу:

Чи кандидат розбиває завдання на кроки.
Чи ставить уточнювальні запитання перед тим, як почати «щось тестувати».
Чи вміє розглядати альтернативні версії, не зациклюючись на одному варіанті.
Чи розуміє ролі в команді і як комунікувати з ними (BA, дев, PM, клієнт).

Порада студентам: завжди мисліть як детектив. Не кидайтесь одразу «фіксити», не маючи всієї картини. У QA дуже важливо спочатку ставити правильні запитання, а потім діяти.

ІНСТРУМЕНТИ Й ТЕХНІЧНІ ЗНАННЯ: НЕ «ЗНАВ», А КОРИСТУВАВСЯ

«Мене як технічного інтерв’юера не вражає довгий список інструментів у резюме. Я завжди запитую: а як саме ви ними користувались у реальних задачах?»

У багатьох початківців є спокуса заповнити резюме десятками назв: Postman, Fiddler, Charles, Jira, Xray, MySQL, Selenium, Jenkins, Docker, Git... Але коли доходить до практики — виявляється, що ці назви знайомі лише з відео або курсів, а не з реальної роботи.

На співбесіді я завжди намагаюся розпитати не тільки «що використовували», а й «як, для чого, в якому контексті».

ТИПОВІ ЗАПИТАННЯ

Тема / Інструмент	Що питаю / перевіряю	Що хочу почути / шукаю	Гарна відповідь / приклад
Postman (API тестування)	▪️ Які запити будували? ▪️ Чи використовували змінні, колекції, середовища? ▪️ Чи писали автотести (pre-request/test scripts)?	▪️ Глибоке розуміння інструменту, а не просто «користувався» ▪️ Знання вкладок, функцій, підходів до автоматизації	Я використовувала Postman для тестування REST API — створювала GET/POST/PUT/DELETE запити, писала тестові сценарії на вкладці «Tests», перевіряла статус-коди й відповіді. Також запускала серії запитів через collection runner.
DevTools (UI тестування)	▪️ Які вкладки використовували? ▪️ Що саме шукали в консолі? ▪️ Як DevTools допомагали при тестуванні/баг-репортах?	▪️ Уміння працювати з вкладками Console, Network, Elements, Application ▪️ Аналіз HTTP-запитів, помилок, DOM, cookies, localStorage	Для UI — відкривала DevTools, перевіряла помилки в консолі, дивилась вкладку Network, особливо при роботі з логінами чи формами. Перевіряла, чи відправляється форма, чи є помилки 4xx/5xx. DOM використовувала для локаторів.
SQL (робота з БД)	▪️ Для чого використовували SQL? ▪️ Які типи запитів писали самостійно? ▪️ Чи працювали з JOIN / кількома таблицями?	▪️ Здатність писати базові SELECT-запити з WHERE ▪️ Розуміння структури БД ▪️ Вміння перевіряти дані / валідність записів	Я перевіряла, чи зберігаються дані після створення юзера — писала SELECT-запити з WHERE та JOIN, щоб зв’язати user_id і user_profile. Також тестувала edge-case, коли в БД є значення, які не видно в UI, напр. soft-deleted записи.

На що я звертаю увагу:

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

Порада студентам: не намагайтеся вивчити всі інструменти відразу. Краще мати 2–3, але знати їх добре. Наприклад, впевнено працювати з Postman, DevTools і базовим SQL — і цього вже буде достатньо, щоб пройти першу співбесіду.

Порада для менторів: у навчальному проєкті чи портфоліо додавайте приклади, де саме студент використовував інструмент.

КРИТИЧНЕ МИСЛЕННЯ Й УВАЖНІСТЬ: НАВИЧКА, ЯКА ВІДРІЗНЯЄ ДЖУНІОРА ВІД ІНЖЕНЕРА

«Це той розділ, на якому часто завалюються навіть сильні кандидати — не тому, що не знають, а тому, що не задумуються про те, що може піти не так».

Коли кандидат правильно відповідає на теоретичні та практичні запитання, наступний етап — це перевірка глибини мислення. Я даю задачі, які не мають одного правильного варіанта. Тут видно, наскільки QA-інженер вміє мислити на кілька кроків уперед, бачити нетипові сценарії, шукати «діри» в логіці, а не просто «клацати по UI».

ТИПОВІ ЗАПИТАННЯ

Скільки тест-кейсів потрібно для перевірки поля «вік»?

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

Що хочу почути:

Чи кандидат одразу ставить уточнювальні запитання: «Який дозволений діапазон?», «Поле обов’язкове?», «Ціле число чи десяткове?», «Мінімальний і максимальний вік?», «Чи залежить від країни?».
Чи враховує:
- Валідні значення (18, 25, 99)
- Граничні значення (17, 100, 0, -1)
- Порожнє поле, символи, великі числа, спецсимволи, пробіли
- SQL-інʼєкції або введення тексту

Гарна відповідь:

«Я б написала тест-кейси для валідних значень (наприклад, 18–99), граничні кейси (17, 100), ввела негативні значення (-1), нуль, порожнє поле, текст, спецсимволи, десяткові значення, дуже велике число (наприклад, 9999). Також перевірила б обробку копіювання/вставки, валідацію на клієнті й сервері».

Ви перевірили всі позитивні кейси, але замовник каже, що щось не працює. Ваші дії?

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

На що звертаю увагу:

Чи не починає кандидат одразу захищати себе: «я все перевірив, у мене працює»
Чи намагається зібрати більше деталей: «що саме не працює? яка роль користувача? яке середовище?»
Чи готовий перевірити ще раз, але вже з іншого ракурсу — інші браузери, таймзона, дані, ролі, паралельні дії

Гарна відповідь:

«Я звʼяжусь із замовником, щоб зібрати більше деталей: яка саме дія не працює, чи є скріншот або відео, з якої ролі, який браузер і ОС. Перевірю цей сценарій на кількох середовищах, зверну увагу на логи, час запиту, права доступу. Можливо, я не врахувала edge-case, пов'язаний з конкретними даними або ситуацією, яку не покрили позитивні кейси».

На що я звертаю увагу під час таких питань:

Чи ставить кандидат запитання, а не одразу «діє».
Чи здатен думати критично навіть до власної роботи — «а може, я щось пропустив?».
Чи бачить картину ширше, ніж лише прямолінійний шлях за тест-кейсом.
Чи згадує про бізнес-логіку, а не лише валідацію форми.

Порада студентам: не зупиняйтеся на «позитивний/негативний кейс». Критичне мислення — це ваша основна суперсила як QA. Запитуйте себе:

Що буде, якщо...?
Чи може користувач зробити щось неочікуване?
Чи може система зреагувати по-іншому в іншому контексті?

КОМУНІКАЦІЯ І SOFT SKILLS: БАГ САМ СЕБЕ НЕ ПОЯСНИТЬ

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

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

Тому на співбесіді я обов’язково ставлю ситуаційні питання, які показують рівень комунікації та емоційного інтелекту.

ТИПОВІ ЗАПИТАННЯ

Запитання / Ситуація	Що оцінюється / На що звертаю увагу	Гарна відповідь / Очікувана поведінка
Як ви повідомляєте розробнику про баг?	▪️ Стиль комунікації: конструктивний чи звинувачувальний ▪️ Чи описує факти без емоцій ▪️ Чи є посилання на вимоги ▪️ Чи дотримується етики	Я спочатку перевіряю, чи можу відтворити баг стабільно. Додаю чіткий опис, кроки, очікувану і фактичну поведінку, скріншот або відео. Уникаю звинувачень. У спілкуванні фокусуюся на вирішенні, а не на винних.
Що зробите, якщо розробник не погоджується з багом?	▪️ Здатність аргументувати, не конфліктуючи ▪️ Посилання на документацію, UX, очікування ▪️ Вміння шукати компроміс: звернення до PO, аналітика	Я з повагою вислухаю аргументи розробника. Якщо він вважає, що це не баг, поясню, чому з погляду користувача це виглядає як помилка. Якщо не домовимось — підключу продакта або BA для спільного рішення.
Як ви реагуєте на критику ваших тестів або підходу?	▪️ Рівень зрілості ▪️ Сприйняття фідбеку: конструктивно чи як атаку ▪️ Вміння пояснювати свій підхід без агресії ▪️ Готовність визнавати помилки	Якщо отримую зауваження — аналізую, чи є у цьому сенс. Якщо справді щось можна покращити — вдячна за фідбек. Якщо не згодна — пояснюю свій підхід. Але завжди відкрита до діалогу.

На що я звертаю увагу:

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

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

Типові фрази, які насторожують:

«Це я ще не вчив» — замість «Я не знаю, але спробую логічно подумати»
«Я все покрив автотестами» — без пояснення, що саме і чому
«У нас це не тестували» — без спроби описати, як би протестував сам

Порада для новачків:

Не бійтеся сказати «не знаю», якщо це щиро. Але обов’язково додайте: «я б спробував так-то…»
Інтерв’ю — це розмова, не допит. Важливо показати мислення, а не ідеальну памʼять.

ЧЕКЛІСТ: ЩО ВАРТО ПОВТОРИТИ ПЕРЕД СПІВБЕСІДОЮ НА ПОЗИЦІЮ QA-ДЖУНІОРА

Цей чекліст допоможе структурувати підготовку за 1-2 дні до технічної співбесіди:

Теорія тестування