Всё, что изложено ниже, — исключительно моё личное мнение. Для кого-то это может показаться очевидным или банальным, но если хоть одна мысль окажется для вас полезной или вдохновит на новые идеи — значит, я не напрасно поделился этим.
Введение
Почему важно обратить внимание на описание вакансии и внимательно отнестись к ее составлению?
По сути, описание вакансии - это лицо вашей компании или отдела. От того какое вы произведете впечатление и насколько сможете заинтересовать потенциального кандидата зависит как количество откликов, так и внимание к вашей компании, желание взаимодействовать с ней.
Грамотно составленная вакансия позволит как привлечь кандидатов, так и отсеять нерелевантные отклики, что сэкономит время, деньги и нервы.
Вакансии, не составленные должным образом, сталкиваются с проблемой слабой заинтересованности, малого количества откликов, что усложняет поиск кандидата и растягивает время закрытия вакансии.
Также на такие вакансии, наоборот, может поступать слишком много откликов, что может отразиться на времени разбора откликов и потенциальной потерей кандидатов (никто не будет ждать неделями пока вы разгребете завал).
Все это подводит нас к важности внимательного отношения к описанию вакансии.
Подготовка
Представьте себе, что вы читаете резюме кандидата. Что бы вы хотели видеть в этом резюме?
В первую очередь, некую структуру. Желательно, чтобы был написан реальный опыт, указаны достижения и чем человек занимался, какова была его зона ответственности, его роль и т.д. При этом, импонирует всегда ясность изложения, не шаблонность.
Во-вторых, указание каких-то дополнительных навыков, например, знание другого языка программирования, интерес к DevOps, наличие преподавательской деятельности и т.д.
В третью очередь, уже какая-то информация о человеке: чем увлекается, какие есть хобби и т.д.
Например:
Java-разработчик (октябрь 2020 - настоящее время)
Проект: сервис управления отчетными данными в соответствии с ФЗ (Федеральными Законами).
Задачи сервиса:
- Формирование отчета для дальнейшей отправки на подтверждение в ГосКомпанию
- Валидация отчетных данных
- Интеграция с ГосКомпанией
- Сбор отчетных данных через сторонние интеграции, API и ручную загрузку файлов в разных форматах
Стек: Java 8/17, Spring Boot, Spring Web, Spring Data Jdbc
БД: PostgreSQL
Тестирование: JUnit, Mockito, Testcontainers
Система сборки: Maven
CI: Gitlab CI
CVS: Git
Архитектура: Монолит
Обязанности:
- Разработка нового функционала в соответствии с требованиями заказчика (от системной аналитики до реализации)
- Интеграции с внешними системами
- Доработки в связи с появлением новых ФЗ
- Подготовка релизных сборок
- Написание и поддержание в актуальном состоянии юнит и интеграционных тестов
Достижения:
- Распаралелил вычисления по проверке формул соответствия ФЗ, что сократило время проверки с 1 часа до 13 минут
- Автоматизировал сборку и выпуск релизов
- Привил команде привычку работы с актуальной документацией в коде (JavaDoc)
О Себе:
- Стараюсь изучать новые ЯП, сейчас изучаю GO
- Обожаю кросс-фит
Структурно, сразу выделены блоки по достижениям и обязанностям, четко выделены границы ответственности.
А какие резюме вам обычно не нравятся? Правильно, те, что содержат глупые опечатки, размытость в том, что делал и за что отвечал человек, неструктурированность текста и т.д.
Согласитесь, что читать:
Java-разработчик
Разработка библиотек для интеграции в приложение заказчика.
Перенос с C# на Java.
Поддержка приложения на Java + Java Spring + Angular + Python
Тестирование на JUnit+ Mokito+Testcontainers.
Парсинг с XML используя библиотеку Saxon
Исправление багов, выпуск новых версий ПО.
Написание документации для пользователей и программистов
Уже не так приятно и даже банально понятно. По такому описанию сложнее сформировать даже портрет человека - нужно личное общение и уточнения, без этого ничего не понятно.
Ровно то же самое можно сказать и про описание вакансии. По сути описание вакансии - это обратная сторона резюме.
И относиться к этому стоит похожим образом, т.е. иногда даже подумать: а как бы я описал свое резюме, работая по этой вакансии?
Можно сказать, что поиск кандидата - это как маректинг, вам нужно 'продать' вакансию человеку. Чем более неряшливо оформлен ваш товар, чем больше на нем дефектов (опечаток, отсутствия структуры) - тем сложнее будет продать такой товар.
Портрет для найма
Перед тем, как писать текст вакансии желательно составить именно портрет для найма.
Иногда этот портрет составляется вместе с HR, иногда его вообще не будут просить вас составить, а сразу перейти к описанию вакансии - все зависит от организации и ее процессов.
Однако, я настоятельно рекомендую этот портрет составлять всегда, так как это поможет вам как на самих собеседованиях, так и с корректировкой вакансии.
Ну а HR это поможет на скрининг-интервью.
В этот портрет всегда входит:
* Технические компетенции
* Личностные качества
* Зарплатная вилка и бонусы
* Мотивация
Техническая часть
Здесь необходимо описать ожидания по хард-скиллам кандидата. При этом лучше разбить на обязательные скиллы и желаемые, которые будут плюсом.
Сюда же входит и опыт работы, возможно, опыт в предметной области.
Например:
Обязательно:
Опыт работы от 3-х лет.
Стек: Java 8+, Spring Boot, Spring Web, Spring Data Jdbc
Умение тестировать свой код и опыт написания как unit, так и интеграционных тестов.
Работал с микросервисами в продакшене.
Работал с реляционными БД и умеет писать SQL-запросы вручную.
Опыт разработки интеграционных решений (REST API, Kafka)
Будет плюсом:
Настраивал CI
Был опыт работы на других ЯП
Был опыт участия в разработке оpen source
Личностные качества
Здесь стоит остановиться и подумать о том, какие личностные качества вы бы хотели видеть в вашем сотруднике?
Например, у нас много интеграций с ГосКомпаниями, зачастую в новой интеграции нужно самому 'прокопать' как это сделать или найти документацию.
Вдобавок, старые интеграции иногда 'падают' из-за того, что сменился контракт, а нас не всегда об этом предупреждают.
Поэтому, мы ценим:
Целеустремленность, готовность работать в условиях неопределенности и самому находить оптимальное решение
Стрессоустойчивость
Спокойное отношение к legacy-коду и желание его улучшать
Зарплатная вилка и бонусы
Посмотрите на предыдущие разделы и на то, что можете предложить. Насколько адекватное соотношение вознаграждение-ответственность? Нет ли перегибов?
Бывают случаи, что описана серьезная область ответственности, при этом оплата труда не соразмерна. В таком случае вы уже на этом этапе подумаете - а не много ли мы требуем?
И сможете подкорректировать свои ожидания.
Мотивация
Тут важно понимать, что за мотивация у человека должна быть и явно это понимать.
Например, если вы разрабатываете финтех платформу, а человек хочет делать продукт и постоянно видеть результат работы у пользователей.
В таком случае, скорее всего, это не тот кандидат, который вам подойдет.
Советы по составлению
Основной и самый важный совет - это прямо представьте человека с нужными качествами и набором скиллов. Представьте его и постарайтесь описать.
При этом обязательно человека представлять как часть команды, вы не друга себе ищете, а коллегу и этому коллеге нужно будет ладить с командой.
Т.е. если вы, к примеру, спокойно относитесь к бранным словам, а в команде вы знаете, что люди не переносят такое - значит один из пунктов будет аккуратная речь. Несмотря на то, что конкретно вы - готовы работать с такими людьми, но это будет негативно влиять на коллектив и приоритет найма такого человека снижается для вас.
Если вы ищете человека, способного спокойно относится к горе легаси - значит это должно быть в портрете.
В команде много любителей настолок и вы собираетесь в офисе или онлайн на них? Значит это тоже можно внести как будет плюсом.
Я встречал случай, когда человек сделал предпочтение в пользу вакансии, так как компания имела ряд мероприятий нацеленных на борьбу за экологию: высадка деревьев, сбор батареек и пластика. И человеку это настолько импонировало, что для него это было дополнительным плюсом.
Также, если у вас есть возможность учить человека, то можно явно выделить это в вакансии. Можно даже разделить на то, в какой области вы готовы учить, и то, что вы ожидаете у кандидата как обязательные требования.
Шаблон
Для начала узнайте у вашего HR есть ли какой-то шаблон по вакансиям. Если вы работаете в плюс-минус большой компании, то скорее всего, этот шаблон есть и в нем уже заложены необходимые блоки. Если же нет, то подумайте над своим и для того, чтобы это было проще, рассмотрим основные блоки.
Эти блоки так или иначе встречаются (скорее всего) во всех шаблонах (можно судить даже по тому, что многие вакансии похожи по структуре).
Кто мы и информация о проекте/направлении
Представьте себе диалог с человеком, которого вы хотели бы рассмотреть как потенциального кандидата.
В начале каждого диалога по этикету принято представиться. Также и в вакансии.
Итак, первый блок - это кто вы. Про компанию обычно писать не надо, это делает HR. Ваша цель - это раскрыть направление, что вы делаете и ищете. Иногда это делает также HR, но скорее всего будет нужна ваша помощь.
Обычно такой блок так и называют:
* О нас
* Кто мы
* Немного о нас
Пример с Yandex (взято с официального сайта [Yandex вакансий](https://yandex.ru/jobs/vacancies/)):
Вертикали — это бизнес-юнит Яндекса, в который входят несколько крупных продуктов, объединённых одним вектором: развитием классифайдов (досок объявлений) в важных для жизни областях.
Внутри мы создали буткемп Java-разработки, который поможет на старте выбрать именно ту команду, которая вам подходит. В рамках этой программы вы проведёте по две недели в трёх разных командах, чтобы лучше понять их процессы и подходы к разработке, и приземлитесь в приоритетную для вас.
Немного о нас
Путешествия – сервис, который помогает пользователям самостоятельно организовать себе отдых или командировку под ключ.
Недвижимость помогает не только купить, продать, снять квартиру или коммерческую недвижимость, но и предоставляет достоверную информацию об объектах.
Аренда — удобный городской сервис, где специалисты помогают собственникам быстро сдать в аренду квартиры, а арендаторам — найти новый дом.
Или пример с VK (взято с официального сайта [VK вакансий](https://team.vk.company/vacancy/))
Дзен — сложная рекомендательная система и блог-платформа, которая помогает людям находить интересный контент, а авторам, медиа и брендам — свою аудиторию и единомышленников.
Сейчас мы ищем специалиста, который усилит нашу команду. Мы занимаемся как пользовательской частью, так и авторским продуктом, можно вживую пощупать все части большой контентной экосистемы. Любой рассказ о проекте будет востребован на технических конференциях и митапах — мы проверяли.
Проконтролируйте, что этот блок в вашей вакансии был описан верно, проверьте его на ошибки!
Из моего опыта были случаи, когда описание было настолько непонятным, что даже я не смог узнать того, что это в мое подразделение вакансия.
Этап знакомства пройден и далее надо переходить к делу, т.е. к тем задачам, которые надо решать в этой роли.
Чем предстоит заниматься
Этот блок схож с тем, что вы видели в разделе 'Обязанности' в резюме.
Иногда его называют:
* Задачи
* Чем предстоит заниматься
* Какие задачи вас ждут
* Задачи, которые нужно будет решать:
На примере тех же вакансий:
Какие задачи вас ждут
- Активное развитие по-настоящему масштабного бизнеса, понятного каждому, кто хоть раз ездил в отпуск или снимал (приобретал) жильё
- Проектирование, разработка и масштабирование микросервисов
- Решение продуктовых и инфраструктурных задач
- Создание и поддержка программного обеспечения от написания до выкладки в продакшн
- Обеспечение стабильной работы компонентов и оперативное решение проблем
И:
Задачи
- Разрабатывать видеопродукты, рекламу и другие форматы, отвечая за стабильность сервисов;
- Создавать новые разделы и страницы сайта;
- Работать над новой функциональностью и обеспечивать производительность и отказоустойчивость runtime;
- Влиять на каждый шаг в цикле разработки: от составления требований, проектирования решений до анализа и утверждения экспериментов.
Можете даже сравнить написанный выше в блоке 'Подготовка' раздел 'Обязанности' и то, что написано здесь, провести корреляцию.
И там, и тут описание было на Java Middle/Middle+.
Чем более размыто описание - тем больше воронка найма. А значит, возможна та самая проблема, когда откликов будет много, но многие из них будут не подходить уже на этапе разговора с HR или на техническом собеседовании.
Соответственно, если вам необходим более узкоспециализированный специалист - сформулируйте этот раздел более конкретно.
Например, у меня был случай, когда я приехал на собеседование по довольно стандартной вакансии Java разработчика (тогда еще офлайн собеседования все были) и наш диалог был примерно такой:
- Джавист?
- Да.
- С bluetooth работал?
- Нет.
- С IoT знаком?
- Нет.
- Видео кодеки знаешь?
- Нет.
- Пока.
- Пока.
Из плюсов: собеседование длилось примерно 20 секунд.
Из минусов: я ехал на собеседование полтора часа.
Стек
Я сторонник именно структурного описания стека. Больше всего мне не нравится, когда в одну строку записаны все ключевые слова, которые вспомнили при составлении вакансии.
Пример:
Стек: Java, Kotlin, Spring Boot, Spring Web, Spring Data Jdbc, PostgreSQL, Kafka, Redis, K8s, S3, Feign, Liquebase, Gitlab CI, JUnit, Mockito, ELK.
Что самое грустное - это не выдуманный пример. Для того, чтобы избежать проблем, ссылку на вакансию или откуда она, я давать не буду, но это известная большая компания и ее продуктом вы, скорее всего, либо пользуетесь, либо знакомы с ним.
Еще один реальный пример:
Мы ждем, что вы:
Писали веб-сервисы на Java: Java 17, Spring 5, Protobuf, gRPC, REST, ANTLR, PostgreSQL 15, S3, Docker, Ubuntu, Bash
Понять в этом наборе слов что-то очень тяжело, вдобавок ко всему они логичеки не сгруппированы и может создаться впечатление, что просто при составлении вакансии накидали то, что вспомнили и в том порядке как вспоминали.
Второй часто встречаемый неприятный момент - это когда не указаны версии. Например для фреймворков, ЯП и так далее. Почему так? Зачастую разница между мажорными версиями даже у библиотек настолько большая, что некоторым людям нужно время для освоения. Чего уж говорить о фреймворках или языках программирования.
Следите за тем, чтобы были указаны версии там, где они действительно важны и это играет роль: где были серьезные изменения в логике или поведению между версиями. Это можно обсудить даже с вашими разработчиками, если что-то для вас не прозрачно в разнице версий.
Например, укажите, версию ЯП, фреймворков, БД.
Возвращаясь к первому примеру, я бы оформил как:
Стек: Java 17, Kotlin 2.0, Spring Boot, Spring Web, Spring Data Jdbc, Spring Cloud OpenFeign, Liquibase.
Тестирование: JUnit 5, Mockito
БД: PostgreSQL 15, Redis
Брокер cообщений: Kafka
Файловое хранилище: S3 (MinIO)
CI: Gitlab CI
Эксплуатация: K8s
Работа с логами: ELK
После стека разработки уже идет блок ваших ожиданий от кандидата.
Ожидания
Этот блок в разных компаниях называют по разному:
* Требования
* Наши ожидания
* Мы ждем, что вы
Здесь по сути перечисляется то, что вы бы хотели видеть в кандидате: опыт, умение работать с конкретным фреймворком, знания виртуализации и так далее.
При этом, важно указать не только требования по техничеким скиллам, но и по ожиданиям от коммуникаций, возможно, какие-то личностные качества (если вы их ждете).
Особенно это важно в вакансиях, где необходимо (и вы знаете это) часто коммуницировать с сторонними командами, вендором и т.д.
Здесь же можно затронуть и культуру в компании/команде, например, если вы ждете, что человек должен будет спокойно работать в условиях неопределенности требований.
Например:
Наши ожидания:
- Опыт работы в роли Java разработчика от 3-х лет
- Опыт разработки интеграционных решений (REST API, Kafka)
- Опыт принятия архитектурных решений в проектировании распределенных систем
- Умеете тестировать свой код (Unit и интеграционные тесты)
- Проводили код-ревью
- Умеете работать в условиях неопределенности требований
Чем более размыто и обще вы здесь описываете требования - тем шире воронка, но и менее предсказуемые по набору качеств кандидаты.
Дополнительные ожидания
Здесь обычно есть еще подраздел про дополнительные (опциональные) пожелания. Это то, что по вашему дает кандидату дополнительные баллы при рассмотрении его на текущую вакансию.
Эти требования не обязательные и не стоит сюда записывать то, что является непосредственной частью работы или то, что вы ждете от каждого своего сотрудника.
Это именно дополнительные плюсы. Если вы считаете, что-то из этого раздела обязательным - перенесите это в раздел ожиданий.
Часто этот блок называтеся:
* Будет плюсом, если вы
* Дополнительным плюсом будут
* Будет плюсом
Например:
Дополнительным плюсом будут:
- Знания технологии контейнеризации Docker и опыт работы с K8s
- Разрабатывали отказоустойчивые сервисы и понимаете, как это делать
Бонусы
Ну и в конце обычно идет блок с бонусами.
Соответственно, если у вас, например, есть внутренние конференции, превосходный офис, возможность влияния на продукт - не стесняйтесь это здесь добавить.
Он также называется по разному:
* Что мы предлагаем
* Мы предлагаем
Суть раздела понятна - сделать вакансию более привлекательной и перечислить те бонусы, которые позволят склонить выбор кандидата в вашу сторону.
Например:
Мы предлагаем:
- Сложные задачи для сервисов с миллионами пользователей
- Гибкий график работы
- Расширенную программу ДМС
- Широкую образовательную программу: курсы, тренинги, участие в конференциях
- Питание за счёт компании
- Скидки в бассейнах, фитнес-центрах и магазинах-партнёрах
Итоговый шаблон
```md
# Название вакансии
## О нас
## Чем предстоит заниматься
## Стек
## Наши ожидания
## Дополнительным плюсом будет
## Мы предлагаем
```
Распространенные ошибки
Можно пройтись по пунктам как по чек-листу.
Неаккуратность и отсутствие структуры
Вакансии в которых:
* Опечатки, ошибки в названии фреймворков, технологий
* Каша в стеке - набор ключевых слов, которые не всегда даже связаны друг с другом
* Нет структуры
Чаще всего отталкивают и являются уже метрикой, что в самой компании (отделе) подобное отношение ко всему.
Избыточность подачи
Избыточный юмор или грубые шутки - зачастую будут минусом для вакансии.
Помните, что это как диалог и пока вы не знаете человека, то не стоит перебарщивать с юмором, сленгом, подколами.
Например:
Для тех, кто различает Java и JavaScript!
Вызовет скорее отрицательную реакцию и фейспалм.
Бывают менее резкие, но тоже странные строки:
Общесистемное ПО: Docker/Kubernetes — здесь всё крутим, катаемся;
Основная БД: PostgreSQL - а куда без слоника;
На мой взляд, это также лишнее, сленг не всегда уместен.
Размытость в описании
В вакансии лучше стараться описать конкретику того, что будет делать человек.
Если все, что вы готовы написать - это:
Задачи:
- Доработка старой системы.
- Перенос функциональности в новую.
То ваша позиция для найма будет закрываться с трудом. К слову говоря, это также не выдуманный текст - это реальная вакансия.
Размытое описание бывает и в требованиях, например:
- Владение инструментами контейнеризации, виртуализации и оркестрации;
- Умение разбираться в чужом коде и писать чистый и понятный код;
На мой взгляд, подобные строки не добавляют баллов к вашей вакансии для кандидатов.
Так как что именно хочет нанимающий - непонятно: какие именно инструменты ожидает? Или важен просто опыт работы с виртуализацией?
Умение писать чистый и понятный код тоже является каким-то абстрактным требованием, так как это понятие для каждого человека свое.
Лучше в таком случае прямо уточнить: что для вас чистый и понятный код.
Общие высказывания в описании не выделяют вашу вакансию. Цель как резюме, так и описания вакансии — это выделить вас среди других. Когда вы делаете общие заявления, то не выделяетесь из толпы.
Скрытие негативных моментов
Нельзя не упомянуть, что в вакансиях зачастую скрываются или просто не пишут важные моменты.
Например, обязательные on-call дежурства, включая выходные.
И на первых порах такое 'сокрытие' может помочь закрыть найм, но вот в дальнейшем может привести к достаточно быстрому уходу сотрудника.
У меня был пример перед глазами, когда в команду нанимали Senior-а и не сказали ему о таких вот дежурствах.
Человек был семейный, с маленькими детьми, и такие дежурства для него давались очень тяжело, что в итоге вылилось в его уход из команды.
Выделение определенной группы людей
Я такого не встречал, но на всякий случай - это сразу нет.
Нельзя выделять группы людей по каким-то признакам (пол, возраст, расса и т.д.), типа 'Вакансия только для разработчиков до 40 лет' - это даже незаконно по ТК РФ.
Пример 1 (плохой)
Это тоже реальная вакансия:
Требования:
- Опыт разработки на Java от 3 лет (Middle) или от 5 лет (Senior), с использованием 11/17 версий;
- Умение разбираться в чужом коде и писать чистый и понятный код;
- Опыт использования Apache Kafka, Kafka Connect;
- Работа на Spring Framework, Spring Cloud;
- Взаимодействие с Hibernate ORM, JDBC, JMX;
- Владение инструментами контейнеризации, виртуализации и оркестрации;
- Знание и опыт работы с PostgreSQL, реляционными БД, системами сборки Maven, Gradle и системой контроля версий Git;
- Опыт работы с инструментами Jira, Confluence, Jenkins, Sonar, Nexus;
- Опыт профилирования приложений - поиск утечек памяти, поиск bottleneck приложений;
- Опыт проектирования и разработки высоконагруженных, распределенных и отказоустойчивых систем;
- Умение профилировать приложения и оптимизировать их производительность.
Разделение грейдов по количеству лет работы - это губительная практика, смотреть надо по знаниям и навыкам/скиллам.
И раз вы все равно рассматриваете от 3 лет, то так и напишите, а грейд уже смотреть надо по результатам собеседования.
Версий не указано, что тоже камень в огород вакансии.
Рядом с Hibernate ORM, JDBC (что относится к работе с БД) почему-то стоит JMX, что вообще про другое.
Указано требование владения инструментами контейнеризации, виртуализации и оркестрации, но что в это входит? Здесь можно подразумевать что угодно.
Знание и опыт работы с PostgreSQL, после идут почему-то системы сборки и Git.
В общем, это не удачное описание требований.
Пример 2 (плохой)
Еще одна реальная вакансия (орфография и пунктуация сохранены):
Наш стек: Java 17/21 и Kotlin, Spring Boot, Spring Web, Spring Data Jdbc, PostgreSQL, Kafka, Redis, K8s, s3, Feign, Liquebase, Gitlab CI, JUnit.
Задачи:
- реализовывать серверную бизнес-логику приложений, интеграции с внешними ИС через API;
- участвовать в груминге фич со стороны бэка;
- работать в тесном сотрудничестве с фронтенд-разработчиками, QA-инженерами, аналитиками, devops-инженерами и продуктами;
- писать понятный и тестируемый код.
Требования
- от трёх лет опыта коммерческой разработки на Java c использованием Spring;
- знание паттернов микросервисной архитектуры;
- знание принципов ООП;
- знание и практический опыт работы с БД (SQL);
- опыт разработки интеграционных решений (REST API, Kafka);
- опыт работы с библиотеками и фреймворками для тестирования;
- желание работать в кросс-функциональной команде в Agile-среде.
Как вы думаете, вакансия на какой грейд перед вами?
Правильно, Senior Java Developer в известную IT-компанию в России.
Попробуйте самостоятельно найти в этом описании несколько проблем, что в нем не так.
Пример 3 (хороший)
Еще один пример:
Чем предстоит заниматься:
Разрабатывать новый и дорабатывать текущий функционал ДБО и инвестиционного проекта.
Мы используем:
Java 16, Spring Boot 2, Hibernate, PostgreSQL, Gradle, Intellij IDEA, GitLab, docker, K8s, Kibana, Prometheus, Grafana, YouTrack, Confluence/DokuWiki, Kafka, Mattermost.
Мы ждем, что ты:
- Уже разрабатывал на Java и Spring Boot от года.
- Имеешь представление о JMS, Hibernate, PostgreSQL.
- Слышал про Spring Cloud, Redis, Rabbit MQ, Kafka, будет здорово, если уже работал с ними.
- Умеешь работать с системой контроля версий Git.
- Знаешь классические алгоритмы и структуры данных.
- Хочешь создавать микросервисы.
- Любишь изучать и применять новые технологии.
- Читаешь техническую документацию на английском.
Из минусов я бы выделил не самую полную информацию (справедливости говоря, в вакансии написано что это за ДБО и у какого Банка) из раздела про ваши задачи.
А также камень в огород бросил бы за сумбур в 'Мы используем' - где и Kafka, и Mattermost с Intellij IDEA. Все же лучше было бы более структурное оформление.
Но в целом написано достаточно понятно, указаны версии, есть представление о том как это эксплатируется и мониторится, понятны требования к вам, как к кандидату.