Сергей Озеранский

Deckhouse Conf 2026 — для тех, кто строит и поддерживает инфраструктуры. 9 апреля узнаете, как создать надёжные виртуальные машины в Kubernetes, перейти на микросервисную архитектуру без боли и правильно проектировать дашборды для мониторинга. И это только начало, в программу добавляются новые доклады. Живое общение с экспертами, демозона с продуктами Deckhouse и практические кейсы. Регистрируйтесь

Еще подготовил свои ИМХО на тему: Что должен найти при анализе кода main.py Я взял просто три уровня инженера - Junior, Middle, Senior. Вот что у меня получилось - https://gist.github.com/ozeranskii/1f39112eadabfd4c3f26af31fc9b1a29?permalink_comment_id=6015190#gistcomment-6015190

Немного мыслей про поведенческие интервью на senior позиции. На первый взгляд этот этап может показаться самым простым, ведь уже много кругов ада пройдено и остается только "поболтать". Хотя на этом этапе часто принимается финальное решение. На таких интервью обычно не проверяют технологии. Проверяют как вы работаете как инженер уровня senior. Что реально хотят увидеть 1. Зону ответственности Важно не “мы сделали”, а что сделал именно ты. Плохая формулировка: “мы разрабатывали высоконагруженную систему”. Лучше: “я отвечал за архитектурное решение для …”. Интервьюеру нужно понять где именно был твой вклад и уровень влияния. 2. Мышление через результат Хорошая история почти всегда выглядит так: проблема → метрика → действие → результат → метрика → повторить от этапа "метрика" Например: была проблема X → я предложил и спроектировал решение для X → в итоге проблему решили. При этом до и после решения идет замер качественных метрик. Иначе оценить внедрение можно только интуитивно, а человек склонен, как мне кажется, быть более оптимистичным. Без результата история звучит как просто “что-то делали”. 3. Умение работать со сложными ситуациями На senior уровне почти всегда спрашивают про: • инциденты • сложные технические решения • конфликты между командами • ситуации неопределенности Важно показать: • как ты анализируешь проблему • как принимаешь решение • как договариваешься с людьми 4. Рефлексию Может будет вопрос про слабые стороны. Нормальный ответ - показать направление роста, например: • хочу глубже разбираться в инфраструктуре • хочу прокачать performance engineering • хочу сильнее развивать продуктовое мышление На senior позиции ожидают осознанность в развитии. Что помогает подготовиться 1. Подготовить 3–5 историй заранее Например: • сложный прод-инцидент • архитектурное решение • оптимизация производительности • конфликт между командами • ситуация, где пришлось принимать решение в неопределенности На интервью мозг иногда просто тупит. Готовые истории сильно помогают. 2. Говорить через конкретику Не: “мы улучшили систему”. А: “снизили latency с 400ms до 120ms”. Цифры сразу показывают масштаб. 3. Задавать вопросы компании Это тоже часть интервью. Например: • как проходит code review • пишутся ли тесты • как устроены performance review • сколько коммуникации с бизнесом у senior инженеров • из чего состоит обычный день инженера в компании Иногда ответы на эти вопросы намного лучше показывают реальность компании, чем сам процесс интервью. Если коротко. На senior интервью проверяют три вещи: • ответственность за решения • умение работать с неопределенностью • умение влиять на людей и систему Поведенческое интервью проверяет не только как человек работает, но и как влияет на систему вокруг себя: • людей • процессы • продукт • архитектуру • культуру И довольно часто именно этот этап решает, будет оффер или нет.

Помните, мы играли в игру. У меня дошли руки, наконец-то😒, сделать результат того, как я вижу этот код (из задачи) в продакшене. Улучшать можно бесконечно, поэтому я написал такой код, который у меня не вызывает вопросов по моим критериям к продакшен коду. Для себя я поставил условия использовать максимально нативный Python, что и получилось. В проде я бы кое чем обвесился и кода возможно немного стало меньше, но главное это архитектура самого решения. Плюс я сделал допущение, что у нас нет внешних зависимостей, таких как Vault, чтобы хранить безопасно секреты, поэтому "по-старинке", в env. И еще допущение - тесты. Я держку в голове, что они написаны. Но я не писал в данном решении. Но после теперь их намного проще писать. И по хорошему при рефакторинге тесты пишутся до рефакторинга. Теперь сам код - https://gist.github.com/ozeranskii/1f39112eadabfd4c3f26af31fc9b1a29 Тут подробное описание diff'a - https://gist.github.com/ozeranskii/1f39112eadabfd4c3f26af31fc9b1a29?permalink_comment_id=6015166#gistcomment-6015166 Повторюсь, сколько людей - столько мнений, но теория программирования она одна. Хотя ее тоже можно интерпритировать по разному, главное соотвествие требованиям, которые изначально заложены.

Чуток теории программирования принесу в понедельник с утра. Уверен, что это все любят. Law of Demeter. Law of Demeter (Закон Деметры), если описать его в одной фразе - "не лезь во внутренности чужих объектов". Пример:

    
        
order.customer.address.city.name  # плохо
{}
    

Укже лучше

    
        
order.getCustomerCityName()
{}
    

Но, как мы любим, есть нюансы. В примере выше запах кода просто скрыт теперь через функцию или там могла быть property. Поэтому надо думать немного шире. Принцип не столько про то, чтобы "не было много точек". Много точек - это просто запах кода, по которому можно понять чуть больше. Суть в связности. Если ты лезешь в цепочку внутренних объектов, значит твой код знает слишком много о соседях. А это высокая сцепка. Чем больше объект знает о внутреннем устройстве другого, тем сильнее он с ним связан. Сильная связность = дорогие изменения. На уровне сервисов - то же самое. Если один сервис знает доменную модель другого это уже не микросервисы. Это распределенный монолит. Law of Demeter - очень простая штука. Но если держать его в голове, системы становятся заметно дешевле в изменениях. И проще в понимании.

Шел 2024 год. И у меня подгорало на текущем на тот момент месте, поэтому я решил посмотреть рынок. Я уже жил в эмиграции, но локального работодателя искать не хотел. Причины простые: деньги и язык. Лидерские роли без локального языка - отдельный квест, а по компенсации часто грустно. Плюс не всегда есть удаленка, а в Валенсии ИТ есть, но его объективно немного. Был вариант искать среди экспат-компаний, например на Кипре, но без релокации. И тут тоже не все готовы, особенно когда речь про Tech Lead и выше. Самый понятный и рабочий вариант - РФ-компания. Да, рубль. Но процессы и люди понятны. Плюс у многих бигтехов уже есть юрлица в СНГ, и вывод дохода на европейский счет давно не проблема. В 2024 году это уже не какая-то серая схема, а нормальная операционная реальность. Но поиск был в режиме "просто посмотреть". И в этот момент мне пишет HR из большого РФ бигтеха. Компания известная, продуктом пользовались, я думаю, почти все. Тогда она мне реально нравилась: сильная инженерная и продуктовая культура, открытость, публичные митапы. Я по возможности их посещал, общался с лидами и инженерами. Отдельно импонировало то, что часть их внутренней документации была выложена публично как OSS. Можно было изучать практики, забирать подходы, применять у себя. Это редкость для бигтехов в РФ. Сейчас уже отношусь к компании нейтрально, просто перестал следить. В эмиграции фокус сместился, и пересечений стало меньше. Интересный момент: в тот момент мне написало сразу несколько HR. Они не штатные, ведут разные проекты внутри одной компании. Классика. И еще деталь - с некоторыми первый контакт был еще в 2023 году. Тогда я отказался от интервью, потому что не планировал менять работу. Но показательно, что сильных кандидатов не забывают. Даже если ты однажды сказал нет. Я решил пройти процесс. Было заявлено 4 этапа: 1. HR-интро 2. System Design - спроектировать решение с нуля 3. Платформа (я не знаю почему там дали такое название этому этапу) - кодинг (именно кодинг!) на Python 4. Кейс-интервью HR-интро сложно не пройти, это нужно очень еще постараться, как мне кажется. Первые два технических этапа прошел уверенно. Хорошая обратная связь, без замечаний. Процесс растянулся на месяц с августа по сентябрь. Потом я снова переезжал, взяли паузу. Вернулись к процессу уже в декабре. К этому моменту я успел дважды сменить локацию. Что это означает? Позицию не закрыли. И я по-прежнему был им интересен. Последний этап - кейс. Домашняя подготовка. Дают задачу и список рекомендаций. Структура понятная, но не новая. Не новая потому что, к кейс интервью подходил так же как это делал в обычной жизни на работе. То есть тут важно то, что я не подсраивался под кейс и не придумывал - делал часть своей работы. И что еще важно, делал то, что реально показать и обсудить за 1 час интервью. То, что действительно важно. В итоге - отказ. Причина: "в кейсе не хватило глубины проработки". Честно? Меня это разозлило. Но сейчас злит не потому, что я там не работаю. Сейчас я рад, что не работаю там. В первую очередь рад потому, что считаю, что любое событие, позитивное или нет, привело меня к тому, где я сейчас. А сейчас я счастлив во всем. Злит другое - поверхностность формулировки. После всех этапов, где я проходил как сильный кандидат, получить обобщенное "недостаточно глубоко". Ну нет... Да, я сделал таблицу приоритизации, а не roadmap. Но это вопрос формы, а не сути. Внутренние стандарты отображения изучаются за 30 минут после выхода в компанию. Это не системный пробел. Если копнуть глубже, там скорее вопрос ожиданий по уровню бизнес-погружения, продуктового мышления и степени детализации. Но это уже про интерпретацию. Но говорить мне про недостаточность бизнес-погружения, человеку, который предоставил HR документ с достижениями для бизнеса с цифрами (много кто ведет такой такумент?). Тому, кто делал стартап и прогорел, кто имел свой бизнес... Кейс-интервью - это не всегда про качество решения. Часто это про совпадение ожиданий. Можно быть достаточно сильным и не попасть в картинку в голове конкретного интервьюера. Это жизнь. Но раздражает.

Как я работаю с System Design на менторинге Недавно разбирали с кандидатом классическую задачу - добавить трекинг курьера в мобильное приложение доставки. Казалось бы, просто "покажи точку на карте". Но именно такие задачи хорошо показывают, умеет ли человек думать как инженер, а не как кодер. Вот структура, которую я использую и которую рекомендую отработать до автоматизма: 1. Функциональные требования - сначала скоуп, потом всe остальное. Что входит, что явно out of scope, кто пользователь, какой happy path. Без этого любой дизайн стрельба вслепую. 2. Нефункциональные требования - думай глобально. Latency, availability, consistency, допустимый staleness данных. В нашей задаче ключевым оказался SLA 100ms и именно это может сильно определять архитектуру. 3. Capacity Estimation - цифры диктуют решениею Быстрая черновая прикидка за 2-3 минуты прямо на интервью. Не нужна точность - нужен порядок величин. В нашем кейсе: 10 000 активных заказов, polling раз в минуту -> 170 RPS, все состояние в кеше -> 500 KB. Три строчки - и сразу ясно что Redis на одной ноде справится, а Kafka и Cassandra здесь просто не нужны. Главное что дает estimation - ты видишь где реальная проблема. В нашем кейсе это не масштаб, а latency. Значит туда и идём, не отвлекаясь на лишнее. 4. API Contract - снаружи внутрь Прежде чем рисовать "квадратики и стрелочки" - зафиксируй интерфейс. Это дисциплинирует мышление и сразу показывает интервьюеру, что ты думаешь о потребителе. 5. Data Model - отдельно, не внутри "дизайна" SQL vs NoSQL под конкретные access patterns, что и как кешируем, какие TTL. 6. High-Level Design по C4 System Context -> Containers. Не надо сразу рисовать 15 микросервисов. Сначала покажи систему в окружении, потом основные блоки с обоснованием технологий. 7. Deep Dive в критический компонент Интервьюер всегда попросит углубиться. Будь готов объяснить failure modes, retry logic, idempotency. В нашей задаче это был Sync Worker, который фоново тянет координаты и пишет в кеш. 8. Trade-offs. Это про зрелость решений. Не "я выбрал Redis потому что знаю Redis". А "я выбрал cache + background sync, потому что клиент обновляет координаты раз в 30 секунд - staleness допустим, а 350ms sequential chain нарушает SLA. Альтернатива X не подошла потому что Y." Что я часто вижу у кандидатов: - Прыгают к решению не уточнив скоуп - Пропускают capacity estimation и архитектура висит в воздухе - Молчат. Интервью по system design это диалог, а не лекция • Не проговаривают от чего отказались и почему Хороший system design это не знание паттернов наизусть. Это структурированное мышление, умение работать с ограничениями и объяснять компромиссы. Именно это и тренируем.

Развитие инженера почти неизбежно выходит за рамки одного только кода. Если смотреть шире, одно из логичных направлений роста - понимание облачных решений. И это не просто расширение набора навыков. Это рост масштаба мышления, эрудиции и понимания того, как технологии работают в реальной среде и даже то, как решение связано с бизнесом и за каждой технологией и решением стоят реальные деньги. Пока мы находимся только в плоскости разработки, мы мыслим кодом: функции, классы, архитектура сервиса, язык, фреймворк, производительность компонента. Это важный слой. Но это не вся система. Особенно для сеньора и выше. Когда начинаешь разбираться в облаке глубже, фокус смещается. Ты начинаешь мыслить целиком: - как система живет под нагрузкой; - как масштабируется; - сколько она реально стоит; - где у нее точки отказа; - как устроена безопасность; - можно ли вообще не писать часть кода, а использовать готовый managed-сервис. И опять же, сколько это стоит и из чего складывается стоимость (и тут не только цена облака). Все это про проектирование среды, в которой существует код. Когда говорим про облака, то важен конкретный провайдер. AWS, GCP, Azure, Yandex.Cloud и так далее. Это не важно. Важно не названия сервисов в конкретном провайдере, а понимание принципов: object storage, managed базы данных, IAM, сетевые модели, балансировка нагрузки, наблюдаемость, экономика инфраструктуры и так далее. S3 в каждом облаке называется по-разному. Managed PostgreSQL тоже. Главное, что остается суть. Именно поэтому инженеру полезно выходить за рамки прикладного кода. Как пример, понимание облака расширяет зону ответственности и меняет масштаб мышления от «я написал сервис» к «я понимаю, как живет вся система». Сертификации могут помочь структурировать знания. Например, AWS Solutions Architect Associate. Но ценность не в бейдже, а в системной картине. У меня нет сертификации, но я шарю. Важно понять, что облако это не про инфраструктуру как таковую. Это про системность. И чем раньше инженер начинает смотреть на систему целиком, тем быстрее выходит на другой уровень профессионального мышления.