Технические Интервью: Советы

Привет, Хабр! Команда Гекслета Большой опыт проведения технических интервью.

Своим опытом и советами мы поделились на вебинаре « Собеседование: взгляд работодателя И сегодня мы публикуем перевод статьи с советами от компании, которая помогает людям подготовиться к собеседованиям.

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



Общайтесь профессионально

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

    Вы когда-нибудь задумывались, что означает «качественный» код?

  • Ответственность и лидерство.

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

  • Коммуникация.

    Будет ли обсуждение с вами технической проблемы практичным или болезненным?

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

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



Продолжайте диалог
Как только вы зайдете на темы программирования, главное — поддерживать разговор.

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

Определите, что это за задача.

Есть два типа задач:

  1. Программирование .

    Интервьюер хочет видеть, что вы пишете чистый и эффективный код для решения проблемы.

  2. Короткий разговор .

    Интервьюер просто хочет, чтобы вы что-то сказали.

    Часто задаваемые вопросы касаются либо (1) проектирования систем высокого уровня («Как бы вы создали клон TwitterЭ»), либо (2) мельчайших подробностей («Что такое хостинг в JavaScriptЭ»).

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

    »

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

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

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

Используйте «мы» вместо «я», например: «если бы мы выполнили поиск в ширину, мы получили бы ответ за O(n)».

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

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

Думайте вслух .

Серьезно! Скажите: «Давайте попробуем вот так – я не уверен, что это сработает».

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

Скажите мне, что может сработать.

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

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

Признайтесь, если вы чего-то не знаете .

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

Вместо этого скажите: «Я не уверен, но я так думаю, потому что…».

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

Не спешите с выводами .

Не отвечайте сразу.

Если это правильно, вам все равно придется это объяснять, а если нет, вы будете выглядеть глупо.

Если вы поторопитесь, вы ничего не добьетесь и, скорее всего, только разозлите интервьюера.



Вылезай из пробки

Иногда оказываешься в состоянии невесомости.

Расслабляться.

Это не значит, что все потеряло смысл.

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

Когда кажется, что надежды больше нет, продолжайте рассуждать.

Рисовать картинки .

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

Нарисуйте пару разных тестовых входных данных.

Нарисуйте процесс получения желаемого результата.

Затем подумайте о переводе вашего подхода в код. Решите более простой вариант задачи .

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

.

Используйте грубую силу.

Сделайте все, что в ваших силах, чтобы получить хоть какой-то ответ. Думайте вслух чаще .

Скажи то, что ты знаешь.

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

Подождите подсказки .

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

Подумайте о границах памяти и времени выполнения .

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

Например:

  • Мне нужно как минимум учесть все элементы, поэтому лучше, чем O(n), этого не делать.

  • Грубое решение — проверить все возможности, то есть O(n 2 ).

  • Ответ будет н 2 элементы, поэтому мне нужно будет потратить как минимум столько же времени.



Загрузите свои мысли

Легко споткнуться о себя.

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

Вызовите вспомогательную функцию и продолжайте .

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

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

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

Не беспокойтесь о синтаксисе .

При необходимости временно вернитесь на английский язык.

Просто скажите, что вы вернетесь к синтаксису.

Дайте себе достаточно места .

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

Начните с верхней части доски и оставляйте пустую строку после каждой строки кода.

Оставьте точную проверку индекса на потом .

Не беспокойтесь о том, будет ли ваш цикл for "<" or "<=".

Set a reminder to come back to this at the end. The main thing is to write down the main algorithm. Используйте описательные имена переменных .

Это займет некоторое время, но поможет вам не потеряться в коде.

Используйте names_to_phone_nums_map вместо nums. Вызов типа в переменной.

Функции, возвращающие логическое значение, должны начинаться с «is_» (в зависимости от стандарта языка возможны и другие варианты, например «Э» в конце имени функции).

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

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



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

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

.

Записывайте, какие значения содержат переменные во время работы программы.

Вы не получите никакой пользы, если будете делать это в своей голове.

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

Вернуться к ошибкам с точностью до единицы .

Возможно, нам следует использовать "<=" instead of "<"? Тестирование крайних случаев .

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

В качестве бонуса упомяните модульные тесты! Не будь скучным .

Некоторые интервьюеры не заботятся об уборке.

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

Упражняться

В конце концов, ничто не сравнится с практикой.

Чаще ходите на собеседования.

Напишите код ручкой на бумаге .

Не обманывайте себя.

Поначалу вы можете чувствовать себя некомфортно.

Отлично.

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

Теги: #собеседование #работа #устройство #разработка сайтов #программирование

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.