На собеседовании лучше кодировать грубое решение сложного вопроса или провести собеседование, тщательно изучая вопрос? [закрыто]

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

Например, проблема 91 в Project Euler может быть решена с помощью не очень сложного решения методом грубой силы: расчета каждого возможного треугольника, написания теста isRightTriangle () и выталкивания всех треугольников, которые проходят тест, в набор. Но две пары координат X / Y делают это решение O (x ^ 4) с высоким постоянным значением. Мы с другом только что придумали более элегантное и эффективное решение, но мы вдвоем потратили на него 3 часа и нарисовали десятки диаграмм, протестировали несколько формул, изучили несколько подходов и т. Д.

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

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

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

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

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

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

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

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

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

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

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

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

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

Есть ли правило, что через 20 минут вы должны просто начать писать код, несмотря ни на что?

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

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

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

Таким образом, мы могли бы явно поместить isRightTriangle(p1, p2, p3)функцию в середину четырех forциклов и выполнить итерацию по всем возможным вариантам для каждой из двух переменных точек. Давайте посмотрим ... проблема запрашивает количество прямоугольных треугольников, включая начало координат на сетке 50x50, поэтому использование метода грубой силы заставляет нас проверять 50 возможностей для каждой координаты каждой точки. Это 50 ^ 4 проверок ... Я уверен, что мы можем сделать лучше, но код очевиден, поэтому позвольте мне записать это ...

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

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

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

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

• Можете ли вы написать код
• Ваш стиль кодирования
• Алгоритм, который вы выбрали
• Указывает ли попытка, что вы поняли проблему
• Если я действительно в восторге от конкретной технологии, вы продемонстрировали, что более или менее знаете ее?

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

Стиль кодирования - я имею в виду не только то, куда вы кладете скобки, но и такие вещи, как:

• Вы выбрали состав или наследство для решения этой проблемы? Почему?
• Для этого значения, почему вы решили использовать enum против строки против int (или любой другой перестановки)
• Вы использовали свойства, поля или методы get / set для этого значения? Почему?
• Как вы справились с состоянием в ваших классах?
• Вы понимаете, как работают наследование, интерфейсы и лямбды?
• Понимаете ли вы соглашения о параметрах языка (что такое ref по значению?)
• Вы знаете, как писать модульные тесты?

Вот что меня действительно не волнует:

• Что он компилирует (при условии, что я только что дал вам блокнот и без компилятора)
• Что вы знали по памяти порядок этих двух параметров в одной функции
• Что вы можете читать строку подключения SQL Server или Oracle наизусть
• Что ты можешь прекрасно кодировать, пока я стою за твоим плечом, наблюдая за каждой ошибкой.

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

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

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

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

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

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

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

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