![](https://habrastorage.org/getpro/habr/upload_files/e53/bb5/a9a/e53bb5a9a2eea9269bce6eb060abb516.jpg)
Волею судеб я снова стал ходить на собеседования, и хочу поделиться некоторыми наблюдениями. На этот раз речь про энтерпрайзные компании, в которых должен быть выстроен процесс найма.
Скрининг
Всё начинает с него, и тех-скрининг становится нормой. Рекрутер прям на первом звонке задаёт каверзные вопросы и сверяется со шпаргалкой. Например:
-
как остановить контейнер?
-
неизменяемые типы данных в 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. Пока писал статью, вспомнился доклад Александра Зизы «Как успешно хантить в никому не понятное место». Там он раскладывает компании по типам, что они могут дать работнику и как каждая из них отбирает себе сотрудников.
ссылка на оригинал статьи https://habr.com/ru/articles/829870/
Добавить комментарий