10 вопросов и 4 сигнала — Valentin Zabotin

10 вопросов и 4 сигнала: где твой реальный разрыв на техсобеседованиях

  • REST
  • Kafka
  • БД
  • System Design
Валентин Заботин
Valentin Zabotin | Team Lead SA @ Beeline
#системныйанализ #техсобес #REST #Kafka #SystemDesign
Канал в Telegram
@valentin_system_analysis

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

Это происходит из-за практико-ориентированного разрыва. На работе ты годами обслуживаешь чужую архитектуру: правишь готовые JSON-схемы, пишешь ТЗ на добавление новых колонок в таблицы и переиспользуешь чужие REST-методы.

Нанимающий менеджер в финтехе, бигтехе или екоме ищет не оператора готовых решений. Он ищет инженера, который умеет проектировать с нуля и аргументировать свой выбор.

Ниже — конкретные сигналы, которые рынок считывает на собеседовании. Проверь, на какой стороне находишься ты.


1. Интеграции и проектирование REST API

Мем: добавил поле в контракт — думаю что умею REST

❌ Твоя иллюзия опыта:
Ты считаешь, что умеешь в REST, если можешь добавить новое поле в готовый контракт или зафиксировать в ТЗ то, что сказал тебе разработчик. Ты годами дорабатываешь одни и те же API и думаешь, что это уровень Middle.

✅ Сигнал для рынка (уровень 200к+):
Интервьюер смотрит на твое мышление и умение жонглировать ограничениями методов. Сильный кандидат сам объясняет:

  • Какие данные безопасно передавать в открытом виде через query, а какие обязательно прятать в body.
  • В каких случаях для POSTметода критически важна идемпотентность, а когда ее реализация избыточна и только усложнит разработку.
  • Как правильно реализовать фильтрацию и пагинацию при получении данных.

🛠 Как преодолеть разрыв:

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


2. Асинхронное взаимодействие (Kafka)

Мем: 3 года работы с Kafka — написал в ТЗ подписаться на топик

❌ Твоя иллюзия опыта:
В твоем проекте Kafka уже развернута архитектором. Вся твоя работа сводится к тому, чтобы написать в ТЗ «надо подписаться на существующий топик» или поправить схему payload. Ты заявляешь «3 года работы с Kafka», но это прокси-опыт.

✅ Сигнал для рынка (уровень 200к+):
На секции тебя попросят набросать решение с нуля в онлайне. Рынок ждет, что ты:

  • Сам обосновываешь, где в архитектуре нужен синхронный REST, а где — асинхрон (Kafka).
  • Четко выделяешь, кто Producer, кто Consumer.
  • Аргументированно выбираешь ключ партиции, понимая, как он повлияет на порядок обработки сообщений.
  • Понимаешь разницу в гарантиях доставки (at-most-once, at-least-once, exactly-once) и выбираешь нужную под бизнес-задачу.

🛠 Как преодолеть разрыв:

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


3. Проектирование Баз Данных и SQL

Мем: я проектирую базы данных — согласовал новую колонку

❌ Твоя иллюзия опыта:
Ты писал SELECT с джоинами, открывал схему в DBeaver и согласовывал добавление новой колонки в таблицу с архитектором. Ты думаешь, что умеешь проектировать БД, но по факту — ты просто читаешь чужую схему.

✅ Сигнал для рынка (уровень 200к+):
Интервьюер дает устный кейс (бизнес-требование). Твоя задача — с ходу перевести домен в модель данных. Сильный аналитик:

  • Без подсказок выделяет сущности, отличая их от атрибутов.
  • Видит разницу между связями 1:N и M:N в конкретном бизнес-процессе.
  • Объясняет, под какой конкретно запрос он ставит индекс и по какому полю.
  • Понимает нормализацию, но знает, когда нужно осознанно пойти на денормализацию ради скорости чтения.

🛠 Как преодолеть разрыв:

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


4. System Design (Архитектура)

Мем: прохожу System Design — сразу рисую квадратики

❌ Твоя иллюзия опыта:
Ты выучил термины: API Gateway, Redis, микросервисы. Ты пару раз нарисовал Sequence-диаграмму для двух систем. Тебе кажется, что ты понимаешь System Design. Но знание кубиков — не равно умению собрать решение под жесткие ограничения.

✅ Сигнал для рынка (уровень 200к+):
На секции смотрят на протокол твоего рассуждения вживую. Сильный кандидат:

  • Не кидается сразу рисовать сервисы. Он сужает задачу: задает вопросы про нагрузку (RPS), роли пользователей и критичность данных.
  • Нарезает осмысленные границы (модули/сервисы) и объясняет связность.
  • Проектирует отказоустойчивость: рассуждает вслух, что произойдет с данными и бизнес-процессом при падении конкретного узла.
  • Отказывается от лишних технологий. Он не пихает кэш везде, а аргументирует компромиссы.

🛠 Как преодолеть разрыв:

Используй алгоритм: Цель кейса → Ограничения (вопросы) → Границы сервисов → Выбор интеграции (sync/async) → Места осознанного упрощения.


🛑 10 вопросов для самодиагностики

Если ты собираешься откликаться на позицию Middle или Middle+ (или на зарплату от 200 000 ₽), задай себе эти 10 вопросов. На них сыплются 80% кандидатов с «тремя годами опыта». Отвечай вслух, не подглядывая в ChatGPT.

  1. Как вы определяете, какие данные безопасно передать в query, а какие нужно скрыть в body?
  2. В каких кейсах для POSTметода критически нужна идемпотентность, а когда она будет избыточна?
  3. По какому принципу вы выбираете ключ партиции для топика в Kafka? Что будет, если оставить его пустым?
  4. Как вы обоснуете бизнесу и команде выбор между синхронным REST и асинхронным взаимодействием для нового функционала?
  5. В каких случаях вы осознанно пойдете на денормализацию таблиц в базе данных?
  6. Как вы понимаете, под какой конкретно запрос нужно строить индекс и по какому полю, чтобы он реально ускорил работу?
  7. Как вы отличаете, где в вашей модели данных сущность, а где просто ее атрибут?
  8. Какие первые 3 уточняющие вопроса вы зададите на System Design секции, прежде чем начнете рисовать квадратики сервисов?
  9. Как вы определяете осмысленные границы между микросервисами, чтобы не превратить систему в распределенный монолит?
  10. Что произойдет с данными в вашей архитектуре при внезапном падении одного из критичных узлов?

Результат теста:

  • Ответил уверенно на 8-10 вопросов: Твоя техническая база в порядке. Если есть проблемы с офферами — дело в упаковке резюме или легенде.
  • Запинаешься, вспоминаешь, ответил на 4-7: Твоя насмотренность ограничена текущим проектом. Ты умеешь решать задачи, но не видишь систему целиком.
  • Меньше 3 ответов: Ты попал в ловушку рутины. Твой рост заморожен процессами компании.

Что делать дальше?

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

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

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

Залетай в канал и лови ближайший анонс разборов (вполне возможно, он висит там прямо сейчас):

Разборы с учениками

👉 Канал «Аналитик Маминой Подруги»

Подписаться на канал
@valentin_system_analysis

Made on
Tilda