P0 · Chapter 00 / 15

Interview brief

The 60-second cheat sheet#

The recruiter described a 90-minute interview with Playwright / TypeScript as the primary focus. The exact vacancy and agenda are unconfirmed. Prepare for the shared automation core first, then AI engineering and truthful career evidence.

Position	Shared core	Additional emphasis
Senior Test Automation Engineer	TS/JS, Playwright, UI/API/E2E, framework design, CI, Git, diagnosis, mentoring	Maintainable automation and release confidence
Senior AI Test Automation Engineer	The same automation engineering foundation	Coding agents, MCP, Skills/Powers, GitLab gates, TestRail/Jira, data reconciliation, LLM evals; optional LangGraph/MLOps

Interview response pattern: define → choose using a concrete condition → show code/evidence → name a failure mode → explain validation and maintenance.

Top eight priorities#

Promises / async: distinguish Promise, response and JSON body.
Locators and assertions: actionability is different from business completion.
API lifecycle: returned ID, exact status, runtime body check, cleanup.
Fixtures / POM: scope and lifecycle, small semantic objects.
Auth / data isolation: snapshot versus live server session.
CI debugging: evidence before changing timing.
GitLab gates: blocking checks plus merge settings.
Agents / evals: verified context and objective fault detection.

Skill-fit matrix#

Evidence	Interview use	Honest growth area
Backend/regulatory API, PostgreSQL/Oracle, Kafka at Flutter/Adjarabet	Explain distributed failure diagnosis and data correctness	Express the same reasoning precisely in TS
Python trade comparison, Allure and Jenkins at Exactpro	Real automation and CI evidence	Do not turn this into continuous Playwright ownership
Playwright regulatory backoffice automation	Concrete UI automation example	Rehearse fixture typing and runner architecture
Built QA approach at Frame.so, coordination/mentoring	Risk, process and leadership decisions	Do not claim unverified framework architecture results
AI feature testing and tool familiarity	Suggestions, rewriting, summaries, labeling; agent workflow design	Quantitative eval harness is a design to explain unless actually implemented

QA history begins in 2018. “6+ years” is the supplied CV wording; the dated work history extends beyond it. Broad QA tenure does not equal automation-only tenure. English B2–C1: use short precise sentences, not memorized jargon.

Study routes#

Time available	Sequence and outcome
10 minutes	2 min async, 2 min response races, 2 min isolation, 2 min gates, 2 min intro
30 minutes	Above + 5 min fixtures, 5 min API lifecycle, 5 min polling, 5 min top 25
2 hours	20 min TS; 25 min Playwright; 20 min framework/auth; 15 min API/Kafka; 10 min CI/RCA; 15 min AI/evals; 15 min coding aloud and STAR. Use the chapter links in the navigation.

Hypothetical 90-minute distribution#

This is practice scheduling, not a confirmed EPAM agenda: introduction 5; TS coding 20; Playwright coding/design 25; API/CI diagnosis 20; AI/behavioral 15; candidate questions 5 minutes. Ask clarifying questions about the real contract during coding.

Professional introduction and differentiators#

“I’m a Senior QA Engineer with experience in backend and regulatory systems, API testing, SQL and Kafka integrations. I have Python automation and Jenkins experience from Exactpro, Playwright experience in regulatory backoffice testing, and QA leadership experience at Frame.so. I focus on reliable evidence of business correctness and I’m deepening my TypeScript automation skills.”

Automation role: My backend experience helps me isolate service and data failures before blaming UI timing. I connect UI coverage to API contracts and CI evidence.

AI role: I have tested AI-assisted product features and use coding tools with reusable instructions and integrations. My proposed engineering workflow combines verified repository context, Skills/Powers, constrained tools, automated validation and human review.

Twenty essential concepts#

Term	Precise meaning
Promise	Future fulfillment or rejection, not the response itself
await	Suspend this async function until a value settles
Locator	Reusable query describing how to find element(s)
Actionability	Preconditions checked before an action, such as visibility/stability
Web-first assertion	Retried observation of browser state until expectation or deadline
Fixture	Typed resource dependency with managed setup and teardown
POM	Encapsulation of page interactions and locators
Context	Isolated browser session container
storageState	Saved browser authentication-related state snapshot
Worker	Test-runner process executing tests
Shard	Partition of the suite executed by a separate run/job
Idempotency	Repeating an operation has the same intended effect
Eventual consistency	Replicas/projections may converge after a delay
Correlation ID	Identifier connecting a flow across services/events/logs
Contract test	Check of an agreed interface and compatibility
Quality gate	Required validation that blocks progression on failure
MCP	Protocol between AI applications and integration servers
Skill / Power	Platform-specific packaged procedures and possibly executable tools
Eval harness	Versioned, repeatable measurement of AI behavior
Mutation test	Inject a controlled fault and check whether tests detect it

Twenty rules worth saying aloud#

Rule	Boundary / caution
Await the response, then await JSON	`status()` itself is synchronous
Concurrency for independent work	`Promise.all` does not cancel siblings
Register events before triggers	A response is not completed business processing
Assert the outcome with a locator	Creating a locator does not wait
Prefer accessible locators	Stable CSS IDs are still valid contracts
Poll a meaningful state	Bound the wait and recognize terminal failure
Keep contexts isolated	Server data can still collide
Reuse auth for compatible tests	Saved cookies do not extend backend TTL
Unique account per conflicting scope	Include pipeline and shard identity
Cleanup in finally	Network failure can prevent cleanup
Exact HTTP contract first	2xx alone does not validate business outcome
Query before replaying payments	Keys help only if backend enforces them
Use the lowest useful layer	Some integration risks require real E2E
Trace before timeout changes	Traces may contain secrets
Retry for diagnosis	Retry is not a reliability fix
Quarantine with replacement evidence	Skipping removes coverage
Mandatory smoke gate	Merge settings must require successful pipelines
Verify agent context	Rules need permissions and deterministic checks too
Measure fault detection	High pass rate can hide weak tests
State only true career results	Fill unknown metrics from genuine records

Last-minute demonstration checklist#

Explain a reason, an alternative and its trade-off. Write a positive assertion and a negative case. Show what happens on failure, how resources are cleaned, what risk remains, and who maintains the test. Bring one backend investigation, one automation example, and one leadership story with true outcomes.