Вам не следует проводить собеседования, потому что… [спойлер — вы сами не ходите на собеседования]
- четверг, 26 апреля 2018 г. в 00:27:54
Тезис: вам не следует проводить собеседования, если вы не ходили хотя бы на три интервью как соискатель за последние полгода.
Более того, вы сами это прекрасно знаете, сознательно или подсознательно, однако корпоративная этика мешает заявить прямо о своих сомнениях.
Для привлечения внимания покажем картинку и продолжим.
Зачастую на собеседовании люди смотрят на сам процесс интервью достаточно однобоко. Однако большинство опытных соискателей проводили хоть раз собеседования или же интересовались ими совсем недавно (чтобы облегчить жизнь самому). Однако с другой стороны стола сидит человек (не всегда, однако очень часто), который пришел на встречу в середине рабочего дня, в его голове всё еще крутится проект. Отсюда и получаем, что на одни и те же вопросы и ответы, соискатель и работодатель смотрят по-разному.
Как я уже сказал выше, вам не следует проводить собеседования, если вы не ходили хотя бы на три интервью как соискатель за последние полгода, в ином случае вы просто будете проводить собеседования крайне неэффективно, будете попадаться на стандартные ловушки и манипуляции. И в итоге наймете совсем не того, кто вам нужен. Однако корпоративная этика всё-таки заставит вас рапортовать, что "всё сделано правильно, команда стала больше, теперь точно всё успеем".
Я нашёл как минимум три стандартные темы, которые помешают нам нанять грамотного человека. Всех их объединяет одно — если следовать совету из тезиса, вы сами четко поймете, почему они только сбивают вас при разговоре с будущим членом вашей команды. Однако важно помнить, что у тезиса есть и обратная сторона: если вы знаете, что плохо проводите интервью, однако абсолютно не хотите ничего улучшать, вы не хотите нанимать грамотных людей — вы найдете сотни причин того, почему вам не стоит тратить время на своё хождение по собеседованиям.
Все темы являются компиляцией интервью на должность программиста (в том числе своих и по рассказам обеих сторон).
Итак, вы пришли наниматься в компанию. Вы хороший пахарь в своей области, у вас есть опыт работы. Вы не сверхгений, не нобелевский лауреат. Вы обыкновенный высококвалифицированный специалист.
С другой стороны сидит team leader (или начальник проекта, или менеджер среднего звена, который может быть когда-то даже программировал). У него горит проект, он вообще не знает, кто тут пришёл с ним говорить. Единственное, что он помнит — "ну вроде программист, ну вроде работал с .Net Core". И после этого задается вопрос: "А расскажите о принципах SOLID?".
Вопрос о подобной теме кажется очень красивым. Он должен подчеркивать опыт соискателя, он должен показывать разницу между зеленым новичком и бывалым воякой. Есть только одно но — ответ на этот вопрос не показывает абсолютно ничего. Если человек сходу расшифрует все пять букв, то это означает лишь то, что он недавно прочел статью об этом. Причем недавно — это в пределах пары недель. Более того, если человек вообще не вспомнит, что обозначают буквы, то это всё так же ничего не означает. Вы ведь берете на работу инженера, не философа, не ученого, а инженера. Он будет писать код, исправлять ваши же баги, а не рассуждать о высоком. Он будет разбираться с тем, почему Oracle сделала так странно интерфейс, а не с тем, почему программа "не канонична, ибо не соответствует формальным 200 правилам".
Однако если вы услышали подобный вопрос на собеседовании, то есть несколько вариантов, кто перед нами. Наиболее вероятные — или менеджер среднего звена, который иногда смотрит код. Или же практикующий инженер, который просто решил начать диалог с хоть какого-то вопроса. А потому правильный ответ соискателя будет содержать еще и свой вопрос: "Раз уж мы заговорили о принципах SOLID — а как вы бы сделали сервис авторизации полностью по этим принципам? Мы с Вами знаем, что сервис должен отвечать за уйму важных вещей, однако давайте он будет делать только три вещи: проверять логин/пароль, выдавать токен, а заодно и проверять этот самый token".
Вопрос выше хорош тем, что вы быстро (и с большой долей вероятности) поймете, с кем имеете дело.
Чаще всего такой человек вырастает из программиста, однако последний раз он делал сам что-то серьезное лет пять назад. Однако наш партнер всё равно считает, что он в тренде, а потому с гордостью говорит о технических подробностях. На это и будет давить.
Если сказать разработчику баз данных, что Oracle/MS SQl сами умные, а потому им не требуется отдельный тюнинг, то специалист сразу отправит вас домой. А заодно разозлится, приведет кучу аргументов и примеров из жизни, когда это не так. Однако, когда мы говорим с менеджером, мы запросто можем выдать фразу вида "в разработке баз данных есть самое главное правило — все запросы должны быть простыми. Любой тюнинг и ускорение запросов (то есть добавление hint-ов) затратит время работы команды, усложнит решения, а выхлоп будет минимальный". Подобная фраза будет как бальзам на душу человеку, который не знаком с базами данных на практике, однако знает теорию и философию. А еще его достали объяснения коллег, почему нельзя сделать задачу быстро, так, как он предполагал в своих обещаниях начальству.
Есть и другая схема давления на философа-менеджера (который пытается казаться и технически грамотным, это очень важно). Зачастую они живут технологиями своей бурной молодости разработчика, а потому полезно будет сказать, что вы противник внедрения самых последних, еще не проверенных временем решений. Поставьте себя на место управленца — он привык к C-подобному синтаксису, а народ собирается кодить на Kotlin/Swift/Scala. И тут приходит человек, который полностью готов (и всеми руками за) использовать старые, понятные менеджеру, технологии, где наш любимый управленец всегда сможет подсказать. Ну как тут можно устоять?
Советы выше полезны только для манипуляции менеджером, который плохо умеет управлять, а потому часто лезет с техническими советами (а не с помощью). Подобные рекомендации никак не помогут (и навредят) при разговорах с:
Не задавайте вопросы о философии. Вы только себя подставите, да и заодно заставите соискателя лишний раз волноваться и ошибаться. В реальности вам абсолютно не важно, как сотрудники теоретизируют о программах.
Однако к разговорам о философии не относятся следующие темы:
Очень важная ремарка: чтобы стать токсичными, все эти вопросы ну никак не должны относиться к хотя бы половине сотрудников. Или по-другому: сами сотрудники могут ответить на них "неправильно", и это будет считаться абсолютно нормальным.
Клише старое, однако используется: а кем вы видите себя в нашей компании через пять лет? Более того, чаще всего такой вопрос задают или те, которые в компании всего пару лет, или те, которые сидят на одном и том же месте в компании лет 15.
Однако вопросы выше мутировали. Например, один из трендов 2018 года: Если у вас есть год свободного времени, вам платят зарплату и так далее. Вопрос: а чем вы будете заниматься? Я, к сожалению, не знаю ответ на этот вопрос, который удовлетворил бы хотя бы 80% работодателей. Этот вопрос только вредит собеседованию, так как:
Еще один пример того, как запутать самих себя на собеседовании. Это вопросы в стиле: "а как вы проводите свободное время?" И опять эта фраза кажется ну очень умной, хотя и является вредной по факту.
В чем же минус этого вопроса? Ведь мы просим человека еще рассказать о том, какой он умный и хороший, как легко он освоит новые знания (всё то, что выделено курсивом — обман и лукавство). Однако по факту:
Не задавайте таких вопросов. Все компании более менее одинаковые, нет смысла просить кандидата признаться в преданности. Нет смысла спрашивать то, что даже проверить сложно — вы просто возьмете лгуна, а выгоните честного работягу.
Не задавайте вопросов, на которые даже члены вашей команды ответят неправильно.
Пример токсичного вопроса: "Мы делаем сервисы на Java, недавно мы обновились на Spring Boot 2 и заметили интересную особенность сериализации XML — в ряде случаев сервер не может обработать XML сообщение. Вам приходилось с таким сталкиваться?"
Что ожидает услышать работодатель: новый класс Jaxb2XmlDecoder не переопределяет метод decodeToMono
, который объявлен в AbstractDecoder (как вы понимаете, Jaxb2XmlDecoder наследует AbstractDecoder). Реализация decodeToMono
по умолчанию — бросок исключения, что приводит к тому, что нельзя ни принять XML, ни отправить.
Тезис статьи — вам не следует проводить собеседования, если вы не ходили хотя бы на три интервью как соискатель за последние полгода. Как соискатель, вы уже видите жесткую проблему в этом вопросе. А как собеседующий — не факт.
Итак, чем же этот вопрос плох:
Пример токсичного вопроса: "Хоть у нас и нет больших объемов данных, однако как бы вы хранили 100 Пб данных, с возможностью быстрого доступа к ним?"
Я слышал такие вопросы и от коллег, с которыми я собеседовал, и от потенциальных работодателей. Во всех случаях я задавал себе вопрос: "ну зачем это спрашивать? У нас нет таких задач, мы не профессионалы в этой области. Да и соискатель пришёл к нам с другими навыками. Ну зачем спрашивать то, что мы даже приблизительно не сможем проверить?".
Этот вопрос очень перекликается с философским, однако выглядит вполне конкретным, реалистичным, а главное — говорит о масштабах компании.
И он тоже очень и очень проблемный, так как:
Не говорите о задачах, которые вы не решаете. Вы опять возьмете не того, кто вам поможет, а того, кто будет фантазировать, как помочь другим.
Как вы уже увидели — есть множество глупейших вопросов, которые только мешают собеседованию. Они даже не нейтральные — они именно вредные. Однако, понять то, что вопрос токсичный, бывает очень сложно. И есть простое и понятное решение: вам не следует проводить собеседования, если вы не ходили хотя бы на три интервью как соискатель за последние полгода.
Ведь это простое, понятное и верифицируемое правило, которое избавит нас:
А заодно вы пообщаетесь с умными людьми, плюс найдете вопросы, которые таки стоило бы задать.