thriwe QA Engineer Interview: Questions, Experience & Prep (2026)

Thriwe is a fintech company that builds loyalty, rewards, and employee-benefits platforms for banks, insurers, and enterprises across India and international markets. Their QA team tests complex redemption flows, third-party API integrations, and financial-grade user journeys where a missed defect can directly affect a customer's money or benefits access.

Candidates typically report 2 to 4 rounds: an HR screening call, one or two technical rounds focused on manual testing, SQL queries, and API testing with tools like Postman, followed by a managerial or culture-fit discussion. The process is generally described as conversational rather than highly algorithmic. Hiring timelines are typically 1 to 3 weeks.

Thriwe currently has 11 open QA Engineer roles, making this an active hiring cycle. Salary ranges based on knok jobradar data reflect the broader QA market:

For Thriwe-specific compensation, check Glassdoor or levels.fyi for current employee-reported figures.

These questions are commonly reported by candidates who have interviewed for QA roles at fintech and rewards-platform companies like Thriwe:

1. Walk me through how you would test a reward-redemption flow end to end.
2. How do you test third-party API integrations when the partner sandbox is unreliable or unavailable?
3. Describe your experience with Postman or similar API testing tools. How do you set up collections and environment variables?
4. A bank client reports that users are not receiving their cashback. How do you triage and isolate the defect?
5. What SQL queries do you write to validate data correctness in a loyalty or transaction database? Give a specific example.
6. How do you approach regression testing when the product team ships new features every sprint?
7. Explain how you would write test cases for a 'first transaction bonus' feature that must apply only once per user.
8. What is the difference between functional testing and integration testing? Give a fintech example.
9. How do you handle a situation where a developer says 'it works on my machine' but you can reproduce the bug consistently?
10. Describe a time you found a critical bug just before a release. What did you do?
11. How do you prioritize test cases when you have limited time before a go-live?
12. What automation frameworks have you used, and how did you decide what to automate versus keep manual?

Q: Walk me through how you would test a reward-redemption flow end to end.

*Situation:* At my previous company, we launched a new cashback redemption feature for credit card users. The flow involved the user selecting a reward, the system calling a payment gateway API, debiting the points, and crediting the bank account.

*Task:* I was responsible for full QA sign-off before the feature went live.

*Action:* I mapped out every step of the user journey and wrote test cases covering happy paths, boundary values (minimum redemption amount, maximum cap), and negative cases like insufficient points, gateway timeout, and duplicate submission. I used Postman to test each API call independently, then tested the complete flow in staging with real test accounts. I also validated the database rows after each transaction to confirm points were correctly debited and credited.

*Result:* I caught two critical defects: a duplicate-debit bug triggered by a rapid double-tap on mobile, and a points balance that did not refresh in real time. Both were fixed before launch, and the feature went live with zero post-release severity-1 issues.

---

Q: How do you handle a situation where a developer says 'it works on my machine' but you can reproduce the bug?

*Situation:* While testing a partner voucher integration at my last role, I found that the voucher code was sometimes returned as null in the API response. The developer could not reproduce it in their local environment.

*Task:* I needed to prove the defect was real and help the team fix it before an upcoming client demo.

*Action:* I documented each reproduction step with screenshots, the exact API request payload, and the response body showing the null value. I recorded the network call in Postman and shared the full collection. I also checked the staging logs and found the issue occurred only when the partner API response was slow, triggering a timeout that was not handled correctly. I shared the relevant log lines with timestamps so the developer could see the exact failure sequence.

*Result:* The developer could now reproduce it reliably by simulating the delay. The root cause was a missing null-check on slow responses. The fix was deployed the same day, and the demo went smoothly without any escalation.

---

Q: How do you prioritize test cases when time is short before a go-live?

*Situation:* Sprint end was approaching and the team cut the testing window from 3 days to 1 day due to a business deadline.

*Task:* I had to decide which tests to run and which to defer without putting the release at unacceptable risk.

*Action:* I used a risk-based approach. I listed all test cases and tagged them by business impact (money movement, user authentication, and partner integration got highest priority) and by change area (only features touched in that sprint). I ran all high-priority and all change-area tests first, then deferred edge cases around UI cosmetics and non-critical reporting screens.

*Result:* I covered all the high-risk financial and authentication paths in the available time and completed the majority of planned test cases. The release went live without a severity-1 issue. I documented the deferred tests and ran them the following day as a post-release check.

STAR (Situation, Task, Action, Result) is the most useful structure for behavioural and scenario questions. Keep Situation and Task brief. Spend most of your time on Action, describing what you personally did step by step. Always end with a concrete Result. Avoid ending with a vague 'it went well.' Name the outcome: the release was saved, the client escalation was avoided, or defect density dropped that quarter.

For technical 'how would you test X' questions, use a structured Test Design approach: (1) understand the feature and its acceptance criteria, (2) identify user flows including happy path, edge cases, and negative cases, (3) list the data conditions to cover, (4) decide the testing level (unit, API, UI, or integration), and (5) state what tools you would use and what you would validate in the database.

For debugging or triage questions, use a Layered Isolation approach: start at the UI, then check the API request and response, then check logs, then check the database. Show interviewers you think in layers and do not jump to conclusions before gathering evidence.

For prioritisation questions, mention risk-based testing explicitly. Interviewers at product companies like Thriwe want to see that you understand business impact, not just raw test coverage counts.

Domain awareness is the first thing Thriwe interviewers check. They want candidates who understand that a bug in a cashback or insurance-benefit flow is not just a UX problem. It can mean a user loses money or a bank client raises a critical escalation. You do not need prior fintech experience, but you must show that you have thought about financial data accuracy, idempotency, and audit trails.

API testing comfort is non-negotiable for mid and senior roles. Be ready to explain how you use Postman, how you validate response schemas, and how you deliberately test for error codes (4xx and 5xx). If you have used API mocking or contract testing, mention it with a specific example.

SQL for data validation comes up in almost every technical round. Practice writing joins and aggregate queries to check that a transaction row was created correctly, that points balances add up, or that a user is not double-enrolled in a scheme.

Communication and ownership matter because QA at Thriwe often means coordinating between internal developers, product managers, and external bank or insurer partners. Interviewers look for candidates who raise issues clearly, document defects thoroughly, and do not let problems slip silently through the cracks.

Step 1: Understand Thriwe's product. Spend time reading their website and LinkedIn page. Know that they build loyalty and employee-benefit platforms for banks, insurers, and corporates. Think about what kind of bugs would be most damaging in that context, and prepare an example of how you would approach testing a core flow like a rewards redemption or a benefit activation.

Step 2: Refresh your API testing skills. Open Postman and practice creating a collection with environment variables. Know how to assert on status codes, response body fields, and headers. Practice testing a free public API so you can narrate your process confidently in an interview.

Step 3: Practice SQL. Write queries using GROUP BY, HAVING, JOIN, and subqueries. Focus on data validation scenarios: checking for duplicate rows, verifying totals, or finding records that should not exist in a transaction table.

Step 4: Prepare 3 to 5 STAR stories. Cover at least: finding a critical bug, handling a disagreement with a developer, working under time pressure, and improving a testing process. Each story should have a specific, nameable outcome.

Step 5: Write sample test cases. Pick a fintech feature (like a referral bonus or a policy-renewal reminder) and write 10 test cases for it. Practice talking through your thinking out loud, since interviewers often ask you to verbally walk through test design rather than write it down.

Step 6: Prepare questions to ask. Ask about the team's automation coverage, how bugs are triaged between QA and development, and what the biggest quality challenge is right now. Thoughtful questions signal genuine interest in the role.

Describing testing only at the UI level. Many candidates explain test cases purely in terms of clicking through screens. Thriwe's QA work involves API and database layers. Always mention that you validate data at the backend, not just what appears on the UI.

Being vague about tools. Saying 'I have used automation tools' is not enough. Name the tools (Selenium, Postman, JMeter, Cypress, RestAssured), state the context you used them in, and describe one concrete thing you accomplished with each.

Skipping the Result in STAR answers. Many candidates describe Situation and Action well, then end with 'the bug was fixed.' Interviewers want to know the impact: was the release saved, did a client escalation get avoided, did the defect escape rate improve? If you cannot quantify it, at least name the business outcome clearly.

Not asking clarifying questions in test-design exercises. If the interviewer asks 'how would you test our rewards API?' and you immediately start listing test cases, you miss a chance to show analytical thinking. Ask first: what are the acceptance criteria, what are the known edge cases, and what does the API contract look like?

Ignoring negative and boundary test cases. Entry-level candidates often cover only the happy path. For a fintech company, edge cases like zero-balance redemption, concurrent transactions, or a user changing their linked account mid-flow are exactly the scenarios that cause production incidents. Show that you think about these proactively from the start.