GridUnity - Staff Software Engineer, Quality Engineering

• GridUnity spends its days removing bottlenecks from the interconnection queue. This role removes our bottlenecks. • We are not hiring you to test our software. We are hiring you to build the system that makes "is this safe to ship" a fact we already have, not a meeting we still need. • Being right and being fast pull against each other, and at our scale that tension is an engineering problem rather than a process one. • As the Staff Software Engineer, Quality Engineering, you will own and lead GridUnity's quality engineering strategy: the technical vision and roadmap for the operating model as it scales, the standards it holds engineering to, and what counts as evidence that something is safe to ship. • you will own and lead GridUnity's quality engineering strategy: the technical vision and roadmap for the operating model as it scales, the standards it holds engineering to, and what counts as evidence that something is safe to ship. • GridUnity engineering runs on an AI-native, artifact-first model. Agents draft tests from specs, run executions, and write automation. Humans arbitrate the evidence, own the release verdict, and continuously calibrate how much of the agents' judgment to trust. Version one of that system is live today on our flagship product line. You will take ownership of it, make it hold under real delivery pressure, and scale it across every product line. • You will make quality a property of the engineering system itself: honest release gates, a defensible and deliberately shrinking catalog of human-judgment testing, and evaluation mechanisms that tell us exactly where human attention is needed. • You report to the Director of Engineering Operations and partner closely with Product Engineering, Platform Engineering and DevOps to improve release confidence while accelerating delivery. • Where we are, and where you come in • Running now: the quality operating model is documented and live on our flagship product line. An agent-drafting workflow ships review-ready tests against documented why-manual criteria, enforced in the ticket lifecycle. A daily regression cadence runs green, with manual coverage held where human judgment is required. Evidence-backed release gating is live in our test-management system of record. An operations console harvests all of it nightly. • Running now: • Yours to build: making all of that hold under real delivery pressure, and taking it from the flagship line to the rest, and to the lines that do not exist yet. • Yours to build: • What you'll own • What you'll own • The release verdict, as a mechanism rather than a meeting. Execution records as evidence, exit criteria agreed before the deadline exists, a waiver path that blocks nobody but puts a name on the exception and counts it, and a defined escalation route, on the record, for the rare call those criteria do not cover. The mechanics exist; making them hold by design rather than by willpower is the work. • The release verdict, as a mechanism rather than a meeting. • The agent pipeline. Operate and harden the system where agents generate, maintain, and run coverage across API, UI, integration, contract, performance and end-to-end, directly from specs and scenario contracts. Nothing becomes coverage until a person reviews and activates it, and you own where that bar sits. • The agent pipeline. • The review loop. Drafts arrive continuously from engineers, product, and agents, and the review SLA is a promise to the whole company. Keeping it as agent output grows is a design problem, not a throughput one. • The review loop. • The shrinking catalog. Own the criteria for what stays human-tested, and build the demotion loop that retires manual tests as automation catches up. The first demotion pass is yours. • The shrinking catalog. • Calibration from zero. Stand up a corpus of golden human verdicts, score agent verdicts against it continuously, and use escape-rate data to point human attention where it actually pays. • Calibration from zero. • Developer-owned quality. Push automated testing into the development lifecycle and the CI/CD pipelines so coverage runs where the code is written rather than in a lane beside it. • Developer-owned quality. • Behavioral validation as an external check. Persona walkthroughs, exploratory charters and judgment-based testing that verify behavior matches intent, not merely that the spec passed. This is the function that asks whether the spec was right. • Behavioral validation as an external check. • The tooling call. Evaluate emerging testing technologies, agentic engineering practices and AI-assisted development tools, and decide which of them earn a place in how we work. The bar is whether something moves the evidence, not whether it is new. • The tooling call. • The engineers around you. Mentor engineers and QA teammates through code review, pairing and technical design discussion, including the discipline of articulating why something is wrong precisely enough that the articulation becomes agent capability. The QA engineers are experienced, and we expect their technical judgment to be sharper for your being here. • The engineers around you. • The metrics that matter. Escape rate, verdict calibration, catalog trend, waiver frequency, deployment success, defined by you and used to argue. • The metrics that matter. • A note on the title • A note on the title • "Software Engineer" comes first because that is the load-bearing skill. Our platform is largely TypeScript, and most of the code you review will have been written by an agent: fluently, confidently, and sometimes wrongly in ways only a strong engineer catches. • "Software Engineer" comes first because that is the load-bearing skill. • "Quality Engineering" rather than "QA," because QA names a stage at the end of a process. We are asking you to make quality a property of the process itself: real exit criteria, evidence instead of assurances, and a manual test catalog that gets smaller each quarter. • "Quality Engineering" rather than "QA," because QA names a stage at the end of a process. • Not "SDET," the one we thought hardest about. SDET names a person whose deliverable is test code, and in our model agents write most of it. The scarce skill is no longer producing automation; it is deciding how much to believe what the automation reports, and knowing which tests have stopped earning their keep. If your best story is a framework you built, this probably is not your role. If it is the day you stopped trusting a green suite and could prove why, keep reading. • Not "SDET," the one we thought hardest about. • What this job is not • Not running test execution. Experienced QA engineers own the daily cadence and keep it. You set the technical standard they work to. • Not building a Playwright suite. Framework depth is context for supervising agent output, not the deliverable. • Not release administration. If this role's answer to a risky release is to convene people, we have built the wrong thing. • Not AI research. The agents are already in production. They need to survive a deadline, not a demo. • You might be the right person if • You have had to say a release was not ready when the date could not move. Afterwards you made sure the next call was settled by criteria agreed in advance, not by whoever argued hardest. • You have deleted test coverage on purpose and could defend it with data. • You have built an evaluation system of some kind, whether an eval harness, a labeling pipeline or scoring for model output, and you treat "can this judgment be trusted" as a measurement problem. • You ran automation at scale and concluded the real bottleneck was the operating model, not the coverage. • You get more out of changing how three teams work than out of being the most productive engineer in the room.