Перевод статьи «How to prepare for a technical interview – tips and tricks to perform your best».
Ох уж эти технические собеседования.
«Бойся. Беги. Судьба настигнет всех», — Танос, 2018.
Ладно, может, это излишне драматично, но я не знаю ни единого человека, у которого процесс собеседований вызывал бы восторг. Поиск работы и связанные с ним интервью в лучшем случае очень утомительны (а в худшем о них можно сказать много чего другого).
Многие люди перед собеседованиями изучают различные приемы и хитрости их прохождения (я тоже поделюсь несколькими), но редко кто задумывается о тех установках, с которыми следует отправляться на собеседование.
А ведь отправляясь на встречу в правильном расположении духа, вы с большей вероятностью сумеете разобраться со всеми проблемами. Если же вы изначально будете рассеяны или робки, после собеседования это превратится в ощущение разбитости.
Вы тоже интервьюер
Большинство людей часто забывают одну вещь: на собеседовании вы тоже выступаете в роли интервьюера.
Да, в ходе собеседований компания оценивает вас, но и вы оцениваете ее, чтобы понять, насколько она вам подходит. Каковы ценности этой компании? Как здесь относятся к людям? Пройти собеседование важно, однако захотите ли вы в конечном итоге работать в этой компании?
Порой нам просто нужна работа — любая работа. Я не хочу и не буду приуменьшать значение этого. Но по возможности постарайтесь прикинуть, как эта работа повлияет на вашу карьеру в долгосрочной перспективе. Если вы говорите «да» этой компании, вы отказываете десятку других, т. е., платите довольно большую цену, отказываясь от других возможностей.
Итак, первое, что следует запомнить, это что собеседование — не односторонний процесс. Порой так кажется, но на самом деле у вас есть некоторый контроль над ситуацией и возможности выбора. Осознание этого факта очень помогает в процессе поиска работы.
Виды собеседований
Есть несколько видов технических собеседований. Они могут многое рассказать нам о порядках, существующих в компании, и о том, каково будет там работать. Я разделяю собеседования на следующие виды:
- Whiteboarding (собеседования с применением белой доски).
- Задачи на написание кода (вопросы по информатике или алгоритмы).
- Задачи на написание кода (какая-нибудь отдельная проблема).
- Проект, который выдается кандидату в качестве домашнего задания.
Ужасный whiteboarding
Whiteboarding это один из ранних вариантов проведения собеседований в индустрии технологий. Суть здесь в следующем: вам дается задача, а код решения нужно написать на доске. В целом, сегодня этот подход уже изживает себя, но многие компании все еще его практикуют.
Не то чтобы кодинг на белой доске был чем-то плох сам по себе. Но он слишком далек от того, чем реально занимаются программисты, ежедневно работающие с компьютерами. Писать и редактировать написанное на доске неудобно, на ней нет подсветки синтаксиса, да и в Google нельзя заглянуть, чтобы поискать стандартную библиотеку.
Кроме того, во многих местах, где все еще применяется whiteboarding, кандидатам также задают ряд вопросов, которые, честно говоря, в 99% случаев тоже бесполезны. Эти вопросы касаются алгоритмов: как повернуть двоичное дерево, как найти кратчайший путь в графе и т. п.
Проблема этих вопросов в том, что подобные задачи попросту не встречаются в реальной жизни программиста. Если вы проходите собеседование в Amazon или Facebook, тогда конечно, знание алгоритмов может представлять особую ценность для этих компаний, но большинство людей может за всю свою карьеру не столкнуться с такими задачами. А при необходимости эти люди просто используют какой-нибудь пакет или библиотеку, где нужный функционал уже будет реализован.
Что же делать, если whiteboarding все же практикуется в компании? Постарайтесь справиться с задачей как можно лучше, используйте советы и приемы, которые я изложу ниже, и серьезно подумайте, не является ли эта практика симптомом проблем в компании.
Задачи на написание кода
Если вам повезло уклониться от белой доски, в большинстве компаний вас попросят решить какие-нибудь задачи на написание кода. И это хорошо, потому что это ваш шанс показать свою техническую компетентность. К тому же, по своему опыту могу судить, что успешное решение задач на этом этапе очень сильно влияет на ваши возможности торга, когда речь зайдет о будущей зарплате.
Хотелось бы отметить, что несмотря на то, что вам удалось отвертеться от белой доски, вопросы и задачи на этом этапе все равно могут касаться алгоритмов, просто решать вы их будете за компьютером. Если это ваш случай, просто сделайте глубокий вдох и примените изученные приемы. Вы справитесь.
Если же вам повезло и в компании не практикуется ни whiteboarding, ни задачки на алгоритмы, скорее всего вам дадут для решения какую-нибудь хорошую задачу. Хорошими я считаю задания типа «Напишите функцию, принимающую количество центов (целое число, меньшее или равное 100) и выводящую наименьшее количество монет, которыми можно представить эти центы».
Мне также давали задачи, которые на первый взгляд казались довольно общими вопросами по информатике, но на самом деле были гораздо интереснее. Например, «реализуйте двусвязный список». Сначала это показалось стандартной задачей, но на самом деле интервьюер хотел код, реализующий поведение двусвязного списка. Т.е., я не использовал указатели, а добивался схожести в поведении. В том случае задача оказалась проще, чем я думал. И это подводит нас к моему первому совету:
Совет 1. Задавайте уточняющие вопросы
В задаче на двусвязный список мне давался пустой Ruby-файл (вакансия подразумевала работу на этом языке) и пустой набор тестов. Что-то такое:
class DoublyLinkedList end
(Если вы незнакомы с Ruby — не волнуйтесь. Код будет очень понятным, я привожу его лишь для иллюстрации).
Итак, двусвязный список, да? Может, вы знаете, что это такое, а может и нет. Если нет, спрашивайте. Это первая ловушка, которую следует обойти. Если вы не понимаете поставленную задачу или вопрос, продолжайте переспрашивать, пока не поймете.
Мне случалось видеть кандидатов, которые становились на путь, неизбежно ведущий к провалу, а интервьюер просто молча позволял им это делать. Я с таким подходом не согласен, так что обязательно убедитесь, что вы работаете именно над поставленной задачей, а не над чем-то, что сами себе придумали.
У меня был бэкграунд в информатике, так что я знал, что такое двусвязный список. Но, тем не менее, я проговорил задачу вслух и спросил, правильно ли все изложено. Даже несмотря на мою уверенность в том, что я знаю, что нужно делать, я все равно уточнил.
Когда вы думаете, что уже вполне поняли поставленную задачу, изложите свое понимание интервьюеру, чтобы он мог поправить вас или направить в нужную сторону.
Далее я задал другой вопрос: «Могу ли я использовать массив для узлов?» И напечатал что-то вроде следующего:
class DoublyLinkedList
def initialize
@nodes = []
end
end
Но интервьюер сказал, что нет, так нельзя — и в этом был определенный смысл. Если бы я использовал массив, это убило бы все назначение этого упражнения, заключавшегося в построении фейковых «указателей» между узлами.
И я чертовски рад, что задал этот вопрос. Ведь иначе интервьюер просто позволил бы мне использовать массив, а это было бы ошибкой.
Итак, массив отставляем. А как решать? Отсюда проистекает второй совет.
Совет 2. Сначала хардкодим, затем делаем топорное решение, затем улучшенное
Когда перед вами стоит какая-то задача на написание кода, сначала создайте решение в общих чертах, а затем улучшайте его.
Исходя из своего опыта собеседования по обе стороны стола, я считаю, что большинство людей пытаются сделать слишком много всего сразу. А это ведет к ошибкам. Поэтому начинайте с простого и постепенно продвигайтесь к более сложному.
Итак, у меня был пустой класс (Ruby). Я посмотрел в мой пустой набор тестов и увидел, что там была функция head, возвращавшая первый узел списка. Я решил попробовать следующее:
class DoublyLinkedList
def head
'A'
end
end
Я создал функцию head, захардкодил заглавную «А» в качестве строки и запустил тест. Он был пройден.
Супер-просто? Очевидно? Да! Но этот код делает две очень важные вещи:
- позволяет запустить тесты и проверить, как все работает (чтобы выявить любые глупые или синтаксические ошибки),
- обеспечивает мне быструю победу, а это существенно поднимает мой уровень уверенности в себе.
Я бессчетное число раз видел, как человек допускает какой-то мелкий промах в самом начале работы, расстраивается, нервничает и в результате тратит большую часть времени на попытки найти и исправить допущенную ошибку.
Не стоит недооценивать значение быстрых побед для чувства уверенности в себе. Накапливая маленькие победы, вы будете продвигаться быстрее.
Окей, мы захардкодили строку «А». Как мы можем продвинуться и улучшить решение? Ну, как насчет того чтобы превратить букву «А» в хэш (или map)?
class DoublyLinkedList
def head
{ value: 'A' }
end
end
Уже немного лучше. Теперь вместо строки в один символ наш «узел» представлен хэшем. Как еще можно улучшить? Например, мы можем представить наш указатель head.
class DoublyLinkedList
def initialize
@head = { value: 'A' }
end
def head
@head
end
end
Что мы изменили здесь? Мы добавили наш инициализатор и создали новую переменную @head, которую использовали в нашей функции head. Теперь это начинает походить на код.
Этот подход может казаться глупым, но я вас уверяю, что он работает. Все изменения вносятся за считанные секунды, итеративно. А когда они накапливаются, у вас на руках довольно быстро оказывается рабочая реализация.
Если думаете, что этот подход покажется интервьюеру странным, обратите внимание на следующий совет (он очень важен).
Совет 3. Говорите. Вслух, громко и четко.
Вы должны говорить все время, пока решаете данную вам задачу. Говорить вслух.
Проговаривайте все, о чем думаете. Все.
(Хм… ну, все, что касается программирования).
Тут ведь вот в чем дело. Прийти к правильному решению важно, но столь же важно (если не важнее) показать свой мыслительный процесс. Интервьюер хочет знать, как вы мыслите, как вы решаете проблемы. Чтобы это продемонстрировать, вы можете делиться своими мыслями, проговаривая их вслух.
Каждый интервьюер когда-то искал работу и сам проходил собеседования, так что все они знают, что в ходе собеседования даже самые простые вещи могут вызывать затруднения. Хорошие интервьюеры обращают внимание не на то, абсолютно ли верно ваше решение. Их больше интересует, насколько хорошо у вас развито критическое мышление. А единственный способ удовлетворить их любопытство — озвучить свой мыслительный процесс.
Если вы прежде ничего подобного не делали, имеет смысл попрактиковаться, потому что это важно для успешного прохождения собеседований.
Приведу конкретный пример того, что именно я говорю, решая задачи на собеседованиях:
- «Окей, давайте просто захардкодим это значение и убедимся, что наши настройки работают».
- «Давайте сначала сделаем топорную, но рабочую версию, а затем улучшим».
- «Пока что я сделаю это вот так, а потом, если будет время, вернусь к этому».
- «Итак, нам нужна функция, принимающая массив, делающая Х и возвращающая ХХ».
В некоторых случаях подобные собеседования могут начать напоминать сессии парного программирования.
Итак, мы теперь знаем, что нужно все проговаривать вслух. Но порой мы допускаем ошибки, иногда нам случается застрять. На этот случай у меня тоже есть важный совет:
Совет 4. Не прерывайте поток логики
Я признаю, что это может быть сложно.
Когда вы на собеседовании понимаете, что в вашем коде есть ошибка или еще какая-то проблема, ваш мозг отчаянно хочет разобраться, в чем дело. Но не будьте настолько отчаянны, чтобы начать крушить свой код или нарушать свой мыслительный процесс.
Видите ли, интервьюеру интересно не только, как вы решаете задачи, но и как вы занимаетесь дебаггингом. Это так же важно, как и пояснение вашего мыслительного процесса. Изо всех сил старайтесь не прерывать поток логики и не отказываться от ваших идей.
Если все идет хорошо
Итак, решение задачи идет успешно, вы разобрались с основной проблемой и прочими вещами полегче. Что теперь? Как нам не просто пройти собеседование, а показать себя во всей красе?
Это очень важная часть собеседования, потому что именно на этом этапе вы можете получить рычаги для дальнейших переговоров относительно должности и зарплаты.
Совет 5. Продемонстрируйте свои знания
Вы работаете над задачей, проговариваете все вслух и все идет замечательно. Теперь вам следует поискать возможность показать свои знания и опыт.
Занимаетесь проверкой логики в модели? Расскажите, что вы также добавили бы ограничения базы данных для обеспечения их целостности. Какие индексы вы бы добавили? Как бы вы развернули миграции, чтобы избежать простоев?
Имея готовое решение, расскажите, что бы вы в нем изменили, если бы у вас было на это время. Вы создали бы какой-то модуль? Как насчет помещения части логики в фон? Озвучьте плюсы и минусы.
Большинство задач на собеседованиях нацелены на определение того, есть ли у кандидата необходимый для вакансии минимум знаний. Обычно задачи не составляются так, чтобы проверить, на что вообще способен кандидат (т. е., для измерения «потолка» его умений). От вас не будет требоваться предоставление дополнительной информации, поэтому вы должны самостоятельно ее добавить.
Поэтому, работая над задачей, упоминайте обо всем, что бы вы вставили в реальное приложение или кодовую базу, и обсуждайте эти вещи.
Дополнительные советы
Я описал, как нужно подходить к процессу собеседований и к решению задач. Дополнительные советы нацелены на то, чтобы предоставить вам небольшое преимущество.
1. Ознакомьтесь с распространенными задачами
Есть несколько распространенных задач, часто появляющихся на собеседованиях (особенно если применяется белая доска). Это все равно что знать, какие вопросы вам попадутся на экзамене: ответы лучше найти заранее.
Две главных задачи в этом плане — FizzBuzz и последовательность Фибоначчи.
А теперь запомните: не нужно заучивать решения, чтобы изложить их на собеседовании. Ни к чему хорошему это не приводит (мне случалось наблюдать подобное). Вам нужно просто ознакомиться с решением и уметь его воспроизвести с нуля.
То есть, для подготовки следует пользоваться книгами, но решения нужно понимать, уметь объяснять и воспроизводить с нуля. Просто заученный ответ ничего вам не даст.
2. Обычно можно подсматривать в документацию
На всех собеседованиях, в которых мне довелось участвовать, никто не возражал, если кандидат поищет стандартную библиотеку или документацию пакета. Но интервьюеры определенно будут возражать, если вы надумаете искать готовый ответ (так что на StackOverflow я бы не заходил). Если у вас возникают сомнения относительно того, куда можно подглядывать, а куда — нет, см. Совет 1 (задавайте уточняющие вопросы).
3. Следите за визуальными подсказками
Это, пожалуй, мой любимый трюк. Не то чтобы он был самый полезный, но он определенно интересный.
Однажды я проходил собеседование дистанционно. Мы пользовались программой для шеринга экрана, я мог видеть лицо интервьюера в верхнем правом углу.
Когда я писал код, я заметил, что интервьюер кивает. Ага! Маленькая визуальная подсказка, подтверждающая, что я двигаюсь в правильном направлении.
Еще раз: это не супер-совет, но определенно может пригодиться. 🙂
4. Если проходите собеседование удаленно, настройте все хорошенько
Что касается дистанционных собеседований, постарайтесь настроить все как можно лучше. Включенная камера (по возможности настроенная так, чтобы вы смотрели прямо в нее), хороший интернет, включенный компьютер, тихая комната, стакан воды неподалеку и т. д.
Подобные вещи не должны повлиять на результаты вашего собеседования, но не следует раздражать интервьюера и самому лишний раз напрягаться из-за плохой связи или шумов.
5. Будьте личностью!
Проходя собеседование, будьте человеком, с которым вам самому хотелось бы работать. Покажите себя с лучшей стороны.
Собеседования пугают, а разработчики в целом тихие и неразговорчивые люди, но вам нужно показать окружающим, что вы можете стать для них интересным и приятным коллегой.
Я не хочу сказать, что вы должны прикинуться кем-то, кем вы не являетесь. Но не нужно плотно сдвигать створки своей раковины, подобно испуганному моллюску.
6. При желании проделайте в ходе подготовки все, что советуют в других источниках
Если это ваше первое техническое собеседование или вы чувствуете себя недостаточно подготовленным, поупражняйтесь, пока не почувствуете себя комфортно.
Почитайте книги (например, “Cracking the Coding Interview” (на русском — “Карьера программиста“) или попрактикуйтесь в алгоритмах и решении головоломок на HackerRank.
Если будете проходить собеседование на позицию full-stack разработчика, будьте готовы с нуля создавать проект с набором тестов.
Изучите информацию о компании, подготовьте вопросы интервьюерам и т. д.
Напоследок: это всего лишь собеседование
Все будет, как будет. Вы не выбираете ни процедуру собеседования, ни интервьюера. Возможно, это будет не ваш день, а может, интервьюер встанет не с той ноги.
Если впоследствии почувствуете себя разбитым, сделайте глубокий вдох и отпустите эту ситуацию! Плохо прошедшее собеседование это не конец света. Ваша карьера из-за этого не рухнет, ваша репутация не пострадает, ваша жизнь тоже будет в порядке.
Это просто собеседование. Учтите полученные уроки и в следующий раз сумеете показать лучший результат.
Нервничать это нормально
Большинство людей (включая меня) нервничают перед собеседованиями или выступлениями. Раньше я думал, что нервозность это плохо. Я говорил себе не переживать — и переживал еще больше.
Но теперь я переосмыслил суть нервозности. Это всего лишь подготовка моего тела к бою. Базовая эмоция, ответ на страх. Чистая биология.
Но, как уже было сказано, это же всего лишь собеседование. На меня не выскочит тигр, так что подобная подготовка к битве не нужна.
И я начал воспринимать нервозность как нечто положительное. Ее наличие означает, что мои чувства обостряются, а это помогает показать наилучшую производительность.
Так что примите свои нервы просто как факт. Это лишь подготовка к тому, чтобы показать себя наилучшим образом.
Прохождение собеседований это навык
Наконец, следует сказать о том, что прохождение собеседований это навык. Его можно приобрести и отточить путем практики.
Поэтому не стоит корить себя, если результаты собеседования не те, на которые вы рассчитывали. Продолжайте учиться и практиковаться, и все у вас получится!
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]
