Code โ€บ tail-villain

Why Study Sessions and Interview Mode Needed to Split

A Tail Villain note on study telemetry and the move toward a roadmap-level interview hub

tail-villainstudy-modeinterview-modetelemetryroadmapllm

Study mode was running, but I still did not feel settled. The conversation was there, yet the product was not really remembering where the learner stood or what still needed to be filled in. A chat log can store words, but a learning product has to keep more state than that.

This is not an algorithm problem. It is a Tail Villain development note about the study-session shape and the interview-mode direction I clarified on April 19.

The turning point was realizing that chat logs and learning state are not the same thing. Logs tell me what was said. State tells me what to ask next, what has already been understood, and what should survive when the user comes back later.

Approach

The first thing study mode needed was state, not just history. Fields like learner level, current milestone, running summary, next focus, progress, and confidence had to live with the session so the product could remember where the learner was.

I also treated study sessions as resumable lanes. If the same user came back to the same topic with the same coach, the system should route them back to the existing active session instead of starting from zero again. A failed shell session should not count as the real active one.

Interview mode needed the same kind of rethink. Real interviews do not stay inside a single topic. They move through introductions, resume questions, technical validation, behavioral questions, and closing feedback. That is why topic-scoped sessions felt too narrow. The better shape was a roadmap-level hub, with topic drills left as a narrower validation lane.

Troubleshooting

The easy mistake is to treat logs and state as one thing. A log tells the story of the conversation, but it does not tell me which milestone is active or what still needs to be checked next.

Another easy mistake is to use the word interview too broadly. A topic drill can look like an interview, but it is not the same experience as a full mock interview. If both live under the same shape, the product starts to blur its own purpose.

So I split the problem in two. Telemetry and session state were for study mode, and a roadmap-level hub was for interview mode. The split was not just technical; it matched the way the product is supposed to be used.

Complexity analysis

This work does not have algorithm-style complexity, but the design boundary was clear.

  • Study session state

    • Conversation history alone is not enough.
    • The product needs progress, next focus, and a durable summary to continue later.

  • Interview hub structure

    • Interview practice should sit at the roadmap level, not only inside one topic.
    • That matches how actual interviews move across multiple question types.

  • Telemetry

    • The important part is not how much was said.
    • The important part is what state the session ended in.

Implementation code

The main work that day was structural. Study mode had to remember more state, and interview mode had to move toward a roadmap-level hub instead of staying trapped inside a topic-scoped flow.

I separated the values that belong to the session from the values that belong to the conversation, and I made the product language match that split. Once those pieces were separated, the rest of the UI and backend work became easier to reason about.

Summary and reflection

The point of the day was not a single line of telemetry. It was deciding what Tail Villain should remember.

The product needed to remember where the learner was, what still needed work, and what kind of practice they were actually doing. Once that was clear, the difference between study mode and interview mode stopped feeling cosmetic and started feeling structural.