У меня недавно был спор с коллегой-программистом. Он брал интервью на новую должность и ему задавали этот вопрос:

Задайте последовательность чисел, начинающуюся с X и заканчивающуюся на Y, но при этом один элемент отсутствует, поэтому N равен YX-1, найдите отсутствующий элемент в O (N) или лучше.

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

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

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

Твои мысли? Хороший вопрос для интервью или нет?

Я согласен с вопросом об алгоритме, но я не согласен с настаиванием на конкретном уровне качества Big-O.

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

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

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

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

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

Требования

Такие вопросы намеренно занижены. В вашем примере нет дополнительной информации о последовательности. Если у вас есть собеседник, который спрашивает вас, действительно ли эти цифры отсортированы, это хороший знак. У него есть правильное мышление, чтобы спросить клиентов о более подробной информации, которая поможет прийти к лучшему решению в более короткие сроки. Кандидат также может поиграть с идеей использования пространства O (n) для хранения массива из N чисел, но он не должен этого делать, не спрашивая более подробную информацию о X и Y. Предположим, что X и Y находятся между 1 и 1000 тогда, конечно, продолжайте и запустите решение на основе массива. Но если я скажу вам, что интервал составляет 1 и 1 миллиард, то проблема становится совершенно другой. Позвольте мне еще раз подчеркнуть, что меня не волнует решение.

Стандартные методы

Я не хочу нанимать программиста, который даже не знает, что означает O (n). Это абсолютно необходимо знать, если у вас было достойное образование в этой области. Но также важно не просто знать, что это значит, но и применять эти знания. В вашем примере я хочу, чтобы кандидат осознал, что ему не разрешается сортировать данные (не задавая дополнительных вопросов, касающихся опции сортировки по группам или других подходов сортировки O (n)), поскольку требуется сортировка O (n log n) в целом.

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

Проблемное мышление

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

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

Как ответить

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

Как общее примечание по вопросам собеседования: встречные вопросы редко бывают плохими. В одном из моих собственных интервью меня, например, спросили что-то вроде следующего: «Если бы вам пришлось реализовать X, вы бы выбрали для этого C ++ или Java и почему?» - Я просто возразил: «Я ограничен этими двумя?». Подумайте сами, какую реакцию вы получаете от интервьюера на такой встречный вопрос - и насколько легко вам действительно показать интервьюеру, на что вы способны.

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

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

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

Проблема с этим конкретным вопросом заключается в том, что это почти хитрый вопрос. С одним конкретным пониманием вы легко придумаете O (n), в противном случае вы будете бороться, чтобы стать лучше, чем O (n log n). Это почти сводится к "Вы видели это раньше?"

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

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

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

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

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

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

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

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

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