Англійська на співбесіді

Де в процесі найму взагалі спливає англійська?

Майже скрізь, і майже ніколи — окремим іспитом з граматики. Перша точка тиха: резюме й публічний профіль, де машинний переклад видає рівень швидше за будь-яку мітку поруч. Далі йде скринінг, на якому рекрутер часто на кілька хвилин перемикає розмову на англійську. Іноді компанія додає окремий короткий дзвінок про мову — з HR або лідом. На технічній співбесіді мова стає фоновим навантаженням: ти одночасно думаєш над суттю відповіді й будуєш її іноземною. В аутсорсі й аутстафі фінальним етапом часто стоїть розмова із замовником, а за нею — щоденна робота тією ж мовою. Практичний висновок: готуватися треба не до тесту, а до робочої розмови, бо саме нею тебе й перевірятимуть.

Що саме оцінюють на мовній частині — граматику чи щось інше?

Оцінюють придатність працювати, а не відповідність шкільній нормі. Розкладається це на кілька спостережуваних речей: чи ловиш ти питання з першого разу, чи тримаєш темп без довгих зависань і чи вмієш перефразувати думку, коли потрібне слово не згадалося. Часи дієслів і артиклі при цьому нікого особливо не цікавлять, доки твоя думка доходить з першого разу. Звідси неочевидний, але стабільний результат: кандидат із кривими формами, який усе ж пояснює свою позицію, майже завжди обходить того, хто зі страху помилитися мовчить. Для QA логіка ще прозоріша: твоя робота — уточнити вимогу на дзвінку й описати дефект так, щоб його зрозуміли однозначно, і саме цю здатність намагаються побачити.

Рекрутер посеред україномовної розмови раптом перейшов на англійську. Що це і як реагувати?

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

Що насправді означає мітка рівня англійської в профілі кандидата?

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

У профілі мітки на кшталт Intermediate, а в вакансіях пишуть B2. Це одне й те саме?

Це два різні переліки, які ринок уживає поруч. Фільтр Djinni на публічному зрізі зарплат перелічує вісім значень — No English, Beginner/Elementary, Pre-Intermediate, Intermediate, Upper-Intermediate, Advanced/Fluent, Proficient, Native Speaker (такий вигляд сторінка мала 2026-07-26), і жодного означення до них не дає. Позначення A2, B1, B2, C1 належать зовсім іншій системі — шкалі авторства Ради Європи (Common European Framework of Reference for Languages, CEFR). Зіставити їх одне з одним по-чесному ми не можемо, і зміст рівнів CEFR теж не переказуємо свідомо: шість адрес Ради Європи, перевірених 2026-07-26, віддали 403 — включно зі сторінкою самої шкали, і скрізь замість тексту стояла заглушка антибот-захисту. Підставляти чийсь переказ замість першоджерела гірше, ніж чесно сказати, що рівні тут лишаються назвами без опису. Для співбесіди це не проблема: рівень усе одно звірятимуть розмовою, а не буквою в анкеті.

Який рівень англійської реально потрібен QA-інженеру?

За нашим зрізом ринку, більшість QA-вакансій закриває приблизно Intermediate–Upper-Intermediate: цього вистачає, щоб пройти скринінг і зрозуміло розповісти про свою роботу. Нижче цієї смуги вибір звужується до україномовних команд, де вся англійська зводиться до листування й читання тікетів. Вище відкриваються ролі з прямим виходом на замовника, де мова вже частина щоденних обовʼязків. Важлива обмовка: стандарту під такий поріг не існує, це узагальнення практики, а не норма, на яку можна послатися. Тому корисніше дивитися не на смугу, а на конкретну вакансію: якщо там щоденні дзвінки з клієнтом, «читаю документацію» не закриє питання.

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

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

Навіщо тестувальнику глосарій ISTQB, якщо терміни й так знайомі?

Бо концептуально ти справді все це знаєш українською — бракує лише англійських ярликів, і ось їх канон і роздає. Глосарій ISTQB містить 651 термін із дослівними означеннями, і сама організація подає свою термінологію як де-факто мову галузі (це самоопис, а не незалежна оцінка, але для звірки формулювань зручно). Найцінніша його роль на співбесіді — не перекладач, а арбітр: він показує, яких розхожих слів у каноні немає взагалі. Наприклад, ані грейдів на кшталт junior, middle, senior, ані лексики найму ти там не знайдеш — і правильно, бо до термінології тестування вони не належать. Практичний хід перед дзвінком: звірити з глосарієм ті пʼять-шість слів, які ти вживатимеш найчастіше.

Як правильно назвати перевірку того, що дефект справді полагодили?

confirmation testing — саме так це називається в каноні: після фікса перевіряють, чи не відтворюється відмова знову. Слова retesting, яке в розмові вживають постійно, у глосарії немає взагалі — воно живе в робочому жаргоні, а не в термінології. Плутати це з регресією не варто: regression testing за означенням стосується незмінених ділянок, і дефекти там бувають як внесені змінами, так і просто виявлені (introduced or uncovered). Тобто одна перевірка дивиться в точку фікса, а друга — навколо неї. На співбесіді ця пара розводиться однією фразою, і сказана вона канонічними словами звучить помітно переконливіше.

Чи можна на співбесіді казати bug?

У розмові — так, тебе всі зрозуміють, але варто знати статус цього слова. Самостійного терміна bug глосарій ISTQB не має: дефект називається defect. Саме слово трапляється в каноні тільки всередині двох сполук — bug bash та bug hunting, — і жодна з них дефекту не позначає. Практична межа проста: у живій мові bug доречний, у документах і формальних відповідях краще defect, і різницю варто вміти пояснити, якщо запитають. Це якраз той дрібний сигнал, який відрізняє кандидата, що читав канон, від кандидата, що переказує чужі слова.

Поясніть різницю між severity і priority.

Це властивості різних обʼєктів, і саме звідси все випливає. severity — це degree of impact, тобто ступінь впливу дефекту на розробку, тестування чи роботу компонента або системи. priority — це рівень важливості, приписаний задачі за певними критеріями. Тобто одне характеризує сам дефект, а друге — роботу, яку через нього треба зробити, і тому одне з іншого автоматично не виводиться. Класична ілюстрація: помилка в назві компанії на головній сторінці впливає на систему мінімально, а виправляють її першою, бо вона на очах у всіх. Зворотний випадок теж буває: важкий дефект у рідкісному сценарії може почекати релізу.

Що має бути в test case за означенням канону?

Означення перелічує пʼять складників: preconditions, inputs, actions (де застосовно), expected results і postconditions, і все це розробляється на основі тестових умов (test conditions). Звідси, до речі, і пара, яку питають окремо: expected result проти actual result — очікуваний результат приходить з кейса, фактичний зʼявляється під час прогону, а їхня розбіжність і є те, що ти описуєш у дефекті. Знати цей перелік англійською корисніше, ніж здається: він одразу дає каркас відповіді на питання «як ви пишете тест-кейси» і водночас показує, звідки береться структура баг-репорта.

Яка мета smoke-тестування за каноном?

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

Як побудувати відповідь на «Tell me about yourself»?

Це не біографія, а коротка усна довідка про твій досвід, зібрана під конкретну вакансію, — і саме тут провалюються найчастіше, починаючи розповідь від школи. Каркас працює той самий, що й на україномовному скринінгу, і складається з трьох блоків. Перший — теперішнє: хто ти зараз і чим займаєшся щодня, тобто роль, роки досвіду, тип тестування. Другий — минуле, і в ньому лише те, що працює на цю позицію. Третій — майбутнє: чому ти подався сюди й куди рухаєшся. Три блоки вкладаються у дві хвилини й дають інтервʼюеру одразу три речі: твій рівень мови, логіку кар'єрного переходу та звʼязок із вакансією. Усе інше — на уточнювальні питання, які після такої відповіді обовʼязково будуть.

Чому не варто вчити самопрезентацію напамʼять?

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

Що робити, якщо не зрозумів питання англійською?

Перепитати. Мовну частину зазвичай топить не бідний словник, а ступор: пропустив одне слово, завмер — і решта питання пролітає повз. Носії перепитують постійно, і оцінюють тут не безпомилкове розуміння з першого разу, а те, як ти виходиш із ситуації. Фразу треба мати готовою заздалегідь, бо в стресі вона не вигадується: не розчув слово — Sorry, could you repeat that?; не вловив саме формулювання — Could you rephrase that, please?; сумніваєшся у сенсі — Just to clarify, do you mean…?; потрібна секунда на думку — That's a good question, let me think for a moment. Найсильніша з чотирьох — третя: ти сам перефразовуєш питання й просиш підтвердити, тобто робиш рівно те, що QA робить щодня з вимогами. І памʼятай про паузи: заповнена звучить зібрано, глуха — тривожно.

Чому відповідь навмання гірша за чесне «could you repeat that»?

Бо вона відповідає на питання, якого не ставили, і це читається миттєво. Інтервʼюер робить із цього єдиний можливий висновок: на робочому дзвінку ти так само кивнеш, не зрозумівши вимогу, і зробиш не те — а переробляти доведеться всій команді. Прохання повторити коштує пʼять секунд і жодних балів не знімає; невлучна відповідь коштує довіри. Те саме стосується спроби «догадатися по ключовому слову»: у робочому контексті вгадана вимога дорожча за уточнене питання. Тому єдина заборонена стратегія на English-частині — вдавати, що зрозумів.

Чому зубріння напередодні співбесіди — погана стратегія?

Бо той самий результат обходиться майже вдвічі дорожче за кількістю повторень, і підпирає це не риторика, а цифра з оригінального дослідження. У дослідах Еббінгауза 38 повторень, розкладених на три попередні дні, дали такий самий ефект відтворення, що й 68 повторень, втиснутих в останній день. Там же крива забування у числах: за годину на відновлення матеріалу йде близько половини первинної роботи, за добу лишається приблизно третина, за місяць — пʼята частина. Спад далі стає пологим, тому теза «завтра все вилетить із голови» з джерела не випливає. Чесності заради варто знати й обмовку самого автора: свої числа він характеризує як special, individual, and uncertain, а висновок формулює обережно — не «доведено», а лише «припущення стає ймовірним». Практичний висновок для підготовки все одно однозначний: три коротші сесії краще за одну нічну.

Що таке рознесене повторення і як укласти в нього два тижні підготовки?

Рознесене повторення (spaced repetition) — це режим, у якому нові й важчі одиниці показують частіше, а вже засвоєні — рідше. Стосовно мови правило звучить так: інтервал залежить не від календаря, а від того, наскільки погано йде конкретна одиниця, — фраза, на якій ти щоразу спотикаєшся, має повертатися помітно частіше за ту, що вилітає автоматично. Друге правило не менш важливе: рознесення працює в парі з ефектом тестування (testing effect), тобто повторення має бути пригадуванням, а не перечитуванням конспекту. Популярний розклад «день / два / чотири / вісім» використовувати можна, але приписувати його Еббінгаузу не варто: він походить від Mace (1932) у викладі Wikipedia, а в самого Еббінгауза інтервал експерименту був один — 24 години. Наповнення цих повторень для English-скринінгу цілком передбачуване: відрепетирувані вголос відповіді, лексика всередині цілих фраз і жива мок-співбесіда.

До дзвінка два тижні, а вакансія вимагає впевненої розмови. Що робити?

Насамперед тверезо порахувати розрив. За два тижні змінюється готовність до конкретної співбесіди, але не рівень мови — це робота на місяці, і жоден інтенсив цього не обходить. Якщо ти жодного разу не говорив англійською вголос, а на позиції щоденні дзвінки із замовником, чесніше визнати, що ця вакансія не твоя зараз, і паралельно подавати заявки під свій реальний рівень. Те, що в два тижні справді вкладається: опорні блоки самопрезентації, десяток робочих фраз, вивчених цілими шматками, щоденне говоріння вголос із записом і переслуховуванням, слухання англомовного QA-контенту для звикання до темпу (цей прийом називають comprehensible input) і одна-дві живі мок-співбесіди з людиною, яка ставить питання й перебиває. Останнє дає найбільший приріст на одиницю часу, бо відтворює саме ту ситуацію, у якій ти маєш не завмерти.

Три розбори типових моментів English-дзвінка: та сама відповідь на «Tell me about yourself» у слабкій і сильній подачі, таблиця рішень для моменту «не розчув питання» і звірка розмовної лексики з каноном перед розповіддю про дефект. Скрізь — що з цього чує інтервʼюер.

Кейс 1. «Tell me about yourself»: одна людина, дві подачі

На цьому питанні легко витратити дві хвилини намарно. Вступна однакова: мануальний QA з трьома роками досвіду подається на позицію з тестування API у продуктову команду.

Слабка подача:

«So, I was born in Kharkiv and studied economics at university. After that I worked in a shop for two years, then in a call center, it was not very interesting. Then my friend told me about QA courses, so I finished the courses in 2023 and started to work as a tester. I like my job. Yes, that's all, I think.»

Тут є хронологія і немає нічого потрібного: рівня не видно, звʼязку з вакансією немає, а фінал розсипається на «that's all». Інтервʼюер отримав біографію замість анотації досвіду.

Сильна подача — ті самі факти, розкладені на три блоки:

• Теперішнє: I'm a manual QA engineer, three years on a fintech web product. Most of my day is API testing in Postman, release regression, and going through requirements with the business analyst.
• Минуле: I came to QA from a call center, so I'm used to reproducing user problems and describing them clearly — that's where my defect reports come from.
• Майбутнє: What I want next is a product-focused team with strong API coverage, because my goal is to move from manual API checks to automated ones — I've already started learning Playwright with TypeScript.

Три блоки, приблизно дві хвилини — і інтервʼюер одразу має рівень мови, логіку переходу в професію та причину, чому ти тут. Ще одна перевага: така відповідь витримує перебивання. На репліку Which tools do you use for API testing? сильна подача просто розгортає перший блок і повертається в каркас, тоді як завчений напамʼять текст після такого питання зазвичай починається спочатку або зупиняється зовсім.

Кейс 2. Не розчув питання: таблиця рішень і два фінали

Ситуація стандартна: дзвінок із лідом, питання прилітає швидко, одне слово в ньому пролетіло повз. Перше, що треба зрозуміти, — рішення тут чотири, а не два («зрозумів» / «пропав»), і кожне читається інтервʼюером по-своєму.

Тепер той самий момент у двох фіналах. Питання: How do you decide what goes into the regression suite when the release window is tight? Кандидат не розчув regression suite.

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

Фінал другий. Кандидат бере паузу й перефразовує:

— Just to clarify, do you mean how I choose which tests to run before a release when there isn't much time?

— Exactly.

— Then I start from risk: payments, login and checkout always go in, and cosmetic checks can wait. I also tell the team what stays untested, so the release decision is a conscious one.

Пʼять секунд на уточнення купили влучну відповідь і заодно продемонстрували навичку, яку в QA цінують окремо. Єдина справді заборонена стратегія — вдавати, що зрозумів.

Кейс 3. Розповідь про дефект англійською: звірка лексики з каноном

Питання Tell me about an interesting bug you found — це коротка історія за форматом STAR, і провалюють її не граматикою, а словником: кальки з української чути одразу, а розхожі слова часто не збігаються з тим, що каже канон. Перед дзвінком варто пройтися по власних формулюваннях таким списком.

Готова відповідь із правильними ярликами звучить приблизно так:

The most interesting defect I found was a double charge on the payment form. The steps to reproduce were simple: throttle the network and click «Pay» twice. Expected result — one payment; actual result — two identical requests and two charges. I filed it as a blocker with clear steps and a video, and the root cause turned out to be a missing button lock on the front end. As a workaround, support cancelled the second charge manually until the fix was released. After the fix I ran confirmation testing and added the case to the regression suite.

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

Де перевіряють і що оцінюють

• Можу перелічити точки, де мова спливає в наймі: профіль і резюме, скринінг рекрутера, окремий English-дзвінок, технічна співбесіда, розмова із замовником — окремого іспиту з граматики зазвичай немає.
• Знаю, що оцінюють насамперед сприйняття на слух і плавність мовлення, а не правильність граматичних форм: чи ловлю питання з першого разу, чи тримаю темп і чи вмію перефразувати думку, коли забув слово, — і чому мова з помилками виграє в боязкого мовчання.
• Розумію, навіщо рекрутер перемикається на англійську без попередження, і маю план на цей момент: пауза, за потреби одне уточнення, спокійний темп.

Рівні й мітки

• Знаю, що мітка рівня в профілі — самооцінка кандидата: означень до своїх міток майданчик не публікує, це значення фільтра, а не критерії, і на дзвінку їх звіряють голосом.
• Не плутаю перелік міток майданчика (від No English до Native Speaker) зі шкалою CEFR авторства Ради Європи, до якої належать A2, B1, B2, C1; зміст рівнів CEFR ми не переказуємо, бо першоджерело недоступне: шість адрес Ради Європи, перевірених 2026-07-26, віддали 403.
• Памʼятаю практичний поріг більшості QA-вакансій — приблизно Intermediate–Upper-Intermediate — і те, що це наш зріз ринку, а не стандарт; і не плутаю пасивне розуміння з робочою мовою.

Лексика за глосарієм ISTQB

• Памʼятаю, що глосарій — 651 термін із дослівними означеннями, і вживаю його як арбітра: знаю різницю retesting vs confirmation testing — першого в каноні немає взагалі, канонічна назва перевірки після фікса — друга.
• Знаю статус слова bug: самостійного терміна канон не має, дефект — це defect, а саме слово трапляється тільки всередині сполук bug bash та bug hunting.
• Розводжу severity і priority за обʼєктом: перша описує вплив дефекту, друга — важливість задачі, тому одна з іншої не виводиться.
• Можу відтворити близько до канону три означення: regression testing (незмінені ділянки, дефекти introduced or uncovered), test case (передумови, входи, дії, очікувані результати, постумови) і smoke testing (достатня впевненість, що обʼєкт можна віддавати в заплановане тестування).
• Тримаю напоготові робочий мінімум фраз: steps to reproduce, blocker, workaround, root cause, статуси duplicate, won't fix, can't reproduce, а також test suite, acceptance criteria, edge case, happy path, coverage, requirement, user story, standup, backlog, release, rollback, staging проти production.

Розмовні пастки

• Знаю фальшивих друзів: actual перекладається як «фактичний» (не «актуальний»), а eventually — як «врешті-решт» (не «можливо»).
• Не кажу make a test (правильно write або run a test), дефект заводжу дієсловами file, report, raise, і перевірив вимову suite («світ») та queue («кʼю»).

Самопрезентація і передбачувані питання

• Маю каркас відповіді на «Tell me about yourself» на дві хвилини — теперішнє, минуле, майбутнє з привʼязкою до вакансії, а не до біографії — і тримаю його опорними блоками, а не завченим текстом, щоб уточнювальне питання не вибило з колії.
• Відрепетирував передбачувані питання English-частини: типовий робочий день, цікавий знайдений дефект (міні-історія за форматом STAR), чому QA, чому шукаю роботу, сильні й слабкі сторони — і маю щонайменше одне власне питання англійською.

Коли не зрозумів

• Маю чотири фрази під чотири ситуації (could you repeat that, could you rephrase that, just to clarify, do you mean…, let me think for a moment) і знаю, чому найкорисніша третя: непорозуміння знімається, а заразом видно щоденну навичку QA — звіряти, чи правильно зрозуміла вимогу.
• Ніколи не відповідаю навмання: невлучна відповідь — гірший сигнал, ніж чесний перепит, бо обіцяє те саме кивання на робочих дзвінках.

Режим підготовки

• Памʼятаю число проти зубріння: 38 повторень, розкладених на три дні, дорівняли 68 повторенням в останній день; і знаю, що розклад «день / два / чотири / вісім» належить Mace (1932), а не Еббінгаузу.
• Розумію правило рознесення: важче й новіше — частіше, засвоєне — рідше, а саме повторення має бути пригадуванням, не перечитуванням.
• Вчу лексику всередині цілих фраз, говорю вголос щодня із записом, слухаю англомовний QA-контент і планую живу мок-співбесіду — і тверезо оцінюю розрив, якщо вакансія вимагає більше, ніж я маю зараз.