Как надо (и как не надо) проводить собеседования

Итак, привет, разработчики, инженеры и им сочувствующие!

Сегодня копнем в технические собеседования. Нет, не в те собеседования, когда вас мучают вопросами, чем kubectl apply отличается от kubectl create. А в те, когда вы сами готовы задавать «неудобные» вопросы.

Даже если вы ещё никогда и никого не собеседовали — сохраните этот пост, в будущем пригодится.

За свою карьеру я собеседовал в разных компаниях и на разных грейдах:
🟠Фронтендеров на проекты с vue.js/react
🟠Бэкендеров на php/python/golang проекты
🟠DevOps инженеров на проекты, связанные с (какая неожиданность!) процессами выкатки проектов в production и обслуживания всего этого счастья. Можете написать в комментариях, что DevOps это не должность и не профессия.

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

➡️ Disclaimer: всё, что вы прочитаете дальше — это личные наблюдения и принципы, выработанные с годами. Не претендую на истину в последней инстанции и не гарантирую, что каждый собеседуемый покинет zoom-комнату с чувством глубокого удовлетворения. Но надеюсь, что эти советы помогут сделать процесс найма более эффективным и приятным для всех участников.

Возможно, через N лет окажется, что лучше было делать по-другому.

Итак, у нас есть два глобальных подхода к найму:

🟠 Конвейер имени корпорации.

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

🟠Мы расширяемся, нам нужно еще пару человек.

Нанимают относительно быстро, часто без особой системы. Зато весело, как пытаться задеплоить сложный сервис в production без правильно настроенных liveness проб, потому что часто это сводится к тому, что за 5 минут до собеса вы, после дебага сложной проблемы, быстро ищете статью «Топ-10 вопросов на k8s инженера».

И знаете что? Оба подхода работают! Всегда будут те, кто проскочит мимо фильтров (false positive), и те, кого отсеют зря (false negative).

С подходами разобрались, теперь поговорим про то, как НЕ надо собеседовать (и как надо, если позволяют)

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

Вместо этого, попробуйте вот что:

➡️ Разрешите гуглить! Серьезно.

Важно уметь искать и анализировать информацию. Представьте, что кандидат дебажит сложный k8s-манифест — ему же понадобится документация! И да, AI уже с этим может помочь (а может не помочь). Задавать правильные вопросы, чтобы получать значимые ответы, так же важно, как автоматизировать деплой в 2025.

За последнюю неделю я обращался к внутреннему поиску компании раз 30, не меньше, и не раз и не два просил AI инструмент создать summary конкретных design documents, чтобы понять, что я ищу в том направлении, и не читать десятки страниц вручную. И все это для того, чтобы решить свою задачу, правильная реализация которой зависит от качества документации множества других команд и от взаимодействия с этими командами.

➡️ Не самоутверждайтесь за счет кандидата!
Да, вы знаете, к примеру, что etcd – это распределенное хранилище key-value, а он — нет. Но это не повод для гордости. Вспомните, как сами начинали изучение.

➡️ Давайте честный фидбек (если можете).
Не надо говорить: «Ну так себе!». Лучше укажите на конкретные ошибки и посоветуйте, что подтянуть. Это как чинить CrashLoopBackOff — нужно знать, что сломалось, чтобы его восстановить. А если не вы писалм код, то тут еще неплохо бы уметь внятно донести проблему до разработчиков (читайте: качать софт-скиллы).

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

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

Карьерный эфир сегодня в 19:00 🐈

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

➡️ Сегодня в 19:00 проведу лайв эфир в формате собеседования и покажу наглядно, как это выглядит. Поговорим про удачные и неудачные ответы на вопросы, обсудим ожидания интервьюера и многое другое.

Если хотите потренироваться — присылайте свои резюме через форму, сбор заявок закрываю в 17:00. Всех жду!

Вижу, что бОльшая часть моих подписчиков уже проводит технические собеседования

Это отлично, значит, будем и дальше развивать тему «Как надо и как НЕ надо проводить собеседования» 🔥

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

Напишите в комментариях, с какими сложностями вы сталкиваетесь, когда проводите собеседования? Что хотелось бы обсудить или разобрать?

Ну что, котятки, соскучились по Кириллу Борисову?

Теперь он ведет канал «Путь SRE», в котором:

➡️ публикует полезные материалы для инженеров;
➡️ делится практическими кейсами, инструментами и лайфхаками;
➡️ рассказывает про факапы;
➡️ проводит прямые эфиры, общается с аудиторией и отвечает на вопросы.

Сегодня в 19:00 на канале пройдет прямой эфир, который поможет разобраться — кто, зачем и как спасает продукт от катастроф.

Специальный гость: Вячеслав Федосеев, TeamLead DevOps в «Честном знаке» и автор канала «DevOps Bootcamp». Да будет файт между DevOps и SRE!

Эфир бесплатный, регистрация не нужна. Подписывайтесь на канал и включайте уведомления, чтобы не пропустить. Записи не будет!

🟣 Путь SRE

Ну что, продолжим про собеседования?

Посмотрел комментарии и сообщения в чате, видел упоминания ChatGPT. На самом деле, поймать кандидата, который ничего не понимает, довольно просто, особенно когда речь идет о коде. В кружке объяснил, почему.

В следующей части лонгрида рассказываю про довольно странных кандидатов, которые встречались мне в процессе собеседований ⬇️

Странные кандидаты

А теперь — минутка баек из склепа! Если вы помните, что это, проверьте срок годности таблеток :)

➡️ Преподаватель Go, который забыл Go.

Искали мы однажды сеньора на позицию golang-разработчика. Пришел кандидат, который преподает Go в одной онлайн-школе. Но на достаточно простые вопросы по языку (типа «порядок обхода map» или порядок «горутины и WaitGroup») ответить не смог.

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

Вы же не захотите водить кандидата по коду, объясняя как работают WaitGroup?

➡️ PHP-разработчик.

Другой кандидат, без камеры, не смог даже с поиском ответить на простые вопросы по Symfony. Зато было слышно, как он ищет ответы. Серьезно, после каждого вопроса был слышен стук клавиш.

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

Мораль: собеседование — это стресс, готовьтесь заранее и помните, что все, что вы пишете в резюме, может всплыть! Поэтому следующая часть поста для тех, кто не собеседует, но проходит собеседования.

Как составлять резюме

🟠 Пишите правду, но не забывайте про ключевые слова, потому что ваше резюме сначала проверит машина. Если не забракуют, смотрим дальше.

🟠 Краткость важна, потому что если вам повезло и вы дошли до HR, человек должен сразу увидеть достаточный уровень компетенции и соответствия должности, не тратя время на вчитывание в N страниц текста.

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

🟠 Если вы написали, что «5 лет работал с Redis», будьте готовы рассказать не только про GET и SET, но и про тонкости работы со streams (если использовали) и как оптимизировать работу на больших RPS (pipelining, если работали с ним).

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

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

Не страшно говорить, что с чем-то не работали. Честность ценится, а научиться всегда можно.

На что лично я обращаю внимание на собеседованиях

➡️ Насмотренность и кругозор. Если кандидат не знает/не помнит нюансов использования конкретного инструмента, но может в правильном направлении рассуждать относительно своего опыта, то есть большая вероятность, что за пару запросов в google/ChatGPT он сможет найти ответ, что он и сделает в реальном проекте. Бизнесу важно решать проблемы и получать прибыль, а не нанимать тех, кто может по памяти вспомнить все сложности настройки очередной вундервафли.

В заключение: Собеседование — это двусторонний процесс. Не только компания выбирает кандидата, но и кандидат выбирает компанию (на самом деле кандидат скорее команду выбирает, если речь о больших компаниях). Будьте честны, объективны (на самом деле мы скорее всегда субъективны) и, главное, помните: все мы люди, все мы ошибаемся. Даже при деплое в production. Удачи!

Как связаны k8s и National Security Agency: часть 1
#полезный_материал

➡️ Посмотрим на примере audit policy и seccomp profiles, как можно повысить безопасность кластера.

Второе видео — завтра. Не переключайтесь!

А пока жду ваших вопросов в комментариях ⬇️