practice

name

practice

description

Свободная тренировка — открытая задача области или короткий drill, без учебного плана. Триггерься на "/practice", "хочу потренироваться", "дай задачу", "дай челлендж", "порешаем что-нибудь", "challenge", "давай порешаем". Читает progress/competencies.json и mistakes_log чтобы подобрать задачу, которая бьёт в пробелы. Два формата: короткий drill (5-10 мин) или открытая задача (для доменов с постановкой задачи — по фазам с тайм-боксами). Не связано с curriculum.

Свободная тренировка

Практика — это не урок. Урок добавляет новое, практика закрепляет уже известное через применение в свежем контексте (interleaving, §1.4 R2). «Применить» значит решить задачу области вслух — оценивается процесс рассуждения, а не артефакт.

Когда использовать practice vs learn

• /learn — пройти следующую тему из curriculum (вводит новое)
• /practice — потренировать уже знакомое на новой задаче
• /quiz — короткий retrieval practice на факты области

Practice — для ситуаций, когда ученик хочет «просто порешать задачу» без большого фрейма урока.

Два формата

Формат A — короткий drill (5-10 мин)

Короткое сфокусированное задание на один навык. Такой навык требует повторений (§4.3 R2) и идеален для разогрева.

Задача: одна маленькая задача-прикидка/применение.

Что делаем: только то, что влияет на решение. Не считай/не разбирай то, что на решение не влияет.

Критерий: результат с нужным порядком/направлением + один вывод для дела.

Drill бьёт по конкретной базовой компетенции. Опорный материал — в доменном контентном скилле области.

Пример drill (область System Design) — estimation:

Задача: прикинь, сколько storage в год нужно сервису коротких ссылок, если создаётся 100M ссылок/день, средняя запись — 500 байт. Что считаем: только метрики, влияющие на дизайн (writes/sec, storage/год, нужен ли шардинг). Критерий: число с порядком величины + один вывод для дизайна («влезет в один Postgres / нужен шардинг»).

Бьёт по компетенции estimation_skill. Опорные числа — в estimation/references/.

Формат B — открытая задача (опционально, для доменов с постановкой задачи)

Если область предполагает развёрнутую «постановку задачи» (от требований до решения), полезен формат с фазами и тайм-боксами (§2.1 R2). Подача — сократическая: ученик начинает с наивного решения, проблемы всплывают по одной, он дорабатывает (§2.3 R2). Не вываливай условия и решение сразу. Если в области нет естественного деления на фазы — пропусти этот формат, используй Формат A или свободную задачу.

Пример фазовой структуры (область System Design — по структуре SD-интервью):

Фаза	Тайм-бокс	Что делает ученик
Requirements	~5 мин	Функц. (топ-3) + нефункц. (квантифицированные: «лента < 200мс»), выбор приоритета по CAP
Estimation	~3-5 мин	RPS, storage, read/write ratio — на салфетке
High-level design	~10-15 мин	Компонентная схема. «Не наслаивай сложность рано»
Deep dive	~10 мин	Итерация по нефункц. требованиям, поиск bottleneck/SPOF
Trade-offs	~5 мин	Разбор: какие развилки были, что выбрал и почему

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

Шаг 1: Выбор задачи

Прочитай progress/competencies.json и progress/mistakes_log.json. Выбирай по приоритету:

1. Есть компетенция с p_known < 0.4 и observations >= 2 → задача, которая её нагружает (см. таблицу-пример ниже — какая задача бьёт по какой компетенции)
2. Есть свежая ошибка в mistakes_log (за последние 3 сессии) → задача на ту же тему
3. Иначе — задача из текущего уровня ученика, от простого к сложному

Пример соответствия «компетенция → задача» (область System Design):

Пробел (низкий p_known)	Подходящая задача / формат
estimation_skill	drill estimation (формат A)
requirements_clarification	любая открытая система, фокус на фазе requirements
data_modeling	«спроектируй хранилище для мессенджера», «лента новостей»
scalability_thinking	«rate limiter», «URL shortener на 100M/день»
failure_thinking	«платёжный сервис» (что при отказе?), «выдержит ли при падении ноды?»
tradeoff_reasoning	любая система с явной развилкой (кеш? очередь? SQL vs NoSQL?)

Шаг 2: Банк задач (генерируется, не статичен)

Задачи генерируются по запросу, не хранятся в файле: состояние ученика (BKT, mistakes, scaffolding) меняется, и задача должна это учитывать. Держи градацию от простого к сложному.

Пример банка задач (область System Design) — открытые системы по сложности:

Сложность	Система
Простая	URL shortener, pastebin, rate limiter, counter сервис
Средняя	news feed, чат 1-на-1, notification service, file storage (Dropbox-lite)
Сложная	мессенджер с группами, search/autocomplete, ride-sharing matching, video streaming

Начинай ученика с простого. Сложную бери, только когда базовые шаги он проходит сам (proactiveness — главный маркер уровня, §3.2 R2).

Шаг 3: Сократическая подача и помощь

Скилл scaffolding определяет, сколько помогать. Два важных момента для practice:

• Не вываливай решение. Веди вопросами: «С чего начнём?» → ждёшь первый шаг → уточняющий вопрос → следующий шаг → «Где это упрётся при усложнении?» Наивное решение → проблема → доработка, пока выбор не станет логичным выводом (§2.3 R2).
• young_male_26 — предлагай помощь проактивно. Из-за help-avoidance он не попросит /hint, даже застряв. На сигналах застревания (пауза, «хм», повтор одной развилки) сам предложи направление — мягко, как опцию. Калибруй overconfidence: его «всё понятно» проверяй вопросом про невыбранный компромисс.

Если ученик застрял — эскалация подсказок из feedback/hint (вопрос → направление → worked example → прямая помощь).

Шаг 4: После решения

Независимо от того, насколько «хорош» результат — спроси (мета-рефлексия, помогает увидеть прогресс):

• «Какая развилка была самой сложной — и почему ты выбрал именно этот путь?»
• «Что бы ты уточнил в самом начале, если бы делал это снова?»

Затем дай фидбек по feedback: процессная похвала за конкретный ход + один сократический вопрос про невыбранный/необоснованный компромисс. Не «правильно/неправильно».

Обнови:

• profile.json: xp += 150 (практика даёт больше XP, чем урок — это retrieval, §1 R2). XP — информация о прорыве, не награда за задачу.
• mistakes_log.json: если всплыла типичная ошибка области — добавь запись
• competencies.json: если задача нагружала компетенцию — обнови observations (через diagnostics)

Правила

• Тайм-бокс. Для формата A — 10 минут. Для формата B держи фазы по времени, не давай зависнуть на одной фазе. «Время, давай зафиксируем и пойдём дальше».
• Не превращай в урок. Practice — это применение, не изучение. Если ученик вообще не знает, как подступиться к задаче → это не practice, а learn. Мягко переключи.
• Давай выбор. Нет настроения на одну задачу — предложи 2-3 альтернативы разной сложности (автономия, §1 R2).
• Не компенсируй слабое решение лекцией. Если задача далась тяжело — разобрали один компромисс, пошли дальше. Не разворачивай «а теперь я расскажу, как правильно» — во многих областях нет единственно «правильного».
• Первый вариант всегда наивный — даже у эксперта. Нормализуй это до разбора (§ нормализация ошибок в feedback).