Что произойдёт после кнопки «Отправить решение»

Сначала ты получишь одну общую интеграционную задачу: контекст, ограничения, критерии готового результата и шаблон сдачи.

Затем разберёшь требования и соберёшь первую версию технического артефакта:

— схему взаимодействия;

— контракт;

— один негативный сценарий.

Это будет не тест с заранее выбранным вариантом ответа. Решение нужно собрать самому и сдать в установленном формате.

После сдачи пройдёт групповой разбор повторяющихся ошибок на обезличенных примерах. Обратная связь строится в одном формате:

Наблюдение: что видно в решении.
Риск: где решение сломается.
Правка: что изменить.
Критерий: как понять, что исправлено.

Из разбора ты применишь к своей версии одну релевантную правку. Готовое решение за тебя не дорисуют: исправленный участок нужно собрать самостоятельно.

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

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

Так будет устроен пробник:

собственная версия
→ групповой разбор
→ одна релевантная правка
→ самостоятельное исправление
→ изменённое условие
→ защита решения

Почему мы строим практику именно так, а не выдаём ещё десять уроков по интеграциям?

Потому что знакомство с темой и способность применить её — не одно и то же. Это хорошо видно в истории Ивана Ломакина.

Курс пройден. Отдельные знания есть. Что дальше?

Иван пришёл ко мне после курса Яндекса и с полутора годами аналитической работы. Но отдельные технологии всё ещё не складывались в общую картину.

Между этим моментом и техническим интервью, которое Иван позднее назвал лучшим, не было ещё одного просмотра всех тем по кругу. У его собственных работ начали появляться следующие версии.

Знакомые темы, которых не хватало в работе

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

REST, базы, UML и интеграции не были для него неизвестными словами. Трудность начиналась там, где из них нужно было собрать собственное решение, а затем объяснить его другому человеку.

На старте Иван хотел глубже участвовать в системном анализе и выйти на следующий карьерный уровень — от 200 тысяч рублей.

У работы появилась следующая версия

Бодрого старта как из рекламного ролика не случилось. Первую домашнюю работу Иван откладывал, извинялся за задержку и переживал, что снова её не сделал.

В апреле он всё-таки сдал задание, и я его прокомментировал. Затем Иван нашёл рабочий ритм — две темы в неделю. В сообщениях стали появляться требования, базы данных, UML, BPMN и интеграции.

Он приносил новые задания и возвращался к прежним. В конце мая написал:

По этой фразе нельзя восстановить конкретную ошибку в схеме или содержание правки. Подтверждён только сам цикл: Иван принёс работу, получил комментарий и вернулся с доработанной версией.

Вместо общего «нужно подтянуть System Design» появилась конкретная работа, к которой Иван вернулся после комментария.

Знать ответ недостаточно

Та же проблема обнаружилась в самопрезентации.

Иван записал рассказ о себе и отправил мне. Я отметил повторы, проблемы с последовательностью и нехватку конкретики: предложил яснее показать рабочий процесс и точнее рассказать про SQL.

Следующая запись стала последовательнее, но растянулась на шестнадцать минут. Значит, задача изменилась: теперь нужно было убрать подробности и распределить внимание между основными проектами.

Это важная часть механизма. Исправление первой ошибки не делает ответ окончательным. Оно открывает следующий уровень проверки.

На моке ответ пришлось собирать вслух

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

После мока вместо общего «надо ещё подготовиться» появился адресный список.

В разборе я отметил сильные ответы по REST и HTTP, нотациям и связям баз данных. Повторить стоило требования, архитектуру, BPMN, асинхронное взаимодействие и порядок сообщений. Рассказ о себе — сократить: меньше первого места работы, больше текущего.

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

Обратная связь не осталась в переписке

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

Иван собрал мои замечания, мок, резюме, HR-интервью и слабые темы в Cursor. Из этого сделал восемь тематических документов и короткую подготовку перед интервью.

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

В большом маршруте Ивана получился тот же принцип:

собственная версия
→ внешняя проверка
→ конкретное замечание
→ самостоятельное исправление
→ следующая попытка

«Думаю, лучшая моя техничка»

Поиск шёл не по красивому сценарию. Были сомнения, мало вводных интервью и отказы.

В августе на интервью в ОИС Иван онлайн описывал REST-интеграции в PlantUML. После разговора написал:

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

Затем появились два предложения. Иван сравнил условия и команду и выбрал ОИС с начальной зарплатой 230 тысяч рублей на руки на первые три месяца.

Было бы удобно приписать этот результат одной правке в System Design. Но между ними были месяцы работы: задания, мок, исправления, реальные интервью, отказы и самостоятельная подготовка Ивана.

Кейс не доказывает волшебную силу одного комментария. Он показывает наблюдаемую последовательность: собственная работа, внешняя проверка, исправления и новые попытки.

В пробнике мы берём один цикл, а не четыре месяца

За пять дней ты не повторишь весь путь Ивана. И не должен.

Ты возьмёшь одну стандартизированную интеграционную задачу, соберёшь первую версию и пройдёшь групповой разбор. Затем применишь к своей работе одну релевантную правку и проверишь решение на изменённом условии.

На руках останутся:

— первая и исправленная версии;

— интеграционный артефакт;

— ответ на изменённое условие;

— честно маркированный технический кейс.

Если задача учебная, так и напишем. Коммерческий опыт дорисовывать не станем.

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