Лучшие практики написания Java и Go приложений под k8s

➡️ вебинар сегодня в 19:00

Разберём:

🟠Что делать, а чего не делать, чтобы приложения чувствовали себя комфортно в k8s
🟠Лучшие практики бесшовного деплоя, чтобы пользователи не заметили
🟠Поддержку настройки приложений на лету
🟠Разделение логики приложения и инфраструктуры
и многое другое.

Приглашенный гость:
Григорий Скобелев, Java Techlead, ведущий подкаста {между скобок}

Ссылка на трансляцию будет в боте. Подключайтесь!

🐈 Мы начинаем! 🐈

Ссылки уже в боте

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

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

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