4 техніки відповіді на питання інтервʼюера: STAR, PREP, PEEL і Teach-back

Привіт, спільното!

Продовжую писати корисне.

Хто насправді оцінює твою відповідь

За 12 років у рекрутингу я весь час між кандидатом і hiring manager. І бачу обидва боки процесу найму.

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

Що саме зробила ця людина?
Як вона мислить?
Чи можна довірити їй складнішу задачу?

Якщо відповідь на співбесіді хаотична, hiring manager не отримує жодної з трьох з них. Досвід у кандидата є, але зчитати його неможливо. Тому сильні кандидати провалюються не через брак досвіду. Вони провалюються через те, як відповідають.

Що йде не так найчастіше:

Відповідь на «розкажи про випадок…» стрибає з контексту в результат і назад. Hiring manager губить нитку.
У розповіді весь час тільки «ми зробили» і «команда вирішила». Лідити будуть саме цю людину, а її внесок не видно.
На питання «A чи B?» відповідь «ну, десь так, залежить». Немає конкретики і не видно, чи вміє кандидат ухвалювати рішення.
Рішення названо, факт названо, а звʼязку між ними немає. На запит уточнення - «Бо так прийнято». Не видно, як людина ухвалюватиме рішення без керівника поруч.
Завчене наперед визначення, яке розсипається на першому ж уточненні.

Чому я вирішила зібрати ці техніки

Вчити «ідеальні відповіді» не працює. Питання щоразу трохи інші, і завчений текст чутно одразу.

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

Нижче чотири структури. У кожної своя ціль.

1. STAR: коли просять розповісти про випадок із досвіду

Питання звучить як «розкажи про випадок, коли…».

Situation: де це було
Task: що треба було зробити
Action: що зробив саме ти
Result: чим закінчилось

Приклад на питання про конфлікт у команді:

S: два розробники не могли домовитись по архітектурі, реліз горів по дедлайнах.
T: моя задача була розблокувати за день суперечку і знайти рішення.
A: я зібрала обох, вивела рішення на цифри, зафіксувала компроміс письмово.
R: реліз вийшов вчасно, рішення працює досі.

Слабке місце майже завжди Action. Hiring manager наймає тебе, а не команду. Йому треба почути «я»: що ти проаналізував, запропонував, узяв на себе. Result завжди в кінці й з наслідком. «Зробив» не результат. «Зробив, і завдяки цьому X…» результат. Якщо немає цифри, назви ефект: швидше, стабільніше, без повторної помилки.

2. PREP: коли треба зайняти позицію

Питання звучить як «ти б обрав A чи B?». Це не про правильну відповідь. Це перевірка, чи вмієш ти тримати позицію.

Point: твоя теза
Reason: чому саме так
Example: приклад із досвіду
Point: повтор тези на закріплення

Приклад на «моноліт чи мікросервіси для нового продукту?»:

P: на старті я за моноліт.
R: команда мала, гіпотези ще не перевірені, мікросервіси це передчасна складність.
E: у минулому проєкті ми стартували з моноліту й виграли час до першого релізу.
P: тому для раннього продукту моноліт це свідомий вибір, не компроміс.

Спершу відповідь, потім обґрунтування. Hiring manager має за декілька секунд зрозуміти, яка твоя вихідна точка. Друге Point особливо важливе. Саме цю фразу він запише й перекаже команді на дебрифі з рекрутером по кандидатах. Тримати позицію не означає бути впертим. Це показати, що ти думав, а не вгадуєш.

3. PEEL: коли питають «чому саме так?»

Питання звучить як «чому ти обрав цей підхід?». Тут видно різницю між кодером і інженером. Кодер каже «бо так прийнято». Інженер показує звʼязок рішення з наслідком.

Point: рішення, яке ти прийняв
Evidence: на які факти спирався
Explain: чому ці факти ведуть до рішення
Link: як це “вписалось” у продукт чи бізнес

Приклад на «чому кеш, а не оптимізація запиту?»:

P: я поставив кеш на цей ендпоінт.
E: більшість звернень йшли на ті самі дані, база була вузьким місцем.
Ex: кеш знімав навантаження там, де оптимізація запиту дала б менший виграш.
L: інтерфейс став стабільним, і ми не платили за апгрейд бази.

Більшість забуває Explain. Hiring manager не мусить здогадуватись про логіку, він має її почути. А Link відрізняє сеньйора: рішення служить не коду, а продукту й користувачу. Саме це керівник хоче бачити в людині, якій довірить ділянку з завданнями.

4. Teach-back: коли треба пояснити складне простими словами

Завчене визначення сиплеться на першому ж уточненні. Справжнє розуміння - ні. За перші хвилини видно, хто є хто.

Відповідай так, ніби пояснюєш колезі, а не складаєш іспит:

почни з простого визначення своїми словами
додай приклад із життя
тоді переходь до деталей і актуальних випадків

Приклад на «що таке індекс у базі даних?»:

Завчено: «структура даних для швидкого пошуку».

Teach-back: «уяви покажчик у кінці книги. Замість гортати всі сторінки, ти дивишся покажчик і йдеш на потрібну. Індекс те саме для бази. Мінус: його треба оновлювати при кожному записі, тому на частих вставках він не завжди виправданий».

І не бійся сказати «цього не робив, але міркую так…». Для hiring manager хід думки вагоміший за завчену відповідь. Так видно, як людина працюватиме, коли зіткнеться з новою задачею.

У чому різниця і чим це корисно

Усі перелічені техніки це не чотири варіанти однієї відповіді. Це чотири різні задачі. STAR показує, що ти зробив. PREP показує, що ти думаєш. PEEL показує, чому ти так вирішив. Teach-back показує, що ти розумієш.

Структури не треба називати вголос. Їхня мета одна: прибрати хаос відповіді, щоб hiring manager побачив твій досвід і міг обґрунтувати рішення про тебе перед командою.

Як потренуватись: візьми три свої ситуації з роботи й розклади кожну за STAR методом. Запиши відповідь на відео й перевір три речі: чи є теза на початку, чи чутно твоє «я», чи є наслідок у кінці.

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

Питання від мене для тих, хто наймає: що в чужій відповіді вам найважче зчитати - роль, позицію, логіку чи результат?