У команды Хекслета немало опыта проведения технических собеседований. Мы делились опытом и советами в вебинаре «Собеседования: взгляд со стороны работодателя». А сегодня публикуем перевод статьи с советами от компании, которая помогает людям готовиться к собеседованиям.
От себя хочу добавить, что не смотря на полезность этих советов, если описанный здесь человек — это не вы, то не нужно стараться эмулировать его.
Болтайте профессионально
Прежде чем начать обсуждение кода, большинство интервьюеров любят обсудить ваш опыт. Они хотят услышать:
- Метапознания о коде. Задумываетесь ли вы о том, что означает «качество» кода?
- Ответственность и лидерство. Рассматриваете ли вы работу в условиях конкуренции? Исправляете ли вы что-то неверное, даже если этого не требуется?
- Общение. Обсуждение с вами технической проблемы будет практичным или болезненным?
У вас должен быть хотя бы один из этих пунктов:
- пример интересной технической проблемы, которую вы разрешили;
- пример межличностного конфликта, который вам удалось преодолеть;
- как вы были в роли руководителя или долевого участника;
- история о том, что стоило сделать иначе в предыдущем проекте;
- пара мелочей о вашем любимом языке, и что вам нравится и не нравится в нём
- вопрос о текущем продукте и бизнесе компании
- вопрос об инженерной стратегии компании (тестирование, скрам и т.д.)
Жадно интересуйтесь всем. Покажите, что гордитесь своими достижениями, что вам интересно то, чем занимается компания, и у вас есть собственное мнение о языках и рабочих процессах.
Поддерживайте диалог
Как только вы перейдёте к топикам о программировании, главное — поддерживать диалог. Кандидат, которому требовалась помощь в течение интервью, но который охотно участвовал в беседе, очевидно, может оказаться лучше, чем кандидат, который не задержался на теме.
Разберитесь, какого типа данная задача. Есть два типа задач:
- Программирование. Интервьюер хочет видеть, что вы пишете чистый, эффективный код для решения проблемы.
- Короткая беседа. Интервьюер просто хочет, чтобы вы что-то рассказали. Часто задаются вопросы либо (1) о системном проектировании высокого уровня («Как бы вы построили клон Твиттера»?) или (2) о мелочах («Что такое хойстинг в JavaScript»?). Иногда мелочи — это подготовка к «реальному» вопросу, например, «Насколько быстро можно отсортировать массив целых чисел? Хорошо, теперь, вместо целых чисел у нас....»
Бывает, что вы начали писать код, а интервьюер просто хотел короткий ответ перед тем как перейти к «реальному» вопросу. Поэтому просто спросите: «нужно ли писать для этого код»?
Покажите, что умеете работать в команде. Интервьюер хочет знать, каково работать над задачей в команде с вами, так что дайте понять, что способны на коллективную работу. Используйте «мы» вместо «я», например: «если бы мы breadth-first поиск, то получили бы ответ за O(n)». Если вам нужно выбрать, где писать код — на бумаге или на доске, всегда выбирайте доску. В этом случае, вы будете находиться рядом с интервьюером, решая задачу (а не напротив него, с барьером в виде стола).
Думайте вслух. Серьезно! Скажите, «Попробуем сделать это вот так — не уверен, что это сработает.» Если вы застряли, просто скажите, что думаете. Скажите, что может сработать. Скажите, что вам кажется, могло бы сработать и почему не работает. Это также относится к тривиальным коротким вопросам. Если вас попросят объяснить замыкания в Javascript, ответ — «это что-то связанное с областью видимости и помещением чего-то в функцию», скорее всего, засчитается как 90% ответа.
Признавайтесь, если вы не знаете чего-то. Если вы затронули факт (например, мелочи конкретного языка, какие-то детали рантайма), не пытайтесь показать, что знаете то, чего не знаете. Вместо этого скажите, «я не уверен, но думаю, так, потому что ...». Потому что может включать исключение других вариантов, при одновременной демонстрации того, что они имеют бессмысленные последствия, или сравнение с другими языками или другими задачами.
Не торопитесь с выводами. Не кидайте ответ сразу. Если он верный, вам всё равно нужно будет его объяснить, а если нет — вы будете выглядеть глупо. Вы ничего не выиграете тем, что будете торопиться, и, скорее всего, только раздразните интервьюера.
Выйдите из стопора
Иногда вы оказываетесь в состоянии невесомости. Расслабьтесь. Это не значит, что всё потеряло смысл. Помните, что интервьюеру, как правило, важнее ваша способность разумно рассматривать задачу под разными углами, чем способность точно ответить на вопрос. Когда кажется, что надежды больше нет, продолжайте рассуждать.
Рисуйте картинки. Не тратьте время, размышляя молча — думайте на доске. Нарисуйте пару различных тестовых вводных данных. Рисуйте процесс получения требуемого результата. Затем подумайте о переводе вашего подхода в код.
Решите более простую версию задачи. Не знаете, как найти 4-й по величине элемент в множестве? Подумайте о том, как найти 1-й элемент и подумайте, можете ли вы адаптировать этот подход.
Напишите наивное, неэффективное решение и оптимизируйте его позже. Используйте брутфорс. Делайте все, что в ваших силах, чтобы получить хотя бы какой-то ответ.
Думайте вслух чаще. Говорите, что знаете. Говорите, что вам казалось, может сработать и почему это не сработает. Может внезапно оказаться, что на самом деле это сработает, или сработает модифицированная версия вашего вывода. Или вы можете получить подсказку.
Ждите подсказки. Не смотрите на собеседующего в ожидании, но остановитесь на секунду, чтобы подумать — интервьюер, возможно, уже решил подсказать вам что-то и просто ждет, чтобы не перебивать.
Подумайте о границах памяти и времени выполнения. Если вы не уверены, что можете оптимизировать своё решение, думайте об этом вслух. Например:
- Мне нужно, как минимум, рассмотреть все элементы, поэтому лучше, чем O(n) не сделать.
- Грубый метод решения — проверить все возможности, а это O(n?2??).
- В ответе будет n2 элементов, так что мне потребуется как минимум потратить такое-же времени.
Выгружайте свои мысли
Легко споткнуться о себя. Сначала сосредоточьтесь на том, чтобы освободиться от своих мыслей, а потом беспокойтесь о деталях.
Вызовите вспомогательную функцию и продолжайте. Если вы не можете догадаться, как реализовать какую-то часть алгоритма, большую или маленькую, просто пропустите её. Напишите обращение к обоснованно названной вспомогательной функции, скажем, «это будет выполнять X» и продолжайте. Если вспомогательная функция тривиальна, вам, возможно, даже не понадобится реализовывать её.
Не беспокойтесь о синтаксисе. На время переключитесь обратно на английский язык, если это потребуется. Просто скажите, что вернётесь к синтаксису.
Оставьте себе достаточно места. Вероятно вам потребуется добавить строки кода или заметки между строками позже. Начинайте с верхней части доски и оставляйте пустую строку после каждой строки кода.
Оставьте точную проверку индексов на потом. Не беспокойтесь о том, какой у вас будет for-цикл "<" или "<=". Поставьте напоминалку, чтобы вернуться к этому в конце. Главное запишите основной алгоритм.
Используйте описательные имена переменных. Это займет определённое время, но
поможет вам не потеряться в своем коде. Используйте names_to_phone_nums_map вместо nums. Задействуйте тип в переменной. Функции, возвращающие булевы должны начинаться с «is_» (в зависимости от принятого в языке стандарта, возможные другие варианты, например, "?" в конце имени функции). Переменные, которые содержат список, должны заканчиваться на «s». Выберите стандарты, которые вам понятны и придерживайтесь их.
Приведите всё в порядок
Пробегитесь по своему решению вручную, вслух, используя для примера исходные данные. Записывайте какие значения содержат переменные, когда программа будет выполняться. вы не получите никаких плюсов, если будете проворачивать это у себя в голове. Это поможет найти баги и развеять сомнения, которые могли появиться у собеседующего в процессе ваших объяснений.
Вернитесь к off-by-one errors. Возможно стоит использовать "<=" вместо "<"?
Протестируйте пограничные случаи. Они могут включать пустые сеты, одноэлементные сеты или отрицательные числа. Как бонус, упомяните юнит-тесты!
Не будьте занудой. Некоторым интервьюерам наплевать на наведение порядка. Если вы не уверены, скажите что-то вроде: «Потом я, как правило, проверяю код на пограничные случаи — стоит нам это дальше делать»?
Практикуйтесь
В конце концов, с практикой ничего не сравнится. Ходите на собеседования почаще.
Пишите код ручкой на бумаге. Не обманывайте себя. Вначале, возможно, будет не по себе. Хорошо. Вам нужно избавиться от этой неловкости сейчас, чтобы не облажаться, когда дело дойдёт до реального интервью.
Комментарии (30)
dmomen
03.11.2015 15:00+4если описанный здесь человек — это не вы, то не нужно стараться эмулировать его.
А если описанный здесь человек — это он, то ему ваша статья не нужна. Такие дела.
stavinsky
03.11.2015 17:37Самому пришло голову нечто подобное ) Это как можно учить годами Карнеги и подобных и не уметь общаться, а можно родиться(или быть воспитанным не знаю что точнее ) так что эти знания уже есть на подсознании с рождения и никакой Карнеги не нужен.
minamoto
03.11.2015 17:49Если описанный здесь человек — он, то он может просто не уметь об этом рассказать. Статья о том, как показать то, кто есть вы, что вы умеете, и как именно вы делаете свою работу. Далеко не все могут это показать.
vayho
03.11.2015 15:21+5Из статьи не понял зачем мне нужно писать код на бумажке в 2015. А вообще большинство советов: как вам вести себя на собеседовании у НАС в компании. Имхо.
omickron
03.11.2015 15:40+4зачем мне нужно писать код на бумажке в 2015.
Исходя из практики — на собеседованиях часто предлагают.vayho
03.11.2015 16:10-1Кажой задаче свое средство
— нужно написать решение какой то неизвестной задачи? дайте нормально средство, например IDE где я смогу проверить разные варианты и сделать как надо
— вам нужен ход моих мыслей? мне не нужна бумага, я вам и так скажу
— вы ждете что я и так знаю решение(в случае с алгоритмами)? тогда варианта 2, я его знаю и я его не знаю, поэтому бумажка мне почти никогда не поможет
Я знаю что на собеседование часто есть лист бумаги для собеседуемого, но я не считаю правильным давать писать код на нем. Порисовать квадратики в процессе размышления — да, выделить основные мысли чтобы не мешались в голове — да, нарисовать граф или массив — да, так мы часто делаем на работе. Для остального могли бы и ноутбук с IDE дать.stavinsky
03.11.2015 17:42+1По моему личному мнению, человек который может писать код на бумажке знает о языке гораздо больше того человека который знает только IDE. Точнее даже не знает, а скорее больше уверен в своих знаниях.
Плюс бывают ну очень редкие случаи когда код надо срочно поправить в vim(nano, Блокнот), например. И я поставлю на того кто смог написать минимум на бумажке и не возьму того кто начал требовать IDE. (Да я знаю что это плохо править код на живую и тд и тп, но все бывает в нашем несовершенном мире)
Согласен что писать там больше чем один класс, наверное бессмысленно. А вот например попросить тот же самый синглтон описать я думаю очень даже хорошая идея(предчувствую споры о его нужности. Это другой вопрос, но теорию знать надо).vayho
04.11.2015 11:18Как понять знает только IDE? Для Java разработчика IDE это 30% сэкономленного времени. Вы наверно думаете что разработка это только знание конкретного языка программирования? Это не так, разработка это много много всего еще и знание IDE это не самый последний скил которым должен владеть разраб.
Но на собесах нас упорно заставляют писать код на бумажке, который даже нельзя оттестить, а ведь еще батюшка Фаулер писал что почти нереально сразу написать правильно работающий код.
В 2015 пора уже использовать какие то новые практики собеседований, перестать воспринимать соискателя как мышку над которой можно ставить эксперименты.
aikixd
04.11.2015 12:26Если вы отсеяли по этому признаку людей, то потеряли очень хороших кадоров. Я принципиально не могу писать код на бумаге. Я пишу код слоями, иногда снизу вверх, иногда сверху вниз, иногда я вижу код только «островками» и отталкиваюсь от них. Но я не могу писать код последовательно.
HaruAtari
03.11.2015 21:48+1Я в таких случаях вежливо отказываюсь. Меня реально бесят такие задачи. Ход мыслей можно и словами объяснить, а кодить на бумажке это издевательство какое-то. Я пишу как курица лапой, мне действительно неудобно и неприятно писать от руки. Думаю я не один такой.
Вообще после того, как мне на собеседовании начинают задавать дурацкие вопросы типа случаев с хитрым вычурным приведением типов, я настораживаюсь. Либо они делают это из праздного любопытства и не ценят мое время, либо у них такие подходы практикуются в разработке.
То же самое касательно кода на бумажке. Хотите посмотреть мой код? Пожалуйста его можно увидеть на моейм github профиле, с которым вы могли ознакомится перед собеседованием. Там прям по коммитам виден ход мыслей.
Я и так на собеседованиях туго тестовые задачи решаю. Просто потому что обстановка не комфортная. А тут еще добавляют.
anton1234
03.11.2015 18:44Вы правда хотите такого собеседника?
Попробуем сделать это вот так — не уверен, что это сработает.
Мое мнение, что слово «не уверен», вообще нельзя использовать. Вы либо знаете, что делаете либо нет. Можно построить гипотезу и проверить ее, это нормальный научный метод.
Так же как и совет вываливать весь свой мысленный процесс. Люди думают очень по разному, и логика иного соискателя может просто шокировать.
В целом описанный здесь человека во многом не уверен, и ему вы советуете всю свою неуверенность и пробелы в знаниях выставлять на показ?
Это напоминает доброго преподавателя, который старается двоишника вытянуть хотя бы на тройку.
summerwind
03.11.2015 22:48Потому что может включать исключение других вариантов, при одновременной демонстрации того, что они имеют бессмысленные последствия, или сравнение с другими языками или другими задачами.
Перечитал два раза, но так и не понял, что тут говорится.
sophist
04.11.2015 14:16После минимальной правки:
«Потому что» может включать в себя исключение других вариантов (при одновременной демонстрации того, что они имеют бессмысленные последствия), или сравнение с другими языками / другими задачами.
fareloz
04.11.2015 11:33+1У нас в компании в последнее время набирают новых сотрудников (уровня Junior, пост-универ в основном). И некоторых программистов просят поучавствовать в такого рода собеседованиях в качестве технических специалистов (собеседование ведет менеджер). Для себя отметил, что короткое задание с кодом на бумаге на 10 минут работы говорит мне о человеке больше, чем все аморфные высоко-теоретические вопросы заданные коллегами.
andreysmind
04.11.2015 13:17Можно узнать пример такого задания?
У сотрудника «пост-универ» и у сотрудника с опытом работы даже три-пять лет разные знания.fareloz
04.11.2015 14:44У сотрудника «пост-универ» и у сотрудника с опытом работы даже три-пять лет разные знания.
Не спорю
Можно узнать пример такого задания?
Задание имеет вид plain-code на двух А4 листах. три маленьких класса, две-функции не считая main(). Нужно найти ЛОГИЧЕСКИЕ (утечки памяти, краши, неверные обращения к памяти и так далее). Их порядка 30 (я очень старался :) ). Найти все ошибки не требуется.
Когда я даю такой тест я смотрю на: как человек читает чужой код, в зависимочти от найденных ошибок — смотрю на области знаний, как человек рассуждает.HaruAtari
09.11.2015 17:19Ну так вы же не заставляете человека самого писать код на бумажке. Это разные вещи. Читать код с бумаги или с экрана — не велика разница. А вот писать — совсем другое дело.
fareloz
09.11.2015 18:19Как я указал раньше — мы искали сотрудников уровня «пост-универ». Такие соискатели редко пишут хороший код. У нас большой и старый проект, в котором «пишут» код очень ограниченное количество людей проработавшие 10+ лет над системой. Поэтому в случае моей компании на начальных этапах важнее читать и понимать код. Кроме того я сторонник мнения, что без умения читать чужой код научиться писать хорошо самому очень сложно (стремиться к «невозможно»)
artemgapchenko
04.11.2015 11:33Используйте «мы» вместо «я», например: «если бы мы breadth-first поиск, то получили бы ответ за O(n)»
Это серьёзно так и работает? Я, например, иду в последний год в обратном направлении — стараюсь использовать почаще «я», чтобы показать (в том числе и самому себе), что решение принимаю я, исходя из своих знаний и представлений, и вне зависимости от результата ответственность остаётся на мне. Не издеваюсь, просто интересно понять, как это воспринимают с той стороны баррикад.Scf
04.11.2015 12:37Частое «я» означает противопоставление себя команде. «я сам принял решение» — другие будут с этим жить и вряд ли будут счастливы по этому поводу. «исходя из своих знаний и представлений» — самоуверенность, далеко не факт, что вы самый информированный. «ответственность на мне» — звучит как «если это писал не я то я за это не отвечаю».
Конечно, речь идет о команде сеньоров, но и к новичкам тоже имеет смысл прислушиваться.
andreysmind
04.11.2015 13:21+1По моему опыту это зависит от расположения звезд на небе.
Когда говорю «мы», то начинают задавать вопросы вроде «А ты что, сам не принимал решений никогда?»
Говорю «я» — тогда спрашивают: «А ты всегда сам работаешь или в команде?»
Поэтому я начал поступать мудро — перестал заморачиваться и обращать внимание на подобные советы.
Valeriy_tw3eX
У меня, почему-то, при прочтении подобных текстов, возникает чувство, что соискатели это некие бедные крестьяне, которые пришли испросить милости у графа. Отношения работник — работодатель больше партнерские, я думаю.
omickron
Поддерживаю. Правда, в некоторых случаях когда работник — незначительный легкозаменяемый «винтик», тип отношений меняется.
Valeriy_tw3eX
Да, хоть это и немного цинично
C «винтиками» обычно интервью проще в разы, советы не нужны эти.
minamoto
Не понимаю, почему у вас возникает такое чувство.
Текст описывает, как показать работодателю, что вы умеете программировать и умеете думать о том, как программировать. Это как экспресс-знакомство — за короткий промежуток времени вам нужно продемонстрировать все свои преимущества, чтобы потом, при обсуждении трудоустройства, выступать с позиций профессионала, подтвердившего свое мастерство и имеющего право претендовать на хорошую работу.
Почему описана только эта часть — потому что, как мне кажется, она — самая важная. Если вы научитесь правильно себя презентовать, особой проблемы с тем, чтобы в дальнейшем выторговать себе условия получше, особо не возникнет.
Valeriy_tw3eX
В «выторговывать» то и грусть. Просто в 80 процентах случаях (цифра с потолка, но думаю мысль ясна) происходит следующее. Соискатель около 2 часов распинается, а работодатель — «ну у нас есть кулер в коридоре и можно в автомате сникерсы покупать».
Просто мое личное мнение — если человек что-то умеет, ему нет нужды в подобных советах, не умеет — воспользоваться не сможет)
minamoto
Вот вам 31 вопрос, который можно задать работодателю: megamozg.ru/post/13704
Когда проходил последнее собеседование — проверял, выяснил из этого списка все, что мне было важно.
Не стесняйтесь задавать вопросы, это же партнерские отношения.