В эфире непостоянная рубрика, в которой я отвечаю на вопросы своих студентов и подписчиков.
“Толя, а может стоит скушать время интервью, излишне долго останавливаясь на каждой теме, чтобы не получить сложных вопросов?”
Затея как минимум хреновая, как максимум - нифига не получится. Попытки затянуть разговор обсуждениями общих, либо хорошо понятных вам тем обречены на провал, сегодня расскажу почему.
Интервью - попытка оценить профпригодность кандидата. И повышение валидности этой попытки - первый шаг при построении процесса найма. Самое очевидное решение, к которому нынче прибегают примерно все крупные компании на рынке - стандартизация структуры технического интервью. Интервьюер может быть гуру разработки, но ничего не смыслить в определении чужих компетенций. Чтобы это нивелировать ему предлагают список тем, знания в которых нужно оценить по балльной шкале. Он старается уложиться в тайминг собеседования и обязательно затронуть каждую.
Может сложиться иллюзия, что если задержать собеседующего праздными разговорчиками, то по последним темам он успеет спросить по одному вопросу, но эта имба-стратка контрится мини опросником, который обычно у интервьюера в самом низу. Там помимо общего впечатления о кандидате еще добавляют пункт “Удалось ли обсудить все вопросы?”. Тут даже не самый прошаренный задумается, а не обвели ли его вокруг пальца. А усердные пионеры разработки могут лихо превратить часовой слот в двухчасовой, чтобы успеть спросить все, что написано в методичке для собеса.
Впрочем, есть схема получше. Трюк, который я предложу взамен очень похож: надо активно демонстрировать знания в темах, в которых вы разбираетесь, уводя разговор от сложных концепций, в которых шарите плохо. Этого можно добиться разными способами:
- Придание обсуждению флёра самоочевидности и рутинности, который отбивает желание копать вглубь. При ответе делать морду вида “ну это ж понятное дело вот так то и так, ёмаё”. Обязательно держать уровень абстракции в ответе таким, чтобы не хотелось докопаться до мелких деталей и в идеале не делать больших пауз.
Допустим, вы не разбираетесь в том как устроена HashMap, когда она там расширяется и кто такие эти ваши красно-черные деревья. При намеке на поворот разговора в сторону хешмапы делаем снисходительное лицо, как будто объясняем ребенку и твердо и четко выдаем абстрактную базу: “Хешмапа работает быстро за счет механизма хеширования, внутри у нее самобалансирующееся деревья, их количество может увеличиваться в зависимости от лоад фактора”. Я так уже 6 лет говорю, всегда прокатывает. Один раз чуть не попался: интервьюер хотел узнать как это чертово дерево работает. Пришлось татуировку на руке расчехлить и отшутиться, тут он уже сдался и мы перешли к другой теме.
- Занятие доминирующей позиции. Кто сказал, что технические вопросы должны задавать только вам? Этот трюк требует определенного навыка и тренировки, но работает восхитительно.
Для примера визуализируем: только что озвучен вопрос про нормальные формы БД. Вы раскидали за 3НФ, но в целом именно в БД шарите плохо, дальше вас ждут хрен пойми какие вопросы по теме, поэтому самое время перехватить инициативу и самому озвучить вопрос: а какая у вас в БД нормальная форма? А почему так? А сколько рпс держите? Собеседующий скорее всего не удержится и начнет вспоминать всякие нюансы по своему проекту, рассказывать как они борются за оптимизацию. В процессе затронет набор основных топиков, о которых хотел спросить. Останется лишь покивать с умным видом, пока он с удовольствием демонстрирует свою прошаренность. Очень вероятно он сам убедит себя, что вы тоже хорошо разбираетесь в теме. Готово, вы восхитительны.Намеренно затягивать интервью - плохая идея. Все таки собеседующие, как и женщины - любят ушами. Динамичный интересный разговор оставляет приятное впечатление. После него хочется оставить положительный фидбэк. А затянутый и душный наоборот - вызывает желание больше никогда не встречаться на рабочих созвонах.