С другой стороны, процесс обучения не должен затягиваться на 5 лет. Максимум — год, и выходить на работу. Я знаю, что рынок в этом году требует других специалистов, но других нет, если те, что сейчас на рынке.

Не ведитесь, если вам говорят, что пройдя мои курсы, вы поднимете зарплату в 2 или 3 раза. А сколько времени обучение? «А, 33 дня, но у вас система вин-вин». Вначале деньги, а потом стулья. Всегда пересчитывайте на человеко-часы. Если обучение стоит 40 тр + 150% оклада, а оклад у вас будет 200 тр, значит, этот ментор должен с вами провести около 120 часов, если его час стоит 2000 рублей. Дробите задачи.

Главное, что стоит взять у левых, — это практику хождения по собеседованиям. На собеседованиях вы можете понять, что требует рынок, какие проекты существуют, что они решают. Вы же нормально относитесь к тому, что зашли в магазин, но ничего не купили. Тут точно так же. Вы пришли посмотреть, чем торгуют, но покупать или устраиваться вас никто не заставляет. Возьмите себе за практику периодически обновлять собеседования и ходить на них. Общайтесь на собеседовании как с коллегами, а не как с врагами с другой стороны.

С курсом по Go я хотел проверить схему левых. Но цифры рынка показывают, что я уже опоздал. Во-первых, даже с накрученным опытом на всех позициях Go мне отказали. Хотя я указал опыт 5 лет. Во-вторых, зарплаты для Go просели. Мало вакансий, но много новичков. Где зп 500-600 тр на Senior? Я вижу 200-250 тр. Причем стали попадаться вакансии с зарплатой около 100 тр. Благо за Java такого я не видел.

Итог

Безусловно, развивать себя в программировании — это ваша основная обязанность, но она должна быть неотрывна от производства. То есть нужно решать реальные проблемы бизнеса, а не сферические задачи. Выходить на рынок и смотреть, что предлагают.

Я сам нарушил этот принцип: хоть я и провожу собеседования, но сам на них не ходил уже лет 10. Такого быть не должно.

Наше обучение https://job4j.ru/ по классической схеме: упор на практику с балансом в теории.

Yoga by Job4j

Пока рынок IT на фризе предлагаю переключиться на йогу.
Сам практикую с 2020 года. Даже есть сертификат тренера по йоге за 2023 год.

Предлагаю сегодня в 19 00 провести тренировку.
Что нужно.
1 час свободного времени, коврик.

Тренировка без шизотерики, мантр, мудр и других этнический элементов. Только физуха.

Вход бесплатный. Пишите в личку @parsentev. Добавлю в чат, где будет эфир. Желательно включить камеру, чтобы я мог править ваш позы ).

ПС. Записи не будет, только живой эфир.

Сливы собесов | Польза и вред

Начну с нравственно-этических аспектов этой темы. Смотреть «слитые» собеседования — всё равно что получить ответы на тест. Не справедливо, правда? Для кого это несправедливо — для других кандидатов или для работодателя?

Как я уже писал, объём доступной информации сейчас огромен. Могут возразить: «В вакансии указан стек, по нему и будут вопросы». Но даже такое упрощение нисколько не уменьшает объём. Приведу пример: в вакансии может быть указано использование PostgreSQL — а это целый мир. Книга по SQL часто занимает 3000 страниц, и если копнуть глубже, понимаешь, насколько сложные механизмы скрыты внутри СУБД.

Работодатели тоже это понимают, поэтому собеседование обычно строится по схеме:

1. Алгоритмическая задача уровня easy из LeetCode. Любой, кто считает себя программистом, должен уметь решать такие задачи. Потренируйтесь на нашей платформе: [https://job4j.ru/topics](https://job4j.ru/topics)
2. SQL-запрос с SELECT, JOIN, GROUP BY, HAVING — стандартный кейс в режиме реального времени. Стас отлично поработал над этим разделом на нашей платформе: [https://job4j.ru/sqlExercise](https://job4j.ru/sqlExercise)
3. Теория. Даже если вы ежедневно работаете с технологиями, вы забываете детали. Прочитать 3000 страниц текста за выходные и выдать хорошие ответы в понедельник невозможно. Единственный способ узнать, что именно спрашивают в конкретной компании, — послушать реальное собеседование.

Как работать со «сливами» собеседований

> Замечание. «Слив» — это запись реального собеседования, а не мок-интервью. На моке вы расслабленно беседуете, а на настоящем интервью вам нужно доказать, что вы справитесь с задачами, и помочь интервьюерам это увидеть.

1. Слушайте полностью. От рассказа о компании до вопросов о процессах. Если у вас совсем нет опыта, вы быстро заметите, как работодатели приукрашивают описание.
2. Решайте задачи самостоятельно. Ставьте запись на паузу, пытайтесь решить — потом отправляете своё решение LLM и просите проверить. Затем слушаете, как это делал кандидат. Важно понимать, что чужое решение может быть неверным, так что не полагайтесь на него целиком.
Если у вас есть записи конкретной компании, прорешайте все её задания. Например, когда я поступал в вуз, готовился по методичкам: я полностью прорешал математические задачи и только просматривал физические. На экзамене мне попалась задача, которую я лишь просматривал — я вспомнил решение лишь фрагментарно.
3. Теория. Выпишите вопрос, поставьте запись на паузу и ответьте сами вслух (не про себя!), затем сравните с ответом кандидата и уточняющими вопросами. На настоящем интервью у вас может «встать ком в горле» — проговорите ответы вслух в спокойной обстановке, чтобы привыкнуть.

Общие правила на интервью

1. Не отвечайте грубостью на грубость. Высокомерие на высокомерие — путь к конфликту.
2. Не перебивайте. Слушайте вопрос до конца, делайте паузы, задавайте уточняющие вопросы, контролируйте темп речи.
3. Объясняйте своё решение. Лучше проговорить ход мысли и получить корректировку, чем молчать и написать неверный код.

Общие правила подготовки

1. Ежедневно решайте easy-задачи LeetCode. Не пропускайте их: на словах задача может казаться простой, но при кодировании всегда появляются ошибки.
2. Мок-собеседования ≠ реальные. Если есть выбор, смотрите реальные записи собеседований и тренируйтесь по ним.

Завтра в 19:00 | Тренировка в стиле йога

Продолжаем тренировку. Завтра в 19:00 жду всех желающий приобщиться к йоге без шизотерики. Только физика, будет жарко.

Пишите @parsentev. Я добавлю в чат.

Комментарии с предыдущей тренировки:
1. Было жарко, Смог сделать половину.
2. Я до этого занимался не йогой )).
3. Отвалилась на пауке.

Типы метрик в Prometheus

В пятницу проходил собеседование в Райф. Вначале обсуждали процессы Ci\CD.
На своем проекте я Prometheus используют только для анализа ERROR. Считаю количество ошибок за день и отправляю Alert если их больше 10.

Но типов метрик в Prometheus больше.

1. Counter (Счётчик)
- Описание: Монотонно возрастающий счётчик, который может только увеличиваться или сбрасываться в ноль при перезапуске
- Использование: Для подсчёта событий, количества запросов, ошибок и т.д.
- Примеры:
- http_requests_total
- errors_total
- Особенности:
- В PromQL обычно используется с функциями rate(), irate() или increase()

2. Gauge (Измеритель)
- Описание: Значение, которое может увеличиваться и уменьшаться
- Использование: Для измерения текущего состояния (использование памяти, температура, количество одновременных соединений)
- Примеры:
- memory_usage_bytes
- temperature_celsius
- current_connections
- Особенности:
- Часто используются в графиках "как есть"
- Полезны функции delta(), deriv()

3. Histogram (Гистограмма)
- Описание: Выборка наблюдений, обычно временных характеристик или размеров ответов
- Использование: Для анализа распределения значений, особенно latency
- Примеры:
- http_request_duration_seconds_bucket
- response_size_bytes_bucket
- Особенности:
- Создаёт несколько временных рядов с суффиксами _bucket, _sum, _count
- Позволяет вычислять перцентили с histogram_quantile()
- Требует предопределённых buckets (границ корзин)

4. Summary (Сводка)
- Описание: Аналогично гистограмме, но вычисляет квантили на стороне клиента
- Использование: Когда нужно отслеживать заранее определённые квантили
- Примеры:
- http_request_duration_seconds_summary
- Особенности:
- Создаёт метрики с суффиксами _sum, _count и квантили _quantile
- Менее гибкий, чем гистограмма, но более эффективный для предопределённых квантилей
- Квантили нельзя агрегировать

5. Untyped (Нетипизированный)
- Описание: Устаревший тип, для совместимости
- Использование: В legacy-системах
- Особенности:
- Prometheus пытается определить тип автоматически

Добавил в наш курс по DevOps урок про типы метрик в Prometheus.

👉 https://job4j.ru/courses/35

Уже традиция. Субботняя йога

В 19 00. Нужен коврик и желание по потеть.

Пишите в личку @parsentev. Я добавлю в чат.

Системный дизайн

В озоне у меня было два этапа с системным дизайном.
Это мой первый опыт прохождения этого блока, ранее никогда не было.

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

https://www.youtube.com/watch?v=RAMWRgt-3G0

Kafka | Outbox

На секциях системного дизайна в озоне использовали сервис -
https://excalidraw.com/. Мне он приглянулся. Я стал использовать его для своего курса по Kafka.

Сегодня добавил два урока:

Иденпотентность и гарантии доставки [#505524]
Outbox [#505525]

В райфе мне дали задачу, у тебя есть сервис (replica > 1), настроен outbox. Вопрос, как избежать дублирование отправки сообщений из payload таблицы?

Ответы пишите в комментарии. Свой ответ я напишу в следующем посте.

Описание курса по Kafka
👉 https://job4j.ru/courses/21

Субботняя йога в 19:00

Напоминаю, что мы теперь не только программируем, но и тренируемся.

Всех желающих жду завтра в 19:00 на тренировку.

Пишите в личку @parsentev.
Вход бесплатный.

Кто диктует правила фронт vs бек

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

Конечно, был вопрос о процессах разработки и взаимодействии с другими командами.
В своём курсе по DevOps я описывал элемент инженерной культуры — спецификации.

Один из примеров касался RPC, например, REST API или gRPC, описанных через Swagger.

Что это даёт? Самое главное — теперь команда backend и frontend может вести разработку параллельно.

В частности, один из тимлидов обратил на это особое внимание, потому что в их проектах команды чётко разделены на backend и frontend. То есть при разработке нового бизнес-процесса он сначала попадает в backend, и только потом — в интеграцию с frontend.

Почему так происходит? Обычно разработка идёт "от базы данных к клиенту" — это восходящее проектирование. Это связано с тем, что наибольшая вычислительная нагрузка ложится на реляционную базу данных, поэтому сначала проектируют схемы БД.
Однако в таком случае frontend-команда простаивает, так как им нужен сервер, чтобы писать свой код.

Есть и другой подход — нисходящее проектирование. Оно как раз начинается с описания API-спецификации, а затем — её реализации. В этом случае можно применять TDD, но есть высокая вероятность, что внешнее API будет меняться, что приведёт к лавинообразным изменениям в слоях приложения.
Зато такой подход позволяет заранее согласовать API между backend и frontend и начать параллельную разработку.

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

А как у вас принято в проектах? Напиши в комментариях.

Наш курс по DevOps — https://job4j.ru/courses/35

"Волки" или Остапы Бендеры из IT

«12 стульев» Ильфа и Петрова — одно из моих любимых сатирических произведений.

Остап Бендер, главный герой романа, — своего рода прародитель «волчества»: он демонстрирует, как умение играть по чужим правилам и искать лазейки позволяет быстрее достигать целей.

Вчера в чате скинули ссылку на статью про «волков». Так как не все еще знают этот жаргонизм, я решил тоже написать пару строк.

Вначале обрисую проблему. У нас есть «кабанчик» (жаргон 90-х — означает предпринимателя или просто бизнес), которому нужны рабочие руки, но эти руки стоят дорого, поэтому нанимать абы кого нельзя. Поэтому нужен процесс отбора кандидатов.

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

HR не может объективно оценить программиста, потому что не имеет опыта в программировании. А для программистов заниматься наймом — неперспективная работа: слушать, как кандидат мямлит одни и те же ответы, — это скучно.

Кабанчик, чтобы решить эту проблему, просит программистов составить скрипты опроса, по которым прогоняют кандидатов и оценивают уже, как бы объективно.

Тут и появляются «волки». Волки — это социальные хакеры. Для них работа в IT — это игра. Играть можно по правилам кабанчика, а можно «взламывать» систему. Здесь появляется не только материальная подоплека, но и игровой азарт.
В этой игре есть четкая балльная система: чем больше ты зарабатываешь, тем ты круче.

Какие трюки используются при найме:

1. Подгонка резюме под фильтры — вставляют ключевые слова из описания вакансии, чтобы пройти автоскрининг.
2. Отработка шаблонных ответов — учат типовые вопросы/ответы и отрепетируют подачу.
3. Прозрачные уточняющие вопросы рекрутеру — выясняют этапы, критерии и таймлайны, чтобы управлять процессом.
4. Ведение нескольких процессов одновременно — чтобы не зависеть от одного оффера и иметь возможность торговаться.
5. Приукрашивание опыта — формулировки, которые не врут прямо, но создают более сильное впечатление.
6. Использование сливов/чужих скриптов интервью — ответы или задачи из прошлых собеседований адаптируют под новые.
7. Подсказки во время удалённого интервью — скрытое вмешательство извне.
8. Фальсификация рекомендаций или проектов — подделка подтверждений опыта.

А зарабатывать можно на всём и как угодно.

Перечислю основные направления:

1. Первая работа. Чем быстрее — тем лучше. 2–3 месяца максимум.
2. Мультиработа. Оптимизируй время. Удалённая работа позволяет работать на нескольких проектах сразу.
3. Проходи собеседования и продавай скрипты, вопросы/ответы, задания.
4. Проходи собеседования и продавай сливы этих собеседований.
5. Продавай услуги менторинга: собеседования, легенда, повышение зарплаты.
6. Продавай советы по трудоустройству.

Вы думаете, что в конце я начну осуждать деятельность этих ребят? Нисколько.
Большинство из приведённых выше трюков я и сам пробовал, а с 2010 по 2015 год даже работал сразу на нескольких проектах. Единственное — я не разделяю идею везде кричать, что так нужно делать.

Сегодня суббота. Кроме IT на https://job4j.ru/ мы ещё и тренируемся. Все, кто желает один час попотеть на коврике, — пишите в личку @parsentev.

Кафка. Вопросы с собеседований: Райф, Альфа, Озон, X5, Сбер

В июле 2025 года проходил собеседования. Ниже собрал расширенный список вопросов о kafka.

1. Какие есть семантики доставки в Kafka: _at-most-once_, _at-least-once_, _exactly-once_? Что на них влияет (например, acks, retries, идемпотентность, транзакции)?
2. При использовании _At-Least-Once_ — какие стратегии можно применить на стороне потребителя, чтобы избежать дубликатов в обработке? (например, идемпотентная обработка, детектирование по уникальному ключу, хранение уже обработанных, transactional read-process-write и т.п.)
3. В чём отличие между _At-Most-Once_ и _At-Least-Once_ по потерям/дубликатам?
4. Как работает схема _Exactly-Once Semantics_ (EOS) в Kafka? Какие компоненты участвуют и в каких ситуациях она всё ещё может не давать 100% гарантию?
5. Какие типы acks есть у продюсера и как они влияют на задержку и надёжность доставки?
6. Что означает min.insync.replicas и как его настройка вместе с acks=all влияет на устойчивость и доступность?
7. Что такое идемпотентный продюсер и почему просто enable.idempotence=true недостаточно для полной защиты от повторной доставки в более сложных схемах?
8. Как потребитель подтверждает, что он "прочитал" сообщения? В чём разница между авто-коммитом и ручным коммитом offset’ов?
9. В чём разница между commitSync и commitAsync и когда какой использовать?
10. Что такое _consumer lag_ и как его мониторить? Почему это важно?
11. Что происходит, если оффсет не найден (например, из-за удаления старых данных)? Как работает auto.offset.reset?
12. Что происходит, когда потребитель отключается от группы или добавляется новый? Как работает ребалансировка, какие стадии есть (revocation, assignment), и как её накладные расходы можно минимизировать (например, cooperative rebalancing)?
13. Что случится, если потребитель не вызывает poll долгое время и превышает max.poll.interval.ms или теряет heartbeat (session.timeout.ms)? Как это отражается на группе?
14. У тебя 3 брокера и топик с 3 партициями: как эти партиции распределяются по брокерам? Как выбирается лидер и реплики?
15. Что происходит при отказе лидера партиции? Как происходит failover и что такое ISR (in-sync replicas)?
16. Что случается при добавлении или удалении брокера — как перераспределяются партиции и кто инициирует ребалансировку партиций?
17. Как правильно подбирать max.poll.records, max.poll.interval.ms, heartbeat.interval.ms и почему слишком длинный poll может вызывать проблемы?
18. Как обеспечить атомарную обработку сообщения и запись результата в стороннюю систему (например, сравнение outbox pattern vs транзакционный read-process-write с Kafka)?
19. Как устроен механизм выбора лидера партиции и какие условия могут привести к длительной недоступности?
20. Какие метрики нужно смотреть, чтобы понимать, что потребители или продюсеры работают корректно и не теряют данные?
21. Как устроено гарантированное завершение транзакции при использовании транзакционного продюсера и как это согласуется с потребителями?
22. Как добиться минимального времени простоя при ребалансировке потребительской группы?
23. В каких ситуациях может возникнуть "split-brain" с точки зрения реплик и как Kafka с этим справляется?

Эти и другие вопросы мы разбираем на курсе по Kafka
👉 https://job4j.ru/courses/21

Поднять Kafka | Minio | KeyCloak за $$$

Для проекта BuddyService нужно поднять инфраструктуру.
Пишите напрямую @parsentev.

Оплата почасовая с дальнейшей поддержкой сервиса

Как вы знаете, я большой фанат тестов: unit, it, e2e.
Одной из крутых особенностей языка Go является встроенный инструментарий для тестирования.
Тесты в Go оформляются в методологии table-driven test. В этом подходе тестовые данные и ожидаемые результаты формируются в виде таблицы. Такой подход позволяет избавиться от дублирования кода теста и при этом покрыть разнообразные случаи поведения вашей программы.

Про этот подход я знал давно, но не использовал его, потому что мне казалось: если у тебя 105 вариантов входных параметров, а падает 101, то тебе каждый раз нужно прогонять все 100 тестов.

Оказалось, что нет — IDEA Community Edition по умолчанию поддерживает запуск отдельной строки из табличных данных.

@ParameterizedTest  
@CsvSource({  
        "true,true,true,true",  
        "true,false,true,false",  
        "false,false,false,true",  
        "true,true,false,false"  
})  
void testMono(boolean a, boolean b, boolean c, boolean expected) {  
    Check check = new Check();  
    boolean[] input = new boolean[]{a, b, c};  
    boolean result = check.mono(input);  
    assertThat(result).isEqualTo(expected);  
}

В нашем Java курсе я перепишу тесты на подход TDT.

А вы используете такой подход? Напишите свои мысли в комментариях.

—-
Наш курс по Go — https://job4j.ru/courses/38

🎒 Акция: Снова в школу

Друзья, мой последний школьный звонок прозвенел ещё в 2003 году, но учиться я продолжаю каждый день.

Хочу поддержать вашу мотивацию и даю скидку на все учебные программы: −15%

Скидка действует до 30 сентября.

👉 http://job4j.ru/

Предал Java ради GoLang

Статьи буду публиковать на платформе, так как канал телеграмм для этого не подходит.

https://job4j.ru/article/view/1

Комментарии пока пишите тут. потом добавлю такую возможность на платформу.

Разбор задания с первого этапа собеседования в Яндекс

https://job4j.ru/article/view/3

В приведенном коде есть явные ошибки. Я их добавил специально, чтобы обсудить. Например, мигающие тесты.

SLI/SLO/SLA

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

SLI (Service Level Indicator) — метрика, по которой мы меряем качество сервиса.
Пример: процент успешных HTTP-запросов (2xx) к нашему платежному микросервису.

SLO (Service Level Objective) — целевое значение для метрики.
Пример: "не менее 99.9% успешных запросов за месяц".

SLA (Service Level Agreement) — формальное соглашение с клиентом, где закреплены SLO и последствия нарушения.
Пример: если платежный сервис падает чаще чем позволяет SLO, то мы возвращаем клиенту часть оплаты.

Как у вас на проектах, есть такие критерии?