[Ezechungi7]

Description

Completed interview reports were rendered in isolation: when a candidate practiced another problem in the same study-plan category (such as 1D DP or Sliding Window) to work on a recurring gap, the finished report gave no comparison against their previous attempt in that category. When a candidate finishes a problem or opens a saved report in Past attempts and has an earlier assessed (HIRE or NO_HIRE) attempt in the same category and interviewMode (coding vs. whiteboard), the report card and its .md export now render a Category progress section naming the category, the prior problem title, date, and decision, alongside deltas for codingScore (or Board work), communicationScore, hintsUsed, same-rubric phase scores, and phase-anchored improvementPlan items.

scripts/gen-problem-cards.py emits web/problem-categories.json, mapping each scenario page name to its single study-plan section from scripts/top-interview-150.json and assigning "origin": "original" problems their deterministic non-container topic ("Design") in the generated map so the renderer needs no special case. loadCategoryMap() in web/problem-data.js fetches /problem-categories.json on demand when a report is rendered rather than embedding categories in web/index.html, keeping the initial lobby free of study-plan section labels before an interview starts. compareCategoryAttempt() in web/practice-insights.js looks up the prior attempt in the normalized entries returned by normalizeProgressEntry (web/progress.js:68), requiring entry.interviewMode === current.interviewMode so editor coding scores and whiteboard board-work scores are never mixed, and maps problemId to its category at render time so saved reports gain no new stored field and existing history participates automatically. Per-step REACTO/STAR score deltas are computed only when frameworkAssessment.rubricVersion matches on both attempts (rendering a version-boundary note otherwise), and improvementPlan items are paired by their closed phase label (web/progress.js:215) rather than string-matching model-written weakness prose.

Feature Example:

After doing a problem of the same category, report now generates:

---

Category progress · Binary Tree General

Compared with Fraud Rule Worst Case · 2026-10-24 · HIRE (previous problem in this category)

• Coding: 100 -> 100 (0)
• Interviewer communication: 90 -> 90 (0)
• Hints used: 0 -> 0 (0)

Step	Previous	Current	Change
Repeat	90	90	0
Example	85	70	-15
Algorithm	90	90	0
Coding	100	100	0
Test	90	90	0
Optimizations	75	75	0

• Algorithm (Flagged in both attempts)
  • Previous attempt: Provide a more detailed explanation of time and space complexity analysis during the discussion phase. (Drill: complexity narration)
  • This attempt: Explicitly state the time and space complexity in terms of the number of nodes and the height of the tree during your initial explanation. (Drill: complexity narration); When asked for complexity, provide both time and space complexity proactively as part of your initial design explanation. (Drill: complexity narration)
• Test (No improvement item flagged in this phase)
  • Previous attempt: Proactively discuss potential edge cases, such as a single-node tree or a highly unbalanced tree, before finalizing the code. (Drill: edge-case enumeration)
  • This attempt: No improvement item flagged in this phase.
• Optimizations (Flagged in both attempts)
  • Previous attempt: Consider discussing the trade-offs between iterative BFS and recursive DFS, specifically regarding stack space for highly skewed trees. (Drill: complexity narration); Explore potential optimizations for space complexity, such as using a recursive DFS approach to achieve O(h) space instead of O(n) for the queue. (Drill: complexity narration)
  • This attempt: While the solution is optimal, consider discussing the iterative approach using a stack or queue to demonstrate depth in handling large trees where recursion depth might be a concern. (Drill: complexity narration)

---

Recording

codetrial_topic_comparison_demo.mp4

Validated with:

• py -3.11 scripts/gen-problem-cards.py --check (passes; web/problem-categories.json is in sync with problem-bank/problems.json, web/problem-pages.json, and scripts/top-interview-150.json)
• py -3.11 scripts/run-python-tests.py tests/test_gen_problems.py (45/45 passed, including generated_categories mapping for study-plan and "origin": "original" problems and the --check drift failure when web/problem-categories.json is stale)
• node --test tests/browser/practice-insights.test.js tests/browser/render.test.js tests/browser/dom-contract.test.js tests/browser/leetcode-import.test.js tests/browser/account.test.js tests/browser/progress.test.js tests/browser/lib.test.js tests/browser/report-recovery.test.js (309/309 passed; Playwright Chromium browser cases in tests/browser/lobby.test.js skip locally without a local Chromium install and will run in CI)

Closes #393

[jserv]

This changes what the web pages show, so the pull request description must include screenshots of the result (before and after where something changed), with any personal data removed.

[jserv]

Rebase latest main branch and resolve conflicts.

[jserv]

Before asking someone to review, you MUST resolve any regressions flagged by GitHub Actions.

No merge conflicts at the current head.

[jserv]

Thank @Ezechungi7 for contributing!