Як я зробив тренажер співбесід для дизайнерів

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

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

В англомовному середовищі є практика Always Be Interviewing: ходити на співбесіди регулярно, навіть коли робота є. Ідея в тому, що співбесіда це окрема навичка, а не побічний ефект досвіду. Її треба тримати в тонусі. Плюс бачиш, що зараз питає ринок.

Мені це зайшло, але з одним але. Реальних співбесід стільки не набереш, а ходити на них заради тренування означає витрачати час. Відео і списки «100 питань з продуктових інтерв’ю» теж не рятують. Ви читаєте питання, киваєте, погоджуєтесь із собою в голові і йдете далі. А відтворити ту саму думку вголос, коли хтось задає уточнюючі питання, це зовсім інша вправа.

Так з’явився VoiceMock. Обираєте роль (поки лише Product Designer), тип челенджу й індустрію, отримуєте згенероване питання і далі просто розмовляєте. Вголос. Із зустрічними питаннями. У кінці оцінка за розбором.

Що означає «зробив сам»

Для продуктового дизайнера різниця тут одна. Зазвичай ти доводиш рішення до макета, віддаєш у розробку і бачиш його вже в релізі. Тут по іншому.

В індустрії цю роль називають design engineer. Людина на стику дизайну й розробки, яка скорочує передачу між ними і доводить рішення до продакшену. У великій команді це окрема позиція. У пет-проєкті чи власному стартапі вона виходить сама собою. Флоу, логіка оцінювання, схема даних, скоуп лишаються в одних руках. Соло ти тримаєш цілісність рішення від макета до релізу, нічого не губиться по дорозі. Команда дає інше: чужий погляд, який ловить те, чого ти в своєму рішенні вже не бачиш. Тут цього немає, тому помилки вирішуєш сам.

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

Іноді це швидше. А іноді означає, що обидва рішення помилкові і нема кому зловити це на рев’ю. Тепер про те, що в мене в результаті вийшло.

Спершу продукт був тестовим

Довго вся частина «після співбесіди» виглядала так: ви закінчуєте, отримуєте літеру A, B або C і короткий перелік того, що варто покращити. Ні історії, ні прогресу, ні підказки, що робити далі.

Це була не лінь. Я не хотів вкладатись у щось складніше, поки не знав, чи продукт узагалі комусь потрібен.

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

Потім стало видно, що люди повертаються. Ретеншн поки невеликий, але продукт просувався двома постами в LinkedIn та Тредс.

Чому оцінки за одну співбесіду замало?

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

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

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

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

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

Мапінг довелось переробляти двічі. Урок звідти один: критерій треба класти не туди, куди тягне його назва, а туди, куди вказує його визначення.

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

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

Після обох перенесень жоден тип челенджу більше не звужується в одну вісь.

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

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

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

Де тут AI, а де звичайний код

AI (у мене це Gemini) робить три роботи: генерує питання на етапі налаштування, виконує роль інтерв’юера під час розмови і оцінює транскрипт у кінці. На цьому все.

Що глибше — зведення критеріїв в осі, вибір наступної рекомендації, підбір ресурсу під прогалину, фільтрація вакансій — звичайний детермінований код. Порівняння, суми, сортування. Ні другого виклику моделі, ні промпту, нічого ймовірнісного.

Що це дає: наступна дія повністю пояснювана. Я можу показати конкретні рядки, які її породили, і вона видасть ту саму рекомендацію щоразу, коли ви оновите сторінку з тими самими даними. Так я планую інтегрувати AI глибше в критерії щоб зроби профіль більш персоналізованішим, але на цьому етапі це лишні витрати.

А чим це краще, ніж просто поговорити з ChatGPT?

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

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

Є ще один варіант, складніший. Воркфлоу з агентами: Claude Code і Codex працюють не у вікні чату, а у вашій папці: читають і пишуть файли, виконують команди. Постійний контекст там тримається інструкційним файлом, який агент підвантажує на старті кожної сесії. Але це вже інша історія)

Що робити далі

Маючи профіль, порядок пріоритетів однозначний:

1. Є вісь, якої ви не торкались зовсім — ідіть туди. Не тому, що вона найслабша, а тому що повнота профілю залежить від різноманіття типів челенджу, а не від кількості пройдених співбесід. Залишена сама на себе, більшість людей повторює те, що вже вміє: лічильник співбесід росте, решта осей лишається порожньою.
2. Усі осі зачеплені — беріть найслабшу.
3. Ніде особливо не слабко — все одно повторіть найслабшу. Сигналу завжди можна зібрати більше, а одна точка на осі — це ще не вимір.

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

Це можна було б реалізувати, розширивши критерії так, щоб вони покривали ці осі ширше. Але це зламало б порівнюваність із кожною оцінкою, яка вже лежить у базі. Тому наразі це відоме й прийняте обмеження.

І окремо: рекомендація завжди приходить із доказом — балом і місцем цієї осі серед шести. Не «зроби це», а «зроби це, бо в тебе зараз 2.8/5 на невизначеності, шосте місце з шести».

Ресурси, прив’язані до конкретної прогалини

Ідею побачив у підбірці платформ де дизайнер може отримати практику до офера.

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

Окремої сторінки з ресурсами немає навмисне. Ресурс з’являється тільки поруч із прогалиною, яка робить його доречним. У вкладку «Ресурси» мало хто заходить, а ресурс під рядком «ось тут ви слабкі» під конкретну сесію відкриватимуть.

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

І нарешті вакансії

Найновіша частина: живі вакансії з Jooble і DOU під тип челенджу й індустрію, які ви вказали на налаштуванні.

Фільтрація виявилась складнішою, ніж я думав. Пошук за фразою «product design» у назві вакансії радо ловить «Mechanical / Product Design Engineer». Це не дизайнерська робота, вона просто містить потрібні слова. Довелось додавати другий прохід на виключення.

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

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

Речі, які я зробив неправильно

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

Промпти в публічному коді. Я знайшов у себе баг: інструкції, за якими AI веде співбесіду й оцінює людину, потрапляли в публічний код сторінки — тобто будь-хто міг їх відкрити й прочитати. Знайшов це на ранній стадії до першого зовнішнього користувача, проаналізувавши це за допомогою розширення Claude, зараз це роблю вже на пряму з Claude Code через Chrome DevTools MCP

Що досі MVP

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

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

Усе описане вище відкривається безкоштовним входом через Google. Ні пейволу, ні картки: пріоритет зараз — зробити продукт достатньо корисним, щоб люди поверталися й розповідали іншим.

Висновок

Найнесподіваніше в цій історії — не продукт, а те, як швидко вчить збирання власними руками.

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

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

Жодне з цих трьох я б не побачив у Figma.

Спробувати: voice-mock.vercel.app