55. Finding Research Problems
55.1Open Problems
Start from the field's own lists — they are unusually public and honest. Theory: BQP vs NP relations, non-abelian hidden subgroup (graph isomorphism's quantum status), dequantization's reach, barren plateau escape routes. Practice: real-time decoding at scale (Ch. 37's 1 µs constraint), magic-state distillation overhead, QRAM feasibility, verified quantum advantage. Curation sources: Aaronson's "semi-plausible quantum computing ideas" listings, problem sections of roadmap papers (IBM, Google, QuEra publish theirs), open questions sections of conference tutorials (QIP, TQC talks), and — richest for you — the "future work" sections of the papers you reproduce in Ch. 53. Method: maintain your own problem ledger; add every open question you meet with a note on why it interests you and what your angle might be. Taste is a ledger, curated over months.
55.2Literature Gaps
Gaps hide in plain sight; find them with search, not genius. Gap patterns: the missing baseline (method papers that never compared against the obvious classical competitor — Ch. 50.8 tells you these exist); the scale cliff (results demonstrated at n=6, claims made about n=100 — reproduce the curve, extend one point); the regime mismatch (decoder validated on depolarizing, deployed against crosstalk — 54.6's falsifier logic); the uncombined pair (two ideas proven separately, never together — barren plateau theory × your favorite ansatz). Technique: pick a niche, read its last three years chronologically, and build a claims matrix — paper × claim × evidence regime. The empty cells are your problem list, and you will see them before the community does because you built the matrix and they didn't.
55.3Engineering Bottlenecks
Your day-one advantage: every friction you personally hit in Parts VI–XIII is a candidate problem, because thousands of engineers hit it too and few write it up. The method: keep a friction journal — every time the tooling surprises you (a transpiler result that changes with seed, a noise model that misses a hardware behavior, a benchmark that measures the wrong thing), write it down with the minimal reproducing example. Then classify: bug (report it — OSS contributions are credibility), missing tool (build it — tools papers are real papers), or unsolved problem (formalize it — this is how research looks from inside). The field's history is full of such conversions: SABRE came from routing frustration; PyZX from circuit-rewriting frustration. Engineers who log friction are running a problem-discovery pipeline without knowing it.
55.4Scalability Problems
Problems that only exist at scale — the field's near-term goldmine, because simulation caps at n≈30–50 and hardware is just now crossing the ranges where these bite. Candidates with live 2025 momentum: transpilation time for 10,000-qubit circuits (compilation itself becoming the bottleneck), real-time decoding bandwidth (Ch. 37), calibration automation (per-qubit tune-up doesn't scale to thousands — ML calibration is a hiring field), pulse-level parallelism across large chips, and noise characterization that scales (randomized benchmarking at 1,000 qubits is its own research problem). Your angle: these are all software systems problems with physics constraints — distributed compilation, streaming decoders, control-plane latency — and the classical-systems playbook (profiling, scheduling, caching, concurrency) barely has been applied. Laptop-viable: everything in the compiler/control plane, via simulation and open calibration data.
55.5Noise Problems
The gap between noise as modeled and noise as lived is a permanent problem factory. Live fronts: noise drift (calibration ages by the hour — compilation and decoding strategies that adapt are open territory), crosstalk and spectator errors (present in every machine, absent from most models — measure, model, mitigate), leakage (states outside the qubit manifold, poisoning QEC — an underexplored decoding input), correlated errors (the known killer of surface-code assumptions), and error mitigation's scaling wall (ZNE/PEC overheads grow exponentially with depth — where exactly does mitigation die, per problem class?). Method note: noise problems are measurement-rich — many need only public calibration data plus clever statistics, which is precisely a laptop researcher's toolkit. One well-designed drift study on public data is a paper.
55.6Compilation Problems
Part XII's material, seen as a research field: open problems with real industrial pull. Noise-adaptive everything (layout, routing, scheduling against measured rather than modeled noise — 45.9 is young); ML-guided pass selection and parameter tuning (which passes, which order, for which circuit family — a genuine search problem); ZX-native compilation at production quality (near-optimal two-qubit counts exist in theory; productionizing is open); Pauli-network routing for chemistry at scale; and fault-tolerant compilation — lattice-surgery scheduling, magic-state traffic management, T-count optimization at the 10⁹-gate scale (the 2030s' compiler field, hiring now). Benchmark infrastructure itself is a problem (46.8's protocols are a 2022+ invention — the field's equivalent of ML benchmarks circa 2015). If you want a niche where your classical-compiler instincts are immediately differentiating, it is this one.
55.7Algorithmic Problems
Theory-side territory, entered through computation: empirically mapping barren plateau onset across ansatz families (the theory gives asymptotics; the constants are unmapped and laptop-measurable); dequantization stress-testing (take a structure-based quantum claim, attempt the classical sample-access version — Tang's playbook, applied to new targets); quantum walk and qubitization engineering (resource counts for real problems keep improving — each improvement is a result); new primitives hunting (28.7's open hunt, approached by systematically asking "what interference structure does problem class X have?"); and algorithm verification — certificates that a quantum computation was performed honestly (Ch. 44's research seam, with cryptographic weight). Honest sizing: most theory problems need mathematical maturity you'll build through Parts III and VIII; the empirical versions of theory questions are the laptop researcher's sweet spot — the field's theory is ahead of its measurement.
55.8Hardware/Software Interface Problems
The boundary itself — Ch. 2.16's design space — is under-engineered, and bilinguals are scarce. Live problems: dynamic-circuit programming models (mid-circuit measurement + classical feedback has no mature abstraction — what's the "async/await" of quantum control?); pulse-level portability across platforms; logical-qubit ISAs (what does the error-corrected machine's instruction set look like, and who designs its calling conventions?); calibration data as first-class API (drift-aware compilation needs streaming calibration — build the interface); and cloud batching/queueing economics for hybrid workloads (the 49.3 loop needs a scheduler; nobody has a good one). These problems reward exactly the profile this book builds: a software engineer who understands the physics stack well enough to design its interfaces. They are also the problems most likely to be paid to solve, in industry, from anywhere — Part XVI's geography-proof careers ride on this interface.
55.9Identifying Tractable Problems
The sizing filter: before loving a problem, grade its tractability against your actual resources. Laptop-sufficient: simulation-scale algorithmics (n ≤ ~30), compiler and tooling problems, decoder algorithmics (fast: Clifford simulators run thousands of qubits), noise-model analysis on public calibration data, and theory-*measurement* (constants and phase transitions in known asymptotics). Needs hardware access (free tiers exist — IBM's open plans, unitary fund credits — but designs around queues and quotas): anything claiming real-machine validity. Needs a lab or large collaboration: materials, device physics, multi-node quantum networks — table these for your affiliations era. Second axis, time-to-artifact: prefer problems where six months of honest work yields something publishable even if the main hypothesis fails (a careful negative result, a tool, a benchmark). The fatal error pattern is falling in love with an all-or-nothing problem; the professional pattern is a portfolio — one safe, one ambitious.
55.10Turning an Observation into a Research Question
The final conversion step, mechanical until it becomes instinct. Take any observation from your ledger — say, "the transpiled depth changed 40% when I changed the seed." Formalize it: what quantity (depth distribution over seeds)? Under what regime (which backend snapshot, which circuit family)? What's the competing explanation (routing luck vs. fundamental non-determinism)? What would distinguish them (correlate depth variance with topology slack at each n)? Now you have a question: "Quantifying routing non-determinism: how large is seed variance as a function of topology and circuit family, and does noise-adaptive layout reduce it?" — a laptop-sized, publishable, immediately useful study, discovered by noticing your own surprise. The template: observation → quantity → regime → hypotheses → discriminator → sized question. Run every friction-journal entry through it monthly; most won't convert, and the ones that do are yours — found in territory the community hasn't mapped because nobody else logged the surprise.