11 ошибок на технических собеседованиях: не допускайте их

Перевод статьи «11 Mistakes To Avoid On A Technical Interview».

Ошибки на технических собеседованиях

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

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

Я провела больше 120 собеседований. Вот несколько самых распространенных ошибок, допускаемых кандидатами.

1. Высокомерие

Я задаю вопрос относительно решения кандидата, а он отвечает: «О, я вижу, вы не понимаете, что я здесь сделал. (Поясняет). Теперь стало понятнее?»

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

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

2. Использование модных терминов без их понимания

Использование модных слов

Префиксное дерево. База данных NoSQL. Балансировщик нагрузки. Кластер. Если вы собираетесь использовать эти слова, вам придется пояснять, почему. Когда кто-то не знает, что такое хеш, это очень легко определить.

«Я помещаю сюда балансировщик нагрузки», – сказал кандидат и нарисовал прямоугольник рядом со своим кластером базы данных. «Он будет запускаться раз в час, запрашивать все машины базы данных, обрабатывать данные и регистрировать результаты».

Хм. Это не то, что делает балансировщик нагрузки. Я подумала, что это была оговорка, поэтому задала еще несколько вопросов. Но нет, человек продолжал называть это балансировщиком нагрузки. Понятно.

«Я использую префиксное дерево», – сказал другой кандидат. Когда я попросила рассказать подробнее, он не смог показать ни малейшего примера, как это выглядит.

В то же время, совершенно нормально не знать детально обо всем. Просто нужно быть честным. Не стоит притворяться, будто знаешь что-то, чего на самом деле не знаешь.

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

Что любопытно, никто еще на моих собеседованиях не пытался использовать блокчейн.

3. Отсутствие указания причин

«Здесь я собираюсь использовать базу данных NoSQL».

«В моем кластере мне нужно 50 серверов».

«Я запускаю это раз в день и извлекаю 92 записи».

Отлично. Расскажите теперь, почему и зачем. Я уверена, что вы это делаете не без причины, что вы мысленно взвесили все «за» и «против», и я хотела бы все это услышать. Почему не SQL? Какую конкретно базу данных NoSQL? Под этим термином скрывается столько баз данных, что стоит как-то конкретизировать свой ответ. Графовая база данных и документо-ориентированная база данных имеют совершенно разные назначения.

Почему именно 50 серверов, а не 70? Почему ежедневно, а не ежечасно? И откуда вы взяли это число 92?

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

4. Отсутствие уточняющих вопросов

Задавайте вопросы

Вопрос, который вам задают на собеседовании, скорее всего не полон на 100%. Это делается намеренно, чтобы изобразить реальную ситуацию, когда вам, скорее всего, не дадут полного описания задачи. Ожидается, что вы сами спросите, так что задавайте вопросы!

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

Также порой вы можете захотеть спросить : «В правильном ли направлении я иду? Вы хотите, чтобы я сфокусировался на этом или на том?» Интервьюер будет рад такому вопросу, ведь ему не придется прерывать вас, чтобы обсудить свои пожелания.

Почему это важно: крайне редко требования бывают на 100% понятны. Разработчик должен уметь прояснять их до того, как приступать к реализации.

5. Забывание требований

В самом начале я сказала кандидату: «Нам нужно, чтобы это было как можно ближе к реальному времени». Я повторяла это в ходе собеседования. В конечном итоге кандидат делает обработку данных партиями каждый час.

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

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

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

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

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

6. Пропуск corner cases

«Я запускаю его раз в 5 секунд и выбираю записи за последние 5 секунд», – говорит кандидат. Всего минуту назад мы установили, что поле timestamp идет вместе с записью. То есть, новая запись 7-секундной давности может быть вставлена именно сейчас. Это означает, что мы никогда-никогда не обработаем эту запись.

Кандидат решает вопрос насчет шахмат, забывает о наличии углов и обращается к массиву «доска» на [-1,-1].

Есть три рабочих процесса, все они выбирают последние необработанные записи. По окончании они помечают записи как «done». Этот кандидат не подумал пометить запись как «in progress». Это значит, что одна запись может обрабатываться до трех раз.

Попытайтесь мыслить логически: работает ли ваше решение во всех случаях? Вы проверяете input пользователя? Есть ли у вас бесконечные циклы? Что, если вы передадите 0, -1, INT_MAX? Как ваша система восстанавливается после утраты сетевого соединения? Что будет при пике запросов?

Старайтесь обдумывать это или даже писать какие-то тесты прямо на месте. Проговаривайте свой мыслительный процесс. Интервьюер скорее всего поможет вам.

Почему это важно: требования пользователей крайне редко включают какие-то corner cases. Могут быть пропущены даже некоторые base cases. А для разработчика важно уметь определять их и делать так, чтобы код работал всегда.

7. Чрезмерное углубление в детали

Углубление в детали

Однажды у меня был кандидат, который начал с выбора протокола, который будут использовать различные компоненты системы для взаимодействия друг с другом. TCP или UDP? Сами компоненты еще не были определены.

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

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

8. Отсутствие достаточного количества деталей

«Так что мы храним данные здесь и просто выбираем нужные записи».

Окей, в какой базе данных мы их храним? По какой схеме, в каком формате? Какие записи рассматриваются как «нужные»? Есть сотни миллионов строк, как нам ускорить процесс выборки?

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

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

Также, если вы что-то недостаточно продумали, вы можете упустить какие-то corner или даже base cases. Возьмем пример с базой данных. Если у вас миллиарды строк, это, скорее всего, не подойдет для одной машины, так что вам придется придумать что-то еще для решения этой проблемы.

9. Неявные предположения

Проявляется обычно при следующих диалогах.

Кандидат говорит: «Данных слишком много, мне понадобится кластер с шардингом, 30 узлов и 3 реплики, балансировщик нагрузки и…»

Я спрашиваю: «Сколько именно данных у нас есть?»

Кандидат делает паузу и спрашивает: «А сколько у нас пользователей?»

Видите? Еще неизвестно, сколько будет поступать данных, от какого числа пользователей и как часто, но у нас уже есть кластер на 90 машин. Это дорого!

Задавайте вопросы. Сколько пользователей? Сколько данных? Какое время ответа для нас приемлемо?

После некоторых вычислений часто оказывается, что нам нужно хранить всего 200MB данных. Бум! Мы мгновенно сэкономили кучу денег на этом кластере.

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

10. Уклонение от вопросов

– Что произойдет в случае Х?»

– Ну, вы знаете, в случае Y я сделаю Z, а если А или В, то С упадет…

– Хорошо, но как насчет Х?

– Давайте посмотрим… Если Х… О, это напомнило мне, что когда у нас есть D…

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

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

11. Невежливость с интервьюером

Важно быть вежливым

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

Ходят слухи, что некоторые кандидаты игнорируют женщин-интервьюеров в принципе. Иногда они считают, что все женщины на собеседовании это эйчары. Порой они бывают грубы именно с эйчарами, хоть с мужчинами, хоть с женщинами. Бывают случаи, когда люди в грубой форме отказываются отвечать на вопрос. Я не могу представить, почему они так делают, но это факт.

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


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

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх