За долгие годы коммерческого опыта я прошел огромное количество технических собеседований, посвященных Java и друзьям. Менялись интервьюеры и язык повествования, глубина вопросов и количество собеседований, но что‑то оставалось неизменным —
«разогревочный» вопрос «расскажи, как работает HashMap?»
Давайте разберемся, почему это не только бесполезный, но и вредный вопрос, который противопоказано задавать в большинстве собеседований на позицию Java-разработчика.
Перед тем как углубимся в проблематику, определимся:
Зачем вообще нужны технические собеседования?
Предположим, что номинальной целью любого технического собеседования является оценка технических знаний, навыков и способностей кандидата успешно выполнять задачи, связанных с предстоящей работой или проектами в компании (практически, это не всегда так, и огромное количество собеседований преследуют какие-то другие, непонятные цели, но с этим разберемся в другой раз).
Исходя из общей цели можем также разумно предположить, что целью каждого отдельного вопроса является проверка определенных, конкретных аспектов кандидата, которые имеют решающее значение для успешного выполнения задач на позиции.
Получается, каждый ответ должен приближать нас к пониманию, справится ли кандидат с поставленной задачей, или нет.
Это может быть вопрос о насущном фреймворке или библиотеке, предыдущем техническом опыте кандидата, дипломной работе в университете и темам, в которых он разбирается и которые ему интересны, но главное – вопрос должен быть полезным, т.е. в зависимости от ответа, интервьюер сможет сделать соответствующие выводы о компетенции и опыте.
Что же насчет работы HashMap?
Разберем на конкретных примерах ответов:
Кандидат А: "Я знаю, как работает HashMap, ..."
Самый частый и предполагаемый ответ. Иногда кандидат знает, как HashMap работает внутри, просто потому что ответил на этот вопрос на 20ти предыдущих собеседованиях. Иногда, сам разобрался и выяснил. Но дело в другом: получая правильный ответ на этот вопрос, давайте спросим себя, приблизились ли мы к цели собеседования на самом деле?
Скорее всего, да. Да, при условии, что мы нанимаем человека на работу над библиотекой продвинутых структур данных, где коллеги пишут свои собственные реализации Java коллекций на постоянной основе.
В оставшемся большинстве случаев, что нам это дает? Знание того, что кандидат проходил собеседования до нас? Возможно, что кандидат заучил список топ-100 вопросов на Java собеседований накануне (к сожалению, такие списки очень популярны)? В теории, что он понимает устройство языка глубже, чем просто использование? Зачем? А если это то, что нам нужно, – является ли такой шаблонный вопрос хорошим для подобной проверки?
Дополнительно спросим себя: если вопрос гуглится, понимается и запоминается за считанное мгновение, является ли незнание ответа на него чем-то, на что мы должны полагаться при решении приема на работу?
Можно также возразить, что на этот вопрос некоторые интервьюеры смотрят со стороны "начать диалог, снизить напряжение". Но может ли вопрос, предполагающий точный, однозначный ответ, быть корректным для этой цели? Первое впечатление слишком сильно влияет на последующее восприятие, и в интересах интервьюера дать кандидату раскрыться с первой же минуты диалога.
Кандидат B: "Я не знаю, как работает HashMap, но знаю, что он обеспечивает, и как пользоваться"
Хуже ли такой ответ варианта Кандидата А? Кажется, что нет. На первый взгляд также может показаться, что кандидат честно признается, что не обладает всеми знаниями, а честность – это хорошо! Но когда речь заходит о техническом собеседовании, ситуация не так очевидна.
Ответ вроде "не знаю, но ..." может обеспечить подсознательную негативную оценку со стороны интервьюера. Психологические исследования подсознательных суждений показывают, что даже когда мы стараемся быть объективными, мы склонны ассоциировать знание с компетентностью. Когда кандидат говорит, что не знает, это может подсознательно вызвать сомнения в его способности эффективно выполнять задачи, хотя на практике – скорее всего, это неправда!
Чтобы избежать подобных ложных установок, можно постараться спланировать вопрос в ключе "существует ли единый, однозначный ответ?", и, если ответ существует, – дважды подумать перед тем, как задать его.
К счастью для разработчиков, мы можем уверенно подойти к проблеме отсутствия точных знаний, посредством задания неточных вопросы: "Какие коллекции знаешь, как использовал?", "Как справлялись с проблемами распределенных транзакций?", "Какую бы БД ты бы выбрал в этом случае? А почему, какие альтернативы?"
Бенефиты такого способа опроса заключаются не только в уменьшении возможных ложных суждений, но и в увеличении вашей собеседнической тракции, глубокому пониманию опыта кандидата, проверке критического мышления и умения находить полезные компромиссы.
Никакая технология в программировании не существует в вакууме – подобно конкретному слову/переводу в словаре, технология в первую очередь – это средство достижения цели.
Представьте, что на выпускном экзамене в лингвистическом университете у выпускников бы спрашивали – "как переводится слово causal? (причинно-следственный, всегда путаю с casual)", и на основании еще 50ти знакомо-незнакомых слов принимали решение о выдаче диплома? Звучит абсурдно, но этот пример совсем не далек от "стандартных" вопросов на техническом собеседований.
Кандидат C: "Я не знаю, как работает HashMap, но могу предположить, что..."
Хуже ли такой ответ варианта кандидата А? Если предположение совпадает с реальностью, нисколько! Зависит от настроения интервьюера, но возможно даже получится так, что кандидат получит несколько бонусных очков за рассуждение! А кандидат А, знающий прямой ответ, оттарабанив его на автомате, их получит? Сомневаюсь.
Ситуация становится еще хуже, если предположение не совпадает с действительностью, но звучит разумно. Разумность, при этом, определяется интервьюером, который может не располагать необходимыми знаниями в требуемой глубокой области, ведь задав точный вопрос – ты ожидаешь получить точный ответ.
Возможно, наш кандидат на завтрак объясняет устройство дерева Фенвика бакалавриату ИТМО и на обед консультирует младшего брата Роберта Мартина по написанию чистого кода, но на вопросы "как работает HashMap" и "Расшифруй SOLID" отвечает – "не знаю, но могу предположить..", и получает штраф-балл за свое собственное "не знаю, но.." и штраф-балл за то, что не знает интервьюер, который не ожидал такого поворота событий. А что еще хуже, интервьюер о таких увлечениях кандидата в потоке шаблонного собеседования может даже не узнать!
Если исходить из предположения, что интервьюер всегда знает широкий ответ на собственный вопрос (что тоже разумно, ведь сам интервьюер как-то работает) и может дать возможность порассуждать, – почему не дать порассуждать кандидатам А и В?
Чем ближе семантика ответов нескольких кандидатов в сравнении, тем проще делать выбор между ними.
Сделать выбор между кандидатом, ответившим правильно на точный вопрос и кандидатом, ответивший с энтузиазмом, ноткой критического мышления и здравым смыслом – тяжело.
Чем шире область вопроса – тем глубже можно зайти. Не загоняйте себя в ловушку собственными формулировками.
Кандидат D: "Я не знаю, что такое HashMap"
Возможно, единственный ответ на конкретный вопрос, который приблизил нас к пониманию. Возможно, не только приблизил, но и убил, и мы спрашиваем себя – как такой кандидат вообще к нам прошел? В данном конкретном случае кажется, что это совсем не тот вариант ответа, который мы ожидаем, но это показательный пример по другой причине:
Наши ожидания – наши проблемы.
Уверенность в определенном варианте ответа всегда плохо сказывается на трезвой оценке происходящего. Чем сильнее ожидание – тем сильнее падение в случае опровержения, и тем слабее ощущение в случае подтверждения.
Рассмотрим чуть менее шаблонный (и не менее вредный) вопрос: – "Что означает буква D в аббревиатуре SOLID?". Вопрос классический, и как интервьюер, могу предположить, что 9 кандидатов ответит на него верно, а 1 – запутается в термине DI и начнет рассказывать про механизм Dependency Injection. Говорит ли нам это, что код этого бедолаги читается хуже, чем остальных? Узнали ли мы что-то о его стиле разработки, о вещах, которые он ценит при написании кода, при ревью? А что насчет тех ребят, которые ответили верно? [Аргументы из секции Кандидата A].
Мы буквально узнали только то, что кандидат понимает термин Dependency Injection, но не может расшифровать букву D. В наших же глазах он опустился на последнюю строчку по вопросу "чистого кода", который предполагается под этим самым SOLID вопросом, и упал еще ниже на основании наших собственных ожиданий, что безусловно, ложно.
Дело, конечно, не в HashMap. "Как работает HashMap" лишь частный случай куда большей проблемы – бездумной преемственности вредных вопросов, кочующих от интервьюеров к кандидатам – будущим интервьюерам, из года в год как неявный бэклог.
С каждым "вопросом с общего листа" шанс найти настоящий бриллиант пропорционально уменьшается, а шанс найти очередную звезду собеседований – увеличивается. Просматривая потенциальные варианты вопросов, спросите себя, можно ли к ним "явно" подготовиться? Имеют ли вопросы точные и однозначные ответы? Представьте себе худшую теоретическую картину кандидата, который потенциально может пройти собеседование, и пересмотрите свой подход, если картина вам не нравится.
К сожалению, большинство компаний, в которых мне посчастливилось проходить собеседования, упускало еще одну очень важную деталь – заинтересованность самого интервьюера в качественном найме на позицию. Если человек не понимает, кого они ищут, если человек не знает, зачем им еще один коллега, никакие советы по содержанию здесь не помогут. Посмотреть на ситуацию под этим углом мы попробуем уже в следующей статье.