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

• Наличие сильной неравномерности в серии оценок, а также сразу несколько диаметрально полярных оценок собеседований (волатильность результатов) — хорошие поводы отклонить кандидатуру.

• Низкие показатели составляющей «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 Распространенный тип логической ошибки в программировании, который чаще всего сводится к недостаточному тестированию граничных условий (значений) программы или функции.]

В написании кода важно, чтобы кандидат заметил и исправил свои ошибки самостоятельно. Ошибки, вероятно, будут, но сразу после написания кода его нужно протестировать (в уме) и исправить, этот навык значительно понижает тяжесть вашей вины в глазах ведущего. Это должно стать привычкой и рутинно завершать решение каждой задачи.

В связи с упомянутым джетлагом мой вам совет: если место собеседования территориально далеко от вас, лучше прилететь на пару дней раньше, чтобы успеть с дороги выспаться и акклиматизироваться (хотя в этом случае вам, скорее всего, придется оплачивать это дополнительное пребывание из собственного кармана). Впереди предстоит несколько дней интеллектуального марафона и естественная усталость от долгой дороги — не лучший фон для демонстрации ваших пиковых результатов.

Второй аспект частых ошибок — лингвистический.

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