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

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

Следите за таймингом

И это не про O(N). На типичном собеседовании по алгоритмам от вас ожидают, что в течение часа-полутора вы напишете решение пары задач. Если ещё и объясните их, будет вообще супер. 

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

К чему это приводит? Как правило, к тому, что через 30-40 минут от начала собеседования кандидат приходит в точку, когда нужно «буквально пару циклов дописать, и всё должно заработать». При таком сценарии на второй задаче можно поставить крест.

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

Рассказывайте о своём решении

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

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

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

Решайте проблемы стратегически

Бывало у вас такое, что думаете-думаете над задачей, пробуете-пробуете — и всё никак? Вроде бы подсказок и так много было, и вроде обсудили возможные подходы, но тупик. Что тут можно сделать?

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

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

Не зацикливайтесь на мелочах

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

Знакомо? Скажу так: я видел, как при таком исправлении мелочей и рефакторинге кандидаты вообще забывали, что хотели написать в итоге.

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

Заключение

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

  1. Следите за временем, не тратьте слишком много на одну задачу.

  2. Рассказывайте про решение. Спросите явно, туда ли вы двигаетесь.

  3. Если застряли, меняйте задачи местами, решайте их с конца. Иногда это правда помогает.

  4. Не утопайте в мелочах раньше времени, первым делом — основной алгоритм.

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

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


  1. wrqqq
    16.06.2022 17:59
    +16

    На что обращать внимание на алгоритмических секциях собеседований

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


    1. antonblockchain
      16.06.2022 18:46

      Вполне понятно желание посмотреть код.
      если fuzzbuzz код на языке человек не может написать то зачем его дальше собеседовать?
      и о чем?

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


      1. segment
        16.06.2022 19:00
        -1

        Можно просто попросить показать код из проектов кандидата


        1. antonblockchain
          17.06.2022 01:46
          +1

          Код из проектов, может быть.
          1) старым — несколько лет назад;
          2) чужим — писала команда и самая лучшая часть кода не претендента;
          3) взятым откуда-то из стековерфлоу;
          4) просто хорошо заученным рабочим примером.

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

          если не использовать живой кодинг.
          тот кто готовится к собеседованиям к вам попадет.
          а тот кто все время работал, и не готовился, не пройдет.

          Цель взять того кто хорошо кодит, а не хорошо проходит собеседования.


          1. kalombo
            17.06.2022 08:16
            +1

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

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

            У меня была задача, нужно было в json вытащить все значения с ключом 'url'. Я затупил и забыл, что в json также могуть быть массивы, хотя пример был перед глазами. А еще задача была проверить на валидное количество скобочек, я её решил, потому что помнил(по сути заучил) как она решается с использованием стека.

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

            P.S. Алгоритмические собеседования - это бюррократический подход к найму в больших корпорациях типа Яндекса и Гугла. Ничего они не рассказывают, кроме того, что программист умеет проходить собеседования по алгоритмическим заданиям. Для этих корпораций такой подход работает, для всех остальных - это карго-культ, которые повторяют за Яндексом и придумывают свои смыслы таких собеседований.


            1. antonblockchain
              17.06.2022 10:44

              по этому в лайв кодинге будет вопрос:
              «а как там с массивами в json это тоже объекты?»


          1. segment
            17.06.2022 13:48

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


      1. JekaMas
        16.06.2022 19:07

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

        Нет открытого или доступного для демонстрации кода - не беда: предоагаю выбрать любой код на языке из вакансии и рассказать о нём в стиле код ревью.


      1. lebedec
        16.06.2022 19:15
        +2

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

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


        1. Nialpe
          16.06.2022 20:12
          +12

          Позволю себе продолжить вашу мысль:

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


        1. Dolios
          18.06.2022 01:03

          Приходит повар в ресторан на собеседование, а ему говорят: давайте приготовим что-нибудь. А он в ответ: ещё чего, от повара готовить требуете, в таком месте лучше не работать!


    1. funca
      17.06.2022 07:22
      -1

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


      1. lebedec
        17.06.2022 08:23
        +3

        А разве такие рабочие ситуации бывают? Приходит продукт менеджер и говорит: "отсортируй пузырьком клиентов по дате подписки". У вас такое бывало?

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

        Как правило задачи от бизнеса выглядят так:

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

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

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


        1. Spunreal
          17.06.2022 12:25

          отсортируй пузырьком клиентов по дате подписки

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


    1. dopusteam
      17.06.2022 08:33
      +3

      А как нанимать то? Лайв кодить нельзя, алгоритмы - нельзя, system design, видимо, тоже нельзя.


      1. Nialpe
        17.06.2022 09:25
        +1

        Попробую рассказать про свое видение этой ситуации... Я - разработчик и у меня есть задачи на спринт, работая над задачей могу сделать перерыв, прогуляться, попить кофе, обсудить с коллегой, посмотреть схожне решение в проекте и воспользоваться отчасти (или полностью) им, почитать документацию и статьи, и даже (о, ужас!) погуглить или залезть на stackоverflow - все это возможно потому, что я бездарь, а возможно потому, что сторонник взвешенных решений (т.к. работаю в финтех). Это вкратце мой рабочий процесс. Как это соотносится с тем, что обычно происходило у меня на алгоритмических и лайвкодинг собеседованиях, я не понимаю до сих пор, честно.

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


      1. lebedec
        17.06.2022 09:27
        +3

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

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

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


        1. dopusteam
          17.06.2022 12:23
          +1

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

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

          В формате беседы - это хорошо. К сожалению, иногда это слишком далеко от реальности, некоторые кандидаты очень сладко беседуют, но потом очень плохо работают.


          1. lebedec
            17.06.2022 15:54
            +1

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

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

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

            Другое дело конечно, если надо "работать", то есть сидеть в штате ровно как можно дольше. Тогда, да, надо проверить что человек хороший и надёжный! Без шуток, надо проверить по всем параметрам: образование, военный билет, медкомиссию, наличие профессиональных сертификатов, алгоритмы... 


      1. HellWalk
        17.06.2022 11:05
        +3

        А как нанимать то?

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

        Совершенно другой уровень собеседования, когда вместо классических вопросов "чем технология x отличается от технологии y" (например чем SQL-базы отличаются от NoSQL) задают вопрос "в каких случаях лучше использовать технологию x, а в каких - y"

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

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

        С другой стороны, вопросы должны соответствовать уровню зарплаты. Если запросы на сеньор+, а зарплата милда - такие работодатели идут лесом сразу.


        1. dopusteam
          17.06.2022 12:26

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


      1. Spunreal
        17.06.2022 12:26
        +1

        А как нанимать то? Лайв кодить нельзя, алгоритмы - нельзя, system design, видимо, тоже нельзя.

        Просто сразу взять синьора помидора. Он же врать не будет по поводу своих навыков и точно подходит.


  1. warhamster
    18.06.2022 01:28

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

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


    1. kostyanoy Автор
      18.06.2022 11:24

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

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