Interview Q&A Prep

Direct answers to the questions this project tends to invite, phrased the way you'd actually say them out loud.

"Walk me through the architecture."

Start with System Overview: React SPA on Cloudflare Pages, Firebase for state/auth, a self-hosted Judge0 instance for code execution, Cloudflare Workers for scheduled jobs. No traditional backend — explain why (solo dev, Firestore + Workers cover what a backend would own) rather than treating it as an omission.

"Why no backend server?"

Because a backend's job here — persisting state, enforcing access control, running scheduled jobs, executing code — is fully covered by Firestore + security rules, Cloudflare Workers, and Judge0 respectively, without paying the ongoing cost of operating a separate service as a small two-person team. See Challenges #4 for the honest tradeoff (harder-to-reason-about authorization logic in rules vs explicit API code).

"What was the hardest technical problem you solved?"

The content-scaling rewrite (import.meta.glob → sharded indexes). It's a good answer because it has a concrete constraint (Cloudflare's 20,000-file limit), a measurable before/after, and a real tradeoff (added complexity). Full detail: Content Pipeline and Challenges #1.

"How do you handle code execution safely?"

Judge0 CE already sandboxes execution (isolated processes, resource limits) — that's why it was used rather than building a sandbox from scratch. The engineering on top of it is fairness (per-language time/memory multipliers) and efficiency (fail-fast on first failing case, hidden tests fetched only at submit-time). See Code Execution.

"How would this scale to 100x the users?"

Firestore scales horizontally by design and the content layer was explicitly rebuilt to scale to 10k–20k questions before it needed to. The actual bottleneck at 100x load would be the self-hosted Judge0 instance — a single Oracle free-tier VM has a real compute ceiling. The honest answer is horizontal Judge0 workers behind a queue (which the Firestore-submission-as-queue pattern already half-anticipates) rather than claiming the current single-VM setup would hold.

"What would you do differently if you started over?"

Two honest ones: (1) the content-index rewrite would be designed in from day one instead of retrofitted once the import.meta.glob approach's ceiling became visible — cheap to say in hindsight, but the retrofit did happen before it became a production incident, which is the more important point. (2) Firestore security rules for a growing feature set (OA attempts, revision schedules, submissions, bank progress, all under different access patterns) would benefit from a lighter access-control abstraction layer sooner rather than accumulating rule complexity ad hoc.

"How do you keep question quality high with an AI-assisted content pipeline?"

verify_solution.py is a mandatory pipeline gate — no generated question ships unless its own reference solution is verified against its own generated test cases, across all supported languages. This exists specifically because of a real bug: a generated reference solution didn't actually pass its own hidden tests. That's a better answer than claiming perfect process from the start.

"Why self-host Judge0 instead of using a SaaS judge?"

Cost and rate limits at OA scale — see Tech Stack and Code Execution. Be ready for the natural follow-up ("what if the VM goes down") — the honest answer is that it's a single point of failure today, which is the right scope for current usage and the first thing worth changing before any serious scale-up.