Энтони Кастрио и три основных момента, которые он обнаружил, которые превращают хорошее интервью в отличное.

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

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

Я обнаружил три основных момента, которые превращают хорошее интервью в отличное:

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

Прежде чем писать код: расскажите о себе

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

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

  • Есть ли в описании проблемы изображение фрактального узора? Ответ будет использовать рекурсию.
  • Указывает ли проблема, что все входные данные больше нуля? Решение может потребовать разделения.

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

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

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

Разница между 0 < x < 1000 и 0 <= x < 1000 невелика, но она может кардинально изменить ваш подход. Обратить особое внимание.

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

III. Объясните свой подход
Как можно больше объясните свои мысли вслух, но не говорите слишком много, если это отвлекает вас от поиска решения. Молчание может быть неудобным на собеседовании, но вы можете это контролировать. Сказав: «Я найду секунду, чтобы осмотреть это», можно нарушить молчание и позволит вам сосредоточиться на решении проблемы, а не на поиске правильных слов.

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

Если вам нужно освежить в памяти анализ большого О, ознакомьтесь с этим прекрасным объяснением.

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

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

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

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

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

Напишите чистый код

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

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

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

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

Говоря о . . .

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

IV. Используйте описательные имена и следуйте соглашениям

Вложены циклы for?
Назовите свои итераторы i и j.
Вы пишете функцию, которая что-то делает? Назовите это doThing():

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

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

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

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

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

Я знаю два лучших способа развить обоняние кода:

  1. Прочтите хороший код. На GitHub можно прочитать почти бесконечное количество хорошего кода. Ищите проекты с открытым исходным кодом с большим количеством звезд.
  2. Выполните рефакторинг собственного кода. Рефакторинг требует от вас понимания того, как можно улучшить хороший код. Вот что такое запах кода! Часто практикуйте рефакторинг, и вы будете хорошо пахнуть (или, по крайней мере, ваш код будет).

Просмотрите свое решение

Некоторые интервью проходят на доске, некоторые с простой подсветкой синтаксиса, а некоторые с выполнением кода и даже тестовыми примерами.

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

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

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

I. Прогуляйтесь
Если в вопросе есть пример, используйте его. В противном случае вам следует самому придумать простой пример. Внимательно и критически изучите свой код. Теперь у вас есть шанс найти ошибки.

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

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

Обратите внимание на некоторые из этих распространенных ошибок:

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

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

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

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

Немного вспомогательного кода может ускорить и упростить добавление новых тестов:

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

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

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

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

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

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

Со временем становится лучше.

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

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

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

Автор: Энтони Кастрио - внештатный менеджер по продукту и инженер-программист. Следуйте за ним на Medium или в Twitter @AnthonyCastrio
https://castrio.me