Find your place in quantum.

A useful quantum-software portfolio can begin with a narrow question: what does it cost to estimate the gradient used by a variational algorithm? PennyLane’s official gradient tutorial compares parameter-shift evaluation with simulator backpropagation, and its related material discusses finite-sample estimates. This pathway uses those resources to build an original audit of gradient accuracy, execution count and uncertainty. It is a self-directed learning project, not a current Xanadu vacancy or an assignment endorsed by the project maintainers.

Start with a small parameterised circuit whose expectation value can be checked analytically or with a high-accuracy classical reference. Choose one parameter and state the derivative convention explicitly. Then compare an exact reference with a sampled estimate over several shot budgets. Preserve the random seeds and report the distribution of estimation errors across repeated trials. A single estimate that happens to be close to the reference should not be presented as the typical outcome. The central skill is designing an experiment that separates mathematical correctness from statistical reliability.

The second part is resource accounting. Record the number of circuit evaluations required to obtain one gradient, the shots per evaluation and the total number of samples. Treat compilation and simulator work as separate costs. Backpropagation through a classical simulator can exploit information unavailable through a hardware sampling interface, so the comparison must name the access model. The goal is not to declare one differentiation method universally superior. It is to explain which method fits a particular execution environment and why the same word gradient can conceal different computational work.

Add a failure case that makes the audit informative. For example, choose a parameter regime with a small true derivative and examine how the sign of the estimate changes across repetitions. Then ask whether an optimiser using those estimates would make consistent updates. Keep the experiment small enough that a reviewer can rerun it quickly. A good report includes the circuit, expected derivative, sample budget, error plot and one decision about when more samples would be justified. This is a proposed exercise; no completed run is claimed.

Vacancy status

Technical resource pathway; no current vacancy advertised or verified

Employer

Not a hiring listing

Salary

Not applicable

Location

Self-directed resource pathway

Starting skills

Python, elementary differentiation, expectation values

Portfolio output

Gradient-cost notebook with repeated-trial error analysis

A useful completion check

Reference derivative reproduced; sample count and uncertainty documented

Hardware needed

No; simulator and analytical reference are sufficient

Software version

Pin PennyLane and numerical-library versions

Quandela’s Perceval resources provide a route into modelling optical quantum circuits and examining their outputs. This pathway focuses on a specific skill: explaining how a selected set of measurement outcomes changes the meaning of a reported success rate. The official documentation and technical note on simulation are starting points, while the portfolio work is an original analysis of a small circuit with clearly stated input states, losses and acceptance rules. It is not a claim of access to Quandela hardware or an open vacancy.

Begin with a circuit small enough that the allowed output patterns can be enumerated and understood. State the input photon occupation, the optical transformation and the detector model. Before running anything, define which outcomes count as accepted and why. Then report both the conditional quality of accepted outcomes and the fraction of all attempts that survives selection. These quantities answer different questions. A clean conditional distribution can coexist with a low overall success probability, and a reviewer should be able to see both without reconstructing the notebook.

The next step is to vary one model assumption at a time. A simple loss parameter or a change in the detector assumption can show how the selected sample changes. Do not label the model as a measured device unless the parameters come from an identified experiment. Use the exercise to distinguish a simulator’s mathematical output from the evidence needed to describe real equipment. The useful question is what the model teaches about the workflow and which physical assumptions remain untested.

Add a deliberately misleading summary and then correct it. For instance, write a sentence that reports only success among accepted runs, then rewrite it with the attempt denominator and selection rule included. This is a communication exercise with technical content: the reviewer should be able to trace every number to a defined set of outcomes. Include a table of raw counts or probabilities, accepted outcomes and rejected outcomes. If the simulated state space becomes too large, state the truncation or resource limit instead of silently changing the experiment.

Vacancy status

Technical resource pathway; no current vacancy advertised or verified

Employer

Not a hiring listing

Salary

Not applicable

Location

Self-directed resource pathway

Starting skills

Python, probability and basic linear algebra

Portfolio output

Photonic outcome and postselection audit

A useful completion check

Conditional and unconditional denominators both reported

Hardware needed

No

Model boundary

Simulation; any loss or detector parameters explicitly illustrative unless sourced

SeQUeNCe’s official documentation describes an open-source discrete-event simulator for quantum networks. Its introductory chapters separate event scheduling, hardware components and network resource management. This pathway turns those resources into a diagnostic project: explain how a change in event ordering or resource lifetime affects an end-to-end network outcome. The result is a software and modelling portfolio, not an operational quantum network and not a verified job opening at Argonne or another institution.

Begin with a minimal topology and a short trace of scheduled events. Each trace row should include simulation time, event type, affected resource and the state change it causes. The goal is to make it possible to reconstruct why an attempt succeeded, failed or was retried. A final average rate hides that causal sequence. A small trace can reveal whether the model is waiting for a classical message, holding a memory resource or discarding a result that arrived too late for the chosen policy.

Choose one policy variable, such as a reservation rule or an explicitly modelled memory lifetime, and vary it while keeping the topology and random seed policy fixed. Report the resulting distribution rather than only its mean. Also record how much simulated time was spent in warm-up and whether incomplete attempts at the end were counted. Those bookkeeping decisions can change a reported rate without changing the physical model. The exercise should expose them so that a reviewer can distinguish a scientific effect from a measurement-window artifact.

A useful failure case is a network that appears connected in a diagram but cannot supply the requested service under the chosen timing and resource conditions. Explain the bottleneck through the event trace and then propose one bounded modification. Do not assume that the modification corresponds to a real device upgrade. It is a model intervention whose effect can be tested inside the simulator. If the intervention helps, state which assumptions would need experimental evidence before the conclusion could be applied to deployed infrastructure.

Vacancy status

Technical resource pathway; no current vacancy advertised or verified

Employer

Not a hiring listing

Salary

Not applicable

Location

Self-directed resource pathway

Starting skills

Python, event-driven programming, probability

Portfolio output

Network trace and bottleneck diagnosis

A useful completion check

Every reported outcome traceable to events and measurement window

Hardware needed

No

Model boundary

Discrete-event simulation; real-device validation separate

QuTiP’s current documentation provides solvers for closed and open quantum-system dynamics, including master-equation methods and configurable numerical options. This pathway uses a small driven system to practise a distinction essential to scientific software work: a numerically stable answer can still come from an inappropriate physical model. The project therefore has two separate reviews, one for the computation and one for the assumptions. It is a resource pathway, with no current vacancy, laboratory access or experimental result claimed.

Choose a model with an independently understandable limiting case. Set out the Hamiltonian, initial state, measured observables and any dissipation terms, with units and conventions explicit. First run a parameter regime in which a simple analytical expectation or a conservation property can be checked. Then introduce one additional physical effect. The notebook should explain why that effect belongs in the model rather than adding terms only because a solver accepts them. A reviewer should be able to connect every parameter to a stated modelling assumption.

The numerical review varies solver tolerances, time resolution where relevant and basis truncation if the system uses an infinite-dimensional degree of freedom. Compare the observable of interest under these changes and define a convergence criterion before selecting the final settings. A smooth-looking curve is not sufficient evidence. The result can be stable at displayed resolution while still changing materially when the truncation or solver settings are tightened. Preserve the computational cost so the reader can see the tradeoff between accuracy and resources.

The physical review asks different questions. Does the chosen equation describe the intended interaction with the environment? Are the parameters constant, time dependent or merely illustrative? Which effects have been omitted, and could they change the conclusion? No amount of numerical precision repairs an assumption that does not apply. A useful portfolio discussion presents one example where numerical convergence is achieved but a change in the physical model changes the interpretation. Label both models and avoid claiming that either represents a real device without supporting measurements.

Vacancy status

Technical resource pathway; no current vacancy advertised or verified

Employer

Not a hiring listing

Salary

Not applicable

Location

Self-directed resource pathway

Starting skills

Python, differential equations, basic quantum dynamics

Portfolio output

Convergence table plus physical-assumption note

A useful completion check

Observable stable under justified numerical refinement; modelling limitations stated

Hardware needed

No

Release boundary

Distinguish stable and latest documentation branches

Google Quantum AI’s OpenFermion documentation provides tools for representing fermionic operators and transforming them into qubit operators. This pathway uses a small model to build an audit trail from the physical operator to the matrix used in a computation. The skill is not merely calling a transformation function. It is preserving ordering, conventions and equivalence checks so another reader can understand what problem the resulting circuit or matrix represents. This is a self-directed project, not a Google vacancy or a claim of quantum advantage.

Start with a two- or few-mode Hamiltonian small enough to inspect directly. State the mode ordering, coefficients, basis convention and particle-number sector of interest. Construct the operator through the library and also write a transparent reference representation. Then compare the spectra or expectation values in a way that accounts for basis ordering. Two matrices can look different while representing the same physical problem under a basis change; conversely, a familiar-looking matrix can be wrong because a sign or ordering convention was lost.

The central exercise is to introduce one deliberate bookkeeping error and diagnose it. Swap a mode ordering without updating the interpretation, omit a sign or compare sectors inconsistently. The report should show which invariant or test exposes the mistake. This makes the portfolio more informative than a notebook that only reproduces the tutorial’s final output. It demonstrates that the author understands the mapping boundary and can design a check that would catch a realistic error in a larger scientific workflow.

Next, connect the qubit representation to a resource question. Count the resulting operator terms and identify which transformations change that representation. Do not infer complete algorithm runtime from a term count alone. State what additional work would be required to compile an evolution, measure an energy or solve the chosen task. The comparison can remain symbolic or use a tiny exact simulation. Its purpose is to show how a representation decision influences downstream computation while keeping the actual task and accuracy target fixed.

Vacancy status

Technical resource pathway; no current vacancy advertised or verified

Employer

Not a hiring listing

Salary

Not applicable

Location

Self-directed resource pathway

Starting skills

Python, matrices and second-quantized operator basics

Portfolio output

Mapping audit with deliberate-error diagnosis

A useful completion check

Small-model spectra or observables agree under documented conventions

Hardware needed

No

Resource boundary

Operator term count is not complete application runtime

pyGSTi’s documentation describes gate-set tomography as fitting a parameterized model to experimental data and provides tools for gauge optimisation. This pathway uses synthetic data to explore how equivalent representations can affect a characterization report. The goal is to produce an explanation that a reviewer can follow from data to model to reported metric. It is not an assertion that a particular device has been characterized, and it is not a current vacancy or a professional certification.

Begin with a small synthetic gate set and a clearly documented collection of circuits. Generate data under a stated sampling model and preserve the seed, number of shots and true model used for the exercise. Fit the model using an official tutorial path, then separate three questions: how well the fit reproduces the observed data, whether the chosen model family is adequate, and how the model is represented for comparison with a target. These questions can interact, but they should not be treated as the same diagnostic.

The core demonstration compares two gauge-optimisation choices while tracking quantities that should retain their operational meaning. The notebook must explain what changed in the representation and what did not change in the predicted observations. Avoid using a single attractive metric as the only evidence of a good characterization. A report can appear closer to a target under one representation while the underlying data and predictive content remain the same. The exercise should make that distinction visible rather than treating gauge optimisation as a mysterious improvement button.

Add a model-mismatch case. Generate a second synthetic data set that the original model does not describe well, and examine the fit diagnostics. State exactly which assumption was changed. This allows the portfolio to discuss the difference between representational freedom and a model that fails to capture the data. Keep the example small enough to reproduce on ordinary computing resources, and do not claim that a synthetic mismatch represents a specific laboratory’s noise. A careful negative result is useful when it identifies the limit of the chosen analysis.

Vacancy status

Technical resource pathway; no current vacancy advertised or verified

Employer

Not a hiring listing

Salary

Not applicable

Location

Self-directed resource pathway

Starting skills

Python, probability, linear algebra and model fitting

Portfolio output

Synthetic GST report with gauge and model-mismatch comparison

A useful completion check

Distinguish changed predictions from changed representation

Hardware needed

No

Data status

Explicitly synthetic; no real-device characterization claimed

Mitiq’s official documentation introduces zero-noise extrapolation as a way to estimate an observable at a lower effective noise level using results obtained at several amplified noise levels. This pathway asks a narrower, practical question: when does the extra sampling and model fitting improve the estimate enough to justify its cost? The project is an original statistical audit built around a small simulated circuit. It does not demonstrate error-corrected computation, a measured commercial device or an open position with a software employer.

Choose an observable with an independently calculable reference value. Define a noise model and a set of scale factors before looking at the results. For each scale factor, preserve the circuit transformation, sample budget and measured estimate. The first comparison should show the raw noisy result beside the extrapolated result, with uncertainty for both. An extrapolated number that lies closer to the reference in one trial can still have a larger spread across repetitions. That distinction is the reason to repeat the complete experiment, including the fit.

The second part is a fair resource comparison. Give the unmitigated baseline the same total sampling budget used across all scaled circuits. If circuit depth or execution cost differs, report that separately instead of hiding it inside a nominal shot count. Then compare error distributions at the same total budget. This proposed experiment may identify regimes in which extrapolation helps and regimes in which it does not. Neither outcome should be suppressed. A useful portfolio can explain a failure precisely without presenting it as a universal verdict on mitigation.

Add a model-choice review. Fit two justified extrapolation forms and examine their sensitivity to the chosen scale range, a held-out point or one noisy estimate. Explain why extending a fitted curve beyond the observed region requires assumptions. Record estimates that leave the observable’s allowed range, and distinguish an optional clipping rule from the original estimator. Clipping can change statistical properties; it should be reported as an additional procedure rather than silently making the result appear physical. Keep all synthetic noise parameters clearly labelled and avoid attributing them to an actual processor.

Vacancy status

Technical resource pathway; no current vacancy advertised or verified

Employer

Not a hiring listing

Salary

Not applicable

Location

Self-directed resource pathway

Starting skills

Python, expectation values, elementary regression and sampling uncertainty

Portfolio output

Equal-budget mitigation audit with repeated complete fits

A useful completion check

All scaled-circuit samples counted; improvement assessed across repetitions

Hardware needed

No

Data status

Explicitly synthetic

Stim’s detector-error-model format describes error mechanisms through their probabilities, detector symptoms and changes to logical observables. Its official format document provides a precise starting point for an interoperability project. This pathway asks whether a small model retains its meaning when a parser, exporter or downstream analysis handles it. The deliverable is a format and semantics audit, not a decoder speed benchmark or a claim about the performance of real error-corrected hardware. The exercise uses deliberately small synthetic examples.

Begin with a hand-readable model containing only a few detectors and one logical observable. For each error mechanism, state which detector outcomes change and whether the logical observable changes. Then construct a tiny exhaustive reference that enumerates combinations of those mechanisms. The reference should make parity explicit: two flips of the same binary symptom cancel. This small model becomes an independent check on the parser’s interpretation and a way to explain why a list of detector identifiers is more than a collection of labels.

The second stage introduces indexing and repetition. Choose an example in which repeated blocks shift detector references, and write the expanded interpretation beside the compact input. Confirm that a transformation preserves the intended identities and total mechanism structure. Coordinates can help a reader visualize a model, but a coordinate convention should not be confused with the detector’s logical definition. The report should identify which fields affect sampled outcomes and which describe geometry or presentation. Keep each claim tied to the exact format version used.

Add an intentionally malformed or semantically altered example. A shifted detector index, missing observable reference or mistaken repetition count can produce a file that looks plausible while changing its meaning. Show the diagnostic that catches the alteration. If the downstream tool accepts only a restricted class of models, record that capability boundary explicitly. Do not convert unsupported mechanisms silently merely to make the import succeed. An honest incompatibility report is more useful than a pipeline that runs while changing the scientific question.

Vacancy status

Technical resource pathway; no current vacancy advertised or verified

Employer

Not a hiring listing

Salary

Not applicable

Location

Self-directed resource pathway

Starting skills

Python, binary parity and simple probability

Portfolio output

Detector-model parser or round-trip audit with exhaustive reference

A useful completion check

Detector and logical-observable distributions preserved in a small enumerated case

Hardware needed

No

Scope boundary

Format semantics and interoperability; no decoder speed claim

Qblox’s Q1 documentation describes a sequencer architecture with distinct instruction-handling and real-time execution responsibilities. That separation creates a useful learning project: explain how a short program becomes an ordered sequence of instrument actions. The pathway uses the official instruction reference and basic sequencing tutorial to design a trace-based review. It is a self-directed control-software exercise, not a current Qblox vacancy, an endorsed training certificate or proof that a physical instrument was operated.

Start with a minimal sequence that contains setup, a loop and a small number of scheduled operations. Write down the intended output before using a compiler or simulator. Then prepare a trace with instruction location, register state, queued action and the relevant time relationship. Separate the program’s logical progress from the physical duration of an operation. The goal is to show where the two are connected and where assuming that every instruction immediately changes a connector output would be misleading.

Choose one concrete failure to investigate. A loop boundary, an incorrect wait or an empty queue can make the intended schedule differ from the executed one. Use documentation-supported behaviour to explain the failure and identify the earliest point at which a review could detect it. If an instrument simulator is available in the selected environment, record its version and limits. If it is not available, label the artifact as a static trace and do not fabricate waveform captures. A clear static analysis can still be a valuable demonstration of reasoning.

The second part is an interface note for someone reviewing the sequence from another discipline. Specify which values are software parameters, which are instrument settings and which would need external calibration. A timing-correct program does not establish pulse amplitude at the device, cable delay or the quantum operation produced by the signal. Those require additional evidence. Include a proposed measurement plan that names the observable output and the independent reference needed to check it, while keeping that future plan separate from the completed software review.

Vacancy status

Technical resource pathway; no current vacancy advertised or verified

Employer

Not a hiring listing

Salary

Not applicable

Location

Self-directed resource pathway

Starting skills

Basic assembly concepts, registers, loops and timing units

Portfolio output

Annotated sequence trace with a diagnosed scheduling failure

A useful completion check

Predicted instruction and queued-action behaviour tied to pinned documentation

Hardware needed

No for static review; measurement extension requires identified equipment

Execution status

Proposed exercise; no instrument operation performed

Quantum Machines’ QUA documentation describes stream processing that transforms measurement data while results move through the control and server workflow. This pathway focuses on an easily overlooked source of error: the shape and alignment of the data that later appears in a plot. The project is an original review of a small acquisition plan, using official stream-processing guidance and release notes. It is not a laboratory calibration result, a claim of access to an OPX system or a current vacancy.

Begin with a synthetic acquisition table containing a repetition index, sweep coordinate, measurement label and value. Define the intended grouping before applying any averaging or buffering. The reference table should be small enough to inspect by eye. Then write the expected output shape and explain which input rows contribute to each output element. This makes a transposed axis, missing repetition or incorrectly grouped channel visible before the data is used to fit a device parameter.

Next, add a deliberately incomplete acquisition. Remove one row or stop the synthetic sequence before the final group is complete. Examine how the intended processing should represent that condition and what the selected software version actually documents. Do not fill missing data with zeros unless the report explicitly defines and justifies that choice. A zero measurement, an absent measurement and a partial average have different meanings. The project should preserve enough metadata for a later reviewer to distinguish them without consulting an undocumented convention.

The third part is a provenance review. Identify the point at which raw records are reduced, the axes retained in the result and the information discarded by averaging. Decide which small raw sample or diagnostic count should accompany the reduced data. There is a practical tradeoff between retaining every record and making an experiment manageable, but that tradeoff should be chosen deliberately. An attractive heat map cannot reveal whether the underlying axes were aligned correctly. A useful report connects each plotted cell to its acquisition rule and its number of contributing observations.

Vacancy status

Technical resource pathway; no current vacancy advertised or verified

Employer

Not a hiring listing

Salary

Not applicable

Location

Self-directed resource pathway

Starting skills

Python arrays, nested loops, averages and missing-data handling

Portfolio output

Stream-shape and provenance audit using synthetic acquisitions

A useful completion check

Every reduced result maps to explicit input rows and sample counts

Hardware needed

No for data-shape exercise

Software version

Record compatible QUA and QOP versions

Zurich Instruments’ LabOne Q documentation includes workflow logbooks for recording experiment runs and their results. That capability provides a starting point for a broader portfolio question: what must be recorded so that a later experiment can understand and reuse a calibration responsibly? This pathway proposes a small synthetic calibration chain with explicit dependencies. It is not a real-device tune-up, an employer assignment or a current vacancy. The official tutorial supplies the software context; the dependency review is original project work.

Choose a simple chain in which one estimated parameter is used by a later experiment. The exact physical example can remain illustrative, but its inputs and outputs must be named consistently. Record the configuration, data identity, fit method, accepted parameter and validation result for each stage. Then distinguish the raw estimate from the decision to adopt it. A fitted number does not become a trustworthy operating value merely because it was saved in a database or displayed in a report.

The core exercise changes an upstream condition and asks which downstream records remain applicable. A configuration revision, a changed measurement setting or an altered fit procedure may invalidate a later assumption. Build a small dependency map and state the reason for each connection. Avoid treating time alone as the only freshness test. A recent calibration can be unsuitable after a relevant hardware or software change, while an older record may remain useful as historical evidence. The logbook should make those relationships inspectable rather than relying on a person’s memory.

Add one rejected calibration. Preserve the attempted measurement and the reason it did not meet the chosen acceptance criterion. Explain whether the next experiment should stop, retain a previous accepted value or request another measurement. These are proposed workflow decisions, not assertions about an installed laboratory policy. The important skill is making the decision explicit and reviewable. Include units, uncertainty and the version of the analysis that produced the estimate. A value without those details can be easy to copy and difficult to interpret.

Vacancy status

Technical resource pathway; no current vacancy advertised or verified

Employer

Not a hiring listing

Salary

Not applicable

Location

Self-directed resource pathway

Starting skills

Python, structured records, measurement units and basic fitting

Portfolio output

Synthetic calibration logbook with dependency and rejection history

A useful completion check

One accepted value can be traced to data, method and validation decision

Hardware needed

No

Data status

Synthetic; no laboratory measurements claimed

The OpenQASM 3.1 specification describes a language for expressing quantum programs together with classical computation and control. A language specification, however, does not establish that every backend implements every feature. This pathway uses a few small programs to build a capability contract between a program’s meaning and an execution target. The project is an original compatibility review, not a claim that a particular provider accepts the examples, a compiler speed benchmark or a current software vacancy.

Begin with three short examples that require different capabilities. One can use only a fixed gate sequence, another can depend on a measured value, and a third can use an explicitly documented classical or timing feature. For each example, write a plain-language statement of the required behaviour. Keep syntax and semantics separate: a parser may accept a construct even when the selected execution target cannot provide its intended behaviour. The contract should identify the earliest stage at which an unsupported requirement becomes visible.

The next step is a capability table. List the required feature, the evidence for its meaning in the specification and the evidence, if any, for support by a named implementation. Use unknown when support has not been checked. Do not infer support from the broad label OpenQASM compatible. If a compiler lowers a feature into another representation, record the assumptions and limitations of that transformation. A program that runs after a silent approximation may answer a different question from the one written in the source.

Add a small negative test that produces a useful diagnostic. The goal is not to create a large test suite that mirrors the implementation. It is to show how a reviewer would distinguish a syntax error, an unsupported capability and an invalid physical assumption. Include the exact software version and the full diagnostic message for any executed test. Where execution is unavailable, keep the example as a proposed conformance case and do not invent a compiler response. This distinction makes the portfolio credible even when it covers more than one execution environment.

Vacancy status

Technical resource pathway; no current vacancy advertised or verified

Employer

Not a hiring listing

Salary

Not applicable

Location

Self-directed resource pathway

Starting skills

Basic quantum circuits, programming types and control flow

Portfolio output

Three-program semantic contract and backend capability table

A useful completion check

Every claimed supported feature has versioned implementation evidence

Hardware needed

No

Execution status

Proposed conformance cases unless actual logs are later added