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

Недавно пытался устроиться в одну компанию (спойлер: не прошёл), и там перед собеседованием был странный этап, который я раньше нигде не встречал.

Нужно было зайти на специальную платформу, отвечать на вопросы с экрана и записывать свои ответы на камеру.

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

Я кое-как ответил на все вопросы, но чувствовал себя абсолютно не в своей тарелке — всё проходило натужно и медленно. Как итог, меня на следующий этап не пригласили.

В общем, время и нервы ушли в никуда.

Мой вывод? Выбирайте компании с минимальным количеством странных этапов. Обычно это говорит о том, что на самой работе вас тоже не будут чрезмерно грузить. Логика простая: чем проще собеседование, тем адекватнее процесс работы.

Давайте знакомиться! Мне 27 лет, у меня неоконченное высшее образование по специальности "Прикладная математика" и 6 лет опыта в разработке: 3 года работал как fullstack-разработчик, а последние 3 года специализируюсь на backend-разработке. Часто хожу на собесы и перекатываюсь с php на go

Однажды решил пройти собеседование в одну известную российскую компанию (спойлер: не прошёл). Там было целых 5 этапов и самое смешное, что с почти пятилетним опытом, уже зарабатывая $4500 мне в итоге сказали, что я "джуниор плюс".

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

Ещё один пример в копилку, что лучше выбирать компании с минимальным количеством этапов собеседования. Идеально — один этап. Так и работу получите, и нервы с самооценкой сбережёте.

Почему мне нравится DDD (Domain-Driven Design)?

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

DDD помогает не просто строить код, а создавать решения, которые решают реальные бизнес-задачи. Он помогает глубже понять предметную область и общаться с командой (не только программистами) на одном языке, поскольку бизнес-логика отделена от кода реализации.

DDD фокусируется на самой проблеме, а не на технических деталях. При построении модели домена ты думаешь, как отразить реальный мир, а не просто решать задачу с минимальными усилиями для кода. Это даёт больше возможностей для роста команды, и продукта.

Пример как мы внедряли DDD. Мы работали над системой управления подписками для SaaS-продукта. На тот момент архитектура была монолитной: вся логика — от расчёта стоимости подписок до продления и отключения — находилась в одном большом сервисе.

Основные проблемами монолита было:

- Сложность внесения изменений. Когда нужно было добавить новый тариф или скидку, разработчикам приходилось разбираться в запутанном коде. Это часто приводило к новым багам.
- Неясность бизнес-логики.
- Код был перегружен техническими деталями (работа с базой данных, API платёжных систем).
- Бизнес-аналитики не могли понять, как работают расчёты, а команде разработчиков приходилось тратить кучу времени на объяснения.
- Плохая масштабируемость. Добавление новых функций замедляло всю систему. Например, расчёт скидок для крупных клиентов иногда блокировал продление подписок для всех пользователей.

Мы решили пересмотреть архитектуру и внедрить DDD.

Вот как это выглядело:

Выделили домены, разделив всю систему на два контекста:
Контекст подписок (управление тарифами, продлениями, переходами между тарифами).
Контекст расчёта стоимости (правила скидок, налоги, специальные предложения).
Эти части стали независимыми, с чётко описанными границами.
Ввели Ubiquitous Language (универсальный язык). Вместо того чтобы использовать технические термины, мы согласовали с аналитиками и бизнес-командой, что будем оперировать понятиями вроде "План", "Активная подписка", "Скидка". Это упростило обсуждение требований.
Изолировали бизнес-логику. Логику расчётов вынесли в отдельные сервисы и написали на основании модели домена. Всё, что касается платёжных API и баз данных, осталось за пределами бизнес-логики.

Результат:

- Меньше багов. После внедрения изменений код стал прозрачным, баги из-за изменения тарифов и скидок сократились на 80%.
- Быстрее изменения. Добавить новый тарифный план теперь занимало не дни, а часы, потому что это стало отдельной частью контекста.
- Ясность для команды. Аналитики и разработчики говорили на одном языке, что ускорило обсуждение новых фич.
- Скорость системы. Теперь расчёты скидок не блокировали другие процессы, так как расчёты выполнялись асинхронно внутри своего контекста.