Software Developer In Test

We’re hiring an SDET to level up the systems behind how we test. Building a strong QA infrastructure is the fastest way to help engineers move quickly without sacrificing quality as our product becomes more powerful and the team grows.

I think of QA as something you build into the system, not layer on top for added confidence. I’m not interested in gatekeeping quality or creating a process for its own sake. I care about building a QA infrastructure that generates fast, helpful feedback, the kind that engineers trust and want to use, and helps us catch problems users would care about most.

That’s what brought me to Ashby. Engineers take on a lot of ownership including ensuring quality of their work which often times means manual testing. QA at Ashby isn’t about convincing people to care; it’s about making it easier to do the right thing at scale.

Sometimes, that means seeing the edge case; sometimes, that means spotting the product's blind spot before it hits production.

This is not a test executor role. This is a deeply technical, hands-on role. Being technical here means knowing how to design a system others want to use and how to debug and simplify what already exists. You’ll write and maintain end-to-end tests, contribute to our test infrastructure, and work closely with engineers on the team to build fast, confident feedback loops, especially in areas where the product is powerful and evolving quickly. Most of your work will focus on building systems, but we're a small team, so when things get busy, you might help out with manual testing too. We all roll up our sleeves when needed.

You’ll be part of our foundational group of SDETs, reporting directly to me. We don’t silo quality, everyone at Ashby owns it but your job is to make it easier for the whole team to do that well. You’ll be writing code most days. That might mean building a test framework, extending a test setup to make it 10x faster, or debugging flaky tests that slow the team down. You’ll bring product intuition into how you build test systems, understanding what users rely on, where edge cases live, and how to steer engineers to the right tests, not just more of them. You’ll focus on building systems that unlock leverage and ensure we cover what matters. If the tools are fast but miss real issues, or catch every issue but slow us down, they’re not doing their job. We don’t count test cases; we count time saved, risks reduced, and overall reliability.

Why You Should or Shouldn’t Apply 

• You’ve written and maintained test automation frameworks from scratch. You know what makes a test helpful, what makes it flaky, and what makes it someone else’s problem
• You think like a user. You know how to spot edge cases, understand how someone might use a feature, and turn that into meaningful test coverage.
• You enjoy working on test infrastructure that supports engineers and removes friction from their workflow
• You get excited about shipping less brittle tests, faster. You don’t treat test automation like a checklist. You care if it’s usable
• You don’t need to be told what “done” looks like. You can scope, build, test, and maintain your own tools and systems

Put Another Way, You Shouldn’t Apply If

• You haven’t written code in a while, or don’t enjoy doing it daily
• You think of QA as gatekeeping, not enabling
• You prefer validating requirements over building and improving systems
• You’re happiest when someone hands you a test plan and a set of instructions
• You’re used to working on large QA teams with lots of ceremony and fixed roles