Quantum Algorithms Explained with Code: Deutsch-Jozsa, Grover, and QFT

Overview

If you are working through quantum computing tutorials, there is a short list of algorithms that repeatedly appear in courses, SDK documentation, and interview-style discussions. Deutsch-Jozsa, Grover, and QFT are on that list for good reason. They each teach a different mental model for quantum programming:

• Deutsch-Jozsa teaches oracle-based reasoning and interference.
• Grover teaches amplitude amplification and iterative search.
• QFT teaches phase encoding and the structure behind more advanced algorithms.

For developers, these are not just historical examples. They are useful because they force you to understand the mechanics that show up elsewhere: Hadamard layers, phase kickback, ancilla usage, controlled rotations, measurement strategy, and the gap between ideal circuits and noisy execution.

This article is intentionally framed as a living reference. The exact import paths, simulator calls, and helper methods may shift across platforms, but the underlying circuit ideas stay stable. That makes these algorithms excellent anchors for a long-term quantum computing learning path.

Below, the code is written in a Qiskit-style Python format because it is readable and widely recognized in beginner and intermediate workflows. Even if you prefer another SDK, the circuit logic transfers cleanly. If you need a setup refresher, see our Qiskit tutorial for beginners. If you are comparing ecosystems before committing, our Qiskit vs Cirq vs PennyLane guide can help.

Deutsch-Jozsa in plain terms

The Deutsch-Jozsa problem asks whether a black-box function is constant or balanced. In the classic teaching version, the promise is that the function is one or the other. A classical algorithm may need multiple queries to gain confidence. The quantum version can determine the answer with one oracle call under the promise.

For developers, the value of Deutsch-Jozsa is less about practical deployment and more about learning three things:

1. How to prepare a superposition over all inputs.
2. How an oracle affects phase.
3. How interference reveals a global property of a function.

from qiskit import QuantumCircuit

n = 3  # input qubits
qc = QuantumCircuit(n + 1, n)

# Prepare output qubit in |1>, then apply Hadamard for phase kickback
qc.x(n)
qc.h(n)

# Put input register into superposition
for q in range(n):
    qc.h(q)

# Example balanced oracle: flip output for x0 XOR x1
qc.cx(0, n)
qc.cx(1, n)

# Interfere input amplitudes
for q in range(n):
    qc.h(q)

# Measure input register
for q in range(n):
    qc.measure(q, q)

print(qc)

The result interpretation is simple:

• If the measured input register is all zeros, the oracle behaves like a constant function.
• If the result is anything else, the oracle is balanced.

That simplified rule is why Deutsch-Jozsa is such a good introductory circuit. The visual pattern is easy to remember: initialize, Hadamard, oracle, Hadamard, measure.

The biggest implementation detail to watch is the oracle itself. Most confusion comes not from the algorithm but from incorrectly encoding the promised function. When revisiting this example later, it is worth checking whether your chosen SDK provides higher-level abstractions for oracles or whether you still need to hand-build them from CNOT and phase operations.

Grover in plain terms

Grover's algorithm solves an unstructured search problem by increasing the probability of measuring a marked state. This makes it one of the most cited examples in any grover algorithm tutorial. It is also one of the best ways to learn that quantum speedups are rarely “free.” You need to define an oracle, decide how many iterations to apply, and understand what happens when you overshoot.

At a high level, Grover works in two repeating phases:

1. The oracle flips the phase of the target state.
2. The diffusion operator reflects amplitudes around the average, amplifying the marked state.

Here is a small two-qubit example that marks the state |11>.

from qiskit import QuantumCircuit

qc = QuantumCircuit(2, 2)

# Start in equal superposition
qc.h([0, 1])

# Oracle for |11>: phase flip on the marked state
qc.cz(0, 1)

# Diffusion operator
qc.h([0, 1])
qc.x([0, 1])
qc.cz(0, 1)
qc.x([0, 1])
qc.h([0, 1])

qc.measure([0, 1], [0, 1])

print(qc)

In this small case, one Grover iteration is usually enough in the ideal simulator setting. As you move to larger search spaces, choosing the number of iterations matters. Too few iterations leaves probability spread out. Too many causes the amplitude of the target state to rotate away again.

That “rotation” perspective is useful because it explains why Grover is elegant but delicate. In notebooks and demos, the algorithm looks clean. On noisy hardware or under imperfect oracle construction, results can degrade quickly. This is also why Grover examples are ideal candidates for regular maintenance: a tutorial that only works in a perfect simulator may need updated notes once readers start running it on cloud backends.

If your next step is real execution, compare platform workflows in our Amazon Braket tutorial and Azure Quantum tutorial. For broader trade-offs, see IBM Quantum vs Amazon Braket vs Azure Quantum.

QFT in plain terms

The Quantum Fourier Transform is often introduced as a building block rather than a standalone business-facing algorithm. That is the right way to think about it. QFT transforms amplitudes into a phase-aware frequency-like representation and appears in the conceptual foundation of algorithms such as phase estimation and factoring-related discussions.

For developers, QFT matters because it teaches a circuit pattern you will see repeatedly:

• Hadamard on a qubit
• Controlled phase rotations from neighboring qubits
• Optional swap operations to reverse qubit order

from qiskit import QuantumCircuit
import numpy as np

n = 3
qc = QuantumCircuit(n)

# Example initial state
qc.x(2)

# QFT
for target in range(n):
    qc.h(target)
    for control in range(target + 1, n):
        angle = np.pi / (2 ** (control - target))
        qc.cp(angle, control, target)

# Reverse qubit order
qc.swap(0, 2)

print(qc)

This compact form captures the structure, though some SDKs offer built-in QFT circuit constructors. It is still worth implementing QFT by hand at least once. Doing so clarifies where the controlled rotations come from and why output order can look reversed if swaps are omitted.

One practical note: QFT examples are especially vulnerable to tutorial drift because they depend on conventions. Different resources may index qubits differently, define endianness differently, or skip final swaps to save gates when the next computation can absorb the ordering. If you are debugging a mismatch between expected and measured output, qubit ordering is one of the first things to inspect.

As your understanding grows, connect QFT to the larger path. Our quantum computing roadmap for beginners and best quantum computing courses and certifications for developers can help you decide what to study after these core circuits.

Maintenance cycle

This section gives you a repeatable way to keep a code-first algorithm reference useful over time. The core ideas behind Deutsch-Jozsa, Grover, and QFT do not change often. The surrounding tooling does. A good maintenance cycle focuses on the parts most likely to drift:

1. SDK syntax: imports, simulator APIs, transpilation helpers, and visualization tools.
2. Execution context: local simulator, managed simulator, or real hardware.
3. Reader expectation: whether people want conceptual walkthroughs, runnable notebooks, or cloud deployment examples.

A practical review cycle for this topic can be simple:

• Quarterly: run each code example in a fresh environment and confirm it still executes with current package versions.
• Every 6 months: review explanations for terminology drift, especially around SDK naming and backend workflows.
• Annually: expand the reference with one new implementation angle, such as a Cirq version, PennyLane version, or hardware execution note.

When you maintain an article like this, update the examples in order of instructional value, not novelty. First confirm the basic simulator examples work. Then add optional sections such as noise-aware runs, transpilation notes, or cloud provider variants.

This is also the right place to decide whether the article should remain Qiskit-first or become multi-SDK. If readers increasingly search for cross-framework examples, add side-by-side snippets and link to dedicated tutorials like our Cirq tutorial and PennyLane tutorial.

A useful maintenance rule is to separate the stable part from the changing part. Keep the algorithm explanation framework-agnostic, and keep the code blocks version-aware. That way, when APIs move, you do not have to rewrite the whole article.

Signals that require updates

Not every change in the quantum ecosystem requires revisiting this article. Focus on signals that directly affect comprehension, correctness, or user success.

1. The code no longer runs cleanly

This is the most obvious trigger. If imports fail, simulator objects change, or circuit methods are deprecated, the tutorial loses trust immediately. Even if readers can patch it themselves, they should not have to reverse-engineer a basic example.

2. Search intent shifts from theory to execution

Sometimes readers searching for “quantum algorithms explained” want intuition. At other times they want “how to build quantum applications” with practical backend steps. If comment patterns, analytics, or related search trends suggest growing interest in execution workflows, expand the article to include:

• how to run each circuit on a simulator,
• what result distribution to expect,
• how noise changes the output,
• and when a hardware run is not worth the cost or wait time.

3. SDK conventions change enough to confuse beginners

Even when old code technically works, conventions may change. Examples include preferred primitives, execution abstractions, backend naming, or result handling patterns. If a tutorial uses a style that readers rarely see elsewhere anymore, update it for clarity.

4. Readers need better comparison context

As the ecosystem matures, tutorials often need stronger context around tool choice. If readers repeatedly ask whether a circuit should be written in Qiskit, Cirq, or PennyLane, add a short note or internal link instead of forcing the article to become a full comparison. Our SDK comparison guide is the right supporting resource for that job.

5. Resource estimation becomes part of reader workflow

Once readers move beyond toy circuits, they begin asking harder questions: How many qubits? How deep is the circuit? How realistic is execution on current backends? Those questions do not change the algorithm definitions, but they do change what makes an article useful. If your audience starts wanting more realism, add a short section on circuit depth, oracle cost, and feasibility, then link to our guide to quantum resource estimation.

Common issues

Most developer frustration with foundational quantum algorithms is not caused by the math alone. It usually comes from a small number of recurring implementation problems.

Deutsch-Jozsa: oracle mistakes

The most common issue is encoding an oracle that does not actually satisfy the promise. If your function is neither clearly constant nor balanced, the textbook guarantee no longer applies. Another frequent mistake is misunderstanding the role of the output qubit. The ancilla is not just extra storage; it enables phase kickback in the standard construction.

What to check:

• Does the oracle represent a promised constant or balanced function?
• Did you initialize the ancilla in the correct state before applying Hadamards?
• Are you measuring only the input register at the end?

Grover: iteration count and diffusion errors

In Grover examples, developers often get the oracle right but the diffusion operator wrong. Another issue is applying too many iterations for a small search space. Because Grover acts like a rotation in a reduced subspace, “more” does not mean “better.”

What to check:

• Does your oracle mark exactly the intended state?
• Is the diffusion operator implemented as H, X, phase flip, X, H?
• Are you using an iteration count appropriate for the number of marked states and total search space?

QFT: qubit order confusion

QFT tutorials regularly trip readers on output ordering. Some examples include final swaps; others omit them. Some measure in displayed circuit order; others assume a different logical order. This can make a correct implementation look wrong.

What to check:

• Did you include the final swaps, or are you accounting for reversed order elsewhere?
• Are your control-target relationships correct in the phase rotations?
• Are you comparing simulator output using the same bit-order convention as your circuit diagram?

Across all three: simulator success does not guarantee hardware success

A simulator is ideal for learning, but it can hide the practical cost of depth, connectivity constraints, and noise. This matters most for Grover and QFT because they often involve controlled operations that become fragile after transpilation.

When examples graduate from tutorial circuits to cloud runs, set expectations clearly. A good beginner tutorial should explain not just how to run the code, but also why a result may become less clean outside an ideal simulator.

When to revisit

Revisit this topic when you want to move from recognition to fluency. The first pass through Deutsch-Jozsa, Grover, and QFT helps you identify the patterns. The second pass is where the circuits become useful building blocks.

A practical revisit schedule looks like this:

• After your first SDK setup: rerun the examples locally and make sure you can explain each gate layer in plain language.
• After learning a second framework: port one algorithm to another SDK to separate concepts from syntax.
• Before trying real hardware: revisit Grover and QFT with an eye on circuit depth, controlled operations, and expected noise sensitivity.
• When planning a learning path: use these algorithms as checkpoints before moving into variational methods, quantum machine learning, or resource estimation.

If you want an action-oriented next step, try this sequence:

1. Implement Deutsch-Jozsa with one constant and one balanced oracle.
2. Build a two-qubit Grover circuit and verify the marked state dominates in simulation.
3. Write QFT by hand for three qubits, then compare it to any built-in implementation your SDK provides.
4. Port one of those circuits to another framework or execution environment.
5. Document what changed: imports, simulator calls, qubit ordering, or measurement handling.

That exercise turns this article from a one-time read into a reusable reference. It also gives you a cleaner foundation for more advanced work, whether you continue into quantum machine learning tutorials, cloud quantum platform workflows, or broader Python quantum computing projects.

Finally, if you are building a sustained quantum computing learning path, treat these three algorithms as recurring checkpoints rather than boxes to tick once. Revisit them when APIs change, when you switch SDKs, when you start using managed backends, or when your understanding of phase, interference, and circuit cost needs sharpening. That is how an algorithm tutorial stays useful long after the first read.