Як я не потрапив у Google, або Марафон співбесід тривалістю 6 місяців
[Від редакції DOU: на прохання автора ми публікуємо цю статтю анонімно]
На DOU часто обговорюють алгоритми та підходи переходу у великі компанії із Кремнієвої долини. Ба більше, для багатьох працювати у FAANG є мрією або можливістю поїхати й подолати скляну стелю або ж соціальну незахищеність в Україні. Хто не читав — обов’язково ознайомтеся зі статтями Адама Леоса та Сергія Семи.
Я хочу поділитися своєю історією провалу і розказати про марафон тривалістю більше як пів року під девізом «пройти співбесіду в Google та отримати офер, більший за п’ять нулів».
Хочу отримати офер Google та відмовитися
Нині я працюю лідом великої команди, поєднуючи обов’язки People та Project Management. Код не писав уже певний час і зовсім не шукав нову роботу. Рекрутери час від часу намагалися додаватись у друзі в LinkedIn або ж надсилали коректні приватні повідомлення з описом своїх вакансій. У січні я отримав повідомлення від сорсера з Google з пропозицією поспілкуватися. «Хмм, а чому б ні? Нічого не втрачаю» — подумав я. А ще було б круто отримати офер і відмовитися!
Не скажу, що шукав роботу, але очі загорілися від бажання «хочу офер від Google»
Під час першого дзвінка сорсер розказав, що вони шукають людину на посаду SRM (Site Reliability Engineering Manager) з можливістю релокації в Дублін. Саме в дублінcьких Silicon Docks розташований один із найбільших хабів Google у Європі. Під час розмови фахівець описав позицію та запитав, чи готовий я релокуватися. І після ствердної відповіді пояснив подальші кроки. Оплату зачепили поверхово, і конкретні цифри тоді не прозвучали. Сорсер також переконався, що я не проходжу інші інтерв’ю, і попросив одразу повідомити, якщо щось зміниться.
У назві посади є два словосполучення, які нечасто використовуються на теренах нашої айтішечки: Site Reliability Engineer (SRE) та Engineering Manager (EM). SRE — це симбіоз DevOps-інженера та інженера підтримки у розумінні Google. SRE не тільки Kubernetes крутить, а й забезпечує працездатність сервісів і взагалі вмикається на ранніх етапах у розробку системи (чи сервісу) для реалізації нефункціональних вимог. Про це є навіть окремий сайт і декілька книг. EM — це менеджер, який достатньо технічний, щоб робити code review та фасилітувати команду до ухвалення технічних рішень. Значною частиною задач EM є People Management. EM — це не Project Manager.
Варто також звернути увагу на опис вакансії на сайті Google. Вона поверхова, і багато хто з кандидатів може сказати, що він (чи вона) точно підходить! Це зроблено для того, щоб сюди подалося якомога більше фахівців, а далі вже йтиме ретельне пропрацювання та відсіювання.
Отже, після такої формальної розмови я отримав листа з описом трьох кроків до виконання: Apply, Googlers, Scheduling
Перший з них — Apply — досить незвичний крок для українських реалій: сорсер попросив самостійно податися на вакансію. Тобто я сам прийшов у Google, хоча мене начебто знайшли. Другий — Googlers — теж не є популярним у нас: потрібно звернутися до людей, які працюють у Google і можуть дати зворотний зв’язок про вас. Пошук у LinkedIn у власній мережі показав десять людей, я відправив контакти трьох. Останній, третій крок найпростіший — надати декілька варіантів часу для проходження інтерв’ю.
Окрім алгоритму з трьох кроків, у листі є документи та посилання для підготовки до перших двох співбесід: code review та management fundamentals.
Під час дзвінка із сорсером ми домовилися, що технічною співбесідою буде code review на Python. Google пропонує готуватися через їхній гайд зі стилю програмування, згадати або вивчити алгоритми, а також потренуватися на TopCoder, Project Euler і careercup.com. І ще вказали посилання на YouTube, як відбувається співбесіда (проте обіцяли, що вона буде адаптована до менеджерської позиції).
Для management fundamentals рекомендували ресурс re:Work, статтю HBR та саморефлексію з виписуванням прикладів власної поведінки в різних ситуаціях. Для саморефлексії надали орієнтовно 15 питань, зокрема: якими командами керував, скільки в них було людей, як вдавалося покращувати продуктивність команди, як підходити до Career Development інженерів, як менеджерам залишатися пов’язаними з технологіями?
Додатково у листі було п’ять посилань на різні ресурси та відео, пов’язані з SRE, і доступ до запароленого сайту з інформацією про міста для релокації. Там зібрана корисна інформація про місто, вартість життя та податки в Ірландії.
Круто бачити такий структурований підхід до організації співбесід. Ви розумієте, хоча, може, і не усвідомлюєте до кінця, що саме вас чекає, і можете цілеспрямовано готуватися.
Для підготовки я взяв трохи більше ніж місяць і домовився про співбесіди на кінець березня. Готувався згідно з рекомендаціями. Для code review перечитав книжку про алгоритми та структури даних і пройшов 50 задачок на LeetCode. Для team management опрацював ресурс re:Work, а результати саморефлексії записав у блокнот.
Звісно, переглянув ресурси для натхнення про Дублін та Ірландію — інстаграмні локації, місця для власного хобі, а також вартість квартир, проживання і, що дуже важливо, темпи вакцинації! Щодо останнього, то ситуація була дивною. Інформація про щеплення є на офіційному сайті. Вакцинація почалася у січні 2021 року і станом на кінець березня 13% населення (637 тисяч) отримали щонайменше одну дозу. Для порівняння: в Україні одну дозу вакцини в той самий час отримали 267 тисяч людей. Забігаючи вперед, скажу, що у травні
Співбесіди у FAANG — це марафон або навіть друга робота
За кілька днів до інтерв’ю надсилають email-чек, мовляв, не забудьте, що скоро співбесіда, подивіться, як користуватися Google Meet, і почитайте ще раз про компанію.
Наприкінці березня я пройшов обидва інтерв’ю і дуже радів з цього. Я не тільки класний менеджер, але й нічо так програміст! До речі, code review був дещо простішим, ніж пишуть в інтернеті, усього дві задачки. Перша — реалізація стеку, ми аналізували ефективність і гнучкість (а якщо потрібно додати нову операцію, чи ефективно працюватиме?). Друга — обробка файлу (код був погано написаний, і треба було в ньому покопирсатися). Розвертати червоно-чорні дерева не потрібно (хоча я до цього був готовий!). Також не було славнозвісних задач про тенісні м’ячики. Робота з кодом відбувалася онлайн через Google Virtual Interview. Така собі емуляція роботи на дошці, але з підсвіткою синтаксису обраної мови програмування (інших фіч IDE не передбачено).
Під час підготовки я зрозумів, наскільки скучив за кодом та алгоритмічними задачками
Далі почалося найгірше для мене і, мабуть, найбільш незвичне для нашого ринку — довге очікування зворотного зв’язку. Півтора тижня тиші. Так, я взяв багато часу на підготовку, але можна й швидше реагувати! Ніхто нікуди не поспішає, чи то перевантаження рекрутерів та технічної команди, чи то погані процеси в «корпорації добра». Я вперше збагнув, що наступні відповіді можуть йти ще довше.
Після надання позитивної відповіді мене передали іншому рекрутеру. Вже під час дзвінка з ним я дізнався, що мене розглядають на перший рівень для SRM — L6. На рівень L5 Google не наймає, а вирощує з власних спеціалістів. Для розуміння рівнів є прекрасний сайт Levels.fyi, на якому можна подивитися орієнтовні зарплати різних фахівців. Так, L6 може отримати офер з п’ятьма нулями!
Наступний крок — це ще три співбесіди. Вже знайомий code review, тоді ще не відомий мені non-abstract large scale design (NALSD) та leadership and Googleyness.
Цього разу для підготовки мені надіслали новий і більший імейл. 25% листа займали Tips for Mental Preparedness: не переймайся, фокусуйся на процесі, найм у Google — це взаємодія (у нас теж працюють різні люди, у всіх різний стиль і підхід до співбесіди).
Для code review важливо не тільки розуміння мови програмування та основних бібліотек, а й вибір структур даних, стиль, ефективність та ідіоматичність коду. Рекомендували опрацювати ресурси Hackerrank, Pramp і книжку Cracking the Coding Interview, а також книги з кожної мови програмування. В моєму випадку Fluent Python та Effective Python.
На відміну від management fundamentals, leadership-інтерв’ю передбачає рольову гру і визначення ваших дій як лідера у певних ситуаціях. Наприклад: «потрібно відкрити новий офіс в Африці» або «ви стаєте CEO нової компанії, що робитимете, які перешкоди бачите?». До них я готувався так, як і до попередніх: знову LeetCode та читання коду з відповідями на задачі на GitHub, ще раз пройшовся по нотатках власної рефлексії, і, звісно, переглянув відео на YouTube на зразок What Does A Google Engineering Manager Do?
А от до NALSD потрібно було готуватися з нуля. Уперше, коли я почув, не зовсім зрозумів, з якого боку заходити. Допомогли курси на Udemy з архітектури, підготовка до System Design інтерв’ю (раз та два) та загальний курс із проходження співбесіди. Найбільш дивне — це потреба вивчити на пам’ять цифри для back-of-the-envelope calculations: наприклад, проходження пакету даних між дата-центрами в Нідерландах та Каліфорнії і назад займає 150 мс. Але найголовніше питання, яке потрібно ставити собі, — чи може моє рішення масштабуватися в 10 разів?
Всі три інтерв’ю були призначені на один день у другій половині травня. Зазначу, що процес призначення співбесід затягнувся на два тижні. При чому я декілька разів писав у Google і запитував, чи вони не забули про мене.
У доковідному світі другий етап був би візитом в офіс Google та обернувся б насиченим днем з маркерами біля дошки. У нинішніх реаліях інтерв’ю відбуваються онлайн. Всі співбесіди були цікаві, хоча й класичні. На code review аналізували код rate limiter (його коректність, ефективність та можливість тестування) і навіть трохи поговорили про механічні клавіатури! На leadership ставили питання в лоб: що робити CEO нової компанії. Під час NALSD-інтерв’ю потрібно було розробити систему централізованої обробки логів з розподілених локацій. Такі рішення вже є, але я з ними не стикався на практиці... Протягом співбесіди ми пірнули в протоколи взаємодії між серверами та розглянули різні варіанти передачі логів. Так, коли дійшли до збереження даних, я вперся в SQL-рішення, хоча і згадав про шардинг.
Усі сім співбесід на Engineering Manager пройдені, але Google не для тебе. Принаймні цього разу
Після чергових двох тижнів рекрутер призначив ще одну зустріч, щоб повідомити, що я впорався з code review, а от leadership та NALSD варто пройти повторно. You didn’t quite hit the mark! Що ж, я взяв ще один місяць на підготовку.
І перейшов від перегляду відео до активного прочитання різних курсів на Educative (Behavioral Interview, System Design Interview, Advanced System Design Interview) та матеріалів. Курс Behavioral Interview надав ще більше питань для саморефлексії (загалом
Безпосередньо перед співбесідою я пройшов імітацію System Design інтерв’ю з другом, який працює в американській компанії. Це було корисно з кількох причин. Передусім це перевірка себе на знання різних компонентів та декомпозицію задачі. Також визначення слабких місць, наприклад занурення в деталі та знов-таки бази даних! І термінологія: Control та Data Plane я раніше не бачив.
Наприкінці червня вже із задоволенням пройшов дві співбесіди. На NALSD потрібно було розробити MMO, і тут ми дійшли з інтерв’юером до підрахунку циклів процесора під час обробки даних.
Видихаю і впадаю в режим очікування на чергові два тижні. В середині липня в Google відбувається hiring committee, і я отримую негативну відповідь. У вигляді приємного бонуса — я пройшов би на рівень L5, але на нього не беруть зовні. Також результат NALSD був значно кращий. Я все ще прикольний менеджер і крутий інженер. На п’ятірочку!
Далі cooldown-період тривалістю 12 місяців, після якого можна спробувати ще раз. Рекрутер сказав, що є люди, які влаштувалися на позицію EM з третього разу.
За деякий час я отримав форму зворотного зв’язку про проходження співбесід. У формі були питання про взаємодію з людьми в Google, моє враження про компанію, а також загальна оцінка інтерв’ю. Більшість питань потрібно було оцінити за п’ятибальною шкалою.
Чи варто було? Безсумнівно, так
Озирнемося назад. Перший контакт з рекрутером був у середині січня, а фінальну відповідь «ні» я отримав у середині липня. Марафон у шість місяців карантинного життя. Протягом цього часу невідомо скільки вечорів та вихідних було виділено для навчання. Традиційні весняні свята (8 березня і травневі) минули вдома з книжкою та LeetCode. Додатково декілька днів відпустки я взяв на підготовку. В результаті: чотири курси на Udemy (1350 грн), три курси на Educative (35 USD), 60 задач на LeetCode, книга з алгоритмів на 900 сторінок, вивчений стиль Google для Python (4 пробіли!).
Я не шукав роботи в Google, тому до початку цього марафону не зовсім розумів деталі процесу. З позитивного — це можливість цілеспрямованої підготовки у власному темпі. Під час цього я рефлексував та усвідомив свої сильні та слабкі сторони. Зворотний зв’язок допомагає переконатися, що нічого не наплутав. Найголовніше — не засмутитися (а це складно!), коли відмовили. Розпитати про деталі й подякувати.
Також потрібно бути готовим, що між співбесідами та результатами є двотижневі паузи. Можна було б сказати «nobody is perfect», але ми не знаємо навантаження на систему рекрутингу. Проте меншим компаніям потрібно цим користуватися і швиденько знімати «вершки» з ринку!
Під час підготовки я зрозумів, куди рухатися далі. Ще не вирішив, чи буду подаватися знову в Google, але роботу Engineering Manager, коли поєднується управління командою та інженерні задачі, точно хочу спробувати! І для цього вже є план дій :)
