🎭 Провалил собес в топовую ИБ-компанию за 3 минуты

И вот как это было...

---

🔥 Контекст:
Шёл просто “попробовать” без подготовки.
Ну как шёл… бежал с предыдущей работы и в прямом, и в переносном смысле.
Но это уже совсем другая история 😅
О том, что собес будет на английском, узнал… на самом собесе.
Удобных корпоративных материалов на GitHub тогда почти ни у кого не было.
Собесы были очными, в офисе

---

📋 Роковой вопрос:
Интервьюер: "How would you debug a host that you can't connect to?"
Мой мозг: Сейчас покажу экспертность!
Реальность: Epic fail incoming... 🤦‍♂️

---

🚨 Что пошло не так:

🔴 Переусложнение на английском
Я: "I will check network topology first. Then analyze packets. Deep inspection of traffic..."
Интервьюер: "So... you mean ping?" 🤨
Внутренний голос: Чувак, ты забыл про ping! И ещё на английском!

---

🔴 Нервы превращали простое в сложное
Вместо: ssh -v host
Говорил: "I need secure shell. With verbose output. For diagnostic."
Мозг: Герой диагностики… только в своей голове 🦸‍♂️

---

✅ Спасла мышечная память (от полного фиаско 😅)
Интервьюер: "How do you exit vim?"
Руками на пустом столе простучал: Esc → :wq → Enter
Пара движений и он понял, что я реально работаю в терминале 💪
Тело помнит то, что мозг забывает под стрессом!

---

💡 Как бы я ответил сейчас:
🎯 Структурированный подход:
1. ping host - хост жив?
2. telnet host 22 - порт доступен?
3. ssh -v host - где именно падает?
4. Логи: /var/log/auth.log, journalctl
5. Сеть: netstat, ss, tcpdump
Просто, логично, по шагам

---

🎯 Для DevOps/SRE/SysAdmin - мини чек-лист подготовки

📖 Техническая база:
* Troubleshooting от простого к сложному
* Базовые команды диагностики наизусть
* Реальные кейсы из практики

🗣 Английский для собесов:
* "First, I would..." — заготовка для начала
* Технические термины без переусложнения
* Практика объяснений на камеру

🧘‍♂️ Психология:
* "Не знаю" > неправильный ответ
* Структура важнее красивых слов
* Спокойствие > показушность

---

🚀 Что изменилось за годы:
Тогда - ноль ресурсов, только книги и гугл.
Сейчас - GitHub с готовыми шпаргалками, практические курсы, менторы.
Подготовиться можно за вечер - главное, знать как.

---

📨 Собес скоро?
🎯 Провёл 100+ интервью и сам прошёл немало — знаю обе стороны.
🎯 За 1–2 часа разберём твой подход, закроем пробелы и отработаем ответы.
Напиши @devitway_pavel и уже в понедельник выйдешь на собес спокойно.
Пара слотов на выходные ещё есть.

---

💬 А у вас?
🤔 Какая самая глупая ошибка была на собесе?
🏆 Помните момент, когда мышечная память спасала?
👇 Поделитесь лучшие истории разберём в следующих постах!

---
#DevITWay #DevITWay_карьера #DevITWay_senior #SFIA #InterviewFails #DevOps #SRE #TechInterview

🤖 "SFIA-бот запущен! 10 минут → результат → план роста"

🚀 От теории к практике - узнайте свой точный уровень

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

Решение: SFIA Assessment за 10 минут → точный анализ → персональный план.

---

🔥 Что получаете за 10 минут:

🎯 Ваш точный SFIA-уровень (1-7)
📊 Зарплатная вилка для вашего уровня
💪 Сильные стороны и точки роста
📋 Персональный план развития на 6 месяцев

🎁 Бонус: бесплатная консультация с экспертом (40 мин)

---

⚡️ Как работает:

1️⃣ Запускаете → @devitway_sfia_bot
2️⃣ 10 минут теста → честные ответы на 20 вопросов
3️⃣ Получаете анализ → уровень + план + рекомендации
4️⃣ Одна кнопка → записываетесь на бесплатную консультацию

---

💡 Примеры результатов по уровням:

🎯 Level 1-2 (до 35%): план изучения основ + бесплатная консультация
🚀 Level 2-3 (35-55%): стратегия роста до Middle + карьерное планирование
🏛 Level 3-4 (55-70%): roadmap до Senior + развитие лидерских навыков
👔 Level 4-5 (70%+): путь к Tech Lead + стратегическое мышление

---

🚨 Два типа DevOps через месяц:

🔴 "Почитаю еще статейки..."
→ Остается гадать о своем уровне

🟢 "Прохожу assessment сейчас"
→ Знает точный уровень + имеет план

---

🎯 Запускайте прямо сейчас:

👇 10 минут → точный SFIA-уровень → план роста:

@devitway_sfia_bot

💰 Стоимость: бесплатно
🎁 Бонус: консультация с экспертом
⏱️ Время: 10 минут честных ответов

---

💪 Профессиональный рост = честная оценка + план действий

Не ждите понедельника.
Не ждите мотивации.
Действуйте сейчас.

💬 Вопросы: @devitway_pavel

#карьера #ai

---

🚀 Запустить бота

Держите краба!
Лучи тепла из Крыма всем, где "прохлаждаться" буду ещё некоторое время, не теряйте, скоро будут обновления 😜
#DevITWay #DevITWay_лайф

🎲 "Лотерея собеседований", или почему интервью в IT напоминает экзамен по билетам и как перестать чувствовать себя студентом на пересдаче

Часть 1: Проблема

Классика жанра:

Ты подготовил резюме, отправил отклик на «инженера по внедрению» (Linux + Docker + MySQL).

Ждешь приглашения на техническое собеседование с командой.

📞 Звонит HR: «Привет! Давайте сразу немного поговорим»

👉 Первый вопрос: "А для чего нужны WAL-файлы в PostgreSQL?"
👉 Второй: "Что показывает Steal Time в top?"
👉 Третий: "ArgoCD vs Flux - что выберешь?"

Ты растерянно отвечаешь, а про себя думаешь:
«Это что вообще за лотерея?! Я готовился совсем к другому...»

---

🎭 Ожидание vs Реальность

Ожидал:
• Вопросы про MySQL
• Практику Docker
• Базовый Linux

Реальность:
• PostgreSQL WAL
• Метрики виртуализации
• Kubernetes GitOps
• Вопросы из топ-списков в интернете

Каждое собеседование как экзамен по билетам. Угадал номер - прошёл. Попался соседний - «недостаточно экспертизы».

⚠️ Даже если вакансия про MySQL, вопросы про PostgreSQL или Linux-базу проверяют широту системного мышления и фундаментальные навыки.

---

🤯 Почему так происходит

1. Рулетка интервьюеров
• Переподготовленный техлид: шпарит топ-100 вопросов из интернета
• Уставший руководитель: листает резюме прямо во время созвона

2. HR работает по чек-листам от техлидов
• «fstab» и «awk» в DevOps-вакансиях — не злой умысел, а вопросы вырваны из контекста
• HR знает что спросить, но не всегда понимает зачем

3. Проверка кругозора vs практические задачи
• WAL PostgreSQL - не рандом, а проверка широты понимания СУБД
• fstab для Kubernetes-позиции - выглядит лишним, но как проверка Linux-базы логично
• Порою связь с реальной работой часто неочевидна

---

🩺 Пример: Steal Time

Новичок: «Это время ожидания CPU»

Профи:
«Steal Time - это процент времени, когда VM ждёт освобождения CPU у гипервизора. Значение >10% сигнализирует о проблемах на уровне хостера. Но низкий Steal Time не гарантирует нормальную работу — могут быть I/O wait, нехватка памяти или блокировки внутри приложения».

Один неожиданный вопрос → паника → все ответы кажутся хуже.

---

#DevITWay #DevITWay_карьера #DevITWay_middle #CareerTrap #DevOps #Собеседования

🎲 "Лотерея собеседований"

Часть 2: Решение

🚀 Как превратить лотерею в игру по правилам

1. Карта знаний
По каждой технологии из резюме сделай карту → «Docker: основы, сеть, хранилище, безопасность, отладка».

Так у тебя всегда есть скелет ответа.

2. Соседи по стеку
Если в вакансии есть MySQL → знай отличие от PostgreSQL и хотя бы базу про Redis / ClickHouse.

3. Шаблон ответа на подковырки
Каверзные вопросы — это не всегда ловушка. Часто это проверка глубины понимания.

Вот структура, с которой ты не растеряешься:
Определение — что это такое простыми словами
Контекст применения — где это реально используется
Связь с другими компонентами — как это вписывается в систему
Практический кейс — когда ты это применял
Ограничения / альтернативы — где не работает, чем можно заменить

🧠 Такой ответ показывает не только знание, но и инженерное мышление. Он особенно силен в ответ на вопросы типа:

«А почему вы выбрали именно это решение?»
«А как это работает внутри?»
«А что если масштабировать?»

✍️ Пример до/после

Вопрос: Что такое reverse proxy?

❌ Ответ без структуры:
Ну... это типа прокси, только наоборот, он снаружи принимает запросы и перенаправляет.

✅ Ответ со структурой:

Определение: Reverse proxy — это сервер, который принимает запросы от клиентов и пересылает их на внутренние серверы.
Контекст применения: Используется в балансировке нагрузки, кэшировании, SSL-терминации.
Связь с другими компонентами: Обычно стоит перед приложениями и взаимодействует с ними по HTTP/gRPC. Может работать в связке с firewall, WAF, ingress-контроллерами.
Кейс: В проекте с Nginx мы настроили reverse proxy, чтобы разруливать 3 backend-сервиса по URI.
Ограничения: Может стать bottleneck'ом. Альтернатива — service mesh или L4 балансировщики, в зависимости от задач.

4. Честные ответы: таблица поведения
❌ «Не знаю» — минус
➖ «Не работал, но понимаю концепцию» — нейтрально
✅ «Не применял напрямую, но решал похожую задачу вот так…» — плюс

5. Изучите компанию заранее
Посмотрите их tech stack в других вакансиях, статьи на Хабре, выступления на конференциях — это подскажет вектор вопросов

Пример: Компания пишет про Kubernetes, а спикеры выступают про Service Mesh → готовьтесь к вопросам про Istio/Linkerd

6. Техника обратного вопроса
«С этим конкретно не работал. А у вас эта метрика критична? В каких сценариях?»

Переводите разговор в диалог вместо экзамена (работает в продуктовых командах, в корпорациях могут ждать формальные ответы).
---

#DevITWay #DevITWay_карьера #DevITWay_middle #CareerTrap #DevOps #Собеседования

🎲 "Лотерея собеседований"

Часть 3: Результат

📊 Кейс Алексея

Было:
• Каждое собеседование — новые вопросы
• Паника на подковырках
• Чувство «недоучки»

Стало (3 недели подготовки):
• Карта знаний по стеку
• Соседние технологии разобраны
• Отработаны 20 вопросов типа Steal Time/ LA / отличия Nginx от HAProxy
• На собеседованиях отвечает уверенно и уточняет про бизнес-контекст

---

💡 Главное

Собеседование ≠ лотерея.

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

90% тем можно предсказать, конкретные формулировки — нет

🎯 На собеседовании побеждает не тот, кто выучил все ответы, а тот, кто умеет связывать факты и рассуждать как инженер.

---

🤖 Хотите персональный разбор вашей ситуации?

Запишитесь на бесплатную 40-минутную консультацию:
• Разберем ваше резюме и найдем слабые места
• Составим план подготовки под ваш уровень
• Определим технологии для углубленного изучения

Или свяжитесь напрямую: @devitway_pavel

Дополнительные услуги:
• Составление резюме под конкретные вакансии
• Подготовка к техническим собеседованиям
• Менторство по развитию в DevOps

---

А у тебя было такое, что собеседование превращалось в экзамен «угадай билет»? Какие вопросы-подковырки запомнились? Делись в комментариях 👇

#DevITWay #DevITWay_карьера #DevITWay_middle #CareerTrap #DevOps #Собеседования

🗺 В DevOps есть три пути обучения. Два из них в тупик.

1️⃣ Курсы → pet-проекты.
На собесе это = «расскажите про прод». Тишина.

2️⃣ «Внутрянка» компании.
Легаси, костыли, процессы «начальника начальников». Всё кривое, но работает.
Ты учишься чинить костыли вместо того, чтобы расти.

3️⃣ Система.
📊 Матрица компетенций
🎯 Roadmap от простого к сложному
🛠 Практика в окружении, похожем на прод

Я выбрал третий путь и собрал свой DevOps roadmap: от трёхзвенки на Proxmox → до микросервисов в Kubernetes.
Каждый шаг = конкретный скилл, который можно показать на деле.

📌 Завтра выложу карту развития.

А ты сейчас где: курсы, внутрянка или система?

👨‍💻- курсы
🙈- внутрянка
🤩- система

#мышление #devops

📍 Обещал — выполняю. Карта развития готова.

Вчера спросил: где вы сейчас?
👨‍💻 Курсы — 4 голоса
🙈 Внутрянка — 3 голоса
🤩 Система — 0 голосов

А где системный подход? Где шаги, которые реально двигают вперёд?

🗺 DevOps Roadmap 2025 — меняем ситуацию.

Не хаотичное «Docker по кусочкам», а концентрические слои компетенций:

1️⃣ Основы — Linux, сеть, Git
2️⃣ Автоматизация — Docker, CI/CD, IaC
3️⃣ Observability — Prometheus, Grafana, ELK
4️⃣ Kubernetes и оркестрация
5️⃣ Production-ready — Security, HA, DR

📋 Чем этот roadmap отличается от остальных:

✅ Рекурсия Парето — сначала 20% самых важных навыков на этапе
✅ T-shaped профиль — широко понимаешь, глубоко знаешь одну область
✅ Проверочные вопросы — можешь ли за 2 минуты понять, что с сервером?
✅ Системная логика — каждый слой опирается на предыдущий

📖 Практическое руководство по развитию системных компетенций:
👉 https://telegra.ph/DevOps-Roadmap-2025

Время перестать учиться хаотично. Начинай строить систему.

#мышление #devops

💡 Хотел поменять лампочку, а пришлось чинить машину

🎭 Знакомая ситуация?
Собираешься сделать простое действие, а оно тянет за собой цепочку задач. В итоге "лампочка" так и не поменяна 🤦‍♂️

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

📉 Нет алертов → проблемы ловишь глазами
📉 Нет дашбордов → ищешь вслепую
📉 Нет метрик → не понимаешь, что реально тормозит

👉 Поэтому написал статью про наблюдаемость и дашборды: разобрал методы USE, RED, Golden Signals, уровни метрик (от бизнеса до «сыра») и примеры панелей.

📊 Там всё: от CPU и saturation до DAU/WAU и конверсий.

🚀 Если ты тоже не хочешь чинить машину, чтобы вкрутить лампочку - читай статью:
Стратегии наблюдаемости и примеры дашбордов

#кейс #devops

🛠 Почти месяц тишины, но инфраструктура не ждала

Сегодня показываю, что построено за месяц.
Запустил первый набор DevITWay Academy:
6 студентов, 16 недель, 4 модуля.

---

🏗 Что уже готово:
⚙️ FreeIPA — централизованная авторизация
(LDAP + Kerberos + DNS в одном месте)
📋 GitLab — эпики, задачи, code review
📚 BookStack — база знаний и документация
🌐 Guacamole — браузерный доступ
(студенту не нужен VPN или SSH-клиент)
🔐 SSO — один логин на все системы
(Firefox с Kerberos — отдельная история)
🤖 OpenWebUI + Qwen3 — свой AI-ассистент

---

💎 Главная фишка:
У каждого студента:
- Свой изолированный VLAN
- Свой jump host
- Nested Proxmox — гипервизор внутри гипервизора
Зачем?
Чтобы студент мог:
✅ Создавать подсети
✅ Поднимать ВМки под монолит
✅ Переходить к трёхзвенке
✅ Мигрировать в Kubernetes
Не игрушечный Docker Compose.
А эволюция инфраструктуры условного стартапа "Брусника" (учебный проект для работы с биржей).

---

📊 Что дальше:
Сейчас студенты настраивают свои изолированные контуры.
Дальше — от монолита до микросервисов за 4 месяца.
📌 На следующей неделе:
Архитектура + скриншоты того, как студент попадает в песочницу за 30 секунд.

---

❓ А ты помнишь свой первый «ад в настройке окружения»?

#кейс #devops

🗡 Два вида искусства прохождения собеседований

Попасть на собес — как вытащить катану из ножен.
А пройти — значит одним движением разрезать лист бумаги.
Всё решает точность и подготовка.

Работал в FAANG или других топовых компаниях? Отлично — твой опыт откроет двери.
А если весь опыт — это легаси, болото и "мы тут так делаем уже 10 лет"?

---

⚔️ Что делать, когда спрашивают: "Расскажите, что вы делали"

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

Винить работодателя — слабая стратегия.
Если нет практики — получи её.

---

🎯 Что это значит конкретно:

• Собери CI/CD пайплайн для деплоя Docker-контейнеров — даже на VPS за $5
• Автоматизируй через Ansible настройку сервера, бэкапы, мониторинг
• Подними Kubernetes (хотя бы K3s) и задеплой приложение через Helm
• Всё оформи на GitHub с README — это твоё портфолио

На собесе говори не "у нас было", а "я сделал".
Не "админы настраивали", а "я настроил — и вот почему".

---

💡 Лайфхак:

Собеседование начинается не в Zoom, а в тот момент, когда ты решаешь получить недостающий опыт сам.

Интервьюер видит разницу между тем, кто "работал с Docker" (видел в проде) и тем, кто "развернул инфраструктуру в Docker" (понимает, почему и как).

---

🎓 Хочешь не просто знать, а уметь?

🤖 Пройди SFIA Assessment и узнай свой текущий уровень:
@devitway_sfia_bot — бесплатная оценка + консультация

🚀 DevIT Academy — обучение на настоящей enterprise-инфраструктуре:
• Персональные VLAN на Proxmox (>120 CPU, >1TB RAM)
• AI-ассистент Qwen 3 Coder на собственном железе
• От монолита до Kubernetes — эволюционный подход
• Портфолио на GitHub для собесов
• Менторы с продакшн-опытом

Не просто курс — реальная практика на production-инфраструктуре.
Подробнее: https://devitacademy.com/

---

🤔 А вы как прокачиваете навыки вне работы — пет-проекты 🔥, стажировки 😎 или open source 👍?
Делитесь в комментах — посмотрим, какие стратегии реально работают.

---

#DevITWay #career #interview #tips #практика #DevOps #петпроекты #SFIA

---

🤔 "Почему софт-скилл интервью решает 50% найма"

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

Что проверяют:

🤝 Культурное соответствие (50%) - впишешься ли в команду?
🚩 Красные флаги (30%) - токсичный? Сбежишь через месяц?
🎯 Мотивация (20%) - зачем тебе эта работа?

---

📖 История:

Алексей на собесах отвечал: "начальник строгий, задачи скучные".
Банк подумал: уйдёт через месяц, будет поливать грязью компанию.

Переформулировал: "Проект заморожен из-за экономики. Перехожу в компанию с активным DevOps".
Результат: оффер в телекоме.

Что изменилось: Убрал негатив, показал фокус на будущее.

---

🔥 Топ-3 вопроса:

1️⃣ "Расскажи о себе"

❌ "Родился, учился, работал..."
Хронология жизни не интересна

✅ "Год в банке системным админом. Видел, как ручные деплои тормозили команду. Прошёл DevOps, строил CI/CD с K8s. Ваша миграция в K8s то, чем хочу заниматься"
Структура: откуда → почему DevOps → зачем им

📌 Структура: 2 минуты, 4 блока по 30 секунд

💡 РФ-специфика: В банках/телекомах (Сбербанк, МТС) спрашивают "как ваш опыт поможет нам". Изучи вакансию на hh.ru заранее.

---

2️⃣ "Почему ушёл?"

❌ "Менеджмент идиотский, коллеги тупые"
✅ "Банк под санкциями, сократили отдел. Перешёл в DevOps"

💡 Варианты:

📦 Стартап:
✅ "10 человек, опыт со всем стеком. Хочу в enterprise с процессами"

⏳ 5+ лет на месте:
✅ "От админа до старшего инженера. Следующий шаг - K8s. У нас монолит, миграции нет"

🔄 Часто менял:
✅ "Понял: админка не моё. Год DevOps в стартапе. Готов к стабильности"

💼 Уволили:
✅ "Реструктуризация. Прошёл переподготовку, собрал портфолио"

Правило: Факты без эмоций, фокус на будущее

---

3️⃣ "Почему DevOps?"

❌ "Хорошие зарплаты, модно"
✅ "Видел, как ручные деплои тормозили. Начал с Docker → CI/CD → K8s. Нравится стык разработки и инфраструктуры"

📌 Правило: Искренний интерес + конкретный триггер

---

💡 Лайфхак: Софт-скилл интервью начинается, когда готовишь ответы.

🤖 Узнай свой уровень: @devitway_sfia_bot

#DevITWay #собеседование #карьера

✨ "Как правильно отвечать на вопрос о конфликте с помощью STAR-метода - структура, которая работает"

На собесе вопрос: "Расскажи о проблемах во время релиза"

90% кандидатов:
"Ну, у нас собираются... Опрашивают, я сообщаю... Потом решили..."

Интервьюер думает: "Хаос. Никакой структуры. Как он будет разруливать проблемы в продакшене?"

---

⚡️ STAR-метод — твоя структура для любого поведенческого вопроса

📋 Сохрани эту карточку:

┌───────────────────────────────────┐
  S - СИТУАЦИЯ (что было)           
  "Команда спорила Jenkins vs       
   GitLab CI. 2 дня на выбор"       
└───────────────────────────────────┘
              ↓
┌───────────────────────────────────┐
  T - ЗАДАЧА (что нужно сделать)    
  "Выбрать инструмент, иначе        
   не начнём проект"                
└───────────────────────────────────┘
              ↓
┌───────────────────────────────────┐
  A - ДЕЙСТВИЯ (что ты сделал)      
  "Матрица критериев → оценка →     
   голосование на основе данных"    
└───────────────────────────────────┘
              ↓
┌───────────────────────────────────┐
  R - РЕЗУЛЬТАТ + УРОК              
  "Выбрали GitLab. Метод теперь     
   используем для всех споров"      
└───────────────────────────────────┘

💡 Пример использования STAR-метода

⚡️ STAR делает любой твой ответ структурированным и чётким

---

📖 Пример из жизни

Тимур на собесе в крупной корпорации:

❌ "Pod не запускался. Гуглил, смотрел логи, починил"
→ Хаос, нет структуры

✅ "Контейнер падал в CrashLoopBackOff (S). Нужно было починить за 2 часа (T). Проверил конфигурацию → нашёл проблему с подключением хранилища → неправильное имя класса хранилища → исправил (A). Контейнер запустился, добавил проверку в чек-лист команды (R)"
→ Системный подход, работа под давлением

Результат: оффер 🎉

---

🎯 Где применять STAR-метод

🤝 Конфликт в команде
Например: конфликт из-за выбора решения по CI/CD (Jenkins vs GitLab). Покажи, как организовал процесс выбора на основе данных

💻 Сложная техническая проблема
Например: продакшн-инцидент, когда нужно восстановить сервис без потерь данных. Покажи системный подход к отладке

📋 Работа с критикой
Например: на code review указали на проблемы с производительностью. Покажи, как исправил и оптимизировал код

⚠️ Ошибка и как исправил
Например: баг в конфигурации приводил к сбоям на проде. Расскажи, как нашёл причину, исправил и добавил автоматические проверки

---

💡 Для российских компаний: В банках/госкомпаниях несколько этапов собесов с разными людьми. STAR помогает каждому интервьюеру понять твой подход - структура запоминается лучше хаоса.

---

🚀 Готов к собеседованиям?

Пройди SFIA Assessment, чтобы составить персональный план подготовки и почувствовать уверенность на собеседовании!

👉 @devitway_sfia_bot

Скоро новые возможности 😉 следите за обновлениями
#DevITWay #собеседование #STAR

📌 "Твои вопросы работодателю (без них не возьмут)"

❗️ Фраза "Есть вопросы к нам?" — НЕ формальность.

Если отвечаешь «Нет» - для многих это красный флаг.

Интервьювер думает:
«Не интересуется. Пойдёт куда угодно. Не выбирает, соглашается.».

---

📖 История из практики

Кандидат прошёл технику идеально.

Финальный вопрос: "Есть вопросы к нам?"
Ответ: «Нет, всё понятно, спасибо».

Результат: отказ.
Комментарий: «Сильный кандидат, нулевая мотивация, ему будет скучно у нас».

---

Почему так происходит:

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

---

Что проработать для увеличения шанса:

На следующем интервью спроси:
- как устроен онбординг
- какой стек и мониторинг
- как команда делится знаниями

---

💬 Что спрашивать (и зачем)

1️⃣ 👥 Команда

"Как проходит типичный день DevOps?"
→ Плановая работа или постоянные пожары

"Какого размера команда? Как распределены роли?"
→ Часть команды или «единственный DevOps на всё»

"Есть ли наставник? Какой опыт у команды?"
→ У кого учиться и как быстро расти

---

2️⃣ ⚙️ Технологии и процессы

"Какие технологии сейчас в проде? Что планируете менять?"
→ Легаси или современный стек

"На чём CI/CD?"
→ GitLab / Jenkins / кастом или деплой по ssh «в 3 ночи»

"Есть ли IaC — Terraform / Ansible?"
→ Автоматизация или «кликаем в GUI»

💡 Реалии РФ: Zabbix, GitLab/Jenkins, самописные пайплайны.
Вопросы про это показывают, что ты понимаешь рынок.

---

3️⃣ 📈 Рост и развитие

"Есть ли обучение или бюджет на сертификаты?"
→ Растят людей или нет

"Как выглядит путь от джуна до мидла?"
→ Есть ли прогнозируемый рост

---

4️⃣ 🚩 Риски (вежливо)

"Почему открылась позиция?"
→ Рост команды или текучка

"Как устроен on-call? Часто ли бывают ночные вызовы?"
→ Зрелый алертинг или хаос

---

💡 Зачем задавать вопросы

✓ Показываешь мотивацию
✓ Оцениваешь компанию — ты тоже выбираешь
✓ Снимаешь риски — заранее понимаешь, куда идёшь

---

❌ Антипример

"Выдают ли маки? Сколько отпуск? Можно только удалёнку?"

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

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

---

📌 Главное правило

На собеседовании выбирают оба.

А хорошие вопросы — твой инструмент показать уровень и осознанность.

---

🚀 Готовься системно

Пройди SFIA Assessment — определишь уровень и получишь персональный план подготовки.

👉 @devitway_sfia_bot

#DevITWay #собеседование #карьера

🔥 Тебя зовут, но место ещё тёплое. Идти или разворачивать?

Бывает оффер на столе, стек норм, деньги норм, а внутри свербит: «Подвох?»
Ты улыбаешься, говоришь «спасибо за доверие», и всё равно ощущение, что что-то не так.

И это не паранойя.
Это инстинкт самосохранения.

---

🚩 Когда лучше притормозить

1) «Мы ищем замену, но не можем сказать кого»
Значит, ушли не очень красиво. Конфликт? Выгорание? Токс? Молчат – уже ответ.

2) Слишком быстрое «подходишь!»
Ещё не спросили про стек, а уже: «Когда выйдешь?»
Так делают, когда горит или никто не держится.

3) Собеседующие путают роль и задачи
У каждого своё видение, зачем ты нужен. На месте будет ещё веселее.

4) Ты наследуешь долги
«Тут задачки, которые надо было вчера».
Беги, пока не стал пожарным по умолчанию.

5) Интервью ради галочки
Ты приходишь, чтобы кто-то закрыл KPI по собесам, а не чтобы тебя реально нанять.
Я сам сидел на таких: по резюме видно мискаст, все понимают, но очередь дошла, надо отстреляться.

---

🟢 Когда идти можно, но с открытыми глазами

* Честно рассказали, почему человек ушёл
* Дали познакомиться с командой
* Показали продукт, а не только «красивый питч»
* У ожиданий есть метрика успеха на 3 месяца
* Руководитель знает, зачем ты ему

Прозрачность вместо «просто поверь».

---

❓Вопросы, которые ставят всё на место

Задай спокойно и уверенно:

* Кто делал эти задачи до меня и почему его больше нет?
* Какие 3 главные проблемы мне нужно закрыть, чтобы вы сказали: «Он справился»?
* Сколько людей пришло / ушло за год в команде и почему?
* Какие процессы живые, а какие только «в Confluence»?

После этих вопросов маски обычно падают сами.

---

🎙 Две мини-истории из реальности

🟥 «Галочный» собес
Сижу, слушаю кандидата и понимаю: совсем не наш профиль.
Но регламенты сказали «посетить».
Все знают, что не возьмём, но конвейер должен крутиться.
В итоге я потом сам «выхватывал» толковых к себе, если видел потенциал.

🟥 «Скиловой, но не к нам»
Коллеге после выключения записи говорят:

«Ты классный, но вакансий в нашей команде нет»
Звучит абсурдно? На самом деле – честно.
Хуже, когда берут «потому что надо закрыть слот», а потом делают пешкой в чужой игре.

---

🎯 Главное

Идти – это нормально.
Главное – понимать, куда.

Не позволяй собой затыкать дыру, которую кто-то оставил, хлопнув дверью.

Вопросы – это зрелость.
Сомнения – это опыт.

Если внутри щёлкает «что-то не так» – прислушайся.
Это твой лучший софт-скил.

---
#DevITWay #DevITWay_карьера #CareerTrap #DevOps #Собеседования

💀 "Open Source умер". Или просто повзрослел?

А вот по себе знаю:

5 лет назад я ставил Grafana, Nexus, MinIO –
всё работало «из коробки», интерфейс удобный, документация понятная.

2025: те же инструменты, но:
• Grafana – базовый интерфейс есть, но всё для команд → Enterprise
• Nexus Repository – OSS версия ограничена, управление ролями и безопасность → Enterprise
• MinIO – AGPLv3, коммерческий продакшн теперь де-факто лицензируемый

Первая реакция: "Нормально же ведь сидели работали!? Чего началось-то?"
Вторая (спустя время): "А как иначе?"

---

Что мы привыкли считать OSS

✅ Бесплатный
✅ С удобным интерфейсом
✅ Готовый к боевому использованию
✅ "Поставил и забыл"

Это была иллюзия 2010-х, когда:
• Рынок был маленьким
• Облачные сервисы только развивались
• Коммерциализация казалась далекой

---

Что есть сейчас (реальность 2025–2026)

⚠️ Open Core (ядро бесплатно, всё полезное – платно)
⚠️ Интерфейс урезан или полностью отсутствует
⚠️ Community Edition = для тестов и экспериментов
⚠️ Enterprise-only функции = для прода

И это не жадность разработчиков.
Это экономика выживания.

---

💡 Правда жизни

"Open Source" не значит "бесплатно для бизнеса".
Это значит "открытый исходный код".

Автор может:
✅ Открыть код
✅ Поставить условия использования
✅ Зарабатывать на своём труде

И это нормально.

---

🛠 Инженерные приметы

Раньше (2010-е):

OSS проект → Пользователь ставит сам
→ Платит за поддержку/консалтинг
→ Автор зарабатывает

Сейчас (2020-е):

OSS проект → AWS/Google берут код
→ Продают как облачный сервис с управлением
→ Зарабатывают миллиарды
→ Автор получает лайки на GitHub 

Пример Elastic:
• 2019: AWS запустил OpenSearch (форк Elasticsearch)
• AWS зарабатывает миллиарды на чужом коде
• Elastic меняет лицензию на SSPL
• Сообщество: "Elastic предали OSS!"

Вопрос: а как должен был поступить Elastic? Работать бесплатно, пока AWS забирает рынок?

---

Что изменилось для DevOps

Плохая новость:
Эпоха «скачал, поставил, забыл» закончилась.

Хорошая новость:
Это заставляет думать об архитектуре, а не о конкретном инструменте.

Инженерные приметы:

❌ Не полагайтесь на «бесплатность» OSS в долгосрочной перспективе
✅ Проектируйте так, чтобы можно было заменить инструмент
✅ Читайте лицензии (да, скучно, но важно)
✅ Держите стратегию миграции в запасе

---

Примеры изменений инструментов (2025)

* Redis: BSD → больше не OSI open source, source-available + enterprise
* MongoDB: AGPL → SSPL (для защиты от облачных провайдеров)
* Terraform: MPL 2.0 → BUSL 1.1 → OpenTofu форк
* Grafana: Apache 2.0 → AGPL + Enterprise UI
* MinIO: Apache 2.0 → AGPLv3 + коммерческая лицензия
* Nexus Repository: OSS ограничен, управление ролями и безопасность → Enterprise

Паттерн: Успешный OSS → Облачные компании забирают рынок → Автор меняет лицензию

---

📌 Мораль

Мы вошли в эпоху post-open-source.
Код открыт, модель – коммерческая.

Это не плохо.
Плохо делать вид, что ничего не изменилось.

Хороший DevOps в 2026 –
это не тот, кто верит во «всё бесплатно»,
а тот, кто готов платить или мигрировать.

Инструменты меняются. Архитектуры остаются.

---

💬 Вопрос к вам:

Сталкивались с ситуацией, когда OSS-проект вдруг стал платным?
Как решали: платили, мигрировали или форкали?

Напишите в комментариях – интересно узнать ваш опыт!

➡️ Среда: «5 паттернов, как OSS медленно становится неудобным»

#мышление #devops

💀 5 механизмов деградации OSS

В понедельник было:
«Open Source повзрослел».

Сегодня – как именно.
Пять механизмов.

---

1. Закрытие функций

Функция была бесплатной.
Добавили проверку лицензии.
Один if – и функция платная.

• Grafana: разграничение прав → Enterprise
• GitLab: расширенная синхронизация LDAP → EE
• Nexus: сканирование уязвимостей → Pro

---

2. Смена лицензии

Лицензия становится жёстче.

• MinIO: Apache → AGPL
• Terraform: MPL → BUSL → форк OpenTofu
• Redis: BSD → «код открыт, но не свободен»

---

3. Контроль сборок

Код открыт.
Готовых релизов – нет.

MinIO:
• сообщество – исходники
• коммерция – готовые сборки

Итог:
• своя сборка
• свой конвейер
• своя ответственность

---

4. Деградация интерфейса

Интерфейс формально есть.
Пользы – почти нет без коммерческой версии.

MinIO:
• администрирование – ограничено
• мониторинг – ограничен
• командная строка – осталась

---

5. Победитель становится драконом

Проект победил монополию.
Стал стандартом.
Потом – бизнесом.
Потом – новым драконом.

Облака

Код берут.
Сервис продают.

• Elasticsearch → OpenSearch
• Elastic → смена лицензии
• MongoDB → смена лицензии

Корпорации

Проект покупают.
Приоритеты меняются.

• MySQL → Oracle
• Java → Oracle
• Kafka → рост влияния IBM через Red Hat

Kafka назван в честь писателя о бюрократии.
Ирония получилась точной.

---

📌 Итог

Цикл всегда один:

1. Проект ломает старую монополию
2. Становится массовым
3. Контроль уходит корпорациям или облакам
4. Автор защищается лицензией
5. Сообщество возмущается

Это не про жадность.
Это про конфликт интересов.

Сегодняшний освободитель – завтрашний тиран.

---

➡️ Пятница: «Чеклист оценки Open Source перед внедрением»

💬 Видели, как проект проходил этот путь?


#мышление #devops

🎯 Чеклист перед внедрением OSS

Как не попасть в ловушку.

---

А вот по себе знаю:

Раньше выбирал инструмент так:
• Нашёл на Хабре
• Поставил за вечер
• Заработало - отлично

2020+:
• Поставил MinIO
• Через год AGPLv3
• Через два - интерфейс деградировал
• Спасибо за рыбу - мигрируем

Просчитался, но где? Можно было заранее понять?

---

📋 Чеклист перед внедрением

Лицензия

• AGPLv3 / SSPL / BUSL → юристы нервничают
• Apache / MIT / BSD → спокойнее
• Менялась за 3 года? → будет ещё
• Один гигант контролирует? → завтрашний дракон

---

Управление проектом

• Все разработчики из одной компании → риск
• Проект под фондом (Apache, CNCF) → безопаснее
• Недавнее поглощение (IBM/Oracle) → жди изменений
• Несколько спонсоров → стабильнее

---

Коммерческая версия

• Все нужные функции только в коммерции → проблема
• Бесплатная версия деградирует (функции уходят) → тревожный знак
• Интерфейс только в коммерции → команде неудобно
• Бесплатная версия полнофункциональна → хорошо

---

Зрелость

• Проект < 2 лет → рано для production
• 3-10 лет + регулярные релизы → норм
• Нет альтернатив → привязка к поставщику
• Есть 2-3 здоровых альтернативы → можно мигрировать

---

Технические риски

• Только исходники, нет готовых сборок → барьер
• Командная строка для всего → команде неудобно
• Интерфейс деградировал → будет хуже
• Проприетарный протокол → нельзя мигрировать
• Готовые бинарники / Docker → удобно
• Совместимость со стандартами (протокол S3) → можно сменить

---

Бизнес

• Одна компания платит всем → зависимость
• Лицензия менялась за год → будет ещё
• AWS продаёт, автор в конфликте → смена лицензии близко
• Множественное финансирование → стабильнее
• Прозрачный план развития → предсказуемо

---

Как оценить

Прошёлся по чеклисту.
Посчитал риски.

• 0-2 риска -> можно брать
• 3-5 рисков -> осторожно, план миграции нужен
• 6+ рисков -> лучше альтернативу

---

Примеры

Kafka (2025):

• Apache 2.0 ✅
• Под фондом Apache ✅
• IBM влияние растёт ⚠️
• Альтернативы: Pulsar, NATS ✅

Итого: 1 риск
Вывод: можно брать, но следить

---

MinIO (2025):

• AGPLv3 ⚠️
• Интерфейс деградировал ⚠️
• Только исходники ⚠️
• Одна компания ⚠️

Итого: 4 риска
Вывод: высокий риск, нужен план Б

---

Grafana (2025):

• AGPL ⚠️
• Коммерция: разграничение прав, отчёты ⚠️
• Бесплатная версия базовая есть ✅
• Альтернативы есть ✅

Итого: 2 риска
Вывод: приемлемо

---

💡Инженерные приметы

Раньше (2010-е):
Поставил → работает → забыл

Сейчас (2020-е):
Поставил → через год лицензия → через два интерфейс деградировал → мигрируем

Что делать:

❌ Выбирать, потому что "модно"
❌ Выбирать, потому что "бесплатно"
❌ Думать, что инструмент навсегда

✅ Проверить лицензию
✅ Оценить риски
✅ Держать план миграции

---

📌 Правда жизни

Open Source повзрослел.

Инструменты меняются.
Драконы неизбежны.
Попасть в ловушку - это выбор.

---

💬 Сталкивались с ловушками OSS?
Как проверяете проекты перед внедрением?

#мышление #devops

🔥 Протоколы есть. Стандарты есть.

А люди всё равно не понимают друг друга.

Странно. Парадоксально:
люди, которые хотят одного и того же, в итоге ругаются.

Мы научились собирать системы, которые работают
почти без сбоев.
CI/CD, оркестрация, отказоустойчивость.

Но система из людей
до сих пор остаётся
самой нестабильной.

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

---

⚔️ Одна фраза — два смысла

Вопрос «Кто последний коммитил?» — информационный.
Но слышится как обвинение.

«Было бы неплохо добавить тесты» — предложение.
Но читается как «твой код — мусор».

«Почему так долго?» — уточнение.
Но воспринимается как «ты медленный».

Это не токсичность.
Это разрыв между интенцией и интерпретацией.

Ты имел в виду одно.
Человек услышал другое.
Оба уверены, что правы.

---

💀 Коммуникативный долг

Есть технический долг — все знают.
Есть коммуникативный — о нём молчат.

Он копится так же:
• мелкие недопонимания
• непроговорённые ожидания
• обиды, которые «ладно, проехали»

А потом — взрыв на ровном месте.
Или тихий уход человека из команды.

Разница с техдолгом:
Техдолг можно рефакторить.
Коммуникативный — только предотвращать.

---

🛠 Один принцип, который меняет всё

Культура без обвинений (blameless).

Не «кто виноват?», а «что пошло не так?»

Звучит просто.
На практике — ломает привычку искать крайнего.

Когда команда перестаёт защищаться — она начинает говорить.
Когда начинает говорить — проблемы всплывают раньше.
Когда всплывают раньше — чинятся дешевле.

Это не про «быть добрым».
Это про эффективность.

---

📌 Что с этим делать

Культура не внедряется сверху.
Она создаётся в каждом сообщении.

Перед тем как отправить — один вопрос:
«Как это услышит человек на другом конце?»

Не «что я хочу сказать».
А «что он поймёт».

Иногда достаточно переформулировать одну фразу.

---

📖 Если тема зацепила — написал подробный разбор:

• откуда берётся разрыв между интенцией и интерпретацией
• табличный паттерн: как фраза звучит → как слышится → как сказать лучше
• чек-лист проверки сообщения перед отправкой
• кейс команды, которая сократила время код-ревью на 30%

👉 Читать в Telegraph: Коммуникативные неудачи в DevOps-культуре

---

💬 А вы ловили себя на том, что сказали одно — а человек услышал совсем другое?

🔥 — да, регулярно
😎 — научился это отслеживать
👍 — у нас в команде с этим порядок

---

#мышление #devops

🚧 Почему «токсичный, но умный» не растёт

---

🧠 Есть миф: если ты технически силён – вырастешь в любом случае.

Реальность жёстче.

«Токсичность» не про характер. Это про повторяющееся поведение в коммуникации. Не ярлык, а паттерн.

---

⚙️ Что такое Senior на самом деле

Senior – это не «знает больше».
Это «делает продуктивными других».

• Менторит джунов
• Проводит ревью так, что люди учатся, а не защищаются
• Участвует в архитектурных обсуждениях и его слушают

Если с тобой не хотят работать – ты не масштабируешься.
А Senior без масштаба – это просто дорогой Middle.

---

🚫 Почему «токсичный гений» застревает

1. Обратная связь замыкается.
Люди перестают говорить тебе о проблемах.
Ты теряешь информацию, которая нужна для роста.

2. Команда обходит.
Задачи, где нужна коммуникация, уходят другим.
Ты остаёшься с тем, что можно делать в одиночку.

3. Lead-позиции закрыты.
Tech Lead – это на 50% переговоры, синхронизация, конфликты.
Токсичный человек на этой роли – риск для всей команды.

---

📊 Данные, а не мнение

Google в проекте Aristotle исследовал, что делает команды эффективными.

Главный вывод: состав команды – кто в ней – менее важен, чем то, как люди взаимодействуют.

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

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

Токсичный человек эту безопасность убивает.
Даже если он гений.

Хорошая новость: это паттерн поведения, а не черта личности.
Паттерны можно менять.

---

📌 Вывод

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

Можно быть умным.
Можно быть правым.
Но если с тобой не хотят работать – расти некуда.

---

💬 Встречали «гениев», которые застряли на одном уровне годами?

🔥 — да, и понятно почему
😎 — сам был таким, исправился
👍 — у нас таких нет

---

#карьера #devops