Перевод статьи «Demystifying the Frontend Technical Interview».
Скажу нечто очевидное: технические собеседования сложны. Вы решаете задачу, с которой, возможно, сталкивались раньше, а возможно и нет. При этом вы работаете в незнакомом окружении, за вами наблюдает посторонний человек, к тому же время на решение ограничено. Это очень неестественная ситуация. Большинство из нас привыкли работать над задачами в одиночестве (по большей части), в комфортной обстановке, без ограничений по времени (дедлайны не считаются). Как же научиться достигать успеха в ситуациях, которые будто нарочно спроектированы так, чтобы вы провалились?
Примечание. В разных компаниях разные подходы к проведению собеседований, и я не утверждаю, что мои советы универсальны. К интервью надо готовиться. Изучите информацию на Glassdoor, а еще лучше — пообщайтесь с людьми, работающими в компании, куда вы идете на собеседование.
Я решила написать эту статью, потому что видела слишком много талантливых разработчиков, впадающих в ступор из-за нервов (синдрома самозванца, стресса). Я хочу показать вам, как собеседование выглядит с точки зрения интервьюера. Надеюсь, это поможет вам обрести уверенность в себе и проявить свои таланты во всей красе.
Вам не обязательно доводить решение до конца
Я как интервьюер хочу увидеть, как вы работаете. То, насколько быстро вы это делаете, может волновать меня гораздо меньше. Если мы вас наймем, вы будете работать совсем в других условиях. Зачем же заставлять кандидата писать код так, будто от этого зависит его жизнь?
Вдохните поглубже и работайте не спеша. Если хотите проговаривать мыслительный процесс и использовать меня вместо резиновой уточки, — отлично. Но если вы хотите сосредоточиться в тишине — нет проблем. Я хочу увидеть, как вы подходите к решению задачи, пишете ли вы псевдокод, какие методы пытаетесь применить, а если что-то работает не так, как ожидалось, — как выкручиваетесь из ситуации.
Я видела, как очень хорошие разработчики впадают в ступор, глядя на часы. Конечно, сказать «расслабьтесь» куда проще, чем в самом деле расслабиться на собеседовании. Вы просто знайте, что в глазах интервьюера скорость не обязательно равна пониманию, так что не спешите.
Вы можете спросить, можно ли поискать информацию
Вероятно, вы слышали поговорку о том, что хорошие разработчики хорошо умеют гуглить. Это правда! Чем больше у вас опыта, тем лучше вы умеете задавать вопросы. Кроме того, ожидается, что мы знаем очень много всего! Разные языки, разный синтаксис, разные инструменты. Могу ли я требовать от человека помнить все, что он когда-либо изучал, если сама в своей работе ежедневно пользуюсь поисковиками?
Если вам нужно освежить в памяти синтаксис Fetch API, не стесняйтесь спросить, можно ли быстренько его загуглить. Поверьте, я вижу разницу между человеком, понимающим, что он делает, и человеком, пытающимся просто найти готовый ответ и скопировать его.
Будьте осторожны с фреймворками и библиотеками
Если только вы не привыкли использовать фреймворк или библиотеку в среде-песочнице, отдайте предпочтение Vanilla JS и простому CSS.
Возможно, вы привыкли пользоваться каким-то фреймворком в уже настроенной среде (причем настроена она могла быть кем-то другим или при помощи мета-фреймворка типа Nuxt). Но если вы попытаетесь настроить фреймворк в песочнице, да еще и в условиях ограниченного времени, это приведет лишь к стрессу и катастрофе.
Многое зависит от того, насколько «сеньористая» роль, на которую вы претендуете. Но в целом, если вы не слишком опытны во фреймворках, зато имеете сильные навыки написания кода на ванильном JS и простом CSS, лучше остановиться на последних.
Будьте открыты для советов
Если я увижу, что вы застряли, а правильных вопросов мне не задаете, я постараюсь сама дать вам какие-то подсказки, чтобы подтолкнуть в правильном направлении. Я хочу, чтобы у вас получилось.
Но не каждый человек готов воспользоваться советом, особенно если предлагается не его любимый способ что-то делать. Конечно, вы вольны решать задачу так, как сочтете нужным. Но если вы даже не рассматриваете возможность решить ее иначе (не объясняя, почему), я задумаюсь, сможете ли вы работать в команде с другими разработчиками.
И маленький секрет на закуску
Я тоже нервничаю, когда провожу техническое собеседование. Кажусь ли я дружелюбной? Произвожу ли я впечатление человека, который знает, что делает? Если мне зададут вопрос, смогу ли я на него ответить? Помните: вы тоже интервьюируете своего интервьюера (как бы странно это ни звучало).
Хотите ли вы работать с этим человеком (или на этого человека)? Как насчет команды, в которой вам предстоит работать? Кажется ли она вам поддерживающей и инклюзивной? Как насчет задачи, которую вам дали решать? Она соответствует позиции и необходимому для нее уровню навыков?
Обдумывание этих вопросов перед собеседованием помогает начать воспринимать интервьюера как нормального, живого человека. Да и сам процесс собеседования делает менее пугающим.
Помните: хорошая компания (интервьюер, человек) тоже болеет за вас.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]