Як проходить співбесіда з дата-інженерами, та які питання їм ставлять? Цього разу досвідом проведення інтервʼю ділиться Solidgate, партнерська компанія Genesis. Це фінтех-екосистема, яка надає онлайн-бізнесам можливість приймати платежі по всьому світу. Місія компанії — зробити так, щоб онлайн-підприємці могли будувати мільярдні компанії завдяки швидкому виходу на міжнародний ринок.
Тетяна Лелюх, Data Engineering Lead в Solidgate, розповіла, як проходять співбесіди дата-інженерів у команду компанії. Вона поділилася головними компетенціями, які шукають у кандидатах, як проводити інтервʼю, щоби у людей не було враження іспиту, як адаптувати запитання під досвід, та чому краще вивчати юзкейси ніж визначення термінів, готуючись до співбесіди. У кінці статті бонус — підбірка актуальних вакансій у технічну команду Solidgate.
> Як проходять співбесіди з дата-інженерами
> Компетенції для Junior та Middle Data Engineer
> Питання для дата-інженера (Junior / Middle)
> Софт-скіли дата-інженера
> Поради кандидатам
Як проходять співбесіди з дата-інженерами
Процес найму в Solidgate складається із чотирьох етапів. Перший з них — це спілкування із рекрутером, який відбирає кандидатів за релевантністю хард- та софт-скілів, а також відсутністю red flags.
Другий етап — технічна співбесіда, де ми обговорюємо технічні питання, досвід та професійний шлях кандидата. Коли людина ділиться, чому прийняла те чи інше рішення, як обирала попередні компанії тощо, це дає змогу скласти певний портрет, зрозуміти її рівень мотивації та відповідальності. Водночас фокус цього етапу — технічний. Я намагаюся вести розмову у форматі діалогу, щоби це не було схоже на іспит чи опитування, і людина себе почувала комфортно. На початку інтерв'ю попереджаю, що можу перебивати та зупиняти, щоби глибше розкрити досвід кандидата, та пропоную також зупиняти мене і ставити додаткові питання, якщо не вистачає контексту.
Ми маємо підбірку базових питань, які стосуються необхідних компетенцій. Водночас співбесіда зазвичай проходить індивідуально, і скоуп запитань формується під професійний шлях людини.
Третій етап — тестове завдання. Ми намагаємося скоротити його до мінімуму, щоби виконання не займало більше чотирьох-шести годин. Для джуніорів воно більш розширене та загальне, для мідлів — менше за розміром, але технічно складніше.
Четвертий етап — співбесіда з C-Level або технічним менеджментом, який перевіряє людину на відповідність Culture Fit — наскільки кандидат відповідає процесам та культурі компанії.
Компетенції для Junior та Middle Data Engineer
Загалом компетенції й відповідно теми для запитань на технічній співбесіді однакові для всіх ґрейдів. Різниця в тому, що для джуніор-кандидатів вони більш загальні. У мідлів ми перевіряємо глибину знань, тому ставимо питання, які не можна легко нагуглити, або які стосуються їхнього особистого досвіду. Наприклад, якщо ми говоримо про Python, то у джуна я питаю, які йому відомі методи в певній бібліотеці, щоби зрозуміти, чи людина працювала з бібліотекою вдумливо чи просто користувалася шаблонними рішеннями з гугла. У мідла я спитаю власну думку про цю мову: що подобається, які бачить плюси і мінуси тощо?
Загалом співбесіда охоплює такі теми.
Бази даних
У цьому розділі ми проходимося по загальних питаннях, а також ставлю додаткові точкові питання з досвіду кандидата. Наприклад, якщо в резюме вказано, що людина працювала зі Snowflake, у джуна я можу уточнити, як у цьому інструменті оптимізувати певний запит. Мідла можу попросити пояснити архітектурні особливості Snowflake, спитати, як в цьому DWH реалізований паралелізм, які стратегії скейлінгу можливі. Часом зустрічаються мідли, які не знають бази, тому зазвичай, ми починаємо із декількох «джунівських» запитань, наприклад, «Що таке OLAP і OLTP бази, і в чому їхні відмінності». І якщо людина на це питання не відповідає, то далі в глибину копати зазвичай немає сенсу.
Data-pipelines (ETL, ELT процеси)
У цьому розділі ми обговорюємо концепцію та архітектурні підходи data pipelines, а також процеси ETL/ELT. Він містить декілька відкритих питань, тому я пропоную кандидатам подумати, перш ніж дати відповідь.
Загалом усіх інженерів, незалежно від грейду, я прошу ставити уточнюючі питання, якщо кандидат не знає відповіді. Перш за все, мене цікавлять не люди, які мають енциклопедичні знання, а ті, хто можуть логічно мислити, маючи певний набір інформації. Було чимало кейсів, коли кандидат зрештою знаходив, хоч і неточну, але дуже близьку до істини відповідь. З такими людьми класно працювати.
Airflow
У дата-інженерії існує чимало різних оркестраторів, але ми в Solidgate працюємо з Airflow, і робимо це на досить просунутому рівні. У нас в команді навіть є люди, які контрибʼютять у цей продукт. Відповідно, ми шукаємо людей із сильною експертизою в цьому інструменті. Загалом ми проходимося по загальних концепціях, притаманних Airflow, і переходимо до більш глибоких запитань, наприклад, як моніторити метрики в інструменті. На це питання мало хто відповідає, але воно дає зрозуміти, наскільки фундаментальні знання має людина: це простий користувач, який здатний запустити даги, чи людина, яка задумується про відмовостійкість системи. Тут також працює підхід «давайте подумаємо».
Трансформація даних
Зазвичай запитую кандидатів, які види трансформацій вони можуть назвати, і як вони реалізують їх з допомогою різних інструментів. Це питання про рефлексію, і показує, наскільки людина може класифікувати якісь загальні знання, знаходити паттерни. І для інженера, як на мене, це важлива характеристика.
Валідація даних і моніторинг системи
Вважаю, що дані, які не пройшли валідацію, не несуть жодної цінності. В дата-інженерії є великий блок роботи, який називається Data Quality. Оскільки Solidgate — FinTech компанія, то якість даних для нас є пріоритетом. Тому блок про валідацію даних також є важливим для мене. Запитую, з якими інструментами кандидату доводилося працювати, які тести він вважає за потрібне налаштовувати, як можна класифікувати валідацію даних. Від джуніора очікую базових знань інструментів та обізнаності, що дані взагалі треба валідувати. У розмові з мідлом, хотілося б почути певні кейси з попередніх проєктів. Коли людину з досвідом питаєш, як вона проводила валідацію і моніторинг даних, а вона відповідає «ніяк», це завжди сумно.
Python
Цей блок питань скоріше для джунів. Вважаю, що Python – це просто інструмент, і якщо кандидат добре розуміється у концептах дата-інженерії, вміє писати юніт-тести, то запитувати в нього щось з Python — це втрата часу.
Питання для дата-інженера (Junior / Middle)
Нижче перелік базових питань для дата-інженерів ґрейдів джуніор та мідл. Вони розташовані у порядку зростання складності та розділені на блоки, які відображають потрібні компетенції. Деякі питання зі списку можемо поставити і джуну і мідлу, проте очікувана глибина відповіді буде різною.
Загальні знання про бази даних
1. Як ви розумієте поняття «транзакція»?
2. Яка відмінність між OLTP i OLAP базою?
3. Які види баз даних ви знаєте? Назвіть принципи поділу.
4. Які архітектурні особливості цих з баз даних?
5. У чому різниця між реляційними та нереляційними базами даних?
6. Які основні відмінності між SQL та NoSQL базами даних?
7. Що таке база даних типу граф? В яких випадках їх доцільно використовувати?
8. Наведіть приклади рівнів ізоляції БД.
9. Як ви розумієте нормалізований вид даних?
10. Розкажіть про архітектуру тієї DWH, з якою ви працювали?
11. Як ви будете пришвидшувати повільний запит (з точки зору написання запиту)?
12. Як пришвидшити читання з таблиці (на прикладі тієї DWH, з якою ви працювали)?
13. Що таке deadlock? Що з ним робити?
14. Переваги та недоліки реляційної і документоорієнтованої БД?
15. Навіщо потрібен індекс? Які проблеми він створює?
Data pipelines, ELT/ETL
16. Які переваги та недоліки підходів ELT та ETL?
17. У чому відмінність ETL від data pipeline?
18. Наведіть приклади побудови декількох архітектур data pipelines?
19. Коли та в якому випадку ви б застосували ELT, а коли ETL?
20. Як можна відстежувати зміни у таблиці реляційної бази (щоб опрацювати їх)?
21. За якими принципами ви будете обирати інструменти для побудови data pipelines?
22. Що ви знаєте про стрімінгову передачу даних?
23. Розкажіть про Zero-ETL concept?
Трансформація даних
24. Які б ви могли виділити види трансформацій даних?
25. Вам доступні наступні інструменти: Airflow, cloud storage, DWH. Як би ви реалізували трансформації? Які переваги має такий спосіб порівняно з іншими?
26. Як ви зазвичай організовуєте процес екстракції даних з різних джерел?
27. Які методи очищення даних ви використовуєте на етапі трансформації?
28. Як ви виправляєте проблеми якості даних?
29. Що таке нормалізація даних і коли її варто застосовувати?
30. Як здійснюється агрегація даних, в яких випадках вона потрібна?
31. Які є основні стратегії обробки дублюючих записів?
32. Який інструмент для трансформації даних ви вважаєте найкращим і чому?
33. Як можна оптимізувати процес трансформації великих обсягів даних?
34. Що таке індексація і як вона впливає на швидкість трансформацій?
35. Які інструменти ви використовуєте для моніторингу процесів трансформації?
36. Які є основні виклики при роботі з трансформаціями даних у реальному часі і як їх подолати?
Airflow
37. Які оператори ви використовували у роботі?
38. Уявіть ситуацію, коли у вас всі задачі зависли в статусі «queued» і не беруться до виконання. Про що це свідчить? Що ви будете робити?
39. Опишіть, для чого можна використовувати XComm, а для яких Variables?
40. Розкажіть про архітектуру Airflow, його концепти?
41. Що таке пули в Apache Airflow?
42. Як відстежувати аномальне виконання дагу?
43. Яка сутність відповідає за найменшу одиницю роботи? Які сценарії застосування бачите?
44. Як можна моніторити навантаження інстанса Airflow, щоб уникнути його падінь? Як можна знімати метрики?
45. Які юзкейси з використання різних типів executors ви можете описати?
46. Які аналоги окрестраторів ви знаєте?
Quality & observability
47. Які рішення, інструменти допомагають в задачі data quality?
48. З якими проблемами в data pipelines ви зіштовхувалися і як їх вирішували?
49. Спробуйте класифікувати види валідації даних.
50. Наведіть приклад інтеграційного (функціонального) тесту в DE?
51. Розкажіть про свій досвід модульного тестування?
Python
52. Як Python працює з памʼяттю?
53. Що ви знаєте про Pattern Matching?
54. Навіщо потрібен декоратор? Як його застосовувати?
55. Як реалізувати функцію зі змінною кількістю аргументів?
56. Які проблеми/мінуси Pandas ви можете назвати? Які знаєте альтернативи?
57. Розкажіть про multi-threading і multi-processing.
58. Чому ви обрали для себе Python? Які переваги має Python для DE порівняно з іншими мовами?
Також перспективним кандидатам рівня Middle можу дати декілька практичних завдань:
59. Задаю умови функціонування системи (кількість репортів, ліміти, частота викладки), в межах яких інженер має запропонувати своє технічне рішення доставки даних для такої системи. Під цю задачу є заготовлені блок-схеми для кращого розуміння умов, а також навіть приклади коду, які пропоную змінити.
60. Надаю вхідні дані по запиту і пропоную оптимізувати його в різних типах баз даних.
61. Надаю вхідні дані по системі і проблему: наприклад, в певний момент часу ви починаєте отримувати помилку. Якими будуть ваші дії?
Зазвичай подібні питання також підбираються індивідуально і корелюються із досвідом кандидата.
Софт-скіли дата-інженера
На технічному інтервʼю немає спеціальних питань, щоби оцінити софт-скіли, — скоріше ми робимо висновки з того, що кандидат розповідає про свій професійний шлях та досвід. Найбільше ми цінуємо такі якості:
Амбітність — така людина бере відповідальність за своє життя, а не пливе за течією. Може пояснити, чому вона прийняла те чи інше рішення.
Вміння глибоко копати — зазвичай протягом інтервʼю питаю про проблеми, що виникали на попередній роботі, та уточнюю, як кандидат їх вирішував, чому вони зʼявилися, як ще можна було їх вирішити тощо. У нас у команді працює підхід: якщо людина не знає причини виникнення проблеми, значить вона в ній не розібралася і не може стверджувати, що проблема вирішена.
Командний гравець — такий кандидат вміє взаємодіяти з різними командами, готовий менторити інших, відкритий до питань, обговорень і пропозицій.
Відповідальність — робота з даними досить кропітка, і в ній можна легко помилитися. Тому важливо, щоби кандидат був відповідальним та правильно підходив до процесу валідації даних.
Мотивація — є люди, яких потрібно весь час мотивувати зовні: направляти, підказувати. Але для нас важливий саме внутрішній стимул людини робити систему кращою. Саме такі спеціалісти потім стають видатними інженерами.
Поради кандидатам
1. Бути чесним. Якщо людина не знає відповіді та відкрито про це говорить, — це не погано. Гірше, якщо вона не готова разом зі мною подумати над цим питанням і отримувати нові знання загалом. Нечесність на співбесіді завжди відчувається.
2. Почитати документацію. Якщо у кандидата в резюме зазначений певний інструмент, він має бути готовим відповісти на певну кількість технічних запитань. Тому, якщо цей досвід був давно, варто перечитати документацію та освіжити знання — як це працює, які плюси, мінуси цього інструменту є.
3. Вчити юзкейси замість визначень. Часто у підбірках питань для співбесід є пункти на кшталт «що таке ACID», «що таке база даних». Проте в Solidgate ніколи не ставлять подібних питань. Я скоріше спитаю «як досягається літера А в абревіатурі ACID». Краще занурюватися в глибину, ніж питати поверхневі визначення. Хоча ця порада релевантна саме для нашої компанії, і вимоги бувають різними.
