Builder QA II
- Compensation
- Not disclosed
- Location
- Hyderabad Telangana
- Work setup
- Not specified
- Seniority
- Not specified
- Employment
- Not specified
- Experience
- Not specified
- Category
- Qa
- Posted
Skills
Must have
- You’ve shipped one. You have built at least one autonomous agent or complex LLM workflow that real people used for real work — not a weekend demo. You know how it failed, because it did.
- You write real code. Python that goes to production and gets reviewed like anyone else’s. If your automation experience stops at a record-and-playback tool, this isn’t the role.
- The manual-task hater. You have a physical reaction to repetitive work. If you do it twice, you’ve already started drafting the automation.
- Technically fearless. A 500-table undocumented legacy schema isn’t complexity, it’s a puzzle about to get solved. You aren’t intimidated by spaghetti code — you’re the one who brings the sauce.
- Rigor over hype. You love the new models and you still ask for the numbers. You know the difference between a cool demo and a pipeline people rely on every release.
- Suspicious by instinct. Your first question about any green build is what it didn’t check.
Full description
Job Description
You are an engineer who specialises in proving things work. The distinction between “dev” and “QA” work is not one we maintain: you read the application code, you write production-grade Python, and you build agents. The difference is what you point them at.
- Core DNA
-
AI-Native Workflow. You use AI to accelerate everything you do as a default, not an experiment. You have opinions about which tools earn their place.
-
Agentic Implementation. You build, debug and deploy autonomous agents — LLM-driven test generation, Playwright browser-use agents, self-healing locator strategies — against complex ERP screens and workflows.
-
Legacy-to-Modern Bridge. Some of what you’ll test is a modern web rewrite. Some is a desktop application older than your career. Both are puzzles.
-
Evidence Over Confidence. A generated test that has never been executed is not a test. You know your own false-positive and flake rates rather than claiming there aren’t any.
- What You Own
The ticket-to-test pipeline. An agent that reads a requirement or defect, understands the affected area, and produces a real test — grounded in the actual application, not in what the model imagines the application looks like. Hallucinated locators are the failure mode that kills these systems; preventing them is your problem.
Execution and stabilization. Generation is the easy half. Your pipeline isn’t done when a test file exists or a ticket gets created — it’s done when the test has run against a real build, passed repeatedly, and earned its place in the suite. Flake is the enemy, because a suite nobody trusts is worse than no suite.
Coverage that means something. You can tell the difference between a suite that covers the code and a suite that covers the risk. You use mutation testing and real defect history rather than counting tests, and you argue for the edge cases that actually bite: fiscal calendars, multi-currency, partial shipments, period-end adjustments.
- Where You Might Lean In
-
Test Generation & Grounding — the retrieval and context problem. How does an agent know what the screen really contains, what the business rule really is, and what changed in this release?
-
Adversarial & Red-Team — you build agents whose job is to break things. Programmatic prompt optimization (DSPy), fuzzing business logic, hunting the input nobody thought of.