Dry Run

Inspiration

Coding interviews are about more than writing code. You need to explain your thinking, defend your approach, handle follow-up questions, and recover when something doesn't work.

Most coding practice platforms focus on the final answer: you write code, run tests, and see whether it passes. We wanted to practice a different skill: solving problems by explaining your reasoning out loud.

That's why we built Dry Run. It acts as an interviewer who knows the solution but won't give it away. Instead, it asks questions and gives small hints to help you figure things out yourself.

What it does

Dry Run is a Mobile app for practicing coding interviews by voice. There's no code editor or multiple-choice questions. You explain your approach, and the tutor responds to what you actually say.

Here's how a session works:

Read a coding problem and start speaking.
Review and edit the transcript if speech recognition gets something wrong.
Discuss your approach with the tutor as it asks follow-up questions, presents failing cases, and gives hints when needed.
Finish the session to see an assessment of your reasoning and a full solution write-up.

The tutor doesn't simply tell you whether you're right or wrong. It tries to help you discover what's missing in your approach.

For example, suppose you're solving Pair Sum with (n \leq 10^7) and suggest checking every possible pair. Rather than immediately suggesting a hash map, the tutor points out that this would mean examining roughly (5 \times 10^{13}) pairs and asks how you could avoid checking them all.

At the end, Dry Run evaluates the ideas you actually expressed. Each credited insight is linked to a quote from your own words and marked if you needed a hint to reach it. It also highlights the parts you haven't figured out yet.

How we built it

The app uses Flutter on Android, with a Cloudflare Worker handling requests to the AI services.

The main stack:

Mobile app: Flutter, SQLite, and Drift for local sessions, transcripts, and streaks.
Backend: Cloudflare Workers with Hono and D1. The database is used for usage limits, not conversation history.
AI reasoning: NVIDIA Nemotron 3 Super 120B through Nebius Token Factory.
Speech recognition: Groq Whisper (whisper-large-v3-turbo).
Transcript correction: Llama 3.3 70B, used to fix common speech-recognition mistakes in technical terms.

Nemotron handles most of the AI work, but we use it for several separate tasks:

Tutoring: Generates follow-up questions and hints while keeping the solution hidden.
Progress tracking: Checks which key insights the learner has already expressed.
Final assessment: Evaluates the learner's approach, complexity analysis, and understanding.
Evidence checking: Verifies that every credited insight is supported by something the learner actually said.
History compression: Keeps long conversations within the available context budget.

The server stores the private reference material for each problem, including expected approaches, key insights, hints, and terms that could reveal the solution. This material never needs to be sent to the phone.

We also added a shared AI key with a daily token budget so judges can try the app without setting up their own account or API key. Users can alternatively provide their own Nebius key, which is sent with requests and never stored.

When the daily voice quota is exhausted, the app falls back to the phone's speech recognizer.

Challenges we ran into

1. Keeping the tutor from giving away the answer

The model naturally tends to be helpful by explaining the solution. We went through several prompt iterations and added a server-side leak filter that checks draft replies for problem-specific forbidden terms before they reach the learner.

2. Making the final assessment fair

Early versions sometimes credited learners for ideas the tutor had suggested or for answers they had merely agreed with. We changed the judge to require a quote from the learner for every credited insight, then added a separate evidence check to reject unsupported credits.

3. Handling empty structured responses

With Nemotron's reasoning enabled, some structured outputs, including final assessments, came back empty. We kept reasoning enabled for the tutor's streamed replies but disabled it for structured calls, which fixed the issue we were seeing.

4. Fixing technical speech-recognition errors

Speech recognition can turn terms like "hash map" into something completely different. We provide problem-specific vocabulary, run a transcript-correction pass, and let users edit the transcript before submitting it.

5. Keeping track of the conversation

Without explicit progress tracking, the tutor sometimes repeated questions about ideas the learner had already covered. We added a progress check after each turn so the tutor can build on what's already been established.

6. Keeping the solution private

The reference solution and evaluation material stay on the server, while sessions, transcripts, and streaks stay on the device. Audio and transcripts aren't stored by our backend.

Accomplishments we're proud of

Building a voice-first coding practice experience without a code editor or tap-to-answer questions.
Making the tutor guide learners without immediately revealing the solution.
Building an assessment pipeline that checks its own evidence instead of blindly trusting the judge's output.
Creating a regression test harness using real tutor and judge transcripts to catch problems when prompts or evaluation logic change.

What we learned

Getting an AI tutor to avoid saying certain things can be just as important as teaching it what to say. Prompts alone weren't enough, so we added checks in code.
Different AI tasks need different settings. Reasoning helped with tutoring but caused problems with some structured outputs.
Voice interfaces need a way to recover from mistakes. Letting users correct a transcript before submitting it made the experience much more practical.
Evaluating how someone thinks is harder than checking whether a final answer is correct. The assessment needs evidence, not just confidence.

What's next for Dry Run

We'd like to expand the problem set to include graphs, dynamic programming, and introductory system design.

We're also planning a dedicated interview mode with a timer, deeper follow-up questions, and a final mock interview assessment.

Finally, we'd like to move speech recognition to Token Factory if a suitable model becomes available, bringing more of the AI workflow under one provider.