CV stories · Technical introductions and credible experience

The 60-second principle#

Use the refreshed CV as factual evidence and distinguish personal action, team outcome, current learning and proposed improvements. You can be experienced in QA while still practicing particular TypeScript syntax. OMNO's Mid-Level title does not require hiding your Senior experience or pretending an unverified personal motivation.

Technical introductions#

30 seconds: “I’m a QA engineer with experience across regulated platforms, financial systems and SaaS. My current work combines backend/API testing, SQL and Kafka investigation with Playwright tests in TypeScript for a regulatory backoffice. Earlier I automated trade comparisons in Python and integrated them with Jenkins. I’m interested in applying that combination of transaction-level reasoning and practical automation to payment orchestration.”

60 seconds: “My QA-related work began in 2018, covering integration/data quality, financial-market systems, frontend releases and regulatory backends. At Adjarabet I develop and maintain Playwright/TypeScript tests and investigate workflows across APIs, Kafka and PostgreSQL/Oracle. My earlier frontend scope included payments and authorization, which helps me connect user behavior to backend outcomes. At Exactpro I wrote Python trade-comparison automation with Allure and Jenkins. At Frame.so I built a QA approach, led API/integration testing and mentored contributors. For OMNO I would bring hands-on investigation, reproducible cases and maintainable automation while learning the actual provider and routing contracts.”

Do not claim you implemented OMNO-style multi-PSP routing unless you have genuine evidence outside the supplied CV. Payments/frontend testing and post-trade systems are relevant transferable experience, not identical responsibilities.

Role-fit mapping and honest boundaries#

Six truthful STAR outlines#

The bracketed fields below are intentional personal-evidence prompts, not fabricated finished stories. Replace them with genuine details before speaking.

Backend/event-driven defect#

Situation: current regulatory backend scope at Adjarabet. Task: [ACTUAL WORKFLOW AND FAILURE]. Actions: use a real case correlating API request, Kafka behavior and PostgreSQL/Oracle facts; name what you personally checked and what developers confirmed. Result: [TRUE OUTCOME; METRIC ONLY IF KNOWN]. Technical follow-up: What ruled out stale data? How did you know the event belonged to that operation? What regression would catch it?

Playwright/TypeScript maintenance#

Situation: maintaining regulatory backoffice automation. Task: [ACTUAL TEST OR FAILURE YOU OWNED]. Actions: describe real locators, setup, assertion, async handling and failure evidence. If the improvement shown in this guide is a proposal, label it as such. Result: [TRUE TEST/REVIEW OUTCOME]. Follow-up: Why this locator? How was the account isolated? What happened if setup or cleanup failed?

Frontend payments or authorization#

Situation: earlier Adjarabet frontend QA included weekly releases and payment/authorization modules. Task: [ONE REAL PAYMENT OR AUTHORIZATION SCENARIO]. Actions: actual reproduction, network/UI inspection, expected requirement and cross-functional defect discussion. Result: [ACTUAL FINDING/RELEASE DECISION]. Follow-up: What did the UI prove? Which backend/provider facts were accessible? Do not turn manual release testing into routing-engine implementation.

Python financial comparison and Jenkins#

Situation: Exactpro, automated trade comparison with Python/Allure and Jenkins, specifically the automation period Apr–Oct 2020 in the current CV. Task: [REAL COMPARISON REQUIREMENT]. Actions: explain actual matching keys, mismatch evidence, reporting and pipeline integration. Result: [ACTUAL RESULT]. Follow-up: How were duplicates/missing records handled? What failed the build? Your current CV lists promotion from Junior to Middle; keep the actual timeline rather than the older simplified baseline.

QA process and collaboration#

Situation: Frame.so Lead QA, part-time Sep 2022–Oct 2024, built QA function/release approach. Task: [REAL INITIAL CONSTRAINT]. Actions: actual strategy/scope/tooling, API/integration checks, defect/release visibility and mentoring. Result: [TRUE OBSERVABLE CHANGE]. Follow-up: How did you prioritize? What did you personally implement? What was a trade-off or thing you would improve?

ETL/data integrity#

Situation: FINA integration/environment/data work beginning in 2018. Task: [REAL SOURCE/TARGET ISSUE]. Actions: actual SQL/NoSQL validation, ETL investigation, safe environment configuration and client coordination. Result: [TRUE RECONCILIATION/FIX/ESCALATION]. Follow-up: What key/time window did you use? How did you avoid misleading equal counts? Which access was authorized?

Senior CV, Mid-Level vacancy#

Prepare your genuine reason for considering the role; the job description and CV do not establish it. A truthful framework is: “I’m evaluating the hands-on scope, product domain and team expectations rather than title alone. My experience can contribute to API/data investigation and automation, and I want to understand what ownership and growth this role offers.” Use it only if it reflects your actual position. Ask about expected coding depth and framework ownership; do not invent salary or personal preferences.

How much automation? State actual Playwright/TypeScript maintenance and earlier Python automation, then explain a concrete example. Broad 8+ years of QA-related work does not equal 8+ years of continuous automation. What are you practicing? “I’m sharpening TypeScript async/types and reliable Playwright patterns, and I can show how I validate the code.” Be direct without undermining genuine backend/domain strengths.

Technical behavioral questions#

Questions to ask OMNO#

1. Which automation language/framework and CI tools are currently used, and which parts need the most maintenance?
2. How are PSP failures, unknown outcomes and late callbacks simulated in the test environment?
3. Which payment integrity risks are most important for this role in the first months?
4. How much framework ownership versus manual/exploratory testing is expected day to day?
5. What data/provider sandbox access and traceability are available to QA, and how are secrets/artifacts protected?
6. How do developers, product and QA agree routing/refund acceptance criteria and release gates?

Closing answer#

30 seconds: “My strongest contribution is connecting UI behavior to API, event and data evidence, with real Playwright/TypeScript and Python/CI experience. For this role I would prioritize reproducible payment scenarios, isolated automation and clear risk communication, while learning the team's actual contracts and stack.”

Memory hook: actual context, personal action, observed evidence, honest limit. Return to brief or technical questions. This chapter uses the CV retrieved for this preparation; raw CV/contact details remain private.

Quick practice#