Глупые темы на собеседовании

Тезис: вам не следует проводить собеседования, если вы не ходили хотя бы на три интервью как соискатель за последние полгода.

Зачастую на собеседовании люди смотрят на сам процесс интервью достаточно однобоко. Однако большинство опытных соискателей проводили хоть раз собеседования или же интересовались ими совсем недавно (чтобы облегчить жизнь самому). Однако с другой стороны стола сидит человек (не всегда, однако очень часто), который пришел на встречу в середине рабочего дня, в его голове всё еще крутится проект. Отсюда и получаем, что на одни и те же вопросы и ответы, соискатель и работодатель смотрят по-разному.

[sendpulse-form id=”278″]

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

Я нашёл как минимум три стандартные темы, которые помешают нам нанять грамотного человека. Всех их объединяет одно — если следовать совету из тезиса, вы сами четко поймете, почему они только сбивают вас при разговоре с будущим членом вашей команды. Однако важно помнить, что у тезиса есть и обратная сторона: если вы знаете, что плохо проводите интервью, однако абсолютно не хотите ничего улучшать, вы не хотите нанимать грамотных людей — вы найдете сотни причин того, почему вам не стоит тратить время на своё хождение по собеседованиям.

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

Глупая тема #1 — разговоры о философии

Итак, вы пришли наниматься в компанию. Вы хороший пахарь в своей области, у вас есть опыт работы. Вы не сверхгений, не нобелевский лауреат. Вы обыкновенный высококвалифицированный специалист.

С другой стороны сидит team leader (или начальник проекта, или менеджер среднего звена, который может быть когда-то даже программировал). У него горит проект, он вообще не знает, кто тут пришёл с ним говорить. Единственное, что он помнит — “ну вроде программист, ну вроде работал с .Net Core”. И после этого задается вопрос: “А расскажите о принципах SOLID?”.

Вопрос о подобной теме кажется очень красивым. Он должен подчеркивать опыт соискателя, он должен показывать разницу между зеленым новичком и бывалым воякой. Есть только одно но — ответ на этот вопрос не показывает абсолютно ничего. Если человек сходу расшифрует все пять букв, то это означает лишь то, что он знает об этом, а вполне возможно, что недавно перечитал информацию об этом. Причем недавно — это в пределах пары недель. Более того, если человек вообще не вспомнит, что обозначают буквы, то это всё так же ничего не означает. Вы ведь берете на работу инженера, не философа, не ученого, а инженера. Он будет писать код, исправлять ваши же баги, а не рассуждать о высоком. Он будет разбираться с тем, почему так странно сделали интерфейс, а не с тем, почему программа “не канонична, ибо не соответствует формальным 200 правилам”.

Однако если вы услышали подобный вопрос на собеседовании, то есть несколько вариантов, кто перед нами. Наиболее вероятные — или менеджер среднего звена, который иногда смотрит код. Или же практикующий инженер, который просто решил начать диалог с хоть какого-то вопроса. А потому правильный ответ соискателя будет содержать еще и свой вопрос: “Раз уж мы заговорили о принципах SOLID — как вы бы сделали сервис авторизации полностью по этим принципам? Мы с Вами знаем, что сервис должен отвечать за уйму важных вещей, однако давайте он будет делать только три вещи: проверять логин/пароль, выдавать токен, а заодно и проверять этот самый token”.

Вопрос выше хорош тем, что вы быстро (и с большой долей вероятности) поймете, с кем имеете дело.

Технический специалист быстро даст заднюю передачу и признается, что всё это философия, она нужна чтобы начать разговор, однако всё это неважно. И вы продолжите общение.
Менеджер среднего звена ответит на философский вопрос что-то в стиле “необходимо использовать неблокирующую очередь и IoC контейнер, использующий свой Class Loader” (я намеренно преувеличил ответ, чтобы была понятна суть). Это звучит для не-программистов очень умно, а значит даже похоже на небрежный такой ответ, из которого любой поймет дальнейшее решение. Однако мы говорим о роли разработчика ПО, потому вы сразу догадаетесь, что на другом конце стола — не технический специалист, а потому вы сможете выбирать ответы так, чтобы именно понравиться ему.

Небольшая ремарка — как вести диалог с не-специалистом, который считает, что он специалист

Чаще всего такой человек вырастает из программиста, однако последний раз он делал сам что-то серьезное лет пять назад. Однако наш партнер всё равно считает, что он в тренде, а потому с гордостью говорит о технических подробностях. На это и будет давить.

Если сказать разработчику баз данных, что Oracle/MS SQl сами умные, а потому им не требуется отдельный тюнинг, то специалист сразу отправит вас домой. А заодно разозлится, приведет кучу аргументов и примеров из жизни, когда это не так. Однако, когда мы говорим с менеджером, мы запросто можем выдать фразу вида “в разработке баз данных есть самое главное правило — все запросы должны быть простыми. Любой тюнинг и ускорение запросов (то есть добавление hint-ов) затратит время работы команды, усложнит решения, а выхлоп будет минимальный”. Подобная фраза будет как бальзам на душу человеку, который не знаком с базами данных на практике, однако знает теорию и философию. А еще его достали объяснения коллег, почему нельзя сделать задачу быстро, так, как он предполагал в своих обещаниях начальству.

Есть и другая схема давления на философа-менеджера (который пытается казаться и технически грамотным, это очень важно). Зачастую они живут технологиями своей бурной молодости разработчика, а потому полезно будет сказать, что вы противник внедрения самых последних, еще не проверенных временем решений. Поставьте себя на место управленца — он привык к C-подобному синтаксису, а народ собирается кодить на Kotlin/Swift/Scala. И тут приходит человек, который полностью готов (и всеми руками за) использовать старые, понятные менеджеру, технологии, где наш любимый управленец всегда сможет подсказать. Ну как тут можно устоять?

Disclaimer

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

Грамотными управленцами. Они просто пропустят технические фразы. Им важно, чтобы работало стабильно и предсказуемо, чтобы в решении было много полезного и удобного функционала. Они хорошие и умные, манипуляцию они почуют сразу.
Начальниками проекта, которые сами не забывают программировать (а не просто иногда смотрят код). Эти люди быстро выведут вас на чистую воду.

Вывод о философских рассуждениях

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

Однако к разговорам о философии не относятся следующие темы:

Идеи того, как и почему базовые структуры устроены тем или иным образом. Это просто вопросы о дискретной математике, практически каждый опытный сотрудник видел неправильное применение структур (хоть и редко).
Как можно улучшить класс XXX. Это вполне практический вопрос, да вы и сами часто отвечаете на него, глядя в код.

Глупая тема #2 — разговоры, не относящиеся к работе

Клише — о преданности делу

Очень важная ремарка: чтобы стать токсичными, все эти вопросы ну никак не должны относиться к хотя бы половине сотрудников. Или по-другому: сами сотрудники могут ответить на них “неправильно”, и это будет считаться абсолютно нормальным.

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

Однако вопросы выше мутировали. Например, один из трендов 2018 года: Если у вас есть год свободного времени, вам платят зарплату и так далее. Вопрос: а чем вы будете заниматься? Я, к сожалению, не знаю ответ на этот вопрос, который удовлетворил бы хотя бы 80% работодателей. Этот вопрос только вредит собеседованию, так как:

Соискатель сразу видит перед собой идиота, у которого закончились вопросы по делу, однако крайне не хочется возвращаться к работе. В голове у работодателя может быть совершенно иное, однако именно так он выглядит со стороны — идиот.
На этот вопрос никогда не дадут правдивый и искренний ответ. Просто потому что все хотят казаться в глазах других людей человеком, который не бросит в беде, Матерью Терезой современности. Так не принято делать, однако очень хочется казаться. А потому соискатель с большой долей вероятности преувеличит практически всё, что только можно.
На этот вопрос уже есть абсолютно искренний, верифицируемый и известный ответ. У 40-летнего программиста было порядка 20 лет работы за свою жизнь, то есть около 20 месяцев отпуска, 2 000 выходных. Плюс еще есть немало вечеров, праздников и т.д. Получаем важное следствие — всё то, что человек мог сделать за теоретический год, он уже сделал за свою жизнь. Более того — в резюме и так описаны самые вкусные подробности, все Open Source проекты, все достижения. Всё уже есть.
И самая главная причина того, что вопрос вредный: нам не нравится правда о сотруднике, мы просим его лгать и фантазировать, чтобы убедить самих себя, что он нужен.

Разговоры о полезности свободного времени

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

В чем же минус этого вопроса? Ведь мы просим человека еще рассказать о том, какой он умный и хороший, как легко он освоит новые знания (всё то, что выделено курсивом — обман и лукавство). Однако по факту:

Если человек серьезно работает по 10-12 часов, он зачастую изучает достаточно на самой работе. Он смотрит презентации коллег, он читает профильные статьи, он анализирует многое из того, что непосредственно связано с его работой. В итоге, если человек действительно профессионал, то он не сможет честно и красиво ответить про свободное время.
Если же наш соискатель тонкий манипулятор, то он мигом сможет понять, что его уже практически взяли, раз задают подобные вопросы. Ну разве стал бы работодатель задавать вопросы не о профессии, если уже решил не брать собеседника? А потому грамотный переговорщик ответит что-то в духе: “Мы говорили о технологиях .Net на Windows. Я дома сейчас читаю статьи о .Net Core на Linux (ну или на Mac, можно на iOS/Android, главное — чтобы тема была смежная, а не совпадала). Я считаю, что это будущее отрасли, а потому стараюсь тщательнее относится к новым решениям, потому что нам скоро с ними работать”. Я неоднократно слышал такой ответ, однако всякий раз соискатель быстро уходил с технического описания на теорию. Однако шаблон ответа по своему прост и гениален. Ведь новый сотрудник делает пассаж в сторону технологии, с которой имеет дело собеседник. Потому он приводит парочку правдивых (хоть и общеизвестных) фактов. И в завершении переводит тему туда, где можно лукавить и откровенно врать, так как проверить работодателю будет сложно (он-то сам вряд ли это изучал).
И самое важное следствие: как бы не ответил соискатель, всё это не важно. Вы сами можете проверить в компании, что ответ про свободное время никак не будет коррелировать с качеством работы.

Вывод о разговорах, не относящихся к работе

Не задавайте таких вопросов. Все компании более менее одинаковые, нет смысла просить кандидата признаться в преданности. Нет смысла спрашивать то, что даже проверить сложно — вы просто возьмете лгуна, а выгоните честного работягу.

Не задавайте вопросов, на которые даже члены вашей команды ответят неправильно.

Глупая тема #3 — разговор о редко встречающихся проблемах

Клише — я недавно узнал, давайте поговорим об этом

Пример токсичного вопроса: “Мы делаем сервисы на Java, недавно мы обновились на Spring Boot 2 и заметили интересную особенность сериализации XML — в ряде случаев сервер не может обработать XML сообщение. Вам приходилось с таким сталкиваться?”

Что ожидает услышать работодатель: новый класс Jaxb2XmlDecoder не переопределяет метод decodeToMono, который объявлен в AbstractDecoder (как вы понимаете, Jaxb2XmlDecoder наследует AbstractDecoder). Реализация decodeToMono по умолчанию — бросок исключения, что приводит к тому, что нельзя ни принять XML, ни отправить.

Тезис статьи — вам не следует проводить собеседования, если вы не ходили хотя бы на три интервью как соискатель за последние полгода. Как соискатель, вы уже видите жесткую проблему в этом вопросе. А как собеседующий — не факт.

Итак, чем же этот вопрос плох:

Мы спрашиваем об очень частной вещи. Ошибка ведь не проявляется в JSON сериализации, то есть если у соискателя в проекте использовался JSON, то он просто не мог узнать о такой подставе.
Мы спрашиваем об очень свежей вещи. Ведь Spring Boot 2 не так давно и вышел, а потому соискатель запросто мог работать в проекте, где еще не начали обновление.
Решив эту задачу, мы сами забудем про это. Однако нам так понравилось найденное решение (или сам факт нахождения), что оно прямо зудит в мозгах, а заодно и требует рассмотрения на собеседовании.
Самое важное следствие: скорее всего через год мы сами не сможем ответить на этот вопрос. А значит, задавая его, мы с высокой долей вероятности просто выгоним грамотного разработчика

Клише — хоть у нас этого не происходит, но давайте поговорим

Пример токсичного вопроса: “Хоть у нас и нет больших объемов данных, однако как бы вы хранили 100 Пб данных, с возможностью быстрого доступа к ним?”

Я слышал такие вопросы и от коллег, с которыми я собеседовал, и от потенциальных работодателей. Во всех случаях я задавал себе вопрос: “ну зачем это спрашивать? У нас нет таких задач, мы не профессионалы в этой области. Да и соискатель пришёл к нам с другими навыками. Ну зачем спрашивать то, что мы даже приблизительно не сможем проверить?”.

Этот вопрос очень перекликается с философским, однако выглядит вполне конкретным, реалистичным, а главное — говорит о масштабах компании.

И он тоже очень и очень проблемный, так как:

Мы не сможем проверить ответ человека. Это как с философией о правильном ПО — человек ответит, однако это не даст нам никаких данных о том, что он реально может сделать.
Задача поставлена очень абстрактно. Не сказан ни размер объектов, ни частота записи, нет требований даже о надежности системы. Тут грамотный специалист может просто отмахнуться ответом вида “возьму одно из эффективных распределенных систем хранения”. Или он может испугаться своего незнания, а потому даст сбивчивый непонятный ответ.
Зачастую на такой вопрос даже ваши коллеги не смогут дать четкого и правильного ответа (и это не плохо, это нормально; окулист может просто не знать, какими препаратами лечат редкую форму рака).
Мы приходим с тому же следствию: этот вопрос лишь увеличит погрешность в оценке кандидата. Этим вопросом мы узнаем не то, насколько человек поможет нашей команде, а то, насколько хорошо человек решит задачу другого отдела (или же другой фирмы)

Вывод о попытках фантазировать про редкие проблемы

Не говорите о задачах, которые вы не решаете. Вы опять возьмете не того, кто вам поможет, а того, кто будет фантазировать, как помочь другим.

Общий вывод о глупых вопросах

Как вы уже увидели — есть множество глупейших вопросов, которые только мешают собеседованию. Они даже не нейтральные — они именно вредные. Однако, понять то, что вопрос токсичный, бывает очень сложно. И есть простое и понятное решение: вам не следует проводить собеседования, если вы не ходили хотя бы на три интервью как соискатель за последние полгода.

Ведь это простое, понятное и верифицируемое правило, которое избавит нас:

От глупых и ненужных вопросов кандидату
От громадного эго, налета гениальности и собственной переоцененности

А заодно вы пообщаетесь с умными людьми, плюс найдете вопросы, которые таки стоило бы задать.