пособие для поступающих в Гугель
Feb. 27th, 2008 06:19 pmЯ недавно в зиване рассказывал, что по моим представлениям надо делать для успешного прохождения интервью в Гугеле. Так что вот, собрание:
Вообще говоря, чтение рассказов того же
ivan_ghandhi про то, как он проводит интервью, помогает понять, чего им хочется увидеть, и действовать соответственно.
Они интервьюируют согласно стандартному конторскому шаблону. По бумажке. То есть, у разных людей есть разные предочтения, какие вещи им нравится спрашивать, но вещи эти берутся из стандартного списка на бумажке. Опять же, у разных людей есть несколько разные мнения о том, чего надо хотеть от кандидата, но ответы они старательно записывают в бумажку, и потом обсуждают на Заседаниях Комитетов.
Главный момент, наверное, в том, что они боятся людей типа виртуального Паши Эткина (я не думаю, что он в реальности такой мудак). Людей, которые запомнили всякие разные слова и с выражением уверенности треплются обо всем, без понимания сути и без умения собственно делать что-нибудь. Поэтому они хотят, чтобы кандидаты проявили это умение. Написанием собственно кода. Соответственно, мой совет кандидатам в том, что надо активно углубляться в детали всех решений. Самому предлагать написать собственно код, оценивать время исполнения и требования к памяти и т.п. Хотя в последний раз, вроде, собственно код у меня никто не просил. Хотя я и предлагал. Может, поэтому и не просили.
Второй момент заключается в том, что они хотят увидеть понимание теоретических основ программирования. Ничего особенного, совершенно базовые вещи. Но это чтобы отсеять людей типа "финансовых программистов", о которых рассказывал Шура: как "финансовому программисту" предложили написать компилятор, а он оскорбилсяи уволился. В-принципе, Паша Эткин в эту классификацию тоже попадает. Советы тут давать просто невозможно: или ты интересуешься вещами и читаешь книжки, или нет.
Ну, очевидный третий момент - головоломки. Решение тут важно, но как минимум не менее важно показать процесс поиска этого решения. Здесь есть две засады: одна - когда видишь очевидное решение, которое выглядит неэффективным, но поэтому не считаешь его нужным выразить, а начинаешь думать над чем-то лучше. Вторая засада - обратная, когда кто-то видит одно решение и упирается в него. Третья - конечно, когда люди вообще не видят решения, но этот случай мы не рассматриваем. Совет тут такой, что надо начать с чего-то попроще, внятно его сформулировать, после чего уже думать, как улучшить, и обсуждать эти пути улучшения вслух вместе с сопутствующими проблемами.
Вообще говоря, чтение рассказов того же
Они интервьюируют согласно стандартному конторскому шаблону. По бумажке. То есть, у разных людей есть разные предочтения, какие вещи им нравится спрашивать, но вещи эти берутся из стандартного списка на бумажке. Опять же, у разных людей есть несколько разные мнения о том, чего надо хотеть от кандидата, но ответы они старательно записывают в бумажку, и потом обсуждают на Заседаниях Комитетов.
Главный момент, наверное, в том, что они боятся людей типа виртуального Паши Эткина (я не думаю, что он в реальности такой мудак). Людей, которые запомнили всякие разные слова и с выражением уверенности треплются обо всем, без понимания сути и без умения собственно делать что-нибудь. Поэтому они хотят, чтобы кандидаты проявили это умение. Написанием собственно кода. Соответственно, мой совет кандидатам в том, что надо активно углубляться в детали всех решений. Самому предлагать написать собственно код, оценивать время исполнения и требования к памяти и т.п. Хотя в последний раз, вроде, собственно код у меня никто не просил. Хотя я и предлагал. Может, поэтому и не просили.
Второй момент заключается в том, что они хотят увидеть понимание теоретических основ программирования. Ничего особенного, совершенно базовые вещи. Но это чтобы отсеять людей типа "финансовых программистов", о которых рассказывал Шура: как "финансовому программисту" предложили написать компилятор, а он оскорбилсяи уволился. В-принципе, Паша Эткин в эту классификацию тоже попадает. Советы тут давать просто невозможно: или ты интересуешься вещами и читаешь книжки, или нет.
Ну, очевидный третий момент - головоломки. Решение тут важно, но как минимум не менее важно показать процесс поиска этого решения. Здесь есть две засады: одна - когда видишь очевидное решение, которое выглядит неэффективным, но поэтому не считаешь его нужным выразить, а начинаешь думать над чем-то лучше. Вторая засада - обратная, когда кто-то видит одно решение и упирается в него. Третья - конечно, когда люди вообще не видят решения, но этот случай мы не рассматриваем. Совет тут такой, что надо начать с чего-то попроще, внятно его сформулировать, после чего уже думать, как улучшить, и обсуждать эти пути улучшения вслух вместе с сопутствующими проблемами.