| 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. Выбирай по приоритету:
- Есть компетенция с
p_known < 0.4 и observations >= 2 → задача, которая её нагружает (см. таблицу-пример ниже — какая задача бьёт по какой компетенции)
- Есть свежая ошибка в mistakes_log (за последние 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).
