Но сегодня я хотел бы поговорить о дурацких вопросах на собеседованиях, которые на первый взгляд сходят за нормальные. Они вроде бы и по теме, но ничего не дают, кроме нервотрепки для претендента на вакансию. Некоторые из них вообще ничего не спасет, а какие-то сами по себе неплохи, но неверно применяются. Вот некоторые из особо злостных.
- Что будет, если создать круговую цепочку прототипов? И прочие сведения случайного характера.
- Как мигрировать с webpack 3 на webpack 5? И прочие частности.
- В чем разница между числом и массивом? И прочие вопросы, затуманенные расплывчатыми формулировками.
- Как быстрее всего перевести строку в число? И прочие вопросы, не дающие достаточно информации о поведении.
- Как сделать этот фрагмент кода лучше? И прочие вопросы, предлагаемые вне контекста.
Я поделюсь рекомендациями как для проводящих собеседования, чтобы они могли разумнее распорядиться своим временем, так и для кандидатов, которые хотят понять, как лучше отвечать. Имейте в виду: я буду использовать примеры из JavaScript, впрочем, найти аналоги в других языках несложно. Поехали!
Сведения случайного характера
В первую категорию входят вопросы, которые очень популярны на собеседованиях, но на практике встают перед разработчиками редко. Что случится, если мы запустим вот такой код?
const x = {};
const y = {};
x.__proto__ = y;
y.__proto__ = x;
console.log(x.field);Мы модифицируем цепочку прототипов во время выполнения, чтобы она закольцевалась. Вы, наверное, уже догадались, что правильный ответ – «ничего хорошего». В продакшн такой код писать никто не станет. Какому ненормальному взбредет в голову использовать свойство __proto__, которое стандартизировали по особому случаю и с тех пор стараются обходить стороной? Но, разумеется, правильный ответ звучит так: y.__proto__ = x дает TypeError: Cyclic __proto__ value. Спасибо, очень полезно.
Единственное, что выявляют такие вопросы – много ли собеседований кандидат уже успел посетить, и то только если вы выберете что-то из популярного. Если попытаетесь сами придумать «что-нибудь похитрее, чтоб в интернете на находилось», то это все равно как монетку бросить – запомнил кандидат эту часть спецификации или нет.
Существенную часть таких сведений случайного характера составляют вопросы по винтажному JS. Ну да, те из нас, кто начал писать код до 2015 года, знают, как работает поднятие переменных и как объявить (и даже расширить) класс с .prototype. По сути, здесь вы проверяете, когда разработчик взялся за изучение JS (и приходилось ли ему работать с legacy-кодом), а эту информацию можно найти и в резюме. Если в вашем проекте есть legacy-код, то, возможно, это еще имеет какой-то смысл.
Для тех, кто проводит собеседования: избегайте вопросов, которые напрямую не связаны с тем, чем разработчику придется заниматься в реальности. Больше всего такие вопросы любят люди, которые не разбираются в программировании и пытаются проводить собеседования по списку вопросов, который нашли в Сети (руководители, основатели, менеджеры проектов). Плохие новости: ничего из этого не выйдет. Либо наймите или одолжите нормального разработчика специально для собеседований, либо ограничьтесь мягкими навыками и рассказами о прошлом опыте.
Единственный способ научиться отвечать на такие вопросы – это, как ни печально, активно ходить по собеседованиям. Ну, или в качестве дешевого аналога – загуглить «топ вопросов по JS на собеседованиях, гарантированно полный список». Охватить все граничные случаи каждого языка и библиотеки в реальности невозможно.
Частности
Какие сложности вызывает миграция на webpack 6? Как проверить, поддерживает ли браузер SSE? Какой aria-role должен быть у модального окна? Понятия не имею. Я обычно гуглю такие вещи, и у меня неплохо получается.
Вот что случается, если принять мой совет использовать сведения из реального опыта разработки слишком близко к сердцу и начать вбрасывать произвольные проблемы, которые вам удалось решить в последнее время, по ходу собеседования. Ясное дело, вы изучили нужные материалы, нашли ответ и довольны собой. Но я-то – не вы, у нас разный опыт, благодаря чему мы можем друг друга дополнять. Так ведь даже лучше, разве нет? Не определяйте меня в придурки только на том основании, что я никогда не имел дела с какой-то областью веб-разработки.
Попросите лучше кандидата рассказать о какой-нибудь недавней трудности, с которой он справился – это будет и занятнее, и полезнее для вас обоих.
Если вам задают вопрос такого рода, а вы сами никогда ни с чем подобным не сталкивались, то дело плохо. Попытайтесь припомнить всю фоновую информацию по этой теме, которой располагаете – возможно, вам удастся вывести ответ просто исходя из здравого смысла.
Туманные вопросы
«В чем разница между числом и объектом?» — это самый удивительный вопрос в мире, и каждый раз, когда я снова его слышу, моё удивление возрастает вдвое. Ну извините, а в чем разница между вашей головой и запеченной картофелиной с пылу с жару? Я что, на стендапера собеседуюсь?
Проблема здесь в том, что от вас ждут совершенно определенного ответа (как я выяснил, ответ этот: «Число неизменяемо»), но если спросить напрямую, то получается как-то слишком просто. Поэтому добавляется подвыверт, чтобы вопрос стал открытым, суть немного затеняется, а в итоге становится вообще невозможно понять, что у вас узнать-то пытаются.
И, что самое худшее в этой ситуации, даже подсказку дать не получится, потому что подсказка и есть ответ, так что вы обречены бродить кругами, всё сильнее и сильнее запутывая друг друга. «Что можно сделать с числами, а с объектами нельзя?» Складывать? Приводить к false? «Ну, подумайте. Есть ли у чисел свойства?» В каком-то смысле, да. Столько времени впустую!
Опять же, ключевым здесь является опыт прохождения собеседований. Как только вы подметите, какие вопросы и темы, связанные с JS, всплывают чаще всего, то начнете всё успешнее их узнавать в любом гриме.
Для тех, кто проводит собеседования: старайтесь отдавать предпочтения прямым вопросам («Какие типы в JS неизменяемы?») или, по крайней мере, позаботьтесь о том, чтобы формулировка направляла кандидата куда нужно, а не заставляла метаться туда-сюда («В чем разница между примитивными типами и объектами?»).
Неясное поведение
Что залогирует console.log(Object.keys({ x: 0, y: 0 }).join()) — x,y или y,x? x[key] быстрее, чем x.find(e => e.key === key)? Я знаю, что при нормальных условиях ответы — x,y (в порядке добавления) и «да», но спецификации нет, так что не следует слишком на это полагаться.
В этой категории особенно популярны вопросы, связанные с производительностью. Время выполнения в JS меняется быстро, и даже если несколько лет назад вы видели, что такой-то код производительнее такого-то, сейчас дела могут обстоять уже иначе. Тот факт, что встроенные структуры данных в JS не уточняют сложность операций, тоже не помогает. Разумно предположить, что доступ к объекту obj[key] займет O(1), но на деле это определяется многими факторами — размером объекта, частотой создания / удаления, тем, являются ли ключи строковыми литералами (см. бенчмарк). И даже когда какая-то разница и существует, она зачастую пренебрежимо мала и не оказывает никакого реального эффекта на фронтенд-разработку.
В целом, такие вопросы хороши тем, что позволяют оценить и практические знания о производительности в стандартных условиях, и понимание разницы во времени выполнения, в том числе применительно к повседневной работе. Всё, что требуется от проводяшего собеседование, чтобы извлечь из них пользу – во-первых, самому не забывать о том, что многое зависит от имплементации, а во-вторых, оставаться открытым для неожиданных ответов. Такие вопросы однозначно не годятся для неинтерактивных форматов собеседования, например для онлайн-теста, где можно выбрать только один вариант (Выберите самый быстрый метод: a) a.pop() b) a.shift() c) a.length -= 1) – для них не существует единственно правильного ответа.
Вопросы без контекста
Открытые вопросы – один из лучших вариантов для собеседования: у них хороший уровень сложности, они показывают и способность кандидата искать решения, и практический опыт. Однако подобные вопросы не терпят ленивых собеседующих – чтобы от них был толк, приложить усилия нужно обеим сторонам. Два основных способа пустить всё под откос – это отказаться идти кандидату навстречу и зациклиться на одном конкретном решении.
Скажем, что не так с этой функцией?
function map(arr, fn) {
for (var i = 0; i < arr.length; i++) {
arr[i] = fn(arr[i]);
}
return arr;
}Не знаю, как по мне, с ней всё в порядке. А может, и нет. Всё зависит от того, чего именно вы от нее хотите. Код сам по себе редко бывает «правильным» или «неправильным». Ну да, допускать мутации arr по нынешним временам не идиоматически, но, возможно, в рамках оптимизации конкретного фрагмента это и работает. Да, использование var не приветствуется, но, может быть, это библиотека, которая должна работать в IE6. Да, можно было бы заменить for (;;) на .map или на for..of, но тогда мы теряем поддержку всех массивоподобных объектов. Как видите, всё зависит от контекста. Я бы мог бесконечно создавать вариации этого куска кода, но, если он не вызывает никаких проблем, то лучше этого не делать.
Часто такие вопросы формулируются в духе «проведите рефакторинг кода, чтобы стало ЛУЧШЕ» — у любого джуниора глаза загорятся. Хорошо, что есть старый ворчун Владимир, который напомнит вам, что «рефакторинг» без ясной цели – это самое бессмысленное занятие на свете.
Чтобы продемонстрировать, как решение завязано на проблеме, возьмем такой пример: вы даете мне галерею со слайдером, которая реализована через жуткую мешанину jQuery, и просите ее «усовершенствовать». Одна беда: вам-то представляется, что самое лучшее, что можно сделать для этой галереи за час – написать модульные тесты и перевести всё на React. А я думаю, что должен заменить jQuery на ванильный DOM и доработать UX, чтобы лучше реализовать прокрутку. Нельзя сказать, что кто-то из нас прав или не прав. В реальной жизни контекст задают цели проекта и направление разработки: сколько у нас зависимостей jQuery по кодовой базе, планируем ли мы мигрировать на React, доступно ли ручное тестирование.
Когда задаете открытый вопрос, либо махните рукой на предполагаемый ответ и наблюдайте за процессом поиска решения, либо уточните недостающие требования, которые подведут к желаемому решению.
Итак, вот пять типов вопросов для собеседований, которые я терпеть не могу – они перечислены в порядке от самых безнадежных до неплохих, но таящих в себе опасности:
- Случайные сведения: всё, что часто всплывает на собеседованиях, и редко – в жизни. Пример: «Что будет, если построить круговую цепочку прототипов?». Такие вопросы проверяют натасканность, а не реальные знания. Их следует избегать.
- Частности: решения для уникальных проблем из практики. Пример: «Как мигрировать с webpack 3 на webpack 5?» Теоретически могут сгодиться, если относятся к базовому набору сведений, которыми нужно располагать разработчику, или к области, крайне важной для вашего продукта. Лучше спросить, какую сложную проблему кандидату удалось решить в последнее время.
- Туманные вопросы: вопросы, которые просты по своей сути, но усложнены расплывчатыми формулировками, например «В чем разница между числом и объектом?» вместо «Неизменяемы ли числа в JS?». Их следует избегать.
- Вопросы по имплементации: ответ зависит от частных особенностей в среде выполнения JS. Пример: «Как быстрее всего сделать циклический просмотр списка?». Избегайте категоричных формулировок и не раздувайте проблем на ровном месте, если ответ будет не таким, как вы ожидали.
- Недостаточно контекста: ответ требует дополнительных сведений. Пример: «Как улучшить этот код?» Если вы готовы искать ответ совместными силами, очерчивать необходимые рамки и по достоинству оценивать способность кандидата подмечать возможности – вопрос отличный. Если вы ждете конкретного ответа при том, что существует масса объективно хороших альтернатив – вопрос ужасный.
К сожалению, для кандидатов у меня не так уж много рабочих советов. Понятно, что всё приходит с опытом, и проглядеть список популярных вопросов – мысль неплохая, даже если вы весь из себя сениор-лид, но в остальном трудно найти выход из положения, когда и вопрос плохой, и собеседник неважный. Вряд ли вам удастся с ходу убедить человека, проводящего собеседование, поменять вопрос или подход к делу (если удастся, лучше претендуйте на высокую должность в отделе продаж). Как ни печально, но лучше будьте готовы признать, что чего-то не знаете, и попытайтесь извлечь максимум из релевантных знаний по теме.
Удачи на собеседованиях и еще увидимся!
Автор: Productivity Inside
