Leaning on the Run-Tests Button vs Manual Dry-Runs in Timed Mocks
On most practice sites, the fastest loop is the run-tests button: write a solution, hit run or submit, read which test failed, tweak, and repeat until everything is green. It is quick and satisfying. The other habit is manual dry-runs in timed mocks: after writing a solution under a timer, you trace three cases by hand—a normal one, an edge case, and a tricky one—out loud, line by line, before you run anything or say "done."
Both involve testing. They train different skills. The useful question is narrower: when does quick test feedback help you learn—and when does a manual dry-run do more for the live round?
This is a workflow comparison, not a criticism of practice platforms. Automatic tests are a genuinely useful learning tool. Interview setups also vary: some rounds let you run code freely, some offer limited tests, and some expect you to reason without running it at all. Ask your recruiter. What stays stable is that interviewers usually want to see how you check your own code, not just whether a hidden test suite passes.
At a glance
| Category | Run-tests button loop | Manual dry-runs in timed mocks (Luna side panel optional) |
|---|---|---|
| Who finds the bug | The test suite | You, by tracing values |
| Test cases | Chosen by the platform | Chosen by you |
| Speed | Very fast feedback | Slower, deliberate |
| What gets practiced | Fixing until green | Choosing cases and reasoning out loud |
| Best for | Learning and checking correctness | Rehearsing how you test in a live round |
| Main tradeoff | Little practice picking your own cases | Can miss bugs a big suite would catch |
What the run-tests loop looks like
A typical session:
- You read the problem and write a first version.
- You hit run and see a failing case.
- You change a condition or an index and run again.
- After a few tries, everything passes.
- You submit and move on.
Honest strengths. Immediate feedback is a great teacher. Hidden tests catch edge cases you would not have thought of—empty inputs, duplicates, very large values—and seeing those failures teaches you which edge cases matter for each pattern. The loop is efficient for volume, and it confirms your solution is actually correct, which hand-tracing alone cannot guarantee. For learning a new pattern, that confirmation is valuable.
Honest limits. The loop can train a habit of guessing: change a plus one to a minus one, run again, see what happens. In a live round, that looks like uncertainty, and if running code is limited or slow, it simply does not work. The platform also picks the test cases, so you rarely practice choosing your own—which is exactly what an interviewer asks for when they say "how would you test this?" And because you never trace by hand, you may not notice you cannot explain why the fix worked.
When the run-tests loop wins: you are learning a pattern and want quick confirmation; you want to discover the edge cases a pattern usually has; you are building volume; or your interview lets you run code freely and you have already practiced explaining your tests.
What manual dry-runs in timed mocks look like
The mock version moves testing before the run button.
- Set the timer to the length of your real round, pick one fresh problem, restate it out loud, and say a two-line plan.
- Write the solution while narrating.
- Before running anything, choose three cases out loud: a normal case, an edge case (empty, single item, duplicates), and one that targets the trickiest line.
- Trace each case by hand, saying the value of key variables at each step.
- Fix anything you find, explain the fix in one sentence, and only then run the code if your setup allows it.
- Write a one-sentence postmortem: did your dry-run catch the bug, or did the tests?
Optional companion: Luna Interview is a Chrome extension framed as a practice / calm side panel—not a substitute for knowing the material, and never an "undetectable" live cheat. Keep it beside the pad while you own the plan, the code, and the testing.
Honest strengths. This practices what interviewers usually look for at the end of a solution: choosing sensible cases, tracing calmly, and explaining a fix instead of guessing. Picking your own edge cases becomes a habit, so "how would you test this?" stops being a surprise. Tracing out loud also tends to surface off-by-one errors before anyone else sees them, which looks steady and careful.
Honest tradeoffs. It is slower, and hand-tracing can miss bugs that a large test suite would find instantly. It is less satisfying than a green checkmark. And it needs a timer discipline: if you spend all your time coding, there is no time left to dry-run—which is a useful lesson in itself.
When manual dry-runs win: feedback said you did not test or tested only the happy path; you tend to hit run repeatedly without knowing why it fails; your round limits running code; or the interview is within a few weeks.
Decision table for candidate situations
| Your situation | Prefer the run-tests loop | Prefer manual dry-runs in mocks |
|---|---|---|
| Learning a new pattern | Strong fit—learn its edge cases | After the first few problems |
| Round limits or disallows running code | Light | Strong fit |
| Feedback: "didn't test before saying done" | Light | Strong fit |
| Change code and rerun without knowing why | Pause and trace first | Strong fit |
| Want to check final correctness | Strong fit, after your dry-run | Run once at the end |
| Interview in under a week | Light | Primary lane |
| Often run out of time before testing | Light | Strong fit—budget the dry-run |
A fair practical method (combine both in one week)
Do not choose by which feels faster. Test by hand first, then let the tests check you.
Learning sessions: Use the run-tests loop on new patterns. After each failure, write down the case that broke your code—that list becomes your edge-case vocabulary.
Rehearsal sessions (two or three a week): One fresh problem, timer at your real round length, restate out loud, two-line plan, narration, three hand-picked cases traced by hand, then one run. Keep a calm practice side panel beside the pad if you use Luna. Score only: dry-run done before time ran out, at least one edge case chosen by you, bug found by you rather than by the tests.
End of week: Compare your edge-case list with the cases you picked in mocks. Add any you keep missing.
Common mistakes / when NOT to use each
Skip the run-until-green loop when you are changing code without a reason, when you cannot explain why the last fix worked, or when your interview will not let you run code. Green tests are a check, not an explanation.
Skip mock theater when you run the code first and dry-run afterwards, pick only easy cases, or trace silently. Also skip any practice-tool framing that promises stealth help in a real employer interview—that is the wrong goal and the wrong integrity bar.
For both: solutions and AI are for study and postmortems, not mid-session rescue if you are training transfer. The skill is your code, checked by your cases, explained out loud.
Soft close
If your bottleneck is testing calmly at the end of a solution—picking good cases, tracing out loud, explaining the fix—Luna Interview is a Chrome side panel built for that practice loop, not for cheating or replacing study. Soft trial path: https://lunainterview.xyz/
Use the run-tests button to learn and to confirm. Use manual dry-runs to rehearse how you test in the round. The offer goes to the candidate who finds their own bug first.
Rehearse with an AI interview copilot, then browse commonly reported interview questions.