В последние недели участилась волна статей на хабре о том, как проводятся собеседования.
Google ищет инженеров постоянно. Как SRE, могу точно сказать, что вы нужны в наших рядах. Печеньки на мини кухнях и кофе в кофемашинах ждут вас. Всего-то нужно пройти собеседование. Это сложно, но реально — когда-то я уже описывал свою историю как соискателя, а сейчас уже в числе прочего занимаюсь и проведением собеседований. Так что сейчас я расскажу, как мы проводим собеседования с инженерами.
Нет, я не стал HRом. Процесс собеседования предполагает сперва разговор с HR. Это общая беседа “что-куда-зачем” (то есть описание процесса для вашего конкретного случая) и тот самый всеми любимый скрининг из опросника с несколькими вариантами ответов. Скрининг мне в своё время показался весьма базовым, подозреваю, что вы отвечали на такие вопросы уже сотню раз. Затем собеседования будут проводиться уже инженерами — вашими будущими коллегами (близкими или далёкими, это уже как получится, наша планета весьма небольшая).
(Важно: я описываю процесс как я знаю, на инженерные позиции. Для интернов процесс меняется; равно как и процесс в принципе может отличаться, так как HR адаптируют процесс для достижения наилучшего эффекта. Используйте информацию приведенную тут только для того, чтобы примерно представлять чего ждать — но никак не публичную оферту! Точной информацией о том, как будет процесс проходить для вас лично, будет только и исключительно информация от вашего HRа. Информация также может уже устареть — смотрите раздел How We Hire для актуальной информации на момент чтения статьи).
Сперва будет несколько собеседований через hangouts/meet. Это уже полноценное собеседование, как я выше сказал — собеседуют инженеры, и предполагается, что кандидат в процессе будет “думать вслух” + напишет десяток-другой строк на каком-либо языке программирования (да, к сожалению, пока в гуглодоках).
Моё собеседование рассчитано на ~45 плюс-минус десять минут, но обычно стараюсь вписаться ровно в 45 минут. Из этого времени пять минут на краткое знакомство и общие сведения, 30-35 минут на вопросы и дискуссию, затем пять минут на вопросы кандидата (если они есть).
Вообще, целью собеседующего инженера является собрать информацию по нескольким осям навыков кандидата (таких как умение кодить, знание алгоритмов и структур данных и т.п.). Но самое важное на собеседовании — узнать как человек думает. То есть всегда важно найти ту границу, когда человек не знает решения. Каждый собеседующий имеет свою технику (особенно для телефонных интервью): кто-то держит в запасе десяток вопросов от разминочных (решение которых буквально — написать цикл в три строчки) до сложных даже для объяснения. Кто-то имеет 2-3 “любимых” вопроса, любой из которых можно повернуть десятком сторон и как упростить, так и усложнить — в зависимости от того, что демонстрирует собеседник. Уверен, есть еще варианты, но я о них не знаю.
Я попробовал обе техники, и мне больше по душе последняя: в зависимости от резюме и самооценки кандидата, использую более подходящую форму вопроса. Вопрос всегда открытый (в конце концов, когда у нас в отрасли вы в последний раз видели точную постановку задачи?) — и в зависимости от того, что и как расспрашивает кандидат, упрощаю или усложняю вопрос так, чтоб к концу первых примерно 10 минут кандидат уже написал тривиальное решение. Это редко когда представляет сложность, в конце концов, решение тривиально.
Так же тривиально задаются вопросы “а почему вы уверены, что оно работает?” (если кандидат не описал сразу границы применимости или тесты), и какова сложность полученного решения. Это просто даёт информацию о том, что кандидат умеет кодить и понимает что он написал. Но мало кодить — надо уметь думать, поэтому следом идут вопросы: а как избавиться от ограничений? Как сделать лучше? Либо (что бывает, когда кандидат очень хорош или просто знает решение по опыту) как сделать так, чтобы код работал при вот таких или иных дополнительных ограничениях.
Это даёт сразу пачку сигналов — а насколько кандидат умеет адаптироваться к изменениям в задании? А насколько готов подумать о сильно альтернативных решениях? Само обсуждение тоже представляет интерес — вопрос задаётся всегда максимально открыто, поэтому есть десятки способов его понять. Уточняется ли бизнес-окружение, или только технические ограничения? А учитываются ли технические ограничения? Например, несколько раз было, что я говорю “ожидается 1e12 объектов”, и кандидат не оценивает сколько это. А это почти терабайт, если по байту на объект. Или ~116.5 гигабайт если по биту. Или 4.3 терабайта если по int32. Ну вы поняли. Нет, помнить это не обязательно — не на экзамене, калькулятор никто не отбирал же. В телефоне есть, да даже в поиске. И, кстати, можно спросить.
И вот так я буду поднимать сложность или просто модифицировать задачу всё доступное время собеседования. Да, возможен вариант, что для собеседуемого это — основной рабочий хлеб, и он такие задачи кушает на завтрак, обед и ужин. Что ж, на этот случай у меня проездной есть совершенно другой вопрос. Например вместо графов — на динамическое программирование. Или на списки. Или вообще вопрос, где оптимальное решение потребует кучу. Главное — другой антураж, другая задача.
Самое важное здесь: дать одновременно и очень простое задание, чтобы кандидат мог решить и показать базовые навыки, и поднять сложность до того уровня, где кандидат не знает ответа, чтобы он мог показать как он думает. Если при этом сможет найти решение более сложной задачи — это отлично, но если кандидат смог решить вообще всё, то это прокол собеседующего, что не подготовил вопрос еще большей сложности.
Хотите конкретики? Вот один из вопросов, которые вам НЕ зададут просто потому, что он считается уже “утекшим” — то есть велика вероятность, что кандидат будет не думать над ним, а вспоминать. Как я писал выше — важно как кандидат думает, а не как он вспоминает… Так вот, вопрос: реализовать LRU кеш.
Вообще задача прекрасна, так как позволяет множество форм задания и множество форм трактовки. Например, можно задать вопрос прямо в лоб “реализуйте LRU кеш”. Можно сформулировать как “представьте, что наш сервис для обработки запроса проверяет существование внешнего объекта. Как можно ускорить обработку?” — ожидая очень очевидное предложение “давайте просто кешировать результат”. На что можно будет спросить “а как?”. И “а как, если мы хотим контролировать максимум памяти, потребляемую этим кешем?”. Вопрос оставляет открытым — а какой API должен предоставлять этот кеш. Для простоты всегда можно свести к set(key, value)+get(key); но можно добавить TTL. Можно с get(key, fetch_func). Вообще, оценка предложенного API тоже может дать дополнительный сигнал об опыте и стиле кандидата.
Тривиальное решение на hashmap даст O(1) на get() + O(N) на set() (это же так, да?). Если все элементы дополнительно слинковать (организовав double link), можно будет получить O(1) на обе операции. Если надо добавить TTL… Думаю, идея ясна. Если есть желание, давайте обсудим в комментариях: представьте что вам задали этот вопрос, как вы будете думать? какое решение предложите?..
А, на каком языке программирования? Да какой нравится, в каком сильнее всего. C++? Чудесно. Go? Замечательно. Python? Всегда пожалуйста. Perl? Нынче редок, но тоже да. И Java да. И javascript (хоть тут и сложнее с учетом памяти у решения).
Итак, спустя примерно 40 минут от начала собеседования, полет мысли кандидата будет прерван, но это не значит, что всё плохо. Это всего лишь значит, что время вышло.
После самого собеседования, собеседующий пишет отчет, часто с детальной стенограммой происходившего на интервью. Этот отчет будет использоваться для принятия решения. Я лично резервирую примерно час сразу после собеседования, чтобы записать полный протокол беседы на свежую память, некоторые просто пишут на бумаге почти полную стенограмму в процессе интервью.
После телефонного собеседования, на основании отчетов всех собеседовавших, принимается решение о приглашении на очную ставку. Это будет полный день собеседований в одном из офисов: несколько собеседований с утра, потом обед (и знакомство со столовой в офисе :) и потом еще парочка. При собеседовании на SRE это будут разные интервью, список которых вам сообщит HR, в числе которых кодинг и обязательно NALSD: Non-Abstract Large-Scale System Design. Ключевое — non-abstract (то есть не общие слова “нам понадобится база данных”) и “large scale” (то есть если база и понадобится — то под петабайты, например). Подробнее можно почитать тут и еще много где найти материалы в поиске. Мне несколько ссылок для подготовки скидывал HR. Это очень важный момент собеседования — просто потому, что работая в компании масштаба гугла, приходится думать и рассматривать системы с таких сторон.
В целом, очное собеседование мало чем отличается от телефонного — аналогичные вопросы и аналогичный процесс. При этом мы стараемся распределить вопросы так, чтобы не задавать один и тот же вопрос дважды.
Что еще могу добавить о процессе собеседования? Have fun! Нет, серьёзно, расслабьтесь и получайте удовольствие! Телефонное собеседование? Просто разговор с интересным собеседником. Гарантированы новая информация и новый опыт. Очные собеседования? Еще веселей! Вы в командировке за счет будущего работодателя :) Прогуляйтесь по городу, встретьтесь со знакомыми. Также гарантирован полный день развлечений и интересных бесед.
И после этого дня веселья, все собеседовавшие вас так же пишут отчет, с полным протоколом беседы. Все данные собеседований собираются воедино, и рассматриваются независимым комитетом. Это важно: никто из тех, кто знает вас лично, в принятии решения не участвует. Никто из тех, кто собеседовал — также не участвует напрямую. Это всё направлено на то, чтобы исключить предвзятость в решении. Оценка идёт только на соответствие требуемой планке стандарта для найма. Если вдруг не повезло, и вы не пройдете — всегда можно будет повторить попытку через год. За этот год можно систематизировать свои знания и заполнить обнаруженные пропуски.
Есть какие-то вопросы? Задавайте в комментариях.
Есть интерес попробовать собеседование до самого собеседования? Есть сервисы для mock interview (например раз и два, но они не от самой компании, так что никаких гарантий); иногда Google проводит аналогичные кампании.
И да, не стесняйтесь подать заявку сами. Если верите в магию “подачи через сотрудника” — пишите мне, я внесу вашу заявку. Вэлкам!
Автор: datacompboy
