OMNO · Technical interview field manual
The 60-second brief#
Prepare to show that you can turn a payment requirement into reproducible manual checks, useful API/UI automation, reliable test data and actionable failure evidence. The vacancy is Mid-Level QA Automation Engineer, full-time and on-site in Tbilisi. Your broader Senior QA experience is relevant, but answer at the practical hands-on level this role asks for.
OMNO is described in the supplied job description as a payment orchestrator aggregating multiple PSPs for merchant payment flows. The exact interview format, duration, language, framework, CI platform, database and PSP integrations are unconfirmed. TypeScript/Playwright are practice choices here; SQL/Kafka examples draw on your transferable strengths, not claims about OMNO internals.
Study priorities#
| Priority | Be able to demonstrate | Go to |
|---|---|---|
| P0 | Explain payment lifecycle and safe handling of an uncertain PSP response | Payments and routing |
| P0 | Write API tests checking exact status, shape, ownership and business effects | API and webhooks |
| P0 | Await the response/body correctly; sequence dependent calls | TypeScript |
| P0 | Use reliable locators, assertions and listener-before-trigger | Playwright |
| P0 | Isolate accounts/payments and explain fixture cleanup | Framework |
| P0 | Design boundary, negative and state-transition cases | Manual/test design |
| P1 | Diagnose duplicates or mismatched totals with SQL and correlation IDs | SQL and events |
| P1 | Read CI evidence, review code and communicate defects | CI/Git/debugging |
| P1 | Solve small coding problems while explaining assumptions | Exercises |
| P1 | Give concise answers and credible personal examples | Q&A, CV stories |
Full job-description coverage map#
| Supplied requirement | Preparation evidence |
|---|---|
| QA fundamentals, test design, defect management | Partitions, boundaries, decision tables, state models, defect report and triage |
| Maintain cases and suites for complex web/backend systems | Requirement traceability, layered suites, risk-based regression and maintenance |
| Manual API/UI/integration testing | Exploratory charter, request inspection, cross-user negatives and end-to-end diagnosis |
| Design/implement/maintain automation frameworks | Small POM/client/fixture architecture, explicit config, isolated data and review criteria |
| Script automated tests and integrate CI/CD | TypeScript examples, Playwright tests, Git workflow and annotated CI job |
| Selenium/Cypress/Playwright or REST tools | Comparative decision table; no unsupported claim of a confirmed OMNO framework |
| Git and Jira | Branch/review/conflict basics and actionable bug/acceptance links |
| SDLC and Agile | Refinement, shift-left examples, sprint test scope and release-risk communication |
| Analyze problems, communicate and document | Worked payment timeout/CI cases with evidence and next diagnostic step |
| Degree or equivalent practical experience | Current CV lists a Computer Science bachelor's degree; use actual dates/scope |
| Fintech/payments/high-availability advantage | Transaction integrity, idempotency, webhook delivery, routing failures and truthful financial-system stories |
Your fit, from the freshly checked CV#
| Current CV evidence | How to use it honestly |
|---|---|
| Adjarabet regulatory backend QA: APIs, Kafka, PostgreSQL/Oracle | Explain how you follow a business operation across service/event/database boundaries |
| Develop and maintain Playwright tests in TypeScript for regulatory backoffice | Describe a specific actual test, locator choice, data setup and diagnosis; don't invent years of framework ownership |
| Frontend QA included payments and authorization across weekly releases | Relevant payment UX/regression experience; not proof you designed a PSP routing engine |
| Exactpro Python trade-comparison automation, Allure and Jenkins | Real automation/financial-system evidence; distinguish Python work from current TS practice |
| Frame.so QA function, API/integration testing, mentoring | Practical standards and collaboration; keep personal contribution separate from team outcome |
| FINA ETL/data-integrity and environment integration | Grounded source/target reconciliation and safe environment setup examples |
The CV now says 8+ years across QA-related roles, beginning in 2018. That is broad experience, not eight years exclusively writing Playwright. Kiro/agentic work appears as a current initiative; it is supporting context, not the main focus of this OMNO vacancy.
Study routes#
15 minutes: five minutes payment ambiguity, three minutes Promise/response, three minutes response races, two minutes intro, two minutes questions to ask.
45 minutes: add test design, webhook scenarios, fixtures, CI investigation, then answer the top 20 aloud.
Two hours: 20 min payments; 20 min API/webhooks; 20 min TS; 20 min UI/framework; 15 min SQL/CI; 15 min exercises; 10 min truthful stories and interviewer questions. These are study allocations, not a promised interview agenda.
A strong technical answer#
“I first clarify the contract and risk. I choose the lowest useful layer, create isolated test data, perform the operation and observe the actual business result. I assert the expected positive and negative behavior, preserve correlation evidence and clean up through an authorized mechanism. If the outcome is unknown, I investigate it before repeating a financial write.”
For a 90-second answer, add an alternative and trade-off: why API rather than UI, why polling rather than sleeping, when a mocked PSP is sufficient, and what a real sandbox integration must still prove. Memory hook: contract → risk → layer → evidence → cleanup.
Shared example assumptions#
All /sandbox/..., /test-support/..., merchant, PSP simulator and UI paths are hypothetical test contracts, not OMNO endpoints. Amounts are integer minor units within a declared currency convention. Use only provider-approved sandbox tokens and synthetic data; this guide contains no real card numbers, credentials or payment backend. A Playwright route mock does not prove actual PSP, settlement or database behavior.
Core study material works offline. Optional official references: Playwright API testing, TypeScript handbook. Continue with payment risks.
Quick practice#
What is payment orchestration?
- A unified merchant integration coordinates provider selection and processing
- Verify normalization, configuration and financial effects across provider attempts.
Pitfall: Assuming every PSP has identical semantics.
Authorization versus capture versus settlement?
- Authorization approves or reserves under the contract, capture requests collection and settlement is a later financial stage
- Test each boundary and its own evidence.
Pitfall: Calling an authorization response settled funds.
Payment ID versus attempt ID?
- A payment is a business operation while an attempt represents one provider interaction
- Correlate provider references and effects without treating every attempt as a new purchase.
Pitfall: An ambiguous transaction ID with no system/grain.