Практические уроки по программированию
97,02
рейтинг
3 ноября 2015 в 12:41

Разработка → Технические собеседования: советы перевод

Привет, Хабр!

У команды Хекслета немало опыта проведения технических собеседований. Мы делились опытом и советами в вебинаре «Собеседования: взгляд со стороны работодателя». А сегодня публикуем перевод статьи с советами от компании, которая помогает людям готовиться к собеседованиям.

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

Болтайте профессионально


Прежде чем начать обсуждение кода, большинство интервьюеров любят обсудить ваш опыт. Они хотят услышать:
  • Метапознания о коде. Задумываетесь ли вы о том, что означает «качество» кода?
  • Ответственность и лидерство. Рассматриваете ли вы работу в условиях конкуренции? Исправляете ли вы что-то неверное, даже если этого не требуется?
  • Общение. Обсуждение с вами технической проблемы будет практичным или болезненным?

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

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

Поддерживайте диалог

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

Разберитесь, какого типа данная задача. Есть два типа задач:
  1. Программирование. Интервьюер хочет видеть, что вы пишете чистый, эффективный код для решения проблемы.
  2. Короткая беседа. Интервьюер просто хочет, чтобы вы что-то рассказали. Часто задаются вопросы либо (1) о системном проектировании высокого уровня («Как бы вы построили клон Твиттера»?) или (2) о мелочах («Что такое хойстинг в JavaScript»?). Иногда мелочи — это подготовка к «реальному» вопросу, например, «Насколько быстро можно отсортировать массив целых чисел? Хорошо, теперь, вместо целых чисел у нас....»

Бывает, что вы начали писать код, а интервьюер просто хотел короткий ответ перед тем как перейти к «реальному» вопросу. Поэтому просто спросите: «нужно ли писать для этого код»?

Покажите, что умеете работать в команде. Интервьюер хочет знать, каково работать над задачей в команде с вами, так что дайте понять, что способны на коллективную работу. Используйте «мы» вместо «я», например: «если бы мы breadth-first поиск, то получили бы ответ за O(n)». Если вам нужно выбрать, где писать код — на бумаге или на доске, всегда выбирайте доску. В этом случае, вы будете находиться рядом с интервьюером, решая задачу (а не напротив него, с барьером в виде стола).

Думайте вслух. Серьезно! Скажите, «Попробуем сделать это вот так — не уверен, что это сработает.» Если вы застряли, просто скажите, что думаете. Скажите, что может сработать. Скажите, что вам кажется, могло бы сработать и почему не работает. Это также относится к тривиальным коротким вопросам. Если вас попросят объяснить замыкания в Javascript, ответ — «это что-то связанное с областью видимости и помещением чего-то в функцию», скорее всего, засчитается как 90% ответа.

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

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

Выйдите из стопора


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

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

Решите более простую версию задачи. Не знаете, как найти 4-й по величине элемент в множестве? Подумайте о том, как найти 1-й элемент и подумайте, можете ли вы адаптировать этот подход.

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

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

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

Подумайте о границах памяти и времени выполнения. Если вы не уверены, что можете оптимизировать своё решение, думайте об этом вслух. Например:
  • Мне нужно, как минимум, рассмотреть все элементы, поэтому лучше, чем O(n) не сделать.
  • Грубый метод решения — проверить все возможности, а это O(n​2​​).
  • В ответе будет n2 элементов, так что мне потребуется как минимум потратить такое-же времени.

Выгружайте свои мысли


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

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

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

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

Оставьте точную проверку индексов на потом. Не беспокойтесь о том, какой у вас будет for-цикл "<" или "<=". Поставьте напоминалку, чтобы вернуться к этому в конце. Главное запишите основной алгоритм.

Используйте описательные имена переменных. Это займет определённое время, но
поможет вам не потеряться в своем коде. Используйте names_to_phone_nums_map вместо nums. Задействуйте тип в переменной. Функции, возвращающие булевы должны начинаться с «is_» (в зависимости от принятого в языке стандарта, возможные другие варианты, например, "?" в конце имени функции). Переменные, которые содержат список, должны заканчиваться на «s». Выберите стандарты, которые вам понятны и придерживайтесь их.

Приведите всё в порядок


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

Вернитесь к off-by-one errors. Возможно стоит использовать "<=" вместо "<"?

Протестируйте пограничные случаи. Они могут включать пустые сеты, одноэлементные сеты или отрицательные числа. Как бонус, упомяните юнит-тесты!

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

Практикуйтесь


В конце концов, с практикой ничего не сравнится. Ходите на собеседования почаще.

Пишите код ручкой на бумаге. Не обманывайте себя. Вначале, возможно, будет не по себе. Хорошо. Вам нужно избавиться от этой неловкости сейчас, чтобы не облажаться, когда дело дойдёт до реального интервью.
Автор: @freetonik Parker Phinney
Hexlet
рейтинг 97,02
Практические уроки по программированию
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

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

  • +10
    У меня, почему-то, при прочтении подобных текстов, возникает чувство, что соискатели это некие бедные крестьяне, которые пришли испросить милости у графа. Отношения работник — работодатель больше партнерские, я думаю.
    • 0
      Отношения работник — работодатель больше партнерские

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

      Текст описывает, как показать работодателю, что вы умеете программировать и умеете думать о том, как программировать. Это как экспресс-знакомство — за короткий промежуток времени вам нужно продемонстрировать все свои преимущества, чтобы потом, при обсуждении трудоустройства, выступать с позиций профессионала, подтвердившего свое мастерство и имеющего право претендовать на хорошую работу.
      Почему описана только эта часть — потому что, как мне кажется, она — самая важная. Если вы научитесь правильно себя презентовать, особой проблемы с тем, чтобы в дальнейшем выторговать себе условия получше, особо не возникнет.
      • +4
        В «выторговывать» то и грусть. Просто в 80 процентах случаях (цифра с потолка, но думаю мысль ясна) происходит следующее. Соискатель около 2 часов распинается, а работодатель — «ну у нас есть кулер в коридоре и можно в автомате сникерсы покупать».

        Просто мое личное мнение — если человек что-то умеет, ему нет нужды в подобных советах, не умеет — воспользоваться не сможет)
        • +1
          Вот вам 31 вопрос, который можно задать работодателю: megamozg.ru/post/13704
          Когда проходил последнее собеседование — проверял, выяснил из этого списка все, что мне было важно.
          Не стесняйтесь задавать вопросы, это же партнерские отношения.
        • 0
          2 часа — это какое-то халявное интервью.

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

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

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

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

              Чтоб определить это, задаются алгоритмические задачки. Благо, что времена «почему люки круглые» и «как выжить в миксере, если вас уменьшили» давно прошли.
              А алгоритмические задачки полезны и могут пригодиться в любую минуту — всё базируется на них. Умение их решать подготавливает мозг и держит в тонусе. Откладывается алгоритм решения: посмотреть данные, проверить граничные условия…

              Меня на телефонном интервью спросили как отсортировать массив из нолей и единиц — это был устный вопрос, без кода.
              Можно решить вызвав стандартную библиотеку — O(n*log n) + расход по памяти, если вызовется сортировка слиянием.
              Можно посчитать ноли и создать отсотрированный — два прохода.
              Можно итерироваться с обеих сторон и перекидывать ноли в начало, единицы в хвост — один проход и никакой доп. памяти.
              За 3 минуты видно, что человеку не чужда оптимизация и когда у него возникнет что-то подобное в проекте он подумает использовать ли стандартную библиотеку или написать свой метод. В Java хватает библиотек, которые дублируют стандартные и оптимизируют их, но которые не следует использовать везде.

              Конечно, не на всяком проекте надо реализовывать что-то вычурное. Где-то достаточно получить данные и отобразить. Потом считать ввод и записать в БД. Но там быстро становится скучно. Но следующий проект будет интереснее и он может быть связан с чем угодно: видеопотоки, хранение данных, работа со внешними устройствами… мало ли чего.

              В Амазон, Гугл, Фейсбук и пр… обычно не спрашивают язык программирования — можно писать на чём угодно (только надо на этом чём угодно правильно писать). Язык, а уж тем более фреймворки — это дело вторичное. Хороший инженер освоит язык довольно быстро. А команда может работать над каким-то веб-приложением на Java, а завтра для оптимизации надо будет написать/дописать сервис на C, чтоб всё летало, — своего сишника нет, искать долго.

              Вот такое моё видение в интервьюировании в продуктовые компании. В сервисных компаниях (а-ля бодишоп) подход может быть другим. Им платят за человека, желательно, чтоб этот человек сидел на этом проекте долго, никуда не ушёл и не требовал повышения ЗП.
              • 0
                Мой комментарий был о негативном отношении к тем собеседованиям, на которых задают отрешённые задачи, вроде «почему люки круглые» и т. п. Как раз на эти задачи, как мне кажется, не стоит тратить время.

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

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

                • 0
                  Нет, люков там не было.
                  Я не присутствовал там — не могу сказать. Я могу предположить почему я некоторые не прошёл. И то не всегда. Но всегда можно себя потешить, что они ищут на более низкую позицию, чем ты себя показал :D

                  Не могу понять как вы пришли к «люкам» в статье — у меня сложилось впечатление, что там только про алгоритмтческие задачки говорилось.
  • +4
    если описанный здесь человек — это не вы, то не нужно стараться эмулировать его.


    А если описанный здесь человек — это он, то ему ваша статья не нужна. Такие дела.
    • 0
      Самому пришло голову нечто подобное ) Это как можно учить годами Карнеги и подобных и не уметь общаться, а можно родиться(или быть воспитанным не знаю что точнее ) так что эти знания уже есть на подсознании с рождения и никакой Карнеги не нужен.
    • 0
      Если описанный здесь человек — он, то он может просто не уметь об этом рассказать. Статья о том, как показать то, кто есть вы, что вы умеете, и как именно вы делаете свою работу. Далеко не все могут это показать.
  • +5
    Из статьи не понял зачем мне нужно писать код на бумажке в 2015. А вообще большинство советов: как вам вести себя на собеседовании у НАС в компании. Имхо.
    • +4
      зачем мне нужно писать код на бумажке в 2015.

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

        Я знаю что на собеседование часто есть лист бумаги для собеседуемого, но я не считаю правильным давать писать код на нем. Порисовать квадратики в процессе размышления — да, выделить основные мысли чтобы не мешались в голове — да, нарисовать граф или массив — да, так мы часто делаем на работе. Для остального могли бы и ноутбук с IDE дать.
        • 0
          Я вполне согласен с вашим утверждением. :)
        • +1
          По моему личному мнению, человек который может писать код на бумажке знает о языке гораздо больше того человека который знает только IDE. Точнее даже не знает, а скорее больше уверен в своих знаниях.
          Плюс бывают ну очень редкие случаи когда код надо срочно поправить в vim(nano, Блокнот), например. И я поставлю на того кто смог написать минимум на бумажке и не возьму того кто начал требовать IDE. (Да я знаю что это плохо править код на живую и тд и тп, но все бывает в нашем несовершенном мире)

          Согласен что писать там больше чем один класс, наверное бессмысленно. А вот например попросить тот же самый синглтон описать я думаю очень даже хорошая идея(предчувствую споры о его нужности. Это другой вопрос, но теорию знать надо).
          • 0
            Как понять знает только IDE? Для Java разработчика IDE это 30% сэкономленного времени. Вы наверно думаете что разработка это только знание конкретного языка программирования? Это не так, разработка это много много всего еще и знание IDE это не самый последний скил которым должен владеть разраб.
            Но на собесах нас упорно заставляют писать код на бумажке, который даже нельзя оттестить, а ведь еще батюшка Фаулер писал что почти нереально сразу написать правильно работающий код.
            В 2015 пора уже использовать какие то новые практики собеседований, перестать воспринимать соискателя как мышку над которой можно ставить эксперименты.
            • 0
              Ну вам врядли ставят задачу на 100 строк кода. И обычно эти задачи тестируются на доске легко.
              Написать правильно работающий код уровня интервью на Амазон, Гугл и т.д. реально.

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

              А вы как проводите интервью? Я пока что ничего не нашёл лучше чем collabedit для телефонного интервью и доски для очного. Да и многие другие компании тоже не нашли.

              И никто не ставит эксперименты над соискателями. Интервью — это имитация рабочего процесса. Вашему будущему коллеге надо найти сотрудника, на которого можно положиться, который умеет мыслить и решать поставленную задачу.
          • 0
            Если вы отсеяли по этому признаку людей, то потеряли очень хороших кадоров. Я принципиально не могу писать код на бумаге. Я пишу код слоями, иногда снизу вверх, иногда сверху вниз, иногда я вижу код только «островками» и отталкиваюсь от них. Но я не могу писать код последовательно.
            • 0
              Компании зачастую руководствуются принципом, что лучше не нанять 1-2 хороших программистов, чем нанять 1 плохого. Ибо от 1 плохого убытков будет больше.

              Если вы не можете писать код на бумажке — скорее всего вы не пройдёте интервью в компании типа Гугл, Амазон (думаю Яндекс в их числе). Я полностью понимаю, что может быть ваши цели могут быть совсем иными, но эти компании вы потеряли.
      • +1
        Я в таких случаях вежливо отказываюсь. Меня реально бесят такие задачи. Ход мыслей можно и словами объяснить, а кодить на бумажке это издевательство какое-то. Я пишу как курица лапой, мне действительно неудобно и неприятно писать от руки. Думаю я не один такой.

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

        То же самое касательно кода на бумажке. Хотите посмотреть мой код? Пожалуйста его можно увидеть на моейм github профиле, с которым вы могли ознакомится перед собеседованием. Там прям по коммитам виден ход мыслей.

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

          Плюс я перед интервью стараюсь даже в резюме не смотреть — чтоб «зачётка не работала на студента».

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

            Полагаю, достаточно авторизации.
            • 0
              Это мне даёт уверенность только в том, что его закоммитил этот человек.
              Студенты курсовые чужие сдают, например.
              • 0
                Технически — да, вы правы.
                И всё-таки речь не об одном коммите, а о наборе репозиториев и наборе коммитов в них, распределённых по длительному промежутку времени.

                Кроме того, можно задавать кандидату вопросы по содержанию коммитов.
                • 0
                  Слишком дорого будет нанимать — интервьюерам надо ещё и работать.
                  А тут потратить время на изучение коммитов, найти интересные.
                  Потом как понять это он сам придумал или ему сказали сделать так.
                  Потом вникнуть в суть проекта и прикинуть как сам бы сделал + ещё пару альтернативных вариантов. Хотя это надо сделать ещё до интервью — чтоб иметь возможность обсудить разные варианты.
                  У меня на код ревью иногда уходит больше времени, чем человек писал изменения. И я этот проект знаю.

                  Ну и не у каждого отличного программиста есть что-то на гитхабе.
                  А если надо будет сравнить 2х кандидатов, а у них разные проекты?
  • 0
    Вы правда хотите такого собеседника?
    Попробуем сделать это вот так — не уверен, что это сработает.

    Мое мнение, что слово «не уверен», вообще нельзя использовать. Вы либо знаете, что делаете либо нет. Можно построить гипотезу и проверить ее, это нормальный научный метод.
    Так же как и совет вываливать весь свой мысленный процесс. Люди думают очень по разному, и логика иного соискателя может просто шокировать.
    В целом описанный здесь человека во многом не уверен, и ему вы советуете всю свою неуверенность и пробелы в знаниях выставлять на показ?
    Это напоминает доброго преподавателя, который старается двоишника вытянуть хотя бы на тройку.
    • 0
      Лучше сказать, что неуверен, чем ляпнуть глупость.
      Я предполагаю, что если человек не уверен — не на интервью он проверит можно ли использовать это, а не сломает всё махом
  • 0
    Потому что может включать исключение других вариантов, при одновременной демонстрации того, что они имеют бессмысленные последствия, или сравнение с другими языками или другими задачами.

    Перечитал два раза, но так и не понял, что тут говорится.
    • 0
      После минимальной правки:
      «Потому что» может включать в себя исключение других вариантов (при одновременной демонстрации того, что они имеют бессмысленные последствия), или сравнение с другими языками / другими задачами.
  • +1
    У нас в компании в последнее время набирают новых сотрудников (уровня Junior, пост-универ в основном). И некоторых программистов просят поучавствовать в такого рода собеседованиях в качестве технических специалистов (собеседование ведет менеджер). Для себя отметил, что короткое задание с кодом на бумаге на 10 минут работы говорит мне о человеке больше, чем все аморфные высоко-теоретические вопросы заданные коллегами.
    • 0
      Можно узнать пример такого задания?

      У сотрудника «пост-универ» и у сотрудника с опытом работы даже три-пять лет разные знания.
      • 0
        У сотрудника «пост-универ» и у сотрудника с опытом работы даже три-пять лет разные знания.

        Не спорю

        Можно узнать пример такого задания?

        Задание имеет вид plain-code на двух А4 листах. три маленьких класса, две-функции не считая main(). Нужно найти ЛОГИЧЕСКИЕ (утечки памяти, краши, неверные обращения к памяти и так далее). Их порядка 30 (я очень старался :) ). Найти все ошибки не требуется.
        Когда я даю такой тест я смотрю на: как человек читает чужой код, в зависимочти от найденных ошибок — смотрю на области знаний, как человек рассуждает.
        • 0
          Спасибо, это пример хорошего задания на мой взгляд.
        • 0
          Ну так вы же не заставляете человека самого писать код на бумажке. Это разные вещи. Читать код с бумаги или с экрана — не велика разница. А вот писать — совсем другое дело.
          • 0
            Как я указал раньше — мы искали сотрудников уровня «пост-универ». Такие соискатели редко пишут хороший код. У нас большой и старый проект, в котором «пишут» код очень ограниченное количество людей проработавшие 10+ лет над системой. Поэтому в случае моей компании на начальных этапах важнее читать и понимать код. Кроме того я сторонник мнения, что без умения читать чужой код научиться писать хорошо самому очень сложно (стремиться к «невозможно»)
    • 0
      Наши Сишники тоже начали использовать такой подход.

      А в одной из компаний мне на собеседовании открыли класс в репозитории, показали 4 метода и спросили можно ли их как-то отрефакторить.

      Было весело =) Кстати, весь рефакторинг потом проходил у доски. Комп был только чтоб код посмотреть.
  • 0
    Используйте «мы» вместо «я», например: «если бы мы breadth-first поиск, то получили бы ответ за O(n)»

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

      Конечно, речь идет о команде сеньоров, но и к новичкам тоже имеет смысл прислушиваться.
    • +1
      По моему опыту это зависит от расположения звезд на небе.
      Когда говорю «мы», то начинают задавать вопросы вроде «А ты что, сам не принимал решений никогда?»
      Говорю «я» — тогда спрашивают: «А ты всегда сам работаешь или в команде?»
      Поэтому я начал поступать мудро — перестал заморачиваться и обращать внимание на подобные советы.
  • 0
    А вот мне нравится Codility как метод отбора. Задачки у них годные, и вообще, посадил человека перед компом, он прорешал, смотришь на то что и как. Ну а потом можно уже обсудить что получилось а что нет.
  • 0
    Только добрался откомментировать.

    Коротко о себе: живу в Сиэтле, работаю в компании Nordstrom, регулярно провожу как телефонные, так и очные собеседования (где-то 1.5 в неделю). Сам, разумеется, побывал во многих компаниях в качестве кандидата (5 завершились успешно)

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

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

    После на словах или схематично опишите возможные решения. Сравните их быстродействие и затраты по памяти ( ru.wikipedia.org/wiki«O»_большое_и_«o»_малое ) и спросите какой из них реализовывать.

    Познакомьтесь с стандартными структурами данных языка. И не только что оно делает, но и как они реализованы внутри.

    И тренируйтесь писать код от руки на доске. Очень загадочно выглядят программисты с опытом работы на Java в лет 10, которые не знают put или add в этой коллекции надо использовать.
    Так что желательно натренироваться так, чтоб ваш код от руки скомпилился и отработал правильно.

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

    Есть хорошая книжка — Cracking the Coding Interview www.amazon.com/Cracking-Coding-Interview-Programming-Questions/dp/098478280X
    • 0
      Всё это положительно впечатлит будущего коллегу. Ведь очень часто интервьюер — это ваш коллега/начальник и он ищет людей с которыми ему будет приятно, комфортно и интересно работать. Которым не надо будет постоянно указывать на огрехи и ошибки.

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

Самое читаемое Разработка