The posting
About Us
Queue builds robots to fill prescriptions. Our machine is designed to take stock bottles of medication and produce counted, labeled vials, so that pharmacists and technicians can spend their time on patients. Our first product is built to work behind the pharmacy counter and to be operated by pharmacy staff.
About the Role
You own the evidence that Queue's software, firmware and models do what we say they do. You are answerable for three things: every release to a machine carries a record a customer or an assessor can follow from requirement to test to result; every hazard that software controls traces to a test that proves the control; and every accuracy figure the company states has a written method and raw data behind it. Most of this evidence should come out of automation that you build and that runs without you.
What You'll Own
- Validation — The plan for showing that software, firmware and models meet their requirements on the real machine, and the automated verification that carries it out. You own the checks that run on every change and the checks a release must pass.
- Requirements and hazard traceability for software — The trace from each software requirement, and each hazard that software controls, to a test and a result. You own that trace for software, working with systems engineering, and keep it current as the code changes.
- Release evidence — For each release: what changed, which versions, which tests ran, what they showed, and which exceptions were recorded and by whom. This covers model changes as well as code, including the evaluation record a model needs before it is promoted.
- Accuracy evidence — The written evidence requirement behind any number Queue states about counting or checking: the sample, the method, the pass criteria set before the run, and the raw data kept afterwards. You keep that requirement with the hardware and vision leads, run the measurement with them, and check each figure against it before it is used.
- Acceptance evidence — Where a customer witnesses an acceptance test, you own its evidence pack, produced from the automation: criteria, method, raw results, exceptions and sign-off.
- The environments tests run in — You are the first customer of our test environments and you set what they must provide, with the engineers who build them.
What stays with others, so that you know where your work stops. Systems engineering keeps the machine-level requirements and their traceability, and you work with them where the software trace joins theirs. Hardware engineering keeps hardware verification. You produce the evidence and say plainly what it shows. Technical readiness for a release is decided by software leadership, a release that misses its criteria is held, and you do not accept risk on the company's behalf.
First 90 Days
- Day 30: You have run the test suites and the end-to-end harness yourself and written your own map of what they prove across the cloud service, the on-machine software, firmware and vision. You have sat down with the hardware and vision leads on the evidence requirement for accuracy figures.
- Day 60: You have produced the evidence record for a release, in a format you defined. The check on a model's evaluation record before promotion is yours. You hold the trace from requirement to test for the path that releases a fill to be dispensed.
- Day 90: You have produced an acceptance evidence pack from the automation. You have run a measurement against the evidence requirement for accuracy figures, with the hardware and vision leads. You hold the trace from each hazard that software controls to the test that proves the control.
What We're Looking For
Must-Have
- Ownership — you have owned verification or release evidence for a system where a wrong result had consequences, and you stayed with it through a release that went wrong.
- You build the automation — you are fluent enough in the languages of the systems you verify to write the harnesses yourself. Ours are Rust, TypeScript, Python and Bash: deep skill in one, working comfort in a second.
- Evidence discipline — results that a third party can audit: criteria stated before the run, method written down, raw data kept. You treat a passing suite as a starting point and not as proof.
- Traceability practice — you have kept requirements, hazards, tests and results connected through real change, with tools or without.
- Build pipelines as a system — you have made suites run reliably with containers, service dependencies and short-lived environments, and you have made a gate that fails loudly when it cannot run.
- Testing at the seams — you look where systems meet: cloud to machine, machine to firmware, software to vision.
Nice-to-Have
- A regulated or audited industry: medical devices, pharmaceutical manufacturing, automotive or aerospace, and witnessed acceptance testing in particular.
- Measurement and statistics for accuracy studies: sampling, uncertainty, and holdout hygiene for model evaluation.
- Load testing, property-based testing and fault testing.
- Automated tests that run against real hardware on a bench.
How We Hire
- Recruiter Screen (30 min)
- Technical Interview (90 min) — a take-home exercise of 2 to 3 hours, sent at least 24 hours before: a working system with defects placed in it. We go through it together: what you found, how you proved it, and the gate that would have caught it.
- Design Interview (60 min) — design the verification and evidence system for a release.
- Leadership Interview (60 min) — how you own your work and work across squads.
Two interviewers score each technical stage independently.
What We Offer
- Ownership — the evidence that our software, firmware and models do what we say they do
- Hard problems: testing where systems meet, tracing the hazards that software controls, and evidence a third party can audit
- Small team, zero bureaucracy, high trust
Why Join Us Now?
Impact & Growth
- Direct Impact: Your evidence is the record a customer or an assessor can follow, from requirement to test to result
- Growth: The work runs from the checks on every change to the evidence for a release
Team and Culture
- Reports to the Head of Software Engineering with significant autonomy and influence
- Who You Work With: You work with every software squad, and your closest partners outside software are systems engineering and hardware engineering
- Where We Work: Hybrid, three days a week at our headquarters in the Bay Area; acceptance testing and bench work need the machine in front of you
Our Values
- Servant Leadership
- Do the Hard Things
- Own Your Work
- Default is Now
Own Your Work comes first in this role: you hold the record of what was proven, and you say so when it was not.
Contact: If you have any questions, please contact us at [email protected]
