Яких питань із машинного навчання очікувати на співбесіді?

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

• Основи. Теоретичні питання про навчання, узагальнення й оптимізацію. Інтерв’юер хоче почути, що ви розумієте, чому метод працює, а не завчене визначення.
• Оцінювання та експерименти. Вибір метрики, стратегія валідації, офлайн-результати порівняно з онлайн-результатами й те, як ви спроєктували б експеримент, щоб довести користь моделі.
• Прикладне моделювання. Конструювання ознак, витік даних, дисбаланс класів і складні аспекти реального набору даних. Такі питання часто формулюють на основі одного з ваших проєктів.
• Проєктування ML-систем. Як модель отримує дані, як її навчають і перенавчають, як обслуговуються прогнози та як ви помітили б погіршення її роботи у виробничому середовищі.
• Програмування. Завдання з pandas або звичайного Python, іноді — реалізація з нуля невеликого алгоритму, як-от k-середніх або логістичної регресії.

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

Формулювання різняться між компаніями, але суть питань повторюється. Практикуйте їх, доки не зможете пояснювати все простою мовою.

• Зміщення та дисперсія: Як ви визначили б, чи модель перенавчена або недонавчена, і що змінили б насамперед? Як регуляризація впливає на модель і коли ви віддали б перевагу L1 замість L2?
• Валідація: Чому випадковий поділ на навчальну й тестову вибірки може давати оманливу оцінку для даних часових рядів? Коли потрібна стратифікована або групова крос-валідація?
• Метрики: Коли точність є неправильною метрикою? Поясніть продуктовому менеджеру влучність, повноту й ROC-криву. Яку метрику ви оптимізували б для виявлення шахрайства та за чим стежили б разом із нею?
• Проблеми з даними: Що таке витік цільової змінної і як ви його виявляли? Як упоратися зі значним дисбалансом класів, не вигадуючи дані? Як опрацьовувати пропущені значення, щоб модель випадково не навчилася використовувати сам факт їх відсутності?
• Моделі: Коли дерево з градієнтним бустингом перевершує нейронну мережу на табличних даних? Що насправді обчислює механізм уваги в трансформері? Чому вкладення допомагають із категоріальними ознаками високої кардинальності?
• Оптимізація: Що відбувається, коли швидкість навчання надто висока або надто низька? Чому пакетна нормалізація полегшує навчання?
• Проєктування систем: Спроєктуйте рекомендаційну систему для маркетплейсу. Як ви виявляли б дрейф даних після розгортання? Як перенавчали б модель, не обслуговуючи застарілі прогнози?
• Експерименти: Офлайн-метрика покращилася, але A/B-тест не показав змін; що ви перевірите?

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

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

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

Спеціалістку з даних, яка проходить співбесіду на ML-посаду в компанії-маркетплейсі, запитують, чому її модель ранжування чудово виглядала офлайн, але нічого не змінила в A/B-тесті. Вона відповідає за чотирма кроками: що таке розриви між офлайн- та онлайн-результатами, чому в її випадку причиною стало позиційне зміщення в журналованих даних, яке контрфактичне оцінювання вона додала, а також застерігає, що воно працює лише за достатньої рандомізації журналювання. Така відповідь цінніша за бездоганний математичний вивід. Інструмент імітації співбесіди створено саме для репетиції усних відповідей; він ставить уточнювальні питання так само, як справжній інтерв’юер.

У розмовних раундах — так, але з певними обмеженнями. Нативний застосунок SubcueAI для настільних комп’ютерів із macOS і Windows захоплює системний звук дзвінка та звук із вашого мікрофона, розпізнає питання інтерв’юера в Zoom, Google Meet або Microsoft Teams і показує коротку запропоновану структуру в плавучому накладному вікні, яке бачите лише ви. Для дзвінків у вкладці браузера Chrome або Edge бічна панель розширення захоплює лише звук вкладки зустрічі, тому чує інтерв’юера й ніколи не транскрибує вас. Жоден із цих інтерфейсів не приєднується до дзвінка як бот і нічого не вбудовує в сторінку зустрічі. Якщо ви завантажили резюме, підказки можуть посилатися на ваші власні проєкти, а саме за це високо оцінюють відповіді з ML.

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