BQ Interview Prep — Cassie (Yue Liang)

Situation
Built VisoCode at AdventureX 2025 — multi-agent system turning plain English into animated educational videos. Agents were calling each other in circles with no state management, pipeline would spin forever and crash on complex prompts. Less than 2 days to demo.

Task
Learn LangGraph from scratch and redesign the entire backend architecture — not patch the loops, but rebuild properly — under a hard deadline with no room for error.

Actions
Min-knowledge principle: asked "what's the minimum I actually need right now?" → state management + conditional edges only. Spent 1 hour in Jupyter Notebook writing toy examples until those two concepts clicked. Didn't touch real code until then.

Source code dive: hit unexpected memory overflow mid-refactor — context growing unbounded on every retry. Docs had no answer. Went directly to LangGraph source on GitHub, traced message accumulation logic, found no truncation by default. Wrote custom routing function with retry counter + context truncation to force clean exit at threshold.

Stress test before merge: ran a batch of complex prompts to confirm loops were fully gone. Only merged after that passed.

Result
Video generation success rate ↑ ~50%. Infinite loop issue completely eliminated. System stable enough for a live demo. Won Most Technically Outstanding at AdventureX 2025.

Reflection
Three durable learning strategies: (1) Minimum knowledge principle — work backwards from the goal, find the smallest set of things you need to understand; reading everything ≠ learning what matters. (2) Toy prototype first — 1 hour in Jupyter saved hours of building on a wrong mental model. (3) Source code over docs — when docs fail on framework-level behavior, the source code never lies.

At AdventureX 2025, I was building VisoCode, a multi-agent system that turned plain English into animated educational videos. The biggest issue was that the agents kept calling each other in circles because we had no real state management, so on complex prompts the pipeline would spin forever and crash. We had less than two days before the demo, so patching it wasn't enough. I had to learn LangGraph from scratch and redesign the backend properly under a hard deadline.

I started by asking what was the minimum I actually needed to learn right then. I decided the two critical concepts were state management and conditional edges. I spent about an hour in a Jupyter notebook writing tiny examples until those clicked, and only then touched the real code. During the refactor I hit a second issue: memory usage kept growing on retries. The docs didn't explain it, so I went directly into LangGraph's source code, traced how messages were accumulated, and found there was no truncation by default. I then wrote a custom routing function with a retry counter and context truncation so the graph would exit cleanly instead of looping forever. Before merging, I ran a batch of complex prompts to make sure the loops were gone.

That refactor improved video generation success rate by about 50%, eliminated the infinite loop issue, and made the system stable enough for a live demo. We ended up winning Most Technically Outstanding at AdventureX 2025. The biggest lesson for me was how to learn fast under pressure: focus on the minimum knowledge you need, prototype before integrating, and when the docs stop helping, trust the source code.

Situation
Building AlgoMentor, an AI coding tutor. Before designing the hint system, talked to several friends grinding LeetCode. Consistent finding: LeetCode hints are one big block that reveals the approach — everyone uses them the same way (get stuck → click → read → write answer). Deeper finding: people get stuck at 3 distinct levels — concept (what data structure?), strategy (how to apply it?), implementation (how to code it?). LeetCode's hint doesn't distinguish between these.

Task
Design a hint system that makes users actually think — and enforce that through system design, not by asking users to be disciplined on their own.

Actions
3-level hint design: L1 = Socratic question ("what data structure gives O(1) lookup?") — targets concept. L2 = directional hint ("try a HashMap to track what you've seen") — targets strategy. L3 = pseudocode skeleton — targets implementation. Each level exactly matches the type of stuck.

Friction gates: time delay between levels to prevent click-through. Started at 5 minutes — users said it felt punishing. Tuned down to 2 minutes — long enough to force a real attempt, short enough not to frustrate.

Prompt chaining with strict constraints: each level has its own system prompt with explicit guardrails — L1 can never hint at strategy, L2 can give direction but no code, L3 can give structure but not the core logic. Enforced by the system, not the LLM's judgment.

Result
Click-through-all-hints behavior dropped significantly. Users started working through problems in steps. The system solved a different problem than LeetCode's hint — not just less information, but the right information at the right moment for where the person was actually stuck.

Reflection
Good product design changes behavior by changing the environment, not by asking users to try harder. A friction gate > a message saying "please think before you click." One is a system constraint, the other is just a suggestion. Next: data-driven delay tuning per problem difficulty; adaptive starting hint level based on user history.

When I was building AlgoMentor, an AI coding tutor, I started by talking to friends who were grinding LeetCode. The pattern was really consistent: LeetCode hints come as one big block, so people use them the same way every time. They get stuck, click, read the approach, and then basically write the answer. What I noticed, though, was that people actually get stuck at three different levels: concept, strategy, and implementation. The existing hint design treated all of those as the same problem.

So my goal was to design a hint system that still helped people, but forced them to think in the right sequence. I built a three-level structure: level one was a Socratic question for the concept, level two gave directional guidance for strategy, and level three gave pseudocode structure for implementation. Then I added friction gates between levels so users couldn't just click through instantly. I started with a five-minute delay, but users said that felt too punishing, so I adjusted it down to two minutes. I also used separate prompts and strict constraints for each level, so the model literally could not jump ahead and reveal too much too early.

The result was that people stopped blasting through all the hints at once and started working through problems step by step. The key lesson for me was that good product design changes behavior by shaping the environment. If you want users to think more deeply, it's much more effective to build that into the system than to rely on them to self-regulate.

Situation
YouDescribe — platform where volunteers write audio descriptions of YouTube videos for visually impaired users. Volunteers review their descriptions at 1x speed (natural for sighted people). Real users listen at 2x–3x (trained over years). A description that sounds perfect at 1x becomes rushed and hard to follow at 3x. Our entire quality measurement baseline was wrong. Nobody had flagged it. Not in my sprint.

Task
Fix the quality measurement baseline gap — without being asked, and without making volunteers feel judged or criticized.

Actions
Communicate before coding: raised in standup with a clear explanation of the 1x vs 3x gap and why it mattered for quality measurement. Got lead's agreement before writing a line of code.

Built Playback Speed Simulator: required 3x playback before submit, no option to skip. Built in React and TypeScript, wired into existing Google Cloud TTS audio pipeline.

Deliberate UX framing: "preview how your description sounds to users" — not "check if your description is good enough." The first is informational. The second is evaluative. That difference matters because these are volunteers doing something generous.

Result
Volunteers immediately started self-correcting — hearing their description at 3x and going back to edit without anyone telling them to. Description length dropped, quality scores went up, user-side feedback improved. Designed and shipped entirely without being asked.

Reflection
Best way to build user empathy into a product: make the people building it actually experience what users experience. If I'd thought about this earlier, I would have been testing AI descriptions at 3x from day one. Next: talk directly to visually impaired users to validate whether 3x is the right benchmark; possibly make it user-configurable rather than hardcoded.

At YouDescribe, volunteers write audio descriptions for YouTube videos so visually impaired users can follow the visual content. I noticed a hidden gap in how we measured quality: volunteers reviewed their descriptions at 1x speed, which feels natural if you're sighted, but many real users listen at 2x or 3x because they're very experienced. That meant a description that sounded fine to volunteers at 1x could feel rushed and hard to follow for the actual audience. It wasn't in my sprint, and nobody had flagged it yet, but I felt it was a core product quality issue.

I raised the issue in standup first so the team understood why it mattered, then I built a Playback Speed Simulator in React and TypeScript and wired it into the existing Google Cloud TTS pipeline. Before submitting, volunteers had to hear the description at 3x speed. I also paid a lot of attention to the framing. Instead of presenting it as a quality check, I framed it as a way to preview how the description sounds to users. That mattered because these were volunteers doing generous work, and I didn't want the experience to feel judgmental.

The result was that volunteers immediately started self-correcting. They would hear the description at 3x, realize it felt rushed, and revise it on their own. Description length dropped, quality scores improved, and user-side feedback got better. The lesson for me was that one of the best ways to build customer empathy into a product is to let the people creating it experience what the user experiences.

Situation
At Deloitte, a major bottleneck in audit engagements was data heterogeneity. Every client provided journal entry data in different formats with custom charts of accounts. Before any analysis could happen, we needed apples-to-apples comparability. The team was spending 1 to 2 days manually cleaning and mapping thousands of client-specific accounts to our standard internal taxonomy, and the process was highly prone to silent human error.

Task
I needed to build an automated, scalable solution to ingest this unstructured client data, standardize it, and map it reliably, so the team could focus on risk assessment instead of manual data entry.

Actions
I designed and built an automated ETL pipeline using Python and pandas. First, I created a data normalization layer that ingested raw CSV and Excel files, handled encoding issues, stripped whitespace, and normalized column names so downstream logic could run on a consistent schema.

Second, I built a rule-based mapping engine. It first used a hash map for O(1) exact matching against a historical master dictionary, which categorized about 70 to 80 percent of standard accounts instantly. For the remaining entries, I added a regex-based fuzzy matching layer to catch slight naming variations.

Third, and most importantly, I designed the system not to guess. Any entry that did not meet a high-confidence threshold was routed into an Exception Log. That validation layer made sure ambiguous data never silently slipped through the pipeline.

Result
The pipeline reduced data preparation and mapping time from up to 2 days to about 3 hours per engagement. By generating the exception log, I shifted the team's workflow from reviewing 100 percent of the data to reviewing only the roughly 10 percent of edge cases that actually required human judgment. It also guaranteed consistent account mapping for downstream risk models.

Reflection
The biggest engineering lesson for me was to never let an automated system fail silently. By explicitly isolating unmapped or low-confidence items into a validation layer, errors were caught at the ingestion stage rather than deep in the analysis phase. That mental model — designing strict validation and exception handling before core processing logic — is something I carried forward into later pipeline work, including BERTScore.

At Deloitte, one of the biggest bottlenecks in audit engagements was journal entry data heterogeneity. Every client sent financial data in a different format with its own chart of accounts, so before we could do any analysis, the team had to spend one to two days manually cleaning and mapping thousands of account names into a common internal taxonomy. It was slow, repetitive, and very prone to silent human error.

I built an automated ETL pipeline in Python with pandas to standardize and map that data reliably. First, I added a normalization layer to ingest raw CSV and Excel files, handle encoding issues, trim whitespace, and normalize column names. Second, I built a rule-based mapping engine that used a hash map for exact matching against a historical master dictionary, which handled about 70 to 80 percent of accounts immediately, and then used regex-based fuzzy matching for close variations. Third, I explicitly designed the system not to guess. If a journal entry did not meet a high-confidence match threshold, it went into an exception log instead of silently passing through.

The result was that data preparation and mapping time dropped from up to two days to about three hours per engagement. More importantly, the exception log changed the team's workflow from reviewing everything manually to reviewing only the roughly 10 percent of edge cases that actually needed human judgment. The biggest lesson for me was that automated systems should never fail silently. If confidence is low, the system should surface the ambiguity instead of pretending it knows the answer.