Pull to refresh

Comments 89

UFO just landed and posted this here
Мне дали ответ на второй день.
UFO just landed and posted this here
В моем случае прошло примерно 2 месяца между телефонным интервью и сообщением от них, что я его прошел. Причем, в течение этих 2-х месяцев я им напоминал о себе раз в 2 недели.
Точно так же проходил у меня отбор в facebook, с которым я имел дело пару лет назад. Тоже советовали почитать литературу, почитать про структуры данных, про расчет big-O. Тоже была тренировка, которая проходит периодически для всех кандидатов.

На собеседовании был всего один вопрос — написать программу (в моем случае на Python). Времени на все дается не так много: 45 минут. При этом считается хорошим тоном успеть не только решить задачу (желательно тремя различными способами), но и поназадавать собеседующему кучу интересных вопросов (о его проекте, о команде, компании и пр.).

Очевидно, что в таких условиях можно решить только такую задачу, похожую на которую ты когда-либо уже успешно решал (а желательно именно такую). В моем случае задача была довольно сложной, с которой ранее сталкиваться не приходилось, даже близко. Успел вроде пару способов предложить, на третий, который самый лучший обычно становится, уже не хватило времени. Но собеседование я скорее всего провалил после вопроса о сложности получившихся алгоритмов, на который я к моему стыду ответить не смог. Она оказалась равна O(2^n).

Отсюда вывод: готовится к таким собеседованиям нужно очень тщательно. Также желательно перерешать все задачи из сборников задач для проходящих собеседование в Google (можно найти такие, и HR сами их даже рекомендуют), и даже не один раз. И очень важно научится определять сложность любого алгоритма, даже самого изощренного.
Обычно если тебе предлагают решать задачу которую ты уже решал, то так и стоит сказать «я вот именно такую задачу решал», потому что если ты знаешь решение, то это хорошо видно по процессу решения и может не очень понравиться собеседующему. Задачи задают не чтобы проверить как хорошо ты вызубрил их, а как ты можешь решать новое и применять стандартные алгоритмы для разных задач.
Не обязательно такую же, большинство олимпиадных задач делается по аналогии, достаточно понять что задача сводится к задачи, скажем, коммивояжёра и дальше все стандартно.

Задачи задают не чтобы проверить как хорошо ты вызубрил их, а как ты можешь решать новое и применять стандартные алгоритмы для разных задач.

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

В результате, может сложиться так что буквально студент-junior пройдет то тех.интервью на котором провалиться человек с огромным опытом в этой сфере.
Ну так свести — это и должно быть самое сложное, если задача хорошая. Кирпичики стандартных алгоритмов все давно знают и умеют писать за минуту с завязанными глазами левой рукой
Увы, сведение типовых задач (а большинство задач на собеседованиях типовые) так же зубрятся как и алгоритмы. Навык прохождения тех. интервью != навыку реальной работы на проектах. Наловчится решать такие полуолимпиадные задачки может студент за несколько месяцев. Какой смысл в интервью где человек с 15 годами опыта в этом языке/технологиях, но не набивший руку на подобных задачках, гарантировано проиграет студенту, победителю районной олимпиады, который тупо выучил книжки тысяча вопросов на собеседование по языку X?
Основная ошибка собеседующихся — это думать, что правильный ответ на технический вопрос равносилен успеху на интервью. Правильность ответов на интервью вообще мало кого беспокоит. Важнее не сам ответ, а то как кандидат на него отвечает, как его обсуждает, какие вопросы задает сам.
В результате, может сложиться так что буквально студент-junior пройдет то тех.интервью на котором провалиться человек с огромным опытом в этой сфере.

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

А так — да, опыт работы с вещами, с которыми вы, скорее всего, никогда в своей работе не столкнётесь, так как у Гугла «всё своё» начиная от VCS (особой надстройки на git) и кончая базами данных и прочими вещами — не ценится. И довольно-таки понятно почему.
Даже если позиция занимается чем-то общим все равно ценность этих знаний ниже. Считается, что проще научить человека с сильной базой нужным технологиям, чем наоборот. Оно будет бонусом, но не основным критерием.

Мелочи ради
начиная от VCS (особой надстройки на git)

Нет там гита, к счастью. Есть только слой для любителей гита, чтобы работать как с гитом.
Обычно если тебе предлагают решать задачу которую ты уже решал, то так и стоит сказать «я вот именно такую задачу решал»

Как тут не вспомнить анекдот: http://www.anekdot.ru/id/-111121027/

2^n — экспоненциальная сложность/полный перебор — это за гранью добра и зла как-то многовато для приемлемого решения.
2^n может быть ок для отправной точки, для разового или почти разового применения, либо для очень небольшого объема данных. В последнем случае, правда стоит большими буквами написать комментарий, хотя бы, что нужно поменять метод если данных станет больше.
Самые важные темы — Big-O notation

А чего такого зубодробительного могут спросить про Ландау нотацию? Или это в контексте рассмотрения других алгоритмов (типа "какая сложность у qsort?")?

Сложность рекурсивных алгортмов, сложность в среднем. Это не rocket science, но универ вспомнить придётся. Плюс волнение.

Дать задачу с условием "сложность не выше O(N)" про химические соединения с ограничением времени в 25 минут, например :) Личный опыт.

Это в контексте того, что вы всегда должны держать в голове сложность ваших алгоритмов. Это не значит, что вы всегда должны использовать самый лучший алгоритм (комментарий типа «тут мы используем вложенный цикл, что даёт нам сложность O(N2), но так как количество элементов в этом массиве не будет превышать 10, то ничего более сложного нам не нужно» — это нормально), но вы должны понимать — какая сложность у того, что вы творите. Всегда. В любой точке. В любой программе.

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 в разы оперативнее. Говорят, что они пытаются ускорить процес найма. Поглядим через пару месяцев.

Почему-то мне кажется, что такой процесс найма отсеивает реально талантливых разработчиков: проходить отбор будут только крепкие середнячки с определенной долей упорства в характере, но не более того.

UFO just landed and posted this here

Я говорил о людях, которые умеют мыслить нестандартно, а Вы — о каких-то мудаках.

К сожалению это не всегда разные люди.
Мне кажется, большинство «крепких середнячки» в гугле вполне себе талантливые, но без звёздной болезни и раздутого самомнения.
А то наймут пару десятков «Шелдонов», которые будут вечно собачиться друг с другом вместо какой-то продуктивной деятельности.
Полагаю что действительно талантливых людей(чемпионов международных конкурсов, авторов програмных языков, популярных инструментов и концепций) они нанимают через совсем другие механизмы. Крепкие середнячки с долей упорства как раз таки идеальный костяк любого продукта, к тому же они все равно будут на голову превосходить «среднестатистических» программистов. Ну а к талантливым, но не засветившимся нигде людям действует житейский принцип: талантливый человек талантлив во всем. Если это происходит без перегибов типа как произошло с автором homebrew, то модель выглядит рабочей.
UFO just landed and posted this here
https://twitter.com/mxcl/status/608682016205344768?lang=ru видимо они не сошлись во взглядах на то как нужно инвертировать дерево.
На самом деле я ошибся, поскольку под перегибами я имел в виду другой случай с автором g-wan веб сервера, где собеседование проводил хр с ответами на бумажке.https://habrahabr.ru/post/313028/

А потом это на HackerNews обсуждали.
Согласен. Хорошим дополнением к статье была-бы приписка «история была рассказана за чашечкой чая в пятницу вечером».

Мне в качестве первого этапа собеседования в Nest (куплен Google) предложили придумать архитектуру небольшого проекта и снять "professional-looking" видео с рассказом о ней. Отказался.

UFO just landed and posted this here

Собеседовался в сентябре на вакансию SETI (то, что раньше было Software Engineer in Test), сначала был телефонный звонок с рекрутером, потом пригласили на гуглодок-интервью с инженером из команды. Впечатление от собеседования осталось негативное и вот почему:


  • Заранее перед интервью спросили, на каком ЯП предпочитаю проходить интервью, я выбрала Питон, поскольку именно на нем приходилось писать последние 3 года, на си/плюсах в универе последний раз писал. На собеседовании же как дошло дело до вопроса на кодинг, выдали задачу с битовыми полями. Ну и, очевидно, слету не удалось написать нормальный код, я был несколько разочарован таким подходом.
  • Не было ни одного вопроса по теме, только про алгоритмы, сложности и все такое. Т.е. натурально ни одного вопроса про практики разработки, тестирование, качество и прочее. Ну я, конечно, читал Cracking the Code Interview, но все-таки ожидал, что при собеседований человека с опытом основное внимание будет уделяться релевантному опыту, а не универской теории. А тут будто на собеседование студента попал, у которого опыта нет, вот и спрашивают что могут.
  • Где-то в письмах они потеряли мою просьбу собеседоваться в Hangouts, поэтому сначала был звонок на телефон и чувак чуть ли не после hi-hi разогнался и пошел фигачить вопросы "сколько стоит вставка в хэш-таблицу". Наверное, вы догадываетесь, что международный телефонный звонок по качеству — то еще развлечение, пришлось его перебить и напомнить, что хотели в Hangouts общаться.

Ну и понятно, что мне написали "вы молодец, но в этот раз мы решили не продолжать", сам понимал, что налажал много где, в первую очередь с кодом, ибо не ожидал такой подставы.


В этом плане Интел куда более адекватно собеседует, вопросы на 95% релевантны должности, никаких бесполезных вопросов не по теме, все релевантно или позиции или резюме.

Software Engineer in Test все же больше Software Engineer. Он не занимается написанием тестов, а пишет инфраструктуру. Плюс гуглдок интервью не является финальным, а просто первая стадия проверки на общие навыки разработчика.

Заранее перед интервью спросили, на каком ЯП предпочитаю проходить интервью, я выбрала Питон, поскольку именно на нем приходилось писать последние 3 года, на си/плюсах в универе последний раз писал. На собеседовании же как дошло дело до вопроса на кодинг, выдали задачу с битовыми полями. Ну и, очевидно, слету не удалось написать нормальный код, я был несколько разочарован таким подходом.

В Питоне нельзя с ними работать или требовали что-то специфичное для си/плюсов?

Так я и не говорю, что это финальное собеседование было, понятно, что только начало процесса.


В Питоне нельзя с ними работать, да. Плюс интервьювер в контексте задачи использовал union, которых тоже в Питоне не существует.

Вы словно Яндекс описали. Аналогично, 5 часов общих вещей: алгоритмы, сложность, задачи на логику. Ни одного вопроса про опыт, архитектуру софта, какие-то фундаментальные бест-практисы. После 10 работы сложновато.у вчерашнего студента больше шансов, всё ещё в памяти.

Студентов алгоритмам не учат. По крайней мере, меня на ВМК не учили.
мне ответили через неделю. жаль из onsite завалил 2(из одного допустимого) и как на зло это не было дизайн-интервью.
UFO just landed and posted this here
Собеседование по результатам поисковых запросов: «Мы готовы предложить вам работу порно-аналитиком»
UFO just landed and posted this here
Тоже споткнулся на этой фразе. Это я приду такой к ним красивый и умный на собеседование, а у них там помимо CV распечатка моих поисковых запросов лежит? Что-то мне подсказывает, что это сильно уменьшит мои шансы успешно пройти собеседование.
http://thehustle.co/the-secret-google-interview-that-landed-me-a-job
UFO just landed and posted this here
А у меня в центральный офис Pornhub
Вот вы пишите
«Если вы хорошо готовились к каждому интервью и имеете шансы на каждом собеседовании 80% из 100, что очень круто, то по теории вероятности после 6 технических интервью Ваши шансы равны 0.8^6 = 0.26.»

На самом деле, при таком раскладе, вероятность пройти после 6-ти интервью
P = 1 — (1-0.8)^6 = 0,999936

Есть потенциал для улучшения перед следующей попыткой :)
1-0.8 = 0.2 — это вероятность провалиться на одном собеседовании.
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

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

Если бы речь шла о попытках устроиться в 6 разных контор, в каждой из которых нужно пройти 1 интервью, то Ваш вариант был бы верен.

P.S. Минусую не я, у меня банально нет такой возможности.
> Речь идёт о попытке устроиться в Google.
> И кандидат, чтобы получить оффер, должен пройти все собеседования.
Это не совсем так. Далеко не про каждое собеседование можно сказать «прошел/не прошел». Не бинарная это штука, а многоступенчатая. А уж способ суммирования результатов тем более слабоалгоритмизируем.
Всё верно, но речь идёт сугубо о корректности вычислений, представленных в статье.
Если уж на то пошло, то и понятие «вероятность прохождения собеседования» использовать нельзя.
Однако, если уж речь пошла про пример из статьи — было бы странно уклоняться от заданного в нём базиса.
Окей, забираю свои комментарии назад.

Если надо пройти все 6, то да, у девушки все верно.
Вы зря минусуете если не разбираетесь.

«0.2^6 — вероятность провалить все 6 собеседований»

соверешенно верно, нам нужно не провалить хотя бы одно (т.е. любой исход кроме того, у которого вероятность 0.2^6), потому
P = 1 — (1-0.8)^6 = 0,999936
Забираю и этот комментарий назад.

Если надо пройти все 6, то да, у девушки все верно.
На самом деле расчет очень грубый, на каждом этапе проходит разное количество человек.
Компании стараются максимально отсеять неадекватов на самом раннем этапе, каждое следующее собеседование стоит компании все дороже в плане денег и времени реальных людей.
Всю эту воду можно было ужать в:

На техническом интервью было 2 вопроса. Один совсем простой про работу со String. По сложности — 1 курс универа. Второй вопрос сложнее (я предлагала Бинарный поиск и прочее) — субъективно 3 курс универа


Спасибо огромное. Информация невероятно полная и полезная. Я думаю после вашей действительно откровенной статьи шансы у людей увеличились.

Ожидал прочитать как обычно ерунду, а тут прямо удивительно развернутый, интересный рассказ о прохождении интервью.

Стоит учитывать, что это только телефонное интервью, которое первый этап чтобы проверить базовые знания. Потом еще 5 часовых интервью на онсайте на которых вопросы несколько сложнее и разнообразнее.
Я вообще не пониманию как Google умудряется нанимать местных специалистов. (С тем кому нужна H1B, Green Card e.t.c совсем другая история)
Не давно сам искал работу, получил первый оффер раньше чем телефонное интервью с google было назначено. Причем и с тем и с другим рекрутером начал разговаривать примерно в одно время.
Они сразу говорят что процесс минимум 1.5 месяца, и это в лучшем случае.
При этом даже в конторы с 1000+ людей можно устроится за 2 недели максимум.

А тут у народа обычно кредитов вагон и маленькая тележка и.т.п. Мое личное мнение что Google сотрудники не особо нужны, нанимают «чтоб было» и денег хватает. Но реальной потребности(а соответсвенно понимания что ты будешь делать и зачем ты нужен — не будет) как таковой нет.

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

Гугл рассматривает вариант с переводом человека по H1B? Надо им с льготы понравиться для этого?

не совсем понял ваш вопрос?
Перевод H1B (h1b transfer в оригинале). Оч простоя процедура, сделают запросто.
что есть льгота, я не знаю

У меня сложилось такое представление: для Н1В компании придется оплачивать всякие пошлины, подавать доки в гос. учреждения, и, самое главное, участвовать в квоте, и только раз в году. Вложиться в человека, чтобы лишь с некоторой вероятностью его перевезти через много месяцев. Если компания большая, есть филиалы, то куда проще человека буду устроить, и через годик — безо всяких квот перевезти по визе L1. Слышал про такую схему у Фейсбука (Европа, США), Майкрософт (Канада, США). Даже пару человек знаю, кто так переехал. Но вот про Н1В не слышал success stories.

Google крайне неохотно идет на оформление H1b. Если в вас не особенно заинтересованы, то делать не будут, а если вы великолепны, то, скорее всего, вам можно сделать O1. Хотя бывают исключения — например, если у вас есть американская магистратура, то вы проходите по другой очереди, и вам H1b, скорее всего, сделают.
Слышал где-то, что с недавнего времени (год-два) Гугл перестал по H1B переводить. Только L1 (ну или если у вас гринкарта появилась)
Ну, мне это в любом случае не грозит, 12 лет сугубо .net стека, гуглу адепт Microsoft не интересен) А так, вот честно говоря, вообще не слышал историй про H1B. Лично знаю человек 7 кто переехал по грин или L1, но не H1B. Поэтому, интересно, насколько это вообще реально (не только в гугл).
Раньше было реально, знаю несколько таких человек. В последние года два-три — скорее нет, чем да
Очень интересная градация сложности вопросов по курсам универа. Прошу указать в статье, какого именно универа и, желательно, семестра, это очень поможет будущим соискателям работы в Google.
Это Вам никак не поможет. В статье я просто хотела сказать, что вопросы простые. По университетской программе. Вам поможет отличное знание курса «Алгоритмы и структуры данных».
У меня один вопрос по всей этой гугло-ахении, сколько можно у инженеров спрашивать по алгоритмам? Нанимайте спеца по алгоритмам, зачем програмистов мучать? Кто-то вообще потом в ежедневной работе высчитывал какой там BigO в моём коммите? Тупоголовый догматизм повсюду
У Гугла все технологии свои. Системный язык — Go, прикладные языки — Dart, JavaScript, Java; СУБД своя — BigTable и так далее. То есть, человек, который знает какие-то API им не нужен.
А оттого, что объёмы данных и количество клиентов у них гигантские, разница даже между 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) нууу не всегда такой алгоритм получится изобрести, потому я про более реалистичные случаи написал.
Мои гугловские знакомые говорят, что в их задачах n легко может быть порядка сотен миллиардов или триллионнов, на таких масштабах константа перебивает нечасто
log21'000'000'000'000 < 40. Написать кусок кода, который будет отличаться от другого в 40 сложно, но можно. Так что логарифм зачастую не страшен даже в Гугле.

А вот чтобы разница между O(n) и O(log n) выстрелила, нужно не так много данных. Я много общался с программами, которые совершенно однозначно содержали пресловутого «маляра» — и для того, чтобы это было заметно петабайтов данных не требовалось.

P.S. Кстати всевозможные пакетные менеджеры очень часто этим грешат. Люди, которые их создают обладают массой полезных качеств (умение работать в команде, умение разрираться в разнообразных билд-системах и т.д. и т.п.), но вот умение писать масштабируемые системы — очень часто не их конёк.
Вот и я о том же. Разница между O(n) и O(log n) почти всегда очевидна, и сильно портит жизнь в любой компании. А вот в Google, в отличие от любой небольшой компании, данных достаточно, чтобы и лишний логарифм был непозволительной роскошью. Не всегда, конечно, но часто.
ахении

Вам сюда: http://gramota.ru/slovari/dic/?word=%D0%B0%D1%85%D0%B8%D0%BD%D0%B5%D1%8F&all=x


сколько можно у инженеров спрашивать по алгоритмам? Нанимайте спеца по алгоритмам, зачем програмистов мучать?

Кажется, вы путаете термины "говнокодер" и "программист" (с двумя "м", прошу заметить).
Первому — да, нафиг алгоритмы не нужны.

У меня один вопрос по всей этой гугло-ахении, сколько можно у инженеров спрашивать по алгоритмам?
Вот пока такие как вы будут пытаться устроиться работать в Гугл — и придётся это делать.

Нанимайте спеца по алгоритмам, зачем програмистов мучать?
Затем что не имеет смысла мучить «спеца по алгоритмам», чтобы они вычитывали весь код и отслеживали %$^%%&^, которые норовят вкрутить в любую дырку маляра Шлемиэля.

Кто-то вообще потом в ежедневной работе высчитывал какой там BigO в моём коммите?
Что значит «высчитывал какой там BigO в вашем коммите»? Если вы код написали — вы и должны за этим следить. Если вы предлагаете ассимптотически неоптимальное решение — будьте любезны добавить комментарий, объясняющий почему вы считаете что в данном случае — это неважно. А как вы это знаете если вы не видите этих самих BigO в написанном вами коде???
Хотелось бы узнать, какое у автора образование и опыт профессиональной работы в области программирования. Интересует, работали ли Вы в коммерческих проектах. Чтобы читатели могли спроецировать ситуацию на себя.
Бакалавр, Программная инженерия, Киево-Могилянская академия, Украина. Есть небольшой опыт, себя считаю Java Junior. Вот мой профиль https://ua.linkedin.com/in/iuliiaashomok
Это «нормальная» практика.
Приглашают очень большее количевство кандидатов, даже с заведомо хучшими требованиями чем им надо.
У них такая работа — набрать на собеседования как можно больше людей, и проводить мосштабную кампанию по приему на работу сотрудника.
Иначе как им еще обяснить те затраты которые они тратят на HR отдел??? Денег то у них много)))
Я прочитал статью, комментарии других пользователей и у меня немного другое понимание мобильной разработки: телефон это клиент, а не большая вычислительная машина, а клиент не должен делать сложных решений алгоритмов, главная цель клиента это отображение данных и плавная, стабильная работа с красивых интерфейсом (так как это нравится конечным юзерам). Это лично моё мнение и я не пытаюсь сказать, что оно абсолютно правильное и единственно возможное. Так вот я не совсем понимаю почему на таких собеседованиях нет таких важных вопросов как архитектура (что позволяет проекту быть хорошо поддерживаемым, расширяемым, т.д.) ну и в целом андроид разработка. Укажите плз в чем я могу быть не прав или почему моё мнение ошибочно?
Меня собеседовали на вакансию Java программиста, а не Android разработчика, UI специалиста или верстальщика. Теорию знать очень важно. Разбираться в архитектуре тоже важно — этому в Google посвящается отдельное собеседование (в офисе). Но я до этого этапа не дотянула.
А кто вам сказал, что нет собеседований на архитектуру, системный дизайн и т.д.?
Автор описал первый этап — телефонное интервью. Успешное прохождение этого этапа это далеко не финиш. Интервью на алгоритмы — первый отсеивающий фильтр.
Более того, автор — Junior Android developer. Никто не ожидает от кандидата на позицию Junior глубоких познаний в архитектуре. То есть после успеха на телефонном интервью такие собеседования всё-равно были бы, но в облегченном варианте.
телефон это клиент, а не большая вычислительная машина, а клиент не должен делать сложных решений
О как. А ничего что на телефоне ещё и батарейка есть и то, сколько всё это ресурсов жрёт напрямую влияет на то, как пользователи будут воспринимать ваш продукт?

Да, если вы «мобильный разработчик», который может себе позволить роскошь «забить» на телефоны меньше чем с 10 ядрами и меньше чем 4 гигибайтами памяти — то для вас, может быть, все эти алгоритмы и не важны. Поставил фильтр в Google Play — и всех делов.

Но мобильный разработчик в гугле должен делать вещи, которые будут демонстрировать «плавную стабильную работу» на всяких индусских телефонах с процессорами трехлетней давности и с весьма «обрезанными» другими спецификациями. Тут подходом «я написал алгоритм, а сколько он будет требовать ресурсов для своей работы — мне не интересно» не годится.
UFO just landed and posted this here
Sign up to leave a comment.

Articles