Три тижні, 120 задач і офер від Google — як потрапити в FAANG без плану

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

Привіт, спільното! Мене звати Оля Войчик, уже майже два роки я працюю Software Engineer в Google, в команді Borg Control Plane.

Більшість статей про FAANG починаються з чіткого плану: рік підготовки, сотні задач, кілька спроб, офер. Та в мене для вас інша історія. Коли зʼявилася можливість спробувати свої сили в Google, я тоді не планувала змінювати роботу, не готувалася роками і не цілилася потрапити в FAANG. Я прийшла в програмування зі бізнес-аналітики, згодом опанувала C++, а до першого Google-інтерв’ю мала всього два тижні на підготовку.

Хочу поділитися тим, як насправді все відбувалося — і залишу кілька порад для тих, хто теж хоче спробувати стати частиною Google.

З бізнес-аналітики в C++

Я вступила до КПІ у 2020 році на системний аналіз — напрямок, що поєднує математику з програмуванням. З третього курсу почала працювати в Польщі: спочатку стажувалася у відділі R&D, де команда займалася дослідженням операцій та машинним навчанням.

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

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

Загалом мій комерційний досвід на момент працевлаштування в Google складав близько двох років, з них більша частина — системна розробка на C++.

Google не був фінальною точкою маршруту

Google не був фінальною точкою мого маршруту, а з’явився несподівано. Паралельно з роботою я брала участь у навчальних групах з C++ в українській спільноті з підготовки до FAANG, про яку мені розповів брат. Саме він допомагав мені розібратися у внутрішній кухні ІТ, як працює рекрутинг та як краще структурувати резюме. Але подавати заявки в жодні FAANG-компанії я на той момент не планувала.

Мені написав рекрутер у LinkedIn. Я подумала, що варто спробувати, хоча я й не розв’язувала жодного лідкоду перед тим. Знала, що такі задачі є, можливо, пробувала колись для цікавості. В мене було 2 тижні, щоб підготуватися до першої співбесіди.

Я довго вагалася: попередня робота мені подобалася — математика, машинне навчання, цікава бізнес-логіка. Перед прийняттям офера написала трьом-чотирьом українцям у LinkedIn, які вже працювали у Google, запитала, як там насправді. Усі відповіли одне й те саме: іди, нудно не буде.

Кожен мені писав: не переживай, йди в Google, наберешся досвіду. І вони всі казали правду — нудно тут не буває.

Фото з особистих архівів

Етапи хайрингу зсередини

Загалом процес зайняв кілька місяців — з урахуванням очікування відповіді після інтерв’ю. Самих інтерв’ю було п’ять, плюс team matching наприкінці.

1. Розмова з рекрутером // неформальний скринінг.

Тут потрібно було відповісти на кілька технічних питань: яка складність такого-то алгоритму, у чому різниця між алгоритмами сортування. Інші кандидати, за її словами, таких питань не отримували — все залежить від рекрутера. Це зустріч-перевірка.

2. Перше coding інтервʼю // розвʼязання алгоритмічної задачі.

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

3. Три coding інтервʼю // різні задачі, різні інтерв’юери.

Одне з інтервʼю було не на класичний алгоритм, а на дизайн структури даних — «як би ти задизайнив таку структуру». Не system design, але близько до нього за форматом мислення.

Примітка: Зараз Google проводить три, а не чотири coding-раунди.

4. Behavioral інтервʼю (Googleyness) // ситуаційні питання про минулий досвід.

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

5. Team matching // коротка розмова-знайомство з менеджером потенційної команди.

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

Як організувати підготовку за обмежений час

У мене не було заздалегідь вибудованої системи — через неочікуваність пропозиції моя підготовка була інтенсивною і короткою. Між першим coding-раундом і наступними я попросила додаткові три тижні на підготовку. Цей час став основним: близько 120 задач, щодня мінімум п’ять.

Пам’ятаю, я тоді поїхала у відпустку — ніч, Іспанія, я розв’язую задачку. Романтика.

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

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

01. Вивчай шаблони, а не задачі. Знаючи загальний підхід до класу задач, вирішиш будь-яку його варіацію.

02. Проходь задачі рандомно з різних тем, а не послідовно. Імітуй умови реального інтерв’ю.

03. Порівнюй своє рішення з іншими. LeetCode показує complexity за часом і пам’яттю — використовуй це.

04. Behavioral потребує окремої підготовки. Записуй та проговорюй конкретні ситуації заздалегідь, не намагайся згадати їх прямо під час розмови — вийде поганенько.

05. За можливості організуй собі mock-інтервʼю. Це допомагає навчитися презентувати свої думки вголос та боротися зі стресом в моменті. А ще це шанс отримати фідбек на ті нюанси, які самотужки важко помітити.

Borg, scheduling та те, чим я займаюся щодня

Я працюю в команді, що підтримує Borg — внутрішню систему керування кластерами Google. Якщо ім’я не знайоме: саме від Borg походить Kubernetes. Будь-який workload, який запускається всередині Google-інфраструктури — все це на Borg.

Що таке Borg:

• Менеджер кластерів: розподіляє та запускає workload по машинах дата-центру.
• Попередник Kubernetes — архітектура K8s будувалася на основі досвіду Borg.
• Публічні папери про систему є у відкритому доступі.

Я займаюся оптимізацією планування та розміщення обчислювальних джоб (scheduling): коли і на яких саме машинах у дата-центрах виділяти ресурси для максимальної ефективності системи. Робота не зводиться до одного напрямку: часто потрібно перемикатися між інженерними задачами, колаборацією з Research та Data Science над новими фічами, запевненням надійності систем разом із SRE та координацією з іншими SWE-командами. Часта зміна контексту — одна з причин, чому мені подобається Google.

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

Фото з особистих архівів

Технічний фундамент — база & ґрунт

Ще під час з хайрингу в Google я паралельно проходила курс Performance Engineering від Івана Петрушенка в CS Osvita. Закінчила навчання вже під час онбордингу в Google. І ця програма виявилася корисною на несподіваних етапах хайрингу.

Найбільш потрібним для мене виявився розбір перформансу різних контейнерів у C++ і їхньої внутрішньої різниці. Один із найяскравіших кейсів, який я пам’ятаю й досі, — оптимізація роботи мап. Тож коли я прийшла в Google і зіткнулася з Abseil — розробленою в компанії open-source бібліотекою, яка слугує ефективнішою альтернативою стандартним структурам, — я відразу зрозуміла, чому тут віддають перевагу саме цим рішенням.

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

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

Несподіванки після офера

• Внутрішній онбординг. У Google діють спеціальні програми для входу в основні мови розробки: мої колеги приходили з зовсім іншим бекграундом і спокійно опановували ту ж C++ з нуля. Втім, навчання не обмежується лише мовою — враховуючи кількість внутрішніх бібліотек та систем, вчити нові речі доводиться кожному. Для цього існує окрема програма адаптації, де розробники опановують базу про внутрішні інструменти.
• Внутрішній інтернет. Свої форуми та власний пошуковик, де на основі внутрішніх документів, обговорень та листів можна знайти відповідь майже на будь-яке питання — від технічних деталей коду до побутових офісних порад.
• Різниця в часових зонах. Взаємодія з командами з США означає, що між вами до 9 годин різниці. Потрібно вчитися писати вичерпні повідомлення з першого разу і заздалегідь планувати мітинги.
• Вечірні мітинги бувають, але не щодня. Команда намагається мінімізувати перетин з вечором. Жорсткого правила починати рано вранці теж немає.

Якщо ти розробник, який хоче в Google, тоді тобі потрібні:

01. База з алгоритмів та структур даних — без неї нікуди, це фундамент усіх coding-раундів.

02. Вміння читати складність алгоритму і порівнювати рішення, а не просто «щоб працювало».

03. Окрему підготовку до behavioral інтервʼю — це навичка, яку потрібно прокачувати додатково. Само собою навряд вийде.

04. Позитивний настрій і готовність до невизначеності в процесі.

05. Цікавість до бізнес-контексту задач, а не тільки до коду.