Как справиться с «плохим кодом» интервью? [закрыто]

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

Какой хороший способ справиться с такого рода собеседованиями, и в целом, какие есть хорошие методы для быстрого чтения и понимания кода ?

Интервью с плохим кодом (если они выполнены правильно) должны показывать вам код со следующим:

• Плохая языковая техника (не использование usingоператора в C # при необходимости или использование ArrayListвместо a List<T>)
• Плохое дизайнерское решение (какого черта мы везде передаем строки, или используем refи outпараметры так много?)
• Синтаксические ошибки (это даже не должно компилироваться!)
• Ошибки во время выполнения (например, переполнение стека, вызванное свойством, ссылающимся на себя в C #)

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

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

Айенде углубляется в серию « Заработная плата за грех ».

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

Ключ ИМО - просто мысли вслух. Поэтому, даже если вы замерзнете - просто скажите: «Я здесь напрягаюсь, но позвольте мне пройти через это медленно вслух».

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

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

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

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

Прежде всего, говорите о том, что вы делаете и думаете - это поможет и вам, и интервьюеру.

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

Я думаю, что хорошее место для начала (если вы не видите ничего очевидного) - это «отладка». Если вы не видите возможные проблемы сразу, хорошим началом будет создание небольшого списка тестовых значений. Хорошие значения - это «счастливый путь» (нормальное) значение, «нулевое» или «пустое» значение, нули, очень маленькое значение (строка из 1 символа, целое число 1 и т. Д.), Очень большое или очень длинное значение. value и «странные» значения, специфичные для типа (например, символы Unicode для строк, отрицательные числа для целых и т. д.). Здесь не мешало бы упомянуть, что обычно вы пишете модульные тесты, используя эти значения для проверки кода, и просто запускаете их для проверки функции.

Начните с того, что пройдете со своими значениями счастливого пути. Для функции сложения вы могли бы начать с 3 или 4. Изучите каждую строку на предмет опечаток и логических ошибок, отслеживая значения локальных переменных по мере продвижения. Надеюсь, вы найдете несколько ошибок. Когда вы закончите со счастливым путем, вы будете лучше чувствовать код и, надеюсь, почувствуете себя немного менее подавленным - скажем что-то вроде: «Теперь, когда я лучше понимаю, что делает этот код, я собираюсь сделать шаг назад и взглянуть на это ", а затем просто сделать это - искать вещи, которые выделяются для вас как вещи, которые вы бы сделали по-другому (плохие проектные решения, плохо названные переменные, исследовать возможные ошибки и т. д.).

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

Это, по крайней мере, поможет вам.

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

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

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

Там может быть две проблемы:

Это может быть «интервью со стрессом» http://en.wikipedia.org/wiki/Job_interview#Stress . Интервьюер пытается увидеть, как вы справляетесь со стрессом, так как их рабочая среда такова.

ИЛИ

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