И раз уж мы разобрались с онбордингом, предлагаю попробовать пройти первое собеседование 🐈

19 февраля в 19:00 мск я проведу прямой эфир — публичное собеседование на позицию разработчика с сильным уклоном в понимание работы с k8s. Участника выберу среди подписчиков канала.

Хотите потренироваться? Отправляйте заявку и свое резюме через форму, и увидимся в прямом эфире в следующую среду.

➡️ Важное сообщение ⬅️

Сегодня Слёрм и Вячеслав Федосеев запускают новый крутой спецпроект — «Честные вакансии: DevOps Middle».

Это серия вебинаров с экспертами из бигтеха, цель которой — дать зрителям адекватное понимание требований к Middle DevOps, помочь выстроить карьерный трек и легче проходить собеседования.

Стартовая встреча уже через 10 минут!

Приглашенный гость: Владимир Федорков, основатель fournines.ru

На повестке дня:

⭐️ Текущая ситуация на рынке: фриз на найм и увольнения. Как найти работу, и что именно нужно компаниям?

⭐️ Ред флаги для миддлов и джунов на собеседовании.

⭐️ Средняя температура по больнице: требования к middle-специалистам.

Занять место на вебинаре можно через бота. А следить за развитием проекта и расписанием следующих встреч — в канале Вячеслава.

Подключайтесь!

🍀 «Честные вакансии: DevOps Middle»

Привет! Это Маркус 🐈

У кого тоже до сих пор стоит ёлка, лапки вверх! Мне она нравится. Особенно если уронить (это же не production).

Вообще, я к вам с важным сообщением: запись последнего вебинара доступна для просмотра. На нём мой человек вместе с Григорием Скобелевым обсуждали лучшие практики написания Java и Go приложений под k8s.

Посмотреть можно тут:

➡️ YouTube
➡️ VK Видео

Сегодня старт «Kubernetes База»

В ближайшие 6 недель мы будем постепенно раскалывать этот айсберг:
🟣 основы работы с Kubernetes, устройство кластера и отказоустойчивость;
🟣 продвинутые абстракции в Kubernetes;
🟣 DNS в кластере;
🟣 работа с stateful приложениями;
🟣 CI/CD в Kubernetes.

В конце — итоговая сертификация на стенде, где нужно последовательно привести кластер к определенному состоянию — запускать приложения, создавать абстракции.

Присоединиться к потоку можно до 24 февраля. Подробности — по ссылке ⬅️

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

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

Сегодня копнем в технические собеседования. Нет, не в те собеседования, когда вас мучают вопросами, чем 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?