Комментарии 89
На собеседовании был всего один вопрос — написать программу (в моем случае на Python). Времени на все дается не так много: 45 минут. При этом считается хорошим тоном успеть не только решить задачу (желательно тремя различными способами), но и поназадавать собеседующему кучу интересных вопросов (о его проекте, о команде, компании и пр.).
Очевидно, что в таких условиях можно решить только такую задачу, похожую на которую ты когда-либо уже успешно решал (а желательно именно такую). В моем случае задача была довольно сложной, с которой ранее сталкиваться не приходилось, даже близко. Успел вроде пару способов предложить, на третий, который самый лучший обычно становится, уже не хватило времени. Но собеседование я скорее всего провалил после вопроса о сложности получившихся алгоритмов, на который я к моему стыду ответить не смог. Она оказалась равна O(2^n).
Отсюда вывод: готовится к таким собеседованиям нужно очень тщательно. Также желательно перерешать все задачи из сборников задач для проходящих собеседование в Google (можно найти такие, и HR сами их даже рекомендуют), и даже не один раз. И очень важно научится определять сложность любого алгоритма, даже самого изощренного.
Задачи задают не чтобы проверить как хорошо ты вызубрил их, а как ты можешь решать новое и применять стандартные алгоритмы для разных задач.
Проблема всех таких задач, что они все равно решаются зубрением типовых групп задач и сведением всех задач к ним. Та же проблема с вопросами по тех.интервью, можно ни черта не понимать в технологии X, но вызубрить все статьи с вопросами интервью по X и бодро пройти тех.интервью. Увы, в таком случае выигрывает не самый умный/самый профессиональный, а тот кто больше остальных прокачивал навыки прохождения тех.интервью.
В результате, может сложиться так что буквально студент-junior пройдет то тех.интервью на котором провалиться человек с огромным опытом в этой сфере.
В результате, может сложиться так что буквально студент-junior пройдет то тех.интервью на котором провалиться человек с огромным опытом в этой сфере.
Это не баг, а фича. Если человек с огромным опытом не может решить обход дерева, бинарный поиск, то ему возможно будет тяжело взаимодействовать с другими сотрудниками. Опыт с другими технологическими стеками (у Гугла почти все свое) и языковой опыт (никогда не писал на плюсах до работы тут) Гугл интересует гораздо меньше чем универсальный алгоритмический базис. Да, возможно можно поменять вообще все в Гугле и нанимать других людей и иным способом, но тогда это будет совсем другие команды, люди и компания.
Опыт с другими технологическими стеками (у Гугла почти все свое) и языковой опыт (никогда не писал на плюсах до работы тут) Гугл интересует гораздо меньше чем универсальный алгоритмический базис.Это не совсем так. Он их тоже интересует — но в том случае если вы претендуете на соответствующую позицию.
А так — да, опыт работы с вещами, с которыми вы, скорее всего, никогда в своей работе не столкнётесь, так как у Гугла «всё своё» начиная от VCS (особой надстройки на git) и кончая базами данных и прочими вещами — не ценится. И довольно-таки понятно почему.
Мелочи ради
начиная от VCS (особой надстройки на git)
Нет там гита, к счастью. Есть только слой для любителей гита, чтобы работать как с гитом.
Обычно если тебе предлагают решать задачу которую ты уже решал, то так и стоит сказать «я вот именно такую задачу решал»
Как тут не вспомнить анекдот: http://www.anekdot.ru/id/-111121027/
Самые важные темы — Big-O notation
А чего такого зубодробительного могут спросить про Ландау нотацию? Или это в контексте рассмотрения других алгоритмов (типа "какая сложность у qsort?")?
Дать задачу с условием "сложность не выше O(N)" про химические соединения с ограничением времени в 25 минут, например :) Личный опыт.
P.S. Понятно что бывают и очень сложные и заковыристые алгоритмы где ответ на вопрос «а какая тут сложность» — сходу не ответить. Сталкиваться вы с ними будете в работе хорошо если раз в год, так что вот их конкретно — будет время обработать. Но сама идея что вы спокойно, не шелохнувшись, пишете код и не знаете — сколько он потребует памяти и процессорного времени — не укладывается в голове у людей, которые работают с масштабами Facebook'а или Google'а. Когда у вас миллиарды пользовалей разницы между O(N) и O(N2) — это не разница между «хорошо» и «плохо». Это разница между «держит нагрузку» и «этот код можно выкидывать не обсуждая».
По весне интервьюировался в Google на позицию Quantitative Analyst. Рекрутер вышла на меня сама. Я географически живу недалеко, поэтому вместо технического телефонного интервью попросил приехать к ним в офис и общаться вживую, отвечая на вопросы на Whiteboard. Мне пошли на встречу. Пара таких технических интервью, а потом приглашение к ним в офис на onsite от которого я отказался.
Основные причины моего отказа от onsite interview:
- Quantitative Analyst — это много статистики, мне же в свою очередь интересно Machine Learning / Deep learning. Причем интервьюировался я на эту позицию потому что рекрутер, который со мной связялся хотел заполнить именно эту вакансию, а не потому что она мне была интересна.
- Офис расположен в Mountain View, причем по утрам и вечерам дикие пробки, то есть это либо в этой деревне жить, либо тратить кучу времени на транспорт.
- Мне дали интересный офер, с жестким дедлайном, так что был выбор либо реальный офер с Машинным обученим в стартапе в Сан Франциско или теоретический офер на работу со статистикой в Google в деревне. => я выбрал Сан Франциско.
Интервьюируют достаточно жестко, но интересно, то что я что-то не знаю или не помню каких-то стандартных с их точки зрения в статистике вещей можно компенсировать тем, что быстро выдаешь рабочие решения, даже если они не самые оптимальные.
В общем очень приятные впечатления от всего этого процесса, за исключением одного — в Google процесс наема идет так долго… Facebook и Uber в разы оперативнее. Говорят, что они пытаются ускорить процес найма. Поглядим через пару месяцев.
Почему-то мне кажется, что такой процесс найма отсеивает реально талантливых разработчиков: проходить отбор будут только крепкие середнячки с определенной долей упорства в характере, но не более того.
А то наймут пару десятков «Шелдонов», которые будут вечно собачиться друг с другом вместо какой-то продуктивной деятельности.
На самом деле я ошибся, поскольку под перегибами я имел в виду другой случай с автором g-wan веб сервера, где собеседование проводил хр с ответами на бумажке.https://habrahabr.ru/post/313028/
Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard so fuck off.
— Max Howell (@mxcl) June 10, 2015
А потом это на HackerNews обсуждали.
Честно говоря, статья ни о чём.
Мне в качестве первого этапа собеседования в Nest (куплен Google) предложили придумать архитектуру небольшого проекта и снять "professional-looking" видео с рассказом о ней. Отказался.
Собеседовался в сентябре на вакансию SETI (то, что раньше было Software Engineer in Test), сначала был телефонный звонок с рекрутером, потом пригласили на гуглодок-интервью с инженером из команды. Впечатление от собеседования осталось негативное и вот почему:
- Заранее перед интервью спросили, на каком ЯП предпочитаю проходить интервью, я выбрала Питон, поскольку именно на нем приходилось писать последние 3 года, на си/плюсах в универе последний раз писал. На собеседовании же как дошло дело до вопроса на кодинг, выдали задачу с битовыми полями. Ну и, очевидно, слету не удалось написать нормальный код, я был несколько разочарован таким подходом.
- Не было ни одного вопроса по теме, только про алгоритмы, сложности и все такое. Т.е. натурально ни одного вопроса про практики разработки, тестирование, качество и прочее. Ну я, конечно, читал Cracking the Code Interview, но все-таки ожидал, что при собеседований человека с опытом основное внимание будет уделяться релевантному опыту, а не универской теории. А тут будто на собеседование студента попал, у которого опыта нет, вот и спрашивают что могут.
- Где-то в письмах они потеряли мою просьбу собеседоваться в Hangouts, поэтому сначала был звонок на телефон и чувак чуть ли не после hi-hi разогнался и пошел фигачить вопросы "сколько стоит вставка в хэш-таблицу". Наверное, вы догадываетесь, что международный телефонный звонок по качеству — то еще развлечение, пришлось его перебить и напомнить, что хотели в Hangouts общаться.
Ну и понятно, что мне написали "вы молодец, но в этот раз мы решили не продолжать", сам понимал, что налажал много где, в первую очередь с кодом, ибо не ожидал такой подставы.
В этом плане Интел куда более адекватно собеседует, вопросы на 95% релевантны должности, никаких бесполезных вопросов не по теме, все релевантно или позиции или резюме.
Заранее перед интервью спросили, на каком ЯП предпочитаю проходить интервью, я выбрала Питон, поскольку именно на нем приходилось писать последние 3 года, на си/плюсах в универе последний раз писал. На собеседовании же как дошло дело до вопроса на кодинг, выдали задачу с битовыми полями. Ну и, очевидно, слету не удалось написать нормальный код, я был несколько разочарован таким подходом.
В Питоне нельзя с ними работать или требовали что-то специфичное для си/плюсов?
Вы словно Яндекс описали. Аналогично, 5 часов общих вещей: алгоритмы, сложность, задачи на логику. Ни одного вопроса про опыт, архитектуру софта, какие-то фундаментальные бест-практисы. После 10 работы сложновато.у вчерашнего студента больше шансов, всё ещё в памяти.
«Если вы хорошо готовились к каждому интервью и имеете шансы на каждом собеседовании 80% из 100, что очень круто, то по теории вероятности после 6 технических интервью Ваши шансы равны 0.8^6 = 0.26.»
На самом деле, при таком раскладе, вероятность пройти после 6-ти интервью
P = 1 — (1-0.8)^6 = 0,999936
Есть потенциал для улучшения перед следующей попыткой :)
0.2^6 — вероятность провалить все 6 собеседований.
1-0.2^6 — вероятность провалиться менее, чем на 6 собеседованиях (0..5).
У девушки всё верно, это частный случай формулы Бернулли.
P.S. Подразумевается, что для получения оффера нужно пройти все 6 (разных) интервью, а не одно из них.
«0.2^6 — вероятность провалить все 6 собеседований»
соверешенно верно, нам нужно не провалить хотя бы одно (т.е. любой исход кроме того, у которого вероятность 0.2^6), потому
P = 1 — (1-0.8)^6 = 0,999936
(зачем я это разжевываю? :) )
В крупных компаниях процесс устройства состоит из последовательности различных технических интервью (обсуждение используемого языка, архитектура, алгоритмы и т.д.).
И кандидат, чтобы получить оффер, должен пройти все собеседования.
Если бы речь шла о попытках устроиться в 6 разных контор, в каждой из которых нужно пройти 1 интервью, то Ваш вариант был бы верен.
P.S. Минусую не я, у меня банально нет такой возможности.
> И кандидат, чтобы получить оффер, должен пройти все собеседования.
Это не совсем так. Далеко не про каждое собеседование можно сказать «прошел/не прошел». Не бинарная это штука, а многоступенчатая. А уж способ суммирования результатов тем более слабоалгоритмизируем.
Если надо пройти все 6, то да, у девушки все верно.
«0.2^6 — вероятность провалить все 6 собеседований»
соверешенно верно, нам нужно не провалить хотя бы одно (т.е. любой исход кроме того, у которого вероятность 0.2^6), потому
P = 1 — (1-0.8)^6 = 0,999936
Если надо пройти все 6, то да, у девушки все верно.
На техническом интервью было 2 вопроса. Один совсем простой про работу со String. По сложности — 1 курс универа. Второй вопрос сложнее (я предлагала Бинарный поиск и прочее) — субъективно 3 курс универа
Спасибо огромное. Информация невероятно полная и полезная. Я думаю после вашей действительно откровенной статьи шансы у людей увеличились.
Ожидал прочитать как обычно ерунду, а тут прямо удивительно развернутый, интересный рассказ о прохождении интервью.
Не давно сам искал работу, получил первый оффер раньше чем телефонное интервью с google было назначено. Причем и с тем и с другим рекрутером начал разговаривать примерно в одно время.
Они сразу говорят что процесс минимум 1.5 месяца, и это в лучшем случае.
При этом даже в конторы с 1000+ людей можно устроится за 2 недели максимум.
А тут у народа обычно кредитов вагон и маленькая тележка и.т.п. Мое личное мнение что Google сотрудники не особо нужны, нанимают «чтоб было» и денег хватает. Но реальной потребности(а соответсвенно понимания что ты будешь делать и зачем ты нужен — не будет) как таковой нет.
Гугл очень и очень полезен с другой стороны если разные вопросы с иммиграцией надо решить, у них опыта много, юристы, не первый кейс. Но это совсем другая история.
Гугл рассматривает вариант с переводом человека по H1B? Надо им с льготы понравиться для этого?
Перевод H1B (h1b transfer в оригинале). Оч простоя процедура, сделают запросто.
что есть льгота, я не знаю
У меня сложилось такое представление: для Н1В компании придется оплачивать всякие пошлины, подавать доки в гос. учреждения, и, самое главное, участвовать в квоте, и только раз в году. Вложиться в человека, чтобы лишь с некоторой вероятностью его перевезти через много месяцев. Если компания большая, есть филиалы, то куда проще человека буду устроить, и через годик — безо всяких квот перевезти по визе L1. Слышал про такую схему у Фейсбука (Европа, США), Майкрософт (Канада, США). Даже пару человек знаю, кто так переехал. Но вот про Н1В не слышал success stories.
А оттого, что объёмы данных и количество клиентов у них гигантские, разница даже между O(n) и O(ln n) для них очень важна.
А оттого, что объёмы данных и количество клиентов у них гигантские, разница даже между O(n) и O(ln n) для них очень важна.Разница между O(n) и O(ln n) всегда велика, за исключением самых тривиальных случаев. Я думаю вы имели в виду разницу между O(1) и O(ln n) — а вот она даже в масштабах гугла может часто перебиваться константой.
Главное чего хочет Гугл — это чтобы никто, нигде и никогда в коде не породил алгоритма Шлемиэля. Количество людей, который с радостью неописуемой порождают O(n2) вместо O(n) — устрашает. Вот с ними на собеседованиях, в основном, и идёт борьба.
А по поводу О(1) и О(in n) нууу не всегда такой алгоритм получится изобрести, потому я про более реалистичные случаи написал.
А вот чтобы разница между O(n) и O(log n) выстрелила, нужно не так много данных. Я много общался с программами, которые совершенно однозначно содержали пресловутого «маляра» — и для того, чтобы это было заметно петабайтов данных не требовалось.
P.S. Кстати всевозможные пакетные менеджеры очень часто этим грешат. Люди, которые их создают обладают массой полезных качеств (умение работать в команде, умение разрираться в разнообразных билд-системах и т.д. и т.п.), но вот умение писать масштабируемые системы — очень часто не их конёк.
ахении
Вам сюда: http://gramota.ru/slovari/dic/?word=%D0%B0%D1%85%D0%B8%D0%BD%D0%B5%D1%8F&all=x
сколько можно у инженеров спрашивать по алгоритмам? Нанимайте спеца по алгоритмам, зачем програмистов мучать?
Кажется, вы путаете термины "говнокодер" и "программист" (с двумя "м", прошу заметить).
Первому — да, нафиг алгоритмы не нужны.
У меня один вопрос по всей этой гугло-ахении, сколько можно у инженеров спрашивать по алгоритмам?Вот пока такие как вы будут пытаться устроиться работать в Гугл — и придётся это делать.
Нанимайте спеца по алгоритмам, зачем програмистов мучать?Затем что не имеет смысла мучить «спеца по алгоритмам», чтобы они вычитывали весь код и отслеживали %$^%%&^, которые норовят вкрутить в любую дырку маляра Шлемиэля.
Кто-то вообще потом в ежедневной работе высчитывал какой там BigO в моём коммите?Что значит «высчитывал какой там BigO в вашем коммите»? Если вы код написали — вы и должны за этим следить. Если вы предлагаете ассимптотически неоптимальное решение — будьте любезны добавить комментарий, объясняющий почему вы считаете что в данном случае — это неважно. А как вы это знаете если вы не видите этих самих BigO в написанном вами коде???
Большое спасибо за ваш интересный опыт
Приглашают очень большее количевство кандидатов, даже с заведомо хучшими требованиями чем им надо.
У них такая работа — набрать на собеседования как можно больше людей, и проводить мосштабную кампанию по приему на работу сотрудника.
Иначе как им еще обяснить те затраты которые они тратят на HR отдел??? Денег то у них много)))
Автор описал первый этап — телефонное интервью. Успешное прохождение этого этапа это далеко не финиш. Интервью на алгоритмы — первый отсеивающий фильтр.
Более того, автор — Junior Android developer. Никто не ожидает от кандидата на позицию Junior глубоких познаний в архитектуре. То есть после успеха на телефонном интервью такие собеседования всё-равно были бы, но в облегченном варианте.
телефон это клиент, а не большая вычислительная машина, а клиент не должен делать сложных решенийО как. А ничего что на телефоне ещё и батарейка есть и то, сколько всё это ресурсов жрёт напрямую влияет на то, как пользователи будут воспринимать ваш продукт?
Да, если вы «мобильный разработчик», который может себе позволить роскошь «забить» на телефоны меньше чем с 10 ядрами и меньше чем 4 гигибайтами памяти — то для вас, может быть, все эти алгоритмы и не важны. Поставил фильтр в Google Play — и всех делов.
Но мобильный разработчик в гугле должен делать вещи, которые будут демонстрировать «плавную стабильную работу» на всяких индусских телефонах с процессорами трехлетней давности и с весьма «обрезанными» другими спецификациями. Тут подходом «я написал алгоритм, а сколько он будет требовать ресурсов для своей работы — мне не интересно» не годится.
Техническое собеседование в Google на Software Engineer — мой опыт