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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


ссылка на оригинал статьи https://habr.com/ru/articles/751594/

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *