company_banner

Как собеседует Google: чему быть, чего не миновать

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

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

    Нет, я не стал рекрутером. Процесс собеседования предполагает сперва разговор с рекрутером. Это общая беседа “что-куда-зачем” (то есть описание процесса для вашего конкретного случая) и тот самый всеми любимый скрининг из опросника с несколькими вариантами ответов. Скрининг мне в своё время показался весьма базовым, подозреваю, что вы отвечали на такие вопросы уже сотню раз. Затем собеседования будут проводиться уже инженерами — вашими будущими коллегами (близкими или далёкими, это уже как получится, наша планета весьма небольшая).

    (Важно: я описываю процесс как я знаю, на инженерные позиции (Software Engineer (SWE) и Site Reliability Engineer (SRE)). Для интернов процесс меняется; равно как и процесс в принципе может отличаться, так как HR отдел адаптируют процесс для достижения наилучшего эффекта. Используйте информацию приведенную тут только для того, чтобы примерно представлять чего ждать — но никак не публичную оферту! Точной информацией о том, как будет процесс проходить для вас лично, будет только и исключительно информация от вашего рекрутера. Информация также может уже устареть — смотрите раздел How We Hire для актуальной информации на момент чтения статьи).

    Сперва будет несколько собеседований через hangouts/meet. Это уже полноценное собеседование, как я выше сказал — собеседуют инженеры, и предполагается, что кандидат в процессе будет “думать вслух” + напишет десяток-другой строк на каком-либо языке программирования (да, к сожалению, пока в гуглодоках).

    Моё собеседование рассчитано на ~45 плюс-минус десять минут, но обычно стараюсь вписаться ровно в 45 минут. Из этого времени пять минут на краткое знакомство и общие сведения, 30-35 минут на вопросы и дискуссию, затем пять минут на вопросы кандидата (если они есть).

    Вообще, целью собеседующего инженера является собрать информацию по нескольким осям навыков кандидата (таких как умение кодить, знание алгоритмов и структур данных и т.п.). Но самое важное на собеседовании — узнать как человек думает. То есть всегда важно найти ту границу, когда человек не знает решения. Каждый собеседующий имеет свою технику (особенно для телефонных интервью): кто-то держит в запасе десяток вопросов от разминочных (решение которых буквально — написать цикл в три строчки) до сложных даже для объяснения. Кто-то имеет 2-3 “любимых” вопроса, любой из которых можно повернуть десятком сторон и как упростить, так и усложнить — в зависимости от того, что демонстрирует собеседник. Уверен, есть еще варианты, но я о них не знаю.

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

    Так же тривиально задаются вопросы “а почему вы уверены, что оно работает?” (если кандидат не описал сразу границы применимости или тесты), и какова сложность полученного решения. Это просто даёт информацию о том, что кандидат умеет кодить и понимает что он написал. Но мало кодить — надо уметь думать, поэтому следом идут вопросы: а как избавиться от ограничений? Как сделать лучше? Либо (что бывает, когда кандидат очень хорош или просто знает решение по опыту) как сделать так, чтобы код работал при вот таких или иных дополнительных ограничениях.

    Это даёт сразу пачку сигналов — а насколько кандидат умеет адаптироваться к изменениям в задании? А насколько готов подумать о сильно альтернативных решениях? Само обсуждение тоже представляет интерес — вопрос задаётся всегда максимально открыто, поэтому есть десятки способов его понять. Уточняется ли бизнес-окружение, или только технические ограничения? А учитываются ли технические ограничения? Например, несколько раз было, что я говорю “ожидается 1e12 объектов”, и кандидат не оценивает сколько это. А это почти терабайт, если по байту на объект. Или ~116.5 гигабайт если по биту. Или 4.3 терабайта если по int32. Ну вы поняли. Нет, помнить это не обязательно — не на экзамене, калькулятор никто не отбирал же. В телефоне есть, да даже в поиске. И, кстати, можно спросить.

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

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

    Хотите конкретики? Вот один из вопросов, которые вам НЕ зададут просто потому, что он считается уже “утекшим” — то есть велика вероятность, что кандидат будет не думать над ним, а вспоминать. Как я писал выше — важно как кандидат думает, а не как он вспоминает… Так вот, вопрос: реализовать LRU кеш.

    Вообще задача прекрасна, так как позволяет множество форм задания и множество форм трактовки. Например, можно задать вопрос прямо в лоб “реализуйте LRU кеш”. Можно сформулировать как “представьте, что наш сервис для обработки запроса проверяет существование внешнего объекта. Как можно ускорить обработку?” — ожидая очень очевидное предложение “давайте просто кешировать результат”. На что можно будет спросить “а как?”. И “а как, если мы хотим контролировать максимум памяти, потребляемую этим кешем?”. Вопрос оставляет открытым — а какой API должен предоставлять этот кеш. Для простоты всегда можно свести к set(key, value)+get(key); но можно добавить TTL. Можно с get(key, fetch_func). Вообще, оценка предложенного API тоже может дать дополнительный сигнал об опыте и стиле мышления кандидата.

    Тривиальное решение на hashmap даст O(1) на get() + O(N) на set() (это же так, да?). Если все элементы дополнительно слинковать (организовав double link), можно будет получить O(1) на обе операции. Если надо добавить TTL… Думаю, идея ясна. Если есть желание, давайте обсудим в комментариях: представьте что вам задали этот вопрос, как вы будете думать? какое решение предложите?..

    А, на каком языке программирования? Да какой нравится, в каком сильнее всего. C++? Чудесно. Go? Замечательно. Python? Всегда пожалуйста. Perl? Нынче редок, но тоже да. И Java да. И javascript (хоть тут и сложнее с учетом памяти у решения).

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

    После телефонного собеседования, на основании отчетов всех собеседовавших, принимается решение о приглашении на очную ставку. Это будет полный день собеседований в одном из офисов: несколько собеседований с утра, потом обед (и знакомство со столовой в офисе :) и потом еще парочка. При собеседовании на SRE это будут разные интервью, список которых вам сообщит рекрутер, в числе которых кодинг и обязательно NALSD: Non-Abstract Large-Scale System Design. Ключевое — non-abstract (то есть не общие слова “нам понадобится база данных”) и “large scale” (то есть если база и понадобится — то под петабайты, например). Подробнее можно почитать тут и еще много где найти материалы в поиске. Мне несколько ссылок для подготовки скидывал рекрутер. Это очень важный момент собеседования — просто потому, что работая в компании масштаба гугла, приходится думать и рассматривать системы с таких сторон.

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

    Что еще могу добавить о процессе собеседования? Have fun! Нет, серьёзно, расслабьтесь и получайте удовольствие! Телефонное собеседование? Просто разговор с интересным собеседником. Гарантированы новая информация и новый опыт. Очные собеседования? Еще веселей! Вы в командировке за счет будущего работодателя :) Прогуляйтесь по городу, встретьтесь со знакомыми. Также гарантирован полный день развлечений и интересных бесед.

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

    Есть какие-то вопросы? Задавайте в комментариях.
    Есть интерес попробовать собеседование до самого собеседования? Есть сервисы для mock interview (например раз и два, но они не от самой компании, так что никаких гарантий); иногда Google проводит аналогичные кампании.

    И да, не стесняйтесь подать заявку сами. Если верите в магию “подачи через сотрудника” — пишите мне, я внесу вашу заявку. Вэлкам!

    Google

    97,00

    Филин Лаки

    Поделиться публикацией

    Похожие публикации

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

      PS Ах да, /голосом Сухорукова из Брата 2/ «Вы мне еще за Panoramio ответите!»
        +13
        Если всех этих людей чем-то не занимать, то они начнут расползаться. Поэтому они начинают плодить уже даже не вторичные фреймворки, нафиг никому не упавшие. Потом это же тянут в прод, чтобы оправдать усилия на их разработку, ко всему этому привлекается армия дизайнеров и фронтендеров, которые хотят красивенько, а не производительно. И получается тормозящий GMail, до кучи ломающий поведение кнопки назад в браузере и вводящий свою (ЗАЧЕМ?!), а также 3D на гуглокартах, чтобы вы каждый раз задумывались о смене своего компа, когда их открываете.
        +2
        Все данные собеседований собираются воедино
        За этот год можно систематизировать свои знания и заполнить обнаруженные пропуски.
        Существует ли способ узнать, что именно не устроило независимый комитет, или при заполнении пропусков нужно ориентироваться только на то, что ты сам посчитал тем, что могло не устроить независимый комитет?
          +1

          Отчёт о собеседовании не доступен, но HR обычно транслируют что прошло не очень хорошо.

            0
            del
              0
              А как же GDPR?


              всё, что можно получить в соответствии с законодательством — можно получить в соответствии с законодательством.
              я не знаю применим ли GDPR в данном случае, поэтому ничего сказать не смогу.
          +4
          я описываю процесс как я знаю, на инженерные позиции


          Либо я чего-то не понял, либо одно из двух. Собеседование на позицию инженера включает в себя подозрительно много кодинга? Я с трудом представляю себе ситуацию, когда, например, network engineer-у нужно будет быстренько нарисовать LRU-кэш.
            0
            Хм. Вообще, учитывая вещи типа ai.google/research/pubs/pub43837 — да, даже сетевику это может потребоваться.
            Но да, как у них — я не знаю. Я пишу про SWE/SRE — добавил это в статью.
              +3

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

              +1
              У сетевиков другое интервью.
              Собственно, я с трудом могу сказать «другое», т.к. автор про интервью не написал почти ничего.
              +1

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

                +2
                Гугл набирает людей надолго, возможно даже навсегда. Поэтому залипать на какую-либо технологию и/или язык не получится. Выбор языка всегда вопрос баланса скорости разработки, стоимости поддержки и личных вкусовых предпочтений разработчика.
                Выбирать команду можно под свой любимый язык, если так хочется; ну либо команде объяснить почему взять именно этот язык.
                Таки что да. У меня есть бейджик за коммиты на 25+ языках, но это по сути типы файлов, которые я трогал ручками (включая ascii proto, json и т.п.). Из языков программирования лично трогал bash, bcl, c++, go, python, java, javascript. Может еще что было по мелочи, уже не помню.
                  0
                  > Гугл набирает людей надолго, возможно даже навсегда.

                  www.businessinsider.de/employee-retention-rate-top-tech-companies-2017-8?r=US&IR=T — Пишут 1.9 года в гугле в среднем работают.
                    0
                    На основании данных людей, кто оттуда ушел?
                      0
                      В этой статье не указано, но вот другая — www.businessinsider.com/average-employee-tenure-retention-at-top-tech-companies-2018-4?international=true&r=US&IR=T с другими цифрами и с небольшим описанием как собирали:

                      Turnover rates are drawn from LinkedIn’s member data. We calculate turnover by taking the number of departures/movement in a given population (e.g., the retail sector, the restaurant industry, or data analysts), then dividing that number by the average headcount of that given population in 2017. We consider professionals as leaving their position if they provide an end-date for their position at a company (excluding internal job changes within the same company). A member can have multiple departures and positions within the year period.


                      Вроде бы логично
                        –2
                        То есть только на основании тех, кто использует LinkedIn. Что далеко от средней популяции по больнице.
                          +3

                          Что, думаю более чем достаточно для исследования. Кто не использует линкедин в долине?

                            –2
                            Это требует отдельного исследования :)
                            Ну и тогда не «в гугле» а «в гугле в долине».

                            Сейчас в гугле согласно последнего отчета ~85000 человек.
                            Согласно это статье в долине раньше была треть человек. То есть минимум две трети (~56 тысяч) не в долине и сомнительно что охвачена линкедином.

                            а еще сейчас глянул — на странице www.linkedin.com/company/google указано что там работает 153 тысячи… то есть в два раза больше, чем сотрудников в компании вообще.
                            в общем, как-то сбор данных странных.
                              0

                              В любом случае не понимаю в чём спор. Вы серьезно думаете, что люди работают в 1ой компании всю жизнь?

                                0
                                Я говорю что цель компании — нанять человека на долгий срок.
                                Вы приводите разные оценки с потолка что некоторые люди меняют место работы через то-ли 2 то-ли 3 года.

                                Ни то ни другое друг другу не противоречит, я просто указываю, что эта цифра не имеет никакого отношения.
                                  0
                                  > эта цифра не имеет никакого отношения.
                                  К чему?

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

                                    Но если все одинаково оценены и наняты гарантированно все проходящие под общие требования, внутренний трансфер становится гораздо проще.

                                    Кстати, даже для такой вещи, сюрприз!, нужны алгоритмы ;)
                                    См. тут. У меня перед глазами достаточно примеров перехода людей между командами.

                                    Таким образом, если сменить команду проще, чем сменить компанию, то люди будут оставаться в компании, а значит, расходы на интервью не будут увеличены на затраты для замены этого человека.
                                0
                                а еще сейчас глянул — на странице www.linkedin.com/company/google указано что там работает 153 тысячи… то есть в два раза больше, чем сотрудников в компании вообще.
                                в общем, как-то сбор данных странных.

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

                                  (когда я прописал что теперь работаю в гугле — у меня был десяток писем разных рекрутёров из разных контор «а не хотите ли к нам?», включая тех, кто обещал оплатить затраты на ранний выход если будут)
                            0
                            Судя по описанию методики, интерны в гугле имеют на эту статистику такое же влияние, как младенческая смертность на среднюю продолжительность жизни — практически ноль в числителе и +1 в знаменателе. Опять же гугл это такой интерншип который воткнут в профиль все, у кого он был. В итоге пять летних интернов и Сергей Брин в сумме приносят около трех лет как средний срок работы в компании.
                          0
                          Это не похоже на истину. Я работаю в Google UK с февраля, за это время из тех пары десятков людей, с кем я более или менее регулярно общаюсь, не ушел никто.
                            +2
                            То что с февраля и то что 20 человек и то что UK, возможно дает другие цифры. Выше комментарий с более вменяемым иследование, чем то что я показал ранее.
                              +1
                              Выше написано, что среднее время работы — 3.2 года. То есть, из, скажем, 20 человек, которых я регулярно наблюдаю, за 7 месяцев должны были уволиться в среднем 3.65. А уволилось 0. То есть, не очень похоже на правду (хотя, конечно, такое совпадение не невероятно).
                                +1
                                Вы как-то странно считаете вероятность.
                                Если в каждом месяце сотрудник с постоянной вероятностью либо увольняется, либо нет — то это распределение Пуассона с матожиданием 3.2 года = 38.4 мес.
                                При этом вероятность, что сотрудник уволится за 7 месяцев, неотличима от нуля; и только на 17 месяцах достигает 0.01%.
                                  0
                                  Ах, если бы эти «исследования» считали среднее время работы матожиданием пуассона…
                                    0
                                    Но я же работаю не в окружении людей, которых наняли одновременно со мной. Из этих людей половина работают дольше указанных трех лет. Какова вероятность, что ни один из них не уволится за семь месяцев, в вашей модели с распределением Пуассона?
                                      0
                                      Точно такая же.

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

                                        Матожидание количества уволившихся из 20 человек за 7 месяцев неотличимо от нуля. Это же верно и для вторых 7 месяцев, и ..., и для шестых. То есть, Матожидание количества уволившихся за 42 месяца тоже неотличимо от нуля (пусть и чуть побольше). Но матожидание срока работы в компании — 38.4 месяца.
                                        Я вижу здесь противоречие.
                                          0
                                          Если вероятность остаться после одного месяца равна p, то вероятность остаться после n месяцев — это pn, а не p·n.
                                            +2
                                            1-pn — это приближение снизу для выражения (1-p)^n. Если хотите, можно честно посчитать, без всяких приближений.

                                            Будем считать, что события «человек уволился в течение месяца» независимы и одинаково распределены для всех людей и месяцев и имеют распределение Бернулли с параметром p. Матожидание времени работы в месяцах равно 0*p + 1*p*(1-p) + 2*p*(1-p)^2 +… + k*p*(1-p)^k +… = (1-p)/p = 38.4. Отсюда p = 1/39.4 ≈ 0.025. Вероятность, что один человек не уволится за 7 месяцев, равна (1-p)^7, а вероятность, что за 7 месяцев не уволятся 20 человек, равна (1-p)^140 ≈ 0.027. То есть, вероятность того, что я наблюдал то, что я наблюдал, получается достаточно низкой. О чем я с самого начала и написал, пусть и менее строго.
                                            PS: Так и не понял, при чем тут распределение Пуассона, оно же показывает вероятность того, что из х одинаковых событий k произойдут. Мне не интересно, сколько раз кто-то уволится за 38.4 месяцев, мне интересно, какова вероятность того, что кто-то уволится за 7.
                            +2
                            Из языков программирования лично трогал bash, bcl, c++, go, python, java, javascript. Может еще что было по мелочи, уже не помню.
                            Я помню!) — asm:)
                            Эта статья ПИД-регулятор своими руками в закладках, в надежде, что когда-нибудь на ее основе напишу на С для stm32
                              +1
                              В гугле я асм еще не трогал :) не было нужды. Только в дизасме копался во время разбирательства.
                            +1

                            У меня собеседование проходило на джаве, а 80% времени приходилось писать на питоне и внутреннем языке для конфигов.

                              0

                              Ну вы ведь сами команду выбирали?

                              0
                              Про языки в Google

                              image

                              +24
                              Годы идут, а воз и ныне там…

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

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

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

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

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

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

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

                                В целом, процесс собеседования модифицируется со временем и адаптируется (да, вы верно заметили — крышки люков больше никто не просит посчитать), но эти изменения не идут с бухты-барахты. Это всё «data-driven» осознанные изменения с оцененной и подтвержденной эффективностью.
                                  +13
                                  Вы «защищаетесь» не с той стороны, с которой я «нападаю».

                                  А на счет домашней заготовки, ну это еще не факт, что хорошо. Есть люди, которые хорошо проходят интервью, а есть те, кто хорошо работают, и это далеко не одни и те же люди. Зайдите на любой сайт, посвященный теме интервью, первое, что вы там увидите «I will teach you to be good at programming interviews» написанное разными словами. То есть это как минимум говорит о том, что проходить интервью и работать это две большие разницы. Это УЖЕ должно наводить на мысль о том, что система сломана.
                                    +1
                                    :) да, есть профессиональные проходители интервью.
                                    Тоже уже встречал, видно практически сразу.
                                    Это всего лишь сокращает первую фазу до 2-5 минут.
                                    А дальше начинается изучение как они думают вне стандартного интервью.

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

                                      И это еще одна «грань» вышеупомянутого айсберга. Способности потенциального работника ставятся выше его мотивации, хотя без должной мотивации сотрудник будет больше вреда приносить, чем пользы, вне зависимости от его навыков.
                                        0
                                        Гляньте тут: careers.google.com/how-we-hire/interview/#onsite-interviews
                                        мотивация и его googlyness тоже оцениваются.

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

                                        все в выигрыше, разве нет?
                                          +4
                                          Ну тут тот же эффект как в инвестировании: инвестировать в компании, которые еще не прибыльные опасно, но им очень нужны инвестиции, а инвестировать в компании, которые уже вышли на прибыль сложно, потому что все хотят туда инвестировать, а инвестиции этим компаниям уже могут быть и не нужны.

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

                                          Вообще на вопрос о мотивации — если человек на собеседовании приходит с низкой мотивацией, а потом его удается «разогреть» это как раз лучше, чем нанять «гуглофана», потому что в голову-то не залезешь, этот гуглофан может быть кем угодно от инсайдера до интервьюкракера. А вот если человек не очень-то хочет работать в гугле, то это не просто же так. На интервью его наверняка соблазнил HR. Всегда было интересно, что бы ответил интервьюер, которому кандидат скажет: «мне че-то лень печатать, давай я тебе продиктую код, а ты сам запишешь»…
                                            0
                                            Я на NALSD собеседовании описывал всю систему из головы. Без вайтборда (я до сих пор так и не научился пользоваться ею!). Итервьюер протоколировал всё в конспект. После еще и нарисовал на доске как он меня понял, и мы обсудили моменты где у него были сомнения.

                                            У меня пока такого не было, но я в пометки себе вношу всё что кандидат думает в слух а не записывает, чтобы не потерять.
                                            +1
                                            — один раз только на одну компанию

                                            Не соглашусь, я вот ездил в Амазон чисто потому что уже обещал приехать на собеседование, хотя оффер принял для другой компании. И снова зовут приехать.
                                              +3
                                              Ну у них наверно KPI завязан на число собеседуемых, а то что компания от этого деньги теряет, никого не волнует. И так во всем. А все почему, потому что нанимают не тех, кто будет отстаивать интересы компании и быть «в доле» с компанией, а нанимают абы как абы кого лишь бы мог «очередь реализовать двумя стеками с амортизационной сложностью О(1)». Остальные специальности наверно так же нанимают… И тут вы скажете «как ты смеешь критиковать компанию, которая стоит триллиард долларов», а я возражу, что система сломана не только внутри компаний, но и снаружи. Самые умные люди в мире в среднем это все-таки ученые, но в среднем они не самые богатые. Хотя без ученых эти триллиард как цифра не существовала бы :)
                                                +2
                                                Все эта сложная система собеседований мне не по душе, это как билет в закрытый клуб.

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

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

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

                                                  +2
                                                  А крупные компании вообще хотя бы кого-то могут слить через год? Во всех крупных компаниях, где я работал, была процедура «перевоспитания» на год-два как минимум. В первую очередь, чтобы не было исков о неправомерном увольнении.
                                                    +4
                                                    В USA еще есть небольшая вероятность быть уволенным из большой компании, а в Европе практически не реально. В потолок можно плевать годами.
                                                      0
                                                      «Небольшая вероятность»? Почитайте, пожалуйста, что означает «employment at will».
                                                        +1
                                                        А вы задуматесь над тем почему в некоторых источниках говорится о восьмидесяти тысячах сотрудников Гугла, в некоторых — о ста шестидесяти и при этом между этими данными нет противоречия.

                                                        И да — это-таки имеет самое прямое отношение к «employment at will» и не только в Гугле.
                                                          0
                                                          Р — релевантность.

                                                          А противоречие есть. В отличии от вас, говорить загадками либо отвечать на ваши в этом конкретном случае я не имею права.
                                                            0
                                                            Очень просто: восемьдесят тысяч — это сотрудники Гугла без учёта контракторов (тех, которые «employment at will»), сто шестьдесят — с учётом. Это не секрет — если бы вы вместо того, чтобы «вставать в позу» погуглили бы, то могли бы найти, скажем, вот эту статью.

                                                            При этом таки большинство SWE/SRE — это вовсе не контракторы… почему из и отбирают по несколько более сложной схеме, чем поваров или уборщиков.
                                                              0
                                                              Р — релевантность.
                                                              У — упорство.

                                                              Расскажите мне, пожалуйста, как постоянные работники Google в США не имеют строчки про «employment at will» в контракте.
                                                        0
                                                        Думаю, США не особо отличается от Канады, где увольняют просто со свистом независимо от размера компании.
                                          +13

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


                                          При этом это был единственный момент, когда что-то в диалоге с собеседующим явно собеседующего не устроило. А теперь rant: ну не хочу я ботать эти ваши Ахо-Корасик и сложные алгоритмы на графах (это я о клипах, простой поиск пути ок). Сейчас в индустрии есть полно куда более полезных и, имхо, важных вещей вроде: пресловутая иерархия памяти (почему B+ лучше бинарных деревьев, и т.п.), многопоточная синхронизация и модели памяти (приходилось методом пристального взгляда искать состояние гонки в большой системе), безопасность (в любом баш скрипте в Амазоне, которые я видел это — полный ахтунг, никогда не используйте баш). Из недавнего — deep learning, как минимум принципы которого надо бы понимать, и где алгоритмы, каждый сложнее Ахо-Корасика, выпускают по 2-3 в год. Ну и, конечно, пресловутый блок-чейн (инженер FB не знал про существование и смысл SHA256, и не смог или не захотел понять решение задачи, включающее вероятность ошибки из-за коллизии в 10^-41 в течении 30 лет по тем ограничениям, которые он сам задал. И это ещё не полный список.

                                            0

                                            Прошу прощения за ошибки и опечатки — набирал с телефона.

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

                                              у меня есть программы которыми пользовались много лет. даже без модификации.
                                              и нет, я ими не горжусь, и даже постыжусь показывать…
                                                +1
                                                Если они приносили пользу, то все в порядке.
                                              +1
                                              Я, когда не прошел интервью в Гугле, решил собрать немножко статистики с интернета и посмотреть отзывы тех кто прошел. Конечно очень субьективно и выборка маленькая, но усредненно выглядит примерно так:
                                              «Я после колледжа проработал несколько месяцев в одной компании, решил что меня это не устраивает и стал готовиться к интервью в Гугле. Я уволился с работы и 6 месяцев готовился по книгам и тестовым заданиям. Теперь я работаю в Гугле, счастлив и всем того же желаю.»
                                              Обратите внимание — человек практически без опыта, зато потративший много времени и усилий именно на подготовку к интервью и именно в Гугле. Мне кажется, ихняя система отбора самонастроилась на именно таких кандидатов, как бы она там изначально не была задумана.
                                                0
                                                Вы читали недавнюю статью nobodyhave?
                                                  +1
                                                  Вот, с вашей подачи прочитал. По моему очень типичный сценарий, только мотивация другая — автор изначально был настроен учиться, а подготовка к интервью выбрана как повод. Но обьем проделанной работы просто подавляет, вот в этом мне и кажется основная проблема — средний соискатель как правило физически не может пройти такое количество курсов и тестов за ограниченное время. Остаются самые мотивированные, но не обязательно самые лучшие. Кстати, если вы заметили, у автора тоже звучит мотив что само по себе изучение алгоримов в повседневной разработке не слишком полезно, а через пару лет без использования они забываются.
                                                  Короче, да, это примено то что я имел ввиду.
                                                    +2
                                                    Не совсем так ) Я бы сказал, что изученные алгоритмы не используются в повседневной разработке. И забываются.
                                                    А вот изучение алгоритмов, как процесс, вполне себе помогает в повседневной разработке. Позволяет по другому взглянуть на задачи.
                                                    А то что алгоритмы забываются, это не проблема. Вспомнить то, что знаешь, гораздо проще, чем это выучить. И опять же есть знание, что в какой ситуации использовать.
                                                      0
                                                      Ну, там в было в контексте, не будем спорить.
                                                      Давайте я лучше скажу что я восхищен вашей работоспособностью )
                                                      0
                                                      Сами алгоритмы и структуры данных не занимаешься реализацией на повседневной основе. А вот решения принимаешь повседневные обоснованно и разумно, а не «так повелось». Выбирая между hashmap и treemap понимать что это не просто O(1) vs O(logN) на выборку; да и O(1) не всегда могут быть гарантированы у первого; и что порой лучше всё же vector, пусть даже надо поиск будет по нему делать.
                                                      И учишься комбинировать структуры. Тот же hashmap где все элементы слинкованы двоичным списком — для LRU кеша, например.
                                                        0

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

                                                          +1
                                                          Вообще-то, все что я хотел сказать, студенты-отличники имеют по моему мнению некоторое преимущество при прохождении интервью такого типа, может это и неплохо.
                                                          Как бы оценка в дипломе и должна описывать качество специалиста… что разумеется не всегда так (именно поэтому приходится проводить интервью я не брать на работу тупо на основании CGPA), но если бы корелляции не было совсем — то это обозначало бы, что вся система высшего образования вообще не имеет никакого смысла — а это, всё-таки, уже перебор…
                                                            0
                                                            Нет-нет, я не об этом совсем. Просто есть очень большая разница между сколько угодно хорошим студентом и специалистом скажем с десятиленим опытом. Здесь даже не лучше-хуже, просто другой подход к работе. В хорошей компании нужен баланс, иначе возникают последствия разные.
                                                              0

                                                              Да. При найме, кстати, на возраст не смотрят.
                                                              Я прошёл интервью без подготовки, через 8 лет после универа. Отличником не был :D


                                                              Так вот. Нанимают определённых людей, да. Нет, натренироваться на интервью можно, но шансов не так много. В конце концов, 14% ошибки все же остаются.

                                                                0

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

                                                                  0
                                                                  Однако существует такая модная практика — кандидат должен пообщаться с каждым членом будущей команды и быть им одобренным.
                                                                  Сомневаюсь, что она практикуется в Гугле. Странно сочеталось бы с отсуствием интервьюеров в комитете…

                                                                  Вот это не по слухам и не по впечатлениям, я точно знаю.
                                                                  Это про Гугл или про какие-то модные стартапы?
                                                                    0
                                                                    Нет, в Гугле такого нет. Но это были и не стартапы — большие и известные компании, два раза минимум.
                                                                      0
                                                                      Не пугайте так. :)
                                                                        0
                                                                        Вам еще далеко :)
                                                                    0
                                                                    первым делом дают список литературы для подготовки.
                                                                    Это логично. Раз большинство готовится — проще дать всем одинаковые материалы и спрашивать как с подготовленных, чем пытаться выяснить, готовился ли человек и почему.
                                                                    0
                                                                    Ну вот на сложность алгоритмов имеет смысл надрочиться перед собеседованиями, просто потому что в жизни точный ответ нужен редко, при принятии архитектурных решений.
                                                                    А это происходит гораздо реже, чем просто написание кода
                                                                      +1
                                                                      Это просто навык, который уходит в бэкграунд. Если попробуешь написать потом что-то кубическое, появится очень неприятное ощущение что что-то происходит не то.
                                                                        +1
                                                                        А это происходит гораздо реже, чем просто написание кода
                                                                        Это происходит при написании кода. Постоянно. То есть вы видите — на входе массив. И вы написали цикл, а внутри него find. В голове сразу звоночек: «так, у нас задача вроде как линейная, а я тут квардрат, вроде как устроил… что я делаю не так». Смотрим на find, обнаруживаем, что он срабатывает один раз или ни разу — успокаиваемся.

                                                                        Шлемиэли встречаются куда чаще, чем нам бы того хотелось, увы — и хочется, чтобы у разрабочика был в голове звоночек, который бы срабатывал, когда он их видит…
                                                                0
                                                                А где полезно самому LinkedHashMap писать кроме собеседований в гугле, не подскажете?
                                                                  0
                                                                  Работа с файлами ресурсов, например.
                                                                  Чтоб быстро как достать по имени, так и проитерировать в нужном порядке.
                                                                    0
                                                                    Я спрашивал про писать, а не использовать. Использую я сам весьма часто, но зачем кому-то понадобится писать свою имплементацию — вот это непонятно.
                                                                      0
                                                                      Например, если нужны дополнительные операции, типа поменять местами два определенных элемента.
                                                                      Еще, насколько помню, в stdlib/stl нет эквивалента LHM.

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

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

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

                                                                          0
                                                                          Сделать. Можно простую обертку сделать например как тут android.googlesource.com/platform/frameworks/support.git/+/795b97d901e1793dac5c3e67d43c96a758fec388/v4/java/android/support/v4/util/LruCache.java

                                                                          Два элемента в LRU местами менять смысла не имеет вообще никакого, т.к. это попахивает сортировкой связного списка. Но я согласен что это полезно знать что элементы хэш таблицы можно линковать. И еще полезнее знать что для большинства применений это либо написано либо делается существенно проще чем написание 'снуля'. Снуль вообще плохо обычно получается, особенно на интервью, особенно когда дают доску размером этак метр на метр и предлагают на нем полную имплементацию хэштаблицы впихнуть (даже не линкованной).
                                                              +3
                                                              Объективный поиск показывает, что такой подход действительно нужен, чтобы отобрать лучших. То что вы нашли, скорее рекламные посты. Но существует другая проблема, которую хорошо иллюстрирует шутка:
                                                              Мы с коллегами часто шутили, представляя себе как Ларри и Сергей выходят в море на своих яхтах, пришвартовывают их рядом друг к другу, садятся в дорогие кресла, которые, несомненно, есть у них на яхтах, наливают себе скотч, раскуривают дорогие сигары и рассматривают фотографии гуглеров с такими маленькими ярлычками вроде “был гендиректором в мультинациональной телеком-корпорации, получил MBA в Гарварде, а сегодня работает в техподдержке Orkut“. А затем они заходятся в безудержном приступе хохота, тушат сигары в скотче и чокаются бокалами. Конечно, этого никогда не могло быть, потому что они не курят и не пьют. А впрочем, все остальное вполне правдоподобно”.
                                                                +2
                                                                был гендиректором в мультинациональной телеком-корпорации, получил MBA в Гарварде, а сегодня работает в техподдержке Orkut
                                                                Некоторых гендиректоров лучше бы не пускать в техподдержку Orkut, а то всё развалят. Впрочем Orkut всё равно закрылся, так что возможно кто-то пролез…
                                                                +1
                                                                У меня история была немного другая — в школьные годы чуть-чуть занимался олимпиадами, в ВУЗе забил. После выпуска пару недель по вечерам после работы чуть подготовился — устроился в Google.
                                                              +2
                                                              Но самое важное на собеседовании — узнать как человек думает.

                                                              Вообще, оценка предложенного API тоже может дать дополнительный сигнал об опыте и стиле мышления кандидата.

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

                                                              Так всётаки, вы оцениваете ход мыслей кандидата или предложенное им решение? Что для вас важнее?
                                                                0
                                                                Нельзя сказать что важно что-то одно. Это отдельные оси оценки кандидата.
                                                                Человека нанимают для работы прямо здесь и сейчас — поэтому человек должен уже уметь писать код. Компания ищет людей на долгий срок — а поэтому человек должен уметь думать и учиться. А так же компания ищет людей, кто будет решать задачи, которые еще не решены (иначе зачем их делать?) в том масштабе или аспекте какой требуется. А значит, надо уметь решать те задачи, которые еще не решены. Или тем способом, которым еще не решали. Именно поэтому важно найти точку где кандидат не знает решения, и смотреть, как будет искать выход.

                                                                Сведение к знакомому алгоритму? Хорошо.
                                                                Преобразование исходных данных? Тоже хорошо.
                                                                Попытка придумать новый алгоритм на ходу? И тоже хорошо!

                                                                Да, за пол часа (которые обычно остаются на этот шаг) редко кто может придумать что-то совсем прорывное, но этого никто и не ждёт. Важно смотреть как будет идти, сможет ли предложить решение, и сможет ли реализовать предложенное хотя бы в некоем подмножестве.
                                                                  +2
                                                                  А что делать людям, которые на практике не работают со сложными алгоритмами и структурами данных? Вот я 10 лет занимаюсь разработкой и мне не требовались ни графы, ни деревья, ни уникальные сортировки. Есть готовые очереди, кэши, сортировки, сессии и т.д.
                                                                  Получается, что людям вроде меня Гугл не светит?
                                                                    +3
                                                                    Ну вы же знаете как они работают? Очереди, кеши, сортировки, сессии? Можете представить как их реализовать? Тот факт, что вы их не пишете — не означает, что вы не можете их написать, если подумаете. Плюс, если что-то не знаете, можно же подготовиться.

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

                                                                      Есть вероятность, что эти люди просто не увидели, что "графы, деревья и уникальные сортировки" и прочие "теоретические" вещи нужны.
                                                                      Мне в своё время (лет 10-20 назад) понадобились:


                                                                      • Диофантовы уравнения и метод ветвей и границ в оптовой торговле фармацевтическими товарами
                                                                      • Реализовать хеш-таблицу и B+ tree в 1С: Бухгалтерии 7.7
                                                                      • Изучить как работает TCP в части three way handshake, модель состояний и работы с SN/ACK SN, чтобы сделать похожий сеансовый обмен между складами
                                                                      • Решить проблемы отсутствия string builder в 1С 8 (при огромном количестве конкатенаций)
                                                                      • Оптимизировать решение систем линейных уровнений в расчете себестоимости.

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

                                                                        +3
                                                                        А вам очень повезло, что у вас за спиной не стоял менеджер и не спрашивал каждые 15 минут, когда будет готово.
                                                                        Я решалку СЛУ еще в колледже вполне успешно писал, но на практике такие вещи не пригодились мне. А там, где могли бы пригодиться, никто не дал бы времени на их реализацию и отладку.
                                                                        К счастью, с 1С я не работал напрямую. Но по опыту знакомых знаю, что это то еще занятие. Была у нас самописная интеграция с 1С. Приходилось на PHP парсить гиговые XML, которые генерировались часами.
                                                                          +2
                                                                          за спиной не стоял менеджер и не спрашивал каждые 15 минут

                                                                          По-разному было. И стоял, и кричал, и не один менеджер. Но я с такими "менеджерами" долго не работаю обычно. Оно того не стоит.


                                                                          никто не дал бы времени

                                                                          Дал бы. Если другого решения нет. С вашими гиговыми XML — если поток XML станет больше, чем может съесть система. Если нерешение проблемы = отзыв лицензии. Обычно получается объяснить, что время нужно. В общем, надо уметь его взять.


                                                                          решалку СЛУ еще в колледже вполне успешно писал

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

                                                                            +2
                                                                            Вы правы, решения зависят от поставленных задач.
                                                                          0
                                                                          Звучит круто!
                                                                          Но получить такое на собеседовании, когда есть 45 минут и не принято отвлекаться ни на конспекты, ни на поиск — это грозит показаться неопытным человеком.
                                                                    +2
                                                                    interviewing.io — private beta for now
                                                                      0
                                                                      спасибо, я слышал отзывы что пользовались им, но сам не пользовался.
                                                                      по сути, это пара рандомных ссылок из поиска (но про которые до меня доходили отзывы).
                                                                      +2
                                                                      gainlo.co еще проводит mock interview
                                                                        0
                                                                        про этих ничего не слышал.
                                                                        +1
                                                                        иногда Google проводит аналогичные кампании

                                                                        можно об этом подробнее?
                                                                          0
                                                                          Слышал про несколько «interview workshop» организованных при университетах и на разных эвентах, навроде www.facebook.com/events/705306866191779
                                                                          Не слежу за ними специально, поэтому как и где их ловить — не знаю.
                                                                          +3

                                                                          SWE это software engineer, a SRE это site reliability engineer, верно?

                                                                            0
                                                                            Да, сейчас довпишу расшифровку, спасибо за замечание
                                                                            +1
                                                                            Какой уровень английского нужен для интервью? Он важен или поняли друг друга и не суть, что не сразу? Локация в Цюрихе, если это имеет значение.

                                                                            Вероятность прохождения интервью зависит от локации или везде выдерживают одинаковые стандарты?
                                                                              0
                                                                              Моего рунглиша без разговорной практики хватило. Вообще надо ~A2 + технические термины.
                                                                              Важно лишь понять, переспрашивать это нормально.
                                                                              Основная цель — поддерживать общий уровень одного стандарта, поэтому локация не должна иметь значения.
                                                                                +7
                                                                                Мне в гугле попался китаец-интервьюер, у которого английского не было буквально совсем. Примитивная речь, кошмарный акцент, и вы спросите: а как же он проводил интервью? А вот как: зашел, пробубнил hello, положил передо мной вырезанный 2x10 кусочек бумаги, на котором было распечатана задача, и просто сидел, перерисовывал себе в блокнот каракули, которые я рисовал у себя на бумажке. В конце он попытался что-то со мной обсудить, выглядел очень жалко.
                                                                                  +1
                                                                                  Мне один раз довелось проводить собеседование на языке, на котором я на тот момент не очень. Подозреваю, это тоже было жалкое зрелище, но зато кандидат внезапно раскрылся не только как хороший специалист, но и как человек, который умеет работать с разными людьми: умение принимать других людей, пытается ли понять, что другие люди хотят и умеет ли адаптировать свои ответы под возможности «клиента» понять. Человек прошел этот тест на ура и до сих пор приносит пользу и радость фирме и всем командам, в которых работает (дело было 5 лет назад). Ну а мне добавилось мотивации подтянуть язык :)
                                                                                –1
                                                                                Но ведь все сервисы гугла уже написаны чуть более чем полностьью и на поддержке стоят ключевые люди. Зачем вам новые, чтобы ковырять и поддерживать то, что никто из своих не берёт?
                                                                                  +3
                                                                                  В Android, например, довольно активная разработка ведется.
                                                                                    0
                                                                                    cloud.google.com/bigquery/docs/reference
                                                                                    гляньте на число значков слева — это новые фичи в бета стадии.
                                                                                    +2
                                                                                    Как нынче с корреляцией результатов интервью и того, насколько человек потом пользу приносит? Всё так же околонулевая ([1], [2])?:)
                                                                                      +2
                                                                                      Очень интересный вопрос, реферат на который готовлю :)

                                                                                      Вкратце:
                                                                                        +1
                                                                                        А вот это было бы крайне интересно почитать! Если не сложно и если реферат в публичный доступ выкладывать соберётесь — можете поделиться?
                                                                                          +1
                                                                                          «реферат» в том смысле, что статью готовлю. ищу все крупицы данных в публичном доступе для этого. внутреннего доступа до статистики у меня нет (и не надо), но примерная картина уже расписана и так подробно.
                                                                                      +1
                                                                                      Как нынче с корреляцией результатов интервью и того, насколько человек потом пользу приносит?

                                                                                      частично описано в книге «Как работает Гугл» Эрика Шмидта
                                                                                      86% в книге так же фигурирует)
                                                                                        +2
                                                                                        пользу ведь традиционно сложно измерять…
                                                                                          –1
                                                                                          Многие крупные компании используют Performance Review и разные виды 360*.
                                                                                          Вполне можно сравнить итог спустя 1-2 года с предсказанием на приёме на работу.
                                                                                            +2
                                                                                            Performance Review — как минимум в тех не последних в мире корпорациях где я работал в лучшем случае превратились в еще одну бюрократическую процедуру по заполнении всяких бланков и проводки их через десяток этапов в HR-системе. В худшем же — перед самым Review искусственно организуются всякие завалы и всплывают «критические» проблемы — которые героически чинятся в авральном порядке. Или наоборот — за месяц до Review никто не хочет делать какие-то серьезные изменения — чтобы не вызвать негативное отношение начальства.
                                                                                              +1

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


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

                                                                                        +2
                                                                                        Вот кстати очень правильно, что код пишете в гуглдоках. Постоянно случается ситуация, когда собеседующий предлагает открыть какую-нибудь CloudIDE и написать код, который бы проходил предварительно написанные тесты. Типа «реализуй промис, а вот пачка тестов». По-моему, это ужасная затея: в реальной практике нам нужно не писать код быстро-быстро под взглядом собеседующих в стрессовой ситуации.
                                                                                          0
                                                                                          Ну это уже как-то стиль олимпиад. Впрочем, возможно им нужны люди, кто могут писать в таких условиях? Или просто им так удобно. Имеют право, в конце концов.

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

                                                                                          Для телефонных собеседований у нас есть только гуглодока, а при on-site собеседовании как кому удобнее — либо доска либо лаптоп с редактором. Но там просто редактор — из умного только отступы и подсветка синтаксиса, компилятора нет.
                                                                                            +1
                                                                                            Думаю, это в основном от непонимания. Я помню как сильно поначалу лажал когда в Blue Brain Project искал себе замену. Первые три собеса были просто жуткими — вопросы задавал дурацкие, народ пугал. Потом понял — надо спрашивать те вещи, которые мы сами делаем на ежедневной основе.
                                                                                            +5
                                                                                            Вот кстати очень правильно, что код пишете в гуглдоках

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


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

                                                                                              0
                                                                                              Да. Я лично надеюсь, что это изменится. В конце концов, и электронные вайтборды есть и онлайн редакторы.
                                                                                              В первую очередь именно для того, чтобы дать собеседуемому максимально комфортные условия.
                                                                                              К сожалению, пока условия всё еще бывают очень дискомфортными для некоторых людей.
                                                                                              Я когда собеседовался — у меня были ровно те же вопросы :)
                                                                                              С тех пор на очных появилась возможность использовать ноуты, и я завидую — мне было бы гораздо легче собеседоваться.
                                                                                                0
                                                                                                интересно. А я наоборот если меня гонят в онлайн IDE начинаю отнекиваться, что у меня она не работает и вообще это плохая идея. Написать при ком-то код, который сразу скомпилируется и заработает — я так вряд ли когда-нибудь научусь.
                                                                                              +4

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


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

                                                                                                0
                                                                                                Это не за гранью, а вполне разумное решение если надо обеспечить верифицируемую непредвзятость. Как предполагаете доказывать в суде непредвзятость отказа, если собеседуемый и собеседующий поговорили и на основании только одного его «нет» не взяли?
                                                                                                  +3
                                                                                                  Как предполагаете доказывать в суде непредвзятость отказа

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


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

                                                                                                +3
                                                                                                Вопрос: я верно понимаю, что гугл никого по-настоящему не приглашает? Слышал историю про то, как создатель Homebrew получил приглашение на собес, пришел — и не прошел по результатам собеседования. Причем завалили не на толерантности к трансгендерам, а на каких-то алгоритмах. Тогда я еще удивился — какое-такое собеседование, его же пригласили? Какое «инвертирование бинарного дерева» — чувак brew написал, неужели этого недостаточно для понимания его профпригодности? Обычно если приглашают — то просто показывают команде, что у него нет рогов и хвоста, да общаются за кофе часок. А вот у калифорнийских компаний, как я понял, не так.
                                                                                                  +4
                                                                                                  А что такое «по-настоящему приглашает»? Вы вот сказали — приглашение на собеседование.
                                                                                                  Не приглашение на работу, а на собеседование…

                                                                                                  Имхо, частая ошибка — профпригодность != пригодность для компании.

                                                                                                  У компании есть определённые правила, которые появились не с бухты барахты, не за один день и не на основании ЖЛП (желания левой пятки) кого бы то ни было.

                                                                                                  Как бы ни был крут в каком-либо аспекте человек, он может не подходить по другим причинам.
                                                                                                    +2
                                                                                                    Получается, гугл настолько боится нанять дураков, что разводит бюрократию, которая отсеивает лучших.
                                                                                                    +1
                                                                                                    Я вот тут подумал — а что если вопросы будут составляться не теми, кто их задает? Собеседующий и кандидат будут видеть вопросы в первый раз в жизни и оба будут их решать. Если собеседующий сам не осилил решить — можно сделать какие-нибудь оргвыводы.
                                                                                                      +1
                                                                                                      А кто будет оценивать? :) Предлагаете соображать на троих?

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

                                                                                                      Кстати, еще раз прочитайте статью — вопрос на максимальной сложности никто не должен мочь решить в отведённое время, если только это не его узкая специализация.
                                                                                                      +5
                                                                                                      В августе собеседовался в Google (Цюрихский офис).
                                                                                                      Прошло все довольно своебразно, сначала со мной поговорил рекрутер из Лондона, который в итоге отправил на техническое hangouts интервью с инженером из Цюриха.
                                                                                                      Только вот отправили меня по направлению software engineer, хотя я сам системщик-эмбеддер.
                                                                                                      Это собственно и всплыло в процессе собеседования, инженер даже немного удивился почему меня к нему отправили.
                                                                                                      После собеседования мне прислали фидбек, что по направлению software engineer они мне не могут ничего предложить, т.к. я мол embedded/firmware engineer, так они решили. В общем то здраво :)
                                                                                                      И добавили еще, что сейчас ищут hiring team по этому направлению и предложили созвониться что бы обсудить всё. Я согласился на созвон и после этого Google пропал, так и не дождался ответа :)
                                                                                                      В сентябре правда прислали заполнить анкету небольшую, что бы я дал уже свой фидбек по поводу процессе собеседования и интервьюверов, я там конечно в дополнительных заметках описал возникшую ситуацию.
                                                                                                      Так что еще и такого плана бардак небольшой присутствует.
                                                                                                        +1
                                                                                                        Интересно. А когда подавались — вы подавались на software engineer или на embedded?
                                                                                                        Я проводил собеседование на Embedded — так оно так и было помечено, как embedded…
                                                                                                        Вероятно, провалилось в какие-то непонятные щели. Если напишете мне в ПМ, я попробую спросить куда вас потеряли.
                                                                                                        Ну либо я попробую добавить со своей стороны — тогда я хоть буду знать что происходит, и смогу дополнительно контролировать.
                                                                                                        +2
                                                                                                        Нуу, не знаю. Последний раз я вроде бы все ответил на телефонку с инжынером, раньше времени все разобрали, вопрос достаточно стандартный. Но потом HR сказал, что нет. Наверное все-таки не на техническую часть нужно обращать внимание, а именно на изучение местных карго-культов. Типа там, отступы не стабами, а пробелами.
                                                                                                          0
                                                                                                          А спросили рекрутёра, почему нет и что надо подтянуть?
                                                                                                            0
                                                                                                            Давно это было, не помню уже деталей, но внятного ответа я точно не получил.
                                                                                                            ААА, начинаю припоминать. Меня человек 5 отреференсило в Гугле и один или два из них обо мне на запрос не ответило. Потом спросил, один сказал, что в отпуске был, другой, что письмо не заметил. Не знаю, но в общем, точно не по технической причине недопустили.
                                                                                                              0
                                                                                                              Что вы понимаете под «не по технической причине»?
                                                                                                                0
                                                                                                                Например, интервьюверу мог не понравиться мой коммент, что stl это часть стандарта C++. Как описать это в отзыве обо мне? Ну, например, можно как «слабое знание С++». Вообще, о том, что «всем давно известно, что в Гугле stl нельзя использовать на интервью» можно догадаться только после прочтения специальных книжек о внутренних каких-то особенностях. Ну это чисто догадки, откуда я знаю, что там реально было. Но мне ничего не сказали кроме «Мы все еще ждем ответа от некоторых, ну и кажется, что вам нужно подтянуть алгоритмы». Это какая-то конкретная причина или ее можно кому угодно по каким угодно поводам написать?

                                                                                                                То есть, грубо говоря, у меня сложилось впечатление, что когда я стал писать решение отличное от того, что было у интервьювера перед глазами, он сразу же решил, что оно неправильное и что я ничего не знаю. А так как у меня есть много знакомых, все-таки прошедших это интервью, я в курсе, что для этого нужно долгое зазубривание стандартных всех решений стандартных задач и ровно этого от тебя ожидает интервьювер. Я просто слишком ленивый для этого.
                                                                                                                  +1
                                                                                                                  Хм. А с каких пор stl стало частью стандарта? Но если понимать как «в стандартной поставке современного c++ компилятора» — то это правда :D

                                                                                                                  А кто сказал что нельзя? Можно. Используйте на здоровье. Но если вы строите очередь на std::vector — будьте добры ответить о полученной сложности алгоритма с учетом вставки и удаления из головы vector'а.

                                                                                                                  А если говорите «допустим, у нас есть библиотека для хранения графов, и мы можем использовать функцию, которая даст кратчайший путь для произвольных вершин» — это тоже нормально для решения. Но да, попросить реализовать эту функцию тоже могут попросить. Ну или как минимум описать её сложность.
                                                                                                                  Если она O(1) — тогда особенно интересно, сколько она по памяти.
                                                                                                                    +4
                                                                                                                    Stl является частью стандарта С++ по-моему с 98ого года. Соб-но, поэтому С++98 так важен.
                                                                                                                    Вот документ стандарта 2005ого года, в который stl уже включен www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1905.pdf

                                                                                                                    Задача у меня была в духе «написать itoa» и естественно, например, предложить использование std::string в качестве выходного значения. Точнее по-моему что-то про массив нулей и единичек и ес-но, я предположил, что хранится он в векторе, а не просто в указателе. Но в известной книжечке приведено решение на указателях, вот и спрашивают тоже с указателями. А иначе как еще можно понять, что решение правильное?

                                                                                                                    То есть, простыми словами: хороший программист С++ должен знать, что stl — часть стандарта С++98 (да и вообще неплохо бы отличия стандартов друг от друга), а хороший программист, проходящий интервью в Гугл, еще и должен знать, что они не считают, будто stl включен в С++.
                                                                                                                      0
                                                                                                                      Отлично! Не знаю про какую известную книжечку вы говорите, но вот стайлгайд:
                                                                                                                      google.github.io/styleguide/cppguide.html#C++11
                                                                                                                      говорит вообще использовать всё что можно из C++11.

                                                                                                                      Вы говорите stl ключен в C++98, отсюда вывод, что stl использовать можно.

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

                                                                                                                      Может просто попробуете еще раз? Будет другие собеседующие и другие вопросы. Если вы считаете, что проблема была в собеседнике — на этом вопрос будет закрыт.
                                                                                                                        +1
                                                                                                                        Да сейчас уже лень, у меня работа хорошая и дом и прочее. Просто мой пойнт в том, что интервьювер ожидает от тебя быстрые стандартные ответы на стандартные вопросы и ничего другого. Не надо обманывать людей, будто там реально будет какое-то вдумчивое обсуждение. Все эти вопросы есть в книжечке cracking code interview, которую нужно просто выучить наизусть. Только там вы выясните, что, например, нужно прикидываться, будто stl не является частью С++, чтобы не ставить интервьювера в неудобное положение и многое другое.
                                                                                                                          0
                                                                                                                          Не надо обманывать людей, будто там реально будет какое-то вдумчивое обсуждение.
                                                                                                                          У меня есть ощущение, что вы провалились как раз на «вдумчивом обсуждении». Потому что для людей, которые на интервью активно используют STL у меня есть стандартный вопрос на 3 минуты: что написано про сложность оператора std::map:iterator::operator++ в стандарте.

                                                                                                                          И, заметьте, ответ «фиг его знает, я стандарт наизусть не помню» — меня более чем устроит. Вопрос будет лишь слегка переформулирован: «что должно быть написано про сложность оператора std::map:iterator::operator++ в стандарте при условии, что его писали разумные люди — и почему.»

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

                                                                                                                          Причём, заметьте — это не издевательство. Для этого профиля даже есть название: Application Engineer. Вот ему разрешено произносить сакральные фразы «у нас есть XXX (в данном случае STL) и потому про YYY (не знаю уж чего там было… сортировки, аллокацию памяти или чего ещё) знать не нужно».
                                                                                                                            +2
                                                                                                                            Я прекрасно понимаю, что любая хорошая компания пытается произвести приятное впечатление на собеседуемого, даже если ему отказывает. Пытается сделать ему наиболее прозрачную и понятную оценку, обьяснить, что она не основана на каком-нить там расизме и дать повод подумать, над чем поработать, чтобы прийти через год. Мой оригинальный коммент был вызван тем, что конкретно у Гугла это в моем случае не получилось вообще никак. При этом я в курсе как можно было бы избежать этих проблем — надо было просто заучить стандартные ответы на стандартные (а мне задали совершенно стандартные вопросы из cracking code interview) и я бы прошел совершенно прекрасно. Поэтому мой совет начинающим и не только программистам — не следуйте моим путем, просто тупо заучите, что от вас требуется и оттарабаньте на собесе, как это делают все остальные прошедшие.
                                                                                                                              0
                                                                                                                              Вы даёте вредные советы. Заучите, и попробуйте пройти. Я писал в статье о самом важном, что делаю на собеседовании — пропускаю заученную часть. Не беспокойтесь, я поставлю задачу так, что заученное не поможет.
                                                                                                                              А дальше вопрос. Если вы выучили и поняли — то прекрасно, вы прошли. Но это не потому, что зазубрили книжку, а потому, что ее поняли.
                                                                                                                              А если зазубрили — без понимания — то в этот момент поплывете.
                                                                                                                                0
                                                                                                                                Может быть вы собеседуете и так. Ну, знамечательно. А вот другие, судя по всему, по другому.
                                                                                                                                  0
                                                                                                                                  Скажем так. Как я писал в статье — на телефонном некоторые задают несколько мелких вопросов. Но даже там важно решение, это черновой осмотр. Даже если вы заучите и пройдёте такое телефонное, на очном будут уже только вопросы на пределе. Где произойдёт точно тот же завал.
                                                                                                                      +3

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

                                                                                                                        –2
                                                                                                                        Я не являюсь специалистом по C++, и у меня нет readability для него — если я пишу любой код на C++, в обязательном порядке его будет review делать кто-либо, кто знает и меня поправит.
                                                                                                                        Вы не должны знать все языки досконально, это не суть — для поддержания общего стиля и правильности есть правила review, есть люди, кто могут проверять код на соответствие правилам.
                                                                                                                        И я писал выше — интервьюеры проверяют как кандидат думает.
                                                                                                                        Во-1х единственно правильного ответа не существует, во-2х если ты даёшь отличный ответ это хорошо, но не значит, что на этом интервью закончилось.
                                                                                                                        Оно заканчивается по времени, вопросы резиновые.

                                                                                                                        Именно поэтому нельзя заучить одно правильное решение.
                                                                                                                          +2
                                                                                                                          Вот и у меня сложилось впечатление, что интервьювер не ориентируется в С++ и вместо того, чтобы просто признать, что он не понимает, что я ему пишу, он сверился с листочком с решением, не увидел совпадений и подумал, что ему мозги дурят. Опять же, чисто мое впечатление.
                                                                                                                          Например, я не беру единственный оператор в составной {}, но бывают джуниоры, которые даже не понимают, что это вообще, и, опять же, это противоречит google code style, однако никак не противоречит здравому смыслу.
                                                                                                                            0
                                                                                                                            Давайте уже перейдём к конкретному примеру вместо воспоминаний о впечатлениях?
                                                                                                                            Напишите itoa — те самые пять злосчастных строчек.
                                                                                                                              +4
                                                                                                                              Для начала я бы уточнил язык. Это Си или C++? И если это С++ не лучше ли конвертить не в ANSI string, а в std::string, у которой уже есть c_str()? Ну и таких вопросов у меня еще много. Хотя, конечно, ничего удивительно нет в том, что они вызывают раздражжение у собеседующего, который просто хочет сравнить 5 написанных строк с тем, что у него в памяти. Но, разве, это какие-то плохие вопросы?
                                                                                                                                0
                                                                                                                                Почему? Прекрасные вопросы. Более того, я вообще надеялся, что хоть кто-нибудь в комментариях захочет реально рассмотреть какой либо вопрос! Полноценно, вдумчиво (но честно, не бегая в гугл или книжку)

                                                                                                                                Отвечу по порядку: язык выбираете вы сами. Сказали си? Пишите на си. Сказали с++? Пишите на нем.
                                                                                                                                Вот только зачем вам функция преобразования анси строки в стд строку и стринг в инт, если вопрос был itoa?

                                                                                                                                Итак, отлично, уточню вопрос: напишите функцию, с тем интерфейсом, который вы считаете оптимальным, которая преобразует число в строку. Язык возьмите какой хотите на выбор из c, c++, python, go, Java, c#. Не используя библиотечные функции преобразований и форматирования строк.
                                                                                                                                  0
                                                                                                                                  Хорошо, но строка в С++ это std::string. Допустим, мы хотим преобразовать в string, но не используя ф-ий преобразования string. Тогда разумно использовать std::vector для хранения промежуточного результата, не так ли?
                                                                                                                                    0
                                                                                                                                    Тогда разумно использовать std::vector для хранения промежуточного результата, не так ли?
                                                                                                                                    Нет — потому что это приведёт к лишней аллокации памяти в куче, что расточительно для itoa. Но если вам так хочется… выбор за вами.
                                                                                                                                      0
                                                                                                                                      А этот вопрос я не совсем понимаю к чему ведёте. Для меня это уже ваше рассуждение в слух, я продолжаю ждать, когда вы будете писать саму функцию.
                                                                                                                                      Если задано с интонацией вопроса требующего подтверждения просто скожу, хорошо, продолжайте.

                                                                                                                                      Обратите внимание еще раз на формулировку задания, ваш вопрос ничему не противоречит, продолжайте.
                                                                                                                                    –1
                                                                                                                                    Но, разве, это какие-то плохие вопросы?
                                                                                                                                    А давайте я тоже — вопросом на вопрос: плохие или хорошие… для чего? Для того, чтобы «почувствовать себя умным и красивым»? Хорошие вопросы. Для того, чтобы устроиться на работу? Плохие, несомненно.

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

                                                                                                                                    То есть вы, задавая ваши вопросы, просто сокращаете время, которое вам останется на содержательную часть с 30 минут до 20 или 10. Или и вообще до нуля. С соответствующими последствиями для результатов собеседования.

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

                                                                                                                                    А ответы… «Если бы собеседование проводил я»…

                                                                                                                                    Это Си или C++?
                                                                                                                                    Выберите что хотите.
                                                                                                                                    И если это С++ не лучше ли конвертить не в ANSI string, а в std::string, у которой уже есть c_str()?
                                                                                                                                    Если вам больше нравится std::string — почему нет… «замечание про себя: человек сам себе копает яму, нужно будет не забыть спросить про сложность std::string::push_back и std::vector::push_back».
                                                                                                                                    Ну и таких вопросов у меня еще много.
                                                                                                                                    И чем больше вы их задаёте — тем меньше у вас шансов пройти нормально собеседование.

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

                                                                                                                                    Тут не нужно какой-то особого «Гуглового подхода». Как и про любую банальность в IT про это написал Спольски:
                                                                                                                                    Главное и единственное требование, предъявляемое к кандидату на работу в нашей компании: он должен
                                                                                                                                    знать свое дело и уметь его делать.

                                                                                                                                    А все ваши вопросы кладут такие маленькие-маленькие крохотные минусики на чашечку «не уметь его делать»…
                                                                                                                                      +3
                                                                                                                                      Ну так и я про то же. Да, в реальной работе я всегда задаю подобные вопросы — зачем нам конкретно это надо, почему мы делаем именно так и чем вызваны любые нестандартные решения. Не нужно раздражжать интервьювера. Вместо этого нужно просто оттарабанить стандартное всем известное решение и еще несколько таких, получить свой оффер, сидеть в офисе у батареи и радоваться жизни, радостно поковыривая в носу.
                                                                                                                                        0
                                                                                                                                        Да, в реальной работе я всегда задаю подобные вопросы — зачем нам конкретно это надо, почему мы делаем именно так и чем вызваны любые нестандартные решения.
                                                                                                                                        Кому вы это задаёте, я извиняюсь? Себе — ну так похвально: так и на интервью сделайте. И расскажите — почему вы сделали так, а не иначе. Интересно будет послушать.

                                                                                                                                        А если не себе — то кому? Это ваша работа и часть ваших должностных обязанностей. А чьих ещё?

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

                                                                                                                                        сидеть в офисе у батареи и радоваться жизни, радостно поковыривая в носу
                                                                                                                                        «Поковыривать в носу» не получится — нужно будет как раз регулярно отвечать на те вопросы, которые вы хотите «свалить» на кого-то. Ну, кроме прочих обязанностей.
                                                                                                                                          +5
                                                                                                                                          Первый раз в жизни встречаю человека, который на полном серьезе мне доказывает, что моя обязанность — работать, не задавая вопросов. Работаете в индустрии вывоза больших черных мешков или отмывания странных больших пятен?
                                                                                                                                            –1
                                                                                                                                            Первый раз в жизни встречаю человека, который на полном серьезе мне доказывает, что моя обязанность — работать, не задавая вопросов.
                                                                                                                                            Нет — ваша обязанность — работать, не задавая дурацких вопросов не по делу. А вопросы, относящиеся к вашей компетенции — задавая себе и отвечая на них самостоятельно.

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

                                                                                                                                            Вот только есть проблема: я оччень сомневаюсь, что бухгалтер или грузчик сможет дать вам ответ на вопрос — стоит вам использовать ANSI string или std::string.

                                                                                                                                            Если же вы считаете, что должен быть какой-то загадочный архитектор или тим лид, который вам даст ответ на эти вопросы, а вы потом только клац-клац-клац закодируете, как робот — то вынужден разочаровать: у нас таких нет. Как и, подозреваю, у автора статьи.
                                                                                                                                              +2
                                                                                                                                              ну, что такое «дурацкий» вопрос это очень субъективно.
                                                                                                                                              но то, что надо уметь отделять вопросы релевантные от нерелевантных — это факт. вопросы «где это будет использоваться» — хорошие, позволяют создать API.
                                                                                                                                              вопрос «должен ли я использовать std::vector» — осмысленен в форме «не запрещено ли по условиям задачи».
                                                                                                                                                0
                                                                                                                                                вопрос «должен ли я использовать std::vector» — осмысленен в форме «не запрещено ли по условиям задачи».
                                                                                                                                                Вопрос как «должен ли я использовать std::vector» осмысленен как что-то, что вы проговорите про себя и отвергните.

                                                                                                                                                Почему отвергните? Ну очень просто. Какие есть плюсы у использования std::vector? Ну разве что «это модно, стильно, молодёжно». Всё же остальное попадает в графу недостатки: вы используете память «в куче», вы вызываете с десяток реаллокаций, вы усложнаяете машинный код самой функции… и при этом даже не экономите память: на стеке вам будет нужен массив размером в 32 байта, а std::vector занимает 24 байта плюс ещё минимум 8 байт будет менеджером памяти задействовано… ну и нафига козе баян?

                                                                                                                                                Я ещё могу как-то «понять и простить» джуна без опыта, который просто тупо лепит std::vector так как про std::array он не знает, а «сырых массивов» боится… но человек с опытом должен такие вещи замечать.
                                                                                                                                                  +1
                                                                                                                                                  Это преждевременное суждение. Пока не было даже решения с std::vector, так что мы не знаем, почему этот вопрос был задан.
                                                                                                                                                0
                                                                                                                                                А еще мне не нравится, когда джуниор, собеседующий меня со своими двумя годами опыта, считает, что он лучше меня разбирается в разработке ПО, раз работает в Гугле, чем я со своими 15ю. Потом, вам лет через 10 с опытом придет, что людям очень редко надо на самом деле именно то, что они просят.
                                                                                                                                                  +1
                                                                                                                                                  Потом, вам лет через 10 с опытом придет, что людям очень редко надо на самом деле именно то, что они просят.
                                                                                                                                                  На самом деле для этого 10 лет не требуется. Но непонятно сколько лет требуется для того, чтобы понять что ровно тот факт, что «людям очень редко надо на самом деле именно то, что они просят» обозначает, что попытки выяснить разнообразные хитрые детали реализации у того, кто вас о чём-то просит — бессмысленны, разве нет?

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

                                                                                                                                                  Джоел говорит что так нужно общаться с «клиентом или нетехнический менеджером»… но на самом деле с вашими коллегами — подход должен быть тот же. Просто немного по другой причине. Если «клиент или нетехнический менеджер» не может понять ваших рассуждений, то ваши коллеги просто не будут хотеть этого делать. Если они «влезут в задачу», которую делегировали вам, настолько, что будут разбираться там в каждой запятой — то на это уйдёт стольков времени и сил, что им проще будет всё самим сделать… зачем такой человек в команде нужен?
                                                                                                                                                    +1
                                                                                                                                                    Джоел то, Джоел это. Я помню тоже удовольствием зачитывался им, когда еще не существовало скайпа и ютуба. Каждый джуниор с новой книжкой для себя столько великих идей открывает. До clean code, я так понимаю, еще не добрались?
                                                                                                                                                      +1
                                                                                                                                                      Идеи Джоела как раз банальны. Никаких хитрых истин у него в блоге нет. Но он хорошо пишет, а прописные истины от того, что прошло 5-10-15 лет ложью не становятся.
                                                                                                                                          +2
                                                                                                                                          Ну почему же. Я сам попросил думать вслух, что и слушаю. Нормальные вопросы. Правда, если человек ждёт подтверждения на каждый шаг реализации — это настораживает, потому что его автономность может вызвыать сомнения, но мы еще не закончили, а преждевременные выводы — зло.

                                                                                                                                          Я никогда не делаю выводов заранее, пишу протокол подробно и целиком, а оценку делаю чуть позднее, читая протокол а не полагаясь на мои воспоминания и ощущения. Это снижает предвзятость.
                                                                                                                                            0
                                                                                                                                            Я думаю, если бы попал на собеседование к вам, мы бы прекрасно поговорили. Но мой пойнт в том, что куда более вероятно попадание к khim, которые, конечно же, считают, что вопросы важно и нужно задавать, но только те, которые ожидает интервьювер и на которые заранее знает ответы. И что сам формат собеседования по времени реально не предусматривает достаточно времени для вдумчивого обсуждения задачи. Ничего сильно плохого в этом нет. В том же универе на экзамене вы тоже знакомитесь с лекциями, а потом часто от вас требуется прямо на ходу выдавать ответ. Просто надо заранее обсуждать формат собеседования, что, мол, спрашивать будем вот по этим вот лекциям.
                                                                                                                                            Кстати, многие американские представители Гугла и прочих компаний в открытую говорят — не выучите материал этих книжке — интервью не пройдете.
                                                                                                                                              0
                                                                                                                                              khim, которые, конечно же, считают, что вопросы важно и нужно задавать, но только те, которые ожидает интервьювер и на которые заранее знает ответы.
                                                                                                                                              Бред какой. С чего вы решили, что мне не нравятся вопросы, ответ на которых я не знаю? Наоборот — если кандидату удаётся указать мне на что-то в тех вопросах, которые я задаю, чего не знаю (такое редко, но случается, я не Бог, всеведением не обладаю) — то это большой плюс. И почти все кандидаты, кому это удалось были приняты в итоге.

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

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

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

                                                                                                                                              Если честно, то меня это удивляет. Во всех компаниях, где я работал принцип был одинаков: меня просили ответить на вопрос «хотите ли вы увидеть кандидата в вашей команде?» — вот именно так и никак иначе.

                                                                                                                                              О том же пишет и Джоел:
                                                                                                                                              Вместо «Нанимать, но не в мою группу» напишите, не задумываясь, «не нанимать», и все будет в порядке. Даже если вы столкнулись с прекрасным специалистом в одной конкретной области, но для вас не подходящим — это значит «не нанимать». [...] Никогда не говорите «может быть» или «не уверен». Не уверены — не нанимайте. Это проще, чем кажется. Не уверены? Скажите нет. И ещё, если вы занимаете выжидательную позицию, это тоже значит «не нанимать». Никогда не говорите: «Хорошо, я думаю, мы его возьмем, хотя есть некоторые сомнения насчет...». Это тоже «не берем».
                                                                                                                                              Если кандидат лично мне не понравился, но остальные от него в восторге — его ведь возьмут всё равно, но если вопрос стоит как «хочу ли вот конкретно я работать бок-о-бок вот конкретно с этим кандидатом»… то эмоции, которые у меня вызывает общение с ним — чуть ли не важнее объективных знаний и умений.

                                                                                                                                              Просто надо заранее обсуждать формат собеседования, что, мол, спрашивать будем вот по этим вот лекциям.
                                                                                                                                              Кто вам такое сказал? Единственное ограничение — интервью длится 45 минут или час, реже 2-4 часа (в разных компаниях по разному, но везде, где я собеседовал был лимит) и, соответственно, времени на обсуждение «погоды на Марсе» у нас нет — ну так и в реальной разработке «лишнее» время редко когда бывает.

                                                                                                                                              И что сам формат собеседования по времени реально не предусматривает достаточно времени для вдумчивого обсуждения задачи.
                                                                                                                                              Вы хотите сказать, что вам не хватит 45 минут времени (более короткие интервью мне не встречались), чтобы «вдумчиво обсудить» itoa? А сколько времени вам потребуется на «вдумчивое обсуждение» реальных задач? Год? Или два?
                                                                                                                                                0
                                                                                                                                                Боюсь что поговорили бы прекрасно, но вот примера кодирования я так и не увидел, хотя задача уже была сформулирована и даже ответы на нерелевантные вопросы даны.
                                                                                                                                                Так что результат был бы «нет».

                                                                                                                                                И, прошу заметить, stl тут не при чем.
                                                                                                                                                  0
                                                                                                                                                  Да я вообще-то спал. Или вы думаете я должен был всю ночь бдеть и отвечать на вопросы?
                                                                                                                                                    0
                                                                                                                                                    Нет, что вы. Я тоже спал. Просто вы отвечали на другие вопросы, вот и всё.
                                                                                                                                                      0
                                                                                                                                                      Еще 18 или 19 лет назад я на олимпиаде по программированию занял 1ое место по городу. Я прекрасно в курсе кода, который принято писать для «C++ имплементации itoa». Но он мерзкий. Он из 90ых. С тех пор С++ изменился, а этот мерзкий пример — нет. Просить написать этот код в 2018ом году, это как просить журналиста написать тестовую статью на старославянском, при том, что писать он будет на современном русском.
                                                                                                                                                        +3
                                                                                                                                                        Я разве просил вас написать «код, который принято писать»? Нет.
                                                                                                                                                        Но вы не хотите писать даже тот код, который считаете красивым и опрятным на современном C++.

                                                                                                                                                        Проще говоря, если вы пришли на собеседование на кодинг, где заранее было оговорено что надо будет написать десяток строк (а об этом написано — «Be prepared to write around 20-30 lines of code in your strongest language.») с желанием просто поговорить — я понимаю, почему собеседование закончилось неудачей.
                                                                                                                                                          –2
                                                                                                                                                          Да нет, я прекрасно понимаю, что требуется написать код в духе
                                                                                                                                                          www.geeksforgeeks.org/implement-itoa(и я могу его воспроизвести по памяти, так как писал его еще мелом на доске, когда Ельцин был президентом). И я знаю, что это именно то, что ожидается. Просто этот код мерзкий. Ни один здравый программист, размышляя с нуля не будет писать такой код. Просто есть такая древняя традиция, лет 30 которой уже, задавать вопрос по itoa (который некорректный сам по себе) и отвечать таким говнокодом, делая вид, что это С++
                                                                                                                                                            +4
                                                                                                                                                            Нет, ожидается, что вы что-нибудь напишете, а не будете разводить демагогию про олимпиады ельцина в детском саду.
                                                                                                                                                              –2
                                                                                                                                                              Если бы мне была очень нужна работа, я бы написал код, приведенный по ссылке сверху. Можете его покритиковать, будет интересно. Очень удивлюсь, если он неидеален по стандартам Гугла.
                                                                                                                                                              Но просить написать такой код это примерно как, нанимая электрика, дать ему два провода и сказать — «сделайте нам скрутку», ожидая, что сейчас от зачистит провода зубами, скрутит руками и сверху изоленточкой. Нормальный электрик вас просто пошлет с такими заданиями. Вежлиый начнет спрашивать, из каких металлов провода, на какой ток расчитаны, какой толщиной, почему нельзя их спаять, можно ли использовать термоусадочные материалы и прочее.
                                                                                                                                                              Интервьювер наверняка скажет, что электрик совсем ничего сделать не может, то, что даже ребенок умеет. Но понимаете, и электрик скорее всего вежливо просто обойдет такую контору стороной, если у него есть выбор работать там, где провода пальцами не скручивают.
                                                                                                                                                              +3

                                                                                                                                                              Если вы вместо этого "говнокода" напишете рабочую версию с std::string::push_back и std::reverse, вам это зачтется за правильный ответ, если, разумеется, сможете объяснить сколько это будет работать и почему.

                                                                                                                                                                –1
                                                                                                                                                                Если вкратце то:
                                                                                                                                                                — постановка задачи «написать itoa на С++» некорректна
                                                                                                                                                                — постановка задачи «написать int to std::string на C++» корректна
                                                                                                                                                                — постановка задачи «написать int to std::string на C++ без использования ф-ий std::string» некорректна
                                                                                                                                                                  +3

                                                                                                                                                                  У вас постановка задачи — написать itoa. На вашем любимом языке. Например, в проекте нужно записать число в нестандартной кодировке (вместо 0 — a, вместо 1 — b, и т.д.)


                                                                                                                                                                  на C++ без использования ф-ий std::string

                                                                                                                                                                  Где вы это требование взяли? Я вам написал выше — используйте любые методы std::string и стандартные алгоримы. Все, кроме, собственно to_string.

                                                                                                                                                                    0
                                                                                                                                                                    Все, кроме, собственно to_string.
                                                                                                                                                                    А чем to_string не угодил? Он же только с основанием 10 работает. Не очень понятно куда его засунуть и зачем, но если удастся его как-то поиспользовать… будет интересно посмотреть…
                                                                                                                                                                      0
                                                                                                                                                                      Попытка сократить время до получения кода.
                                                                                                                                                                      Ведь требования поддержки radix не было…
                                                                                                                                                                      +1
                                                                                                                                                                      «a» в itoa означает ANSI string — null terminated 1 bytes per char. Это Сишный формат строк. У С++ свой формат строк. Постановка задачи некорректная. Корректная — написать string to_string(int)

                                                                                                                                                                      Касаемо «ожидания готового кода», мне его скопипастить, чтоли, из приведенной выше ссылки? Я написал, что именно это подразумевается под правил