# Как подойти к подготовке к собеседованию в Google? > Практический план подготовки к собеседованию в Google на восемь недель: программирование, системный дизайн, истории, пробные интервью и ИИ. За восемь недель можно заметно повысить свои шансы на собеседовании в Google. Этого времени не хватит, чтобы заново выстроить карьеру, запомнить все алгоритмы или скопировать чужую манеру держаться на интервью. Цель должна быть уже: показать, как вы решаете незнакомую задачу, сделать ход мысли понятным интервьюеру и убрать из процесса ошибки, которых можно избежать. Большинство кандидатов тратит слишком много времени на сбор задач. Я проводил собеседования, создавал инженерные команды и видел, как сильные специалисты выступали слабее своих возможностей, потому что их подготовка поощряла узнавание задачи, а не рассуждение. Кандидат, который торопливо решил 300 задач, может растеряться, когда интервьюер изменит одно условие. У кандидата, который внимательно разобрал 70 задач, объяснил компромиссы, протестировал код и изучил ошибки, шансы обычно выше. Этот план рассчитан на позицию разработчика, потому что на примере программирования, проектирования систем и поведенческих интервью проще составить конкретную программу. Google меняет набор этапов в зависимости от роли, уровня, страны и текущей потребности в найме, поэтому письмо рекрутера важнее любого общего руководства, включая это. Используйте план как рабочую основу, а затем замените его предположения реальным списком этапов. ## Восемь недель работают только при точной цели Восьминедельный план работает, если вы уже отвечаете базовым требованиям вакансии и можете выделять на подготовку около 10-14 часов сосредоточенной работы в неделю. Дополнительное время иногда помогает, но утомительное повторение быстро перестает давать результат. Если вы не можете писать обычный рабочий код без постоянных подсказок или роль требует опыта системного дизайна, которого у вас нет, перенесите собеседование, если рекрутер это допускает. Смелость перед календарем не восполняет пробел в основе. В первый день выберите одну целевую роль, один уровень и один основной язык программирования. Общая цель вроде «попасть в Google» не помогает выбрать между задачей на графы, проектированием распределенного кеша и историей о лидерстве. В описании вакансии указана предметная область. Рекрутер знает ожидаемый набор интервью. Первая пробная сессия показывает, где именно ломается ваше выступление. Эти сведения должны определять расписание. Распределяйте нагрузку по неделе, а не отдавайте каждый день одной теме. Для обычной позиции разработчика разумная отправная точка выглядит так: 45 процентов времени на программирование, 20 процентов на дизайн или знания по роли, 20 процентов на примеры из опыта и 15 процентов на пробные интервью и разбор. Кандидаты в начале карьеры могут перенести значительную часть времени с дизайна на программирование. Опытным кандидатам стоит уделить больше времени архитектуре, лидерству и детальному разбору прежних решений. Не считайте просмотренные видео и прочитанные страницы подготовкой. Считайте результаты, которые можно проверить: решения с ограничением по времени, записанные объяснения, архитектурные схемы, репетиции историй и письменные разборы ошибок. Каждое занятие должно что-то оставить после себя. Это правило не дает повториться знакомой ситуации, когда кандидат учится три часа, чувствует занятость, но не делает ничего похожего на собеседование. До конца первой недели назначьте дату интервью, если вы можете на нее влиять, договоритесь минимум о четырех пробных сессиях с живыми людьми и внесите все занятия в календарь. Друзья отменяют встречи, а работа занимает свободное время. План развалится, если вечером перед нужной тренировкой вам еще придется искать собеседника. ## Сначала составьте карту реальных этапов Расписание от рекрутера дает единственную надежную карту вашего процесса. Google не проводит одинаковую последовательность для всех кандидатов, а рассказы в интернете часто смешивают разные роли, годы и уровни. Спросите рекрутера, что проверяет каждая встреча, сколько она длится, какими инструментами вы будете пользоваться, будет ли системный дизайн и нужно ли отдельно готовиться к материалу по конкретной роли. Рекрутер вряд ли раскроет вопросы, но обычно может уточнить формат. Процесс для разработчика может включать разговор с рекрутером, один или несколько технических отборочных этапов и расширенную серию интервью по программированию, дизайну для соответствующих уровней, профессиональным знаниям и поведению в рабочих ситуациях. Считайте это набором возможных этапов, а не обещанием точного количества или порядка. Подбор команды и итоговое рассмотрение тоже могут влиять на путь после интервью, но они не меняют того, как нужно работать во время встречи. Составьте одностраничную таблицу из пяти столбцов: встреча, проверяемый навык, ожидаемый формат, доказательство навыка и ответственный за тренировку. Слова «программирование» в столбце навыка недостаточно. Запишите наблюдаемые действия: уточнить ограничения, выбрать структуру данных, вывести сложность, написать исполняемый код и проверить граничные случаи. Для системного дизайна укажите требования, оценки нагрузки, интерфейсы, модель данных, поведение при сбоях и компромиссы. Формат влияет на результат сильнее, чем ожидают кандидаты. В техническом руководстве Google по виртуальным интервью сказано, что на некоторых встречах по дизайну используют Google Drawings, и кандидатам советуют сосредоточиться на ответе, а не на идеальных фигурах. Там же сказано, что можно работать ручкой на бумаге, если предупредить интервьюера и хорошо показать записи. Тренируйтесь в инструменте из письма с подтверждением. Красивая архитектурная схема в любимом приложении не готовит вас к объяснению грубого наброска в общем окне браузера. Проверьте технику до серьезных пробных интервью. Используйте тот же компьютер, положение камеры, микрофон, профиль браузера и экран, с которыми планируете проходить интервью. Общее руководство Google по виртуальным интервью советует показывать одно окно, закрывать лишние вкладки и работать на одном экране в одном окне. Это разумная организация: она снижает риск раскрыть личные данные, отвлечься на уведомление или потерять время в поисках нужного документа. Если приглашение противоречит статье или курсу, следуйте приглашению и задайте вопрос рекрутеру. Кандидат, который выучил устаревший процесс, может неправильно распределить половину подготовки. Неопределенность нужно превратить в вопрос рекрутеру, а не в личную теорию из сообщений на форумах. ## Таблица оценки полезнее счетчика задач Таблица оценки показывает, почему решение прошло проверку или провалилось, а количество задач это скрывает. Google не публикует для кандидатов полную форму оценки интервьюера, поэтому не выдавайте неофициальную шкалу за политику компании. При этом ничто не мешает оценивать действия, которые видит любой технический интервьюер, и направлять подготовку по результатам. Скопируйте этот шаблон в журнал подготовки. По каждому пункту ставьте от 0 до 2: 0 означает, что действие отсутствовало, 1 означает, что оно появилось после подсказки или с существенным пробелом, 2 означает ясное и самостоятельное выполнение. Записывайте факты, а не ощущения. ```text Problem: Date: Round type: Time limit: Clarified goal and constraints 0 1 2 Evidence: Built a correct approach 0 1 2 Evidence: Explained tradeoffs 0 1 2 Evidence: Implemented cleanly 0 1 2 Evidence: Tested normal and edge cases 0 1 2 Evidence: Estimated time and space 0 1 2 Evidence: Recovered from feedback 0 1 2 Evidence: First failure point: One change for the next session: ``` Первая точка отказа полезнее итоговой суммы. Допустим, код не работает с пустыми входными данными. Видимый дефект проявился при тестировании, но первая ошибка могла возникнуть раньше, когда вы не уточнили, допустим ли пустой ввод. Исправив только последнюю строку, вы научитесь латать этот пример. Если исправить первую ошибку, вы научитесь уточнять контракт. Используйте тот же метод для пробных интервью по дизайну и рабочим ситуациям. Ответ по системному дизайну может быть в целом правильным, но слабым, если кандидат не оценивает трафик, не объясняет владельца данных или не обрабатывает отказ зависимости. Поведенческий ответ может звучать гладко, но ничего не доказывать, если в нем не видно личного решения кандидата, возникшего разногласия и результата, который он может защитить. После каждого пробного интервью выбирайте одно изменение для следующей сессии. Не несите в новую задачу список из девяти исправлений: под давлением рабочая память отбросит их все. Если главный дефект состоял в молчаливом размышлении, на следующей тренировке сформулируйте план до написания кода. Если при системном дизайне вы не удержали границы задачи, сначала подтвердите два основных требования и только потом рисуйте компоненты. Не меняйте таблицу оценки в течение всех восьми недель. При плавающей шкале невозможно увидеть улучшение. Сложность задач будет разной, поэтому ищите повторяющееся поведение на нескольких сессиях и не делайте выводы из одной высокой суммы. ## Первая и вторая недели дают честную отправную точку Первые две недели должны обнаружить пробелы и восстановить базовые приемы, а не создать внушительное количество решенных задач. До начала учебы проведите пробное техническое интервью с ограничением по времени. Возьмите незнакомую задачу, выделите 40 минут, рассуждайте вслух, напишите рабочий код и проверьте его. Запишите сессию с согласия партнера, затем оцените ее без скидок на волнение. Волнение входит в проверяемую систему. Составляйте список тем по шаблонам, которые умеете выводить сами, а не по названиям знакомых задач. Повторите массивы и строки, хеш-таблицы и множества, связные структуры, стеки и очереди, деревья и графы, сортировку и двоичный поиск, рекурсию и базовое динамическое программирование. Этот список не предсказывает вопросы. Он проверяет, что незнание структуры данных не остановит обычное решение. Для каждого шаблона отработайте четыре действия: распознать сигнал, сформулировать простой подход, улучшить его с объяснением причины и доказать сложность. Пишите код только после этих действий. Кандидаты часто сразу переходят к оптимальному приему, который помнят наполовину, а затем не могут объяснить, почему он подходит. Правильный простой вариант создает основу для обсуждения и путь к улучшению. Используйте язык, которым лучше всего владеете на интервью, если роль или рекрутер не требуют другой. Вы должны без усилий помнить коллекции, поведение сортировки, правила равенства, пределы целых чисел и обычные операции стандартной библиотеки. Составьте короткую памятку по собственным синтаксическим ошибкам. Просматривайте ее между занятиями, но не читайте во время пробного интервью. Нужно убрать случайную нагрузку от синтаксиса, чтобы внимание осталось на задаче. До конца второй недели проведите хотя бы одну диагностическую сессию по системному дизайну, если он ожидается на вашем уровне. Так же проверьте поведенческую часть. Выпишите восемь-десять реальных эпизодов из опыта: трудное техническое решение, конфликт, провал, неоднозначный проект, лидерство без формальных полномочий, компромисс в качестве, влияние на клиента и случай, когда вы изменили мнение. Это исходные записи, а не готовые сценарии. Проверка на выходе из второй недели проста. Вы укладываетесь в заданное время с задачами знакомых шаблонов средней сложности, объясняете решение до набора текста, пишете почти исполняемый код и знаете два своих самых частых сбоя. Если это пока не так, на третьей неделе уменьшите новизну и почините базовые приемы. Переход к следующей неделе с прежним дефектом лишь добавит ему повторений. ## Третья и четвертая недели превращают знания в интервью На третьей и четвертой неделях нужно тренировать взаимодействие, которого нет в самостоятельной учебе. Техническое собеседование похоже на совместный сбор доказательств. Интервьюеру нужно увидеть ваши предположения, решения, исправления и реакцию на подсказки. Молчаливая скорость приносит меньше пользы, чем думают многие кандидаты, потому что скрывает процесс, который интервьюер должен оценить. Выработайте повторяемый ритм решения, но не превращайте его в спектакль. Перескажите задачу своими словами, задайте лишь те вопросы, которые меняют решение, разберите небольшой пример, опишите базовый вариант, выведите улучшенный подход, реализуйте его и протестируйте. Для каждого этапа не нужна речь. Объяснения должно хватать, чтобы интервьюер видел ход мысли и мог вмешаться до того, как вы потратите пятнадцать минут на неверную трактовку. Потренируйтесь принимать подсказку. Некоторые кандидаты воспринимают ее как доказательство провала и начинают защищаться. Другие соглашаются, но не встраивают подсказку в решение. Попросите партнера один раз прервать пробное интервью полезным наблюдением. Сильная реакция признает следствие, меняет план и продолжает работу: «Значит, мое состояние посещения должно хранить оставшийся ресурс вместе с узлом. Я изменю пару состояния и заново оценю сложность». При системном дизайне не запоминайте огромную архитектуру, чтобы натянуть ее на любой вопрос. Начните с поведения системы и масштаба, который меняет проектное решение. Выберите два-три основных действия пользователя, оцените порядок величины только там, где он влияет на выбор, определите главные данные и интерфейсы, затем проследите один запрос. Добавляйте кеширование, очереди, репликацию или секционирование, когда этого требует названное ограничение. Декоративные компоненты порождают вопросы, на которые вы не сможете ответить. Каждую неделю проводите одну тренировку отказа системы. После базового проекта пусть партнер отключит зависимость, увеличит один вид нагрузки, потребует определенную согласованность или спросит, как вы будете искать причину задержки. Это ближе к инженерной работе, чем перечисление блоков по памяти. Заодно станет видно, понимаете ли вы компонент или только знаете его название. В эти недели нужно готовить и поведенческую часть. Превратите список опыта в короткие истории с контекстом, вашей ответственностью, принятым решением, личными действиями, результатом и тем, что вы бы изменили. Не запоминайте полные предложения. Интервьюер будет уточнять интересные детали, и выученный монолог сломается, когда следующий вопрос зайдет сбоку. Завершите четвертую неделю смешанным пробным интервью со сменой режимов, например программирование, а затем вопрос о рабочей ситуации, или дизайн, а затем подробный разбор прошлого проекта. На реальных этапах придется так же переключаться. В разборе отметьте, как быстро вернулось внимание между частями, и не ограничивайтесь оценкой каждого ответа. ## Пятая и шестая недели требуют давления и обратной связи Пятая и шестая недели должны содержать самую трудную работу: полные пробные интервью, незнакомых партнеров и жесткий разбор повторяющихся ошибок. Самостоятельные занятия поддерживают технику, но не воспроизводят вмешательства, неоднозначность, чужой темп и неудобство от необходимости показывать незавершенные рассуждения. По возможности назначайте по два живых пробных интервью в неделю, причем хотя бы один партнер не должен быть знаком с вашей обычной манерой объяснения. Ограничения на пробном интервью должны быть реалистичными, а цель ясной. Сообщите партнеру тип имитируемого этапа и передайте таблицу оценки. Попросите не спасать вас слишком рано. Партнер должен дать подсказку в момент, когда это мог бы сделать настоящий интервьюер, записать ее причину и оставить время на ваши вопросы. Тренировка, где кандидата пытаются унизить редкими фактами, дает плохие данные. Меняйте источники и форматы задач, чтобы узнавание не вытягивало результат. На одной сессии решайте незнакомую задачу, на другой проектируйте систему, на третьей подробно разбирайте проект из резюме. При разборе проекта партнер должен спросить, почему вы выбрали эту архитектуру, что сломалось, какая метрика изменилась, за что отвечали вы, что сделал другой инженер и какой выбор вы бы сделали сейчас. Если пункт резюме не выдерживает таких вопросов, честно перепишите его до отборочного этапа. Теперь же проверьте истории из опыта на расплывчатые формулировки. Замените «мы повысили надежность» своим решением и наблюдаемым результатом, который можете подтвердить. Если результат конфиденциален или у вас нет точного публичного числа, опишите операционное изменение без выдуманной точности: инциденты перестали повторяться после определенной защиты, проверка стала ловить класс дефектов или миграция убрала ручную передачу. Интервьюеры замечают числа, добавленные только для украшения истории. В конце каждой недели объединяйте таблицы. Посчитайте, как часто каждое действие получало 0 или 1, и перечитайте фактические комментарии. Выберите две главные закономерности для исправления. Если реализация стабильно чистая, а уточнение условий слабое, усложнять задачи бессмысленно. Возьмите более простые и требуйте точного контракта до первой строки кода. Я не советую проводить полное пробное интервью каждый день. Такой совет популярен, потому что создает ощущение максимальной нагрузки, но не оставляет времени изолировать дефект и восстановить отдельный навык. Работайте циклом: выступление, диагностика, точечное упражнение и новое выступление. Спортсмены не готовятся к забегу одними забегами, и с интервью нужен такой же здравый подход. К концу шестой недели у вас должны быть минимум два удачных смешанных пробных интервью с реалистичным временем, ни одного необъяснимого утверждения в резюме и короткий список оставшихся рисков. Удачное не означает идеальное. Партнер смог проследить рассуждение, решение выполнило заданные ограничения, а вы восстановились после изменения направления. ## Седьмая и восьмая недели снижают разброс Последние две недели нужны для повторяемого результата. С приближением даты кандидаты часто увеличивают объем, меньше спят и добавляют новый материал. Они повышают разброс именно тогда, когда нужна стабильность. Перестаньте гоняться за редкими темами, если на них не указывают описание роли или рекрутер. На седьмой неделе проведите полную имитацию всей серии с ожидаемым количеством и типом встреч и нормальными перерывами. Возьмите другие вопросы и партнеров, чем раньше. Проверьте еду, воду, температуру в комнате, заметки и переход между звонками. Правильное решение, после которого на следующем этапе болит голова, показывает организационную ошибку, которую можно предотвратить. Сверьте истории с резюме и заявкой. Инструменты для работы с текстом на основе ИИ позволяют легко получить гладкие формулировки, которые шире реальной работы кандидата. Каждое существительное и число в заявке должно выдерживать уточняющие вопросы. Если помощник редактировал текст, сравните итог с исходными фактами и удалите добавленные им утверждения. На восьмой неделе уменьшите нагрузку. Коротко повторяйте шаблоны, проведите одну-две умеренные сессии по программированию, компактно разберите дизайн и проговорите истории в форме беседы. Последнее полное пробное интервью должно пройти за несколько дней до настоящего, чтобы вы успели исправить конкретную проблему и не принесли эмоциональный осадок на основной этап. Составьте одностраничную памятку с временем встреч и часовым поясом, контактом рекрутера, способом подключения, разрешенными инструментами, нужным документом и вопросами интервьюерам. Не добавляйте заметки по решениям или материалы, которыми нельзя пользоваться. Руководство Google советует подготовить компьютер, камеру, запасной телефон, бумагу и маркер, а также проверить технику; письмо с подтверждением может изменить этот список. Накануне закончите пораньше. Прочитайте заявку, проверьте оборудование и выспитесь. Еще одна сложная задача на графы в полночь не создаст новый навык. Зато она может помешать воспользоваться уже выработанным. ## ИИ сильнее изменил отбор, чем подготовку Отбор с помощью ИИ удешевил безликий текст заявки, усилил соблазн передать подготовку помощнику и сделал подтверждение личности и авторства заметнее на ранних этапах. Он не отменил ясное рассуждение, правильный код и опыт, который кандидат способен защитить. В ответ стоит лучше следить за происхождением своих материалов и реалистичнее тренироваться, а не соревноваться в машинной оптимизации речи. Не утверждайте, будто знаете внутреннюю модель отбора Google. В открытых материалах нет полного описания оценки каждой заявки, а практика может меняться. Готовьте материалы под описание роли и правдивые доказательства, понятные человеку и автоматической системе: используйте стандартные названия должностей, если они точны, прямо указывайте подходящие навыки, оформляйте даты понятно и связывайте в каждом пункте действие с результатом. Набивка ключевыми словами и невидимый текст ухудшают заявку для любого серьезного проверяющего. До интервью используйте ИИ как тренера, работу которого вы проверяете. Он может создавать варианты задачи, оспаривать допущения в дизайне, имитировать уточняющие вопросы, разбирать уже написанный вами код или показывать, где в истории не видно личного действия. Просите критиковать, а не создавать вашу профессиональную личность. Храните исходные факты для заявки и не принимайте переписанный пункт, пока не сможете защитить каждое утверждение без инструмента. С началом интервью граница меняется. В текущем общем руководстве Google по виртуальным интервью прямо сказано не использовать ИИ для ответов, иначе кандидат будет исключен из процесса. Там же требуется отправлять только собственную работу, а ответы, созданные ИИ, и скопированный исходный код названы примерами нарушений, ведущих к исключению. Это яснее споров на форумах. Закройте помощников, экранные подсказки, ботов расшифровки с рекомендациями и уберите вторые устройства, если рекрутер явно не разрешил инструмент как специальное условие или часть задания. Тренировать распознавание ИИ не нужно. Тренируйте авторство. Вы должны объяснить назначение каждой строки, изменить ее при новом ограничении и связать каждое утверждение об опыте с памятью о реальной работе. Неожиданный уточняющий вопрос проверяет ту же непрерывность, которую часто стирает общий текст от ИИ. Кандидаты смешивают еще два разных понятия: отбор с ИИ на стороне работодателя не разрешает кандидату отвечать с помощью ИИ. Первый процесс проводит компания со своими правилами и контролем. Второй регулируют выданные вам инструкции. Споры о справедливости не отменяют письменное правило интервью, а узнавать его через дисквалификацию неразумно. Если в будущем приглашении прямо разрешат ИИ-помощника, считайте это отдельным типом этапа с другим наблюдаемым навыком. Тренируйтесь точно ставить задачу, проверять созданный код, находить скрытые сбои и объяснять, что принимаете или отклоняете. Не переносите правила из новости о другой компании или пилотной программе. Условия вашей встречи задают рекрутер и письменное приглашение. ## В день интервью управляйте адаптацией В день интервью следуйте отрепетированному процессу и подстраивайтесь под собеседника. Подключитесь заранее, проверьте звук и рабочий инструмент, выслушайте условие целиком. Если связь не работает, сразу сообщите об этом и воспользуйтесь контактом рекрутера или запасным способом. Попытка скрыть техническую проблему отнимает время и может выдать сбой общения за сбой мышления. Если застряли, покажите полезное текущее состояние задачи. Кратко сформулируйте известное, назовите мешающее предположение и предложите более простой вариант или полный перебор. Тогда интервьюеру будет на что ответить. Повторение «я думаю» перед неподвижным редактором ничего не дает. Считайте уточняющие вопросы новыми ограничениями, а не приговором первому ответу. Подтвердите изменение, сохраните применимую часть работы и исправьте остальное. Если нашли ошибку, назовите ее, почините и снова проверьте затронутый случай. Попытка скрыть уже замеченный дефект разрушает больше доверия, чем обычная ошибка. Между встречами не разбирайте предыдущую по косточкам. При необходимости запишите один факт, выпейте воды и переключитесь. Кандидаты часто неверно читают нейтральное поведение интервьюера и тратят следующую встречу на спор с провалом, которого, возможно, не было. Следующему интервьюеру нужно все ваше внимание. Если серия изменится, встречу перенесут или рекрутер добавит незнакомый формат, уточните ожидания и пересоберите оставшийся календарь. Восьминедельный план не святыня. Он нужен, чтобы доказательства, тренировки и риски оставались видимыми при изменении обстоятельств. Основателям, которые читают эту статью ради собственного найма, пригодится тот же урок: четкая шкала и наблюдаемая работа полезнее фольклора о вопросах, а Team & AI Audit на oleg.is применяет эту дисциплину к инженерным ролям, процессам и расходам на штат. Кандидатам нужна более узкая задача. Приносите работу, которая принадлежит вам, понятный ход решения и достаточно сил, чтобы воспользоваться и тем и другим.