Как подготовиться к собеседованию на позицию разработчика

Посетители сайта Quora рассказали о том, как они готовятся (готовились) к своим собеседованиям.

Марк Али. Проходил стажировку в Google и Facebook и, наконец, получил свой оффер

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

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

Нужно знать базовые структуры данных и алгоритмы. Это самая фундаментальная вещь для собеседования на позицию разработчика. Если провалитесь в структурах данных, которые учили еще в университете, то и все собеседование пойдет коту под хвост. Я не преувеличиваю: побывав на нескольких технических собеседованиях, вы поймете всю важность этих тем.
Практикуйтесь писать код на белой доске. Большинство людей этот совет игнорируют. На первый взгляд кажется, что это не должно вызывать проблем, верно? Но только до тех пор, пока не попробуете. Вам будет ужасно недоставать этих восхитительных сочетаний клавиш в вашей IDE или текстовом редакторе. Также окажется весьма неудобным, что вы не сможете модифицировать код путем копирования и вставки. Но вам придется научиться со всем этим справляться, потому что на большинстве реальных собеседований вас попросят написать на доске ПОЛНЫЙ код решения. Его не надо будет компилировать, но он должен быть написан. Не псевдокод!
Практикуйтесь на вопросах с реальных собеседований. Есть тысячи ресурсов, где вы сможете найти эти задачи. Если у вас на примете конкретная компания, лучше тренироваться на вопросах, которые задают именно там. Не стоит ожидать, что в итоге вам зададут в точности такой же вопрос (хотя это возможно). Но практика на задачах с реальных собеседований поможет вам ориентироваться в том, вопросы какого рода и сложности стоит ожидать в компании, которая вам интересна.
Практикуйтесь на постановочных собеседованиях. Это отличный способ приобрести некоторый опыт в ситуации, где вы не можете ничего потерять. Тренироваться можно с друзьями и, в свою очередь, помогать им тем же. Я также проходил постановочные собеседования на http://www.gainlo.co. Интервьюеры на этом ресурсе работают в Google, Facebook и т. д.; я получил от них очень много отзывов. Многие люди игнорируют постановочные собеседования, поскольку их не так просто организовать. Ведь вам нужно найти подходящего человека, к тому же это требует времени. Но дело того стоит!

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

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

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

Сохам Мехта из InterviewKickstart.com

Как справедливо отметил Пол Брайант, «Каждый хочет победить, но мало кто хочет готовиться к победе».

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

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

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

Если же вам нужно подготовиться за ограниченное время, тогда:

0. Имейте четкое представление, на какие компании вы нацеливаетесь

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

1. Выберите и остановитесь на одном языке программирования для ваших тренировок

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

2. Подходите к делу системно

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

При подготовке к вопросам по программированию (вопросы по структурам данных и алгоритмам), а также по проектированию систем / дизайну архитектуры / моделированию объектов вам помогут следующие ресурсы:

Книги: «Elements of Programming Interviews», «Cracking the Coding Interview» («Карьера программиста»).

Сайты: Leetcode, Interview Cake, InterviewBit, GeeksforGeeks, HiredInTech (кроме моделирования объектов)

Курсы: http://interviewkickstart.com (я проходил именно эти курсы).

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

3. Отдавайте предпочтение нескольким раундам «вширь», а не «вглубь»

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

Почему? Потому что все строится друг на друге.

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

Относительно пробных собеседований важно помнить два правила:

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

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

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

5. Обеспечьте себя системой поддержки и верьте в силу практики

Осознайте, что обучение это ступенчатый, а не линейный процесс. Выполнив 10 задач на одну тему, вы не станете в два раза искуснее, чем выполнив 5.

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

Это медленное восхождение, часто требующее решения 400-500 задач. И способа сократить этот путь нет.

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

6. Готовьтесь к тому чтобы стать хорошим инженером, а не просто хорошо проходить собеседования

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

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

Брайан Шмитц, работал в Google

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

Я сделаю упор на долгосрочную техническую подготовку.

Вам точно нужно знать:

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

Общая подготовка:

Прочтите «Cracking the Coding Interview» («Карьера программиста») Гейла Макдауэлла. Это классическая книга по подготовке к техническим собеседованиям, в ней вы найдете практически все, что вам нужно знать.
Практические задачи можно найти на Career Cup, Glassdoor и leetcode. Участие в соревновательном программировании также является отличным способом подготовки к собеседованиям.
Работайте над интересными личными проектами. Подумайте над участием в хакатонах или open-source проектах.

Усиленная подготовка:

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

Что касается специализированных ролей, я бы сделал упор на личные проекты, участие в open-source, проведение исследований, посещение лекций по нужному предмету.

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

Подходы к техническим вопросам:

Первая сложность состоит в том, что не надо бросаться с места в карьер. Приступайте к написанию кода только когда вы: 1) уверены, что путь, которым вы собираетесь пойти, позволит вам решить всю или большую часть задачи, а не первые ее строчки; 2) разъяснили для себя любые очевидные неясности, которые влияют на решение проблемы. Если вы начнете писать код до выполнения первого пункта, для интервьюера это сработает как красный флаг.
Если у вас есть очевидное брутфорс-решение и очень расплывчатое представление о возможном лучшем варианте, начните с брутфорс-решения. При этом объясните интервьюеру, что начнете вы с этого простого подхода, а затем посмотрите, сможете ли улучшить его, когда у вас в руках будет рабочий код. Что-то всегда лучше, чем ничего, а последовательное улучшение кода позволит предположить, что у вас происходит алгоритмический мыслительный процесс.
Вы должны говорить понятно и спокойно. Не замолкайте, чтобы интервьюер знал, о чем вы думаете, куда идете и какие проблемы учитываете.
Всегда прислушивайтесь к подсказкам интервьюера.
Если вы не уверены в какой-то специфической функции или особенности языка, которые используете и которые не относятся к общим знаниям, спросите интервьюера, можете ли вы предположить, что определенный функционал существует и ведет себя определенным образом. Часто интервьюер позволит вам сделать такое допущение (даже если на самом деле такой функционал не существует), посчитав это небольшим недочетом.
Если вы застряли, скажите об этом интервьюеру и объясните, почему так вышло.
Когда вы закончили, не бойтесь потратить слишком много времени на тестирование своего кода на правильность, за исключением случая, когда интервьюер четко даст понять, что ваше решение правильное. На собеседовании у вас скорее всего будет только одна возможность сделать тест на корректность.

Удачи!

Кен Мазаика, директор и соучредитель thefirehoseproject.com

Готовьтесь к техническому собеседованию с учетом закона Мерфи.

Если на техническом собеседовании что-то может пойти не так, оно пойдет не так. Но, что удивительно, это сделает вас только сильнее.

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

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

4 года спустя я оказался по другую сторону стола для собеседований.

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

Я видел, как все начинает идти не так, с разных точек зрения, и это научило меня одной вещи.

Единственный способ совладать с законом Мерфи – ожидать неожиданностей.

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

Знайте, чего ожидать от типичного технического собеседования. Ожидать следует 10-минутного общения с каждым интервьюером и 50-80-минутную сессию у белой доски. Отрабатывайте именно этот сценарий.
Работайте над проектом, которым вы увлечены. Очень легко говорить о вещах, которыми любите заниматься.
Знайте, что имеет значение, а что нет (подсказка: вы должны хорошо уметь адаптироваться).
Самое главное, рассматривайте каждое собеседование как возможность для обучения, а не деловую встречу.

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

[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]