Опять про интервью, теперь со стороны нерелевантных вопросов

Утро доброе
Будучи не первый год на хабре, читал многие статьи на тему интервью: со стороны инженеров на входе, со стороны TA, со стороны успешного литкода. Хотелось бы добавить в эту, без сомнения, внушительную коллекцию мнение со стороны человека, чей подход к интервью многократно называли “завалил на тонкостях”.

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

Вопрос первый: Какие операционки есть у вас дома и почему?
Цель вопроса — не отсеять виндузятников, а услышать именно что мотивацию и склонность к ИТ вне тасок в джире. Как, наверно, понятно из описания, ответы в стиле “у меня есть комп, за которым я играю\смотрю ютуб и больше ничего” не приведет к успеху.

Вопрос второй: Какой инструмент вы бы выбрали для <стандартная задача в рамках роли> и почему?
Пример стандартных задач: CDC для дата инженера, оркестрация для MLOps, управление конфигурациями для админа и так далее.
Цель вопроса: понять знакомство кандидата с основной ролью, на которую он пришел и стандартным актуальным инструментарием в этой области. Если мне назовут динозавра или же always in beta продукт — я сильно насторожусь. С динозавров сложно переучиваться и скорость адаптации проекта у кандидата с динозавром не будет впечатлять. Смузи-стек может быть как хорошим признаком для совсем зеленого проекта, так и плохим признаком для команды с трехлетней историей.

Вопрос тертий, из-за которого и затевался этот очерк: назовите технологию, в которой вы чувствуете себя наиболее уверенно и которая вам больше всего по душе? После получения названия — вопрос “второй степени” в эту технологию.

“Вопрос второй степени” — это ситуация, которую с большой вероятностью нужно решать в проде, но на которую нет прямого ответа в документации. Пара примеров:

• Технология: “elasticsearch”. Вопрос: индексы не помещаются в память. Что делать?

• Технология: “linux”. Вопрос: у вас LA 9000/9000/9000, но система отвечает и к ней можно законнектится. Куда копать?

• Технология: терадата\snowflake\hive. Вопрос (для дата инженера): перформанс одного и того же запроса падает быстрее, чем растет количество данных. В чем может быть проблема и что делать?

Цель вопроса достаточно проста: получить от кандидата технологию, в которую он умеет лучше всего (почти) безотносительно заявленного стека на проекте и проверить, то он в ней действительно разбирается. Если самая сильная технология раскопана на уровне первых трех ссылок гугла — то есть хорошая вероятность, что и с остальным будет сильно не лучше. Когда вам, в следующий раз, задают вопрос “на завалить” возможно ваш интервьюер преследует именно такую стратегию.

Хорошего дня, леди и джентльмены.

Немного о себе для контекста:

• В основном, интервьюирую людей с бэкраундом около системной инженерии и анализа данных, в последние несколько лет добавился ML/DL и питон разработка в контексте интеграционных\системных сервисов

• Команды от энтерпрайза разной степени кровавости, до стартапа с минус тремя месяцами существования

• За плечами более 500 интервью на разные уровни: от джуна до архитектора и ПМа

• Сам со стороны интервьюируемого был ровно 6 раз за все это время

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