HR из Google вышла на меня сама. Мне 25 лет, Junior Android developer, у меня есть свой простой сайт-визитка, 3 опубликованных довольно примитивных приложения в маркете, живой гитхаб профиль и 2к репутации на StackOverflow. Как именно меня нашли я не знаю. 1 раз я сама подавалась на вакансию к ним, давно — может это повлияло. Кроме этого я часто программирую для удовольствия — я гуглю очень много по теме и возможно мои поисковые запросы складывают обо мне хорошее впечатление. Остается только догадываться.
Первое собеседование с HR было очень легко пройти. Мы прошлись по моему резюме, она указывала на мои сильные стороны, а мне нужно было просто поддакивать. Ей понравилась что я люблю open-source разработку, Android и что у меня математическое мышление. Она так же задала мне пару простых вопросов на алгоритмы сортировки и их big-O, попросила явно указать линк на мой GitHub в CV.
Она рассказала про процесc отбора.
Следующий этап это Phone-screen интервью. Оно может проходить через телефонный звонок+экран монитора или через Hangouts+экран монитора. Мне сообщили, что в случае успеха я смогу выбрать страну (только EMEA) и город, где смогу работать, а следовательно и проект. Google вначале набирает сотрудников, а потом распределяет. Также сказали, что я сколько угодно долго могу готовиться к техническому интервью, но рекомендуют 2 недели. Я попросила 6 недель. Дату и время испытуемый выбирает сам. В Google готовы подстраиваться под Вас.
Для подготовки HR посоветовала прочесть книгу Cracking the Coding Interview Steve Yegge's Blogspot.
Кроме этого меня попросили записаться на 1 часовой online тренинг для кандидатов — как правильно отвечать на вопросы тех интервью. Этот тренинг называется Coaching session. Он проходит 1 раз в 7 дней, кажется, и на нем присутствует тренер инженер Google и около 7 кандидатов. Опять через Hangouts. На этом тренинге рассматривается одна задача, все думают вслух, потом тренер предлагает шаблон как отвечать по задаче. У нас была задача по графам.
Тренинг действительно полезная штука.
Нормально и даже хорошо, если вы вначале предлагаете наивное (не эфективное) решение задачи. Вы сообщаете о проблемах вашего решения, назваете Run-time (Big-O) алгоритма и предлагаете улучшения.
Важно сразу писать код (в Google doc). Несколько раз было сказано, что код должен быть компилируемым. Псевдокод не подойдет.
В переписке с HR я спросила про зарплату, зависит ли она от страны, которую я выберу. Мне не называли сумм, но сказали что разочарована я не буду, что компания входит в топ по зарплатам для всех стран. Вот в этом посте тема зарплат раскрыта более полно, и вообще хороший блог от сотрудника Google.
На техническом интервью было 2 вопроса. Один совсем простой про работу со String. По сложности — 1 курс универа. Второй вопрос сложнее (я предлагала Бинарный поиск и прочее) — субъективно 3 курс универа. Вопросы на сообразительность, но в целом довольно простые, что меня удивило.
Мне показалось, что я отвечала хорошо, хотя собеседование я не прошла. Сказали, что не хватает знаний в алгоритмах.
Вот выводы, которые я сделала:
— Хорошо перед собеседованием прочесть книгу, что советует HR (я читала лишь первые 20 страниц).
— Хорошо пройти пару курсов на Coursera по «Алгоритмам и структурам данных» — это дает ещё и технический английский.
— На тренинг нужно записаться как можно раньше, Ваши знания на нем, наверное, не оценивают, зато Вы получите больше времени для правильной подготовки.
— Самые важные темы — Big-O notation, алгоритмы, графы, большие данные. Это не полный список.
Если Вы проходите phone-screen интервью, следующий этап — 5 интервью в офисе Google в 1 день с перерывом на обед.
Отбор очень жесткий. Давайте посчитаем. Если вы хорошо готовились к каждому интервью и имеете шансы на каждом собеседовании 80% из 100, что очень круто, то по теории вероятности после 6 технических интервью Ваши шансы равны 0.8^6 = 0.26. Короче Вас скорее не возьмут, чем возьмут. Но все равно пробовать стоит.
Следующая попытка собеседоваться может быть только через 1 год. Вот такие ограничения.
Комментарии (79)
renskiy
11.12.2016 23:00+3Точно так же проходил у меня отбор в facebook, с которым я имел дело пару лет назад. Тоже советовали почитать литературу, почитать про структуры данных, про расчет big-O. Тоже была тренировка, которая проходит периодически для всех кандидатов.
На собеседовании был всего один вопрос — написать программу (в моем случае на Python). Времени на все дается не так много: 45 минут. При этом считается хорошим тоном успеть не только решить задачу (желательно тремя различными способами), но и поназадавать собеседующему кучу интересных вопросов (о его проекте, о команде, компании и пр.).
Очевидно, что в таких условиях можно решить только такую задачу, похожую на которую ты когда-либо уже успешно решал (а желательно именно такую). В моем случае задача была довольно сложной, с которой ранее сталкиваться не приходилось, даже близко. Успел вроде пару способов предложить, на третий, который самый лучший обычно становится, уже не хватило времени. Но собеседование я скорее всего провалил после вопроса о сложности получившихся алгоритмов, на который я к моему стыду ответить не смог. Она оказалась равна O(2^n).
Отсюда вывод: готовится к таким собеседованиям нужно очень тщательно. Также желательно перерешать все задачи из сборников задач для проходящих собеседование в Google (можно найти такие, и HR сами их даже рекомендуют), и даже не один раз. И очень важно научится определять сложность любого алгоритма, даже самого изощренного.
Rasifiel
12.12.2016 16:33+1Обычно если тебе предлагают решать задачу которую ты уже решал, то так и стоит сказать «я вот именно такую задачу решал», потому что если ты знаешь решение, то это хорошо видно по процессу решения и может не очень понравиться собеседующему. Задачи задают не чтобы проверить как хорошо ты вызубрил их, а как ты можешь решать новое и применять стандартные алгоритмы для разных задач.
terryP
12.12.2016 16:42+3Не обязательно такую же, большинство олимпиадных задач делается по аналогии, достаточно понять что задача сводится к задачи, скажем, коммивояжёра и дальше все стандартно.
Задачи задают не чтобы проверить как хорошо ты вызубрил их, а как ты можешь решать новое и применять стандартные алгоритмы для разных задач.
Проблема всех таких задач, что они все равно решаются зубрением типовых групп задач и сведением всех задач к ним. Та же проблема с вопросами по тех.интервью, можно ни черта не понимать в технологии X, но вызубрить все статьи с вопросами интервью по X и бодро пройти тех.интервью. Увы, в таком случае выигрывает не самый умный/самый профессиональный, а тот кто больше остальных прокачивал навыки прохождения тех.интервью.
В результате, может сложиться так что буквально студент-junior пройдет то тех.интервью на котором провалиться человек с огромным опытом в этой сфере.alexeykuzmin0
12.12.2016 16:52Ну так свести — это и должно быть самое сложное, если задача хорошая. Кирпичики стандартных алгоритмов все давно знают и умеют писать за минуту с завязанными глазами левой рукой
terryP
12.12.2016 16:59Увы, сведение типовых задач (а большинство задач на собеседованиях типовые) так же зубрятся как и алгоритмы. Навык прохождения тех. интервью != навыку реальной работы на проектах. Наловчится решать такие полуолимпиадные задачки может студент за несколько месяцев. Какой смысл в интервью где человек с 15 годами опыта в этом языке/технологиях, но не набивший руку на подобных задачках, гарантировано проиграет студенту, победителю районной олимпиады, который тупо выучил книжки тысяча вопросов на собеседование по языку X?
bay73
12.12.2016 18:56+3Основная ошибка собеседующихся — это думать, что правильный ответ на технический вопрос равносилен успеху на интервью. Правильность ответов на интервью вообще мало кого беспокоит. Важнее не сам ответ, а то как кандидат на него отвечает, как его обсуждает, какие вопросы задает сам.
Rasifiel
12.12.2016 16:54+3В результате, может сложиться так что буквально студент-junior пройдет то тех.интервью на котором провалиться человек с огромным опытом в этой сфере.
Это не баг, а фича. Если человек с огромным опытом не может решить обход дерева, бинарный поиск, то ему возможно будет тяжело взаимодействовать с другими сотрудниками. Опыт с другими технологическими стеками (у Гугла почти все свое) и языковой опыт (никогда не писал на плюсах до работы тут) Гугл интересует гораздо меньше чем универсальный алгоритмический базис. Да, возможно можно поменять вообще все в Гугле и нанимать других людей и иным способом, но тогда это будет совсем другие команды, люди и компания.khim
12.12.2016 19:05Опыт с другими технологическими стеками (у Гугла почти все свое) и языковой опыт (никогда не писал на плюсах до работы тут) Гугл интересует гораздо меньше чем универсальный алгоритмический базис.
Это не совсем так. Он их тоже интересует — но в том случае если вы претендуете на соответствующую позицию.
А так — да, опыт работы с вещами, с которыми вы, скорее всего, никогда в своей работе не столкнётесь, так как у Гугла «всё своё» начиная от VCS (особой надстройки на git) и кончая базами данных и прочими вещами — не ценится. И довольно-таки понятно почему.Rasifiel
12.12.2016 20:57Даже если позиция занимается чем-то общим все равно ценность этих знаний ниже. Считается, что проще научить человека с сильной базой нужным технологиям, чем наоборот. Оно будет бонусом, но не основным критерием.
Мелочи ради
начиная от VCS (особой надстройки на git)
Нет там гита, к счастью. Есть только слой для любителей гита, чтобы работать как с гитом.
Maccimo
12.12.2016 20:41+1Обычно если тебе предлагают решать задачу которую ты уже решал, то так и стоит сказать «я вот именно такую задачу решал»
Как тут не вспомнить анекдот: http://www.anekdot.ru/id/-111121027/
to_climb
17.12.2016 20:332^n — экспоненциальная сложность/полный перебор — это
за гранью добра и злакак-то многовато для приемлемого решения.dimm_ddr
19.12.2016 11:312^n может быть ок для отправной точки, для разового или почти разового применения, либо для очень небольшого объема данных. В последнем случае, правда стоит большими буквами написать комментарий, хотя бы, что нужно поменять метод если данных станет больше.
BelBES
11.12.2016 23:24Самые важные темы — Big-O notation
А чего такого зубодробительного могут спросить про Ландау нотацию? Или это в контексте рассмотрения других алгоритмов (типа "какая сложность у qsort?")?
RomanArzumanyan
12.12.2016 09:26+1Сложность рекурсивных алгортмов, сложность в среднем. Это не rocket science, но универ вспомнить придётся. Плюс волнение.
SamDark
12.12.2016 16:44Дать задачу с условием "сложность не выше O(N)" про химические соединения с ограничением времени в 25 минут, например :) Личный опыт.
khim
12.12.2016 19:14+1Это в контексте того, что вы всегда должны держать в голове сложность ваших алгоритмов. Это не значит, что вы всегда должны использовать самый лучший алгоритм (комментарий типа «тут мы используем вложенный цикл, что даёт нам сложность O(N2), но так как количество элементов в этом массиве не будет превышать 10, то ничего более сложного нам не нужно» — это нормально), но вы должны понимать — какая сложность у того, что вы творите. Всегда. В любой точке. В любой программе.
P.S. Понятно что бывают и очень сложные и заковыристые алгоритмы где ответ на вопрос «а какая тут сложность» — сходу не ответить. Сталкиваться вы с ними будете в работе хорошо если раз в год, так что вот их конкретно — будет время обработать. Но сама идея что вы спокойно, не шелохнувшись, пишете код и не знаете — сколько он потребует памяти и процессорного времени — не укладывается в голове у людей, которые работают с масштабами Facebook'а или Google'а. Когда у вас миллиарды пользовалей разницы между O(N) и O(N2) — это не разница между «хорошо» и «плохо». Это разница между «держит нагрузку» и «этот код можно выкидывать не обсуждая».
ternaus
12.12.2016 00:32+3По весне интервьюировался в Google на позицию Quantitative Analyst. Рекрутер вышла на меня сама. Я географически живу недалеко, поэтому вместо технического телефонного интервью попросил приехать к ним в офис и общаться вживую, отвечая на вопросы на Whiteboard. Мне пошли на встречу. Пара таких технических интервью, а потом приглашение к ним в офис на onsite от которого я отказался.
Основные причины моего отказа от onsite interview:
- Quantitative Analyst — это много статистики, мне же в свою очередь интересно Machine Learning / Deep learning. Причем интервьюировался я на эту позицию потому что рекрутер, который со мной связялся хотел заполнить именно эту вакансию, а не потому что она мне была интересна.
- Офис расположен в Mountain View, причем по утрам и вечерам дикие пробки, то есть это либо в этой деревне жить, либо тратить кучу времени на транспорт.
- Мне дали интересный офер, с жестким дедлайном, так что был выбор либо реальный офер с Машинным обученим в стартапе в Сан Франциско или теоретический офер на работу со статистикой в Google в деревне. => я выбрал Сан Франциско.
Интервьюируют достаточно жестко, но интересно, то что я что-то не знаю или не помню каких-то стандартных с их точки зрения в статистике вещей можно компенсировать тем, что быстро выдаешь рабочие решения, даже если они не самые оптимальные.
В общем очень приятные впечатления от всего этого процесса, за исключением одного — в Google процесс наема идет так долго… Facebook и Uber в разы оперативнее. Говорят, что они пытаются ускорить процес найма. Поглядим через пару месяцев.
i360u
12.12.2016 08:12+6Почему-то мне кажется, что такой процесс найма отсеивает реально талантливых разработчиков: проходить отбор будут только крепкие середнячки с определенной долей упорства в характере, но не более того.
vsapronov
12.12.2016 08:35+15Есть теория, что им как раз только такие и нужны: «крепкие середнячки с определенной долей упорства». А то наймешь гениев и они поднимут бузу: «а че такой код говенный» и «менеджер, выучи матчасть сначала». И развлекать их надо много, чтобы не печалилсь и не разбегались с своим опытом и секретами компании… Нет, середнячков, только середнячков…
lanseg
12.12.2016 09:17+3Мне кажется, большинство «крепких середнячки» в гугле вполне себе талантливые, но без звёздной болезни и раздутого самомнения.
А то наймут пару десятков «Шелдонов», которые будут вечно собачиться друг с другом вместо какой-то продуктивной деятельности.
Tsimur_S
12.12.2016 12:51+1Полагаю что действительно талантливых людей(чемпионов международных конкурсов, авторов програмных языков, популярных инструментов и концепций) они нанимают через совсем другие механизмы. Крепкие середнячки с долей упорства как раз таки идеальный костяк любого продукта, к тому же они все равно будут на голову превосходить «среднестатистических» программистов. Ну а к талантливым, но не засветившимся нигде людям действует житейский принцип: талантливый человек талантлив во всем. Если это происходит без перегибов типа как произошло с автором homebrew, то модель выглядит рабочей.
0xd34df00d
12.12.2016 23:54А что там с автором homebrew-то произошло? А то уже второй раз за тред отсылку вижу.
Tsimur_S
13.12.2016 00:49https://twitter.com/mxcl/status/608682016205344768?lang=ru видимо они не сошлись во взглядах на то как нужно инвертировать дерево.
На самом деле я ошибся, поскольку под перегибами я имел в виду другой случай с автором g-wan веб сервера, где собеседование проводил хр с ответами на бумажке.https://habrahabr.ru/post/313028/
madhead
12.12.2016 09:00+16Честно говоря, статья ни о чём.
Andrey_911
12.12.2016 12:51+3Согласен. Хорошим дополнением к статье была-бы приписка «история была рассказана за чашечкой чая в пятницу вечером».
TheGodfather
12.12.2016 12:51Собеседовался в сентябре на вакансию SETI (то, что раньше было Software Engineer in Test), сначала был телефонный звонок с рекрутером, потом пригласили на гуглодок-интервью с инженером из команды. Впечатление от собеседования осталось негативное и вот почему:
- Заранее перед интервью спросили, на каком ЯП предпочитаю проходить интервью, я выбрала Питон, поскольку именно на нем приходилось писать последние 3 года, на си/плюсах в универе последний раз писал. На собеседовании же как дошло дело до вопроса на кодинг, выдали задачу с битовыми полями. Ну и, очевидно, слету не удалось написать нормальный код, я был несколько разочарован таким подходом.
- Не было ни одного вопроса по теме, только про алгоритмы, сложности и все такое. Т.е. натурально ни одного вопроса про практики разработки, тестирование, качество и прочее. Ну я, конечно, читал Cracking the Code Interview, но все-таки ожидал, что при собеседований человека с опытом основное внимание будет уделяться релевантному опыту, а не универской теории. А тут будто на собеседование студента попал, у которого опыта нет, вот и спрашивают что могут.
- Где-то в письмах они потеряли мою просьбу собеседоваться в Hangouts, поэтому сначала был звонок на телефон и чувак чуть ли не после hi-hi разогнался и пошел фигачить вопросы "сколько стоит вставка в хэш-таблицу". Наверное, вы догадываетесь, что международный телефонный звонок по качеству — то еще развлечение, пришлось его перебить и напомнить, что хотели в Hangouts общаться.
Ну и понятно, что мне написали "вы молодец, но в этот раз мы решили не продолжать", сам понимал, что налажал много где, в первую очередь с кодом, ибо не ожидал такой подставы.
В этом плане Интел куда более адекватно собеседует, вопросы на 95% релевантны должности, никаких бесполезных вопросов не по теме, все релевантно или позиции или резюме.
Rasifiel
12.12.2016 17:04+2Software Engineer in Test все же больше Software Engineer. Он не занимается написанием тестов, а пишет инфраструктуру. Плюс гуглдок интервью не является финальным, а просто первая стадия проверки на общие навыки разработчика.
Заранее перед интервью спросили, на каком ЯП предпочитаю проходить интервью, я выбрала Питон, поскольку именно на нем приходилось писать последние 3 года, на си/плюсах в универе последний раз писал. На собеседовании же как дошло дело до вопроса на кодинг, выдали задачу с битовыми полями. Ну и, очевидно, слету не удалось написать нормальный код, я был несколько разочарован таким подходом.
В Питоне нельзя с ними работать или требовали что-то специфичное для си/плюсов?TheGodfather
12.12.2016 20:58Так я и не говорю, что это финальное собеседование было, понятно, что только начало процесса.
В Питоне нельзя с ними работать, да. Плюс интервьювер в контексте задачи использовал union, которых тоже в Питоне не существует.
brainunavailable
12.12.2016 12:51мне ответили через неделю. жаль из onsite завалил 2(из одного допустимого) и как на зло это не было дизайн-интервью.
echo_mont
12.12.2016 12:51Гугл собеседует из-за поисковых запросов? Вот это да! У меня есть шанс попасть в НАСА!
cb_ein
12.12.2016 14:48Тоже споткнулся на этой фразе. Это я приду такой к ним красивый и умный на собеседование, а у них там помимо CV распечатка моих поисковых запросов лежит? Что-то мне подсказывает, что это сильно уменьшит мои шансы успешно пройти собеседование.
Rothmansua
12.12.2016 13:41-8Вот вы пишите
«Если вы хорошо готовились к каждому интервью и имеете шансы на каждом собеседовании 80% из 100, что очень круто, то по теории вероятности после 6 технических интервью Ваши шансы равны 0.8^6 = 0.26.»
На самом деле, при таком раскладе, вероятность пройти после 6-ти интервью
P = 1 — (1-0.8)^6 = 0,999936
Есть потенциал для улучшения перед следующей попыткой :)Jigglypuff
12.12.2016 13:48+51-0.8 = 0.2 — это вероятность провалиться на одном собеседовании.
0.2^6 — вероятность провалить все 6 собеседований.
1-0.2^6 — вероятность провалиться менее, чем на 6 собеседованиях (0..5).
У девушки всё верно, это частный случай формулы Бернулли.
P.S. Подразумевается, что для получения оффера нужно пройти все 6 (разных) интервью, а не одно из них.Rothmansua
12.12.2016 13:58-6Вы зря минусуете если не разбираетесь.
«0.2^6 — вероятность провалить все 6 собеседований»
соверешенно верно, нам нужно не провалить хотя бы одно (т.е. любой исход кроме того, у которого вероятность 0.2^6), потому
P = 1 — (1-0.8)^6 = 0,999936
(зачем я это разжевываю? :) )Jigglypuff
12.12.2016 14:01Речь идёт о попытке устроиться в Google.
В крупных компаниях процесс устройства состоит из последовательности различных технических интервью (обсуждение используемого языка, архитектура, алгоритмы и т.д.).
И кандидат, чтобы получить оффер, должен пройти все собеседования.
Если бы речь шла о попытках устроиться в 6 разных контор, в каждой из которых нужно пройти 1 интервью, то Ваш вариант был бы верен.
P.S. Минусую не я, у меня банально нет такой возможности.bay73
12.12.2016 19:03> Речь идёт о попытке устроиться в Google.
> И кандидат, чтобы получить оффер, должен пройти все собеседования.
Это не совсем так. Далеко не про каждое собеседование можно сказать «прошел/не прошел». Не бинарная это штука, а многоступенчатая. А уж способ суммирования результатов тем более слабоалгоритмизируем.Jigglypuff
12.12.2016 20:49Всё верно, но речь идёт сугубо о корректности вычислений, представленных в статье.
Если уж на то пошло, то и понятие «вероятность прохождения собеседования» использовать нельзя.
Однако, если уж речь пошла про пример из статьи — было бы странно уклоняться от заданного в нём базиса.
Rothmansua
12.12.2016 14:04+2Окей, забираю свои комментарии назад.
Если надо пройти все 6, то да, у девушки все верно.
Rothmansua
12.12.2016 13:57-2Вы зря минусуете если не разбираетесь.
«0.2^6 — вероятность провалить все 6 собеседований»
соверешенно верно, нам нужно не провалить хотя бы одно (т.е. любой исход кроме того, у которого вероятность 0.2^6), потому
P = 1 — (1-0.8)^6 = 0,999936Rothmansua
12.12.2016 14:05+1Забираю и этот комментарий назад.
Если надо пройти все 6, то да, у девушки все верно.
novoselov
12.12.2016 20:33На самом деле расчет очень грубый, на каждом этапе проходит разное количество человек.
Компании стараются максимально отсеять неадекватов на самом раннем этапе, каждое следующее собеседование стоит компании все дороже в плане денег и времени реальных людей.
Mugik
12.12.2016 14:32+9Всю эту воду можно было ужать в:
На техническом интервью было 2 вопроса. Один совсем простой про работу со String. По сложности — 1 курс универа. Второй вопрос сложнее (я предлагала Бинарный поиск и прочее) — субъективно 3 курс универа
Спасибо огромное. Информация невероятно полная и полезная. Я думаю после вашей действительно откровенной статьи шансы у людей увеличились.
Ожидал прочитать как обычно ерунду, а тут прямо удивительно развернутый, интересный рассказ о прохождении интервью.
Rasifiel
12.12.2016 17:51Стоит учитывать, что это только телефонное интервью, которое первый этап чтобы проверить базовые знания. Потом еще 5 часовых интервью на онсайте на которых вопросы несколько сложнее и разнообразнее.
viru0
12.12.2016 18:40+2Я вообще не пониманию как Google умудряется нанимать местных специалистов. (С тем кому нужна H1B, Green Card e.t.c совсем другая история)
Не давно сам искал работу, получил первый оффер раньше чем телефонное интервью с google было назначено. Причем и с тем и с другим рекрутером начал разговаривать примерно в одно время.
Они сразу говорят что процесс минимум 1.5 месяца, и это в лучшем случае.
При этом даже в конторы с 1000+ людей можно устроится за 2 недели максимум.
А тут у народа обычно кредитов вагон и маленькая тележка и.т.п. Мое личное мнение что Google сотрудники не особо нужны, нанимают «чтоб было» и денег хватает. Но реальной потребности(а соответсвенно понимания что ты будешь делать и зачем ты нужен — не будет) как таковой нет.
Гугл очень и очень полезен с другой стороны если разные вопросы с иммиграцией надо решить, у них опыта много, юристы, не первый кейс. Но это совсем другая история.bay73
12.12.2016 19:06+1В Гугл никто и не ищет людей на конкретный проект. Горящих вакансий не бывает. Сначала сотрудника принимают на работу, а уж потом определяют проект, локацию и т.п. В статье об этом, кстати, написано.
Rasifiel
12.12.2016 21:02Ну не обязательно быть без работы, чтобы собеседоваться в гугл. Многие идут собеседоваться уже где-то работая, потому что хочется больше, что-то поменять, где-то конкретно поработать.
weiser
13.12.2016 14:43Очень интересная градация сложности вопросов по курсам универа. Прошу указать в статье, какого именно универа и, желательно, семестра, это очень поможет будущим соискателям работы в Google.
ashomokdev
17.12.2016 23:24Это Вам никак не поможет. В статье я просто хотела сказать, что вопросы простые. По университетской программе. Вам поможет отличное знание курса «Алгоритмы и структуры данных».
spamas
13.12.2016 14:43-3У меня один вопрос по всей этой гугло-ахении, сколько можно у инженеров спрашивать по алгоритмам? Нанимайте спеца по алгоритмам, зачем програмистов мучать? Кто-то вообще потом в ежедневной работе высчитывал какой там BigO в моём коммите? Тупоголовый догматизм повсюду
svboobnov
13.12.2016 15:59+3У Гугла все технологии свои. Системный язык — Go, прикладные языки — Dart, JavaScript, Java; СУБД своя — BigTable и так далее. То есть, человек, который знает какие-то API им не нужен.
А оттого, что объёмы данных и количество клиентов у них гигантские, разница даже между O(n) и O(ln n) для них очень важна.khim
13.12.2016 18:26-1А оттого, что объёмы данных и количество клиентов у них гигантские, разница даже между O(n) и O(ln n) для них очень важна.
Разница между O(n) и O(ln n) всегда велика, за исключением самых тривиальных случаев. Я думаю вы имели в виду разницу между O(1) и O(ln n) — а вот она даже в масштабах гугла может часто перебиваться константой.
Главное чего хочет Гугл — это чтобы никто, нигде и никогда в коде не породил алгоритма Шлемиэля. Количество людей, который с радостью неописуемой порождают O(n2) вместо O(n) — устрашает. Вот с ними на собеседованиях, в основном, и идёт борьба.svboobnov
13.12.2016 19:01+1Да уж, Джоэл привёл замечательную притчу про маляра Шлемиля =)
А по поводу О(1) и О(in n) нууу не всегда такой алгоритм получится изобрести, потому я про более реалистичные случаи написал.
alexeykuzmin0
14.12.2016 13:48-1Мои гугловские знакомые говорят, что в их задачах n легко может быть порядка сотен миллиардов или триллионнов, на таких масштабах константа перебивает нечасто
khim
14.12.2016 17:28+1log21'000'000'000'000 < 40. Написать кусок кода, который будет отличаться от другого в 40 сложно, но можно. Так что логарифм зачастую не страшен даже в Гугле.
А вот чтобы разница между O(n) и O(log n) выстрелила, нужно не так много данных. Я много общался с программами, которые совершенно однозначно содержали пресловутого «маляра» — и для того, чтобы это было заметно петабайтов данных не требовалось.
P.S. Кстати всевозможные пакетные менеджеры очень часто этим грешат. Люди, которые их создают обладают массой полезных качеств (умение работать в команде, умение разрираться в разнообразных билд-системах и т.д. и т.п.), но вот умение писать масштабируемые системы — очень часто не их конёк.alexeykuzmin0
15.12.2016 13:44-1Вот и я о том же. Разница между O(n) и O(log n) почти всегда очевидна, и сильно портит жизнь в любой компании. А вот в Google, в отличие от любой небольшой компании, данных достаточно, чтобы и лишний логарифм был непозволительной роскошью. Не всегда, конечно, но часто.
Maccimo
13.12.2016 16:03+1ахении
Вам сюда: http://gramota.ru/slovari/dic/?word=%D0%B0%D1%85%D0%B8%D0%BD%D0%B5%D1%8F&all=x
сколько можно у инженеров спрашивать по алгоритмам? Нанимайте спеца по алгоритмам, зачем програмистов мучать?
Кажется, вы путаете термины "говнокодер" и "программист" (с двумя "м", прошу заметить).
Первому — да, нафиг алгоритмы не нужны.
khim
13.12.2016 18:19+2У меня один вопрос по всей этой гугло-ахении, сколько можно у инженеров спрашивать по алгоритмам?
Вот пока такие как вы будут пытаться устроиться работать в Гугл — и придётся это делать.
Нанимайте спеца по алгоритмам, зачем програмистов мучать?
Затем что не имеет смысла мучить «спеца по алгоритмам», чтобы они вычитывали весь код и отслеживали %$^%%&^, которые норовят вкрутить в любую дырку маляра Шлемиэля.
Кто-то вообще потом в ежедневной работе высчитывал какой там BigO в моём коммите?
Что значит «высчитывал какой там BigO в вашем коммите»? Если вы код написали — вы и должны за этим следить. Если вы предлагаете ассимптотически неоптимальное решение — будьте любезны добавить комментарий, объясняющий почему вы считаете что в данном случае — это неважно. А как вы это знаете если вы не видите этих самих BigO в написанном вами коде???
ConceptDesigner
13.12.2016 14:43+1Хотелось бы узнать, какое у автора образование и опыт профессиональной работы в области программирования. Интересует, работали ли Вы в коммерческих проектах. Чтобы читатели могли спроецировать ситуацию на себя.
ashomokdev
17.12.2016 23:21Бакалавр, Программная инженерия, Киево-Могилянская академия, Украина. Есть небольшой опыт, себя считаю Java Junior. Вот мой профиль https://ua.linkedin.com/in/iuliiaashomok
Sergey99999
16.12.2016 17:56-1Это «нормальная» практика.
Приглашают очень большее количевство кандидатов, даже с заведомо хучшими требованиями чем им надо.
У них такая работа — набрать на собеседования как можно больше людей, и проводить мосштабную кампанию по приему на работу сотрудника.
Иначе как им еще обяснить те затраты которые они тратят на HR отдел??? Денег то у них много)))
alexlitvinenko
17.12.2016 23:14Я прочитал статью, комментарии других пользователей и у меня немного другое понимание мобильной разработки: телефон это клиент, а не большая вычислительная машина, а клиент не должен делать сложных решений алгоритмов, главная цель клиента это отображение данных и плавная, стабильная работа с красивых интерфейсом (так как это нравится конечным юзерам). Это лично моё мнение и я не пытаюсь сказать, что оно абсолютно правильное и единственно возможное. Так вот я не совсем понимаю почему на таких собеседованиях нет таких важных вопросов как архитектура (что позволяет проекту быть хорошо поддерживаемым, расширяемым, т.д.) ну и в целом андроид разработка. Укажите плз в чем я могу быть не прав или почему моё мнение ошибочно?
ashomokdev
17.12.2016 23:18+1Меня собеседовали на вакансию Java программиста, а не Android разработчика, UI специалиста или верстальщика. Теорию знать очень важно. Разбираться в архитектуре тоже важно — этому в Google посвящается отдельное собеседование (в офисе). Но я до этого этапа не дотянула.
bay73
20.12.2016 15:14А кто вам сказал, что нет собеседований на архитектуру, системный дизайн и т.д.?
Автор описал первый этап — телефонное интервью. Успешное прохождение этого этапа это далеко не финиш. Интервью на алгоритмы — первый отсеивающий фильтр.
Более того, автор — Junior Android developer. Никто не ожидает от кандидата на позицию Junior глубоких познаний в архитектуре. То есть после успеха на телефонном интервью такие собеседования всё-равно были бы, но в облегченном варианте.
khim
20.12.2016 18:03телефон это клиент, а не большая вычислительная машина, а клиент не должен делать сложных решений
О как. А ничего что на телефоне ещё и батарейка есть и то, сколько всё это ресурсов жрёт напрямую влияет на то, как пользователи будут воспринимать ваш продукт?
Да, если вы «мобильный разработчик», который может себе позволить роскошь «забить» на телефоны меньше чем с 10 ядрами и меньше чем 4 гигибайтами памяти — то для вас, может быть, все эти алгоритмы и не важны. Поставил фильтр в Google Play — и всех делов.
Но мобильный разработчик в гугле должен делать вещи, которые будут демонстрировать «плавную стабильную работу» на всяких индусских телефонах с процессорами трехлетней давности и с весьма «обрезанными» другими спецификациями. Тут подходом «я написал алгоритм, а сколько он будет требовать ресурсов для своей работы — мне не интересно» не годится.
Laney1
проходил сабж год назад. Рекрутер не задавал никаких технических вопросов и видимо вообще не смотрел мое резюме, причину отказа после 2-го интервью мне также не сообщили.
В любом случае, думаю что на интервью с гуглом очень легко попасть, но так очень велики сроки прохождения (после каждого этапа ответ от рекрутера можно ждать месяц) и процент отказов. Если вы хотите найти работу в течение пары месяцев, то это вариант не для вас.
ashomokdev
Мне дали ответ на второй день.
vsapronov
Кому-то дали ответ прямо во время интервью. Я уверен есть такие. Вобщем у их интервью-процесса нет SLA. Я как пользователь услуги «интервью» всегда интересуюсь SLA и хочу видеть его на нормальном уровне. У Google оно отсутствует, типа: «ответим, когда ответим». Никакие частные редкие случаи быстрых ответов это не могут исправить.
То, что в Google (да и вобщем по индустрии) сломан процесс собеседования известно и широко обсуждается. Одна история ненайма создателя homebrew в Google чего только стоит. Пока никто не может придумать, как это пофиксить. Все прикрываются фразами: «false negative is better then false positive» и сцыкуют перед всякими радикальными практиками найма.
base2
В моем случае прошло примерно 2 месяца между телефонным интервью и сообщением от них, что я его прошел. Причем, в течение этих 2-х месяцев я им напоминал о себе раз в 2 недели.