LeetCode for Quantum Computing

The practice-problems section of Bosonic’s website is a LeetCode-style experience for quantum programming. It helps learners move from understanding quantum-computing ideas to constructing circuits and interpreting feedback on their solutions.

The practice alpha provides focused prompts, Python/Qiskit starter code, an in-browser editor and reference-based evaluation. My role centers on the learning experience, UI design and supervision of the practice section.

Reading an explanation of an algorithm does not necessarily prepare someone to implement it. Learners need bounded exercises, explicit success criteria and feedback that distinguishes an incorrect quantum state from a correct but unnecessarily expensive circuit.

Quantum solutions also cannot be judged by matching source code to a reference. Different gate sequences can prepare the same state, and measurement probabilities alone can miss relative-phase errors. The practice experience needs a meaningful correctness check while leaving room for alternative constructions.

Each challenge presents its difficulty, topic tags, requirements and a starter solve() function. The current catalog includes two-qubit Bell-state preparation, five-qubit QFT applied to the basis state |13⟩, and a five-qubit RealAmplitudes ansatz with fixed rotation parameters and linear entanglement.

The React and TypeScript workspace sends the problem identifier and submitted Python code to an evaluator API. The evaluator checks that solve() returns a Qiskit QuantumCircuit with the required qubit count and no classical bits, then constructs the submitted and reference statevectors. A fidelity threshold of 0.999 determines acceptance.

The result panel pairs the verdict and fidelity with circuit depth, total gates, single-qubit gates and a multi-qubit gate count labeled controlled gates. It also exposes execution errors and captured output. Code and the most recent result are saved per problem in browser storage, allowing a learner to return to an attempt without an account.

I contributed the practice-problems section within the broader Bosonic website. My role was UI design and supervision: shaping the challenge workspace and the way learners move between a prompt, their code and evaluation feedback.

The practice section brings the problem catalog, editing workspace and submission results into a single learning flow. It integrates with the project’s Python evaluator to present quantum-specific feedback within the wider Bosonic site.

The inspected alpha implements three challenge specifications with matching backend reference circuits. It supports submission, accepted and wrong-answer verdicts, execution and connection errors, side-by-side circuit metrics, reset controls and local progress tracking. These are implemented product capabilities; the repository does not provide learner-outcome or adoption measurements.

A Bell-state submission, for example, is evaluated against (|00⟩ + |11⟩)/√2. The reference uses a Hadamard followed by a controlled-X gate. A different construction can pass if its output reaches the fidelity threshold, while the metrics show how its circuit cost compares with that reference.

The QFT task evaluates the output for one specified input, and the VQE task evaluates a fixed ansatz state. These checks do not establish that a submitted circuit implements QFT for every input or performs a complete variational energy-optimization loop. The broader problem catalog and leaderboards remain roadmap items in this alpha.

Separating correctness from circuit cost makes the feedback easier to interpret. Statevector fidelity accounts for relative phases while allowing an irrelevant global phase; depth and gate counts give learners a second axis for improving an already correct answer. Those counts describe the submitted circuit, not a hardware-transpiled execution cost.

A small Python/Qiskit interface keeps the initial exercises focused. Although the platform’s introductory copy describes a broader language-agnostic ambition, the implemented submission path currently expects Python and a Qiskit circuit. Browser-local persistence similarly supports a lightweight alpha, with progress tied to that browser rather than synchronized through an account.

Clear prompts are part of the evaluation contract. The fixed VQE angles exist in the backend reference but are not listed in the displayed requirements or starter code; exposing that information is an important next improvement. More generally, each challenge should make its target, supplied parameters and scope of validation explicit so learners can distinguish a coding mistake from missing information.