Главная » Хабрахабр » Вам не следует проводить собеседования, потому что… [спойлер — вы сами не ходите на собеседования]

Вам не следует проводить собеседования, потому что… [спойлер — вы сами не ходите на собеседования]

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

Более того, вы сами это прекрасно знаете, сознательно или подсознательно, однако корпоративная этика мешает заявить прямо о своих сомнениях.

Для привлечения внимания покажем картинку и продолжим.

Народ нарывается на ЯРОСТЬ

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

Соискатель и работодатель смотрят на проведенное время

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

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

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

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

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

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

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

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

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

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

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

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

Disclaimer

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Оставить комментарий

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

*

x

Ещё Hi-Tech Интересное!

Оптический приемопередатчик FTDI-POF

Мне предложили поучаствовать в одном проекте связанном с передачей данных по оптическому волокну и я с интересом взялся за эту работу. Привет, Хабр, я студент по специальности лазеры в инфо-коммуникационных системах и я впервые работал с оптоволокном. Это интернет, подключение ...

«Kubernetes во все поля!» – интервью с программным комитетом конференции DevOops

Раньше докер был крутым, молодежным, вещью в себе. А потом как-то докер перестал быть интересен: он просто есть, он у всех и во всем. На нем все микросервисы, Kubernetes, девопс — всё, что угодно. Вместе с тем, люди тащат контейнеры ...