[Перевод] Технические собеседования: советы
Привет, Хабр!
У команды Хекслета немало опыта проведения технических собеседований. Мы делились опытом и советами в вебинаре «Собеседования: взгляд со стороны работодателя». А сегодня публикуем перевод статьи с советами от компании, которая помогает людям готовиться к собеседованиям.
От себя хочу добавить, что не смотря на полезность этих советов, если описанный здесь человек — это не вы, то не нужно стараться эмулировать его.
Болтайте профессионально
Прежде чем начать обсуждение кода, большинство интервьюеров любят обсудить ваш опыт. Они хотят услышать:
- Метапознания о коде. Задумываетесь ли вы о том, что означает «качество» кода?
- Ответственность и лидерство. Рассматриваете ли вы работу в условиях конкуренции? Исправляете ли вы что-то неверное, даже если этого не требуется?
- Общение. Обсуждение с вами технической проблемы будет практичным или болезненным?
У вас должен быть хотя бы один из этих пунктов:
- пример интересной технической проблемы, которую вы разрешили;
- пример межличностного конфликта, который вам удалось преодолеть;
- как вы были в роли руководителя или долевого участника;
- история о том, что стоило сделать иначе в предыдущем проекте;
- пара мелочей о вашем любимом языке, и что вам нравится и не нравится в нём
- вопрос о текущем продукте и бизнесе компании
- вопрос об инженерной стратегии компании (тестирование, скрам и т.д.)
Жадно интересуйтесь всем. Покажите, что гордитесь своими достижениями, что вам интересно то, чем занимается компания, и у вас есть собственное мнение о языках и рабочих процессах.Поддерживайте диалог
Как только вы перейдёте к топикам о программировании, главное — поддерживать диалог. Кандидат, которому требовалась помощь в течение интервью, но который охотно участвовал в беседе, очевидно, может оказаться лучше, чем кандидат, который не задержался на теме.
Разберитесь, какого типа данная задача. Есть два типа задач:
- Программирование. Интервьюер хочет видеть, что вы пишете чистый, эффективный код для решения проблемы.
- Короткая беседа. Интервьюер просто хочет, чтобы вы что-то рассказали. Часто задаются вопросы либо (1) о системном проектировании высокого уровня («Как бы вы построили клон Твиттера»?) или (2) о мелочах («Что такое хойстинг в JavaScript»?). Иногда мелочи — это подготовка к «реальному» вопросу, например, «Насколько быстро можно отсортировать массив целых чисел? Хорошо, теперь, вместо целых чисел у нас....»
Бывает, что вы начали писать код, а интервьюер просто хотел короткий ответ перед тем как перейти к «реальному» вопросу. Поэтому просто спросите: «нужно ли писать для этого код»?
Покажите, что умеете работать в команде. Интервьюер хочет знать, каково работать над задачей в команде с вами, так что дайте понять, что способны на коллективную работу. Используйте «мы» вместо «я», например: «если бы мы breadth-first поиск, то получили бы ответ за O(n)». Если вам нужно выбрать, где писать код — на бумаге или на доске, всегда выбирайте доску. В этом случае, вы будете находиться рядом с интервьюером, решая задачу (а не напротив него, с барьером в виде стола).
Думайте вслух. Серьезно! Скажите, «Попробуем сделать это вот так — не уверен, что это сработает.» Если вы застряли, просто скажите, что думаете. Скажите, что может сработать. Скажите, что вам кажется, могло бы сработать и почему не работает. Это также относится к тривиальным коротким вопросам. Если вас попросят объяснить замыкания в Javascript, ответ — «это что-то связанное с областью видимости и помещением чего-то в функцию», скорее всего засчитается как 90% ответа.
Признавайтесь, если вы не знаете чего-то. Если вы затронули факт (например, мелочи конкретного языка, какие-то детали рантайма), не пытайтесь показать, что знаете то, чего не знаете. Вместо этого скажите, «я не уверен, но думаю, так, потому что ...». Потому что может включать исключение других вариантов, при одновременной демонстрации того, что они имеют бессмысленные последствия, или сравнение с другими языками или другими задачами.
Не торопитесь с выводами. Не кидайте ответ сразу. Если он верный, вам всё равно нужно будет его объяснить, а если нет — вы будете выглядеть глупо. Вы ничего не выиграете тем, что будете торопиться, и, скорее всего, только раздразните интервьюера.
Выйдите из стопора
Иногда вы оказываетесь в состоянии невесомости. Расслабьтесь. Это не значит, что всё потеряло смысл. Помните, что интервьюеру, как правило, важнее ваша способность разумно рассматривать задачу под разными углами, чем способность точно ответить на вопрос. Когда кажется, что надежды больше нет, продолжайте рассуждать.
Рисуйте картинки. Не тратьте время, размышляя молча — думайте на доске. Нарисуйте пару различных тестовых вводных данных. Рисуйте процесс получения требуемого результата. Затем подумайте о переводе вашего подхода в код.
Решите более простую версию задачи. Не знаете, как найти 4-й по величине элемент в множестве? Подумайте о том, как найти 1-й элемент и подумайте, можете ли вы адаптировать этот подход.
Напишите наивное, неэффективное решение и оптимизируйте его позже. Используйте брутфорс. Делайте все, что в ваших силах, чтобы получить хотя бы какой-то ответ.
Думайте вслух чаще. Говорите, что знаете. Говорите, что вам казалось, может сработать и почему это не сработает. Может внезапно оказаться, что на самом деле это сработает, или сработает модифицированная версия вашего вывода. Или вы можете получить подсказку.
Ждите подсказки. Не смотрите на собеседующего в ожидании, но остановитесь на секунду, чтобы подумать — интервьюер, возможно, уже решил подсказать вам что-то и просто ждет, чтобы не перебивать.
Подумайте о границах памяти и времени выполнения. Если вы не уверены, что можете оптимизировать своё решение, думайте об этом вслух. Например:
- Мне нужно, как минимум, рассмотреть все элементы, поэтому лучше, чем O(n) не сделать.
- Грубый метод решения — проверить все возможности, а это O(n2).
- В ответе будет n2 элементов, так что мне потребуется как минимум потратить такое-же времени.
Выгружайте свои мысли
Легко споткнуться о себя. Сначала сосредоточьтесь на том, чтобы освободиться от своих мыслей, а потом беспокойтесь о деталях.
Вызовите вспомогательную функцию и продолжайте. Если вы не можете догадаться, как реализовать какую-то часть алгоритма, большую или маленькую, просто пропустите её. Напишите обращение к обоснованно названной вспомогательной функции, скажем, «это будет выполнять X» и продолжайте. Если вспомогательная функция тривиальна, вам, возможно, даже не понадобится реализовывать её.
Не беспокойтесь о синтаксисе. На время переключитесь обратно на английский язык, если это потребуется. Просто скажите, что вернётесь к синтаксису.
Оставьте себе достаточно места. Вероятно вам потребуется добавить строки кода или заметки между строками позже. Начнинайте с верхней части доски и оставляйте пустую строку после каждой строки кода.
Оставьте точную проверку индексов на потом. Не беспокойтесь о том, какой у вас будет for-цикл "<" или "<=". Поставьте напоминалку, чтобы вернуться к этому в конце. Главное запишите основной алгоритм.
Используйте описательные имена переменных. Это займет определённое время, но
поможет вам не потеряться в своем коде. Используйте names_to_phone_nums_map вместо nums. Задействуйте тип в переменной. Функции, возвращающие булевы должны начинаться с «is_» (в зависимости от принятого в языке стандарта, возможные другие варианты, например, "?" в конце имени функции). Переменные, которые содержат список, должны заканчиваться на «s». Выберите стандарты, которые вам понятны и придерживайтесь их.
Приведите всё в порядок
Пробегитесь по своему решению вручную, вслух, используя для примера исходные данные. Записывайте какие значения содержат переменные, когда программа будет выполняться. вы не получите никаких плюсов, если будете проворачивать это у себя в голове. Это поможет найти баги и развеять сомнения, которые могли появиться у собеседующего в процессе ваших объяснений.
Вернитесь к off-by-one errors. Возможно стоит использовать "<=" вместо "<"?
Протестируйте пограничные случаи. Они могут включать пустые сеты, одноэлементные сеты или отрицательные числа. Как бонус, упомяните юнит-тесты!
Не будьте занудой. Некоторым интервьюерам наплевать на наведение порядка. Если вы не уверены, скажите что-то вроде: «Потом я, как правило, проверяю код на пограничные случаи — стоит нам это дальше делать»?
Практикуйтесь
В конце концов, с практикой ничего не сравнится. Ходите на собеседования почаще.
Пишите код ручкой на бумаге. Не обманывайте себя. Вначале, возможно, будет не по себе. Хорошо. Вам нужно избавиться от этой неловкости сейчас, чтобы не облажаться, когда дело дойдёт до реального интервью.
