Введение

Смена работы в айти — обыденное явление. Обычно это происходит раз в 1-2 года. После трёх лет работы на одного работодателя можно себя уже и старожилом считать.

Цель

Пусть все постоянно говорят, что не любят часто меняющих место работы сотрудников, но в реальности именно им и удаётся, как правило, получить большую зарплату. Никто же не будет повышать оклад человеку, усердно трудящемуся на протяжении 10 лет. А вот дать побольше новому сотруднику — это гораздо проще морально. Поэтому для поддержания актуальной оплаты своего труда рекомендуется периодически сверять его с рыночным. Рубль в последние годы довольно быстро падал. Сравните цены в 2007 и 2025!!! Если вы видите, что ваша зарплата сильно отстаёт от рыночной, просите индексации. Просить тоже надо уметь, опишите, чего вы добились за время работы, какие задачи и проекты завершили, какие технологии изучили, укажите желаемую зарплату. Не будьте слишком краткими. Пишите подробнее. Одного предложения тут точно мало. Если же переговоры о повышении не удались, а зарплаты на рынке уже сильно выше вашей, то пора обновлять резюме.

При написании этой статьи я хотел собрать воедино все свои записи за прошедший год, связанные с поиском очередной работы. Клуб-Никаких-Имён! Только общая информация. У меня никогда не было желания работать в какой-то конкретной организации. Я всегда искал подходящую по моим критериям из того, что было. Если вы хотите в какой-нибудь Яндекс или VK, например, то можете дальше не читать — готовьтесь по материалам для подготовки в Яндекс/VK соответственно.

Моральные страдания

Для большинства людей смена привычной обстановки — это дополнительный стресс. После какого-нибудь десятого места работы это, конечно, проходит. Времена, когда после университета человек устраивался на завод и работал там до пенсии, давно прошли. Хотя я бы сказал, что в СССР тоже можно было менять место работы. Если это делать с умом, то иногда это могло принести определённые материальные плюшки.

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

Резюме

Вам нужно составить своё резюме. В резюме обязательно должны присутствовать:

• Ваш номер телефона, e-mail и контакты в мессенджерах для связи.

• Перечисление основных используемых технологий. HR фильтрует резюме по используемым технологиям. Просто по набору ключевых слов. Если здесь накосячить, то дальше ваше резюме даже не пройдёт. Нужно понимать, что HR — это не технический специалист. Он не знает разницы между JavaScript и Java, между Spring Boot и Spring Framework и т. д. Будьте максимально подробны и понятны. Нужно именно полное совпадение ключевых слов. Есть вероятность, что сейчас они используют нейросетевые технологии для анализа резюме, но как нам с этим работать — пока непонятно.

• Знание языков: английский, русский и т. д.

• Блок о себе, в котором необходимо рассказать про свои пет-проекты, выступления на конференциях, приложения на Google Play, статьи на хабре, выпущенные книги, неудавшиеся стартапы и все остальные внеклассные айтишные занятия.

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

• Название высшего учебного заведения, специальность и год окончания. Если вы только закончили учиться, то этот этап стоит расписать подробнее.

• Резюме не должно быть слишком длинным. Сильно сомневаюсь, что HR и кто-то другой будет читать что-то длиннее 1-2 страниц.

Как проходят

Собеседований в один этап практически не осталось. Везде два, три или даже четыре этапа.

Обычно можно выделить следующие этапы:

1. Беседа на 15 минут с HR.

2. Техническое собеседование.

3. Написание кода

4. Знакомство с командой

5. Интервью с руководителем.

6. Тестовых заданий в этом году никто не предлагал. По крайней мере мне.

Созвон с HR

Техническое собеседование

Java hashCode и equals

Важно понимать контракт между методами hashCode и equals.

Уметь рассказать, почему эти методы нужно менять вместе. Описать разные способы реализации этих методов.

Рассказать, почему нужно использовать getClass() при реализации equals, а не instanceof. Причина в том, что согласно контракту метод equals симметричен. Если x.equals(y) == true, то y.equals(x) тоже должен быть true, а с instanceof это условие нарушается для дочерних классов.

Внутреннее устройство HashMap

Нужно уметь рассказать про capacity и loadFactor у HashMap.

Очень круто понимать внутреннее устройство HashMap, как он поступает при совпадении hashCode у объектов, и т. д.

Полезные ссылки:

Внутренняя работа HashMap в Java

Tiebreaker Regarding Java HashMap, TreeNode and TieBreakOrder

Подробный разбор класса HashMap

Internal Working of HashMap in Java

Типы индексов в PostgreSQL

B-Tree индекс и его производные в PostgreSQL

Рассказ про b-tree индексы для разработчиков приложений — Владимир Ситников, PGConf.СПб 2023 — YouTube

Паттерны распределённых транзакций

Различные паттерны: SAGA, TPC и т. д.

Распределённые транзакции в микросервисах: от SAGA до Two‑Phase Commit

CQRS

Паттерн Saga через MassTransit. Оркестрация vs Хореография

Отказоустойчивость в Kubernetes

Паттерны отказоустойчивости приложений в Kubernetes

Liveness, Readiness, and Startup Probes в Kubernetes

Проблема N+1 в JPA и Hibernate

Суть в том, что при объявлении связей 1:М и М:1 в сущностях можно легко нагрузить систему дополнительными запросами на выборки связанных коллекций сущностей и одиночных сущностей для @OneToMany, @ManyToOne и @ManyToMany.

Основные способы решения:

1. Всегда использовать FetchType.LAZY и подгружать только необходимые коллекции с помощью графов сущностей или запросов с fetch HQL, JPQL.

2. Использовать Set вместо List. В этом случае Hibernate сможет за один запрос к базе данных получить данные для всех коллекций. В этом случае необходимо правильно переопределить методы hashCode и equals у сущностей, которыми заполняется Set!

Проблема с N+1 запросами в JPA и Hibernate

N+1 Problem in Hibernate and Spring Data JPA

В моей книге про Spring можете увидеть примеры использования FetchType.LAZY, графов сущностей, запросов HQL, JPQL и маппинг связанных сущностей на коллекцию Set. В реальных коммерческих проектах маппинг на Set мне ещё ни разу не доводилось увидеть, так что, я считаю, там прямо уникальная информация в моей книге.

Скоупы бинов в Spring

Уметь рассказать про скоупы бинов в Spring:

• singleton — (по умолчанию) единственный экземпляр на каждый контейнер Spring IoC.

• prototype — возвращается новый экземпляр на каждое обращение к бину.

• request — создаётся новый бин на каждый HTTP-запрос. Только для веб-приложений.

• session — бин живёт во время жизни HTTP сессии. А точнее связан с объектом Session. Только для веб-приложений.

• application — связывает жизненный цикл бина с ServletContext веб-приложения.

• websocket — связывает жизненный цикл бина с жизненным циклом WebSocket. Только для веб-приложений.

На собеседованиях могут спросить, что будет с жизненным циклом бина, если его скоуп prototype. Нужно ответить, что обработчики интерфейса DisposableBean, destroy-method из XML-конфигурации и аннотации @PreDestroy вызываться не будут, так как отследить эти этапы жизненного цикла становится невозможно. Никто не знает, когда будет вызвана сборка мусора этих объектов.

Некоторые собеседующие могут спросить, как внедрить бин со скоупом prototype в бин с другим скоупом, например, singleton. Ответы:

• с помощью context.getBean.

• с помощью javax.inject.Provider.

• ScopedProxyMode.TARGET_CLASS,

• с помощью ObjectFactory,

• использовать аннотацию @Lookup с подменой реализации метода.

Хорошая статья с описанием каждого из вариантов внедрения бина со скоупом prototype в бины с другим скоупом Injecting Prototype Beans into a Singleton Instance in Spring.

Domain Driven Design

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

Нужно уметь рассказать про следующие термины:

• агрегат,

• корень агрегата,

• Data Access Object,

• единый язык,

• интерфейсы,

• диспетчер,

• фасад.
  

Хабр: Domain-Driven Design: чистая архитектура снизу доверху.

Статья Domain-driven design на википедии.

Презентация DDD, necessary but insufficient: physical design principles for microservices.

Книга Domain-­‐Driven Design Reference Definitions and Pattern Summaries PDF-файл.

Распиливание монолитов на микросервисы

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

Что такое ACID

1. A — Atomicity.

2. C — Consistency.

3. I — Isolation.

4. D — Durability.

Полный ответ в статье на моём сайте.

Уровни изоляции транзакций

В PostgreSQL есть все уровни изоляций из статьи по ссылке ниже, кроме READ_UNCOMMITED. В PostgreSQL уровень READ UNCOMMITED работает как READ_COMMITED.

Уровни изоляции транзакций

SOLID

Абстрактный теоретический вопрос.

SOLID — это…

Написание кода

Этап написания кода проходит чаще всего на Yandex Code, который позволяет совместно редактировать текст программы. Несколько глючная вещь, на мой взгляд. Периодически теряет синхронизацию и приходится обновлять страницу. Периодически что-то глючит и пропадает возможность редактировать код напрочь. Опять таки лечится перезагрузкой страницы. Живительный F5, без него никуда.

Знакомство с командой

На этом этапе вы визуально смотрите часть людей из команды, беседуете с ними о проекте, о используемых подходах, о своём опыты, просто о жизни. Обо всём, что придёт в голову вам и собеседующим. Формат крайне субъективный, никаких чётких критериев и правил в нём нет.

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

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

Собеседование с руководителем

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

Проблемы собеседований

Как человек, побывавший по обе стороны собеседований, могу точно сказать, что никто, будь он хоть Столлман, хоть Линус Торвальдс, хоть профессор МГУ — никто не знает как проводить собеседования. Нет методологии, которая могла бы хотя бы с 90 % вероятности подсказать, подходит ли собеседуемый на эту должность или нет. Аналогично нет никакой реальной методики подсказать, подходит ли место работы вам или нет. Всё очень абстрактно и субъективно. Все фирмы, все собеседующие придумывают свои форматы и вопросы, подбирая их из того, с чем столкнулись, из интернета и копируя у других фирм. Собеседование в айти — это скорее свидание, чем реальный подбор подходящиего сотрудника или подходящей вам вакансии.

Случаи на собеседованиях

Если с собеседующим удаётся поговорить просто так о жизни, то они могут и пару баек рассказать.

Есть один мальчик...

Есть одна девочка...

Байка 1: суфлёр

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

Байка 2: нейросети

Тятя! тятя! нейросети Притащили мертвеца

Один из собеседующих, помню, рассказывал, что видел, как у кандидатов глаза постоянно бегают. Очевидно, что читает ответ откуда-то.

Байка 3: волчары

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

Заключение

Если вы работаете по своей профессии уже много лет, то найти работу в 2025 вполне можно. Особых отличий с прошлыми годами я не заметил. По скорости уложился примерно в один месяц.

Алгоритм всё ещё остался прежним:

1. Актуализировать резюме.

2. Попасть на собеседование.

3. Запомнить вопросы, на которые не смогли ответить.

4. После собеседования изучить темы, в вопросах по которым у вас были проблемы.

5. Если офферов пока нет, то перейти на пункт 1.