QA Engineer
First PrinciplesJob Description
About First Principles
First Principles is a product consultancy that builds radical value for ambitious, emerging technology startups. We provide product leadership and strategic support, blending modern technology with thoughtful design to shape tomorrow's products. We were founded by startup and enterprise leaders who have built and scaled products across many industries.
We work with clients in four ways: AI-first PM training and certification, product coaching, fractional product leadership through CPOs and PMs who set vision and keep roadmaps on track, and AI-first product squads that go from concept to prototype in days instead of months. Our team runs on curiosity, empathy, and continuous improvement.
The Product
You'll be working on a text fundraising application that helps political and non-profit groups raise money for their campaigns and causes. It handles the full lifecycle: registration with carriers, phone number provisioning and management, message building and sending, and detailed metrics and tracking.
The product is at an inflection point. We spent the last year and a half building the first version and running it as an internal tool. Our client is a texting firm, and we built this to replace their existing platform with something that costs half as much and does exactly what they need. We're now building differentiating features and engineering for scale as we prepare to launch it as a standalone SaaS product over the next year, with plans to roll it out to our client's own clients so they can run campaigns themselves by the end of 2026.
The Role
We're looking for someone who sits at the intersection of QA, engineering, and product: an expert in test automation who also has the product sense to understand how the application actually gets used, not just how it works mechanically.
In practice, you and the product manager should become the two people who understand real customer flows and what correct results look like better than anyone else on the team, including the engineers. The engineers know how their features work. You'll know how the system is supposed to behave end to end, and you'll be the one who can tell a genuine defect apart from expected behavior.
You'll start by testing things manually, because that's how you'll learn the system deeply and figure out exactly what needs to be checked. From there you'll automate it, ideally writing down the manual steps clearly enough that AI tooling can help you build out the scripts while you move on to testing the next thing. Manual testing never fully goes away, especially for brand new features, but the goal is a first-class automated suite that frees you and the team from re-checking the same ground every release.
Responsibilities
Manual and release testing. This is a big part of the role, shared closely with the product manager rather than owned outright. Manually test new features before release, focusing on the full range of scenarios including the unhappy paths, not just the happy path. Help drive release preparation and post-release testing: running code freezes, identifying what's changed and what needs checking, building and running smoke and regression tests, and making sure new work is genuinely ready to ship. A lot currently goes untested each release, including phone numbers, brands, campaigns, user auth, and messaging reports, and closing that gap is a big part of why this role exists.
Test automation. Build and maintain automated test suites across API, web UI, and service-to-service layers, choosing the right level of test rather than defaulting to brittle UI tests. The web interface is a natural place to start building automation early. Use AI tooling to accelerate this wherever it helps, but be able to review and write and modify the code yourself when the tooling needs it.
Own the test / proxy API. Take ownership of the proxy and test environment that simulates message sending. Right now different engineers have each built pieces of this for their own work, and it's drifted away from reality, for example generating one donation per message, which isn't realistic. We want one person who owns this, keeps it updated as new functionality ships, and makes it emulate real production conditions as closely as possible. The aim is realistic testing, not artificially over-stressing the system, since over-testing a dynamic system creates pressure in places that wouldn't see it in production.
Bug reproduction and reporting. Reproduce issues reported by the client and end users, pin down what actually triggers the problem, and document it clearly with the evidence engineering needs, such as reproduction steps, trace IDs, log excerpts, and metrics, so they can act without re-investigating. A good chunk of reported "bugs" turn out to be confusion rather than defects, so part of the value is sorting one from the other.
Performance and load testing support. Set up the framework and configuration for performance and load tests, run them on a schedule, and help facilitate reviewing the results so the team can act on them. Engineers still own performance testing of their own work and fixing what surfaces; you provide the tooling, run the comprehensive tests, and serve as the subject matter expert they come to.
Environment configuration and light DevOps. Configure and operate test and staging environments so tests can run reliably: scheduling automated test runs through CI, making sure jobs kick off and hit the right environment with the right keys, and inspecting queues and AWS metrics when something isn't behaving in a distributed, queue-based setup.
Process and collaboration. Work with the PM during requirements gathering to help document manual test cases as features are designed. Help improve the team's overall QA process over time.
Requirements
What We're Looking For
Automation expertise is the non-negotiable. We can help the right person develop product sense, and manual testing can be taught by showing someone the system. The skill we can't easily build internally is real depth in test automation. You should be an expert with modern UI and API automation frameworks such as Playwright, Selenium, or similar, not someone learning them on the job. We're open to your view on the right tooling for our stack.
Testing mindset and detail orientation. You write clear, complete test cases and reproduce bugs methodically. You're the kind of person who notices the scenario nobody else thought to check, and you document observations so precisely that engineering can act on them immediately.
Distributed and event-driven systems. You understand producer/consumer and pub/sub patterns and their specific failure modes: consumer lag, message redelivery and duplication, poison messages and dead-letter queues, and what happens when one stage runs slower than its upstream. You can trace a single logical operation as it crosses multiple services and queues, reason about where a discrepancy was introduced, and tell a real defect apart from normal lag or eventual consistency. Debugging a monolith is one thing; not missing anything in a system where events are passing around everywhere is another, and that's the skill that matters here.
Our stack. You don't need every one of these on day one, but you should be familiar with most of what we use and comfortable with these types of systems and tools:
•
AWS as our cloud platform
•
Lambda, which powers our testing environment; worth knowing its limitations versus the real API
- JavaScript and TypeScript
•
Queues, specifically BullMQ, though comfort with similar queue-based systems matters more than the exact one
- DocumentDB
- Redis
- Some DevOps familiarity for standing up environments and scheduling test runs
AI in the QA workflow. Comfort using AI tools to support testing and to help generate automation code. This is increasingly part of every engineering role, and we lean into it.
Engineering ability. Enough general engineering and scripting skill, in Python, JavaScript/TypeScript, or similar, to build your own tooling and harnesses, and to modify automation code so it works with AI agents rather than waiting on the engineering team to do it for you.
Product empathy. Whether you arrive with it or build it here, you'll need to develop a genuine feel for how the application is used in the real world, so you can look at data and behavior and know whether it's right.
Nice to Have
- Experience testing streaming data pipelines or analytics systems
- Familiarity with infrastructure-as-code such as Terraform, CloudFormation, or CDK
- Familiarity with contract testing between services, such as Pact, and with chaos or fault-injection testing
- Experience validating real-time analytics pipelines for correctness under load
Benefits
- Engagement type: 1099 contractor
- Location: Fully remote
- Working hours: Flexible Schedule. US timezone overlap required
Originally posted on Himalayas
