QA Engineer

Salary Range: $ To $ Annually

Location:

Centennial, CO (In-Office)
Company:
Refi Jet

Reports to:

Director of Product

Refi Jet processes a high volume of auto refinance applications every month across a network of 30+ lending partners. The software running that operation spans borrower-facing applications, lender integrations, and internal tools used by our operations teams, including My Yes Go  (our agent CRM), Connex (our call center platform), and Refi Me Now  (our lender marketplace). The quality, reliability, and usability of that software directly affects real financial outcomes for real people.

You would own software quality for the organization. Not administer it, own it. In your first year, most of what you produce will not exist yet: the integration test plans, the UAT process, the coverage standards our developers write against, the regression suite, the definition of what "tested" means before a release goes out. That is the work. This role sits in Product rather than Engineering, and that is deliberate.

Half of what you own is whether we built the thing right. The other half is whether we built the right thing, and whether it still holds up for the borrower and the agent once it is live.

We are deliberately stack and platform agnostic. We care that you can reason about risk, learn a system quickly, and tell the difference between a test that proves something and a test that runs.

Plan on five days per week on site in Centennial, Colorado. One or two remote days per week may become available once you are established and performing well.

You are the quality function. Leadership here is not managing people, it is defining a practice and getting an organization to adopt it.

• Own software quality strategy for the department, and put it in writing so it can be argued with rather than assumed
• Define what "adequately tested" means at Refi Jet, in terms specific enough that a developer can tell whether they have met it before they open a pull request
• Assess the adequacy of developer-written unit test coverage, and raise gaps as findings with evidence rather than as opinions
• Bring release risk to the Director of Product and Technology Leadership with a clear recommendation and a clear statement of what you are uncertain about, and accept the decision when it goes the other way
• Report on quality in terms leadership can act on: what broke, what would have caught it, what it would cost to catch it next time
• Own the definition of done jointly with Product, covering product acceptance as well as engineering acceptance, so nothing closes until someone has confirmed it does what it was written to do
• Bring quality debt into roadmap planning as prioritized, sized work rather than a standing complaint, and defend the trade-offs with the Director of Product

• Write and execute integration test plans across borrower-facing applications, backend services, internal operations tools, and lending partner integrations
• Design and run the User Acceptance Testing process, including coordinating operations partners who will actually use what we build and translating their feedback into defects a developer can act on, separating genuine defects from change requests and routing change requests to Product instead of absorbing them into scope
• Build and maintain a regression suite, automating where automation pays for itself and keeping the manual coverage deliberate rather than accidental
• Test the failure paths, not only the happy paths. Lender integrations fail, partners time out, data arrives malformed. Those cases are where our real risk lives.
• Write defects that a developer can reproduce without asking you a follow-up question, and verify fixes rather than accepting them
• Run release validation, including post-release verification that what shipped works in production
• Own the test data problem, including how we test realistic scenarios without moving production borrower data into non-production environments
• Use AI-assisted tools as part of normal daily work, including for test case generation and exploratory coverage, and remain fully accountable for what you sign off on

• Review requirements, user stories, and acceptance criteria before development begins, and send back anything that cannot be objectively verified
• Validate features against intent, not only against the ticket. If the story is satisfied and the borrower or agent problem is not solved, that is a finding and you raise it.
• Own cross-product journey testing across My Yes Go , Connex, Refi Me Now , and the borrower-facing application. Most of our real defects live in the handoffs between systems rather than inside any one of them.
• Verify that analytics and event instrumentation ships correctly and fires accurately, so the product decisions we make afterward rest on data we can trust
• Validate feature flags, phased rollouts, and experiment configurations before and…