21.08.2018 05:29
nobodyhave 349 65400 Источник


Заголовок статьи звучит как epic fail, но на самом деле все не так однозначно. Да и в общем и целом эта история закончилась весьма позитивно, хоть и не в Google. Но это уже тема для другой статьи. В этой же статье я расскажу о трех вещах: каким образом проходил мой процесс подготовки, каким образом проходили интервью в Google и почему же на мой взгляд все не так однозначно, как может показаться.

Как все начиналось


Одним холодным кипрским зимним вечером мне вдруг пришла в голову мысль, что мои познания в классической Computer Science весьма далеки даже от средних, и с этим надо что-то делать. Если кстати вдруг кто-то еще не читал, почему вечер кипрский и холодный, то можно об этом узнать здесь. После некоторых размышлений было решено для начала пройти онлайн курс по алгоритмам и структурам данных. От одного из бывших коллег слышал про курс Роберта Седжвика (Robert Sedgewick) на Coursera. Курс состоит из двух частей (часть 1 и часть 2). Если вдруг ссылки поменяются, то можно всегда нагуглить по имени автора. Каждая из частей идет 6 недель. В начале недели выдаются лекции, а в течении недели еще нужно делать упражнения. Первая часть курса покрывает базовые структуры данных, основные виды сортировок и сложность алгоритмов. Вторая часть уже более продвинутая, начинается с графов и заканчивается такими вещами как Linear Programming и Intractability. Обдумав все вышеизложенное, я пришел к выводу, что это именно то, что мне нужно. Тут кстати пытливый читатель может спросить, а при чем же здесь Google. И действительно, до этого момента он был тут совсем не при чем. Но мне нужна была цель, так как заниматься 12 недель вечерами без цели несколько затруднительно. А какая может быть цель в получении новых знаний? Конечно, их применение на практике. В повседневной жизни это достаточно проблематично, а вот на собеседовании в крупную компанию запросто. Беглое гугление показало, что Google (уж простите за тавтологию) является одной из крупнейших компаний в Европе (а я рассматривал именно Европу), в которой проводят такие собеседования. А именно, их офис находится в Цюрихе, Швейцария. Итак решено — учимся и идем собеседоваться в Google.

Подготовка к первому заходу


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

  • Лектор говорит на достаточно четком английском
  • Материал хорошо структурирован
  • Шикарные презентации, показывающие внутренности каждого алгоритма
  • Грамотная подборка материала
  • Интересные упражнения
  • Упражнения автоматически проверяются на сайте, после чего создается отчет

У меня работа над курсами обычно проходила следующим образом. За 1-2 дня я прослушивал лекции. Затем проходил быстрый тест на знание материала. Остаток недели делал упражнение в несколько итераций. После первой получал свои 30-70%, последующие доводили результат до 97-100%. Упражнение обычно заключалось в реализации какого-нибудь алгоритма, например Seam carving или bzip.

После окончания курсов я осознал, что многие знания это многие печали. Если раньше я просто знал, что ничего не знаю, то теперь начал осознавать, что именно я не знаю.

Так как был еще только май месяц, а собеседование я запланировал на осень, я решил продолжить свое образование. После просмотра требований к вакансии, было принято решение пойти параллельно по двум направлениям: продолжить изучение алгоритмов и пройти базовый курс по машинному обучению. Для первой цели я решил переключиться с курсов на книгу и выбрал монументальный труд Стивена Скиены (Steven Skiena) «Алгоритмы. Руководство по разработке» (The Algorithm Design Manual). Не такой монументальный, как у Кнута, но все же. Для второй цели я опять пошел на Coursera и записался на курс Эндрю Ына (Andrew Ng) Machine Learning.

Прошло еще 3 месяца, и я закончил курс и книгу.

Начнем с книги. Чтение оказалось достаточно интересное, хотя и непростое. В принципе, я бы книгу рекомендовал, но не вот так сразу. В общем и целом, книга дает более глубокий разбор того, что я узнал на курсах. Плюс к этому я открыл для себя (с формальной точки зрения) такие вещи как эвристики и динамическое программирование. Естественно, раньше мне доводилось их использовать, но как они называются я не знал. Так же в книге присутствует некоторое количество баек из жизни автора (War Story), которые несколько разбавляют академичность изложения. Вторую половину книги можно кстати опустить, там идет скорее описание существующих проблем и методов их решения. Полезно, если регулярно применяется на практике, иначе забудется сразу же.

Курс меня более чем порадовал. Автор явно знает свое дело и рассказывает интересно. Плюс изрядную часть, а именно линейную алгебру и основы нейронных сетей я помнил еще с университета, поэтому особых трудностей не испытал. Структура курса достаточно стандартная. Курс разбит на недели. Каждую неделю сначала идут лекции вперемешку с короткими тестами. После лекций выдается задание, которое нужно сделать, отправить и оно автоматически проверится. Вкратце, список преподаваемого в курсе следующий:
— cost function
— linear regression
— gradient descent
— feature scaling
— normal equation
— logistic regression
— multiclass classification (one vs all)
— neural networks
— backpropagation
— regularization
— bias/variance
— learning curves
— error metrics (precision, recall, F1)
— Support Vector Machines (large margin classification)
— K-means
— Principal Components Analysis
— anomaly detection
— collaborative filtering (recommeder system)
— stochastic, mini-batch, batch gradient descents
— online learning
— map reduce
— ceiling analysis
После прохождения курса, понимание всех этих тем присутствовало. Через 2 года уже почти все естественно забылось. Рекомендую тем, кто не знаком с машинным обучением и хочет получить хорошее понимание базовых вещей для движения дальше.

Первый заход


На дворе был уже сентябрь и пришло время задуматься о собеседовании. Так как подаваться через сайт дело достаточно гиблое, занялся поиском знакомых, работающих в Google. Выбор пал на datacompboy, так как он был единственным, кого я знал напрямую (пусть и не лично). Он согласился передать мое резюме, и вскоре я получил от рекрутера письмо, предлагающее забронировать слот у него в календаре для первого разговора.Через пару дней состоялся созвон. Пробовали общаться через Hangouts, но качество было ужасное, поэтому переключились на телефон. Сначала быстро обсудили стандартные как, зачем и почему, а потом перешли к техническому скринингу. Он состоял из десятка вопросов в духе «какая сложность вставки в hash map», «какие сбалансированные деревья вы знаете». Не сложно, если есть базовое знание этих вещей. Скрининг прошел хорошо и по результатам решили организовать первое интервью через недельку.

Интервью тоже было через Hangouts. Сначала минут 5 поговорили обо мне, потом перешли к задачке. Задача была на графы. Я быстро понял, что надо сделать, но выбрал не тот алгоритм. Когда начал писать код осознал это и переключился на другой вариант, который и дописал. Интервьюер задал несколько вопросов на тему сложности алгоритма, спросил, можно ли быстрее. Я как-то затупил и не смог. На этом время вышло и мы распрощались. Потом, минут через 10 до меня дошло, что вместо алгоритма Дейкстры, который я использовал, конкретно в этой задаче можно было бы использовать поиск в ширину, и это было бы быстрее. Через некоторое время позвонил рекрутер и сказал, что интервью в целом прошло хорошо и надо бы организовать еще одно. Договорились на еще через недельку.

В этот раз дела пошли хуже. Если в первый раз интервьюер был дружелюбный и общительный, то в этот раз какой-то мрачноватый. Задачку я сразу раскусить не смог, хотя те идеи что я выдавал в принципе могли привести к ее решению. В итоге после нескольких подсказок интервьюера до меня дошло решение. В этот раз это снова оказался поиск в ширину, только из нескольких точек. Решения я написал, во время уложился, но забыл про граничные случаи. Через какое-то время позвонил рекрутер и сообщил, что в этот раз интервьюер остался недоволен, так как по его мнению мне потребовалось слишком много подсказок (3 или 4 штуки) и я постоянно менял код во время написания. По результатам двух собеседований было принято решение дальше не идти, а отложить следующее интервью на год, если у меня будет такое желание. За сим и распрощались.

И этой истории я сделал несколько выводов:

  • Теория это хорошо, но в ней надо быстро ориентироваться
  • Теория без практики не поможет. Надо решать задачки и доводить написание кода до автоматизма.
  • Многое зависит от интервьюера. И с этим ничего не сделать.

Подготовка ко второму заходу


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

  • Продолжать изучать теорию путем чтения книжек и статей.
  • Прорешать алгоритмические задачи в количестве 500-1000 штук.
  • Продолжать изучать теорию путем просмотра видео.
  • Продолжать изучать теорию путем курсов.
  • Изучить опыт других людей по прохождению собеседований в Google.

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

Книги и статьи


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

Книг я прочитал 5: Algorithms, 4th edition (Sedgewick, Wayne), Introduction to Algorithms 3rd Edition (Cormen, Leiserson, Rivest, Stein), Cracking the Coding Interview 4th edition (Gayle Laakmann), Programming Interviews Exposed 2nd edition (Mongan, Suojanen, Giguere), Elements of Programming Interviews (Aziz, Lee, Prakash). Их можно разделить на 2 категории. В первую попадают книги Седжвика и Кормена. Это теория. Остальные это подготовка к интервью. Седжвик в книге рассказывает примерно то же самое, что и в своих курсах. Просто в письменном виде. Нет особого смысла читать внимательно, если вы проходили курс, но проглядеть стоит в любом случае. Если курс не смотрели, то имеет смысл почитать. Кормен мне показался чересчур занудным. Осилил честно говоря с трудом. Вынес оттуда только master theorem, да несколько редко используемых структур данных (Fibonacci heap, van Emde Boas tree, radix heap).

Книгу для подготовки к интервью стоит прочитать хотя бы одну. Они все построены примерно по одному принципу. Описывают процесс интервью в крупных технологических компаниях, дают базовые вещи из Computer Science, задачки на эти базовые вещи, решения задачек и разбор решений. Из приведенных трех я бы наверное рекомендовал Cracking the Coding Interview как основную, а остальные по желанию.

Алгоритмические задачи


Это наверное был самый интересный пункт подготовки. Можно, конечно, сесть и тупо решать задачи. Для этого есть много разных сайтов. Я в основном использовал три: Hackerrank, CodeChef и LeetCode. На CodeChef задачи разбиты по сложности, но не по темам. На Hackerrank и по сложности, и по темам.

Но как я сразу для себя выяснил, есть более интересный способ. И это соревнования (programming challenges или programming contests). Все три сайта их предоставляют. Правда с LeetCode есть проблема — неудобная временная зона. Поэтому я не участвовал на этом сайте. Hackerrank и CodeChef предоставляют достаточно большое количество различных соревнований, длительностью от 1 часа до 10 дней. У разных форматов разные правила, ну да это про это можно долго рассказывать. Основная суть, почему соревнования это хорошо, это внесение соревновательного (и снова тавтология) элемента в процесс обучения.

Всего я поучаствовал в 37 соревнованиях на Hackerrank. Из них 32 были рейтинговые, а 5 или спонсируемые (я даже получил 25$ в одном из них) или по фану. В рейтинговых я 10 раз входил в топ 4%, 11 раз в топ 12% и 5 раз в топ 25%. Лучшими результатами были 27/1459 в 3-х часовом и 22/9721 в недельном.

На CodeChef я перешел, когда на Hackerrank соревнования стали устраивать реже. Всего я успел поучаствовать в 5 соревнованиях. Лучшим результатом было 426/5019 в десятидневном соревновании.

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

Просмотр видео


Прочитав книжку Скиены, я в принципе заинтересовался тем, чем он занимается. Как и Седжвик, он является профессором в университете. В связи с этим, в сети можно найти видеозаписи его курсов. Я решил просмотреть курс COMP300E — Programming Challenges — 2009 HKUST. Не скажу, что мне сильно понравилось. Во-первых качество видео не очень. Во-вторых я не пробовал сам решать задачи, разбираемые в рамках курса. Так что вовлеченность была не очень высокая.
Также в процессе решения задачек, пытаясь найти правильный алгоритм, я натыкался на видео Tushar Roy. Он работал в Amazon, а сейчас работает в Apple. Как позже я для себя выяснил, у него есть канал на YouTube, где он выкладывает разбор различных алгоритмов. На момент написания статьи канал содержит 103 видео. И надо сказать, что разбор в его исполнении сделан очень прилично. Я пробовал смотреть других авторов, но как-то не зашло. Так что этот канал однозначно могу рекомендовать к просмотру.

Прохождение курсов


Тут я особо ничем не занимался. Просмотрел видео из Android Developer Nanodegree от Google и прошел курс от ИТМО How to Win Coding Competitions: Secrets of Champions. Nanodegree вполне себе, хотя ничего нового оттуда я естественно не узнал. Курс от ИТМО в плане теории немного скомканный, но задачки были интересные. Я бы не рекомендовал с него начинать, но в принципе время на него было потрачено не зря.

Изучить опыт других людей


Само собой множество людей пытались попасть в Google. Кто-то попал, кто-то нет. Некоторые писали об этом статьи. Из интересных вещей наверное отмечу вот эту и вот эту. В первом случае, человек подготовил для себя список того, что ему нужно выучить, чтобы стать Software Engineer и попасть в Google. Попал он в итоге в Amazon, но это уже не так важно. Второй мануал написан инженером Google, Ларисой Агарковой (Larrr). Помимо этого документа, можно также почитать ее блог.

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

Ссылки на другие мелкие статьи приводить не буду, вы их сами прекрасно сможете найти в Google.

Второй заход


И вот год прошел. Выдался он весьма насыщенным в плане учебы. Но к новой осени я подходил с гораздо более глубокими теоретическими знаниями и отработанными практическими навыками. До окончания назначенного мне срока отведенного на подготовку года оставалось еще несколько недель, как вдруг на почту упало письмо от рекрутера из Google, в котором он меня спрашивал, имею ли я все еще желание работать в Google и не против ли пообщаться с ним. Естественно, что я был не против. Договорились созвониться через неделю. Также у меня попросили обновленное резюме, к которому я присовокупил краткое описание того, что сделал за год на работе и в принципе.

После общения за жизнь решили, что через недельку будет Hangouts интервью, все как в прошлом году. Неделя прошла, пришло время интервью, но интервьюер не появился. Прошло 10 минут, я уже начал нервничать, как вдруг кто-то ворвался в чат. Как выяснилось чуть позже, мой интервьюер по какой-то причине не смог появиться и ему срочно нашли замену. Человек был несколько не готов как в плане настройки компа, так и в плане проведения интервью. Но затем все пошло хорошо. Задачку я решил быстро, описал где возможны подвохи, как их можно обойти. Обсудили несколько разных вариантов задачи, сложность алгоритма. Потом еще 5 минут пообщались, инженер рассказал свои впечатления от работы в Мюнхене (в Цюрихе видать срочной замены не нашли), на том и расстались.

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

Пока готовил документы, попутно обсуждал с рекрутером предстоящее интервью. Стандарное интервью в Google состоит из 4 алгоритмических и одного System Design. Но, так как я устраивался как Android разработчик, мне было сказано, что часть интервью будет с Android спецификой. Какие именно и в чем будет специфика я из рекрутера так и не смог вытрясти. Насколько я понял, это ввели относительно недавно и он сам был не очень в курсе. Также меня записали на две тренировочные сессии: как проходить алгоритмическое интервью и как проходить System Design интервью. Сессии были средней степени полезности. Там мне тоже никто не смог рассказать, что же спрашивают у Android разработчиков. Поэтому моя подготовка в этот месяц свелась к следующему:

  • Покупке маркерной доски и написании 2-3 десятков самых популярных алгоритмов на ней по памяти. По 3-5 штук каждый день. Итого каждый был написан несколько раз.
  • Освежении в памяти разной информации по Android, которую не использую каждый день
  • Просмотре нескольких видео про Big Scale и все такое

Как я уже говорил, параллельно я делал документы для поездки. Для начала у меня запросили данные, чтобы сделать пригласительное письмо. Потом я долго пытался выяснить, кто же на Кипре делает визы в Швейцарию, так как швейцарское посольство этим не занимается. Как выяснилось, этим занимается консульство Австрии. Позвонил и записал на прием. Там затребовали пачку документов, но ничего особо интересного. Фото, паспорт, вид на жительство, кучу разных справок и естественно пригласительное письмо. Письмо тем временем все не приходило. В итоге поехал с обычной распечаткой и это вполне прокатило. Само же письмо пришло еще дня через 3, причем кипрский FedEx не сумел найти мой адрес и пришлось ехать за ним самому. Заодно получил все в том же FedEx'e посылку, которую они тоже не смогли мне доставить, так как не нашли адрес, и которая там лежала с июня (5 месяцев, Карл). Так как я о ней не знал, что естественно и не предполагал, что она у них есть. Визу я получил вовремя, после чего мне забронировали отель и предложили варианты перелета. Варианты я подкорректировал, чтобы было удобнее. Прямых рейсов уже не было, в итоге летел туда через Афины, а обратно через Вену.

После того как все формальности с поездкой были улажены, прошло еще несколько дней и я собственно вылетел в Цюрих. Добрался без приключений. От аэропорта до города доехал на поезде — быстро и удобно. Немного поплутав по городу нашел отель и заселился. Так как отель был забронирован без еды, отужинал по соседству и завалился спать, ибо рейс был утренний и спать уже хотелось. На следующий день позавтракал в отеле (за отдельные деньги) и отправился в офис Google. Всего в Цюрихе у Google несколько офисов. Мое собеседование было не в центральном. И в общем-то офис выглядел достаточно обычно, так что не довелось мне посмотреть на все плюшки «нормального» офиса Google. Зарегистрировался у администратора и сел ждать. Через какое-то время вышел рекрутер и рассказал мне план на день, после чего отвел в комнату, где и должны были проходить интервью. Собственно в плане значились 3 интервью, обед и еще 2 интервью.

Интервью номер раз


Первое интервью было как раз по Android. Причем вообще никак не было связано с алгоритмами. Сюрприз, однако. Ну да ладно, так даже привычнее. Попросили сделать определенный UI компонент. Сначала обсудили, что и как. Предложил сделать решение на RxJava, описал, что именно и почему бы сделал. Сказали, что это конечно хорошо, но давайте сделаем средствами Android фреймворка. А заодно напишем код на доске. Причем не просто компонента, а всей Activity, использующей этот компонент. Вот к такому я был не готов. Одно дело писать на доске алгоритм на 30-50 строчек, а другое дело лапшу Android кода, пусть даже с сокращениями и комментариями в духе «ну, это я писать не буду, так как и так очевидно». Получился какой-то винегрет на 3 доски. Т.е. задачу-то я решил, но выглядело это стремно.

Интервью номер два


На этот раз интервью было по алгоритмам. И интервьюеров было двое. Один собственно интервьюер, а второй юный падаван (shadow interviewer). Нужно было придумать структуру данных с определенными свойствами. Сначала как обычно обсуждали проблему. Я задавал разные вопросы, интервьюер отвечал. Через какое-то время попросили написать несколько методов придуманной структуры на доске. В этот раз более-менее удалось, правда с несколькими мелкими ошибками, которые я исправил с подсказки интервьюера.

Интервью номер три


На это раз System Design, который вдруг тоже оказался Android. Нужно было разработать приложение с определенным функционалом. Обсудили требования к приложению, к серверу, к протоколу коммуникации. Далее я стал описывать, какие компоненты или библиотеки я бы использовал при построении приложения. А затем при упоминании Job Scheduler случился некоторый затык. Суть в том, что я никогда не использовал его на практике, так как в момент его выхода как раз переключился на поддержку приложений, где задач для его применения не было и в помине. При разработке последующих было тоже самое. То есть в теории я знаю что это за штука, когда и как применяется, но опыта в применении нет. И интервьюеру это похоже не сильно понравилось. Потом попросили написать код. Да, при разработке приложения сразу нужно писать код. Опять же Android код на доске. Получилось снова страшненько.

Обед


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

Интервью номер четыре


Наконец-то алгоритмы в чистом виде. Первую задачку я решил достаточно быстро и сразу эффективно, правда промахнулся с одним граничным случаем, но по подсказке интервьюера (он дал этот самый граничный случай) нашел проблему и исправил. Само собой нужно было писать код на доске. Затем была дана похожая задача, но сложнее. Для нее я нашел пару неоптимальных решений и почти нашел оптимальное, не хватило 5-10 минут чтобы дожать мысль. Ну и код для нее я написать уже не успел.

Интервью номер пять


И снова Android интервью. Интересно, зачем я учил алгоритмы весь год?
Сначала было несколько простых вопросов. Потом интервьюер написал на доске код и попросил найти в нем проблемы. Нашел, объяснил, исправил. Обсудили. А дальше начались несколько неожиданные вопросы в духе «а что в классе Х делает метод У», «а что внутри у метода У», «а что делает класс Z». Что-то я конечно ответил, но потом сказал, что в работе в последнее время с этим не сталкивался и естественно не помню, кто, что и как в деталях делает. После этого интервьюер расспрашивал, что я делаю сейчас. И вопросы пошли на эту тему. Тут я уже отвечал гораздо лучше.

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

На то, чтобы обработать результаты интервью ушло полторы недели. После чего мне сообщили, что я был «a bit below the bar». То бишь немного не дотянул. Если конкретнее, то 2 интервью прошли хорошо, 2 немного не очень, а System Design очень не очень. Вот если бы хотя бы 3 прошли хорошо, то можно было бы побороться, а так без шансов. Предложили заходить еще через год.

Поначалу я конечно расстроился, так как на подготовку было затрачено много сил, и к моменту интервью у меня уже зрела мысль о том, чтобы покинуть Кипр. Устройство в Google и переезд в Швейцарию казались отличным вариантом.

Заключение


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

  • За полтора года я узнал огромное количество вещей, связанных с разработкой программного обеспечения.
  • Я получил немалое удовольствие, участвуя в соревнованиях по программированию.
  • Я съездил на пару дней в Цюрих. Когда еще туда выберусь?
  • Я получил интересный опыт интервью в одной из крупнейших IT компаний мира.

Таким образом, все произошедшее за эти полтора года можно просто считать обучением, или тренировкой. И результаты этой тренировки дали о себе знать. Моя мысль покинуть Кипр дозрела (по некоторым обстоятельствам семейного характера), я успешно прошел несколько собеседований в другую известную компанию и через 8 месяцев переехал. Но это уже совсем другая история. Тем не менее, думаю, что мне все равно стоит поблагодарить Google как за эти полтора года, которые я работал над собой, так и за 2 интересных дня в Цюрихе.

Что я могу сказать напоследок. Если вы работаете в IT, подготовьте себя к интервью в Google (Amazon, Microsoft, Apple и т.д.). Возможно, когда-нибудь вы туда заходите попасть. Даже если не захотите, то поверьте, от такой подготовки вам хуже не станет. В том момент, когда вы поймете, что можете (пусть даже только при удачном стечении обстоятельств) пройти интервью в одну из этих компаний, перед вами будет открыто гораздо больше дорог, чем перед началом вашей подготовки. А все, что вам потребуется в пути это цель, настойчивость и время. Желаю успехов :)

Комментарии (349)


  1. Foreglance
    21.08.2018 08:56
    #19014649

    Пару раз не прошёл интервью в Амазон (они очень активно нанимают), впечатления остались очень положительные — их сотрудники действительно пытаются узнать твои сильные стороны, уважительно и профессионально ведут процесс собеседований (ни какого сравнения с другой известной крупной компанией). Многому научился в процессе подготовки. Рекомендую — полезное и увлекательное занятие, только планку нужно высокую ставить, чтобы не сожалеть, когда ее преодолеете.


  1. Valle
    21.08.2018 09:06
    #19014673

    Фигасе. Гугл заболел, что-ли? Я андроид разраб — три раза проходил онсайт в гугле в MV и самый приближенный к андроиду вопрос был «а покажите над чем раньше работали», три четверти заданий обычно динамическое программирование и отстаток почему-то простецкие задачки с leetcode.


    1. Valle
      21.08.2018 09:09
      #19014679

      А, это Цюрих, не MV.


    1. Areso
      21.08.2018 12:35
      #19015639

      Прошу простить, а MV это где?


      1. Bizonozubr
        21.08.2018 12:44
        #19015711

        Ме?кленбург-Пере?дняя Помера?ния (Abkurzung MV). Германия получается, если правильно понял


        1. Gugic
          21.08.2018 13:01
          #19015807

          Скорее уж Mountain View (там главный кампус)


          1. Bizonozubr
            21.08.2018 13:09
            #19015851

            Признаю ошибку, хотя, судя по статье, думал речь идёт о Европе.


            1. vdonich
              21.08.2018 23:02
              #19018587
              +1

              Иногда, кстати, сокращают до MTV.
              И наверное чаще, чем MV. [citation needed]


              1. Homas
                22.08.2018 04:30
                #19018983

                MV вполне нормально для обозначения Mountain View.
                BTW MTV на автобусах Гугловских написано, которые сотрудников развозят.


      1. river-fall
        21.08.2018 12:58
        #19015791

        скорее всего Mountain View, CA


    1. alexeykuzmin0
      21.08.2018 18:26
      #19017625

      Видимо, заболел. Я не так давно переехал в Лондон в тот же самый Android, так по Android ни одного вопроса ни на одном собеседовании не было.


  1. j_wayne
    21.08.2018 09:30
    #19014747

    > Но это уже совсем другая история.

    А про устройство в другую компанию есть планы написать? Было бы круто.


    1. FlashManiac
      21.08.2018 09:50
      #19014817

      Да, с удовольствием почитал бы )


    1. nobodyhave Автор
      21.08.2018 09:57
      #19014851

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


      1. 3aBulon
        21.08.2018 10:29
        #19014959

        Интрига


  1. datacompboy
    21.08.2018 10:06
    #19014883

    А почему андроид? После проведённой подготовки произвольный swe же пыщпыщ


    1. nobodyhave Автор
      21.08.2018 10:19
      #19014923
      +1

      Да привык я как-то к андроиду ) Уже как 6 лет в нем ковыряюсь. Ну и допустим что собеседование на произвольного SWE я пройду на ура. А что дальше-то делать? Я же по сути всю жизнь с мобилками ковыряюсь, ничего другого не умею, кроме разве что давно забытых сакральных знаний об ассемблере и микроконтроллерах.
      Вот и получается, что Андроид я знаю, а собеседование не прошел.
      А то, куда наверное прошел бы, я не знаю.
      Такой вот парадокс )


      1. datacompboy
        21.08.2018 10:47
        #19015033

        Ну а потом уже свичнуться в андроид :)


      1. neyronius
        21.08.2018 10:51
        #19015055

        Вы ограничиваете себя сами своим отношением. Вы Software Engineer, который в данный момент времени занимается мобильными приложениями. А в принципе можете быстро перейти в любую другую область. Проще всего посмотреть сначала в Backend, ничего сложного там нет. Те же алгоритмы и подходы. Технологии меняются часто и всем приходится постоянно учиться.


        1. nobodyhave Автор
          21.08.2018 11:05
          #19015145

          Не совсем. Как я уже писал, я всю жизнь занимаюсь мобилками или встраиваемыми устройствами. Занимаюсь потому, что мне это нравится. У меня были офферы от геймдев компании и компании по разработке чего-то вроде биллинговой системы. Но даже имея их я предпочел мобильную разработку. Так что это скорее вопрос желания, а не возможностей.


      1. alekspak
        21.08.2018 18:23
        #19017609

        Когда приходишь в Гугл учишь много нового, потому что все системы и «библиотеки» свои. То есть общие знания о том, как что устроено помогает, но в целом никто не ждет, что ты с первого дня начнешь писать кучу кода. Поэтому интервью так устроены, потому что в основном фундаментальные знания снаружи полезны внутри. И в целом ожидается, что ты сможешь взять любую технологию/язык и сделать что-то с этим. Я уже успел написать код на 6 языках и даже сделать кое-какие изменения в приложении для Андроида, хотя никогда в жизни не прикасался к Андроиду.

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

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


  1. BingoBongo
    21.08.2018 11:10
    #19015167
    +1

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


  1. dadyjo
    21.08.2018 11:12
    #19015179
    -9

    «Как подготовиться к собеседованию в Google и не пройти его. Дважды» — А знаете как легко можно распознать таких гуманитариев? По крику: «Свободная касса!!!» :)


    1. dadyjo
      21.08.2018 12:18
      #19015541
      -3

      Гуманитарии негодуют!


      1. ZXZs
        21.08.2018 13:18
        #19015919
        +1

        Да, гуманитарии объявляют войну! Гуманитарии — это не только грузчики, технички и кассиры! Гуманитарии тоже люди!


        1. dadyjo
          21.08.2018 14:41
          #19016463
          -1

          Гуманитарии — обиженки!


        1. alexeykuzmin0
          21.08.2018 18:29
          #19017635

          Грузчики, технички и кассиры — тоже люди. Вообще все вокруг люди, за исключением тех, кто не люди.


        1. Graf54r
          22.08.2018 21:56
          #19022765

          Грузчики это же физики!


    1. Arris
      21.08.2018 20:42
      #19018117
      +2

      По своему опыту знаете? :)
      *ирония*


    1. forgotten
      21.08.2018 22:46
      #19018537
      +1

      А не пробовали читать текст прежде, чем искромётно шутить?


    1. bugdesigner
      22.08.2018 07:57
      #19019159

      По вашей логике, только гуманитарии не могут пройти собеседование в Гугл? Вот вы, например, работаете в Гугл или вы — гуманитарий?


      1. alexeykuzmin0
        23.08.2018 20:27
        #19026719

        Может, он может, но не хочет. Я, например, довольно долго относился к этой категории.


  1. dali
    21.08.2018 11:17
    #19015207
    +2

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


    1. nobodyhave Автор
      21.08.2018 11:20
      #19015229
      +1

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


      1. dali
        21.08.2018 11:22
        #19015237

        а где брали свободное время?


        1. nobodyhave Автор
          21.08.2018 14:00
          #19016201

          Вечерами, на выходных. Иногда на работе выпадало свободное время.


          1. Errandir
            23.08.2018 19:03
            #19026429

            А как к этому относились домашние?


            1. nobodyhave Автор
              23.08.2018 23:21
              #19027177

              Терпели и поддерживали ) У меня очень хорошие домашние.


        1. BalinTomsk
          21.08.2018 17:44
          #19017471

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


          1. TimsTims
            21.08.2018 20:16
            #19018011

            имплементировать

            Скомпилировать


    1. 0xd34df00d
      21.08.2018 18:19
      #19017599

      А оно вообще надо?

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

      С другой стороны, стоит делать то, что прёт, и тогда вопросов таких не возникнет. Меня в своё время очень радовал курсеровский курс по биоинформатике с Певзнером. Очень драйвово, садишься, зашариваешь, решаешь алгоритмические задачки, хотя всё био от моей практики ну очень далеко.


  1. ewgRa
    21.08.2018 11:27
    #19015257
    +1

    Ох… стоит ли оно того? если такие знания потом на практике не использовать — выветриваются быстро.

    Велик шанс что вас возьмут и дадут довольно рутиные задачи, где вообще не надо применять эти все знания… так что может оно и к лучшему?

    Но такое упорство заслуживает уважения.


    1. dimm_ddr
      21.08.2018 13:05
      #19015841

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


      1. nobodyhave Автор
        21.08.2018 14:01
        #19016207

        Вот прямо то, что хотел ответить )


      1. da-nie
        21.08.2018 18:08
        #19017559

        Откройте мне секрет: тут очень много пишут про нужность всех этих графов, деревьев, матриц, сортировок и преобразований.
        Я, правда, в специализированных конторах по разработке ПО не работал — я программы пишу в одиночку (потому что я просто инженер в НИИ, а не в IT-фирме). Пишу программ я много. Самых разных. И игры, и простенькие 3D-движки и чёрт знает, что ещё. Как для себя, так и по работе. Задач требуется решать массу. Кому это просто посчитать, а кому-то сложный комплекс нужен с большущим GUI. И вот никак я не могу понять, чем вы в IT-конторах занимаетесь, что вам нужны все эти деревья и сортировки? Ну правда, я давно заметил, что самое сложное в программе — это обеспечить интерфейс для маленького (по сравнению с обёрткой вокруг) модуля. Этот модуль и есть то, ради чего программа делалась. И в этом модуле могут быть все эти алгоритмы. Но он получает конкретные данные (это как фильтр в фотошопе, а вокруг него весь остальной фотошоп) и часто достаточно прост. Непростая вот вся остальная обвязка с проверкой ошибок, получением данных, реакцией на действия пользователя, автоматика. Есть, правда, «чистые программы» — там почти вся программа такой вот модуль. Но это специфическая задача автоматики. Так вот, я чего не понимаю-то: как так выходит, что у меня в ПО эти алгоритмы встречаются достаточно редко и самым сложным не являются, а послушать вас всех, так у вас кроме алгоритмов в программе, считай ничего и нет — остальное не существенное. И я этого нифига не понимаю. Расскажите, если не сложно, в чём тут фишка.
        Спасибо. :)


        1. nobodyhave Автор
          21.08.2018 18:23
          #19017613

          Я уже приводил в других темах пример. Продублирую тут.
          «И пример из личной практики. Человек, явно не понимающий ничего в сортировках, умудрился делать вставку в сортированную коллекцию за O((N^2)*lgN), вместо O(lgN). Что при размере коллекции 1000 элементов дает примерно 7 000 000 (7 миллионов, Карл) операций, вместо 7.»
          Графы — поиск пути почти в любой игре. Или на карте.
          Деревья — TreeMap из Java. Мне вот один человек на собеседовании доказывал, что это ненужная штука и можно отсортировать HashMap. Шутник.
          Матрицы — любая банальная операция в машинном обучении. Там сплошные матрицы.
          Т.е. шаг в сторону от GUI, и вот они, алгоритмы )


          1. da-nie
            21.08.2018 20:20
            #19018031
            +2

            Всё это замечательно, но мой вопрос не об этом. За всю мою практику мне пару раз потребовалось BSP-дерево (для думоподобного движка) и столько сортировка. Остальные задачи всего этого не требовали. Они требовали управления устройствами, работы с железом, обработки ситуаций автоматики, но никаких графов, деревьев и матриц (я имею в виду работу с разрежёнными матрицами и прочей экзотикой — обычные матрицы и кватернионы я использовал в математике) не требовалось совсем.


            1. nobodyhave Автор
              21.08.2018 20:36
              #19018089
              +2

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


              1. da-nie
                21.08.2018 21:00
                #19018173
                +2

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

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


                То есть, человек может накатать с нуля операционку (так бывает — не Windows, конечно, но вполне рабочую), сделать систему управления боеголовкой (так тоже бывает), накатать автоматику станка или высоконадёжного устройства с резервированием, но вот HashMap он не использует и не применяет. А уровень знаний почему-то остаётся неприемлем. Почему же? Что помешает открыть книжку и найти требуемое? Почему в инженерной практике не требуется значть вот прямо всё — есть справочники, есть пособия по проектированию. Вот не знаю я, как делать лопасти турбины. Открываю литературу и читаю: все расчёты есть. Так же и со схемотехникой. Нужен мне прецизионный усилитель — открываем, читаем, изучаем, применяем. Тогда что не так с IT? Я не понимаю. :)

                Вот, кстати, а где вы эти хэши используете? Я такое максимум в шахматной программе использовал для определения повтора позиций и не более.


                1. nobodyhave Автор
                  21.08.2018 21:36
                  #19018311
                  +1

                  Вот, кстати, а где вы эти хэши используете?
                  Да везде же. В Java всего два варианта Map: HashMap и TreeMap. Остальное завязано на них так или иначе. И если мне надо удобно хранить пару ключ-значение с доступом по ключу (разумно быстрым), то естественно я использую одну из них. И так как в среднем HashMap быстрее (если знать как его готовить), то использую я его. А TreeMap как раз в тех редких случаях, когда нужна сортировка по ключам.
                  Открываю литературу и читаю: все расчёты есть.
                  Вот вы читаете. А другой возьмет и запилит на production сервер в «горячее» место HashMap с кастомным объектом в качестве ключа и не переопределенной хэш функцией. Что сервер сделает от такого? Естественно «умрет», так как поиск в мапе деградирует с O(1) до O(N). А зачем ему читать доки? Он же где-то слышал, что HashMap быстрый.
                  И да, я видел на собеседовании людей, которые не знают что такое хэш и как он используется в HashMap, но при этом HashMap используют.


                  1. da-nie
                    21.08.2018 22:22
                    #19018463
                    +1

                    . И если мне надо удобно хранить пару ключ-значение


                    Вопрос был в том, для чего вам может понадобиться хранить пару ключ-значение и тем более делать это с хэшем? Два примера (оба связаны с анализом текста для интерпретации/компиляции) тут привели. Но это вряд ли распространённые задачи.

                    и запилит на production сервер


                    Давайте всё же без web (я не знаком с web и не занимаюсь им). Меня интересует обычный Си++ и прикладное ПО, запускаемое на ПК пользователей.


                    1. nobodyhave Автор
                      21.08.2018 23:06
                      #19018593

                      С хэшем чтобы быстрее, ибо правильно настроенный HashMap быстрее TreeMap, как минимум асимптотически.
                      Хранить пару ключ-значение например чтобы из списка в миллион пользователей (или сообщений, или отчетов или чего угодно) можно было быстро выдернуть искомое по ID. Например железяка (мы же не рассматриваем веб, пусть будет прямая связь по bluetooth) говорит, что пользователь 100500 изменил местоположение и присылает новые координаты. Почему не присылает все данные по пользователю? Потому, что они могут быть несколько мегабайт. Нечего забивать канал. Я беру HashMap, в который у меня все пользователи загружены при коннекте к железке, быстро выдергиваю пользователя, меняю данные и уведомляю пользователя через UI. Да, можно было хранить пользователей списком, но тогда бы мне пришлось просмотреть миллион пользователей (в худшем случае). И так каждый раз. А сообщения такого типа могут прилетать от каждого пользователя.

                      И да, это примерное описание реальной ситуации, с которой я сталкивался.


                      1. da-nie
                        21.08.2018 23:17
                        #19018625

                        Судя по всему, мне потребуется несколько переформулировать «без web». Правильнее будет: «без клиент-серверной технологии». Иначе сюда, действительно, сразу попадают все задачи поиска пользователя, а они и так очевидны, но совсем не интересны. Впрочем, может я сильно отстал, и алгоритмы так желанны у соискателей потому, что везде этот самый «web» с подобными задачами поиска пользователей?


                        1. nobodyhave Автор
                          21.08.2018 23:50
                          #19018723

                          Ну, тогда не из моей практики, но в принципе — написание любой IDE и почти любого текстового редактора. В IDE там и графы, и строки с подстроками и все что угодно. В текстовом редакторе соответственно работа со строками/подстроками.


                          1. da-nie
                            22.08.2018 09:03
                            #19019279

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


                          1. da-nie
                            22.08.2018 09:37
                            #19019419

                            Все эти ответы — всё не то. Как бы объяснить…
                            Вот смотрите: вы пользуетесь всеми этими строками, хэшами, стеками, очередями, деревьями и прочим. Почти всё из этого покрывается stl. Вы будете писать свой алгоритм сортировки только если у вас есть специфика в данных. Всё остальное время вы будете вызывать функцию из библиотеки. Зачем в этом случае вам помнить алгоритмы сортировок? Что это вам даст? Ничего. Та же история со всем остальным. Если вам понадобится балансировать дерево — найдёте и так, как это сделать. Искать подстроку в строке с максимальной скоростью — точно так же.
                            Далее, в программе всё это перечисленное составляет, наверное, столь малую часть, что непонятно, почему эта часть возведена в абсолют. Я вот об этом и спрашиваю: моя практика показывает, что сложность разработки ПО не связана с тем, что принято называть алгоритмами. Она связана с внутренней организацией, с общими алгоритмами работы ПО, с прозрачным взаимодействием между модулями, с предусматриванием возникающих ситуаций, но никак не с сортировками, поиском и прочим. Именно поэтому я и спрашиваю вас, что такое вы постоянно пишете, что у вас на первое место постоянно вылезает не архитектура ПО, а все эти стандартные алгоритмы? Вы отвечаете — мы ими ищем пользователей, строки и прочее. Неужели у вас вся программа — это бесконечный поиск с минимальной обработкой? У меня почему-то программы выглядят как автоматы с кучей состояний в зависимости от того, что хочет пользователь. Скажем, вот пользователь решил включить режим рисования. Отменяем всё незавершённое в предыдущем режиме, начинаем новый. Пользователь щёлкнул мышкой — запоминаем точку, предварительно пересчитав координаты из экранных координат в мировые с учётом масштаба и смещения системы координат. Пользователь продолжает дальше щёлкать мышкой и перемещать поле зажав другую кнопку мышки. Отслеживаем курсор и отрисовываем линию, соединяющую соседние точки между собой и всё остальное, уже нарисованное пользователем (простой список нарисованного есть). Пользователь замкнул фигуру. Проверяем, выпуклая ли она? Если да, заносим её в список с определением описывающего прямоугольника и позволяем рисовать дальше заново. Алгоритмы до сих пор так и не появились. Это примерно так работает у меня редактор карт. Конечно, можно захотеть странного в данном случае — разбить список готовых объектов на дерево для оптимизации вывода графики, но во-первых, даже если я это сделаю, то это составит крохотную часть программы, а во-вторых, пользователь физически не нарисует столько простых объектов, чтобы оно начало тормозить даже на P-233. Потому что пробежать список и выбросить всё, с координатами описывающего прямоугольника вне экрана очень быстрый процесс.


                            1. Neikist
                              22.08.2018 09:46
                              #19019451

                              Именно поэтому я и спрашиваю вас, что такое вы постоянно пишете, что у вас на первое место постоянно вылезает не архитектура ПО, а все эти стандартные алгоритмы?

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


                              1. da-nie
                                22.08.2018 09:52
                                #19019479

                                К тому же на бэкенде постоянно с этим сталкиваешься на самом деле,


                                Мне кажется, у нас разные Солнечные системы. :)


                                1. nobodyhave Автор
                                  22.08.2018 10:10
                                  #19019547

                                  Скорее всего, все сводится именно к этому )

                                  Пользователь замкнул фигуру. Проверяем, выпуклая ли она?
                                  А вот кстати и алгоритм. Из раздела Computational Geometry. Неважно, как мы это проверяете, но это алгоритм, готовый или самодельный.


                                  1. da-nie
                                    22.08.2018 10:22
                                    #19019597

                                    Не-а. :) Потому что, как все знают, вообще-то алгоритм — это просто порядок действий для достижения результата — то есть, абсолютно любая программа и есть алгоритм. А вот то, что понимают под алгоритмами нынче, это вполне чёткие фишки типа фишек из книги Рода Стивенса «Алгоритмы. Теория и практическое применение».


                                    1. alexeykuzmin0
                                      23.08.2018 20:35
                                      #19026745
                                      +1

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


                            1. tym32167
                              22.08.2018 11:08
                              #19019819

                              Из моей практики мне несколько раз помогало знание основ алгоритмов. Самое очевидное и частое где это пригождается — народ поголовно не понимает разницу между линейным поиском и поиском по хеш таблице. Только в прошлом году разгонял участок кода, который работал 30 минут из за большого количества линейных поисков (там надо было замапить одну сущность на другую, так вот бралось пооле из сущности 1 и лнейным поиском искалось поле из сущности 2). И после замены на словарик тот участок стал работать 3 секунды. Потому когда я собеседую людей, обязательно задаю вопрос про различие поиска по словарю и по списку.
                              Другой пример — однажды мы делали систему где важной частью была древовидная сущность — дерево с произвольным количеством дочерних узлов. Нам надо было ходить вверх\вниз, собирать множество и подмножество объектов, и прочее. Это, конечно, не rocket science, но поиск в ширину и глубину пришлось использовать.
                              Много было более мелких эпизодов, когда ты видишь неэффективный код и правишь его просто чтобы улучшить производительность — как то раз применял сортировку подсчетом, менял проверку наличия цифр в строке с регулярки на линейный поиск (почему все так любят регулярки? Они ж медленные. Откуда я это знаю? — из курса алгоритмов) и тд. Но, конечно, у меня не было ничего настолько сложного, чтобы пришлось прямо изобретать алрогитм. А писать свою сортировку слиянием это вообще зачем? Я не уверен, что олимпиадники в задачах пишут сортировки сами (только если это не смысл задачи), мне кажется это просто трата времени.
                              Я к тому, что писать алгоритмы каждый день может и не придется, но знание как они работают помогает писать более эффективный код.


                              1. da-nie
                                22.08.2018 11:24
                                #19019919

                                Спасибо. :) Да понятно, что кусочки любой использовал.

                                Я не уверен, что олимпиадники в задачах пишут сортировки сами (только если это не смысл задачи), мне кажется это просто трата времени.


                                Ну, на областной в 2000 году мы таким точно не занимались. Но вот решение японского кроссворда таки было. А что там на всероссийской и выше, тем более сейчас, я не знаю. :)


                                1. ohotNik_alex
                                  22.08.2018 16:42
                                  #19021495
                                  +1

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


                                  1. da-nie
                                    22.08.2018 17:12
                                    #19021653

                                    Я разве где-то говорил про незнание?


                                    1. ohotNik_alex
                                      22.08.2018 20:28
                                      #19022485
                                      +1

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


                                      1. da-nie
                                        22.08.2018 20:50
                                        #19022531
                                        -2

                                        вы же конечно знаете скажем перемножение Карацубы?


                                        Нет, не знаю. Я знаю что есть CORDIC (цифра за цифрой) для быстрых математических операций. А вообще, сопроцессор у нас чем занимается? Электричество только жрёт что ли? А оптический умножитель не хотите применить (да, если бы была задача на скорость и устройство сами бы проектировали, я бы на этапе создания железа бы уже задал ряд вопросов)? :) Есть и такое.

                                        В условиях ограничений по ресурсам (на мобильнике, например) кто-то малограмотный просто воспользовался бы стандартным алгоритмом из библиотеки и получил перерасход аккумулятора и расход времени.


                                        Мне кажется, вы шутите. У меня тут сложные вычислительные задачи (да, обсчёт модели гироскопа дорогая штука. А уж если ещё и фильтр Калмана добавить...) на микроконтроллерах работают с крошечным ОЗУ и смешными мегагерцами. А вы мне рассказываете про перерасход аккумулятора и расход времени на мобильнике?! Это которые многоядерные с частотами в пару ГГц? Там подсветка сожрёт больше, чем вы наоптимизируете. Да, собственно, работа сайтов на старом оборудовании прекрасно показывает всю вашу оптимизацию — они не работают на компьютерах, скажем, 2004 года. Не хотят-с. Тормозят вплоть до зависания.

                                        у вас будет стэк и задача в любой момент времени отдать какую-то минимальную на весь стэк величину. стек то получает элементы, то теряет. и как у гугла спросить есть ли что-то такое?


                                        Кстати, как вы это решали? Мне приходит в голову хранить поступающие значения в отсортированном связанном списке (сделав его обычной структурой с указателями на предыдущий и последующий элементы — т.е. без stl (чтобы указатели на элементы не менялись) ну и указатели на начало и конец завёл бы), добавляя вставкой элемент куда надо. А в стеке хранить указатель на элемент списка, убирая или вставляя его. Соответственно, начало списка и его конец всегда будут указывать на большее и меньшее число.


                                        1. ohotNik_alex
                                          22.08.2018 21:05
                                          #19022571
                                          +2

                                          > приходит в голову хранить поступающие значения в отсортированном связанном списке

                                          ого! вместо единичного времени вставки в стек вот так запросто перейдем к линейному времени(место-то надо найти). и правда… где 1 такт на вставку, там и секунду подождать можно (если стек не из 100 элементов, конечно). только вот как из стека потом вынимать-то… немножко конфуз с правилом FILO выходит.
                                          а решается это самым типовым алгоритмом с созданием дублирующего стека.

                                          > А вы мне рассказываете про перерасход аккумулятора и расход времени на мобильнике?!

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

                                          > У меня тут сложные вычислительные задачи (да, обсчёт модели гироскопа дорогая штука. А уж если ещё и фильтр Калмана добавить...)

                                          куда уж мне с 3 миллиардами финансовых операций в сутки 24/7 в swift-е и обязательно не в кластере… написать абы как и пусть банки в очереди ждут пока транзакция досчитается. (и такое в практике было)


                                          1. da-nie
                                            22.08.2018 21:13
                                            #19022595
                                            -1

                                            только вот как из стека потом вынимать-то… немножко конфуз с правилом FILO выходит.


                                            Так же. В стеке-то указатель на список. Из списка выбросить элемент пара пустяков.

                                            а решается это самым типовым алгоритмом с созданием дублирующего стека.


                                            А подробнее? Вот пришло число — вы его поместили в первый стек. А что со вторым стеком делать?

                                            куда уж мне с 3 миллиардами финансовых операций в сутки 24/7 в swift-е и обязательно не в кластере… написать абы как и пусть банки в очереди ждут пока транзакция досчитается. (и такое в практике было)


                                            И тормозит у вас, конечно, именно умножение чисел, да? ;) Вот эти самые 3 миллиарда финансовых операций в сутки, это сколько умножений в секунду требуется? Неужели, однотактный умножитель в ваш процессор почему-то не завезли? Просто сдаётся мне, вы оптимизировали то, что не требовало оптимизации. Или вам профайлер показал, что программа на умножениях застревает? Но судя по вашей специфике, это будет странно.


                                            1. ohotNik_alex
                                              22.08.2018 21:25
                                              #19022635

                                              вопрос с добавлением в отсортированный список не отпадает. золотое сечение тут использовать не получится — элементы лежат в памяти не подряд.
                                              это не HashMap и ткнуть в нужный элемент не получится. чтобы получить, скажем, 4й элемент придется обратиться к 1му, от него ко второму, от него к третьему и лишь потом получите нужное.
                                              а теперь представим список из 1_000_000_000 элементов и вы добавили какое-то число, равное max-1… можно идти домой — сегодня результата не будет.


                                              а если подробнее — просто рядом размещается стек с актуальным минимумом. вынимается элемент — минимум стирается и сверху оказывается новый. добавляется — создается новый элемент.
                                              это вот действительно самая типовая задача.


                                              И тормозит у вас, конечно, именно умножение чисел, да?

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


                                              1. da-nie
                                                22.08.2018 21:38
                                                #19022681

                                                вопрос с добавлением в отсортированный список не отпадает.


                                                Да, не отпадает.

                                                это возможно удивит, но систем, в которых виновата в тормозах только 1 операция почти нет.


                                                Профайлер часто показывает, что такие системы бывают. :) Но вот что умножение у вас виновато в тормозах, так это сильно вряд ли.

                                                но вот после чистки кода от таких вот «типовых» решений


                                                А если умножение вернуть стандартное, быстродействие у вас ухудшается?


                                                1. ohotNik_alex
                                                  22.08.2018 21:54
                                                  #19022755

                                                  А если умножение вернуть стандартное, быстродействие у вас ухудшается?

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


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


                                                  Профайлер часто показывает, что такие системы бывают

                                                  моя практика показывает, что 9 из 10 java-программистов пытаются профилировать приложение без включения спец режима на горячем..) хорошо если они тогда хоть что-то там найдут.
                                                  посмотрите лекции Паньгина из Однокласников для примера.


                                                  1. da-nie
                                                    22.08.2018 22:09
                                                    #19022805

                                                    общая идея была «будем считать каждый байт и такт».


                                                    До ассемблера с оптимизацией кэшей и оптимизаций предсказаний ветвлений вы, надо полагать, ещё не добрались? :) (шутка :) )

                                                    моя практика показывает, что 9 из 10 java-программистов


                                                    Я не пишу на java. Только Си и Си++. :) Поэтому проблемы java мне не ведомы.


                                                    1. ohotNik_alex
                                                      23.08.2018 06:08
                                                      #19023409

                                                      До ассемблера с оптимизацией кэшей и оптимизаций предсказаний ветвлений вы, надо полагать, ещё не добрались?

                                                      ну вообще-то до изучения исходников добрались.


                                                      Поэтому проблемы java мне не ведомы.

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


                                                      1. da-nie
                                                        23.08.2018 07:48
                                                        #19023513

                                                        ну вообще-то до изучения исходников добрались.


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

                                                        откуда вам знать, что не повторяете ту же ошибку и используете профайлер по максимуму его возможностей?


                                                        От профайлера типа Intel VTune мне (в Си++) нужно просто увидеть, где программа проводит большую часть времени во время работы и какая конкретно операция жрёт процессор больше всего. Что показывает профайлер для java — не в курсе.


                                                        1. ohotNik_alex
                                                          23.08.2018 15:25
                                                          #19025425

                                                          у меня не мобильник. всего лишь депозитарная система ЦБ, которые известные медиа ресурсы, банковские сервера… сидя на 1 месте 5 лет только потеряете квалификацию. это был простейший пример с мобильником, но ничуть не надуманный. просто обычно нормальная подготовка такова, что устройство значения особого не имеет.

                                                          > полагаю, для написания высокоскоростного приложения java не лучший выбор

                                                          предположение не верно. страшно удивитесь, но путем некоторых ухищрений и манипуляций Java может даже обогнать плюсы за счет более качественной оптимизации байт-кода. но это требует опять же знаний. а не книжек уровня 1го курса. плюс уж извините, но плюсы крайне неудобны в крупных проектах. бардак с именованиями, редкие обновления спек, множество велосипедов по причине отсутствия стандартных типовых библиотек для не слишком стандартных вещей. одни утечки памяти чего стоят — в проекте из нескольких тысяч файлов допустить подобное ничего не стоит. посетите что-нибудь из конференций jug.ru (для дотнетовцев тоже есть) — сильно удивитесь подходам в крупных компаниях.
                                                          как я вас понял — вы работаете без команды и обмена опытом нет. может быть в этом проблема? сходите на собеседование в крупную компанию — запомните на чем завалите собеседование.

                                                          сам лет 7 назад собеседовался в mail на позицию разработчика в skyforge. на вопрос о графах в итоге выдал бред, что «сейчас компьютеры настолько мощные, что знать этого не нужно».
                                                          провалил. выпросил книжки для самообучение. прочитал… до сих пор стыдно)))

                                                          > и какая конкретно операция жрёт процессор больше всего.

                                                          ну в том же Java профайлере операция может быть слишком высокоуровневой. то что там что-то написало — не значит ровным счетом ничего. например. не выйдет заглянуть внутрь for без бубна.
                                                          самое смешное, что далеко не все понимают, что профайлер «врет» чтобы программа не повисла из-за слишком пристального внимания.


                                                        1. 0xd34df00d
                                                          23.08.2018 16:38
                                                          #19025763

                                                          От профайлера типа Intel VTune мне (в Си++) нужно просто увидеть, где программа проводит большую часть времени во время работы и какая конкретно операция жрёт процессор больше всего

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


                                          1. da-nie
                                            22.08.2018 21:25
                                            #19022629

                                            Как ни странно, я нашёл эту задачу с решением. Понятно, как решается. Там, кстати, есть интересные варианты решения и без дублирующего стека (для целых чисел):

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

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

                                            public class MinStack {
    long min;
    Stack<Long> stack;

    public MinStack(){
        stack = new Stack<>();
    }

    public void push(int x) {
        if (stack.isEmpty()) {
            stack.push(0L);
            min = x;
        } else {
            stack.push(x - min); //Could be negative if min value needs to change
            if (x < min) min = x;
        }
    }

    public int pop() {
        if (stack.isEmpty()) return;

        long pop = stack.pop();

        if (pop < 0) {
            long ret = min
            min = min - pop; //If negative, increase the min value
            return (int)ret;
        }
        return (int)(pop + min);

    }

    public int top() {
        long top = stack.peek();
        if (top < 0) {
            return (int)min;
        } else {
           return (int)(top + min);
        }
    }

    public int getMin() {
        return (int)min;
    }
}


                                            1. ohotNik_alex
                                              22.08.2018 21:28
                                              #19022641
                                              +1

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


                                              1. da-nie
                                                22.08.2018 21:34
                                                #19022669

                                                Но заметьте. Двойной стек также не является лучшим решением в целых числах.
                                                Бывают задачи на несколько минут. Бывают на несколько дней. А бывают и на годы.


                                                1. ohotNik_alex
                                                  22.08.2018 21:47
                                                  #19022735
                                                  +1

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


                                                  1. da-nie
                                                    22.08.2018 22:06
                                                    #19022797
                                                    -1

                                                    Так я и не возражаю: «что-то где-то видел» — это прекрасно. Но помнить все эти реализации — увольте.


                                                    1. ohotNik_alex
                                                      23.08.2018 06:04
                                                      #19023393

                                                      а как вы предлагаете проверять, что человек не вызубрил названия алгоритмов, а именно понимает о чем речь? ла еще за каких-то пару часов собеседования. если вы понимаете как работает быстрая сортировка — вы ее хоть спросонья напишете.


                                                      1. da-nie
                                                        23.08.2018 07:51
                                                        #19023525

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


                                                        1. bay73
                                                          23.08.2018 13:56
                                                          #19025045

                                                          Угадайте, смогу я сейчас написать условия работы отсечений этого алгоритма? Не смогу.
                                                          Это как раз и является признаком того, что использовали вы алгоритм без понимания того как он работает.


                                            1. ohotNik_alex
                                              22.08.2018 21:42
                                              #19022709

                                              с натуральными числами вроде работать будет. с отрицательными не уверен, но поверю.


                                  1. alexeykuzmin0
                                    23.08.2018 20:40
                                    #19026761

                                    вот пример
                                    Конкретно в этом примере как раз все получится: по запросу в Google «stack with minimum» у меня на первой странице все ссылки по теме. Даже код есть с просьбой провести review.


                                    1. ohotNik_alex
                                      23.08.2018 21:58
                                      #19026997

                                      но вот приведенный выше код, кстати, не надежен.
                                      уложу туда 10 значений -1*max_long и получу переполнение. т.е. теоретически вспомогательный функционал крашит основной.


                                1. alexeykuzmin0
                                  23.08.2018 20:39
                                  #19026755

                                  что там на всероссийской и выше
                                  Здесь есть задачи всероссийской олимпиады.


                        1. bay73
                          22.08.2018 09:33
                          #19019403

                          Задача поиска атрибутов по ключу возникает практически в каждой Enterprise системе неоднократно. Web тут совершенно не причем.


                      1. vedenin1980
                        21.08.2018 23:32
                        #19018675
                        +1

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

                        Основы понимания алгоритмов нужно многим (как и скажем основы баз данных), но вот умение без инета написать любой алгоритм поиска в графе или сортировки — не так часто нужно. ИМХО.

                        Это как вопросы вроде вспомнить восьмую нормальную форму БД — да есть 0.01% программистов, которые без нее работать не смогут, но остальные могут работать с базой не вспоминания о нормальных формах.


                        1. fukkit
                          21.08.2018 23:39
                          #19018695

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


                        1. bay73
                          22.08.2018 09:34
                          #19019409

                          А кто и где требует написания алгоритма по памяти?


                          1. da-nie
                            22.08.2018 09:40
                            #19019427

                            Так в статье об этом.

                            Задача была на графы. Я быстро понял, что надо сделать, но выбрал не тот алгоритм. Когда начал писать код осознал это и переключился на другой вариант, который и дописал. Интервьюер задал несколько вопросов на тему сложности алгоритма, спросил, можно ли быстрее. Я как-то затупил и не смог. На этом время вышло и мы распрощались. Потом, минут через 10 до меня дошло, что вместо алгоритма Дейкстры, который я использовал, конкретно в этой задаче можно было бы использовать поиск в ширину, и это было бы быстрее.


                            Следовательно, автор сидел и реализовывал сам алгоритм.


                            1. nobodyhave Автор
                              22.08.2018 10:17
                              #19019573

                              Написание алгоритма не отличается от написание кода в целом. Меня попросили решить конкретную задачу. У меня был выбор — написать свой велосипед или использовать что-то готовое. Если знаешь что-то готовое, то это гораздо быстрее. Не обязательно помнить детали. Что есть алгоритм Дейкстры? Обычный жадный алгоритм. Берем точку, смотрим расстояние до соседей и запоминаем. Берем ближайшего соседа, смотрим расстояния от него до соседей и обновляем путь до исследованных точек, если он стал короче. Повторять пока не посмотрим все точки. Написать под это код дело техники.


                            1. bay73
                              22.08.2018 16:46
                              #19021531

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


                              1. da-nie
                                22.08.2018 17:14
                                #19021663

                                Судя по фрагменту, требовалась именно реализация на доске. Программа. А это означает как раз и тонкости реализации в том числе.


                            1. alexeykuzmin0
                              23.08.2018 21:00
                              #19026825

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


                              1. Druu
                                24.08.2018 08:48
                                #19027849
                                -1

                                Не уверен, что вообще возможно понимать алгоритм Дейкстры, но не мочь его написать.

                                Да легко можно, понимается он ведь в предметных терминах, а формулируется — в терминах ЯП, причем обычно в тех терминах "чтоб производительно". Если я цикл в явном виде последний раз год назад писал — то естественно будут проблемы с тем, чтобы выразить алгоритм в рамках требуемых примитивов, если же я начну писать как удобно — то это будут всякие свертки, чистые функции и прочая иммутабельность. Мне, наверное, проще будет рекурсивную схему под дийкстру подобрать, чем записать его классически :)


                      1. Druu
                        22.08.2018 12:05
                        #19020145

                        Да, можно было хранить пользователей списком, но тогда бы мне пришлось просмотреть миллион пользователей (в худшем случае).

                        Пользователей-то можно так и сортированным массивом хранить. Для миллиона пользователей, наверное, и пошустрее хеша получится (хотя тут уже зависит от того, что за хеш)


                        1. nobodyhave Автор
                          22.08.2018 13:32
                          #19020521

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


                  1. Zoolander
                    22.08.2018 06:03
                    #19019021

                    Мне кажется, с мэпами вы отклонились в сторону. Понять, где и когда надо применять TreeMap и HashMap — можно меньше чем за час, просто прочитав их описание. В статье же речь идет о куче алгоритмических задач, и умении их быстро решать, что уже намного более сложно и никак не достигается прочтением, только практикой.


                  1. Druu
                    22.08.2018 12:02
                    #19020117

                    Вот вы читаете. А другой возьмет и запилит на production сервер в «горячее» место HashMap с кастомным объектом в качестве ключа и не переопределенной хэш функцией.

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


                    Что сервер сделает от такого? Естественно «умрет», так как поиск в мапе деградирует с O(1) до O(N). А зачем ему читать доки? Он же где-то слышал, что HashMap быстрый.

                    Вообще, согласитесь, если ваш хеш деградирует на дефолтной хеш-функции до линейного, то это не хеш, а хрень.


                    1. nobodyhave Автор
                      22.08.2018 13:43
                      #19020563
                      +1

                      Вообще, согласитесь, если ваш хеш деградирует на дефолтной хеш-функции до линейного, то это не хеш, а хрень.
                      Дак на то она в Java и дефолтная, просто шестнадцатеричный идентификатор объекта.
                      Так может усилия стоит направить на то, чтобы определить тех людей, которые «читают», а не тех, что знают двадцать вариантов сортировки?
                      Ну, и то и другое полезно. Каждый ли разработчик Java знает, что при сортировке массивов примитивов используется вариация быстрой сортировки, а при сортировке массивов объектов используется вариация сортировки слиянием. И для скольких из них будет сюрпризом, что быстрая сортировка может деградировать до O(N^2), а при сортировке объектов им понадобится дополнительно O(N) памяти?


                      1. TheKnight
                        22.08.2018 15:19
                        #19021017

                        А что вы подразумеваете под быстрой сортировкой?
                        Каноничную сортировку Хоара с одним опорным элементом?
                        Или все вариации?


                        1. nobodyhave Автор
                          22.08.2018 15:48
                          #19021161

                          Java использует DualPivotQuickSort. Подробнее можно посмотреть тут.


                          1. TheKnight
                            22.08.2018 16:21
                            #19021363

                            Перечитал ваш пост, перечитал свой вопрос, понял что задал вопрос совершенно не про то, про что надо.
                            Хотя и ответили вы тоже не на тот вопрос, который я задавал :)
                            P.S.: Про то, что в Java STL используется быстрая сортировка с двумя опорными элементами знал и так, равно как и про TimSort.


                  1. alexeykuzmin0
                    23.08.2018 20:31
                    #19026729

                    так как в среднем HashMap быстрее
                    Не оспаривая тот факт, что обычно это так, хочется дополнить. В случае TreeMap нам нужно алфавитное сравнение элементов, которое может работать быстрее, чем вычисление хеш-функции. Например, если у нас не очень большой Map из длинных массивов, то TreeMap будет на случайных данных работать быстрее, поскольку сравниваем мы до первого не совпавшего элемента за O(N), где N — размер Map, а хеш считаем — за O(M), где M — размер массива. Помнится, на каких-то олимпиадах я с этим сталкивался.


                    1. nobodyhave Автор
                      23.08.2018 23:31
                      #19027207

                      Не совсем понял, но отвечу на то, что понял. Если массивы это ключи, то это уже в принципе плохо. Если значения, то без разницы.
                      В случае идеального HashMap, мы имеем О(1) как на вставку, так и на доставание. Т.е. при вставке мы считаем хэш (если он уже не посчитан для этого объекта) и кладем в пустую ячейку. При доставании считаем хэш (если не посчитан) и делаем 1 вызов equals.
                      В случае с TreeMap equals будет вызываться в каждом узле, чтобы понять куда идти, т.е. lgN раз.

                      Итого, если даже массив из М элементов это ключ, а в мапах по N элементов, для HashMap положить это M и достать 2*M + N, а для TreeMap положить это M*lgN, и достать аналогично.


                      1. Druu
                        24.08.2018 08:53
                        #19027863

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


                        1. nobodyhave Автор
                          24.08.2018 11:38
                          #19028627

                          Нет, не забыл, я написал «идеальный HashMap». Т.е. коллизий у нас нет. Но это да, сферический конь в вакууме.
                          А вот в дереве элемент всегда кладется как лист. А уже потом мы начинаем балансировать дерево. Т.е. lgN у нас всегда.
                          Да, я прекрасно понимают, что если нужна гарантия, то мы берем дерево, так как в случае HashMap гарантия это O(N).


                1. saluev
                  21.08.2018 21:39
                  #19018321
                  +3

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


                  1. da-nie
                    21.08.2018 22:18
                    #19018453

                    А вот если отвлечься от Web?


                    1. saluev
                      21.08.2018 23:05
                      #19018591

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


                      1. da-nie
                        21.08.2018 23:21
                        #19018635

                        Потому что я не занимаюсь web и, уверен, масса людей тоже им не занимается. И мне интересно, для чего всем им эти самые алгоритмы сдались и почему они их возводят в абсолют, словно это самое-самое главное в написании ПО.
                        Да, в свете нового комментария от nobodyhave, мне следует уточнить, что задача авторизации пользователя любого прикладного ПО не представляет для меня интереса, как очевидная задача поиска. Меня не она интересует. :)


                        1. Neikist
                          22.08.2018 09:41
                          #19019433

                          По моему сейчас 90% всех программистов это фронтэнд вебовский, бэкенд какой нибудь, да мобилки. Притом что понимание структур данных и алгоритмов везде желательно.


                    1. littorio
                      22.08.2018 15:30
                      #19021063
                      +2

                      Ну вот у меня не Web, у меня HFT и всякий онлайн трейдинг. Тоже постоянно поток ордеров, которые надо распихивать по фин. инструментам. Инструменты, соответственно, в хэшмапах.

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


                      1. da-nie
                        22.08.2018 17:16
                        #19021673

                        Ну вот у меня не Web, у меня HFT и всякий онлайн трейдинг.


                        По-моему, это задачи одно уровня: клиент-сервер. :)
                        У меня таких задач практически нет, потому я про них мало что знаю.


                        1. littorio
                          23.08.2018 10:48
                          #19024179

                          Кроме адаптеров, писал симуляторы рынков — везде то мапы, то сеты и перфоманс. Писал кодеки (с биржевых протоколов) — однажды аж Trie использовать пришлось. Кеширование строчек и т.п. так постоянно. Писал анализаторы биржевого трафика, скрипты для разбора логов и т.п. — тоже постоянно map'ы. Как вообще без hashmap'ов программировать?!


                  1. da-nie
                    21.08.2018 22:25
                    #19018469
                    +1

                    где нужно управлять железом


                    Так это почти любая контора, где это самое железо есть. :)
                    А вот интересно, например, такое слово, как «QNX» у вас какие-либо ассоциации вызывает? :) Это всё из того же мира автоматизации оборудования.


                1. FlashManiac
                  23.08.2018 14:43
                  #19025227

                  Попытаюсь ответить зачем спрашивают на интервью алгоритмы и структуры данных. Во время интервью открывается возможность увидеть как человек мыслит и каким образом он решает задачу и как он общается с коллегами. К тому же задачи на алгоритмы и структуры данных могут быть отсортированы по сложности. Это дает возможность спросить сначала что то простое а потом усложнять — тем самым проверяя уровень профессионализма кандидата.

                  На практике (гейм дев) мне лично постоянно приходится использовать те или иные алгоритмы. Из последних — «поиск оптимально пути в графе(пришлось модифицировать алгоритм Дейкстры)» или «поиск пересечений пуль и объектов(просто перебор был жутко медленный)». Так же надо знать очень хорошо геометрию — матрицы и вектора. но в большинстве случаев уже есть библиотеки или движки которые это делают. Нет смысла пилить свой велосипед. Но в гейм деве есть ограничения производительности и весе приложения — поэтому проще сделать какое то упрощенное быстрое решение чем использовать супер навороченную библиотеку. И вот тут включается мозг ) Надо проанализировать существующие решения выбрать самое оптимальное или скомбинировать и потом доработать его.

                  Если например взять другую область где надо набросать UI. То там конечно не будет этих алгоритмов. Там другие задачи. Возможно вы решаете другие задачи которые редко требуют алгоритмы. Либо используете нативные средства языка или библиотеки. И вам не сильно важно что бы это был быстро.


          1. cebka
            21.08.2018 20:38
            #19018099
            +3

            Простые бинарные деревья на самом деле бывают редко нужны из-за специфики их работы и адресации. Хотя хороший slab allocator может эту проблемку порешать, да. А так hash + vector зачастую оказываются быстрее в реализации, когда внезапно нужно иметь упорядоченный хеш. Знание алгоритмов — это хорошо, бесспорно, но при наличии интернета достаточно умения найти подходящий алгоритм. Другой вопрос — возникнет ли такое умение, если нет базовых знаний этих самых алгоритмов...


            1. da-nie
              21.08.2018 21:06
              #19018195

              А вот зачем вам хэш вообще? :)


              1. tyomitch
                21.08.2018 21:16
                #19018227

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


                1. da-nie
                  21.08.2018 21:25
                  #19018261

                  Годится? :) Я, может, ошибаюсь, но мне кажется, что написание компилятора весьма большая редкость. Спишем на вашу уникальность. :)


              1. cebka
                21.08.2018 21:33
                #19018295
                +2

                У меня была такая задача, когда я писал удобный (как минимум для себя) язык конфигов libucl — https://github.com/vstakhov/libucl. И там одним из важных свойств была возможность выводить конфиг после парсинга в как можно более близком к оригиналу виде (в том числе и порядок ключей объекта). Ну и производительность была тоже важна, да. Ну и в моем основном проекте Rspamd такая задача тоже встречалась. Если же нужна сортировка элементов, то такой "хеш с порядком" работает только в случае read-most структуры, иначе, конечно, дерево.


              1. Danik-ik
                22.08.2018 08:39
                #19019229

                Вы, кажется, упорно пытаетесь доказать, что хэш-таблицы нужны только веб-деву и небожителям?
                Потребность в алгоритмах и структурах зависит не только от конечной макрозадачи, но и от архитектурного подхода.
                Пример: приложение на дельфи7, которое формирует sql запрос, выполняет его, превращает в файл одним из десятков заложенных способов, отправляет. И таких действий в приложении сотни.
                Легаси содержало что-то вроде:
                AdoQuery1.sql.add(Format(…
                И таких от 3 до 30 строк на запрос. А потом outfile.lines.add('node' + encode(adoqwery1.fieldbyname('foo').asstring) + '/node');
                Сопровождаемость отсутствует как класс.
                Логично вынести шаблоны запросов в ресурсы. Ресурсы адресовать по имени. И чтобы каждый раз не расшифровывать (запросы в ресурсах зашифрованы) — кэшировать. Самое место для хэш-мэпа строка-строка.
                А этапы отдельных операций, настроечные параметры — были в харрррдкоде и дельфи-формах, а теперь объявляются декларативно, в массиве константных объектов, и адресуются по имени.
                Приложение, заметьте, не поменялось в смысле цели. Но затраты труда на сопровождение и доработку снизились ну просто феерически. Прежде всего — из за введения абстракций с косвенной адресацией элементов по именам.
                А начальник, который создал исходный вариант, фигачит всё по-старому и в ус не дует. Ему-то хеш-мапы ни к чему, да… И даже всё работает, и бизнес-цели реализуются.


                1. Whuthering
                  22.08.2018 09:03
                  #19019283

                  Большая часть того, что вы описали, относится скорее к рефакторингу и понимаю «чистого кода». Что, по моему мнению, очень важно, но к «алгоритмам в computer science» отношения практически не имеет.
                  И здесь нужно заметить, что для того, чтобы сделать описанное вами, нужно просто примерно представлять, как в используемой платформе происходит работа со строками, что вообще такое хэш-мапы, что они умеют и в каких случаях их выгодно использовать по сравнению с другими вариантами. Еще раз: достаточно просто иметь об этом представление, а не уметь писать с закрытыми глазами реализации хэш-функций для разных типов данных, имплементить в уме на базе них таблицы с открытой адресацией, и т.д.
                  Иными словами «примерно представлять что это и как оно работает» и «уметь изобрести велосипед на доске» это разные вещи. Вы говорите про первое. В статье (что и вызывает недоумение у многих комментаторов) про второе.


                  1. Danik-ik
                    22.08.2018 18:55
                    #19022143

                    А теперь представьте, что вы хотите нанять работника. И знаете себе цену, и она высока. Вы выберете того, кто "и так справляется", того кто "умеет пользоваться" или того, кто "так хорошо понимает, что потенциально и улучшить может"?


                    1. Druu
                      23.08.2018 04:47
                      #19023323

                      И знаете себе цену, и она высока. Вы выберете того, кто "и так справляется", того кто "умеет пользоваться" или того, кто "так хорошо понимает, что потенциально и улучшить может"?

                      Вы же понимаете, что описанное в статье — как подготовка к экзамену. Сдал и забыл?


                      1. nobodyhave Автор
                        23.08.2018 10:18
                        #19024015

                        Не-не. Это как ездить на велосипеде ) Если научился решать задачки, то это останется. Да, забудутся детали, но общий навык никуда не денется, особенно, если все равно пишешь код каждый день.
                        И восстановить навык при необходимости займет максимум 1-2 месяца, тогда как получить его с 0 потребовалось 1.5 года.


                        1. Druu
                          23.08.2018 13:20
                          #19024937

                          Не-не. Это как ездить на велосипеде ) Если научился решать задачки, то это останется.

                          Ну, не знаю. Я не раз ловил себя на том, что помню, что задача Х решается неким хитрым методом, но при этом самого метода — не помню. Потому что дело было года 3 назад.


                          1. bay73
                            23.08.2018 14:00
                            #19025057

                            :)
                            Для пятилетнего ребёнка умножение — «хитрый метод» для быстрого подсчёта. Для третьекласника решение задач с помощью уравнения — тоже «хитрый метод», который они не помнят.


                            1. Druu
                              23.08.2018 15:32
                              #19025469

                              Нет, ни то ни другое хитрым методом не является, т.к. в обоих случаях — это вполне алгоритмизируемая штука.
                              А вот когда вы ОДУ, при помощи хитрой замены решаете, приводя к некоторому виду, в котором оно уже решается при помощи алгоритма — это как раз то самое. Потому что замена ниоткуда не следует и не выводится (если только вы не придите к разделяемым переменным через группы Ли), никакой логики в ней нет.
                              Именно в этом смысл хитрости метода — в его логической невыводимости и неалгоритмизируемости. Вы либо его знаете, ну, как наизусть, либо вам везет, и он приходит в голову при переборе.
                              С-но если он в голову пришел — и вы его потом забыли, то тот факт, что вы его когда-то использовали, вам уже ничем и не поможет. И никакое понимание не поможет, потому что понимать там банально нечего.


                              1. bay73
                                24.08.2018 10:22
                                #19028233

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


                                1. Druu
                                  24.08.2018 10:25
                                  #19028247
                                  -2

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

                                  Вы, видимо, не поняли. Смысл хитрого метода именно в том, что ничего глубокого в его основании не лежит. Иначе бы он не был хитрым.


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


                                  1. bay73
                                    24.08.2018 10:38
                                    #19028305

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


                                    1. Druu
                                      24.08.2018 10:40
                                      #19028317

                                      Если вы (или я) не знаете, что лежит в основании хитрого метода, то это не значит, что основание отсутствует.

                                      Если никто не знает — значит основание отсутствует.


                      1. Danik-ik
                        23.08.2018 13:22
                        #19024947
                        +1

                        Вы же понимаете, что при найме не проверять соискателя на соответствие именно Вашим критериям профессионализма (которые могут формироваться и на основании баланса спроса и предложения, кстати, помимо собственно "разумной достаточности") — это за не то, что обычно делают адекватные люди?


                1. da-nie
                  22.08.2018 09:06
                  #19019295
                  -1

                  Да нет, вопрос был не в том…


        1. alexeykuzmin0
          21.08.2018 18:40
          #19017673

          Очень часто бывает нужно знать асимптотику работы стандартных алгоритмов и структур данных. Грубо говоря, чтобы не использовать List там, где нужен произвольный доступ, тем самым, сэкономив O(N). Еще раз в сто лет бывает нужно реализовать какой-нибудь алгоритм в местном SDK, причем очень желательно сделать это оптимально и обобщенно (например, многие не знают, что обход в ширину, обход в глубину, алгоритм Дейкстры и алгоритм А* — это, по сути, один и тот же алгоритм). Ну и на каждом собеседовании спрашивают, так что знание алгоритмов позволяет получить больше офферов, из которых проще выбрать более вкусный (особенно если все эти офферы есть одновременно — они могут торговаться между собой, избавляя вас от необходимости торговаться с компанией).


          1. da-nie
            21.08.2018 20:24
            #19018053
            +1

            Собеседование — вопрос отдельный. Меня интересовало, что вы все такое программируете (чем занимаетесь), что используете тот же обход дерева в ширину? Вот что? В моей практике гораздо чаще встречаются задачи уровня разобраться с работой с технологией (например, с DirectShow, с сокетами, с портами, с написанием драйвера, да с чем ещё угодно), чем делать обход чего либо.
            Правда уточню — я пишу на Си и Си++. И не для Web.


            1. alexeykuzmin0
              21.08.2018 20:36
              #19018091

              что вы все такое программируете (чем занимаетесь), что используете тот же обход дерева в ширину?
              В такой постановке вопроса — в 99.9% случаев ничего. Еще в 0.1% случаев — дописываю во внутреннюю SDK какую-нибудь ранговую эвристику в СНМ или что-нибудь такое. Оно потом будет использоваться везде и всеми.
              Но помимо этого, я каждый день решаю, что мне использовать — LinkedList или ArrayList, и мне важно не ошибиться в этих решениях.
              PS: А поскольку мне все же своя рубашка ближе к телу, для меня лично в знании алгоритмов и структур данных важнее всего возможность получить более вкусные офферы.
              В моей практике гораздо чаще встречаются задачи уровня разобраться с работой с технологией (например, с DirectShow, с сокетами, с портами, с написанием драйвера, да с чем ещё угодно), чем делать обход чего либо.
              Правда уточню — я пишу на Си и Си++. И не для Web.
              В моей тоже. Я, правда, тоже пишу в основном на C и C++ и не для Web.


              1. da-nie
                21.08.2018 21:05
                #19018193
                +4

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


                Следовательно, причина распиаренности алгоритмов в том, что их зачем-то спрашивают те, кому они не нужны. :)


                1. alexeykuzmin0
                  21.08.2018 21:10
                  #19018207
                  +1

                  Ну да. Я человек маленький, смотрю, какие навыки ценятся на рынке, и пытаюсь их получить и продемонстрировать. Менять глобальные тренды — это пока что, увы, не про меня.


                1. tyomitch
                  21.08.2018 21:21
                  #19018247
                  +1

                  Пару месяцев назад здесь была статья от профессионального собеседователя с тезисом «из всего того, что можно уместить в получасовое-часовое собеседование, именно навыки решения алгоритмических задач лучше всего коррелируют с будущей эффективностью сотрудника».
                  Т.е. там не причинно-следственная связь, а эмпирически установленная закономерность.


                  1. da-nie
                    21.08.2018 21:33
                    #19018291

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

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


                    1. grinCo
                      21.08.2018 22:55
                      #19018567

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


                      1. da-nie
                        21.08.2018 22:59
                        #19018577

                        Так я не против. :)
                        Но я не вижу прикладной их ценности. Это сродни олимпиаде по математике. И я полагаю, что как шахматы развивают только шахматы, то и алгоритмы только сами себя и развивают в мышлении. Но сложность программы не определяется этими самыми алгоритмами. В ПО Шатта вряд ли есть эти самые алгоритмы, а сложность этого ПО ужасающая.


                        1. grinCo
                          22.08.2018 01:27
                          #19018847

                          А есть исследования, что шахматы развивают только шахматы?
                          Я где-то читал исследования, что люди играющие в шахматы значительно успешнее не играющих. Там было про уровень дохода и образования. Попробую найти вечером.
                          Как позиционируется — шахматисты развивают способность просчитывать и дисциплину. Для тех кто думает что это легко, попробуйте рассчитать хотя бы на 5 ходов вперед все возможные ходы на каждом ходе. Это несложно, но нужна самодисциплина.
                          Хотя я лично думаю, что люди играющие в шахматы уже заведомо были умнее других и росли в других условиях.


                          1. grinCo
                            22.08.2018 02:17
                            #19018891

                            Нагуглил что-то.
                            www.ncbi.nlm.nih.gov/pmc/articles/PMC4126200
                            www.sciencedirect.com/science/article/pii/S0160289616301593


                          1. WinPooh73
                            22.08.2018 03:26
                            #19018923

                            Да, в случае с шахматами — это явно отношение корреляции, а не причинности.


                          1. Zoolander
                            22.08.2018 06:16
                            #19019053

                            есть такое исследование, называется «шахматные программы»
                            сколько ни пытался, не смог в них ни текст набрать, ни таблице посчитать

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


                            1. grinCo
                              22.08.2018 06:21
                              #19019057

                              Вы подменяете развитие интеллекта, дисциплины в человеке программой для игры в шахматы?


                      1. fukkit
                        21.08.2018 23:22
                        #19018643
                        +3

                        Если человек смог осилить алгоритмы это говорит о том, что он более менее умен, мотивирован и усидчив.

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

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


                        1. grinCo
                          22.08.2018 01:21
                          #19018843

                          Если человек рассортировал вручную 1 тонну гречнево-рисовой смеси это говорит о том что он глуп или золушка.


                          1. Zoolander
                            22.08.2018 06:18
                            #19019055

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


                    1. alexeykuzmin0
                      23.08.2018 21:10
                      #19026839

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


            1. agentx001
              21.08.2018 22:49
              #19018549

              Я вот недавно для себя писал игровой движок гексагональный — намучался с алгоритмами когда делал поиск пути.


              1. da-nie
                21.08.2018 22:53
                #19018561

                Но я правильно понимаю, что этот поиск пути махонькая часть движка?
                Я-то ведь чего спрашиваю? Эти алгоритмы подаются как первостепенной важности вещь. Но моя практика показывает, что они применяются в прикладном в очень ограниченных объёмах (если вообще применяются), а основная сложность ПО вовсе не в алгоритмах, а скорее, в архитектуре и обеспечении прозрачного взаимодействия десятков/сотен/тысяч компонентов.


            1. 0xd34df00d
              21.08.2018 23:44
              #19018709
              +1

              Делал оптимизатор для самодельного компилятора — бегал по графу.

              Делал упрощение выражений — бегал по графу и обмазывался кодекартовыми квадратами на графах.

              Искал дубликаты в большой базе — делал блумфильтр (и оценивал вероятность false positives).

              Сейчас в порядке хобби делаю биндинги для кланга — думаю, как бы поизящнее и повыразительнее выражать запросы по AST и по data flow. Там много чего алгоритмического тоже вылезет, думаю.

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


              1. da-nie
                22.08.2018 09:09
                #19019309

                Я половины написанных слов не знаю. :)


              1. muove
                22.08.2018 13:44
                #19020571

                А зачем писать свой компилятор? (я далек от чистой разроботки, просто для интереса в каких случаях это требуется)


                1. tyomitch
                  22.08.2018 13:50
                  #19020613

                  Ответы могут быть от традиционных («для нашего устройства выгоднее создать свой контроллер со своей ISA и своим компилятором, чем лицензировать существующие») до хайповых («пишем компилятор для смарт-контрактов в новом блокчейне»).


                1. 0xd34df00d
                  22.08.2018 16:46
                  #19021533

                  Реализовывал DSL для, собственно, некоторой предметной области.


              1. tyomitch
                22.08.2018 20:55
                #19022545

                думаю, как бы поизящнее и повыразительнее выражать запросы по AST и по data flow

                Не знаю, какие именно запросы и как именно надо выражать, но вроде же в llvm есть встроенные средства для паттерн-матчинга по поддеревьям?


                1. 0xd34df00d
                  22.08.2018 21:09
                  #19022587

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


            1. Neikist
              22.08.2018 09:50
              #19019463

              Серьезно? Обход дерева даже мы в 1с периодически используем, правда из за того что в стандартной библиотеке это не реализовано))


              1. da-nie
                22.08.2018 09:58
                #19019501

                … и этот обход и есть суть всей программы. Так? :) Или этот обход — кусочек вспомогательного кода и только? Поймите, я не говорю, что это не нужно использовать, я не понимаю, почему именно вот эта, на мой взгляд, очень незначительная часть ПО, подаётся как суть всего ПО. Вот почему?


                1. fukkit
                  22.08.2018 10:30
                  #19019627
                  +1

                  Давайте я отвечу на ваш вопрос)

                  Программирование — это, во многом, искусство. Создание сложной сущности из ничего. Программист, подобно Творцу, создает упорядоченную вселенную из хаоса равновероятных единиц и нулей.

                  Некоторые части любого искусства могут быть формализованы.
                  Всегда есть пытливые умы, которые глядя на художника скажут: «ага! ты не просто творишь, братец! Ты делаешь два мазка слева-направо, а потом один вертикальный, и вот так вот подрезаешь!». Это научные работники, их хлебом не корми — дай понавыдвигать гипотез и научным методом потыкать прекрасное со всех сторон.
                  Когда толпа научных работников собирается вместе, самые правдоподобные гипотезы они признают теориями и записывают их в монографии, затем в учебники.
                  Таким образом, эти трудолюбивые жучки помогают превращению искусства в технологию.
                  Бизнесу плевать на искусство, ему нужна технология. Она даёт возможность привлекать к производству не только талантливых художников, но и индийских маляров за еду, что весьма позитивно сказывается на финансовой стороне вопроса (качество, по большому счету, никто никому не обещал, не просит и не ждёт).

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

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

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


                  1. nobodyhave Автор
                    22.08.2018 10:39
                    #19019689

                    Экий интересный подход )
                    А человек, который докажет, что P = NP маляр или художник? Он же кроме алгоритмов ничего не знает.
                    А мяляр, который может снизить стоимость издержек для бизнеса в 10 раз, заменив 100 строчек кода достоин называться художником, или не очень?


                    1. da-nie
                      22.08.2018 10:59
                      #19019785

                      Знаете, в моей практике в проекте с реальным устройством участвуют и математики (так как теория работы устройства требует построения математической модели). Думаю, с разработкой быстрого алгоритма та же фигня — для них нужны тоже математики. Доказать N=NP — разве это не математическая головоломка? Сдаётся мне, что там не одну диссертацию по этим алгоритмам защитили.

                      А мяляр, который может снизить стоимость издержек для бизнеса в 10 раз, заменив 100 строчек кода достоин называться художником, или не очень?


                      Здесь год назад был человек с ником idot, так вот, он писал, что он как-то ускорил скорость корректного «чистого» кода (на паттернах и агалогичных вещах) с часу до 5 минут, выкинув все эти шаблонные компоненты. Это, я так понимаю, и есть художественный подход. А нехудожественный, надо полагать, описан в статье «архитектурные астронавты». :)


                  1. da-nie
                    22.08.2018 10:51
                    #19019731

                    Просто шикарно! :)


                1. Neikist
                  22.08.2018 11:45
                  #19020021

                  Это небольшой кусочек, но если не знать как его сделать — можно сделать дичь.


                  1. da-nie
                    22.08.2018 11:53
                    #19020071

                    Так фишка в том, что это относится ко всей программе целиком:

                    «Вы печатаете на клавиатуре заклинание, и вот экран дисплея оживает, показывая объекты, которых не было и могло не быть никогда
                    . Но если хоть один символ, один пробел в магической формуле не находится строго на своем месте, волшебство не работает.»

                    В сложной системе, если она сделана абы как, точно так же вы просто утонете в концепциях и взаимосвязях между объектами задолго до того, как проект вообще появится. А уж сколько интересных неучтённых ошибок вы получите на этапе отладки — это будет сказка. :) У меня тут есть коллега, решающий задачу автоматизации в лоб — я его программу загоню легко в состояние, в котором она начнёт делать с аппаратурой нечто невменяемое. Потому что он вместо общего заложил частности. Алгоритмов, кстати, это ПО не содержит — оно чисто автоматика.


                    1. Neikist
                      22.08.2018 12:16
                      #19020197

                      Ну вот смотрите — при нормально организованных процессах модульность так или иначе поддерживают, крупные архитектурные решения принимают архитекторы (а иногда и мелкие), а вот конкретные задачи решают уже все, а при их решении понимание важно. Плюс при прочих равных знание алгоритмов гарантирует что человек с головой и памятью. И их можно быстро проверить. Плюс странно если нормальный программист не знает алгоритмов, ему же это должно быть просто интересно даже самому узнать.
                      P.S. Несмотря на то что я топлю за знание алгоритмов программистами у самого знания эти почти отсутствуют, как и в сфере которой приходится заниматься. За что кстати 1сников заслуженно часто ругают.
                      Это все равно что не понимать хотя бы примерно как работает железо, интерпретаторы, компиляторы, ос (не в деталях, а поверхностно хотя бы знать должны все, чтобы чушь не писать)


                      1. da-nie
                        22.08.2018 12:29
                        #19020261

                        Плюс странно если нормальный программист не знает алгоритмов, ему же это должно быть просто интересно даже самому узнать.


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


                        1. Neikist
                          22.08.2018 13:31
                          #19020517

                          А откуда он это знает? Значит же интересовался. А раз интересовался — то и смотрел как это сделать можно. Ну и конкретные задачи — задачами, но ведь всегда интересно что и как внутри устроено.


                          1. da-nie
                            22.08.2018 14:58
                            #19020915

                            Ну он как бы книжки-то читает иногда. ;) Но из того, что вы пользуетесь какой-то технологией вовсе не следует, что вы сможете её вывести. Я могу пользоваться законом Био-Савара-Лапласа, но вот вывести его не смогу. Ну или уравнениями Максвелла — я их тоже вывести не смогу. Так и тут. Бесполезно просить сделать быструю сортировку — кандидат может вообще плохо помнить, в каких случаях она не самая быстрая и как она вообще устроена. Но он помнит в целом, что сортировки существуют и есть быстрые алгоритмы.

                            Ну и конкретные задачи — задачами, но ведь всегда интересно что и как внутри устроено.


                            Ладно, ладно. Вот у вас есть сотовый? Вы знаете, что это — устройство с использованием радиоволн. А вот знаете ли вы методы модуляции, параметры антенны и сможете всё это реализовать? Очень сомневаюсь. А ведь вам, следуя такой логике, должно было быть интересно, как там оно внутри устроено. Но вот мне преподаватель по вакуумной и плазменной электронике как-то сказал на экзамене «Вы что, хотите понять все курсы? Это невозможно. Максимум — останутся в голове какие-то основы и обрывки». Так и здесь. Прочитал книжку — не факт, что даже понял методики и доказательства — но потребуется, можно найти реализацию и сделать. Так всё инженерное образование построено! Почему программисты должны быть другими?


                            1. Neikist
                              22.08.2018 15:12
                              #19020989
                              +1

                              Вообще я не утверждал что я хороший программист. А хорошему да, должно быть интересно все что связано с программированием. А алгоритмы и подобное уже по идее сами по себе запомнятся.


                              1. da-nie
                                22.08.2018 17:25
                                #19021705

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


                          1. Naglec
                            22.08.2018 15:03
                            #19020955
                            +1

                            Мне вот много чего интересно как внутри устроено, но время есть ограниченный ресурс. Если потратить все это время на A, то пробелы будут в B,C и D. Как произошло у автора с алгоритмами и разработкой непосредственно под Android


                            1. da-nie
                              22.08.2018 17:23
                              #19021699

                              Вот и я об этом. А самое интересное, что «специалист подобен флюсу — его полнота односторонняя». И в результате получаем поразительную вещь: я знал математика, который в математике прекрасно, но во-первых, имеет совершенно никакой кругозор, а во-вторых, у него принципиально отсутствует желание понимать. Например, я не смог объяснить ему, как можно измерять массу не в килограммах, а в метрах и секундах (LT-система единиц — масса измеряется в м^3/с^2). Вот не смог и всё тут. Он не может этого понять. Вообще. Он обзывал меня с коллегой идиотами и тупыми, но понять, что происходит при введении подобной системы единиц и почему это получается он не способен даже с формулами. Потому что инерция мышления и привычки мыслить проторенными категориями столь огромны, что требуется полный слом системы в голове. Это поразительно.


                              1. 0xd34df00d
                                22.08.2018 18:08
                                #19021961

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

                                Построили бы аналогию с раскладыванием величин в базис.


                                1. Druu
                                  22.08.2018 18:17
                                  #19022015

                                  Построили бы аналогию с раскладыванием величин в базис.

                                  Надо было заметить, что величины образуют абелеву группу по умножению.


                              1. Druu
                                22.08.2018 18:11
                                #19021983

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

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


                                1. da-nie
                                  22.08.2018 18:18
                                  #19022027

                                  Ну, он просто импульсивный. :) Верит во всём статьям из википедии (а там почему-то не написано, что массу можно мерить в метрах и секундах). Что рабство было в США не знал вот… Любит авторитетов. :) Но доказывает теоремы и выводит хорошо и кандидатскую защитил. Сейчас наукой занимается в другом месте.


        1. dimm_ddr
          22.08.2018 16:26
          #19021387

          Мне кажется я как раз в своем комменатрии вам этот секрет и открыл. Изучение алгоритмов, на мой взгляд, нужно в первую очередь для тренировки мозга. Если вы внимательно прочитаете мой комменатрий, то найдете там фразы вроде такой:


          При том что алгоритмов я, наверное, не вспомню по памяти вообще ни одного уже.

          Что, впрочем, не совсем правда, забыть бинарный поиск нужно сильно постараться например.
          Это, конечно, не значит что алгоритмы сами по себе не нужны — вам накидали множество примеров где они таки нужны. Но в случаях когда нужен алгоритм достаточно уметь это заметить и уметь алгоритм найти. А вот тренированный мозг, который может заметить потенциальную проблему и быстро накидать корректную абстракцию вы на SO уже не найдете. Я этот мозг использую буквально каждый день и очень хорошо вижу разницу с теми, кто алгоритмы и структуры данных всякие не изучал. Время объяснения потенциальной проблемы, например, просто кратно отличается.


          1. da-nie
            22.08.2018 17:45
            #19021801

            До 2005 года я любил писать разные простые игровые и прикладные программы и баловался с 3D-графикой. В 2005 мне пришлось начать работать с аппаратурой. И оказалось, что мышление тут потребуется изменить. Отсюда я заключаю, что тренировка мозга гораздо больше связана с анализом и решением возникающих нестандартных ситуаций, а вовсе не с запоминанием и пониманием стандартных алгоритмов.

            Это, конечно, не значит что алгоритмы сами по себе не нужны — вам накидали множество примеров где они таки нужны.


            Вот именно, что накидали примеров того, где они нужны. А я разве примеры спрашивал? Я спрашивал вполне конкретную вещь: откуда у вас всех акцент именно на алгоритмах? Я на 100% уверен, что могу поставить задачу вам такую, что вы ни разу не используете ни одного стандартного алгоритма, но при этом задачу провалите полностью и утонете в абстракциях и взаимодействиях между компонентами, просто потому, что никогда такого не делали. Вот подобная задача:
            1) Имеются три вычислителя, объединённые шиной CAN.
            2) Каждый вычислитель имеет четыре процессора, соединённых в звёздочку через двупортовое ОЗУ.
            3) Первый процессор подключён к первой шине CAN, второй ко второй, третий к третьей. Четвёртый является DSP и реализует математическую модель и является центром звёздочки. Вычислители соединенты по первой шине. Вторая идёт на обмен с рядом устройств. Третья тоже идёт на некие устройства.
            4) Одно из устройств на первой шине управляет электропитанием всех компонентов системы (и вычислителей). Все устройства вне вычислителей троированы.
            5) Имеется система тактирования с частотой 32 Гц. Это — системный такт обмена и по результатам обмена производится вычисление модели в заивисимости от команд по магистральному последовательному интерфейсу.
            6) Модели нужно около 27 кБ ОЗУ для расчётов и буферов. Скорость CAN не позволит передавать такой объём в каждом такте.
            7) Первые процессоры подключены к магистральному последовательному интерфейсу.
            8) Каждый момент времени работает только один вычислитель. Второй в горячем резерве. Третий в холодном (выключен).
            9) Имеются два программиста. :) Удачи им в написании ПО с резервированием отказов компонентов (отказать может любой. Перезагрузиться, кстати, тоже — время штатной работы исчисляется годами. Потеря связи — запросто. Зависание — легко. Отказ — это когда перезапуски не помогают восстановить управляемость) и синхронизацией данных между вычислителями (с запоминанием того, что вообще делает устройство в данный момент и чем заняты компоненты комплекса и математическая модель). Ах да, язык — Си99.

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


            1. dimm_ddr
              23.08.2018 00:44
              #19023161

              До 2005 года я любил писать разные простые игровые и прикладные программы и баловался с 3D-графикой. В 2005 мне пришлось начать работать с аппаратурой. И оказалось, что мышление тут потребуется изменить.

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


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

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


              анализом и решением возникающих нестандартных ситуаций

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


              1. da-nie
                23.08.2018 08:04
                #19023543

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


                Я говорю о архитектуре приложения. О методах работы.

                Я говорил про опыт работы с разными алгоритмами, с разными структурами данных и про опыт применения этого всего.


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

                То есть именно что с анализом и решением возникающих нестандартных ситуаций


                Ситуации, описанные в книжке, по которой вы изучали алгоритмы, уже являются стандартными.

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


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


                1. dimm_ddr
                  23.08.2018 10:43
                  #19024151

                  Я говорю о архитектуре приложения. О методах работы.

                  А я говорю о навыке построения абстракций и умении работать с алгоритмами.


                  Я спрашивал, почему вы их поставили на первое месте в разработке ПО.

                  Так покажите мне где я их поставил. Это не я пять раз отвечаю на неправильный вопрос, это вы не удосужились прочитать мой комментарий ипросите от меня чего-то вами же придуманного. Был вопрос:


                  Ох… стоит ли оно того? если такие знания потом на практике не использовать — выветриваются быстро.

                  Я написал почему стоит. Как вы из этого сделали вывод что я считаю изучение алгоритмов самым важным в разработке ПО для меня — загадка.


                  Ситуации, описанные в книжке, по которой вы изучали алгоритмы, уже являются стандартными.

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


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

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


                  алгоритмы не являются пупом Земли

                  следует второе:


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

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


    1. alexeykuzmin0
      21.08.2018 18:34
      #19017651

      Те же алгоритмы спрашивают чуть более, чем везде, так что если их знать, можно без проблем получить немало офферов, и дальше уже выбирать лучший из них (и намекать нелучшим, что они не лучшие). Больше денег — хорошо, при прочих равных.


  1. SaM1808
    21.08.2018 11:44
    #19015345

    по некоторым обстоятельствам семейного характера

    Как Вам удается совмещать семью-работу-обучение? Просто я никак не могу найти этот баланс, только два из трех получается совместить. :(


    1. datacompboy
      21.08.2018 11:53
      #19015409
      +7

      Студенту нельзя жениться. Будет заниматься женой — у него появятся " хвосты". Будет увлекаться учебой — вырастут рога. А попробуй совместить и то другое — отбросишь копыта!


    1. nobodyhave Автор
      21.08.2018 14:04
      #19016229
      +3

      Ну, вот как-то удалось. Я почти не тратил время на дорогу. На Кипре я жил в 15 минутах езды от офиса. Вместо обычной книжки читал книжку по программированию. На работе вместо прокрастинации переключался на решение задачек.
      Но как вы сами понимаете, такое возможно только на ограниченном отрезке времени.
      Например сейчас, с появлением третьего ребенка я бы уже так не смог.


      1. dali
        21.08.2018 14:31
        #19016389

        чувак, да ты герой! проделать такое с двумя детьми… у меня хватает время только на 8 часов работы и остальное время с детьми и семьей…


        1. fukkit
          21.08.2018 22:55
          #19018569
          +1

          Чувак, да вы мы в 21 веке разленились просто до ужаса и зажрались.
          Тут, говорят, диды по 15 детей рожали, успевая при этом гектары перепахивать на сивой кобыле.
          График был: с 3:30 до 17:00, обед в том же поле (без смузи).
          Такие дела.


          1. SaM1808
            22.08.2018 09:18
            #19019341

            Так и отпрыски «дидов» с 5-ти лет избу мели, с 7-и одежду себе шили, с 12-ти за остальными приглядывали, корову доили, есть готовили, пока родители в поле…
            Но это не наше детство… ;)


          1. da-nie
            22.08.2018 09:44
            #19019443

            Так они и мёрли как мухи.
            Где-то была статья про таджиков (100 чего-то там про Таджикистан), так у них ребёнок к колыбели привязывается как-то (без подушки под головой), снизу пакетик, а сами в поле.


      1. c0f04
        21.08.2018 22:44
        #19018521

        Неплохо умеете пробиваться. У меня один пока ребёнок — время свободное почти исчезло. Час — погулять в день с ребёнком, потом ещё поиграться, попытаться пообучать чему-нибудь, а на остаток не попрограммируешь, т. к. нужна какая-то сквозная задача, а для её начала требуется как минимум отпуск взять. Остаётся только книжки читать и ещё по мелочи.


        1. grinCo
          21.08.2018 23:56
          #19018731

          Два ребенка играют друг с другом, а один с родителями.


      1. Danik-ik
        22.08.2018 08:52
        #19019257

        Ничего, скоро вырастут и попереженятся, и Вы опять со сверспособностью найти время.
        У меня четверо от 7 до 15, время на учёбу вроде находится, но потом смотришь как всё кругом запущено, и вот уже и нет его...


  1. werklop
    21.08.2018 11:50
    #19015391

    80й уровень ботанства


    1. 0xd34df00d
      21.08.2018 18:22
      #19017607
      +2

      Как будто что-то плохое. Очень радостно встречать таких людей.


      1. werklop
        21.08.2018 18:32
        #19017645

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


  1. Naglec
    21.08.2018 12:25
    #19015569
    +2

    Какие-то знания реально потом пригодились? Если да, то какие именно?


    1. nobodyhave Автор
      21.08.2018 14:06
      #19016241

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


      1. Naglec
        21.08.2018 15:56
        #19016899

        Тут я бы сравнил с подготовкой к айрон мену, нежели к бегу по утрам


        1. Nordosten
          24.08.2018 11:14
          #19028497
          +1

          Подготовка к айронмэну с целью просто ходить до работы пешком.


  1. dim2r
    21.08.2018 12:26
    #19015579

    На интервью требуют гениальности, а как до кода дело дойдет, то мама родная — бесконечный легаси.


    1. JediPhilosopher
      21.08.2018 12:51
      #19015753
      +1

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


      1. dimm_ddr
        21.08.2018 13:09
        #19015849

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


      1. BingoBongo
        21.08.2018 13:39
        #19016049

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


        1. JediPhilosopher
          21.08.2018 17:50
          #19017485

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

          Чувство собственной нужности и полезности (пусть даже лишь как отдельного винтика в крупной корпоративной машине) людям нужно.


          1. BingoBongo
            21.08.2018 18:18
            #19017595

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


            1. JediPhilosopher
              21.08.2018 19:26
              #19017865
              +1

              Речь не о качестве кода, а о его нужности в принципе. Очень тяжело делать работу, которая абсолютно никому не нужна. Можно сделать раз, два, но когда ты понимаешь что в конторе это скорее правило чем исключение (т.е. выбрасывание результатов многомесячного труда в помойку) — пропадает вообще стимул что-то дальше делать.


          1. 0xd34df00d
            21.08.2018 18:23
            #19017619

            Ну это зависит. У меня было два проекта, которые пошли в стол. На одном из них я многому научился и решил ряд интересных и нетривиальных задач, и мне, в общем, пофиг, в стол он пошёл или в прод. На другом я, конечно, писал на приятном мне языке и решал интересные мне задачи, но не было челленджа, поэтому как-то да, грустновато. Но там и другие причины примешиваются.


      1. alexeykuzmin0
        21.08.2018 18:53
        #19017729

        Некоторые части Google лежат в open source, например, Android. Можно оценить, сколько пишет средний разработчик.


      1. dim2r
        23.08.2018 12:18
        #19024657
        -1

        Меня как-то смутило одно интервью с инженером Гугла, которое проводило Бибиси. Ожидал увидеть комфортный футуристический офис, нооо… интервью проводили на лужайке во дворе. Сразу понял, что эти футуристические оффисы — кино-постановка. А что творится реально — лучше никому не показывать, даже такой проверенной конторе, как Бибиси.


        1. Danik-ik
          23.08.2018 13:38
          #19024973

          Вы удивитесь, но "не показывать" можно далеко не только бардак. И между "оформить разрешение на посещение с камерой" и "позвать выйти на улицу" тоже как бы разница есть.


          1. dim2r
            23.08.2018 14:18
            #19025127

            Смутило то, что это было Бибиси, а не блоггер Пупкин, которого любой может обидеть. Я тоже в филиале большой конторы работаю, чуть меньше гугла. Примерно понимаю о чем речь.


            1. bay73
              23.08.2018 15:06
              #19025347

              Журналист Пупкин, который работает на Бибиси, договорился взять интервью у знакомого разработчика Гугла. :)


            1. dimm_ddr
              23.08.2018 16:15
              #19025669

              А зачем бибиси платить большие деньги за разрешение на съемку в офисе если можно снять на лужайке? А может им вообще было важно именно в таком формате снять, чтобы не отвлекать от интервью рекламой офиса гугла. Тысячи причин могут быть чтобы сделать именно так.


              1. dim2r
                23.08.2018 17:11
                #19025913

                Бибиси — это очень хороший ПиАр. Многие сами бы заплатили бы.


    1. Gugic
      21.08.2018 13:06
      #19015845

      Это не так.


      Система как раз отстроена на наем крепких середняков (ну и плюсом — мы лучше отсеем хорошего девелопера, чем пропустим плохого) — гении в энтерпрайзе сильно не нужны, а если и нужны на какие-то конкретные узкие места, их хантят отдельно.


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


  1. finlandcoder
    21.08.2018 13:41
    #19016063
    +1

    Собеседование в Gooogle это олимпиада по программированию. При этом шанс писать какой-то убитый легаси очень велик. Риск не оправдан. Можно сходить ради фана, но не более. Тем более 2-3-5 раз.


    1. alexeykuzmin0
      21.08.2018 18:55
      #19017735

      Ну, команду все же можно выбирать. Да и сменить потом вполне реально.


    1. Gugic
      21.08.2018 22:03
      #19018393

      Нет, далеко не олимпиада — задачки где-то на уровне leetcode'овского medium, ничего сверхъестественного там нет. Интервью на дизайн тоже ничего сложно не представляет из себя если есть какой-никакой бэкграунд в похожем технологическом стаке. Плюсом оценивают пресловутую коммуникабельность и прочие софт-скиллы. И как тут уже заметили таки да, команду можно выбирать + internal mobility работает очень хорошо. Есть даже внутренний стартап-инкубатор где с бюрократией сильно проще чем в среднем по больнице, и туда также постоянно нужны люди, как и в другие проекты.


    1. Zoolander
      22.08.2018 06:28
      #19019061

      // Риск не оправдан
      многие не согласятся, потому что
      — строка в резюме почетная
      — знакомства с новыми людьми из крутой компании
      — хорошие бонусы
      — возможность клевой релокации
      — после такой работы чувствуешь себя реально опытным бойцом


  1. Palpatin
    21.08.2018 13:58
    #19016183

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


  1. aaerokhin
    21.08.2018 14:07
    #19016251

    С таким упорством у Вас все получится, удачи!


  1. mAAriellla
    21.08.2018 14:42
    #19016467

    Ваша статья мотивирует. Ценный опыт.
    Основательный у Google подход к интервью… по крайней мере в Цюрихе.


  1. thauquoo
    21.08.2018 15:21
    #19016657

    Google — уже не та компания, что была 15 лет назад. Слишком поменялись её принципы.


    1. alexeykuzmin0
      21.08.2018 18:56
      #19017741

      Расскажете, каким Google был 15 лет назад? Интересно.


  1. lanseg
    21.08.2018 15:24
    #19016677

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


    1. Медленное рабочее решение лучше быстрого, но плохо работающего. Решение за экспоненциальное время, лучше, чем решение, которое должно было бы работать за линейное время, но работало через раз.
    2. Большинство задач даётся в «открытом» виде, без полного набора критериев и требований. Так что, считается хорошим тоном «Будет ли этот код запускаться в нескольких потоках?», «Есть ли какое-то ограничение по памяти?», «Будет ли это приложение кроссплатформенным?», «Это полностью решается классом X из java.util.concurrent, можно ли использовать его?»
    3. Ну и, конечно же, комментировать. «Тут нужно отлавливать NPE», «Этот код не будет потокобезопасным, если бы нужен был потокобезопасный код, то я бы использовал метод Б»

    Как-то так. Я хорошо ответил на алгоритмические и архитектурные вопросы и так себе на объектно-ориентированный дизайн, в итоге сейчас пишу эту простыню из Цюриха.


    1. suharik
      21.08.2018 15:28
      #19016701

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


      Именно этот принцип рождает проблемы, описанные в статье про 24-ядерный проц.


      1. lanseg
        21.08.2018 15:34
        #19016749

        Я о том, что медленное, но рабочее решение лучше, чем ничего. Само собой, быстрое рабочее решение лучше, чем медленное.


    1. nobodyhave Автор
      21.08.2018 15:46
      #19016811

      Все сильно зависит от интервьюера. Кому-то описанного вами достаточно, кому-то нет. Кого-то N^3 вместо N*lgN не устраивает как решение, стоящее записи. См. интервью 4.
      В вашем случае звезды сложились, в моем нет )


    1. alexeykuzmin0
      21.08.2018 18:58
      #19017747

      Более того, решить задачу — это вообще не то, что нужно для трудоустройства. Обычно нужно показать, что умеешь думать. Если направление мысли было правильным, ты задавал верные вопросы — это будет в сто раз лучше, чем молча код написать.


    1. Izaron
      21.08.2018 19:09
      #19017797

      Можете привести пример из первого пункта? Вы имеете в виду имба-задачи как Traveling Salesman, которую разные гении начинают оптимизировать путем "а давайте брать ближайшую незанятую точку и идти туда"? (Хотя тут уже все перекопано и есть эвристичестие решения, которые ошибаются на 0.05% от идеального-преидеального варианта)


      Просто если человек решал много задач, у него отпечатывается "неполное решение = вообще не решение", то есть если код не прошел даже самый крайний corner case — может идти лесом.


      1. lanseg
        21.08.2018 20:17
        #19018017

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

        Просто если человек решал много задач, у него отпечатывается «неполное решение = вообще не решение», то есть если код не прошел даже самый крайний corner case — может идти лесом.

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


  1. artemmityushov
    21.08.2018 15:26
    #19016691

    Ребят, вот все конечно же круто, но остался один вопрос — а работа в гугл реально стоит такого гемора? Ну вот в деньгах не факт что больше чем во многих других компаниях, по опыту тоже самое, не факт что будешь заниматься чем-то серьезным, даже наоборот громадная вероятность что самое крутое что ты напишешь это то что писал на собеседовании. И на сколько я слышал от многих знакомых такая фигня с собеседованиями только у гугла, остальные не доходят до такого маразма с требованиями, особенно когда понимают что гонять по алгоритмам фронтенд разработчика это глупость.
    Бывший коллега как-то уехал в одну московскую крутую компанию(имя называть не стану), прошел все круги ада собеседований, что только у него не спрашивали, один из вопросов вообще был «а как вы оптимизировали бы решето аткина»(сам завис, через 10 лет после окончания вуза такие вещи вообще не вспомнишь если не применяешь, а вероятность применения близка к нулю), и в результате коллегу взяли и за три года работы по его словам он не применил ничего о чем спрашивали на собеседовании включая почти всех кто сидел в их здании. От лукавого все это, от лукавого.


    1. nobodyhave Автор
      21.08.2018 15:48
      #19016829

      Для кого-то это гемор, для меня было интересное увлечение. Когда времени на это не стало, свернул попытки устроиться в гугл и устроился в другую компанию. Но знания все равно пригодились )


      1. artemmityushov
        21.08.2018 15:59
        #19016917

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


    1. mike1
      21.08.2018 15:59
      #19016925
      +1

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

      Надо же как-то фильтровать миллионы желающих работать в Гугле. Все примерно знают одинаково технологии. Остаётся заставлять решать задачки.
      Бывший коллега как-то уехал в одну московскую крутую компанию

      Тут нету крутых компаний. Яндекс что ли?


      1. artemmityushov
        21.08.2018 16:18
        #19017027

        Ну не сказал бы что все знают технологии одинаково, это уж сильное преувеличение.
        А что такое крутая компания? Вот если положив руку на сердце — чем для среднестатистического разработчика Гугл отличается от многих других компаний, даже региональных, кроме громкого имени и клевой записи в резюме? От того что компания «крутая» и распиаренная не говорит что именно вам придется там заниматься чем-то действительно интересным.


    1. Goldseeker
      21.08.2018 18:50
      #19017711

      Я посмотрел что там по деньгам у гугла в Цюрихе — пожалуй, да, стоит.


      1. Izaron
        21.08.2018 19:13
        #19017817

        А потом погроммист проходит в Google, резко прыгает к вершине пирамиды Маслоу и начинается выпендреж: "5 строк за год всего лишь послал", "Ну вот в деньгах не факт что больше чем во многих других компаниях"...


        1. 0xd34df00d
          21.08.2018 19:18
          #19017837

          5 строк — это самореализация. А сами по себе деньги — это не вершина пирамиды.


    1. alexeykuzmin0
      21.08.2018 19:02
      #19017763

      а работа в гугл реально стоит такого гемора?
      Полтора года (это с нуля, я так понял, а так было бы быстрее) интересных занятий, общеразвивающих для мозга, ради того, чтобы получить навыки, позволяющие без проблем получить оффер практически в любой интересующей тебя компании? Плюс, если все-таки пойдешь в Google, строчка в резюме, благодаря которой на тебя будут смотреть не так, как на «еще одного иммигранта»? Ну даже не знаю.


    1. ankh1989
      22.08.2018 08:01
      #19019165

      Автор судя по всему проходил собеседование на сеньора, а в гугле это $300-400K в год. Много есть мест в мире где можно столько получать?


  1. elenbert
    21.08.2018 17:29
    #19017379

    Интересно, спасибо )
    Буквально сегодня общался с рекрутером из Google, правда они сами меня нашли. Так же предлагают Цюрих.
    На следующей неделе будет первое техническое интервью, тут даже больше интересно попробовать и проверить себя.
    Сам рекрутер звонил из Лондона, общались через Hangouts и это действительно было не очень, частые фризы, рассыпание картинки и заикания звука.


    1. vmc1
      21.08.2018 18:16
      #19017585

      удачи! сколько задач с литкода решили?


      1. alexeykuzmin0
        21.08.2018 19:03
        #19017767

        С рекрутером задачи не решают, а техническое интервью будет на следующей неделе.


    1. Areso
      21.08.2018 19:08
      #19017783

      Интересно, кто же у них такой пишет Hangouts, что на него все жалуются. Школьники из Индии на аутсорсе?) /s


  1. SpbSprut
    21.08.2018 18:16
    #19017587

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


    1. nobodyhave Автор
      21.08.2018 18:17
      #19017589
      +1

      Математика это математика, а Computer Science все-таки несколько другое. Хотя местами и пересекаются.


    1. Izaron
      21.08.2018 19:24
      #19017859

      В Google тоннами шлют свои биографии со всех стран мира. Шанс что рандомное резюме пробьется, равен std::numeric_limits<double>::epsilon(). Из каждого утюга пишут, что не шлите через сайт pdf, отправьте через знакомого, иначе вам придет "привет, досвидания" автоматом.


      Логика такая, что если формочки там клепает overqualified профессор компуктерн саенс, прошедший отбор 1000 человек на место, то пусть это и будет профессор, который к тому же еще точно знает, что в начало списка добавлять миллион элементов по отдельности вредно, а не какой-то рандомный во всех смыслах парень.


    1. bay73
      21.08.2018 19:45
      #19017915
      +1

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


    1. ankh1989
      22.08.2018 08:10
      #19019177

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


  1. Perlovich
    21.08.2018 18:28
    #19017633

    После окончания курсов я осознал, что многие знания это многие печали. Если раньше я просто знал, что ничего не знаю, то теперь начал осознавать, что именно я не знаю.


    so true. Чем больше материала изучаешь, тем больше знаешь о том, чего не знаешь.


    1. SpbSprut
      21.08.2018 18:44
      #19017689

      Знания как белый круг во тьме, чем круг шире тем больше область видимого не знания)


      1. a-l-e-x
        21.08.2018 18:50
        #19017709

        иногда хочется его конформно отобразить…


  1. VasiLLivanov
    21.08.2018 18:48
    #19017697

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

    Но если подавать заявку в Гугл на разработчика Андроид, то как бы нужно 90% времени читать документацию Андроид! Ведь работа будет связана либо с разработкой/оптимизацией фрагментов новых/старых версий Андроид, либо с реализацией сервисов Гугл на Андроид, не так ли?
    У Вас ведь спрашивали именно документацию Андроид

    «А дальше начались несколько неожиданные вопросы в духе «а что в классе Х делает метод У»»

    Со стороны автора рассказа все выглядит как детский сад, Вы просто отняли время у Гугл, играли в игру «собеседование в Гугл», явно не желая получить положительный результат и работать в Гугл, а просто хотели приключений.
    И еще раз, 2 года подготовки вызывают уважение.


    1. domix32
      21.08.2018 19:50
      #19017937

      Android-разработчик, а не разработчик Android'a или я чего-то не так читаю


      1. Izaron
        21.08.2018 20:06
        #19017987
        +2

        Так написано: "работа будет связана либо с разработкой/оптимизацией фрагментов новых/старых версий Андроид, либо с реализацией сервисов Гугл на Андроид", то есть и Android-разработчик, и разработчик Android.


        Можно подозревать что сил на разработку всего Android, т.е на оболочку, API, свистелки, сервисы типа Google Play тратится несоизмеримо больше сил, чем на создание клиентов приложений на всем готовом, то есть в сорцы нырять пришлось бы все равно. Точно ничего не утверждаю, в Google не работал Android-девом, где-либо еще тоже.


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


    1. nobodyhave Автор
      21.08.2018 19:59
      #19017961
      +2

      Видите ли, до недавнего момента в гугл спрашивали именно то, к чему я готовился. На любую роль, хоть фронтенд разработчик, хоть кто. И какие-то подвижки начались не так давно. И как заметили выше из Лондона, похоже даже не во всех офисах.
      Так же я упоминал в статье, что да, рекрутер мне озвучил то, что будут вопросы с андроид спецификой, но не смог привести пример.
      Т.е. готовился я играть по одним правилам, а когда сели за стол, то правила слегка поменялись.
      А неожиданность вопросов не в том, что они по андроиду, а в сути. Ну не уровень это гугла, спрашивать, что какой метод делает. А особенно как. Т.е. был вопрос, что написано внутри метода. Может я его 3 года назад смотрел, а они там код переписали.


      1. VasiLLivanov
        21.08.2018 20:26
        #19018055

        Вы рассказали интересный случай, как КомпьютерСаэнс для конкретной вакансии оказался важным, но не главным фактором. Конечно, ответственность за неудачное собеседование не только Ваша. Рекрутеры должны были уточнить какие-то требования к вакансии, какие знания Вы должны подтвердить на интервью. Плюс, интервьюер имеет какие-то инструкции, кроме общего впечатления (Комп.Саэнс) он должен проверить кандидата на специфику того департамента/команды, где открыта вакансия.
        Интересно, интервьюеры как-то представлялись?


        1. nobodyhave Автор
          21.08.2018 20:39
          #19018101

          Да, но я уже не вспомню подробностей.


        1. alexeykuzmin0
          21.08.2018 20:44
          #19018123

          интервьюеры как-то представлялись?
          Обычно кратко представляются, вроде «привет, меня зовут Алекс, я из команды Android Z»


          1. tyomitch
            21.08.2018 20:53
            #19018149

            В конце беседы они всегда спрашивают, есть ли к ним вопросы, и на вопросы в духе «давно ли здесь, чем занимаешься, как тебе атмосфера» и т.п. — отвечают вполне охотно.


      1. alexeykuzmin0
        21.08.2018 20:43
        #19018119
        +1

        Ну не уровень это гугла, спрашивать, что какой метод делает. А особенно как.
        Ну это смотря как сформулировать и как оценивать ответ.
        Меня вот в одной компании спрашивали «как реализован std::distance?» Я ответил, что впервые такое название слышу. Интервьювер сказал, что это функция, которая выдает расстояние между двумя итераторами и спросил, как бы я ее реализовывал — ну я и рассказал, как бы я это делал, со всякими std::enable_if, с обсуждением того, логично ли выдавать отрицательный ответ, если на вход даны два RandomAccessIterator в неправильном порядке, и тд. По-моему, неплохой вопрос получился.


  1. Extremum
    21.08.2018 18:55
    #19017737

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


  1. Alexsey
    21.08.2018 19:25
    #19017861

    Завидую упорству автора. Реально очень круто. И в очередной раз офигеваю с гугловской моды насиловать мозг кандидатам. (больше всего, конечно, меня добивает написание простыни кода на доске)


    1. alexeykuzmin0
      21.08.2018 19:28
      #19017871

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


      1. Alexsey
        21.08.2018 19:42
        #19017907

        Если ноутбук дают — то без вопросов, просто я слышал только про доски и никак иначе.


      1. nobodyhave Автор
        21.08.2018 20:02
        #19017977

        Нуу, это выглядит так.
        — Напишите нам код на доске.
        (Начинаю писать код, исписал доску)
        — Ой, знаете, а у нас тут хромбук есть, но я им как-то никогда не пользовался. Хотите?
        -Нет, спасибо, давайте не будем отвлекаться

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


        1. alexeykuzmin0
          21.08.2018 20:45
          #19018127
          +1

          Интервьювер не прав, что не обратил ваше внимание на него сразу.


        1. daiver19
          21.08.2018 20:47
          #19018135

          Не в гуглодоке, но и не в ИДЕ. Простенький редактор кода, не помню, есть ли подсветка синтаксиса.


          1. nobodyhave Автор
            21.08.2018 20:55
            #19018153

            Если память мне не изменяет, а это может быть, так как было давно, на тот момент мне предлагали именно гуглодок. И Hangouts собеседования тоже были в нем.


            1. daiver19
              21.08.2018 20:57
              #19018161

              Хэнгаутс собеседования, к сожалению, еще в гуглодоке пока что. Я не знаю, конечно, всех экспериментов с хромбуками, но последний начался недавно и включает в себя этот спец редактор.


          1. alexeykuzmin0
            21.08.2018 21:04
            #19018185

            Обычно именно что в гуглодоке, по крайней мере, год-два назад так было


            1. alekspak
              22.08.2018 00:04
              #19018747

              Это новая штука. Там есть подсветка синтаксиса. Правда большинство готовится писать на доске и выбирают доску. Также с языками. Готовят джаву, говоришь, у вас тут питон как главный язык в резюме, может питон, а они всё равно на джаве.


      1. tyomitch
        21.08.2018 20:50
        #19018139

        Мне на собеседовании у них в Цюрихе не предлагали ноутбук — только доску и маркер.
        Возможно, в других офисах ноутбук действительно предлагают.


        1. alexeykuzmin0
          21.08.2018 21:05
          #19018189

          Неожиданно. Я слышал, что такое случалось в далекой древности.


          1. tyomitch
            21.08.2018 21:23
            #19018259

            Я у них был ровно два года назад.


      1. WinPooh73
        22.08.2018 03:36
        #19018935

        Писать код на доске неудобно хотя бы тем, что за долгие годы практики руки привыкают набирать открывающую и закрывающую скобки одновременно, парой, и никак иначе :)


      1. gohan
        22.08.2018 03:58
        #19018959

        А чем плохо код на доске писать?

        Я, например, с детства ненавижу писать на доске. Меня напрягают следующие вещи:

        1) надо писать от руки (пишу медленнее раз в 10-20, чем набираю)
        2) надо писать от руки на вертикальной поверхности, мне это тупо в разы неудобнее, чем на горизонтальной
        3) мало места, мелкими буквами писать не люблю и выйдет ещё медленнее чем нормальными
        4) нужно постоянно отходить чтоб окинуть взглядом написанное
        5) волнуюсь, оказавшись перед доской под чьим-то пристальным взором, будто в школе будто опять очутился (учился там хорошо, но у доски всегда нервы)


        1. F0iL
          22.08.2018 09:09
          #19019311

          6) Copy-paste работает только вручную, если нужно перенести уже написанный кусок кода в другое место. Аналогично со вставкой блока кода в середину уже существующего — только вручную, и повышается риск ошибок.


          1. tyomitch
            22.08.2018 21:43
            #19022717
            +1

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


            1. F0iL
              23.08.2018 09:16
              #19023727
              +1

              Ох нет. Помнится, в Яндексе мне как-то раз попался один наглухо упоротый интервьювер, требовавший «чтобы вообще вот без ошибок было». Причем под ошибками понимались и «я точно знаю, что есть функция стандартной библиотеки с таким-то функционалом, с таким-то названием, я только не помню точно порядок аргументов в сигнатуре вызова, давайте посмотрим в доках, ну или я напишу примерно как я себе это представляю, суть от этого особо не поменяется», так и синтаксические ошибки, типа точеки с запятой и скобочек. Хотя, может просто я ему чем-то не понравился, кто знает.

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


              1. Druu
                23.08.2018 09:33
                #19023799
                +1

                Ох нет. Помнится, в Яндексе мне как-то раз попался один наглухо упоротый интервьювер, требовавший «чтобы вообще вот без ошибок было».

                Вы же не прошли? Ну и радуйтесь, не придется с ним работать :)


              1. bay73
                23.08.2018 14:06
                #19025071

                Да и в целом, в процессе работы на хоть сколь-нибудь сложным алгоритмом с множеством граничных случаев, этих «стрелочек с кружочками» в итоге может стать столько

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


                1. Druu
                  23.08.2018 15:38
                  #19025493

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

                  К этим 20 строчкам еще надо алгоритм привести, из алгоритма на все 200.


                  1. bay73
                    24.08.2018 10:31
                    #19028269

                    Что значит «еще надо алгоритм привести»? Кому и куда его приводить надо?
                    На алгоритмическом интервью вы должны просто написать код и дать к нему устные комментарии. Объём кода, который ожидает увидеть собеседующий обычно очень невелик (и вряд ли требует более 5 минут на собственно написание). Сколько вы при этом наболтать успеете — дело добровольное.


                    1. Druu
                      24.08.2018 10:41
                      #19028321
                      +1

                      Что значит «еще надо алгоритм привести»? Кому и куда его приводить надо?

                      Ну вот вы написали алгоритм "влоб", получилось 200 строк. Его, конечно, можно переписать за 20. Но надо еще переписать.


                      Сколько вы при этом наболтать успеете — дело добровольное.

                      Ну при чем тут наболтать? Вы еще предложите в уме интегралы брать.
                      Человек придумывает алгоритм, по ходу дела пишет код. Естественно, что если человек наперед не знает алгоритма, код будет сильно неэффективен. Не в плане оптимизаций (хотя частично и в них) но именно в плане выразительности.


                      1. bay73
                        24.08.2018 10:59
                        #19028413

                        Естественно, что если человек наперед не знает алгоритма, код будет сильно неэффективен
                        Нет, это неестественно. Нормальный разработчик сначала немного подумает, а потом начнёт писать. Идеального кода сразу, конечно, не получится. Но и разбухания в 10 раз не будет.


        1. tyomitch
          22.08.2018 21:39
          #19022689
          +1

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


          1. nobodyhave Автор
            22.08.2018 21:54
            #19022757

            Кроме того, задачи для собеседований нарочно выбираются так, чтобы простыни кода там не понадобились
            Попробуйте написать на доске (да даже и на бумажке) код для Андроид. Например Activity + AsyncTask + TextWatcher + пару побочных классов типа таймера. И снабдить это минимальной бизнес логикой.
            И вы неприятно удивитесь размеру )


      1. Konachan700
        23.08.2018 16:15
        #19025667

        Тем, что предполагается вызубривание наизусть того, что постоянно меняется. Тем более, что на собеседовании обстановка всегда стрессовая, что на память влияет крайне негативно. Алгоритмы-то в псевдокоде пишут, и писать псевдокод на доске норм — его на ходу можно выдумывать, но автор-то говорил про конкретный java-код активити… Это жесть, садизм какой-то. И самое главное, зачем это? У них пишут код на обрывке газетки под периодическим пулеметным огнем? Почему нельзя дать ноутбук с IDE?
        Напомнило мне, как я в один автосервис на диагноста пришел устраиваться лет 7 назад — меня не к машинам повели, как везде, а дали кипу задач по физике и электротехнике из универа, с вопросами чуть ли не о типах кварков блин… Развернулся и ушел сразу, а потом выяснилось, что туда берут только с технической вышкой, и что сервис мягко скажем, пользуется дурной славой — там одни студенты-теоретики, руками никто работать не умеет.


  1. daiver19
    21.08.2018 19:49
    #19017925
    +2

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

    Как-то подозрительно, раньше точно так не было. Даже 2 года назад так вроде не было. Бронируют отель и самолет, за еду потом можно по чекам получить.

    Мне кажется, что вы зря пытались пройти именно на Android разработчика. Во-первых, это, имхо, одна из самых неинтересных вещей, которыми можно заниматься в Google. Во-вторых, проще пройти как SWE и потом уже трансфериться, если уж очень хочется именно в Android.

    Ну и хочу добавить, что интервью — это несколько рандомный процесс и методы оценивания и вопросы некоторых людей являются, мягко говоря, неоптимальными (и не следуют гайдлайнам. какой нафиг код на System Design?)


    1. nobodyhave Автор
      21.08.2018 20:04
      #19017983

      Как-то на тот момент над этим не задумывался. Тем более что до момента, как позвали на онсайт, никто не говорил, что интервью будет отличаться от стандартного для SWE.
      А то что процесс рандомный я уже понял. Если бы было время — может еще бы покидал кубик, но не сложилось.


    1. Civil
      22.08.2018 18:14
      #19021999

      Как-то подозрительно, раньше точно так не было. Даже 2 года назад так вроде не было. Бронируют отель и самолет, за еду потом можно по чекам получить.


      Отель не оплачивают в том случаи, если ни в одном из отелей с которыми есть договоренности нет свободных мест. Такое бывает если о собеседовании договариваться почти в последний момент, либо в это же время было какое-то крупное событие (например для Швейцарии это может быть сезон зимних видов спорта).

      Проезд внутри страны и еда компенсируются дейсвительно по чекам после.


  1. Dywar
    21.08.2018 20:34
    #19018077

    Супер, спасибо за статью.

    В целом считаю что лучшее что вы с этого получили это знания в процессе подготовки.

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

    Сам в алгоритмах не силен, просто прочитал пару книг, и иногда напоминаю себе что и такое бывает :)


    1. nobodyhave Автор
      21.08.2018 20:42
      #19018113
      +2

      Проблема в отсутствии свободного времени ) Поэтому надо было себя настроить, чтобы выделить это время из несвободного. Маленький лайфхак.
      А если есть свободное время и желание развиваться, то естественно это можно делать и просто так.


  1. Mike-M
    21.08.2018 22:33
    #19018491

    Как-то не вяжется: сначала заставляют пройти 5 интервью, а в результате получают

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


    1. nobodyhave Автор
      21.08.2018 23:10
      #19018599
      +1

      Ну, тут проблема может быть и не в Hangouts ) Интернет на Кипре он такой, специфический )


      1. Mike-M
        21.08.2018 23:16
        #19018619

        Сам однажды пробовал собеседоваться через Hangouts. Минут через 20 браузер вылетел с крэшем. Где-то выше в комментариях другие тоже жаловались. Так что проблема точно в Hangouts.


    1. vedenin1980
      21.08.2018 23:12
      #19018611

      Подход к подбору кандидатов явно требует перемен.

      Так если они хотели видео звонок, то не по скайпу же HR'у гугла организовывать, над ними потом весь инет смеется будет. К тому же качество могло проседать на стороне кандидата, тут ничего не сделаешь, какое программу видео-звонков не бери, кроме как перейти на телефон.


      1. Mike-M
        21.08.2018 23:27
        #19018659

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


    1. Gugic
      22.08.2018 01:01
      #19018825

      Hangouts (именно как видеоконференция) весьма достойно работают (исходя из моего личного опыта конечно). Я постоянно делаю конф-коллы с друзьями, очень нравится то, что не нужно каких-то специальных телодвижений делать — просто кидаешь ссылку и человек тут же присоединяется к конференции (гуглоаккаунт нужен, да, но он почему-то есть у всех без исключения моих знакомых) — не нужно ничего устанавливать и где-то помимо гугла регистрироваться. Если начинаются фризы/лаги — это обычно из-за качества соединиения (а скорее из-за кривой маршрутизации) на той или другой стороне, выключаешь hd и все становится лучше.


      Есть еще интересный факт — hangouts официально ПО для видеоконференций внутри гугла (https://www.blog.google/products/g-suite/how-google-went-all-video-meetings-and-you-can-too/), а это значит что сами гугловцы отбивают десятки тысяч видеоконференций в день, соединяя зачастую офисы в разных городах и странах.


  1. maybe_im_a_leo
    21.08.2018 23:59
    #19018739

    Я обычно ничего не спрашиваю на собеседовании, если мне и так все понятно. Предоставляю возможность человеку самому рассказать о себе (задолго до собеседования, с помощью научных публикаций, патентов, GitHub, блога, etc).


  1. maybe_im_a_leo
    22.08.2018 00:08
    #19018753

    Мне кажется есть два подхода:


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

    Какой конкретно подход наверное зависит от самой компании (например очень большие компании имеют бесконечную очередь желающих туда попасть) и области о которой идёт речь (в hardware например имеется куда более глубокая специализация, и часто требуется человек с конкретным skill set и опытом)


  1. romangoward
    22.08.2018 02:50
    #19018903
    +1

    Так как подаваться через сайт дело достаточно гиблое, занялся поиском знакомых, работающих в Google.

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


    Этой весной, занимаясь подготовкой инфраструктуры для повторного прохождения QSA-аудита для получения сертификации PCI, выяснилось, что у k8s с этим всё очень плохо. Немного подумав, я решил, что если и заниматься k8s, то лучше сразу в Google, о чем и было написано в сопровождающем письме к отклику на вакансию SRE через careers.google.com.


    Через несколькой дней позвонил HR с просьбой подтвердить намерения, позадавал уточняющие вопросы (в какой офис хотите? и т.д.), после чего прислал письмо со ссылкой на google calendar, где необходмо было выбрать удобный мне слот для первого телефонного интервью.
    В процессе поиска информации о формате данных интервью, я натыкался на типичные вопросы, которые там задают… и назначил интервью через 4 дня, решив, что если не смогу пройти первичную отсеевалку, то явно мне дальше делать нечего. Звонок прошёл хорошо, и меня попросили зарегистрироваться на Coding Coaching Session, для подготовки ко второму телефонному звонку.
    На CSS было человек десять: трое не досидело до середины, уточняющие вопросы задавали очень вяло.
    Смысл CSS ровно один — у них есть анкета, которую заполняет интервьювер по ходу собеседования и чтобы умозаключения более последовательные, а оценки о них более приближенны к реальности — есть манифест о том, как надо себя вести.


    CSS прошёл, написал письмо.
    Назначили нового HR из Сингапура.
    Начал звонить первый HR и спрашивать в каком офисе я хочу работать и когда можно назначить дату телефонного звонка. Ок, накладочка вышла.
    Я уезжал в отпуск в Европу, о чем уточнил в письме, поэтому второй звонок назначили через неделю.


    Готовиться к интервью с особым усердием я не стал, посмотрел несколько типовых задач, да и только.
    Во-первых, вместо обещанной сессии по программированию на 45 минут, я получил сессию по nix internals & programming.
    Минут через 10 после начала разговора, когда мы еще не с головой залезли в дебри файловой системы, я уточнил что ожидал вообще-то сессии по python. "Сорян", — сказали с той стороны монитора, и пообещали отметить это в анкете.
    30 минут мы общались по теории, после чего перешли к практике.
    Сначала я и второй рекрутер не видели текст задачи, потому что основной интервьювер писал не в тот документ, после чего у меня отвалился интернет: 10 минут драгоценного времени потрачены зря, но резервный канал под боком и едем дальше: пытаемся обсудить как можно хранить и процессить данные по задаче. Ок, договорились — наконец-то начинаем писать код… на 45 минуте.
    И тут же первая (и последняя) сложность:
    — Я не знаю какие параметры принимает функция (из стандартной библиотеки) и что она возвращает
    — Да мы тоже не знаем, в гугле стандартную библиотеку не юзают, у нас все своё
    — Эээ, давай откроем документацию?
    — Нет времени, пофантазируй
    — унылая_двухминутная_фантазия_о_возможных_методах_и_функциях.jpg
    — Время закончилось


    Фидбэк за второй звонок: solid knowlege за unix internals и "больше фокусируйтесь на программировании" за вторую часть.
    HR уточнила согласен ли я с оценками, на что я ответил: согласен, ведь задача не решена, но организация интервью была очень странная — я так и не понял чего я не знаю и как готовиться дальше (ха-ха!). "Я ж вам присылала список литературы для подготовки… не получали? Странно."


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


  1. ankh1989
    22.08.2018 07:50
    #19019149

    Среднее кол-во попыток для тех кто прошёл — 4.


    1. tyomitch
      22.08.2018 22:07
      #19022799

      [citation needed]


  1. Druu
    22.08.2018 11:54
    #19020079
    +1

    Мне кажется, ничто не демонстрируют все будет нынешних принципов найма в IT, чем подобные статьи.
    Люди готовятся не к решению практических задач на работе, а к прохождению интервью.


    1. tyomitch
      22.08.2018 12:48
      #19020337

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


      1. Druu
        22.08.2018 13:12
        #19020431

        Что предложите нанимателям вместо таких собеседований?

        А что, кроме как "напишите бинарный поиск на доске" и "скажите, какая сложность у сортировки пузырьком" больше вопросов не бывает? Не, ну серьезно?


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


        1. tyomitch
          22.08.2018 14:00
          #19020647

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

          На собеседовании в Гугле вопросы совсем не такие. Не на заучивание алгоритмов, а на их творческое применение.

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

          Во-первых, чтобы не показывать кишки непубличных проектов каждому встречному. Во-вторых, потому что в компаниях размером даже в 1/10 Гугла любой проект будет завязан на стотыщ внутренних сервисов, и одно только объяснение «чем мы здесь пользуемся» займёт дольше, чем само ревью.

          В сайтоклепательной конторе из десяти человек подход к найму, конечно, будет другой, чем в Гугле.


          1. Druu
            22.08.2018 15:02
            #19020951
            -1

            На собеседовании в Гугле вопросы совсем не такие. Не на заучивание алгоритмов, а на их творческое применение.

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


            Гугла любой проект будет завязан на стотыщ внутренних сервисов, и одно только объяснение «чем мы здесь пользуемся» займёт дольше, чем само ревью.

            Да никогда не бывает такого, что нету таски, в которой не завязано совсем на все. Если у вас таких нет — значит совсем уж говнокод, да.


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


            1. nobodyhave Автор
              22.08.2018 15:54
              #19021201
              +1

              Алгоритмы я заучивал, чтобы не отвлекаться на их вспоминание на интервью.
              А вот решение задачек это как раз творческое их применение. Откройте например Hackerrank и возьмите задачу пусть даже не Expert, а Hard. С 95% вероятностью вы не найдете стандартного алгоритма для ее решения. Решение будет состоять либо из модификации стандартного алгоритма, а для этого надо понимать, что у него внутри, либо из комбинации стандартных алгоритмов, причем комбинации не самой очевидной.


              1. Druu
                22.08.2018 16:30
                #19021415
                +1

                А вот решение задачек это как раз творческое их применение. Откройте например Hackerrank и возьмите задачу пусть даже не Expert, а Hard.

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


                1. nobodyhave Автор
                  22.08.2018 16:42
                  #19021499

                  Дак задачки из жизни они такие же ) Можно в реальной задаче увидеть знакомый паттерн, и решить путем применения известных вещей. А можно изобрести велосипед.
                  Опять же, задача обычно разбивается на подзадачи. Каждую из них можно решить каким-то способом. Была вот одна интересная Hard задачка. Там в одной из ее частей надо было делать RangeMinQuery. Стандартная вещь, даже банальная, но ни один из четырех опробованных вариантов не прошел по скорости, так как это было «узкое место» в задаче. В итоге после пары часов раздумий придумался вариант, использующий еще более банальные prefix sum, но сделанные очень нестандартным способом. И взлетело. Помогло ли мне знание стандартных алгоритмов? Скорее нет. Помогли ли мне навыки решения задач с их использованием? Да, я смог взглянуть на проблему с разных сторон, примерить разные решения и найти верное, пусть и не очевидное.


                  1. Druu
                    22.08.2018 17:38
                    #19021765

                    Стандартная вещь, даже банальная, но ни один из четырех опробованных вариантов не прошел по скорости

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


                    Например вот:
                    https://www.hackerrank.com/challenges/build-a-string/problem


                    Понятно что решается динамикой за O(n^3), и интуитивно понятно, что такой вариант не пройдет. Но сколько надо? O(n^2logn)? O(n^2)? меньше?


                    1. nobodyhave Автор
                      22.08.2018 17:53
                      #19021847

                      Для Java по опыту знаю, что в 4 секунды укладывается решение с
                      5х10^7 — 10^8 операций, зависит от сложности операции.
                      У нас 3 теста, каждый по сложности в худшем случае 30000, т.е уже получаем примерно 100 000. Т.е. тут вырисовывается что-то в духе O(N*lgN*lgN) или O(N*sqrt(N)).
                      И опять же — в реальной задаче вам никто не скажет сложность. В лучшем случае ограничение по времени, как и здесь. А уже ваша задача подобрать сложность, чтобы влезть в ограничения.


                      1. Druu
                        22.08.2018 17:56
                        #19021877

                        И опять же — в реальной задаче вам никто не скажет сложность.

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


                        1. nobodyhave Автор
                          22.08.2018 17:59
                          #19021893

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


                          1. Druu
                            22.08.2018 18:04
                            #19021943

                            Почему не пройдет?

                            Ну там же время не пишут? Просто говорят, что "нишмогла" за ограничение, так?


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

                            Но у них же не мой компуктер.


                            1. nobodyhave Автор
                              22.08.2018 18:09
                              #19021963

                              Просто говорят, что «нишмогла»
                              Это да, потому и пишу тесты.
                              По многим задачам есть открытые тесты. И пишут, сколько по времени ушло на тест. Возьмите такой тест и прогоните у себя на машине. Теперь вы знаете, насколько ваш комп быстрее.
                              Мой был в 2-3 раза. Т.е. если я вижу, что решение худшего случая на моей машине 10 секунд, я близок к цели. Считает уже минуту — точно мимо.


              1. Druu
                22.08.2018 16:35
                #19021443

                deleted


            1. khayrov
              22.08.2018 16:54
              #19021581

              Да никогда не бывает такого, что нету таски, в которой не завязано совсем на все.

              Дело не в количестве непосредственных зависимостей задачи, а в размере полного графа транзитивных зависимостей. В случае Гугла получается, что ближайшая система, о которой внешний кандидат может иметь хоть какое-то представление, находится в 3-4 шагах от начальной точки. Единственный выход: заменять конкретику на абстрактные расплывчатые описания, что примерно эта подсистема делает и какие у неё ограничения. Но system design собеседования примерно на таком уровне детализации и ведутся.


      1. da-nie
        22.08.2018 13:20
        #19020471

        А как по другим профессиям людей набирают? :)


        1. tyomitch
          22.08.2018 13:45
          #19020577

          Я не знаю как. Кроме как программистом, я работал только дояром в коровнике, но там конкурса на вакансию не было :-)
          Если хотите рассказать, как набирают людей по другим профессиям — буду рад.


      1. 0xd34df00d
        22.08.2018 16:56
        #19021595

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


        1. Druu
          22.08.2018 17:40
          #19021779

          А если нет гитхаба соискателя — то гитхаб работодателя! :)


          1. 0xd34df00d
            22.08.2018 18:10
            #19021969
            +1

            А это, кстати, вполне серьёзно может быть одним из критериев выбора работодателя.


            1. artemmityushov
              23.08.2018 08:56
              #19023659
              +1

              А вот зачем личный гитхаб для человека у которого нет личных проектов на энтузиазме? Ну вот мне 37, у меня работа, семья, тренировки, откуда мне взять время на личные проекты? Ну вот правда, завидую тем кто может все это совмещать, но чем больше живу тем больше прихожу к мнению что все это «ложь, пи… шь и провокация», ну не верю я в такие вещи, иначе у человека что-то должно просаживаться, например работа текущая не пыльная, занят часа три, а дальше может своим заниматься, либо с семьей общается на отъ… сь, либо спорт в виде зарядки 10 минут утром. Ну вот как все это совместить хотя бы в 18 часов в день и не свихнуться не представляю.


              1. fukkit
                23.08.2018 10:14
                #19023999

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


              1. 0xd34df00d
                23.08.2018 16:52
                #19025823

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

                Спорт — два раза в неделю кардио по выходным (в процессе которого я могу читать не шибко заумные статьи и книги, Шеня по матлогике так не почитаешь, а вот Parallel and Concurrent Programming in Haskell — вполне), плюс пешком на работу и обратно 25 минут в один конец быстрым шагом. Да, ерунда, кубиков на пузе и здоровенной бицухи нет, но 12 кило за 8 месяцев я потерял, да и на ожидаемую продолжительность жизни оно влияет весьма положительно.

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


  1. Ilias
    22.08.2018 14:44
    #19020843

    Подскажите, пожалуйста, на каких по сложности задачах с hackerrank лучше тренироваться (имеется в виду practice, не соревнования на время)? Medium или Hard уже?
    На самих интервью какой приблизительно сложности алгоритмические задачи были?


    1. nobodyhave Автор
      22.08.2018 15:56
      #19021211

      Если смотреть Hackerrank, то интервью ближе к Medium, может между Medium и Hard. Если смотреть Leetcode, то Medium и Hard. Leetcode в принципе полегче


      1. Ilias
        22.08.2018 16:39
        #19021481

        Забыл спросить, насколько сильно вас подтянули курсы на курсере и книги по алгоритмам? До их прохождения/прочтения вы могли решать hard и medium задачи с Hackerrank?


        1. nobodyhave Автор
          22.08.2018 16:48
          #19021541

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


          1. Ilias
            22.08.2018 16:50
            #19021555

            Спасибо большое, буду тренироваться.


  1. dadyjo
    22.08.2018 15:32
    #19021081
    -1

    «Как подготовиться к собеседованию в Google и не пройти его. Дважды» —
    С такой подготовкой только и остается, что работать в Яндекс Такси — Таксистом!"


  1. zim32
    22.08.2018 18:19
    #19022031
    +1

    Странно мне всегда казалось что там ищут креативных людей, а не "доводить до автоматизма". Ну его этот гугл


    1. Gugic
      22.08.2018 19:38
      #19022283
      +1

      Там ищут людей способных решать поставленные задачи оптимальными способами. Собеседования людей способных ставить задачи проходит по-другому.