… На этот раз без хейта, но с мемами.

Привет, Хабр! Меня зовут Леонид Калядин, я Cluster Data lead в МТС Диджитал. Однажды на собеседовании в очень известную компанию с моим знакомым случилась интересная история. После интервью он произнес всего одну странную фразу. «Я ответил все правильно, кроме тех вопросов, где нужно было ошибиться» Оказалось, что он дал верный ответ, а собеседующий начал утверждать обратное. В итоге моему другу отказали с формулировкой «У вас недостаточные знания SQL». 

Вопрос при этом был простейший: «Какие поля можно вывести в SQL-запросе, при условии использования групповой функции?». Ответ друга: «Те, которые участвуют в группировке и результаты агрегации по другим полям». Внезапно собеседующий сотрудник сказал, что это не верно и вывести можно все поля. Вот так просто и безапелляционно он закончил интервью, не став ничего проверять в онлайн редакторе SQL-кода.

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

Обесценивание опыта

Часто случаются истории, что собеседование плавно переводится в разряд какого-то челленджа. Например, при интервью на middle-позицию или junior+, начинаются вопросы уровнем сильно выше. При неправильных ответах следует: «Ну вот, ты же этого не знаешь. Почему ты хочешь больше денег?». Много людей, особенно на старте карьеры, после такого начинают сомневаться  и считать себя некомпетентным специалистом и в итоге разочаровываются в своих навыках.

Обычно такая ситуация возникает, когда собеседующего устраивает уровень знаний соискателя, но ему нужно снизить зарплатную планку или просто самоутвердится. Интервью начинается с обычных вопросов, соискатель уверенно все отвечает, но сложность все растет и растет, затрагивая уже смежные компетенции. Собеседующий в этом случае прекрасно понимает, что запрос у человека выше вилки. Ему нужно за что-то зацепиться. Например, на позицию разработчика могут начать спрашивать про SRE и инфраструктуру, либо задают вопрос о работе конкретной СУБД, что никак не связано с прямыми задачами на будущей должности. Уверенность соискателя теряется и довольный работодатель, не получив ответа, говорит: «Если вы таких основ не знаете, то придется снизить зарплатные ожидания».

Избежать подобных уловок можно, если четко ставить границы и оценивать свою потенциальную зону ответственности и соответствие вопросов предлагаемой должности. В описанном примере было бы логично спросить: «А должен ли я знать на это ответ?». Нужно четко понимать, какие вопросы соответствуют уровню вакансии, а какие уже лежат в диапазоне совершенно других должностей и зарплат.

Со стороны компании самая правильная тактика — это честность. Можно открыто описать ситуацию, предложить другие варианты. А если какие-то специфические вопросы действительно критически важны для этой вакансии или вам интересно проверить кругозор потенциального сотрудника, то честно напишите это в описании или еще на этапе HR уточните уровень дополнительных знаний у соискателя. Даже если человек откажется, у него останутся положительные впечатления о вашей компании. 

Технические ошибки собеседующих

Вернемся к первой истории. Когда начался спорный момент, мой знакомый подумал: «А есть ли вообще смысл доказывать собственную правоту?». Если бы нанимающий вместе с кандидатом разобрали проблемный вопрос, то мог получиться интересный нетворкинг, который бы позволил оценить атмосферу рабочего процесса и общий уровень коммуникации в команде. 

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

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

Фейковые собеседования

Другая беда, с которой сталкиваются многие senior-специалисты. На одном из интервью мне предложили накидать системный дизайн, перечислили конкретные ограничения текущих реалий, и попросили встроить решение в их стек технологий. Казалось бы, типичная рабочая ситуация для архитектора.

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

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

Это нормальная ситуация, когда ищут опытного человека, который потушит текущие пожары и не допустит следующие. Можно честно предупредить: «Слушай, у нас не будет чистого системного дизайна: стек уже выбран, а возможности его оперативно поменять нет. Как решишь такие и такие проблемы?», Так кандидат поймет, насколько ему интересны текущие задачи в компании и с чем он столкнется при выходе на новую работу. Увы, но многие вместо этого пытаются получить бесплатную консультацию.

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

Как избежать подобных ловушек и не потерять нервы и время 

На мой взгляд, собеседование — это обоюдный процесс. Даже если кандидат не подошел по ожиданиям или компетенциям, важно создать положительное впечатление как о компании, так и о специалистах, которые в ней работают. Один из способов сделать это — предоставить полную и конструктивную обратную связь. Например, во время собеседования в МТС я получил один из лучших примеров такого ответа:

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

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

Комментарии (30)


  1. XelaVopelk
    20.02.2025 09:43

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


    1. Lkalyadin10 Автор
      20.02.2025 09:43

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


      1. XelaVopelk
        20.02.2025 09:43

        С точки зрения техстека самое простое объяснение "поддерживать зоопарк технологий нам дорого". ИМХО для соискателя в этом случае наиболее благоприятный способ себя показать это решить задачу в условиях заданных ограничений, а потом по итогу разговора касательно этого решения показать как можно элегантно и с меньшими затратами (важно!) сделать то же самое с использованием "такого-то" техстека.

        Способность решать задачу в условиях заданных ограничений это как раз не про хард скилы.


    1. pkchlov
      20.02.2025 09:43

      Архитектору, окей. А с каких пор системный дизайн в качестве отдельной секции стал обязательным для обычного разраба уровня сеньор (ну или миддл+, предпочитаю быть скромным)? Прохожу сейчас очередную мясорубку собесов и оно сейчас практически на каждом собесе. Как и девопс, как и алгоритмы/кодинг "в прямом эфире"


      1. remindscope
        20.02.2025 09:43

        вот мы прямо сейчас в поиске разраба такого уровня на java, и лично я никому не задаю вопросы на эту тему на собеседовании, да и мои коллеги, в целом, тоже


      1. XelaVopelk
        20.02.2025 09:43

        Если фирма типа Озона, где архитектор - птица редкая (Степаненко считает архитекторов дармоедами), то на сеньора будет систем-дизайн в обязательном порядке.


  1. vldmrmlkv
    20.02.2025 09:43

    получил один из лучших примеров такого ответа

    Хороший опросник, можно самому спросить если нет обратной связи и я бы ещё добавил вопросы по типу "Что Вы рекомендуете улучшить?" :)


  1. AlexMih
    20.02.2025 09:43

    Те, которые участвуют в группировке и результаты агрегации по другим полям

    Если уж копнуть глубже, то это не всегда так. Насколько я помню, MySQL тупо позволял выводить все что угодно, правда при этом значение не-агрегатных полей не гарантировалось - оно могло принимать любое значение из группы. Ну и оконные функции я бы упомянул отдельно.


    1. Lkalyadin10 Автор
      20.02.2025 09:43

      Я проверил запрос на SQL fiddle на нескольких СУБД, включая MySQL, Oracle и MS SQL, и все они выдали ошибку, только на MariaDB и SQLite запрос выполнился без ошибки. Важно отметить, что, в истории из статьи, исходный вопрос не содержал уточнений о конкретной технологии и  ответ соответствовал правилам основных реляционных СУБД, а интервьювер вместо уточнения технологии или контекста, просто закончил собеседование. Вообще хорошо наверное, что такие особенности коллег на собеседовании уже проявляются, а не в первые дни как вышел на новую работу :)


      1. AlexMih
        20.02.2025 09:43

        Оказывается, все еще интереснее. То что вы говорите, действительно для древнего SQL-92. В SQL-99 введено дополнение - можно выводить в SELECT не только группировочные поля, но и поля, явно связанные с ними. Например, при группировке по user_id можно также вывести user_name, но только если user_name однозначно определяется через user_id:

        SELECT user_id, user_name, count(*)
        ...
        GROUP BY user_id

        В MySQL совместимость с этим хозяйством регулируется опцией ONLY_FULL_GROUP_BY. Еще это вроде бы поддерживает PostgreSQL.

        Так что поговорить тут есть о чем. Что, однако, никак не оправдывает поведения интервьюера.


        1. onets
          20.02.2025 09:43

          Тоже хотел вставить скрин из my sql - я несколько раз напарывался на это, когда случайно забывал добавлять колонки в group by - оно работало без ошибок, но выдавало дичь


  1. jhoag
    20.02.2025 09:43

    полную и конструктивную обратную связь

    Адекватность

    У нас такие разные представления о хорошем и плохом.


    1. Lkalyadin10 Автор
      20.02.2025 09:43

      Любой критерий в какой-то мере субъективен. Что касается "адекватности", то если бы, например, в ОС я получил бы 5 по знаниям и соответствию тех. стеку и позиции, но 3 за "адекватность", я бы задумался: хочу ли я переходить в компанию, где мой стиль мышления может кажется коллегам не совсем адекватным :)


      1. jhoag
        20.02.2025 09:43

        Адекватность не используется как самостоятельная величина. Это отношение к чему-то: «опыт, адекватный зарплатным ожиданиям». Но я не удивлён. Вымышленный критерий, измеренный в попугаях, — эйчар-бренд МТС.


      1. vldmrmlkv
        20.02.2025 09:43

        возможно "soft skills" или "коммуникация" корректнее будет, чем адекватность)