Игорь Савчук - Отъявленный программист: лайфхакинг из первых рук Страница 43

• аналитические способности (analytical abilities); 

• навыки программирования (coding & design skills); 

• опыт работы (professional experience); 

• общение (communications skills).

По каждому из этих пунктов выставляется максимум 1 балл (могут ставиться дробные оценки меньше единицы, например 0,5), после чего оценка суммируется (очевидно, теоретический максимум — 4 балла). Эта оценка как конечный результат прохождения собеседования должна сохраняться в тайне как от других интервьюеров, так и от самого участника интервью. После чего она представляется на специальном бланке в комиссию по найму (Google Hiring Committee). У этой комиссии есть множество подкомиссий, каждая из которых специализируется на отдельной специальности (например, для администраторов это Site Reliability hiring committee). В нее централизованно стекаются все данные со всех собеседований множества отдельных рекрутеров низшего звена, затем они распределяются по соответствующим подкомиссиям. Я видел у вас подобный бланк, где кроме оценки и всех ее составляющих включается краткий отчет о прошедшем собеседовании. В этой карточке репорт начинался с фразы: «Кандидат очень нервничал, поэтому первые 20 минут я успокаивал его, всячески подбадривал и пытался ввести его в рабочий режим, говоря на нейтральные темы, а также обсуждая его биографию». Жалко, что вы не показали все остальные бланки из тех, что у вас остались на память. (Улыбаясь.) Там примерно одно и то же, поверьте мне на слово. В последнее время такие отчеты чаще всего предоставляются по электронной почте, а затем хранятся для последующего контроля и повторных интервью. Продолжая тему — не нужно сильно бояться какой-то личной неприязни со стороны отдельных интервьюеров или единичных провальных интервью в серии — вам всегда дадут шанс показать себя с разными людьми и в разных темах, после чего все данные постепенно стекутся в комиссию по найму. Каждому рекрутеру дается на составление подробного отчета 2–4 дня, при этом инструкция требует воздерживаться от личных оценок, взамен предоставляя максимальное количество фактов. Эта комиссия — своего рода локальный рекрутинговый штаб, который определяет текущие потребности данного подразделения компании в определенных людях, динамично формулирует критерии под свою рабочую специфику, подбирает наиболее подходящий под должность и особенности каждого кандидата состав интервьюеров, планирует весь процесс найма. А после всех собеседований совместно анализирует и принимает судьбоносные решения по каждой отдельной кандидатуре, чаще всего делается это коллективно в режиме обсуждения. Это второй (после самих собеседований) уровень анализа результатов собеседований (так называемая стадия Executive Review). Как работает этой второй после собеседований уровень отбора? Такие же обычные инженеры-рекрутеры, не участвующие в очных собеседованиях, раз в неделю получают запрос на рассмотрение 5–8 новых кандидатов. В свободное от основной работы время им нужно изучить для каждой полученной кандидатуры: ? резюме; ? все отзывы с его собеседований (которые были составлены и отправлены на предыдущем уровне; обычно от 3 до 8 отзывов в зависимости от количества собеседующих); ? отзыв реферала (если таковой есть). Последний пункт, как понятно, редко встречается. Еще реже он носит действительно содержательный характер. В связи с этим я могу лишь повторно посоветовать: если у вас есть хороший знакомый в Google (на любой ступени карьерной лестницы), с которым вы действительно когда-то работали вместе, и он может написать содержательный фидбек с разбором ваших возможностей и компетенций — воспользуйтесь этим прекрасным случаем. Итак, для каждой изученной кандидатуры пишется «мини-репорт» — попытка сделать выжимку из всего прочитанного со своим личным вердиктом в конце. На самом деле рекрутер редко когда-либо глубокого вчитывается в ворох чужих оценок, чаще всего используются конкретные паттерны-вопросы для сканирования фидбека коллеги-рекрутера, по которым судят об успешности или провальности каждого отдельного интервью. Вот их наиболее типичные примеры: ? Умеет ли кандидат писать быстрый и точный код? ? Насколько быстро и легко кандидат решает задачи из области своей заявленной компетенции? (Подтверждение опыта.) ? Способность быстро находить ошибки, в том числе в своем коде. Адекватность реакции на подсказки и помощь. ? Способность нахождения решения задач за областью комфорта и компетенции кандидата. Степень адаптации в незнакомых областях, уровень креативности. ? Отдельные случаи во время интервью (как правило, все нестандартные и интересные ситуации документируются отдельно). ? Коммуникативные способности и легкость в общении. Соответствие принципам компании и «гугловость». Это типичный каскад ключевых запросов для обязательного выяснения, который может варьироваться в деталях у каждого конкретного рекрутера. Через день или два после рассылки каждой новой «пачки» кандидатов эта группа собирается вместе и, глядя на свои мини-доклады, написанные заранее, последовательно обсуждает каждую кандидатуру, пытаясь выработать единое мнение-консенсус по каждому конкретному испытуемому. Получается, что все устроено так, что люди, которые будут принимать решение, чаще всего не имеют личного контакта с теми, чью судьбу они будут вершить. Также каждый член такого комитета принимает свое личное решение заранее до сбора всех участников группы, фиксируя его в мини-репорте. Повторюсь, что, так же как и армия рядовых рекрутеров-инженеров, рекрутеры из комиссии — это динамическая и открытая структура, которая работает по совместительству. Например, упомянутый мною SRE hiring committee собирается на совещания два раза в неделю, курируя процедуру найма (фактически для своих собственных нужд) параллельно со своей основной работой в компании.Хорошо, абстрагируясь от устройства всей этой системы, давайте подведем промежуточные итоги и выделим коридор результатов, необходимый для получения положительного решения для кандидата. Мне хочется более конкретно понять, как работает эта машина по оценке кандидатов изнутри, каковы критерии отбора? Приведу набор эмпирических фактов. ? Средний балл должен быть обязательно выше 3, иначе, скорее всего, у испытуемого маленькие шансы. Диапазон оценки между 2,9 и 3,2 — это так называемые пограничные кандидаты, вероятно, их судьба будет решаться на дополнительных собеседованиях. ? Каким бы парадоксальным это ни казалось, но слишком высокая оценка, вплотную близкая к максимальной (>3,7), — это также причина для отказа (не буду повторяться, я уже говорил о выбраковке самых лучших). ? Наличие сильной неравномерности в серии оценок, а также сразу несколько диаметрально полярных оценок собеседований (волатильность результатов) — хорошие поводы отклонить кандидатуру. ? Низкие показатели составляющей «communications skills» особенно опасны, независимо от всех остальных оценок они могут привести к отказу. В силу многонационального коллектива и большого количества эмигрантов именно этой оставляющей уделяют отдельное внимание. Дополнительно я бы хотел упомянуть здесь о двух интересных деталях. Если статистический анализ выявляет, что кто-то из рекрутеров постоянно «заваливает кандидатов», это также будет учтено внутри комиссии, автоматически понижая вес его мнения. Вторая крайне важная деталь — молодым в Google дают множество поблажек. Можно воспринимать это как дискриминацию по возрасту, но факт остается фактом: ошибки, которые запросто прощают «интернам» сразу после университета, никогда не простят опытному разработчику со стажем. И наоборот — чем выше ваш возраст, чем выше у вас заявленный опыт — тем более жесткие требования будут предъявляться к вам. Получая молодого специалиста (до 26 лет), компания еще имеет время сформировать его как специалиста, говоря о людях после 35 лет — Google намерена нанимать только состоявшегося и матерого специалиста, и никак иначе. Именно поэтому уровень задач, отношение и сложность вопросов к этим двум возрастным группам заметно различаются. Итак, рассмотрев устройство фильтрующего механизма, мы готовы попытаться учесть его особенности. Поэтому сразу вопрос на засыпку: по вашему мнению, какая из четырех названных компонент суммарной оценки наиболее провальная, согласно сухим отчетам вашей статистики? Не знаю, совпадет ли ответ с вашими ожиданиями, но согласно моим данным, бесспорно лидирует составляющая «Навыки программирования» (coding skills). Это то, что заваливают 7 из 10 проходящих интервью человек. Вторая опасная отметка для иностранного специалиста — «communications skills». Вот на двух этих больных местах я и предлагаю остановиться отдельно. В чем корень столь частых проблем именно в этих сферах? Писали ли вы когда-нибудь программы на клочке бумаги? Есть ли у вас навык быстрого составления алгоритма в стрессовой ситуации, когда за тем, как вы пишете программу, внимательно наблюдают несколько человек? Писали ли вы, комментируя вслух на чужом для себя языке, каждый ход своей мысли? Как насчет опыта олимпиадного программирования и скоростного поиска решений для весьма нестандартных задач? Программировали ли вы после 10-часового перелета (однозначно стоит попробовать), а также знаете ли вы, что такое джетлаг, накрывающий вас на следующий день после перелета? В Google все это неизбежно: во время интервью вам почти наверняка придется писать фрагменты программ, функций или классов на настенной доске (white board), а на стадии телефонного интервью будьте готовы к тому, что вас могут попросить черкануть пару строк кода на Google Docs, иллюстрирующих какую-нибудь концепцию на удобном для вас языке программирования. Вам придется программировать после долгого перелета и смены часовых поясов. Поэтому прямо сейчас возьмите листок бумаги и попробуйте написать небольшую программу без помощи уже привычных подсказок/автодополнений со стороны IDE (например, без столь любимой многими IntelliSense в Visual Studio) — исключительно по памяти. Есть N коробок. Все они открыты. Некий человек последовательно проходит и закрывает каждую вторую коробку. Затем снова проходит по уже каждой третьей коробке и, если она открыта, — опять закрывает, если же закрыта — открывает. Потом повторяет цикл по каждой четвертой, и так до N. Итоговый вопрос: сколько коробок останутся открытыми после окончания прохода? Большинство программистов считают, что это относительно простое задание, поэтому охотно берутся за решение и получают быстрый ответ, но мало кто решает его правильно. После математического подсчета интервьюеры часто просят также смоделировать эту задачу в программном виде (конечно, результаты комбинаторного прогона по конкретным значениям должны совпасть с математической формулой первого ответа). Должен откровенно признаться, что лично я испытывал серьезные затруднения в связи с внезапным обнаружением непредвиденных трудностей по написанию программ на небольших цветных бумажках уже в процессе прохождения интервью. На своей работе мы предоставляем работодателю уже готовый отлаженный и заранее продуманный код, но задумывались ли вы, сколько исправлений и модификаций кода отделяет его первоначальные схематичные наброски от финальной версии? На интервью такого уровня просто не будет времени и возможности набросать черновой вариант и постепенно его доработать под отладчиком — здесь вы пишете код на лету и сразу поясняете алгоритм. Это и станет вашей окончательной версией решения, которую будут оценивать без всякого снисхождения на полевые условия. Подобный режим — это когнитивный диссонанс по отношению к стандартному и неспешному офисному программированию, где мы обычно тщательно продумываем и оптимизируем каждый элемент своего решения в тиши кабинета, пребывая в спокойном сосредоточении тет-а-тет с кодом, так любезно подсвеченным в любимой IDE. Также обращаю внимание: как утверждает статистика, при подобном «спортивном программировании» наиболее распространенный тип ошибки — off-by-one error (OBOE). [1 Распространенный тип логической ошибки в программировании, который чаще всего сводится к недостаточному тестированию граничных условий (значений) программы или функции.] В написании кода важно, чтобы кандидат заметил и исправил свои ошибки самостоятельно. Ошибки, вероятно, будут, но сразу после написания кода его нужно протестировать (в уме) и исправить, этот навык значительно понижает тяжесть вашей вины в глазах ведущего. Это должно стать привычкой и рутинно завершать решение каждой задачи. В связи с упомянутым джетлагом мой вам совет: если место собеседования территориально далеко от вас, лучше прилететь на пару дней раньше, чтобы успеть с дороги выспаться и акклиматизироваться (хотя в этом случае вам, скорее всего, придется оплачивать это дополнительное пребывание из собственного кармана). Впереди предстоит несколько дней интеллектуального марафона и естественная усталость от долгой дороги — не лучший фон для демонстрации ваших пиковых результатов. Второй аспект частых ошибок — лингвистический. Убедитесь в своем произношении. Поверьте, факт того, что вы понимаете, что говорит ваш собеседник, вовсе не означает автоматически, что вас так же хорошо понимают, что ваш акцент не является препятствием для общения. Специфика подобных международных интервью имеет то свойство, что многие участники не являются носителями английского языка, и часто фокусируя все время и силы на технической и содержательной частях интервью, порой игнорируют языковую составляющую. В связи с этим плохое понимание вашей речи может стать вероятной причиной отказа, не забывайте про четвертую компоненту оценки. Попробуйте заранее проверить правильность произношения основной технической терминологии на английском языке. Например, как правильно произносится слово «procedure»? Обратите внимание на правильность ударения. Очень часто обсуждается тема сложности алгоритма, его асимптотическая оценка и нотация «большое-О», в связи с этим как бы вы произнесли вслух формулу O(log(n))? Следующий важный момент из частых завалов — активное использование адаптивных методик рекрутерами. В самом простом случае это значит, что чем лучше вы будете отвечать, тем более сложные вопросы будете получать в продолжение интервью. Отчасти поэтому непримечательным середнячкам так часто везет в этом увлекательном забеге. Стремление казаться самым крутым не всегда оправданно, если в реальности вы не соответствуете этому уровню. В любом случае очень важны равномерность и последовательность знаний — это не лотерея, здесь не может быть «любимых вопросов», благодаря которым вы рассчитываете блеснуть. Если вы ответили на какой-то вопрос очень сильно, планка сразу поднимается, и дальше вы должны защищать уровень уже более высокого балла. Не стоит писать в своем резюме амбициозных фактов, доказать которые впоследствии вы будете не в состоянии. Повторяю еще раз: гораздо выгоднее произвести впечатление крепкого середнячка, чем неведомого никому гения, который не способен отвечать за свои слова. Покончив с наиболее типичными ошибками, хочется уточнить еще один паттерн. Я слышал, как вы обсуждали со своими курсантами составной допрос — что это значит? Это еще один распространенный паттерн собеседования. Я называю его «составной допрос» (это когда некий теоретический вводный вопрос красиво компонуется с продолжением — практической задачей на его основе). Например, начав обсуждать теорию «Big O notation», после плавно съезжают к обсуждению алгоритма TLS Handshake, который имеет, мягко говоря, много предварительных вычислений. Для интервьюера этот прием — хорошая возможность оценить, насколько у вас большой зазор в понимании между сухой академической теорией и конкретными реализациями на ее основе. Большая проблема и одновременно узкое место нашего современного образования — то, что эти две важные составляющие подчас никак не связаны между собой.Чтобы как-то суммировать этот большой объем информации, давайте перечислим наиболее частые и общие темы на подобных собеседованиях, которыми нужно владеть в обязательном порядке. Нужно хорошо знать хеши, устройство деревьев и графов, главные алгоритмы поиска и сортировок, стандартные структуры данных, основы математики (особенно системы счислений, теорию чисел, основы теории вероятностей и комбинаторику). Кроме того, спецификации основных сетевых протоколов и RFC, работу процессора и памяти, детали TCP/IP и все уровни модели OSI. Для программистов дополнительно — принципы ООП и основные паттерны, теорию работы компиляторов, а также базовые вещи. Пример последнего — очень частый вопрос о расчете времени и эффективности выполнения (Big O notation). Для администраторов — основные API-вызовы операционных систем, то есть вызовы типа fork(), иметь хорошее практическое знание Perl. Кроме того, нужно иметь хотя бы один любимый язык, которым вы владеете очень сильно, вместо десяти языков, на которых решили пару стандартных задач в свободное от работы время (и на основании этого самодовольно поставили птичку в своем резюме напротив их наименований). Как бы ни страшно звучало все перечисленное, требуется знать лишь основы, но знать их нужно уверенно. [1 Проецируя это на действительность бывшего СССР, необходимые знания математики примерно соответствуют уровню 1–2 курса физмата.] Также я хочу коснуться важного момента: требуется понимать то, что было прочитано в различных книгах и интернет-источниках, а не просто механически повторять ранее выученное. К примеру, вот проверочный вопрос из реальной практики собеседований на тему паттернов программирования, который поставил в тупик моего подопечного. Давайте поговорим подробнее об одиночке (singleton). Является ли одиночка паттерном или антипаттерном? Классическая реализация одиночки приводит к невозможности использования модульного тестирования, почему вы тогда относите его к паттернам? Подловить новичка на бездумном повторении книжных истин — это сам по себе «паттерн собеседований» в Google, который без должного уровня осмысления, произносимого порой, ставит кандидата в весьма сложные и неожиданные ситуации. Приведу еще три вопроса-примера в этом же стиле для самоконтроля. Каков физический размер этой Си-структуры в памяти на 32-битовой системе? На 64-битовой? От чего зависит ее размер?