Основные ошибки на собеседовании в FAANG

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

1) Отсутствие должной подготовки. Некоторые кандидаты вообще не готовятся к подобным собеседованиям. Это заметно на phone screen, а также на system design если они прошли phone screen. Это несмотря на то, что мы описываем весь процесс до самого собеседования и даже присылаем материалы для подготовки. Мы хотим, чтобы кандидат показал свой лучший перфоманс на собеседовании, свой максимум. Пройти такое собеседование без подготовки практически не возможно. Только если вы уже готовились к нему когда-то ранее, или у вас бэкграунд топового олимпиадника + большой практический опыт в создании high load систем. Или вы гений с IQ 150-160. Поэтому если вы действительно хотите собеседование пройти - нужно уделить время подготовке.

2) Кандидаты не задают уточняющие вопросы, не уточняют требования. Все задачи обычно формулируются так, чтобы они не были однозначными, особенно system design. Ожидается что вы будете задавать уточняющие вопросы, уточнять требования или выдвигать свои предположения и спрашивать, могу ли я это предположить для решения задачи. Некоторые кандидаты ничего не уточнят и сразу начинают решать. Очень часто это приводит к тому, что они решают другую задачу, не которую хотел интервьюер. Это приводит к потере времени и негативному фидбеку по communication оси.

3) Кандидаты не могут без компьютера продебажить свой код и найти в нем ошибки. После того как код написан, мы просим протестировать код путем подбора примеров (test cases) и в ручном режиме пройтись по коду и проверить правильно ли он сработает или нет. Некоторые кандидаты не способны проверить работоспособность своего кода без запуска его на компьютере. Даже если им указываешь на конкретный пример, на котором это работать не будет, они все равно не могут понять почему. Из-за этого они получают слабый рейтинг по оси verification

4) Не реагируют на подсказки и наводящие вопросы. Иногда кандидаты вообще не реагируют на интервьюера и продолжают погружаться в свои рассуждения и мысли. Интервьюер делает подсказки не для того чтобы вас отвлечь и мешать вам думать и решать задачу. Он это делает, когда видит, что вы застряли или вы думаете куда-то не туда. Кандидаты, которые могут быстро среагировать на наводящий вопрос или подсказку могут быстро разблокировать себя и решить задачу.

5) Нерационально расходуют время. На кодинг собеседовании иногда кандидаты начинают тратить время на совершенно второстепенные проверки в коде, писать зачем-то комментарии к коду, рассуждать подолгу над именами переменных. Расходуют на это почти все время и не могут приступить к решению собственно самой задачи. Обычно, никакие проверки на input делать не надо. Это можно просто коротко спросить интервьюера, могу ли предпологать, что input валиден? ответ будет да в 99% случаев и просто можно его не проверять. Комментарии писать тоже не нужно, просто озвучивайте свои мысли по ходу написания. Интервьюер поймет что и зачем вы написали. Впечатлять интервьюера ненужными комментариями в коде не надо.

6) На system design кандидат не драйвит обсуждение. На system design кандидат должен быть тем, кто драйвит дискуссию. Это не собеседование, где интервьюер у вас должен спрашивать вопрос-ответ. Тут вы должны проявить себя в качестве лидера и вести дискуссию. Как на реальной работе, когда вы дизайните систему или API, вы должны описать и продать свой дизайн, а не у вас его выуживать в час по чайной ложке. Если вы будете работать в режиме вопрос ответ, то в лучшем случае скажут что вы не соответствуете уровню, на который вы собеседуетесь.