Комментарии 302
Знакомо. :(
Но я бы и в спокойной обстановке не выдал Base64, просто потому что понятия не имел как он работает и всю жизнь воспринимал его как данность. А ведь это так, только цветочки перед 5 ягодками настоящего очного собеседования.
Мне процесс собеседования показался очень сложным, и я бесконечно далек от этого уровня. Не знаю, зачем Гуглу нужны все эти гении-олимпиадники, но им виднее.
Не знаю, зачем Гуглу нужны все эти гении-олимпиадники, но им виднее.
Потому что они могут себе позволить выбирать, в отличии от других контор, у них реально «очередь за забором»
===
другое дело что такой высокий уровень вхождения, и отнюдь не блестящее качество программных продуктов… вот что для меня не понятно
другое дело что такой высокий уровень вхождения, и отнюдь не блестящее качество программных продуктов… вот что для меня не понятно
Потому что умение щёлкать олимпиадные задачки имеет мало пересечений с умением делать качественный продукт.
Такой выбор тут скорее действительно «потому что могут». Когда очередь рассосётся, они выкинут задачки про круглый люк в этот самый люк и будут набирать нормально.
Потому что умение щёлкать олимпиадные задачки имеет мало пересечений с умением делать качественный продукт.Не совсем так. Тут на Хабре тоже была статья о том, какие там порядки. Для повышения там надо предоставлять громкие цифры или ремейки, перезапуски и выпуски нового. А за фикс багов и оптимизации вы там так и будете сидеть на низшей ступени.
Оптимизации — вещь полезная, но их надо уметь преподносить.
Ключевая сложность с промо — нужно скрупулёзно собирать метрики и доказывать свою полезность, чтобы твоему менеджеру было что показать комитету, который ни про тебя, ни про твои проекты вообще ничего не знает. Чтобы сделать что-то для промо, нужно в 3 раза больше времени, чем просто это сделать.
При этом процесс всё равно не особо честен. Часто люди получают промо за запуски оперденей, выхлопа от которых нуль без палки, а мега-продуктивные люди, которые пилят ключевую инфраструктуру и получают важные результаты, годами не номинируются.
другое дело что такой высокий уровень вхождения, и отнюдь не блестящее качество программных продуктов… вот что для меня не понятно
Насколько я понимаю, тот же DroidGuard — проект компании Impermium. Google поглотил Impermium, команда перешла в Google, а в Android появилась толковая защита от фрода.
Для этого DroidGuard собирает определенную информацию о девайсе. Какую именно информацию — это решает логика, заложенная в байт-код. Байт-код каждый раз новый возвращается с сервера. По итогу чтобы написать бота, надо реализовать виртуальную машину, которая сможет интерпретировать байт-код DroidGuard.
Манипуляции с имейлами, соцсетями и прочим. Это хорошие деньги. Не зря китайцы не заморачиваютя, а просто собирают фермы из сотен настоящих смартфонов. Это дешевле, чем регулярно обход проверок переписывать
Теперь хочется понять механизм. В Android есть какой-то API, посредством которого приложения «соцсетей и прочего» узнают результат проверки — бот ими пользуется или не бот?
Если так, то что мешает «боту» подменить на своём устройстве эту API?
Если так, то что мешает «боту» подменить на своём устройстве эту API?Тем, что это API не находится на устройстве?
То есть да, вы можете подменить этот API и убедить программу, что она общается с настощим Facebook'ом и настоящим GMail'ом и эти фейковые Facebook и GMail верят ей… дальше что? Греть воздух?
Для этого более простые способы есть…
Устройство грузит (обфусцированный с использованием одноразовой ВМ) код для валидации. Выполняет его.
Что делается с результатом выполнения этого кода?
Сохраняется локально для использования приложениями «соцсетей и прочего»? (Тогда что мешает его подменить локально?)
Отправляется на сервер гугла? (Тогда что мешает вместо него отправить гуглу эталонный результат, полученный на настоящем устройстве?)
Этот результат, очевидно, уникальный и зависит от загружаемой ВМ и байткода. Байткод уникальный для каждой проверки, ВМ меняется раз в несколько недель.
Для обхода защиты надо раз в несколько недель перереализовывать ВМ, понять, какие АПИ и как оно может дергать и эмулировать их все, как на реальном устройстве.
«Байт-код каждый раз новый возвращается с сервера.»
Поэтому и ответы ожидаются каждый раз новые.
Во-вторых, защиту SafetyNet вполне успешно обходят, и это совсем не новость. Есть даже опенсорс реализация всех проприетарных гугловых сервисов microG Project.
Системных вызовов меньше 400 ;) И не удивлюсь, если Google под каждую железку, которая проходила у них сертификацию, уже сгенерила набор виртуалок, которыми пользуется.
Но это всё чисто теоретические измышлизмы, без конкретной цели монетизации этого взлома можно даже не начинать разбираться, слишком много работы :)
А если кто-то дискредитирует канал связи с «корпорацией добра»?
Опасненько… ;)
Весь мир строится на доверии, и надежды на то, что «нас-то всяко пронесёт». Иначе как ездить на машине, ходить по улице и писать на Хабр? :)
А если кто-то дискредитирует канал связи с «корпорацией добра»?человек посередине начнёт майнить.
Опасненько…
хм, провайдеры не хило так могут зарабатывать майнингом на своих пользователях.
или можно такой не хилый отечественный ботнет поднять, что вся западная сеть встанет и нас точно отрубят от международных каналов связи))
Мне было интересно, копал ли топикастер эту тему дальше. С практической точки зрения меня больше интересует применение вирутальных машин внутри приложения для защиты его данных.
Здесь показана интересная фишка — генерация не только нового исполняемого кода, но целиком виртуальной машины для единственной проверки. На такой идее можно построить систему защиты контента в приложении, каждой инсталляции отдавать с сервера свою версию виртуальной машины, которая будет работать только на данном конкретном устройстве и уметь расшифровывать только данный конкретный файл.
И уязвима она совсем с другой стороны: не «дизассемблировать переданную виртуальную машину, разобраться в переданном байткоде», а запустить его на выполнение на реальном телефоне (одном на 100500 эмуляторов) и передать результат от имени эмулятора.
Если же сервер передаёт после покупки зашифрованный контент и виртуальную машину, специально заточенную для расшифровывания этого контента, причём только на этом конкретном устройстве, плюс приложение хранит в железном KeyStore какие-то данные для работы этой виртуалки, то ломать эту конструкцию будет гораздо сложнее.
Или я изобретаю ещё один велосипед? ;)
Данные (строки, например) внутри байт-кода можно считать тем самым контентом. Байт-код несет в себе логику по работе с этими данными, а виртуальная машина исполняет команды.
Что есть на поверхности:
- Android ID
- Application ID
- Order ID — уникальный идентификатор покупки
- марка/модель/ABI
- случайное число, ключ для расшифровывания которого храним в KeyStore
Раньше ещё можно было потрогать MAC, IMEI, но и этого должно хватить, чтобы сделать уникальную виртуалку со своим уникальным набором команд и регистров, на которой достаточно реализовать какой-нибудь кастомный вариант ChaCha20.
Много слоёв будут слишком медленно работать на конечном устройстве. Плюс лишние слои не добавят безопасности, если она вся основана на нескольких переменных, которые лежат почти на поверхности. Мы с вами просто не знаем, где их читать.
Конечно, смотря о каком контенте идет речь и как этот контент используется. В том же DroidGuard даже значения переменных в памяти хранятся в зашифрованном виде. Но это не мешает с помощью дебагера перехватить их значения в тех местах где они используются.
Пример подобного приложения с платным контентом пробегал здесь позавчера, lamptest.ru. В его платной версии показываются дополнительные параметры лампочек. Если не защищать весь контент, который приходит с сервера, то нехорошим людям достаточно просто сделать бесплатный клон этого приложения типа lamptest.pro, который будет круче, и зарабатывать на рекламе и/или подписках.
Системных вызовов меньше 400 ;)
А если еще и параметры возможные подсчитать?
Google поглотил Impermium, команда перешла в GoogleВот Вы и описали трудоустройство в Google не через собеседования
Круто, я не верил, но это случилось :) Буквально 200 с хвостиком сообщений хватило, чтобы упомянули нацистов.
При этом гении-олимпиадники внутри Google не могут родить ничего дельного (я на Google в обиде, имею право так считать).так он таки будет жить, остаётся только «выбирать качественную пищу для поглощения», а иначе это грозит несварением. Тут интереснее задуматься как это можно организовать чтобы заработать
Насколько я понимаю, тот же DroidGuard — проект компании Impermium. Google поглотил Impermium, команда перешла в Google, а в Android появилась толковая защита от фрода.
Умение проходить гугловские интервью говорит лишь об умении проходить гугловские интервью. Самые комфортные свои работы я находил вообще без дурацких интервью с олимпиадными задачками. Самое короткое интервью заняло три минуты с VP
За то что пойдете поговорить никто не осудит вас кроме вас самих
вот в этом и проблема кстати если углубляться, сложно для самого себя оказаться лузером
потому что например работаешь на разных работах, получаешь 100500 денег и весь такой уважаемый профи, а потом идешь на собеседование на +20% от твоей ЗП, а тебя начинают валить голой академической теорией как джуна… и в итоге выходишь оттуда… как будто у тебя и нет опыта за плечами и кучи успешных проектов… ты незнаешь основ… и собеседующие смотрят на тебя снисходительно… ну чё ты такой лох то… а потом обсуждают что «ходят черти кто на собеседования, найти нельзя нормальных людей»
Я отлично знаю что все конторы разные, и что бывают неадекватные собеседования как я описал выше… но себя сложно обмануть, ведь реально я не знаю наизусть определения из учебника… и это угнетает морально
==
у меня синдром самозванца, да
не особо спасает даже понимание что я был на двух собеседованиях всего чтобы найти работу не имея коммерческого опыта в (обычном) программинге и вообще не просев даже по зарплате по сравнению с прошлой работой (одинесником, где у меня около 8 лет опыта)… т.е. не-безуспешно тыкался и разочаровался
Одно дело боятся, другое боятся и делать. я просто описал этот страх и что он реален и более серьёзен чем кажется. Это не помешало мне и иметь оффлайновый бизнес (7 лет и побегать потом с ним по прокуратуре отбиваясь от уголовки когда он развалился) и поработать в куче самых разных отраслей, от ремонта электрооборудования в вагонах до банковского процессинга (в разных отделах)… сейчас вот программинг, от написания успешного сервиса в одно лицо до просто бекенд-программист (вынужденный дауншифтинг в профессии но с повышением зп, для повышения квалификации)
Вы скорее всего экстраверт если не понимаете что это нельзя перебороть усилием мысли… да можно натренироваться, я когда работал с 1С получил навык общения с начальством что меня ни раз выручало… но всёравно подсознательно меня это очень всё угнетает
А надо сместить фокус недовольства с «я такой несуразный» на «они такие гондоны» :)
М.б. поможет
- Пожалуйста, не надо путать интроверсию и социальную тревогу. Одно не подразумевает другого (хотя часто встречаются вместе).
- Практика как раз хорошо помогает от тревожности. Завалите вы одно собеседование, второе — и в какой-то момент придет осознание того, что ничего катастрофичного в этом нет. Зато каждое хорошее техническое собеседование — это отличный срез своих знаний: чем хорошо владеешь, а где плаваешь.
- Каждое успешно пройденное собеседование даёт мощный плюс к самооценке. Прекрасное чувство.
- Не забывайте — на другом конце стола зачастую сидит такой же человека, как и вы. И, возможно, он волнуется больше вашего.
Удачи!
Я бы сначала написал перевод в произвольную систему счисления, а дальше оптимизировал под base64: выкинуть деления и вычисления остатка, заменив соответственно битовыми сдвигами и наложением битовой маски, ну и работать сразу с триплетами, что делает ненужными умножения и сложения.
Математически — это то же самое, а практически — отличный способ развлечься на интервью и получить отказ.
Всё-таки base64 — это перевод 3 байтов в 4 c помощью битовых манипуляций, а дальше обработка массива в цикле, а не превращение данных в длинное целое и попытка потом реализовать эффективно операции деления.
И кстати, ваша формулировка «c помощью битовых манипуляций» (и картинка с битами в голове) мешает вам же искать другие решения, почему не использовать таблицу? Надо всего то 64Mb памяти, это может внезапно оказаться быстрее плохой реализации с битами.
Потому что: для преобразования одного блока из 3 байт нужна будет только одна операция хоть и дорогая по тактам (примерно mov eax, [tbl + esi]), а для «битовых манипуляций» операций будет на порядок больше, пусть и дешевых.
на чем было под рукой, размер исходных данных только кратный трем, в примере 30Mb
Random source data: []byte{0x52, 0xfd, 0xfc, 0x7, 0x21, 0x82, 0x65, 0x4f, 0x16, 0x3f}...
Run bitwise 0.053900 s
Base64: Uv38ByGCZU8WP18PmmIdcpVmx00QA3xNe7sEB9Hi...
Run tabular 0.128237 s
Base64: Uv38ByGCZU8WP18PmmIdcpVmx00QA3xNe7sEB9Hi...
Text source data: :d9d fxqpe 0bq9}{mbx3kdadbqf8 ...
Run bitwise 0.042929 s
Base64: OmQ5ZCBmeHFwZSAwYnE5fXttYngza2RhZGJxZjgg...
Run tabular 0.024196 s
Base64: OmQ5ZCBmeHFwZSAwYnE5fXttYngza2RhZGJxZjgg...
Результат не стабильный, но для текста табличный метод всегда быстрее.
$ ./a
Prepare table
Random source data: []byte{0x52, 0xfd, 0xfc, 0x7, 0x21, 0x82, 0x65, 0x4f, 0x16, 0x3f}...
Run bitwise 0.040010 s
Base64: Uv38ByGCZU8WP18PmmIdcpVmx00QA3xNe7sEB9Hi...
Run tabular 0.118122 s
Base64: Uv38ByGCZU8WP18PmmIdcpVmx00QA3xNe7sEB9Hi...
Text source data: :d9d fxqpe 0bq9}{mbx3kdadbqf8 ...
Run bitwise 0.033740 s
Base64: OmQ5ZCBmeHFwZSAwYnE5fXttYngza2RhZGJxZjgg...
Run tabular 0.037435 s
Base64: OmQ5ZCBmeHFwZSAwYnE5fXttYngza2RhZGJxZjgg...
А если добавить в алфавит еще и большие буквы, то сразу становится стабильно не пыщпыщ:
Text source data: Ds1OwN"G}nUKsDeVtsZjbd"mqv:YlA...
Run bitwise 0.034508 s
Base64: RHMxT3dOIkd9blVLc0RlVnRzWmpiZCJtcXY6WWxB...
Run tabular 0.052095 s
Base64: RHMxT3dOIkd9blVLc0RlVnRzWmpiZCJtcXY6WWxB...
Да, в общем случае для данных с мощьностью алфавита 256 с нормальным распределением бинарный способ будет быстрее.
Используя валявшийся под руками 32гиговый текстовый файл (proto2 дамп) табличный побеждает стабильно, неважно го или плюсы (на плюсах разве что вдвое быстрее чем на го).
==== GO:
Run bitwise 0.047352 s
Run tabular 0.022693 s
=== C++O0:
Run bitwise 0.0737085s
Run tabular 0.0408408s
=== C++O3:
Run bitwise 0.0233191s
Run tabular 0.0193432s
интересно; дома попробую потыкать палочкой на личных ноутах, у них процы несколько постарше, будет интересно посмотреть где точка невозврата
PoC pastebin.com/MwHy4cF1Это не PoC, а PoLoK (Proof of Lack of Knowledge). Вы бы ещё Python взяли и начали там что-то мерять.
на чем было под рукой
Да, разумеется, если взять язык, в котором битовые операции медленные, а обращение к памяти — быстрое, то можно ещё и не таких вещей наизобретать. Но мы вроде говорили не об этом?
Вот ваша же программа, переведённая на язык, где битовые операции не являются искуственно замедленными. Ну и от попыток померить субсекундные времена тоже я отказался.
Результат у меня такой:
$ g++ test.cc -O2 -o test $ ./test Prepare table Text source data:f axhtg6xr1grgiwotdn0kuvufyo36 Run bitwise 3.2983s Base64: ZiBheGh0ZzZ4cjFncmdpd290ZG4wa3V2dWZ5bzM2 Run tabular 7.24175s Base64: ZiBheGh0ZzZ4cjFncmdpd290ZG4wa3V2dWZ5bzM2 $ grep model /proc/cpuinfo | sort -u model : 63 model name : Intel(R) Xeon(R) CPU E5-2690 v3 @ 2.60GHz
Никаким ускорением даже и не пахнет. Даже на текстовых данных. Причём я даже глянул на godbolt — нет, никакой векторизации нету, всё честно: сдвиги и битовые манипуляции.
2. Пока что примеры были на компилируемых языках, возьмите интерпретируемые, вы будете уверены что там биты будут быстрее?
3. Запустил ваш же пример на процессоре с чуть меньшей частотой
$ ./test
Prepare table
Text source data:f axhtg6xr1grgiwotdn0kuvufyo36
Run bitwise
4.12588s
Base64: ZiBheGh0ZzZ4cjFncmdpd290ZG4wa3V2dWZ5bzM2
Run tabular
4.69363s
Base64: ZiBheGh0ZzZ4cjFncmdpd290ZG4wa3V2dWZ5bzM2
$ grep model /proc/cpuinfo | sort -u
model : 79
model name : Intel(R) Xeon(R) CPU E5-2650 v4 @ 2.20GHz
Разница уже не 120% а всего 14%, подозреваю что с той же памятью но меньшей частотой CPU результат будет ещё интереснее. Потому что с битами мы упираемся в частоту, а с таблицей в память.
4. Посмотрел godbolt, убедился что при O2
*((uint32_t*)&result[j]) = *((uint32_t*)&tbl[block]);
лучше
std::memcpy(&result[j], &tbl[block], sizeof(uint32_t));
не все ещё забыто, успокоился.
Если говорить про компилируемые языки, то скорось битовых операций и обращений к памяти едвали можно считать различными, конечно будут нюансы зависящие от реализации компилатора но в целом разницы нет.
Почему это? Обращение к памяти в десятки-сотни раз медленнее битовых операций.
учитывая, что нельзя просто прочитать как дворд и использовать в лоб (точнее можно — в табличном методе, еще немного ускорить можно за счет этого).
Мне это напоминает историю с каким-то чуваком, который когда-то давно в LKML появился и начал объяснять, что ядро плохо написано и вообще его разработчики идиоты. Его попросили показать «мастер-класс» — и он «ускорил» (примерно похожим образом) вычисление TCP/IP чексуммы. Раза в четыре, если не ошибаюсь.
После чего ему ответил кто-то из гуру и «раскатал» его. Ибо, как и следовало ожидать, его код был медленнее на всех сетевых бенчмарках и на всех доступных системах. Потому что на практике вычисление TCP чексуммы перемежается с другим кодом — а подобные трюки не дают тому коду работать «убивая» L1 кеш.
Таблички с предвычисленными значениями были актуальны в 70е-80е годы, когда память была быстрой, а процессоры медленными… Но в те времена 64MiB стоили таких денег, что никому и в голову бы не пришло их на base64 отдать.
Да, разумеется, если взять язык, в котором битовые операции медленные, а обращение к памяти — быстрое, то можно ещё и не таких вещей наизобретать.
без разницы на каком языке писать такой тест, пропорции будут примерно одинаковые, а абсолютные значения будут отличаться в зависимости от компилятора.
Имелось ввиду что скорость битовых операции в разных компилируемых языках мало отличимы по скорости.Ну если «разика так примерно в три» — это «мало отличимы», то я уж не знаю кто и что вам может помочь.
Тут фишка в том, что в спецификации Go написано:
There is no upper limit on the shift count. Shifts behave as if the left operand is shifted n times by 1 for a shift count of n.
А в спецификации C++:
The behavior is undefined if the right operand is negative, or greater than or equal to the length in bits of the promoted left operand.
Что это обозначает? Что в Go вы вынуждены кодировать shift тремя-четырьмя операциями CPU, а в C++ — достаточно одной.
Тут бы, конечно, вмешаться хорошему, качественно оптимизируеющему, компилятору — но таковой есть только в gccgo, а им любители Go пользуются редко.
Потому и оказывается, что Go по скорости доступа в память — близок к железу, а вот по скорости вычислений — сильно от него отстаёт.
И всё бы ничего, но вот только готовность выделить пресловутые 64GiB — указывает на то, что эта задача для вас ну просто очень-очень важно… так с какого перепугу вы используете язык, который заметно отстаёт от оптимума?
без разницы на каком языке писать такой тест, пропорции будут примерно одинаковые, а абсолютные значения будут отличаться в зависимости от компилятора.Тогда почему в вашей программе таблица выигрывает иногда, а моей — всегда проигрывает, хотя иногда с разгромным счётом, а иногда — немного? Но проигрывает всегда…
Разница уже не 120% а всего 14%, подозреваю что с той же памятью но меньшей частотой CPU результат будет ещё интереснее. Потому что с битами мы упираемся в частоту, а с таблицей в память.Нет — и это мы уже выясняли. Вы же сами чётко чуть выше пишите: нужные куски таблицы попадают в кеш и этот способ уже работает быстрее битовых операций. Если бы ваш код упёрся в память — то там уже ни о каком выигрыше и речи бы не шло.
А скорость кеша процессора, обычно, это какая-то доля от скорости процессора, так что этот козырь вы уже отыграли.
Чтобы табличный метод выиграл вам нужен какой-то аномальный процессор с огромным кешом и при этом очень «дорогими» сдвигами… Не очень понятно что бы это такое могло бы быть…
Так вам над этим 64-метровым числом надо повторять операцию деления на 64 до тех пор, пока в частном не получится 0, т.е. 87 миллионов раз. Операция деления таких длинных чисел занимает большое время, вам нужно вручную пройтись по всем разрядам (пусть даже вы будете обрабатывать по 64 бита за раз), аккуратно делая переносы остатка с разряда на следующий разряд. Навскидку, сложность предложенного вами решения получается O(n^3). Битовый же энкодер base64 даёт O(n), причем без тяжеловесной для CPU операции деления.
Не туда ответил
Проблема в том, что вы этим решением убъёте нафиг кеш, как WraithOW
написал — и при этом ещё и получите ужасную скорость (64MB ни на одном современном процессоре ни в один кеш не влезут, а за время обращения в память процессор может выполнить порядка тысячи инструкций).
Однако если его чуть-чуть модифицировать и использовать три таблички по паре килобайт — то есть уже шанс вписаться в L1 кеш, однако, во-первых, не факт, что пользователям вашей процедуры так уж понравится, что вы существуенную долю кеша заняли, а во вторых — тут уже всё равно будут нужны дополнительные манипуляции и не факт, что будет выигрыш.
Тут еще не факт, что в итоге больше потеряли (в плане возможностей) от такого итога собеседования именно Вы, а не Google. В истории довольно много примеров, когда провалы на собеседованиях в одной компании становились причиной роста числа или силы конкурентов такой компании.
Хотя точно могу сказать, что мне подготовка пошла все-таки в плюс. Теперь каждый раз когда пишу код, автоматом думаю о сложности O(n). Раньше такие вопросы приходили в голову только если что-то медленно работало и это дело надо оптимизировать.
Своеобразный случай, потому как продукт готовили на продажу уже как небольшой по доходу и работающий бизнес. Сначала проект пытались продать AS IS, с проблемами не только в коде, но и в документации API, серьезными проблемами в момент пиковых нагрузок от клиентов и прочими прелестями. Продажа не состоялась, цену продукта примерно ожидали в $180..200k (копейки).
После окончательной потери надежды продать или привлечь доп средства на развитие, владелец этого бизнеса чуть позже случайно познакомился с командой, которая занималась консультированием и private TPA (частный техаудит проектов), ребята предложили помочь оценить самые дорогие проблемы в проекте и потратить полгода на его доведение до стабильно работающего состояния за 20% от конечной стоимости повторной продажи. Команда у них также была своя (4-5 человек примерно) + несколько временно привлекаемых консультантов по AWS и лоеры для аудита схем монетизации. За несколько месяцев было все донастроено по инфраструктуре, далее переписаны криво реализованные сервисы, протестировали уже дополненные тесты, дописали доки.
Была возможность слегка поучаствовать в этом и наблюдать со стороны. Сравнивая визуально репу старого проекта и репы нового, кода стало раз в 10 меньше, сервисов (API endpoints) тоже поубавилось, тестов различных появилось много (нагрузочные), внедрена автодокументация на javaDoc, поправлена старая. Короче технически проект был причесан и вылизан очень грамотно.
После всего, через год в сумме (из-за ожидания каких-то конкретных эвентов, типа бизнесс-выставок и встреч) у проекта появилось несколько покупателей, им был передан отчет по аудиту и проделанной работе, также переделанные основные доки по проекту и в конечном итоге после аукциона его продали за $1.8m (сильно больше ожидаемого). Проект по тематике довольно нишевый, связанный с оптимизацией логистики, страхования, хранения и перевозки грузов. Далее через год этот проект уже выкупила одна из продуктовых сетей (кажется Kroger) за $4m. Да, за прошедший год у проекта появилась другая команда.
По сути на старте проекту сильно повезло как в плане того, что конкурентов особо не появилось за все это время изменений, так и в плане случайных совпадений и знакомств, которые вытащили бизнес из глубокой дыры (финансовой и развития).
Во всех остальных, довольно многих случаях, попытки просто улучшить код, рефакторить все с самого начала, затягивая развитие самих бизнес-процессов — всегда приводили к одному и тому же: начинающие проекты со временем становились просто никому не нужны, так как быстро появлялись конкуренты и просто забирали целевые ниши. Что с такси, что с хостелами, что с сервисами самокатов или чего-то более серьезного. Попробуй в таком окружении встань на feature freeze на месяцок, ага.
Так что первые версии продуктов, вернее где-то первый год существования бизнеса в рынке — сервисы/продукты, увы, всегда будут жрущими ресурсы и тормозящими, но выполняющими те бизнес-процессы, которые приносят доход и действительно нужны. И только они сначала улучшаются, после идут уже всякие улучшения в UI use-cases, разбор и оценка качества пользования сервисом, размеры бинарников, network traffic shaping и прочее. Поэтому либо так, либо на рынке будет существенно меньше выбора. Если он будет вообще.
Знание Base64 сразу выделяет людей, которые интересуются simd :) ибо это по сути одна из тренажерных задачек.
64 намекает что мы используем 64 символа, 6 бит. НОК(6, 8) = 24. То есть каждые 3 байта можно нарубить на ровные 4 символа.
Это как перевести в 64-ричную систему исчисления указанное число.
itoa же можете реализовать? ну вот ровно так же, только не по основанию 10, а по основанию 64…
Компания выглядит адекватной, и я сомневаюсь, что девушка из-за незнания принципа работы транзисторов не попала на работу, однако, думаю, она испытала немалый стресс. (Я бы испугался, если бы почувствовал, что человек специально ищет тему, на которой можно меня завалить)
Поэтому идет селекция по определенному типажу психики.
У меня была пара случаев в жизни, когда предоставлялся шанс пройти стажировку в Microsoft. Тогда о гугле не знали даже. Когда я интересовался порядком приему на работу у меня все желание проходило сразу. Куча каких-то условностей, что-то там ты должен, что-то не должен. Че-то там раз в год я обязан менять должность, если я не росту я автоматом увольняюсь. Бла, бла, бла… политика и т.п.
Оба раза я отказался. После первого отказа даже какие-то сожаления были. Особенно когда друзья узнали и говорили, что я эм… не умный. Но второй раз (это было по окончанию 3го курса) я уже осмысленно это делал. У меня были интересные проекты и мне откровенно не хотелось заниматься тем, что скажет мне «дядя».
Я почитал статью, было потрачено много времени. Судя по тексту. Причем, с пониманием того, что вы делаете. То, что вы не ответили на простой вопрос, это ооооочень распространенная ситуация. И она зачастую игнорируется грамотным hr. Невозможно все в голове держать, с чем ты не работаешь постоянно. Скорее всего, вы столкнулись с корпоративной машиной. Скорее всего, вы рассматривались на уровне обычного кандидата. Такого же, как если закинуть резюме иными путями. Отсюда шаблонный подход к общению с вами.
Если есть суровое желание работать в гугле, просто продолжайте туда стучаться. Я уверен, что это вполне реальная цель при вашем подходе.
Но, ИМХО, это не стоит того. Самореализация на собственном проекте куда как интересней.
Когда-то Макса Хоувел (разработчика Homebrew) не взяли в Google. Он по этому поводу такой твит выдал:
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.
Я уже немного наелся самореализации, хотелось обратно в уютный мир, где каждый месяц за работу платят деньги :) Увы, пока не сложилось.
Все потому, что интегрировать в себя готовый продукт легко. Он понятен, документирован, есть четкие сроки, оценка трудозатрат и т.п.
Т.е. это скорее селектор и концентратор технологий, а не драйвер. Возможно я в этом ошибаюсь, но по той информации, которую я имею, складывается такое впечатление.
да и про легкость интеграции — это только кажется, что все это легко. посмотрите, к примеру, на майкрософт — сколько продуктов куплено и погублено (нокия, скайп, ...). казалось бы — что сложного?
Если есть желание быть кодером, когда за тебя все решено… ну что ж, это тоже выбор, достойный уважения.
Что касается — только кажется и Микрософт. Загубить можно все. Не принимать в расчет очевидность параметров готового решения оправдывая это некомпетентностью процесса интеграции, не самый верный путь.
Инфраструктуру вместо работы...? не понимаю… Возможно я какой-то неправильный, но я не разделаю развитие одного от другого. Это обоюдно необходимые вещи.
Если у вас сотни продуктов, писать тулинг под каждый из них выходит слишком накладно. Мы ведь здесь говорим конкретно о Гугле — вот конкретно в Гугле инфраструктура общая для всех. Запустить примитивный сервис во множестве регионов на инфраструктуре Гугла у вас займет меньше часа. Ваша задача — делать сервис, а не решать проблемы деплоймента во множество датацентров, чекина кода в репозиторий только после прохождения каких-то тестов и получения апрувалов от ревьюеров, лоудбалансинга и прочих вещей. Вы все это получите бесплатно. Делать это все на уровне каждого продукта — просто неэффективно. Поэтому инфраструктура и продукты разделены. Но опять же — хотите работать над инфраструктурой — пожалуйста. Хотите работать над продуктами — милости просим. Хочется поделать одно, потом другое — можно менять команды, ну или тратить 20% своего времени на любые другие задачи помимо вашей основной работы (это сейчас реже практикуется, но все еще существует).
Если есть желание быть кодером… ну что ж, это тоже выбор.
Почему вы считаете работу над продуктом «желанием быть кодером» — тоже не очень ясно. Работа над продуктом включает множество составляющих. И сбор требований, и дизайн, и согласование разных моментов с партнерами (upstream callers, downstream service providers), и планирование, и релиз — далеко не только кодинг.
единый тулинг для мониторинга, пуша в прод и прочее.
Нет, тулинга в всегда как минимум два — один deprecated, а другой красивый, но пока толком не работает, причём вам нужно срочно на него переехать.
Ну и для пуша в прод вариантов гораздо больше, чем 2.
Побуду кэпом: нужно было при подготовке к собеседованию учесть специфику конкретного отдела, в данном случае DroidGuard. Видимо они там занимаются более низкоуровневой разработкой, поэтому и такой вопрос.
habr.com/ru/company/google/blog/378507/#habracut
Как мне кажется, довольно специфический навык.
Но учитывая, что резюме пришло через реверс, вполне вероятно тоже бы задал что-нибудь более низкоуровневое… Правда, не знаю как бы прошло. Есть интерес сыграть в ролевую игру тренировочного интервью? :D
Ставка: по приколу, так что нервов и напряга должно быть меньше
Это хорошая задачка на «поговорить». В пятнашках 20 триллионов вариантов, так что имея кластер её можно решить полностью.
А можно два поиска в ширину «навстречу друг другу» отправить. А можно тот, который «с конца» заранее рассчитать.
Там есть о чём поговорить! Именно этим задача и интересна: готового единственного «правильного» ответа нету и можно смотреть в какие области более склонен идти кандидат.
Никто не ожидал от вас, что вы знаете все теории, воздвигнутые вокруг этой задачи — как раз если бы вы их знали пришлось бы быстренько переключиться на что-то другое!
Ребята, вы гении, если вы туда смогли попасть! Серьезно. Я не представляю, как можно пройти через эту полосу препятствий.
datacompboy что скажете?(я видел ваш пост про интервью, но все же)
Ну и про саму статью. Очень интересно услышать ваш комментарий.
Мне понравился ваш подход — хотел пройти собеседование, готовился, но не вышло. Так редко пишут, чаще бывает — «да не очень-то и хотелось, и вообще после отказа я понял, какие они дураки там».
А когда через год вам перезвонят и снова пригласят пройти собеседования — вы согласитесь?
Я пока пару лет делал игры на Unity, так в Android успела революция произойти: вместо Java пришел Kotlin, RxJava стал золотым стандартом, Android SDK распался на Android Jetpack Components… Ничего, все можно довольно быстро освоить. Даже сертификат получил красивый от Google.
Насчет перезвонят я так скажу. Собеседование я проходил чуть больше года назад :) Не перезвонили. Но я им сам недавно повторно написал. Если посмотреть правде в глаза, они мне нужнее, чем я им: Google в резюме — он такой один, а из таких как я у них очередь стоит.
Они написали человеку сами, значит нашли его по шагам той истории, когда он ковырял их продукт, и поковырял неплохо так. Т.е. у человека есть опыт решения задач, где-то сложных где-то не очень. И тут вопрос про реализацию base64… Если заглядывать под капот каждой функции которую используешь — то так и будешь под этим капотом сидеть, а не задачи бизнеса решать!
У меня опыт работы не большой, 5 лет примерно. Но когда мне на собеседовании на веб-разработчика(!) предложили на бумажке реализовать алгоритм поиска простых чисел и бинарную сортировку — я от туда убежал (после института, я эти алгоритмы с закрытыми глазами мог написать, НО за 5 лет коммерческой веб-разработки ни в одной задаче не было даже намеков на простые числа и на реализацию бинарной сортировки — и все забылось).
Если вас такие вопросы прям бесят, значит Google для вас не подходит, а вы не подходите для них.
на бумажке реализовать алгоритм поиска простых чисел и бинарную сортировку
И правильно сделал. Все это жадность, получить мидла за денежку джуна, или сеньора за денежку мидла (я не про ваши конкретные вопросы).
У меня как-то, лет 5 назад было собеседование на позицию мидла .net в наших топ 5 интеграторах, я туда пошел уже просто для опыта собеседований (год шлялся, еле нашел). Стандартный набор — интерфейс vs абстрактный класс, boxing / unboxing, напиши пузырьковую сортировку, async/await, using, бла-бла-бла и прочий шлак из собеседований, думаю, чета они про шаблоны проектирования забыли, ан нет, напишите реализацию синглтона. Ок, пишу. И тут прорвало — напишите на бумажке еще 5 реализаций синглтона, назовите и опишите все паттерны из книги Desing patterns, бинарные деревья, какие-то реализации низкоуровневых блокировок, алгоритмы аппроксимации пиков, и все дальше и глубже.
Я не выдерживаю и спрашиваю — что, неужели они у них мидлы такие, все это знают?
В ответ, гордо — У нас все мидлы уровня сеньеров!
Я, офигевая — Что? А получают они как мидлы?
Не задумываясь, и еще гордее — Да!
Ясно-понятно, до свиданья.
Я как раз таки хорошо умею делать велосипеды и быстро разбираюсь в новых либах.
Но как то решил попробовать с С++ пересесть на С#. С ним я и до этого работал, но в основном с .Net core.
Тут предложили на одну фирму поработать. В итоге им все эти фундаментальные знания, знания алгоритмов и прочее — нафиг не нужно. Им нужно на зубок знать весь .Net винды.
ASP .Net, Entity Framework, MVVM, MFP, MVC и т.д.
А когда я говорил, что писал асинхронные сервера на .net core на сокетах, писал врапперы во круг собственных сишных либ — они смотрели как на иродиевого.
Ни о каких хэштаблицах, деревьев, сортировок, обход графа, алгоритмов поиска, методов оптимизации и прочего речи и близко не было.
Вы бы друг друга просто не поняли. Причём в обе стороны: вы бы пытались строить велосипеды там, где есть готовые функции, а ваши коллеги городили бы страшные многотонные конструкции, тем, где можно обойтись велосипедиком на 100 строк.
Эти два рода деятельности сегодня настолько разошлись, что вот то, что им было нужно — получило отдельное название: application engineer. И да, такие Гуглу тоже нужны — но это отдельная вакансия!
предложили на бумажке реализовать алгоритм поиска простых чисел и бинарную сортировку
Такие вопросы задаются чтобы понять способны ли вы выражать свои мысли внятно и понятно. Есть ли у вас представление о «велосипедах» и можете ли вы их «изобретать». Я тоже в свои проекты набираю людей способных отвечать на такие вопросы. И они гораздо важнее мартышкиных знаний о фрейворках и конкретных методах библиотек.
Задача на интервью — понять способен ли человек мыслить, или он «конечный автомат» ;).
Так кто вам больше нужен: лесорубы, которые делают конечный продукт, или кузнецы, шахтёры, металлурги, геологи? Если мне надо посмотреть на реализацию Base64, то я быстро найду Base64.java в том же Android. Но не каждый Senior, а тем более Middle знает, что бывают другие, более эффективные кодировки типа Base85, или более простые типа Hex. А уж вопрос какую где лучше применять сможет поставить в тупик даже интервьюера ;)
Чтобы проверить, что человек умеет мыслить, то ему надо дать задание по конкретной теме, например, тестировщикам я предлагал придумать 10 способов разбить стакан, стоящий на соседнем столе, а все без исключения разработчики делали тестовое задание очень близкое к тому, чем они потом будут заниматься. Сразу было видно, знает ли человек нужный нам язык или фреймворк.
А если вы библиотек не знаете и как рашать задачу без них — тоже, тогда что же вы умеете? Произносить умные слова?
Вот я и пишу, что прежде всего при поступлении задачи нужно изучить имеющиеся решения и оценить их применимость для нашего случая. И только если они по каким-то причинам неприменимы разрабатывать собственное решение. Это и есть «подход к решению»Нет — это не «подход к решению». Это — «способ переложить решение на кого-то ещё».
Такие знания статичны. Если всегда механически применять полученные когда-то знания, то в результате получится: «знаю один фреймворк (библиотеку) и сую его (ее) во все проекты».Почему же статичны? Библиотеки меняются, подходы меняются, «наука на месте не стоит». Application Engineer'ы — они тоже разных уровней бывают.
Но если для них важно обладать знанием о как библиотеках, то Software Engineer — это тот, кто, в первую очередь, может задачу решить. А не найти где-нибудь готовое решение. И потому именно этот навык и проверяется.
P.S. И да, очень часто их путают. И ставят Software Engineer'ов на задачу «натягивания скина на Drupal» или, наоборот, Application Engineer'а на задачу «придумавания нового алгоритма для обработки данных на графе». Последнее, впрочем, реже: так как зарплата у Software Engineer'а обычно выше, то чаще Application Engineer'ы пытаются устроиться на эту позицию, а не наоборот.
Интересный пример, но не релевантный. Речь идет о том, а умеете ли вы пользоваться топором, или только бензопилой? И более того, а способны ли вы заправить бензопилу когда в ней кончится бензин? Знаете ли вы что кроме бензина, туда еще и масло надо заливать? :).
Это если мне дровосеки нужны.
Ну и я не говорю еще о том, что сейчас часто встречаются люди не знающие что «руда» из вашего примера в принципе существует...
Что же касаемо программистов, сейчас развелось человеков, которые думают, что если они выучили пару языков, научились быстро гуглить готовые решения на «стэке» и заучили немного умных слов, то теперь они программисты. Вот таких мне и надо отсеять на интервью. Мне в проекте нужны люди способные решить поставленную задачу оптимальным способом придумав решение именно моей задачи. А не нагуглив его.
Давать на собеседовании реальные задачи из проектов нельзя, по многим причинам. Но главное это их нетривиальность — просто не успеешь обьяснить задачу :). Потому и придумыаются поостые шаблонные «всеми забытые» базовые задачи, при этом они темне менее показывают способность мыслить или помнить — если учился хорошо ;) в универе...
А человеки с умными словами обычно отсеиваются ещё на стадии чтения этих слов в их резюме. Типа «сетевые протоколы: HTTP, JSON, XML» ;)
И ещё очень полезно посмотреть, на какие паблики они подписаны.
Всё это множество люков-автобусов и прочих пузырьковых сортировок происходят в основном из-за неспособности интервьюеров придумать что-то своё. Или хотя бы обратить внимание, как человек краснеет, двигает ногами, смотрит и говорит. То, что он не сумел решить какую-то теоретическую задачку не говорит о том, что он будет плохо работать. Тут уже было массу статей про плохие интервью. Меня самого один раз не взяли в довольно крупную контору из-за того, что зевнул пару раз, потому что было реально скучно проходить обследование у десятка человек, никак не связанных с моей будущей должностью.
Ну и на крайний случай, если промахнулись, есть испытательный срок, благо в этой стране он по закону достаточно длинный. Честно, ни разу не применялся, обычно люди уходили сами в более тёплые места.
PS. могу купить, разобрать и собрать бензопилу
PSS. могу точить цепи от бензопил ;)
а способны ли вы заправить бензопилу когда в ней кончится бензин? Знаете ли вы что кроме бензина, туда еще и масло надо заливать?Нет, никогда не держал в руках бензопилу, никогда масло ей не менял, бензин не заливал.
Но я понимаю, зачем она нужна, как работает, где она применима, а где нет. И если вдруг, мне нужно будет ей вдруг(!) воспользоваться, я достану инструкцию, распилю несколько досок (возможно и кривовато), но выполню свою работу.
Да, я не задрот бензопилы, и опоры будут кривоваты, но зато работа будет выполнена. Если построенный дом окажется востребованным клиентами, то можно будет кривые доски и перезапилить ровнее. А если дом окажется ненужным(нет клиентов), то и не жалко было потраченного времени. MVP во всей красе. Вам шашечки(мастер бензопил), или ехать(человек, умеющий быстро осваиваться)?
Конечно же, если бы я работал на пилораме, то мне просто необходимо было бы владеть бензопилой. Но чаще всего, кроме бензопилы, нужно знать про 100500 инструментов, какие они бывают, и какой лучше где применить. Архитекторы зданий например, не все держали в руках инструменты, а кто держал — наверняка не все инструменты на свете. Но это не мешает им строить дома, и делать свою часть работы.
решить поставленную задачу придумав решение именно моей задачи. А не нагуглив его.Стоп, вы платите людям, чтобы они ваши желания исполняли так, как вы желаете? Тогда это скорее ваши рабы. Или вы хотите, чтобы они делали вместе с вами работу, и зарабатывали для вас деньги? Если второе, то какая разница — нагуглили они, или взяли полуготовые библиотеки из гитхаба?
показывают способность помнить — если учился хорошоЗнаю много противоположных примеров, кто учился плохо, ничего с универа не помнит, но понимает, что нужно заказчику, выдаёт готовые продукты в короткие сроки, и именно так как просил заказчик. Поэтому у меня обратное мнение — тот, кто помнит отлично универ — либо гений, либо у него синдром отличника.
И если вдруг, мне нужно будет ей вдруг(!) воспользоваться, я достану инструкцию, распилю несколько досок (возможно и кривовато), но выполню свою работу.А как вы поймёте, что ей нужно воспользоваться? Вам начальник скажет? Так в Гугле нет начальников, дающих вам техзадание описывающих в деалях какими подходами пользоваться…
Знаю много противоположных примеров, кто учился плохо, ничего с универа не помнит, но понимает, что нужно заказчику, выдаёт готовые продукты в короткие сроки, и именно так как просил заказчик.Но у Гугла ведь нет заказчика…
Если второе, то какая разница — нагуглили они, или взяли полуготовые библиотеки из гитхаба?
Я так понял человек пишет о том что нагуглить или взять полуготовое не выйдет так как его просто не существует.
Стоп, вы платите людям, чтобы они ваши желания исполняли так, как вы желаете? Тогда это скорее ваши рабы.
Да, я хочу чтобы они делали для меня работу наилучшим возможным образом и с первого раза. Потому что второго шанса «продать» не будет.
Есть такие работы, где во первых ничего нет на гуглах/гитхабах, во вторых вариант «и опоры будут кривоваты, но зато работа будет выполнена» вообще не допустим. Потому что от этого не какие-то там клиенты «не купят», а зависит чья нибудь жизнь.
ПС. Вас бы я на работу не взял :). Принцип «Good enough» у нас категорически не приветствуется.
— Запускаем в комнату ребёнка, отбираем мобилку, запрещаем разбивать стакан.
— Достаём из кармана гранату. Бросаем её в стакан.
— Играем стаканом в футбол.
— Накрываем стол до конца. Играем свадьбу.
— Приглашаем жену и любовницу. Привязываем к поясам гантельки на верёвочках. Устраиваем весёлый свадебный конкурс – кто первым попадёт гантельной в стакан.
— Наливаем в стакан метиловой незамерзайки. Не разбился? Ну вот мы и прошли один из тестов, который стакан выдержал.
— Находим подходящий подшипник. Натягиваем в тугую на стакан. Кидаем их в жидкий азот.
— Берём перфоратор и высверливаем дырками имя любимой девушки.
— А теперь то же самое – только лазером. И помощнее.
— Загоняем в вибратор. Прогоняем по всем частотам.
— Используем в качестве изолятора. Хватит 40 киловольт.
— Кидаем стакан в бардачок теслы. Запускаем теслу в космос. Ждём.
— Просто ждём. Если ждать достаточно долго…
— Подходя с чисто философской точки зрения, стакан уже разбит.
— Хотя если по-настоящему абстрагироваться, то стакан не только уже разбит, но и ещё разбит.
— Нельзя наполовину разбить стакан. Или можно?
— Бросаем в стакан чёрную дыру.
— Запускаем в комнату трёх тестировщиков, трёх котов, трёх псов с привязанными к хвостам консервными банками, Киркорова и агил. Выключаем свет.
— Подгоняем танк.
— Осторожно, аккуратно, деликатно, выбрасываем стол в окно.
— Поджигаем стол.
— Ставим стакан в сейф Шредингера.
— Расплавляем стакан, отливаем из него стеклянный хер. Выдаём дураку под расписку его и пару защитных перчаток.
— Отпиливаем у стола все ножки. Тем самым защищаем объект от разбивания в состоянии «стояния на этом столе».
— Стучим по стакану карандашом, по звуку проверяем, а не разбит ли он уже.
— Спорим в пьяной компании, что стакан можно засунуть в … да что там… тут все программисты..., в сраку. При попытке извлечения стакан разбивается. Реальный случай. Я лежал в одной палате с человеком, который пострадал, поводя эксперимент. У него были сломаны нос, нога и челюсть. Так что соблюдайте технику безопасности, если соберётесь повторить.
— Становимся Президентом России. Жмём большую красную кнопку.
— Если не помог предыдущий пункт — отсылаем Креосану.
— Просто засовываем в посылку и посылаем почтой России.
— Засовываем в посылку, платим за объявленную ценность в 100 000р и посылаем почтой.
— Берём стакан на митинг по защите… ну вы меня поняли.
— Обеспечиваем в комнату свободный доступ. Каждую ночь наливаем в стакан 100 грамм водки. Повторяем до ожидаемого эффекта.
— Привязываем к ножке стола ноги секретарши будущего босса. Начинаем кидать в неё замороженные какахи. Или лучше незамороженные. Для чистоты эксперимента.
— Прибиваем стакан гвоздём к столу.
— Забиваем стаканом гвоздь в стол.
— Забиваем столом стакан в гвоздь.
— А у вас ещё есть стаканы? А то меня ещё столько вариантов осталось!
— Отдаём задание на аутсорс.
— Объявляем конкурс на поставку 10 битых стаканов.
— Делаем из стакана секундный маятник. Чтобы… да неважно, что, процесс изготовления так выбесит…
— Подгоняем 1000т пресс. Сбрасываем пресс на стакан.
— Берём две ровные сухие сосновые дощечки. Ставим между ними стакан. Сверху аккуратно ставим слона. Сбрасываем на них пресс.
— Вбиваем в стакан черенок лопаты. Доливаем пива по вкусу.
— Предлагаем просто взять, просто взять и сломать мой богатырский меч о стакан. Если возьмут на работу.
— Устраиваем в комнате просмотр инсталляции. Внезапно объявляем приз в 1000р за лучший перфоманс.
— Закладываем на вертолёте крутой вираж. Стакан соскальзывает со стола. Если не разбивается, делаем мёртвую петлю.
— Наполняем комнату водой. Одеваем акваланг. Ныряем. Обматываем стакан тухлым мясом. Выныриваем. Заныриваем в комнату акулу.
И ведь некоторые из собеседуемых не могли придумать и пяти способов.
Передал тестировщикам, боюсь теперь они до конца дня будут хихикать ;)
А вообще после таких статей хочется забухать…
А вообще после таких статей хочется забухать…
Вы же понимаете, что желание «забухать» ненормально по определению, вне зависимости от надуманной причины?
Реверс виртуалки — интересная техническая задача, плюс.
Последующее собеседование — пища для размышлений, тоже плюс.
Прошли собеседование — отлично, не прошли — ну и фиг с ним. Проще нужно ко всему относиться.
У меня от прочтения статьи исключительно положительные впечатления.
В Гугле в Цюрихе хорошо платят — гугл+швейцария стоило того, чтобы попробовать. Другое дело, что слишком хорошо выступить на собеседовании тоже чревато.
Лучше бы я поступил на уровень попроще, на зарплату поменьше и развивался бы до текущего уровня, получал бы удовольствие от новых знаний и сохранял нервы, а не держался бы через силу.
С «испытанием» я справился, но очень уж пришлось напрягаться.
Не хотите рассказать подробнее?
Мои проблемы будут выглядеть нытьём зажравшегося «тракториста».
1. Какие есть возможности релокации из Цюриха в штаты (L1/H1B), или не интересовались?
2. Про гугл много пишут что они предлагают средний total compensation, но с competitive offer могут сильно ее поднять. Так ли это?
2. Даже не задумывался. Когда мне выдали оффер, зарплату сразу предложили даже больше той, за которую я планировал торговаться.
В Швейцарии намного лучше ситуация как с жильём, так и с транспортной доступностью офиса.
кроме калифорнийского кампуса есть еще вашингтонский (сиэтл-керкленд). там и с жильем, и с доступностью офиса пока получше калифорнийского. его тоже можно рассматривать в качестве варианта.
2. сложно сказать. выше среднего наверное, но не прям заоблачно. и да, оферы от других компаний очень сильно помогают с поднятием.
Про гугл много пишут что они предлагают средний total compensation, но с competitive offer могут сильно ее поднять. Так ли это?Да, это везде так, и гугл не исключение. Никто не будет вам сразу давать жирный офер (особенно если вы приходите не из FAANG) — надо немного поторговаться, и офер от другой компании лучшее для этого средство.
С командой и менеджером повезло — думаю, они довольно быстро смогли оценить мой реальный уровень, но решили, что я смогу подтянуться.
Об L5 я, пока, даже не задумываюсь — оклематься бы.
То, что вас взяли на уровень выше, — это однозначно плюс, поскольку не надо лишний раз проходить через промо (вот там будет реальная нервотрепка). Еще, говорят, очень сложно уволить человека из гугла.
Вот то же самое хотел написать, только постеснялся «диагноз по фотографии» ставить. Как можно понять в первые полгода из-за чего у тебя проблемы с планированием, от недостатка опыта или потому что любая простейшая задача требует длительных раскопок эзотерической инфраструктуры? Кроме того, если у lanseg нет конкретного инсайда от интервьюеров или комитета (надеюсь, что нет), то я очень сомневаюсь, что результаты интервью повиляли на hiring level.
Что такое FAANG?
в целом, полезно с рекрутером заранее про уровень все обговорить. если вас интересует 5-6 в гугле, то стоит заранее убедиться, что вам луп не на 3-4 устраивают.
Есть даже такая легенда: однажды один программист загуглил «mutex lock», а вместо результатов поиска попал на страницу foo.bar, решил все задачи и устроился на работу в Google.У меня сейчас в закладках foo.bar висит. Никак не соберусь поиграть. На работу в гугл не собираюсь, к тому же, после этого фубара такая же головомойка как и у самых рядовых кандидатов.
Наверное и вопросы сплагиатили из тестовых вопросов этих самих курсов.
После десятка лет работы в специфичных предметных областях, большая часть неиспользуемой в работе «теории» забывается, зато в предметных областях ориентируешься так, как будто получил соответствующее образование в данной области.
А про кодирование последовательности байт в 6-ти битную «символьную кодировку» и про прочие сортировки пузырьками можно за пару минут и википедии прочитать.
В жизни всякое встречается в прикладной разработке (в том числе и в кровавом ынтерпрайзе, не говоря уже о гуглах): редко, но за свою карьеру мне пригождались знания, полученные в институте по курсам: "стохастические процессы", "теоретическая механика", "теория управления", "линейная алгебра". Не думаю, что я смог бы решить те задачи, не имея знаний, и даже не зная, что искать в википедии.
А про кодирование последовательности байт в 6-ти битную «символьную кодировку» и про прочие сортировки пузырьками можно за пару минут и википедии прочитать.
Проблема с алгоритмами в том, что не зная их, разработчик даже не подумает, что эту задачу можно решить таким-то методом. Будет какой-нибудь полный перебор всобачивать. Или сортировать списки квиксортом, ведь в вики написано, что это быстая сортировка.
А про кодирование последовательности байт в 6-ти битную «символьную кодировку» и про прочие сортировки пузырьками можно за пару минут и википедии прочитать.
А когда нужно не 6 бит, а какие-нибудь 5 бит? Надо представлять как это работает, чтобы хотя бы знать, что можно адаптировать base64, только не 3 байта в 4 перобразовывать, а 5 в 8.
Если человек не может понять, что как тут можно битовую последовательность нарезать на кусочки для base64, то и эта новая, уникальная задача займет слишком много времени или вообще будет неподъемна.
Я не имел ввиду что можно начать программировать, прочитав по данной теме пару статей в википедии.
Каждый «мастер» должен знать если не все то почти все про возможности «инструмента», которым работает.
А вот тонкости-подробности способа решения какой-либо, редко встречающейся, задачи можно «освежить» и в соответствующей документации.
Ну какие тут тонкости? Или человек додумается до разбиения на биты, хоть и с подсказками, или — нет. А тонкости особо не важны. Если кандидат -1 где-то в коде не поставит, пустит 2 последовательных цикла вместа одного, или забудет про граничное условие, то я подскажу. Это минус, но не красный флаг.
Через 3 дня после звонка я получил письмо, в котором мне сообщали, что собеседовать дальше меня не хотятНу не хотят — как хотят. На работу не взяли, NDA не подписали! Можно смело выкладывать исходники!
Лучше их продать плохим парням!
Лучше продать их китайцам
1) Неосиляторы — те, кто ноют, что в гугле (подставить любую компанию из Долины) спрашивают задачки на простенькие алгоритмы для джунов
2) Разумные — те, кто понимают, как на самом деле проходят интервью в топ кампании, зачем они имеют такой формат и как они на самом деле оцениваются.
Разумные легко попадают в желаемую компанию если не с первого, то со второго или, на худой конец, с третьего раза.
Неосиляторы ноют. В редких случаях из-за сильного университетского бекграунда они попадают в желаемую компанию. ЧСХ, потом они оттуда валят, потому что «все не то и все не так».
Вам не приходило в голову, что это послание – не приглашение? Вы копали код защиты. Можно предположить, что вы нашли ещё один слой защиты, только на этот раз – психологический. Потенциально вас могли и взять, но главная цель, вполне возможно, была иная – отвлечь от взлома некоторую часть ломающих, используя в качестве наживки авторитет компании. Проверить и «отсобеседовать» их, взять на заметку, убедительно попросить не разглашать.
Главное, вполне сработало.
Определенно тут приложили руку психологи «отдела безопасности»-)
Но, судя по фактам, получилось именно так.
На мысли наводят даже не приглашения, а холодный приём сразу после них.
Письмо от члена команды DroidGuard было довольно лаконичным: «Зачем ты этим вообще занимаешься?»
Совсем не похоже на «О, это наш человек!». Это «прям-очень-сильно-занятый-сотрудник-боооольшой-сеееерьёзной-компании» хмуро смотрит «ну кто там опять ковыряется, задолбали».
Ребята, вы гении, если вы туда смогли попасть! Серьезно. Я не представляю, как можно пройти через эту полосу препятствий.
У меня знакомый туда таки попал. Они выкупили стартапчик вместе с конторой, и сотрудниками которые его пилили.
Они выкупили стартапчик
Есть такая полу-шутка, что единственный способ заниматься чем-то действительно интересным в Гугле — пилить интересный стартап, который потом купит Гугл.
Мне повезло, мне попался вопрос, который я заранее видел в интернете и который я уже решал перед собеседованием.
Не могу сказать наверняка, но, скорее всего, в этом и была проблема. Надо было честно об этом сказать. Интервьюэр работает с этим вопросом и представляет насколько сложно в него врубиться с первого раза. На телефонном интервью не оценивают ваши навыки, смотрят на потенциал и на очевидные red flags. Если умолчать, что знаете вопрос — это сразу red flag. Вам самому нравится работать с людьми, которым не доверяешь?
Нет никакой проблемы в том, чтобы не решить задачку, тут важен процесс. Насколько вы были вовлечены, насколько задавали хорошие вопросы. Как у вас вообще с софт скиллз? Возможно, вы недооцениваете этот компонент.
Решение:
1. придумать разделитель
2. экранировать в строках этот разделитель и возможно спец символы (если есть)
3. склеить строки с этим разделителем
Использование base64 для строк даст только экранирование спец симвлов (если они вообще есть) и увеличение размера на треть. Дальше интервьюер пытается направить на правильный путь, зная как работает предложенный вариант можно было бы понять что это так себе решение, но и тут пустота. Два вопроса — два не правильных ответа, есть смысл продолжать?
А вообще, в качестве разделителя можно использовать нуль-символ, так что мудрить с base64 необязательно.
Зачем тогда их называть строками?
Кроме Си, на свете есть и другие языки.
добавляем в конце каждого из массивов
В начале. А иначе вы этот конец потом не найдёте.
Почему это важно? Хотя бы потому, что если приходит 30 Тб строк — вам не нужно ничего сохранять и хэш считается на лету как ему и положено.
Чувствую себя собеседующим в гугле.
Но не важно. Вот вам две строки:
"\0\1\2" + 30 Тб повторений '\2'
"\0\1\2" + 30 Тб повторений '\2' + "\1"
Первая — это "\0\1" (длиной 2 символа) и за ней 10 трлн строк "\2\2" (длиной 2 символа каждая).
Вторая — это "\0" (длиной 1 символ), за ней 10 трлн строк "\2\2" (длиной 2 символа каждая), и в конце "\2" (длиной 1 символ).
Результат — вы не можете вычленить первую из сериализованных строк до того, как прочитаете все 30 Тб.
Мне повезло, мне попался вопрос, который я заранее видел в интернете и который я уже решал перед собеседованием.
Если не сложно, какой вопрос был первый? Не точная формулировка, а примерно.
Конечно жалко, что рускоязычное комьюнити мертвое в плане взаимопощи в подготовке к подобным собеседованиям. Крохи на dou.ua и здесь не в счет. Китайцы, например, подробно описывают как они проходят интервью, решают вместе задачки, делятся опытом как выбить больше денег и т. п. и т. д. Ваша задачка кстати в топ 70 на литкоде по тегу Гугл, если по частоте попадания на интервью отсортировать за 2 года. Но вы наверняка даже не знаете про литкод, т. к. смотрите выше про мертвое комьюнити.
вы наверняка даже не знаете про литкод
Да не то чтобы я был прям такой дремучий :)
Вот сейчас открыл глянуть свою статистику — 60 задачек на литкоде я решил, пока готовился. Много информации о прохождении собеседования, в том числе и на русском языке. На английском еще больше, это же не проблема.
Ну и может не совсем насчет комьюнити… Но мне уже два человека отписались из Цюрихского офиса Google, посоветовали как лучше готовиться и т. д. Так что взаимопомощь есть.
Во-вторых, не понимаю позицию «хороший программист должен пройти в любую компанию, а если не прошёл — значит собеседователь некомпетентный
А из Google за два года я больше никаких сообщений не получал.
Меня и из гугла, и из FB через год после первого (проваленного) собеседования звали отсобеседоваться снова, но я уже не искал работу.
Судя по статье, описанный «квест» вовсе не был частью отбора, а вставили его просто так, по приколу — как и упомянутый в самом начале статьи com.android.egg.
И как уже много раз написали, логика собеседования не такая, что «реализовал base64 — берём, не осилил — отсеиваем». Собеседователь хочет видеть, как кандидат решает незнакомую задачу.
Для большинства инженеров собеседования — это обыденная обязанность. Они отвлекают от работы, вынуждают тебя быть пунктуальным, после них нужно потратить кучу на написание фидбека, даже если кандидат очень слабый. Мало кто в здравом уме не будет тратить столько времени и ресурсов, чтобы потешить самолюбие.
далеко не высокими зарплатами
Зависит от региона, но в целом зарплаты в гугле очень хорошие.
ни топикстартеру, ни мне никакого «детального фидбека» не предоставлялось
Речь о фидбеке, который получает комитет. Вы, разумеется, никакого детального фидбека не получите, чтобы не с чем в суд было идти.
Не вижу, как это что-то там подтверждает. Тем, кто безразличен, как раз нет особого резона проводить собеседования.
Я много раз был в роли собеседуемого, и почти всегда (кроме собеседования в Amazon) впечатления были строго положительные. Меня собеседовали люди, с которыми я бы хотел работать.
или либо работаете в Google небольшое время, чем до сих пор очень гордитесь :)
Не знаю, что для вас «небольшое время», я проработал там 4 с хвостиком года, все это мог наблюдать своими глазами, и никакого щенячьего восторга или розовых очков у меня нет.
Про какой «hiring committee и детальный фидбэк» вы говорите, я так и не понял
Про комитет вам уже рассказали ниже, ну и про зарплаты вы тоже заблуждаетесь — они не самые высокие в индустрии, это правда, но они все же выше подавляющего большинства. Есть, правда, нюанс — существует поправка на географическое положение офиса. Например, в Калифорнии или Нью-Йорке платят больше, чем в Колорадо.
Т.е. вы считаете, что абсолютно все инженеры Google, проводящие интервью, подобно вам, добросовестно подходят к делу, и, прежде всего, их заботит будущее компании, а не личные обстоятельства/настроение?
Нет, как я уже выше сказал, об «абсолютно всех» я сказать не могу, но могу сказать о подавляющем большинстве. В конце лупа все участвовавшие видят весь фидбэк, оставленный другими интервьюерами. И оттуда видно, что люди подходят (обычно) к вопросу добросовестно.
Объяснения «значит, его знания были недостаточны для этого проекта» не выглядят, в силу вышеизложенного, убедительными — слишком высок входной порог, равно, как и объяснения, что «гуглу нужны специалисты только гениального уровня».
Мне сложно судить, меня там не было и отчета другой стороны я не видел. В гугле есть еще один интересный момент — найм делается не для команды, а для компании. То есть, возможно, в конкретную команду человек может подходить, но в другие, возможно нет. А придя в гугл, человек может сразу же перейти в другую команду. Ну и телефонные интервью — это более лотерейная вещь, чем полноценный онсайт.
Хочу вот еще к этому добавить:
человек прошел очень нетривиальный «входной тест», и смог расшифровать хитро спрятанную «пасхалку»
Это очень похвальное достижение, но оно мало говорит о способности кандидата решать задачи и писать хороший код. В какую-нибудь антивирусную компанию, где навыки реверс-инжениринга нужны, это был бы хороший тест. В гугл? Не очень.
А вопрос на интеврью кандидат практически завалил. Задача, напомню, о сериализации массива строк. base64 — это очень плохой подход. Это при том, что автор написал, что эту задачу он раньше видел! Т.е. кандидат не удосужился проанализировать возможные решения и не додумался использовать более простое с экранированием символов разделителя. А потом кандидат не смог реализовать предложенное им же решение, даже с подсказками интервьювера. Не удивлюсь, если были и подсказки в сторону более простого решения, но автор их не уловил.
Да, можно много ругаться, что такие алгоритмические интервью с задачами — зло и слабо коррелируют с настоящей работой, но это не отменят того, что интервью было проведено честно, с известными заранее рамками и условиями, и автор просто не осилил его.
Тогда объясните, для какой цели, с вашей точки зрения, данная «пасхалка» (а, точнее, сложная техническая загадка) была помещена гуглом в продакшн код?
это способ попасть в рекрутинг пайплайн. большинство резюме, пришедших в гугл, не пройдут до этапа даже звонка от рекрутера. решивший же пасхалку получает шанс проинтервьюироваться.
Я так привык: есть задача — решаем, есть проблема — оптимизируем. «Преждевременная оптимизация — корень всех зол.» (с) Дональд Кнут.
Это плохо и точно не характеризует меня как хорошего разработчика. Поэтому с Гуглом нам оказалось не по пути.
Десятки миллионов закачек моих приложений — к сожалению, это не моя заслуга. Просто время раньше такое было: можно было выложить что угодно в Google Play и получить миллионы бесплатных инсталлов.
А вообще мне интервью понравилось, и интервьюер тоже. Приятный парень, я после интервью был уверен, что я его прошел. У меня из моего опыта общения с сотрудниками гугла пока складывается впечатление, что главный критерий отбора у них — это быть приятным в общении :) После статьи несколько человек из Цюрихского офиса отписались, посоветовали, как готовиться и т. д.
Но job offer-а от них я так и не получил.Именно так. Если, не дай бог, вы покажите интервьюируемому, что вы чем-то недовольны, и даже, ужас какой, упомяните чем именно — получите тот ещё разнос от начальства. Потому даже не надейтесь по реакции интервьера понять — получите вы оффер или нет. Это вам не Яндекс.
Я так привык: есть задача — решаем, есть проблема — оптимизируем.И вот именно людей с подобным подходом и было призвано отсеять собеседование.
«Преждевременная оптимизация — корень всех зол.» (с) Дональд Кнут.Как же все задолбали выдёргиванием этой фразы из контекста.
Если вы почитаете оригинал, то обнаружите, что сама эта фраза служит уточнением к другой, почти прямо противоположной: в развитой инжереной дисциплине улучшение в 12%, легко получаемое, никогда не рассматривается как несущественное — и я верю, что подобный же подход должен возобладать и в програмимровании (in established engineering disciplines a 12% improvement, easily obtained, is never considered marginal; and I believe the same viewpoint should prevail in software engineering).
Просто всё упирается в то, что нельзя оптимизировать программу отдельным проходом «когда-то потом». Нельзя. Не работает это. Причём разница между программой, которую реализовывали аккуратно, думая о скорости и потреблении памяти на всех этапах, и программой, которую оптимизировали по принципу «есть проблема — оптимизируем», зачастую, достигает 3-5 раз.
Другое дело, что сегодня, сейчас, часто вполне хватает и нифига не оптимизированной программы — потому что компьютер всё равно простаивает, а программисты дороги… но когда у вас миллиарды пользователей, то необходимость в написании эффективных программ возникает чаще, чем у какого-нибудь стартапа.
И вот именно людей с подобным подходом и было призвано отсеять собеседование.
Да я только «за». Я еще раз хочу уточнить: я этот пост не потому написал, мол посмотрите, вот я непризнанный гений, а меня Google обидел. Просто Google — не мой уровень.
На собеседовании все было честно и справедливо. Чтобы найти пасхалку нужно только много свободного времени, больше ничего. Я безработный, времени у меня в избытке.
Это же хорошо, что в индустрии много людей, как я («с подобным подходом»). Пока нас много, у вас будет хорошая работа :) Если все были бы лучшими, то кто тогда работал бы в топовых компаниях?
Как же все задолбали выдёргиванием этой фразы из контекста.
Зачем так сразу категорично? Я видел цитату про преждевременную оптимизацию в контексте этой статьи.
Communications of the ACM CACM Volume 17 Issue 12, Dec 1974
Тут как раз про излишнюю оптимизацию и рост сложности.
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¢.
Тут Кнут прямо явно ссылается на свою другую статью.
Но даже и в той цитате, что вы привели, есть слова I am sorry to say that many people nowadays are condemning program efficiency, telling us that it is in bad taste — это, собственно, то, что делаете вы.
Нельзя, к сожалению, «добавить» в программу эффективность (или безопасность) после того, как она написана. Эти вещи должны быть там с самого начала.
Лучшее, чего можно добиться — это разбить программу на достаточно крупные блоки и каждый из них переписать с нуля.
Да, конечно, можно удариться в другую крайность и начать писать функции в 10'000 строк в попытках избежать потерь на передачу данных — и это ни к чему хорошему не приведёт, так как вы в этих функциях запутаетесь.
Но сегодня, увы, превалирующая доктрина приводит к ровно противоположной проблеме: вы теряете настолько много на банальных бессмысленных индирекциях, что попытки выиграть что-то на векторизации, «раскрутке» циклов или на каких-нибудь заранее аллоцированных массивах (то есть как раз вещи, про которые Кнут и писал, что их не стоит делать в 97% случаем) выглядят, по меньшей мере странно: какие, нафиг, 12%, если у вас за счёт «новейшего дизайна» программа требует в 100 раз больше памяти, и в 10 раз больше времени, чем оптимальная?
Но, судя по словам Андрея, последовавший за этим вопрос: «а напишите мне алгоритм кодирования base64», по моему, явно выходит за рамки телефонного (да и white board) интервью.А что тогда туда входит, я извиняюсь? base64 — это, фактически задача чуть сложнее сложения чисел в массиве. Нет, там тоже есть куда углубиться (вот тут, например)… но просто закодировать строку — это вот примерно этот уровень.
Если не спрашивать даже подобные задачки на интервью, то… что тогда спрашивать?
Взгляните, например, на С-шную имплементацию, будет чуток посложнее, чем «сложение чисел в массиве».Именно что «чуток». Посмотрите на ассемблерный выхлоп сложения двух массивов — сложность вполне сравнима, разница только в том, что оптимизации за вас компилятор делает, а в случае с
base64
вам это руками нужно делать.Так что не вижу проблем в том, чтобы написать работающую реализацию хоть в командной строке — а потом обсудить как её можно было бы улучшить. Точно также как и в случае со сложением массивов (если предположить, что векторизовать ваш компилятор не умеет и вам нужно делать это руками).
Какие качества разработчика при этом проверяются?Умение написать 10-15 строк осмысленного кода, однако.
Помнит ли он детально RFC?Сдалось вам это RFC. Там base64 посвящена одна страница. И, я вас уверяю, интервьюер бы простил вам перепутанные символы "+" и "/". И даже не обиделся бы, если бы вы вместо "=" использовали бы, скажем, минус. Не в этом же дело-то!
Человек приплел, от волнения, ни с того, ни с сего, base64, а от него сразу попросили этот алгоритм написать.Но ведь он же приплёл, его никто за язык не тянул!
А если он просто забыл, как именно реализуется base64 — вы такое можете представить?Я бы был скорее удивлён, если бы он все детали и тонкости помнил. Конечно же речь шла про то, чтобы увидеть как он его будет «на лету» реализовывать, а не как он его вспомнит и в готовом виде на интервьюера «выльет». Раз он сам вспомнил — значит где-то что-то видел… А для такой простой задачи больше-то и не нужно!
Предложи ему задачу в полном виде, вроде «закодировать ASCII строку только буквами и цифрами латинского алфавита, плюс два дополнительных», он, думаю, как-нибудь да решил (пусть и не совсем изящно).А кто ему будет в таком разжёванном виде после приёма на работу задачи ставить будет????
Вот вы, не заглядывая в stackoverflow и не гугля, можете слету выдать эффективный base64 для Unicode strings?Чем Unicode строки перед вами провинились? И причём тут base64? Или вы хотите результат в виде UCS-2? Или вообще что?
Или, например, без гугла выдать алгоритм CRC-64?CRC-64 не выдам — я там коэффициенты не помню. Но ясно же, что это остаток от деления на какой-то полином 64й степени и xor'ами всё должно делаться…
< сходил в Гугл >
Ух ты: CRC64, оказывается, бывает аж два: ISO и ECMA… Но в целом — та же фигня: полином 64й степени, xor'ы, всё как ожидалось… В чём подвох?
P.S. А к чему был «ассемблерный выхлоп», я вообще не понял…К тому, что вы откопали какую-то странную «высокоэффективную» реализацию, которая, тем не менее, включает в себя дикое количество комментариев. Простейшая реализация гораздо проще и короче…
Человек приплел, от волнения, ни с того, ни с сего, base64, а от него сразу попросили этот алгоритм написать.
Я уверен, что человеку дали задачу, он предложил решать через base64. Интервьювер спросил про другие решения, собеседуемый не придумал ничего другого. Возможно даже были подсказки. Потом, ведь надо же какое-то решение написать, да? Вот и предложили кандидату написать придуманное им решение.
Опять же, задача в сериализации массива строк. Кандидат мог предложить хоть base64, хоть hex. Тут абсолютно фиолетово, какими именно символами что кодируется, какой padding используется и т.д. Если не помнишь, как base64 реализуется, придумай что угодно другое, только помни, зачем в этой задаче его приплел (что бы в закодированных строках не встречались придуманные тобой разделители).
Интервьювер спросил про другие решения, собеседуемый не придумал ничего другого. Возможно даже были подсказки. Потом, ведь надо же какое-то решение написать, да?
Вот вы сейчас зачем-то придумываете то, чего не было :)
Интервьюера устроил мой ответ с base64 для экранизации разделителей, и я его реализовал в google docs. После этого мне предложили реализовать base64. А вот дальше с подсказками интервьюера с горем пополам я написал что-то похожее на base64.
Даже если бы я сходу наизусть выдал base64 — это не гарантировало бы прохождение телефонного интервью. Потому что это так себе решение для исходной задачи, мягко говоря.
Чисто формально я решил исходную задачу. Но ведь цель собеседования не в этом же :) Увеличить размер исходных данных на треть и ничего не сказать про это, не оценить плюсы и минусы такого решения, остановиться на первой попавшейся идее — это все плохо и не для Гугла. Поэтому я и не попал дальше по конвееру собеседований, а не из-за незнания внутренностей base64.
Говорят, что очень возможна и обратная ситуация: можно не решить исходную задачу, но пройти собеседование. Охотно верю.
К уже отмеченному добавлю, что это скорее всего просто прикольнулись разработчики. Или идея была переманивать очень любопытных людей. Пусть лучше в гугл пойдут, чем будут эту защиту ломать. Или идея была чтобы народ связался с гуглом, раскрыл себя, тут можно и судом пригрозить, чтобы эксплоиты в сеть не сливали.
Но, насколько я знаю, просто вообще нет у разработчиков никакой возможности влиять на рекрутеров и процесс найма. Какую бы сложную задачу они бы не внедрили в пасхалку, просто бюрократически такой процедуры нет. Даже чемпионы мира по спортивному программированию проходят интервью, как все (хотя ни у кого нет ни малейших сомнений, что они интервью пройдут).
Но, насколько я знаю, просто вообще нет у разработчиков никакой возможности влиять на рекрутеров и процесс найма.
на само интервью влиять невозможно. но можно влиять на две другие компоненты процесса:
— вероятность того, что кандидат получит интервью (referral)
— вероятность найма в случае спорной ситуации. положительная рекомендация от сотрудника, ранее работавшего с кандидатом, может склонить чашу весов в пользу кандидата при рассмотрении комитетом.
Да, про положительные рекомендации забыл, но они весьма малый вес имеют и только в действительно спорных ситуациях на что-то влияют.
А referral… Сколько грусных мемов я видел про то, что "мой referral опять отсеян даже без телефонного интервью! T_T".
И ни то, ни другое интервью не заменяет и не отменяет никак, за что в этой ветке, как мене показалось, ругают злой гугл (ведь автор же уже сложную пасхалку решил).
base64 — это очень плохой подход. Это при том, что автор написал, что эту задачу он раньше видел! Т.е. кандидат не удосужился проанализировать возможные решения и не додумался использовать более простое с экранированием символов разделителя.
Не такой уж плохой подход: в худшем случае он увеличивает строку на треть, тогда как экранирование символов — вдвое.
Не такой уж плохой подход: в худшем случае он увеличивает строку на треть, тогда как экранирование символов — вдвое.
Но при этом и в лучшем случае длина увеличивается на треть. А в экранировании можно использовать для экранирования любой из символов, который встречается в строке меньше других. Если выбирать из всех 255 символов, то можно гарантировать увеличение максимум на пол процента + 1 символ. А в лучшем случае, если данные не случайны, то вообще без увеличения.
Но главный минус выбранного подхода — автор не смог его запрограммировать. Экранирование в этом случае было бы гораздо проще, т.к. там не надо битовых операций.
Но при этом и в лучшем случае длина увеличивается на треть. А в экранировании можно использовать для экранирования любой из символов, который встречается в строке меньше других. Если выбирать из всех 255 символов, то можно гарантировать увеличение максимум на пол процента + 1 символ.
Совершенно верно, но по условию задачи строки бесконечно длинные (а иначе можно было бы сохранить их длину) — так что нет возможности пройтись по ним перед сериализацией и выбрать редко встречающийся символ.
Совершенно верно, но по условию задачи строки бесконечно длинные
Читаем 250 символов, выбираем наиредчайший и используем его для экранирования в этом куске. Повторяем, пока строка не кончилась.
Распаковщик читает символ для экранирования, потом читает до символов <экран>0. Если распаковано 250 символов, считывается новый символ экранирования.
Ваш аргуемент, что в худшем случае строка раздуется в 2 раза — он не абсолютно объективный. Потому что таких плохих входных строк мало, а тех которые почти не раздуются — их много. Т.е. в среднем и в лучшем случае алгоритм с экранированием сильно лучше base64.
Я, как интервьювер, предпочел бы ответ с экранированием. Да, дополнительный вопрос про экономию места был бы в обоих случаях. Но если экранирование можно соптимизировать до 0.5% ухудшения всегда, то base64 никак уже не улучшить.
Т.е. в среднем и в лучшем случае алгоритм с экранированием сильно лучше base64.В среднем случае он таки хуже — и сильно хуже.
Потому что таких плохих входных строк мало, а тех которые почти не раздуются — их много.Если сроки случайные — то наоборот. А если неслучайные — то нужно уже разбираться что это за строки и откуда они взялись.
В среднем случае он таки хуже — и сильно хуже.
Почему вы счиатете, что строки в которых более 33% данного, выбранного символа — средние? Если брать не '\', а какой-нибудь 0x01? А только такие при экранировании увеличатся хотя бы на треть, как base64 сделает со всеми строками.
Если сроки случайные — то наоборот.
Как раз в случайных строках и будет наперед выбранный символ встречаться меньше процента. И раздуются они на этот несчастный процент. В средней случайной строке все возможные символы встречаются почти одинаковое количество раз.
Это как сравнивать пузырек и квиксорт. Да, у квиксорта константа больше и в худшем случае он будет медленее пузырька. Но на практике (для больших массивов) используют квиксорт, а не пузырек. Так и тут. Экранирование для некоторых входных данных будет хуже base64, но для абсолютного большинства случайных строк оно будет лучше. Если же входные данные не случайные и там преобладает некоторый символ — просто возьмите другой символ экранирования.
Более того, я уже привел алгоритм, который гарантированно не раздувает строки более чем на 1% при этом требует константной памяти и выполняется за один проход по строке. Из base64 вы такого никогда не сделаете.
такая «пасхалка» вряд-ли была заложена обыкновенными инженерами с целью «просто поржать», практически наверняка это акция менеджмента. Наверняка сложность была выбрана, чтобы отсеять большинство кандидатов (вернее, что найдут ее считанные единицы из миллионов), т.е. разгадавший загадку заведомо будет высокого уровня
Не знаю насчёт именно этой пасхалки, но как раз большинство подобных штук инициируется инженерами и, зачастую, даже не доводится до сведения высоких менеджеров.
Понимаю, может Google компания не самая выгодная, но это лучше, чем ничего (я последние пару лет безработный).
Мне уже написал один человек из Amazon, предложил пойти к нему в команду. Правда, там энтерпрайз в Канаде. Не знаю, может не тратить попытку и подать резюме в Amazon на что-то более релевантное моему опыту мобильного разработчика :)
Да, H1B нужен, конечно. Я в Цюрих метил прежде всего потому, что у меня гражданство Евросоюза и мне не надо никаких дополнительных разрешений-виз и т. д.
Вообще это наименьшая из проблем (если можно назвать это проблемой). Ни разу не слышал, чтобы какая-то бумажная волокита стала препятствием в устройства на работу.
Разве что в штатах сложнее, да. Знакомый прошел собеседование, а с квотой пролетел.
Граждане EU/EFTA (за исключением Румынии и Болгарии, и то только до 31 мая сего года) пользуются правом на работу и проживание в Швейцарии.
https://www.sem.admin.ch/sem/en/home/themen/fza_schweiz-eu-efta/eu-efta_buerger_schweiz.html
Да, но порядок его получения скорее уведомительный чем разрешительный. К гражданам ЕС не применяются ни квоты, ни требования минимальной квалификации. Можно приехать, найти работу, подать на пермит и гарантированно получить его, а работодателю в свою очередь не надо доказывать, что в ЕС никого не нашлось на эту вакансию.
Нет никакой интриги, levels.fyi к вашим услугам. Не знаю как для Амазона, но для Гугла там картина вполне адекватная.
Ещё раз: не могу поручиться за Амазон, но указанные выше 100$/час = 200K$/год не представляют собой ничего выдающегося даже для L4 в G, не говоря уже о L5 (senior). По крайней мере на обоих побережьях и в Цюрихе.
Про гугл ничего точно сказать не могу, а Amazon знакомой предложил сильно меньше, по какой-то причине.А это точно было «на обоих побережьях и в Цюрихе»?
Потому что в других местах, где общий уровень цен ниже (а они почти везде ниже, побережья и Цюрих вообще самые дорогие места в мире… ну может в Токио сравнимы зарплаты), разумеется, предложение будет ниже.
В гугле работают одни эльфы поэтому вариант «попинать балду в оплачиваемое время и инкрементнуть метрику в годовом отчёте» мы конечно исключаем.
Насчет того, что хотел интервьюер. Я слышал такую версию, что их главная задача — нащупать предел компетентности кандидата. То есть будут менять условия и углубляться, пока не завалят. А оценивают по тому, как далеко удалось при этом уйти.
Экономный вариант для бесконечно длинных строк: bit stuffing.
В классическом варианте (шесть стоп-бит) гарантирует увеличение как максимум на 20%, тогда как base64 — на 33%.
Как я нашел пасхалку в защите Android и не получил работу в Google