Опыт собеседования в Google на позицию SRE

Предыстория:

Подавался через рефер от своего друга в Google, на позицию SRE. Сначала был init call с HR, которая спросила про опыт работы и пробежалась по тесту, где даются варианты ответов. Тест по Google/Python ответил на 100% правильно, по Linux Internals наверно процентов на 50%. Меня спросили по какому направлению я хочу собеседоваться SRE-SWE или SRE-SE. Я выбрал SRE-SE. После этого мне назначили телефонное интервью. 

Начали с вопросов по Linux, дальше был кодинг и 10-15 минут ответы на мои вопросы. Кодинг приближен к рабочим задачам, надо было побегать по /proc/ собрать некоторую информацию и вывести результат. Google это называется practical coding, нужно написать аккуратный, читаемые код без багов.

После телефона прошла примерно неделя, мне позвонил HR и дала фидбек, что кодинг был отлично, а вот linux internal надо улучшать. Она поинтересовалась, как у меня продвигаются дела с Amazon, я сказал, что жду онсайта. После чего я примерно еще неделю ждал, когда назначат второй телефон, но это не происходило. Я пинганул HR и она снова связалась со мной по телефону и сказал, что хайринг менеджер принял решение не проводить второй телефон и сразу звать на онсайт. Далее меня передали другому HR и мы запланировали онсайт сразу через 2 дня после онсайта с Амазоном. На выбор мне было предложено 3 страны: Ирландия, Швейцария, Германия. Я выбрал Швейцарию.

В итоге сразу после онсайта с Амазоном, я перелетел из Варшавы в Цюрих.

Leadership.

25-30 минут leadership questions. Задают 2 типа вопросов:

 - Привести пример из прошлого, как я действовал в той или иной ситуации

 - И как бы я действовал, если ситуация случится в будущем.

После Амазона, показалось легко, на некоторые вопросы давал заготовки для Амазона.

Troubleshooting. 

Есть некий сайт, твой коллега говорит тебе, что иногда сайт грузится дольше, чем обычно, нужно найти причину.

Сначала задавал вопросы на счет исправности клиентского оборудования, описал как бы убедился в том, что с компом и сетью и на клиентской стороне все ОК. Далее решили, что все ОК и надо копать инфраструктуру. 

Интервьювер нарисовал на доске график (время выполнения запросов). Я задавал вопрос на счет того, какие инструменты у меня есть. Например, могу ли я, где-то посмотреть список инцидентов, которые создала тех. поддержка или еще кто? Может быть проблема уже известна и ей занимаются. 

Есть ли у меня дашборд с релизами и могу ли я сматчить выбросы на графиках с временем релиза? И если да, то может быть дело в релизе и его надо откатить.

Есть ли у меня система трейсинга запросов, могу ли я попросить своего коллегу, выполнить запрос добавив какой нибудь query параметр в строку браузера, чтобы получить trace ID и далее отправить его в систему и получить расклад по latency на всех уровнях системы. Интервьювер сказал, что это было бы слишком просто, поэтому продолжаем копать дальше руками. 

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

Далее я предложил найти корреляцию между базовыми метриками на серверах и графиком latency. Пришли к выводу, что всплески совпадают с графиками CPU. Далее интервьювер разложил графики группы серверов с application на отдельные и представили, что на машине #3 потребление в разы выше, чем на остальных.

Я спросил, нужно ли мне убрать машину #3 из кластера, чтобы она не влияла на продакшен? Интервьювер сказал нет, так как 2 оставшиеся не справятся с нагрузкой.

Пошли на машину по ssh и начали смотреть, что там. Поговорили о тулзах Линукса, top, free, pidstat, iotop. Я предложил почитать логи приложения, там конечно все ОК. Базовые логи сервера тоже в порядке, с железом проблем нет.

Посмотрели с помощью iperf top, что делает приложение, затем предложил снять статистику и построить flame graph, чтобы найти горячие функции. Интервьювер сказал, что мы выяснили, что проблема в функции, которая работает с базой данных. И в этот момент закончилось время, дальше капнуть не успели.

Систем дизайн.

Пришел парень, тимлид, 10 лет в гугле. Попросил спроектировать key/value storage из которого только читают. Постановка задачи звучала ровно так.

Я начал задавать уточняющие вопросы:

 1) Какой размер ключей и значений, какой тип данных? key 1КB string и val 10KB binary

 2) Сколько всего пар будем хранить в нашем сторадже? 5 млрд.

 3) Какая нагрузка на чтение? 100к запросов в секунду.

 4) Какое железо у меня есть? 32CPU/256GB RAM/10 Gbit net/ 10 * 6 Tb HDD

 5) Какие к сервису предъявлены SLO? 95% req < 50 ms и availability 99.99%

Далее начали считать цифры, сколько всего нужно места для хранения такого объема, сколько сети. На это было потрачено больше всего времени, было разрешено юзать калькулятор в телефоне. В итоге вышло, что для ключей надо 51.2 Tb и для значений в районе 500Tb. Затем начался разговор про то, как будем хранить на диске или в памяти. Далее речь зашла про время позиционирования головки жесткого диска и количество iops на каждый диск. Я предложил для старта хранить все в RAM. Расчеты показали, что при текущем железе, надо 2.3к серверов, предложенной конфигурации. 

Далее сказал, что мы можем сэкономить потребление памяти и часть данных хранить на диске или использовать SSD, вместо HDD. Сказал про LRU кэш и на этом время закончилось.

Обед.

Пришел другой сотрудник с которым пошли пообедать в их столовку, пообщались про работу в Google, про жизнь в Цюрихе.

Linux Internals.

Пришел инженер 8 лет опыта в Google. Начал с простого вопроса про различие симлинков и хардлинков. Потом сказал, что есть веб сервер, который отдает файлики, нужно подменить содержимое файла и минимизировать простой. Я предложил использовать SIGHUP для reload конфигурации или использовать симлинки. Далее он копал в глубь и просил придумать еще способ. Я предположил, что можно подцепить к процессу с помощью GDB, открыть новый файловый дескриптор и с помощью системного вызова dup, заменить старый дескриптор на новый.

Затем поговорили про жизнь процесса, fork, exec, zombie process. Потом снова вернулись к веб серверу, как бы я в проде решал эту проблему, если бы писал сервер сам с нуля. Я предложил два варианта, использовать менеджмент порт для взаимодействия с веб сервером по gRPC и отправлять ему команды. И второй варианты был использовать etcd или подобную систему, чтобы мое приложение само ходило за актуальной конфигурацией. Было, что-то еще, но уже позабыл.

Большую часть в этой секции я позабыл и не смог восстановить в памяти, были еще вопросы про kernel/user space, сигналы и что-то еще.

Кодинг.

Пришел мужик предпенсионного возраста, долго не мог настроить ноут для собеседования, очень тихо говорил, было сложно разобрать. Дал задачку написать на python аналог программы pstree. Долго проговаривали решение, своими подсказками он скорее меня сбивал с толку. Относительно остальных интервьюверов он выглядел супер уныло и не заинтересовано. В итоге начал писать код, на середине программы кончилось время. По-сути задачу не решил.

Потом выяснил у него, что он работает чуть больше года, и вероятно у него мало опыта собеседований. Последняя секция с ним меня сильно расстроила, потому что до этого все было отлично.

ОФФЕР:

Через пару дней мне написал мой HR, предложил созвониться. Меня это дико напрягает, когда они не пишут в письме тему разговора и какой то краткий итог. Потому, что до момента звонка ты не знаешь да/нет, это очень нервирует. Амазон сразу писал в письме, а по телефону давал детали.

Попросил мой фидбек по секциям, затем дал фидбек со стороны Google. Сказал, что хайринг менеджер передает мое дело в хайринг комитет. Так как это было преддверие нового года, то рассмотрение было назначено на 6 января. 

7 января мне позвонили и сказали, что не успели рассмотреть и перенесли на 8 января и вечером 8 января мне позвонили и сказали, что хайринг комитет одобрил мою кандидатуру и теперь надо дождаться официального оффера. Я спросил у своего HR, а как же кодинг? По моему мнению я считал, что завалил его. На что он мне сказал, что комитет посмотрел фидбек с телефонного интервью и там был хороший отзыв и им этого хватило для принятия решения.

В итоге, 10 января вечером, я получил официальный оффер и далее начались переговоры c Амазоном и Гуглом.

UPD: Google перед выставлением оффера сразу спросили цифры от Амазона и прислали сразу улучшенный оффер.