Собеседование в руках маньяков

Добрый день меня зовут Александр и я токсичный душнила с двадцатилетним стажем в айти, готовый откусить вам кадык, как только вы расслабитесь. Мои характеристики делают меня хорошим техническим собеседующим, поэтому добро пожаловать на моё провальное собеседование. Запомните, вы его никогда не пройдете. А знаете почему?

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

Узнали? Это то как происходит собеседования в 99% не топ компаний по всему миру. К сожалению, и я вначале шел именно этим путем. Загнобить, унизить человека. Найти его тонкие стороны, чтобы сбить планку, растоптать и подвести технические скилы под заданный мной трафарет, который, конечно будет схожим, но точным, также как шарж точен с оригиналом. Зачастую это хорошая методика. Её даже можно использовать при приеме на работу. Особенно когда денег нет, а иллюзию найма показать надо. Но когда такое техническое собеседование делается в качестве реального инструмента определения качества специалиста - оно никуда не годно. Оно конечно подстегнет ребят работать над собой, но не даст того, над чем именно нужно работать сотруднику.

Поэтому я начал разбирать собеседования. Я смотрел по несколько собеседований ежедневно. Я просмотрел и прочел все списки вопросов к собеседованиям по фронтенду (да я из этих), которые только смог найти. Я прошел несколько собеседований в росгалеры, что бы понять одну простую вещь - большинство однораундовых собеседований никуда не годны. Но и брать сотрудника без собеседования, как советуют некоторые специалисты, в современной России это транжирить деньги работодателя. А раз ответа нет в нашей сфере, то может нам поискать это в сфере педагогики. Уж кто, кто, а они то точно научились отличать задрота-заучку, от студента, который знает предмет.

Таксономия Блума

Да, я говорю именно о таксономия Блума. Давайте я кратко расскажу о чем речь, чтобы те кто не учился в педвузе меня поняли

Бенджамин Блум, докумекал в середине прошлого века, о том что любое знание внутри человека проходит несколько стадий закреплений в голове. Запоминание, понимание, применение, анализ, оценка и создание. А если перевести на наш айтишный, то эти стадии будут примерно такие: где-то слышал, читал пару статей, имею опыт работы, читал код этой абстракции, делал пулл-реквест в нее, и участвовал в создании этой штуки.

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

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

Почему я так решил? Всё дело в вопросах. Давайте выпишем форматы вопросов с собеседований и подумаем какие вопросы ответят нам на вопрос - натасканный это человек или действительно опыт имеющий. Т.е. отвечают на вопросы отличные от ступени применения.

Вначале, напишем те шаблоны вопросов, которые задавать, по моему мнению, не надо, так они отвечают на другие ступени:

• Викторинные вопросы.
  Варианты: Что такое …. ?; Как называется … ?;
  Вопросы, аля, “Своя игра”; Вот это самый неправильный вопрос из всех которые только можно предположить. Но и самый популярный. Он отвечает на то, есть ли у человека первая стадия - запоминания (слышал где-то), но не скажет нам работал ли он с этим. Хотя, кстати, некоторые ответы на этот вопрос очень хорошо показывают откуда он это слышал. Например, спросите у джаваскрипт джуна, что такое замыкание. Вы очень удивитесь о том, как легко распознать с каких курсов он к нам пришел

• Вопросы перечисления
  Варианты: Перечисли …; Какие … есть в …;
  Тоже очень популярный и тоже неверный. Он тоже относится к стадии запоминания. Однако у него есть контрпример из стадии применения, который относится к нужной стадии, о нем чуть позже

• Изложение на тему
  Варианты: Расскажите о [название технологии]…
  Тоже вопросы из стадии запоминания, однако они могут быть предтечей следующего вопроса. Либо проверкой на знания очень узкой области вопроса, которая практически не встречается в практической области, но знать о ней, и даже иногда использовать - необходимо

• Как это работает
  Варианты: Как … делает …; Что происходит когда …; Как происходит …; Как работает …;
  Это вопросы из сразу 2х категорий. Из категории понимания и категории анализа. Всё зависит от того есть ли по этим вопросам статьи/книги/видео. Если нет - то это проверка стадии анализа, он позволяет определить насколько человек адекватно мыслит, и может ли он рассуждать. Другое дело когда информация по этим вопросам есть в свободном доступе.

• Разговор о паранормальном
  Варианты: Объясните …; Представьте …; Почему произошло …; (код) WTF?
  Это тоже вопрос из 2х категорий, с одной стороны понимания, с другой стороны - анализа. И здесь нельзя быть уверенным, показывает ли это то что человек сталкивался с решением в каком либо ролике или статье, или то что человек действительно нашел это решение у вас на глазах

• Вопросы уровня ЖОПП (жизненный опыт полученный на практике)
  Варианты: Какие особенности применения …; Что будет если … натянуть на …;
  С одной стороны это хорошие вопросы, и если собеседник смог ответить на него, то они показывают, что у него есть этот опыт. Но тут проблема - обратное не показывает, что человек не имеет опыта. Не каждый собеседующий имеет такой же специфичный опыт как у вас, который необходим для решения этой проблемы

Ну вроде с тем что не надо спрашивать, и почему мы определились. А что тогда спрашивать?

Мой совет – задавать вопросы опираясь на область опыта. То есть те вопросы, на которые можно получить конкретные ответы, основанные на практике. Такие вопросы помогают понять, как человек действует в реальности, а не только то, что он думает об этом. Кроме того, они могут подсказать, какие навыки и методы можно использовать для повышения эффективности работы. Например:

• Поиск ошибки на глаз
  Шаблоны вопросов: (код) Найдите ошибку в этом коде; (код) В чем проблема в этом неработающем коде; (код с тестом) Тест упадет. Почему?;

  Например, мы часто спрашивали у джуниоров в очень давнем прошлом, чем let отличается от var. А потом начали показывать конструкцию c for (var и спрашивать почему он выведет 10 раз число 10. Пока это не стало заезженным это был как раз способ обойти заучивание вопроса о let-var-const. Кстати, после кучи статей по этой теме вопрос из сферы опыта перешёл в сферу анализа.

  Другой, тоже немного заезженный пример, в блоке чтения кода filter.map.reduce, я даю конструкцию .map(parseInt) и смотрю насколько человек знает проблему использования функций нескольких переменных в filter/map/reduce. К удивлению этот вопрос не перешёл в сферу анализа, а так и остался сферой опыта

• Оптимизация на примере
  Варианты: Какая сложность алгоритма и как ускорить; Что не так в этом рабочем коде…

  Тут давайте тоже приведу пример на собесах с джуниором блока об оптимизации. Один из базовых вопросов на собеседовании джунов: “Что такое React.memo?” (ну или более старое по PureComponent). Но не каждый джун и даже мидл умеет их использовать на практике. Например, на вопрос что не так с этим облеченным кодом:

const Component = ({items}: Props) => {
	const viewItems = items.filter(checkViewItem).map(renderItem);
	return (
		<ul className={styles.container}>
			{viewItems}
		</ul>
	)
}

не каждый мидл скажет про оптимизацию и ререндринг компонентов. Кстати, вопрос для мидлов, что тут выгоднее использовать React.memo или useMemo? Подумайте перед ответом.

• Синтез опыта
  Варианты: Перечисли способы ….; Придумайте N способов применения …;

  Аналогичный пример с джун собеседования: Перечислите значения свойства position. Но в реальности оно ни капли не интересно с точки зрения опыта. С точки зрения опыта мы хотим узнать умеет ли джун верстать абсолютами. Поэтому правильнее задавать этот вопрос в следующем контексте: Относительно чего позиционируется элемент с position: absolute. И если джун скажет, что относительно position: relative, то спросить что будет если в один position: absolute поместить другой элемент с position: absolute. Или задать вопрос каким можно вытащить элемент из контекста стекирования и что зачем это вообще нужно.

• Архитектурный вопрос
  Варианты: Как сделать … ; Какие методы …; Какие паттерны использовать …;

  Этот тип вопросов, которые лучше задавать на вакансии от мидла. В более больших компаниях есть целые архитектурные секции, на которых ты рассказываешь как реализовать какой либо функционал. К сожалению, в малых командах никто не даст тебе общаться с кандидатом 5-6 часов, да и кандидаты уже после второго часа просто встанут и уйдут. Тут надо подходить более стерильно.

  Например, просить рассказать как реализовать какой нибудь компонент, будь то таблица с пагинацией или список объектов. Главное ограничить время рассказа 5-10 минутами. Или спросить как можно оптимизировать ререндринг компонента зависящего от части значений глобального контекста.

  Также можно поговорить о стейтменеджерах, сборщиках, css-in-js и минут на 5-6 вывести на холивар на какую либо тему. Да, это очень токсично, однако это очень хорошо покажет софтскилы разработчика. И иногда, даже убережёт вас взять в относительно большой легаси проект человека, который в первый коммит в девелоп всунет правила линтинга перенесенного с предыдущей работы

• Расскажите о вашей ЖОПП
  Варианты: Приведите примеры использования…; А как на вашем проекте было реализовано…

  Очень красивый и одновременно сложный тип вопросов. Обычно вопрос формируется на первом этапе “расскажите о себе”, когда собеседуемый рассказывает о последнем проекте. Тут надо не проспать и подметить что это за проект, какие задачи он ставил. И уже на этапе технического интервью можно спросить, а как вы это делали на предыдущем проекте, какие библиотеки использовали, как решали ограничения библиотек и прочее. Это позволяет глубоко копнуть в технологии, в зону ответственности собеседуемого, его инициативности и проактивность.

  Например, собеседник рассказывает, что у него на проекте был календарь с резервом времени. Можно спросить о том, как был реализован перенос резерва на другой день, неделю. Можно спросить о том, как проверялся наличие ресурса на создание резерва и как происходила обработка исключительных ситуаций, когда резерв нельзя было переместить. Человек, который реально делал проект, а не придумывал это из головы вполне корректно ответит на эти вопросы в рамках своей компетенции. При этом ему будет достаточно легко об этом рассказывать. Единственное, что его будет сдерживать, это NDA. поэтому ответы будут достаточно с большой задержкой, для осознания нарушается ли NDA этим “откровением“ или нет.

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