Pull to refresh
190
0
Арвид Блументал @andrei_mankevich

Google Certified Android Developer

Send message
Интервьювер спросил про другие решения, собеседуемый не придумал ничего другого. Возможно даже были подсказки. Потом, ведь надо же какое-то решение написать, да?

Вот вы сейчас зачем-то придумываете то, чего не было :)

Интервьюера устроил мой ответ с base64 для экранизации разделителей, и я его реализовал в google docs. После этого мне предложили реализовать base64. А вот дальше с подсказками интервьюера с горем пополам я написал что-то похожее на base64.

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

Чисто формально я решил исходную задачу. Но ведь цель собеседования не в этом же :) Увеличить размер исходных данных на треть и ничего не сказать про это, не оценить плюсы и минусы такого решения, остановиться на первой попавшейся идее — это все плохо и не для Гугла. Поэтому я и не попал дальше по конвееру собеседований, а не из-за незнания внутренностей base64.

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

Да я только «за». Я еще раз хочу уточнить: я этот пост не потому написал, мол посмотрите, вот я непризнанный гений, а меня Google обидел. Просто Google — не мой уровень.

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

Это же хорошо, что в индустрии много людей, как я («с подобным подходом»). Пока нас много, у вас будет хорошая работа :) Если все были бы лучшими, то кто тогда работал бы в топовых компаниях?

Как же все задолбали выдёргиванием этой фразы из контекста.

Зачем так сразу категорично? Я видел цитату про преждевременную оптимизацию в контексте этой статьи.

Communications of the ACM CACM Volume 17 Issue 12, Dec 1974

Тут как раз про излишнюю оптимизацию и рост сложности.

Computer Programming as an Art by Donald E. Knuth
Another important aspect of program quality is
the efficiency with which the computer's resources are
actually being used. I am sorry to say that many people
nowadays are condemning program efficiency, telling
us that it is in bad taste. The reason for this is that we
are now experiencing a reaction from the time when
efficiency was the only reputable criterion of goodness,
and programmers in the past have tended to be so
preoccupied with efficiency that they have produced
needlessly complicated code; the result of this unnecessary complexity has been that net efficiency has gone
down, due to difficulties of debugging and maintenance.

The real problem is that programmers have spent
far too much time worrying about efficiency in the
wrong places and at the wrong times; premature
optimization is the root of all evil (or at least most of it)
in programming.


We shouldn't be penny wise and pound foolish, nor
should we always think of efficiency in terms of so
many percent gained or lost in total running time or
space. When we buy a car, many of us are almost
oblivious to a difference of $50 or $100 in its price,
while we might make a special trip to a particular
store in order to buy a 50¢ item for only 25¢.

Я могу только сказать, что Base64 было первым, что пришло мне в голову :) Простое готовое решение из коробки, а весь код задачи занимает три строчки. Страшно признаться, но я даже не знал, на сколько именно вырастут исходные данные. Всю жизнь использовал и в голову не приходило посмотреть, что из 3 байт выходит 4, а размер увеличивается на треть.

Я так привык: есть задача — решаем, есть проблема — оптимизируем. «Преждевременная оптимизация — корень всех зол.» (с) Дональд Кнут.

Это плохо и точно не характеризует меня как хорошего разработчика. Поэтому с Гуглом нам оказалось не по пути.

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

А вообще мне интервью понравилось, и интервьюер тоже. Приятный парень, я после интервью был уверен, что я его прошел. У меня из моего опыта общения с сотрудниками гугла пока складывается впечатление, что главный критерий отбора у них — это быть приятным в общении :) После статьи несколько человек из Цюрихского офиса отписались, посоветовали, как готовиться и т. д.
Я в миграционном законодательстве не очень, но насколько я понимаю, нужен только residence permit. Но он в любой стране Евросоюза нужен, если живешь там больше 90 дней, а не туристом. Ну и для Болгарии и Румынии больше каких-то ограничений.

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

Разве что в штатах сложнее, да. Знакомый прошел собеседование, а с квотой пролетел.
На самом деле я это собеседование проходил 2 года назад. Просто никак не мог побороть лень и написать статью :) Сейчас активнее ищу работу и наконец собрался с силами.

А из Google за два года я больше никаких сообщений не получал.
Спасибо за позитивный коммент! :)

Понимаю, может Google компания не самая выгодная, но это лучше, чем ничего (я последние пару лет безработный).

Мне уже написал один человек из Amazon, предложил пойти к нему в команду. Правда, там энтерпрайз в Канаде. Не знаю, может не тратить попытку и подать резюме в Amazon на что-то более релевантное моему опыту мобильного разработчика :)

Да, H1B нужен, конечно. Я в Цюрих метил прежде всего потому, что у меня гражданство Евросоюза и мне не надо никаких дополнительных разрешений-виз и т. д.
Вот именно с этого я и начал (хранить размер массива, длину каждой строки и т. д.). Условие задачи было дополнено, мол строки прям бесконечно длинные. Настолько длинные, что нельзя хранить их размер, слишком он большой.

Насчет того, что хотел интервьюер. Я слышал такую версию, что их главная задача — нащупать предел компетентности кандидата. То есть будут менять условия и углубляться, пока не завалят. А оценивают по тому, как далеко удалось при этом уйти.
Закон Годвина
Круто, я не верил, но это случилось :) Буквально 200 с хвостиком сообщений хватило, чтобы упомянули нацистов.
вы наверняка даже не знаете про литкод

Да не то чтобы я был прям такой дремучий :)

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

Ну и может не совсем насчет комьюнити… Но мне уже два человека отписались из Цюрихского офиса Google, посоветовали как лучше готовиться и т. д. Так что взаимопомощь есть.
Задача была всегда одна — сериализовать массив строк.
Ее родимую. Просто говорят, она должна быть платной.
Я все-таки должен отметить, что само общение было очень вежливым и корректным :) Но общение ограничилось вопросом «зачем», взыванию к совести и благоразумию и просьбой не шарить наработки с плохими людьми.
Скажем так, я немного дальше зашел, чем эти сообщения. Дальше там тоже ничего интересного нет, к сожалению. Цели полностью симулировать работу DroidGuard у меня не было. Плюс у Google есть отличная возможность ответного хода — просто обновить эту нативную библиотеку, и все наработки по реверсу превратятся в тыкву.
Хороший вопрос про софт скиллз. Недооцениваю, факт :) Я все время считал, что главное — это техническая часть и решить все задачи. Но мне уже объяснили, что не совсем так (особо для Google).
Так я вроде и не писал, что я — недооцененный гений, а интервьюер спрашивает какую-то ерунду :) Все было честно и справедливо, а Google — просто не мой уровень. Это нормально, люди разные. Если бы все были одинаково умные, то как бы в Google попадали лучшие?
Проблема в том, что байт-код для проверки у гугла каждый раз новый и разный, а платный контент — уникальный и один на всех. После того, как виртуальная машина его расшифрует и он окажется в незашифрованном в виде в памяти, можно будет снять дамп и дальше его распространять.

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

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

Information

Rating
Does not participate
Location
Рига, Латвия, Латвия
Registered
Activity