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

Скрининг

Всё начинает с него, и тех-скрининг становится нормой. Рекрутер прям на первом звонке задаёт каверзные вопросы и сверяется со шпаргалкой. Например:

  • как остановить контейнер?

  • неизменяемые типы данных в python?

  • какой pid у ядра linux?

  • как расшифровывается CAP и PACELC?

  • ...

Тинькофф пошёл ещё дальше и создал целую платформу с небольшими кусками кода, который можно запускать. 20 вопросов за 20 минут. "А как послать сообщение в генератор?" или "А что делает этот код?". Да фиг его знает ‑ я б такой код просто на ревью не пропустил, потому что делает он дичь. Ну и да, я забыл, что у sorted второй аргумент только именованный, так что получил минус. И системе плевать, что гуглится это за 25 секунд, я проверял.

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

Но в то же время магию календаря освоило ~20% из них. Они почему-то уверены, что на фразе "Поставил(а) звонок на пятницу в 13.30, вот ссылочка ..." общение закончено. Нет, блин! Календарь! Потому что я:

  • забуду

  • потеряю ссылку

  • займу слот

  • буду рассчитывать на полтора часа вместо часа

  • не познакомлюсь заочно с собеседником

  • и вообще 13.30 это было по UTC

Должен быть обязательный тест при устройстве рекрутера на работу. И в одной большой компании с кружочками дошло до того, что за 2 недели мы 3 раза договаривались о собеседовании, но в итоге то интервьюер не пришёл, то время не поставили ("я поставлю на понедельник?" - "ага, свободен весь день" - и тишина...). А если попросить перенести по болезни, то про тебя вообще забудут. С календарём факапов будет меньше.

Лайв-кодинг

Вокруг него всегда много шума. Кому-то он нравится (интервьюерам), кому-то совсем нет (кандидатам), а кто-то после него уходит к психологу на полгода. Вот неужели, чтобы понять, что кандидат умеет кодить, недостаточно обширного проекта на github, профильных статей с кодом, докладов в конце концов... Как мне рассказали, это делается для того, чтобы все были равны при найме. Нууу, удачи нанять лида или сеньора через 5 собесов. Уже на втором он спросит себя "А это мне действительно надо? Вот же есть уже 3 оффера" и отвалится.

Ладно, лайв-кодинг. Обычно вам дают 2 задачки, которые нужно запрограммировать. Да-да, повертеть деревья. (А знаете самый рофл? Приходишь потом к ним, а у них вообще деревьев нет) На всё про всё даётся 1 час. И как пройдёт этот час очень сильно зависит от собеседника. Есть те, которые помогают рассуждать, подрабатывают IDE расставляют двоеточие и self, если забыл, проявляют какую-то эмпатию и поддержку - кандидат-то всё равно в стрессе. Берегите таких! Гораздо чаще мне попадаются те, кто даже камеры не включают. Просто дают задание и смотрят на попытки. На одной из таких сессий я решил за час 3 задачки. Получил ли я оффер - нет :) "Потому что у вас и так скорее всего есть из чего выбрать, так что мы не будем дальше общаться". Epic failwin!

Самый интересный лайв-кодинг у меня был с одним канадцем. Мы вместе обсудили и решили задачку. Буквально вместе - он писал одну часть, я вторую, более сложную. И тогда-то я понял ещё одну проблему этой сессии - однобокость. У нас же со-беседование в конце концов. Т.е. и кандидат должен присматриваться к будущим коллегам. Умеют ли они тоже кодить? Работа в ВОТВАСЯ это не всегда предполагает.

А в одной жёлтой компании просят решить задачки за O(1), но зато наплевав на объём дополнительной памяти. Сразу понятно почему их приложение столько весит правда, всё равно тормозит. Но нюанс в том, что на практике такой код писать и поддерживать гораздо сложнее из-за проблем синхронизации этих самых структур данных. И получается, что собеседование превращается в олимпиаду; а там как повезёт - если выспался, придумал решение; нет - ничего, придумаешь перед сном.

Ещё одна причина, почему не любят онлайн-программирование - интервьюер не готовится. Кодирование в блокноте с пошаренным экраном всё равно встречается. Чаще, конечно, просто какой-то онлайн редактор, и хорошо если с подсветкой синтаксиса. Но найти такой ещё пол-дела, надо ж ещё и задачку придумать. Самое странное у меня было: "Реализуйте перевод денег со счёта A на счёт B" - и белый экран. Ни интерфейсов, ни шаблонов, нет даже намёка на БД... И ты просто 10 минут втыкаешь в каком же виде они хотят видеть результат. А классы писать? А какие поля? Короче, весь этот вспомогательный код, который не относится напрямую к задаче.

А теперь как надо. Больше всего мне понравилось обсуждение какого-то PR. Тут без сарказма, сразу понятно как человек будет себя вести в рабочей ситуации. На что он обращает внимание, а что пропускает и почему. Например, сеньоры обычно игнорируют форматирование, потому что это работа линтеров, а больше сосредотачиваются на API, гонках и оптимальной работе с базой. Настоятельно рекомендую попробовать.

System Design

На старших грейдах появляется ещё один тип собеседования - system design. Вам за один час надо спроектировать систему, на продумывание архитектуры которой в реальном проекте вы бы потратили несколько недель. IDEF0, UseCase, ER, C4, DFD, BPMN - забудьте эти страшные слова, тут на них нет времени. Фигак-фигак и в продакшен. Сбор требований -> варианты использования -> системные требования -> проработка -> презентация решения, время пошло. Тут главное побольше баззвордов, строить умное лицо и куда-нибудь воткнуть kafka. Тогда через 40 минут от вас отстанут.

Проверка знаний

Помните, я говорил про 5 этапов. Вы, наверно, подумали, что я преувеличил. Но нет: рекрутер, проверка знаний python, лайв-кодинг, сис диз, софт-скил. Потом ещё звонок на презентацию оффера. Так вот, второй этап - просто фейспалм какой-то. Мало того, что его вполне можно совместить с лайв-кодингом, если не просто кодить, но и обсуждать решение, так ещё и вопросы на нём мягко говоря дурацкие. Примитивные и давно вызубренные. А значит по логике компании, что туда можно отправить мидла, чтобы не терять время сеньоров. Я, конечно, не дон Карлеоне, но мидл просто не сможет оценить знания сеньора. Банально, он не туда смотрит, а самое главное - поверхностно. 

Например, вопрос как измерить время работы программы. Ну, time.time - что сложного. Хотя я бы взял какой-нибудь более подходящий инструмент. Но правильный ответ - использование time.monotonic. Без вопросов - он абсолютно стопудово верный, но мы действительно будем замерять в ночь с 30 июня на 1 июля 2024 года? И монотонное время действительно монотонно равномерно? После уточняющих вопросов, я понял, что собеседник в курсе про монотонное время, но абсолютно без понятия про NTP и високосную секунду.

Ну и опять же - у нас со-беседования, значит, что я тоже могу узнавать уровень того, с кем мне придётся работать. Хотя на одном была сказана фраза "Здесь я задаю вопросы". Отчего-то мне сразу показалось, что мы не сработаемся.

Ветка DevOps/SRE

Я был безработный, времени полно, так что решил пройти собеседования на направление DevOps. Зря что ли курс по linux в местном вузе веду?! И тут процесс мне понравился гораздо больше. Состоял он всего из 2 шагов: общие знания и траблшутинг.

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

Траблшутинг представлял собой ролевую игру. Есть система, пользователи жалуются, что сайт не грузится. Ноута и дашбордов у вас нет, а есть только смышлёный джун, которому можно давать команды что-то сделать или посмотреть. Тут как миниму было всело и максимально приближено к реальной работе. Проблема не сложная, но на дебаг всего час. И научный метод тут проигрывает эмпирическим наблюдениям. У SRE должна быть некоторая чуйка что происходит в системе, которая вырабатывается как раз на разборах инцидентов.

Советы кандидатам

За последние лет пять я прошёл уже несколько сотен собеседований как с одной, так и с другой стороны. Так что несколько лайфхаков:

  • проходите разминочные собесы. Такие, куда в целом не собираетесь. Прокачаете скилл или вдруг что интересное окажется; или вдруг это будет единственное место с оффером. Никогда не знаешь что в коробке конфет.

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

  • возьмите стакан воды. Пейте в любой непонятной ситуации, это хороший и адекватный филлер.

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

  • относитесь легче. Если вас не возьмут, то никто не умрёт. Да, возможно, будет труднее, но через год-два вы даже "спасибо" скажите. Такое отношение поможет немного снять градус скованности.

  • обязательно просите фидбэк. Без обратной связи очень тяжело учиться.

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

Советы интервьюерам

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

Вместо заключения

За свои почти 20 лет в IT я успел поработать во многих типах компаний. В основном это были стартапы или небольшие компании на 20-30 человек. Так вот, собеседования в энтерпрайз разительно отличается от них. У рекрутеров огромный поток вакансий и резюме, так что возможны дикие на первый взгляд варианты. Например, после 7 (семи) успешно (!) пройденных интервью мне сказали, что не смогли найти для меня позицию. WTF?! Но в оправдание могу сказать, что у них потоковый найм. Т.е. они гребут всех, "а там как-нибудь разберёмся". И процессы стандартизированы полностью. Будь вы сеньор в python с 15-летним стажем по рефералке, но всё равно проходите все круги ада этапы.

P.S. Пока писал статью, вспомнился доклад Александра Зизы "Как успешно хантить в никому не понятное место". Там он раскладывает компании по типам, что они могут дать работнику и как каждая из них отбирает себе сотрудников.

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


  1. panzerfaust
    26.07.2024 09:30
    +2

    Тут главное побольше баззвордов, строить умное лицо и куда-нибудь воткнуть kafka. Тогда через 40 минут от вас отстанут.

    Вот да, баззводры тащат. Я как-то ответил, что сначала бы рассмотрел вариант использования RabbitMQ а не Kafka банально потому, что по рэббиту у меня опыта гораздо больше. Ну как я могу сказать, что кафка топчик, если тупо с ней не работал? Интервьюеру это очень не понравилось.

    В другой раз пошел разговор про распределенные БД и consistent hashig. И я упомянул Cassandra, в которой вроде как эта штука чуть ли не из коробки. Интервьюер чуть в ладоши не залопал от слова Cassandra. Ну а что толку, если я с ней не работал и для меня это тупо баззворд?


    1. Gorthauer87
      26.07.2024 09:30
      +1

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


    1. zergon321
      26.07.2024 09:30

      Потому что интервьюэры на этих собесах и сами не шарят за архитектуры. Зато могут иметь опыт разворачивания какого-то говна. Я слышал, на одном собесе по system design обсуждали тупо ковыряние параметров Kafka


  1. atues
    26.07.2024 09:30
    +4

    Работодатели (не буду указывать пальцем кто именно, но таких немало) в курсе, что многие высококлассные разработчики просто психологически не способны лайвкодить? Вот не могут и все - ступор у людей. Из недавнего: приятель, отменно знающий ядро линукса в части многопоточки и планирования на уровне исходников, сам правивший и контрибьютивший в него, не смог пройти элементарного собеседования по C. При том, что знает язык до деталей стандарта. Ну не тот у него характер, не тот психотип. Результат? Конечно, отказали. Хотя на той стороне сидели люди, чьи скиллы в совокупности вряд ли больше, чем у него.
    И знаете, мне таких работодателей ни капельки не жаль. Действуя по шаблону, они упустили главное - нужного человека. Приятель мой нашел работу, если что.
    Работодатели, вы кого ищете? Джуна - да, надо в меру погонять. А сеньора+ для чего? Вы поговорите с ним по-душам. Скорее всего, его опыт совершенно адекватен и возможно даже более чем адекватен для той позиции на которую ищут человека. Какого (извиняюсь) хрена вы требуете написать реализацию B-дерева, когда вся работа, которую вы готовы предложить - элементарный Rest API и перекладывание json-ов?


    1. vfreeeman
      26.07.2024 09:30

      а что за термин такой "перекладывание json-ов" ? без сарказма и иронии. или это не доступно для понимания разработчикам на c#?


      1. panzerfaust
        26.07.2024 09:30
        +6

        Ну это такой тип систем, где у вас с одной стороны апишка рестовая, с другой БД. Вы берете джейсон из апишки, мапите на Entity, Entity пишете в базу. Типичная бесхитростная CRUD-логика, которой в каждом продукте навалом и которую спокойно тащат джуны.

        Но некоторые компании вообразили, что именно их крудошлепка это rocket science, и заставляют заниматься каким-то нерелевантным бредом на собесах.


    1. Dolios
      26.07.2024 09:30

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

      Почему это плохо? Они в итоге закрыли вакансию?

      Вы поговорите с ним по-душам.

      Человек может прекрасно уметь говорить, но не уметь писать код.


      1. atues
        26.07.2024 09:30
        +1

        Почему это плохо? Они в итоге закрыли вакансию?

        Понятия не имею. Я там не работаю. И приятель мой. Что и правильно


        1. Dolios
          26.07.2024 09:30

          Ну, т.е. это просто обида, без желания разобраться?


          1. TyVik Автор
            26.07.2024 09:30

            Внимательнее прочитайте начало треда. Там было "сам правивший и контрибьютивший в него", а вы набрасываете "Человек может прекрасно уметь говорить, но не уметь писать код." Противоречие же?

            Если у кандидата есть активный github, то по нему вполне можно оценить как он кодит. Если у кандидата есть видео выступлений, то по нему понятно как он разговаривает.


            1. Dolios
              26.07.2024 09:30

              "сам правивший и контрибьютивший в него"

              Это он так сказал?

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

              Если у кандидата есть активный github, то по нему вполне можно оценить как он кодит. Если у кандидата есть видео выступлений, то по нему понятно как он разговаривает.

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


          1. atues
            26.07.2024 09:30
            +1

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


            1. Dolios
              26.07.2024 09:30

              Вы написали буквально следующее:

              Действуя по шаблону, они упустили главное - нужного человека.

              Мой вопрос был в том, почему вы решили, что работодатель что-то упустил и что ваш человек был нужный? Какие помойки, к чему эти эмоции, какого конструктива они добавляют в беседу?


    1. TSchmidt
      26.07.2024 09:30

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


  1. Gorthauer87
    26.07.2024 09:30

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


  1. fo_otman
    26.07.2024 09:30
    +3

    Подтверждаю. Желтая компания отказала после 3го этапа собеседований, синяя тоже после 3го, а зеленая - молодцы! - отказали сразу. Всего за месяц было 30+ собесов в самые разные компании. Зп хотел по нижней границе их предложения. Еще около 20 компаний отказали сразу, без собесов. Ощущение, что рынок перенасыщен кандидатами. Если что, у меня 7 лет опыта. 3 года назад взяли через пару дней после активации резюме на hh.


    1. joffer
      26.07.2024 09:30

      как тут не вспомнить - "на рынке дефицит высококвалифицированных низкооплачиваемых кадров" (с) - "вот таких мы и ищем, вот такие люди нам нужны" (с) ))


  1. DenSigma
    26.07.2024 09:30

    Заваливал лайвкодинг.

    Оба раза принимали на работу после простого собеседования и простейшего вопросника по языку.


  1. icecube092
    26.07.2024 09:30
    +1

    просят решить задачки за O(1), но зато наплевав на объём дополнительной памяти

    как-то раз на собесе была такая задачка, я сразу заметил что так нельзя делать и у меня подозрение что работать не будет, ответом было "ну главное по скорости уложиться"
    проверил потом - stack overflow получается на их каноничном решении


  1. fruitella
    26.07.2024 09:30

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

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


  1. venanen
    26.07.2024 09:30

    У меня было одно очень приятное интервью, состоящее всего из одной задачи - написать функцию сортировки массива объектов по переданному ключу (sortBy(array, key)). Сначала проще, потом вопросы, обсуждения, типизация и так далее. То есть это не стрессовая задача, решающаяся человеком с любым уровнем знаний, позволяющая поговорить и про сложность О, и про память, и про саму сортировку, и сразу видно - знает человек что-то или нет. Взял себе на вооружение, тоже спрашиваю теперь ее. За последнее время один сеньор ее в принципе не решил, один не смог базово типизировать, один решал полчаса и решил через штатную сортировку. В связи с чем у меня вопрос - дорогие хабравчане, может все таки не такая простая задача, как мне кажется? (ну по-другому у меня нет вариантов, как сеньор с опытом в 6+лет не может решить задачку уровня джуна)


    1. slonopotamus
      26.07.2024 09:30

      Что значит "отсортировать массив по ключу"? Что есть "ключ"?


      1. venanen
        26.07.2024 09:30

        Писал уже сонный и забыл правильную постановку. Не отсортировать, а вернуть объект с максимальным значением.
        Нужно написать функцию function maxBy(array, key){}
        Пример:
        const costs = [{cost: 100, id: 1}, {cost: 10, id: 4}, {cost: 35, id: 6}]
        maxBy(costs, 'cost') => {cost: 100, id: 1}


    1. venanen
      26.07.2024 09:30

      UPD: не отсортировать, а вернуть объект с максимальным значением