Senior​/Frontend Engineer

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.

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.

You own the screen that pharmacy staff will use to run the machine, and then every other screen Queue ships. The operator screen is a large, touch-only panel on the front of the unit, built to be used all day by technicians who are busy with something else. You are answerable for three things: the screen that ships is the screen that was reviewed, a change in the design reaches the machine in days, and the next screen is built to the frontend standard you keep.

This posting covers Senior and Staff levels. Senior level means you own this surface end to end. Staff level means the frontend standard and review practice carry your name, and other engineers build against them. The technical interview is set at the Senior bar.

• The operator screen — Its scope is the prescription queue, replenishment of drugs and consumables, machine health, administration and exception handling, and sign-in on an on-screen keypad.
• The prototype and the application — The interface has two forms: the design prototype that is reviewed, and the React application for the machine. You are answerable for the match between them, working with our product designer.
• The rules of touch — There is no mouse and no keyboard. Touch targets are never smaller than 48 pixels. Text can be read at a glance in the middle of another task. The screen advances on physical events, such as a drawer closing, and not on extra taps. An action that cannot be undone is never placed where fast fingers land.
• What interrupts a technician — A model with three layers: ambient status, a call for attention, and a blocking dialog, with clear rules for which is used when. That includes the alerts for the machine's own faults.
• Working in the interface contract — The screen owns no domain state: it renders what the machine sends, so a reload always lands on the truth. Its Type Script types are generated from the Rust source on the machine, and the build fails when they drift. The engineers who own the on-machine software own the contract; you work in it with them every day.
• The quality bar — You set it and hold every screen to it: unit tests with coverage measured, end-to-end tests in a real browser, and lint rules that enforce the design tokens.
• The screens that follow — Our cloud operations dashboard comes next, and then the screens of later products. They are built to the standard you set on the operator screen, on smaller displays as well as large ones.

• Day 30:
  You have merged a change to the screen. You know the queue, replenishment and alert flows as a technician will meet them, you have sat in a design review, and you have gone through the prototype and the application side by side with our product designer.
• Day 60:
  Design changes reach the application through your own commits. The three-layer interruption model is yours, alerts included. Your end-to-end suite runs the flows a technician will run every day.
• Day 90:
  You are answerable for the match between the application and the reviewed design, and for the screen's readiness for security review. You keep the frontend standard: testing,…