Pull to refresh

Comments 33

Вообще непонятен смысл статьи. Точнее связь содержимого и заголовка, который меня заинтересовал. Я ожидал реальные кейсы взаимодействия с настоящей проблемой, а что внутри? Задача с собеседования, решенная к тому не через Бойера-Мура или Кнутт-Моррис-Пратта, а "в лоб". В таком кейсе и ошибиться нельзя. Может быть ценность в рассуждении? Камон, написать на бумаге примеры, прикинуть алгоритм и перенести в код — только в Гугле так делают? В общем, разочарование.

В алгоритме есть проблемы, кстати. 1. Не учитывается случай, что шаблон может быть длиннее строки, в которой он ищется, или может быть пустым. 2. Бесполезные итерации в конце поиска.
Думаю что тут решается вполне конкретная проблема — на собеседовании в Гугле нельзя писать код в IDE и пользоваться интернетом, а решение задачи идёт на скорость. Все эти срачи в твиттере о том, что юзернейм придумал решение, но ему не хватило времени записать его в виде кода. Поэтому возникает закономерный вопрос «как таким убогим образом можно сделать хоть что-то», и вот тут приходят на помощь всякие лайфхаки.

То есть, это не какой-то абстрактный совет про технологию решения проблем в общем случае, а вполне конкретная последовательность действий, которую нужно зазубрить как отче наш, как рефлекторную сборку-разборку автомата, и решать по этой схеме олимпиадные задачки, будучи разбуженным ночью.
До гугля тоже были программисты и тоже решали задачу на скорость. Причем тут известная торговая марка-то?
Потому что он в ней работает и может говорить только за себя и своего работодателя?
А что, если в Оракал решают так же?
Ну может и решают, и что?
Как решает типичные проблемы программист Google — создает стартап. А как же еще то?
Ищет решение в гугле
Делает презентацию описывающую проблему
Приглашает менеджеров и ведущих разработчиков на встречу
Коротко но эмоционально объясняет почему эту проблему необходимо решить и внедрить как можно быстрее
????
Через две недели идет на повышение, а баги будут чинить уже совсем другие люди.
Испытываю смешанные чувства. С одной стороны, вроде и понятно, что автор хотел сказать, с другой — по прочтении условия задачи мне пришло в голову (на Питоне) sourceString.find(searchString). Городить велосипед (пусть и на собеседовании) мне в последний раз хотелось лет 10+ назад.
А если бы в задании было «реализовать алгоритм перемножения чисел A и B» — то вы бы сделали это на «питоне» так: A*B — да?
Подозреваю, что да. Если бы в задании не было указано веских обоснований того, что стандартный оператор не устраивает.
Честно говоря, я не понимаю, зачем переводить подобные статьи. Неужели в ней есть какие-то откровения неизвестные даже студенту айтишной специальности второго курса?

Они там в гугле остальных что-ли за идиотов считают? Или у них там шанс повышения растет согласно индексу цитирования?
Проблема в том, что если попытаться на собеседовании записать код в IDE без интернета, ты наткнешься на кучу чудесных открытий. Которые нигде и никогда в других случаях не встретишь. Если при реальном кодинге ты сразу напишешь финальный код и потом просто поправишь ошибки, то тут надо написать с первого раза, в условиях стресса когда руки дрожат и мысли из головы выветриваются. Отсюда этот пятиступенчатый процесс уточнения (идея -> чертеж -> алгоритм -> псевдокод -> возможно правильный код) с пятым шагом в случае наличия ноутбука чтобы прогнать на нём тесты. Это совершенно не то, что происходит в реальной жизни, люди к этому не готовы.
Это всеочевидные вещи для тех, кто сдавал экзамен по ассеемблеру на листочке вклеточку (да, без компа!).
Проблема в том, что если попытаться на собеседовании записать код в IDE без интернета, ты наткнешься на кучу чудесных открытий. Которые нигде и никогда в других случаях не встретишь. Если при реальном кодинге ты сразу напишешь финальный код и потом просто поправишь ошибки, то тут надо написать с первого раза, в условиях стресса когда руки дрожат и мысли из головы выветриваются.

Извините, но нет, в статье речь идет не о собеседовании, а о повседневной работе.
В этой статье я расскажу о своей стратегии решения проблем, возникающих в ходе работы над проектом, от старта до финиша. Я использую ее в ежедневном рабочем процессе в Google,
Причем тут собеседования?

Если меня попросят писать код (не псевдокод, а код) на бумажке на собеседовании, я соглашусь если мне только скажут, что все в компании пишут код на бумажке.

Но в статье шла речь про работу. И если людям из Гугла всерьез приходит в голову писать статьи что можно словесно записывать алгоритм и рисовать блок схемы, то у меня только 2 предположения:
1) Для них самих это явилось откровением
2) Они считают всех работников не Гугла идиотами.
Зачем в реальной жизни записывать алгоритм, псевдокод и недокод, если можно сразу писать на языке программирования? Для меня это откровение, да (откровение скорей о работниках гугла, чем нечто такое, чем действительно стоит пользоваться).

Это может произойти или если ты не знаешь языка, или если тебе специально запихали палки в колёса (на собеседовании).

С другой стороны, если ты не знаешь JavaScript, ты всегда можешь написать на том языке, который знаешь, и потом странслировать на JavaScript. Наверное, есть специальный кейс — для человека, который не знает ни одного языка программирования, но как он оказался разработчиком в Google?

В целом вся эта статья с приближениями выглядит очень беспомощно

Зачем в реальной жизни записывать алгоритм, псевдокод и недокод, если можно сразу писать на языке программирования? Для меня это откровение, да


Ну например за тем, что речь может касаться нового разрабатываемого функционала. Ты сидишь с бизнес-аналитиками и записываешь с их слов алгоритм. Предлагаешь сразу на Go херачить?

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


Вы хотите работать в Гугле и получать $200к и более в год? Не хотите? Как хотите, следующий.
А если хотите, то делайте так как говорят в интервью.
Нет, не хочу.

Более того, я считаю, что уважающий себя спец не будет собеседоваться 10 этапов в длиной полгода-год, если ему не нужны очень сильно деньги, по нескольким причинам:
1) Зарплаты в IT и так высокие, выше какого-то порога деньги перестают быть решаюшим фактором
2) За время потраченное на все эти интервью и подготовки к ним человек может уже нормально работать и приносить пользу.
3) Сам факт, что люди закрывают вакансии по году говорит о том, что компании не нужны разработчики.
4) У хорошего спеца всегда есть предложения здесь и сейчас

Возможно, опыт работы в Гугле и полезен бывшим студентам, но я не очень понимаю зачем спецу с 10+ опытом там работать с учетом того, что 2/3 работы идет в помойку, а флагманские продукты гугла откровенно плохи
(Вспоминаю свою работу с корпоративной почтой gmail. Открыл админку, пошел кофе заварил. Выбрал приложение пошел чашку помыл. Выбрал роли — пошел покурил. А потом эти люди что-то на серьезных щах вещают про производительность)
А решение вашей проблемы в том, что никто адекватный не предъявит вам за отсутствующую точку запятой или пропущенную скобку в решении задачи на бумажке.
А если предъявит, тогда, наверно, оно и к лучшему — нечего с идиотами работать.
Они там в гугле остальных что-ли за идиотов считают?

В Гугле работает порядка ста тысяч людей.
Я бы не судил о всех о них по статье одного человека.
Тут два путя — статья либо фейк, либо согласована с пресс службой гугла. Если второй путь, то видимо да, можно судить.
Или не согласована, т.к. автор пишет в своём личном блоге и акцентирует внимание на:
Opinions expressed in my articles are mine, not those of my employers.

Или согласована, но людьми, которые не в состоянии оценить очевидность этих советов. Или этим людям эти советы показались очевидными, но не для всех. Например, они могут быть полезны начинающим разработчикам. Или это вообще нормально для медиума давать такие советы(медиум реально переполнен капитанскими статьями). Или ещё что-то.
В любом случае, не думаю, что статью рецензировали все разработчики из Гугла.
Но да, никто не мешает думать, что гугл — это некое живое существо у которого есть единое мнение.
Читаю статью, а потом открываю gmail.com — и понимаю, что типичные программисты google таки смогли найти себе проблему, с которой же и не справились :)

Ага, они indexOf найти в документации не смогли, судя по всему, но зато с бумажкой эффективно решили проблему!


Хотя странно выглядит эта статья. Вроде как код того же Chrome довольно таки хорош и красив, хотя судя по статье сложилось впечатление, будто бы его писало три миллиона джунов с бумажками на псевдокоде.

А давайте каждый сотрудник google/facebook/microsoft/etc расскажет нам как решать задачи. Мы-то ничего не знаем, потому что не работаем в google/facebook/microsoft/etc. Ога. Судя по тормознутости gmail, дерьмовости skipe и говнокоду facebook средний разработчик в этих компаниях — последний человек к мнению которого стоит прислушаться.
Так ли думает програмист?
— читаю пачку символов нужной длины по известному смещению, если она совпадает с тем что надо — бинго!
! но тут совершенно упускается то как «сравнение» работает, что делает операцию копирования просто лишней

— иду по массиву и ищу начало последовательности. Если нахожу — начинаю смотреть что дальше. Если что-то не получается — возвращаюсь в начало и все заново.
! все хорошо, но не надо акцентироваться на «задаче», надо акцентироваться на том что надо делать. Что нужно делать — идти по строке и искать начало последовательности. Про то, что надо возвращаться назад речи и быть не может, и стоит только уточнить что есть «последовательность».

Так получается Ахо-Корасик — банально делает что сказали, и именно так и должен думать «програмист гугла».
У вас уже постановка задачи неправильная: Даны две строки, sourceString и searchString, нужно вернуть первый индекс при появлении sourceString в searchString. Может, наоборот?
Sign up to leave a comment.