07 — Full Round 1 Timed Mock Interview + Self-Scoring Rubric¶
One-line note: A complete, run-it-yourself timed reproduction of the documented Candescent Round 1 (Instructions → Intro → Framework Design → EP/BVA → Methodologies → Communication), with banking-flavored and alternate scenario sets, a 30-question rapid-fire round, a 1–5 self-scoring rubric, and a night-before cheat sheet. Answer cues only — full model answers live in the sibling files
01–06.
0. How to use this mock¶
This is a practice harness, not a study sheet. Read it once silently to learn the flow, then run it as a real interview.
Rules of engagement (mirror the real Round 1): - Time it. Target 45–60 minutes for one full run. Use a visible timer; honor the per-section budgets below. - Out loud. Speak every answer aloud in full sentences. Do not type or read. The interviewer is grading spoken English and structure, not your inner monologue. - Record it. Phone or screen recorder. You will learn more from re-watching 10 minutes than from reading for an hour. - Whiteboard the design section. Section 3 is a talk-and-draw skill. Have paper or a draw tool open and sketch the layered diagram live. - No pausing to look things up. If you blank, say a placeholder and move on — that is what you must do in the real room.
Two passes:
1. Pass 1 — cold self-test. Run the whole mock with this file's prompts only. Keep the answer-cue blocks covered. Record yourself. Score with the rubric in §6.
2. Pass 2 — check against the kit. Re-do the weak sections, this time after reading the matching sibling file (01–06). Compare your spoken answer to the cue bullets here and the full answer there. Re-score; the gap between Pass 1 and Pass 2 is your study list.
Anti-AI behavior the interviewer watches for (Section 1): slow, verbatim repeating of the question to stall; eyes drifting to a second screen; long silent gaps then a suspiciously polished monologue. Counter it by paraphrasing the question in one short clause ("So, designing a framework from scratch for a banking portal — let me start with the layers"), then talking continuously in your own voice.
Two full runs are provided: Mock Set A (banking-primary + one generic variant) and Mock Set B (alternate JD sample scenarios). Do A in week 1, B as a fresh cold run later so you are not just reciting A.
MOCK SET A — Banking-primary run¶
Total budget ≈ 50 min. Read the interviewer prompt aloud (or have a friend read it), start the timer, answer, then uncover the cue.
A1. Instructions (≈2 min — not scored)¶
Interviewer says: "Before we start — please show me your room with your camera: the desk, behind your monitor, and confirm there's no second screen or phone in use. Keep your video on the whole time. Answer in your own words; if I see you repeating my questions slowly or reading off-screen I'll note it. Ready?"
What to do (not a graded answer): - Pan the camera calmly, confirm "single monitor, phone is away, no one else in the room." - Sit square to camera, good light, video stays on. - Practice the micro-paraphrase habit now so it is natural by Section 3.
A2. Introduction (≈4 min — scored: communication)¶
Interviewer says: "Tell me about yourself — your background, what you've worked on, and what you're looking for in this role."
What a strong answer hits (cue — full version in 06-behavioral-and-intro.md)
- **60–90 seconds, structured:** who I am → core stack → 1–2 proof projects → why Candescent/BFSI → what I want.
- Lead with **SDET identity**: "QA/SDET, ~X years, design and own automation frameworks — not just write scripts."
- Name the stack crisply: **Java / Selenium / TestNG / RestAssured**, **Playwright / TypeScript**, plus **security / VAPT**.
- One framework-ownership proof + one API-chain proof (sets up Section 4's API→email→SMS).
- **Bridge to banking unprompted:** mention money-accuracy, real-time balances, security/PII as things I care about — signals BFSI fit.
- Close with the "ask": a role where I architect scalable, multi-environment automation for a regulated banking product.
- **Avoid:** life story, listing every tool, mumbling the years of experience.
A3. Functional & Automation — Framework Design (≈15 min — scored: framework design, tool depth, BFSI framing)¶
Interviewer says (banking variant): "Suppose you're starting fresh. Design an end-to-end automation framework for a digital banking portal — online and mobile banking for a US bank: login, view accounts and balances, fund transfers, bill pay, statements. Walk me through the architecture. Name the major classes, the hierarchy, and the components. Then give me one sample test case as it would look in your framework."
Generic variant (use on a re-run): "Design an automation framework for a generic e-commerce web application — same depth: layers, classes, components, one sample test."
Likely follow-ups the interviewer fires: - "Where does test data come from, and how do you keep prod data safe?" - "How do you run this across QA / pre-prod / prod environments?" - "Cross-browser and mobile — how?" - "How do you handle the API side, not just UI?" - "What's non-functional here — anything banking-specific you'd test?"
What a strong answer hits (cue — full blueprint in 01-framework-design.md)
- **Open with layers, top-down** (draw it): **Tests → Page/API objects → Business actions → Core utils → Config/Env → Test data → Reporting/CI.** State that layering is what makes it *scalable and maintainable* — that's the grade.
- **Name the classes/hierarchy:** `BaseTest` / `BasePage` (parents), `DriverFactory`/`DriverManager` (thread-safe driver), `ConfigReader` (env profiles), `WaitUtils`, page objects (`LoginPage`, `AccountsPage`, `TransferPage`), business-action classes (`TransferService.transfer(from,to,amount)`), `ApiClient`/service classes, `TestDataProvider`, `ReportManager`, TestNG `listeners` (retry + fail-screenshot).
- **Components, named:** runner (TestNG), build (Maven), cross-browser (Selenium Grid / BrowserStack), mobile (Appium for the app), multi-env config (QA/dev/pre-prod via profiles + externalized secrets — never hard-code), data-driven (JSON/Excel/DB), reporting (Allure/Extent), CI (Jenkins/GitHub Actions), parallel execution.
- **Banking-specific framing (this wins the section):**
- **Money math** — assert on `BigDecimal`/exact precision, never float; verify rounding and currency.
- **Idempotent transfers** — a retried transfer must not double-debit; test it.
- **Real-time** — balance updates reflect immediately after a transfer.
- **Security/PII** — mask account numbers in logs/reports, secrets in a vault, test authZ (User A can't see User B's accounts), session timeout.
- **Audit trail / compliance** — every money movement is logged.
- **Sample test case** — speak it as a real flow: `transferFunds_validAmount_debitsAndCreditsCorrectly`: login → capture both balances → transfer $100 → assert source −100, destination +100, exact precision, transaction appears in history, confirmation shown. Mention the negative twin (insufficient funds blocked).
- **API + UI story:** UI for the journey, RestAssured to set up state and verify the backend ledger independently — faster and more reliable than UI-only.
- **Avoid:** jumping straight to "I'd use Selenium and write a login test." They want **architecture first**.
A4. Test Case / Test Plan Enumeration — EP + BVA (≈12 min — scored: test-design rigor, BFSI framing)¶
Interviewer says (banking variant): "Here's a fund-transfer screen. The 'Amount' field accepts a transfer from $0.01 up to a daily limit of $10,000.00, two decimal places, USD. There's also a 'From account' dropdown and a 'To account' field. Give me a test plan using Equivalence Partitioning and Boundary Value Analysis. Walk me through your partitions and boundaries."
Likely follow-ups: - "What are the exact boundary values you'd test on the amount?" - "Beyond the amount field — what else on this screen?" - "What about non-numeric or malformed input?" - "Negative / error cases the customer could hit?"
What a strong answer hits (cue — full tables in 02-test-plan-ep-bva.md)
- **State the method first:** EP = group inputs into classes that behave the same, test one per class; BVA = test the edges of each valid range because bugs cluster there.
- **Equivalence partitions for Amount:**
- Invalid-low: ≤ 0 (0, negatives).
- Valid: 0.01 → 10,000.00.
- Invalid-high: > 10,000.00.
- Invalid-format: > 2 decimals (10.999), non-numeric ("abc"), empty, symbols, spaces.
- **Boundary values (the money point):** **0.00 (reject), 0.01 (min accept), 9,999.99, 10,000.00 (max accept), 10,000.01 (reject).** Plus precision boundary: 0.01 accepted, 0.001/0.009 rejected or rounded per spec.
- **Other fields:** From-account dropdown (each account, sufficient vs insufficient balance), To-account (own vs third-party, invalid/closed account), same source=destination blocked.
- **Banking-specific cases (differentiator):** insufficient funds → blocked, daily-limit aggregation (two transfers summing over limit), idempotency on double-submit, currency/precision, authorization (can't transfer from an account you don't own), and a security nudge — injection/XSS in the amount/account fields.
- **Present as a table** out loud: "Test case, input, partition/boundary, expected result." Structure is graded as much as coverage.
- **Avoid:** only listing happy-path numbers; forgetting format/precision; ignoring non-functional banking concerns.
A5. Software Development Methodologies — TDD / BDD / ATDD (≈10 min — scored: methodology clarity)¶
Interviewer says: "Explain TDD, BDD, and ATDD and how they differ." Then follow-ups, asked one at a time: 1. "Write me a quick Gherkin scenario for a fund transfer." 2. "How do you organize step definitions so they don't become a mess?" 3. "How do you handle test data across different environments in BDD?" 4. "What's the ROI of BDD — is it worth the overhead?"
What a strong answer hits (cue — all 8 Q&A in 04-methodologies-tdd-bdd-atdd.md)
- **One-line differentiators:** **TDD** = developer-level, red-green-refactor, drives design via unit tests. **BDD** = behavior in Given/When/Then, shared language (Gherkin), collaboration between QA/dev/BA. **ATDD** = acceptance criteria agreed *with the business before* development; the acceptance test is the definition of done. TDD = "build it right"; ATDD/BDD = "build the right thing."
- **Gherkin (fund transfer):**
`Given I am logged in with a checking balance of $500`
`When I transfer $100 to my savings account`
`Then my checking balance should be $400 and savings $100 higher`
`And I should see a transfer confirmation`
- **Step-def organization:** group by **page/domain** (not by feature file), keep steps thin → delegate to business-action/page classes, reuse parameterized steps, no logic in steps, share via hooks. Same layering as the framework in `01`.
- **Test data across envs:** externalize per-env (config/profiles, env-specific data files or a data API), never hard-code, use API/DB setup to seed state, tear down after; mask PII.
- **ROI:** worth it when **business stakeholders read/collaborate** on the scenarios and behavior is the spec; overhead is real (Gherkin + glue), so don't BDD a pure unit-test layer. Living documentation + shared understanding is the payoff.
- **Avoid:** conflating BDD with "just Cucumber," or saying all three are the same with different names.
A6. Communication Skills (≈3 min — scored: communication, continuous)¶
Interviewer says: "Why are you interested in Candescent specifically, and do you have any questions for me?"
What a strong answer hits (cue)
- Tie your interest to **banking software quality**: regulated, money-accurate, real-time, security-critical — exactly where rigorous SDET work matters and where your VAPT/security background is a differentiator. - Show you know Candescent = **digital banking for US banks & credit unions** (ex-NCR Voyix Digital Banking). - Ask 1–2 sharp questions: "How is the automation framework structured today — Selenium, Playwright, or both?" / "How does the team handle test data for money flows without touching prod data?" - Communication is scored across the **whole** interview: short clauses, no slow question-repeating, no rambling, structured ("first… second… finally").MOCK SET B — Alternate scenarios (fresh cold run)¶
Same section flow and timings as Set A. Use these the second time so you're adapting, not reciting. Keep one banking lens even on the generic prompts — Candescent is grading domain transfer.
B3. Framework Design — alternate prompts¶
Variant 1 (ride-share): "Design an automation framework for a ride-sharing app (rider books, driver accepts, live GPS tracking, fare calc, payment, rating). Layers, classes, components, one sample test."
Variant 2 (Netflix / streaming): "Design a framework for a video-streaming platform (browse, search, play, resume, profiles, multi-device incl. smart TV). Same depth."
What a strong answer hits (cue — same blueprint, re-skinned; see 01-framework-design.md)
- **Same layered blueprint and class list as A3** — the whole point of the kit's "asset A" is that one template re-skins in 5 minutes. Don't reinvent.
- **Ride-share specifics:** real-time GPS/location (async waits, websocket/streaming validation), fare calculation accuracy (money math again — surge, tax, tip), payment integration, driver+rider as two synchronized sessions, mobile-first (Appium), map/geolocation mocking.
- **Streaming specifics:** **multi-device matrix** (web/iOS/Android/smart-TV → device farms like BrowserStack/Sauce), playback/resume state, search relevance, CDN/region, concurrent-stream limits per plan, profiles/parental controls.
- **Always close the loop to banking instincts:** money accuracy (fare/billing), real-time state, security/PII, multi-environment — these transfer straight to Candescent. Say so.
B4. EP / BVA — alternate scenarios¶
Variant 1 (hospital registration): "A patient-registration form: Age field accepts 0–120, Name required (2–50 chars), valid email, phone 10 digits. EP + BVA."
Variant 2 (discount code): "A checkout discount-code field: valid codes are 6–10 alphanumeric chars, case-insensitive, one per order, some expire. EP + BVA + your test plan."
Variant 3 (integration chain): "A user registers on a form → it calls a backend API → on success the user gets a confirmation email and an SMS OTP. Write the test plan for this end-to-end flow. What do you test at each hop, and what do you own vs another team?"
What a strong answer hits (cue — full tables incl. the chain in 02-test-plan-ep-bva.md)
- **Hospital Age boundaries:** -1 (reject), 0 (accept), 120 (accept), 121 (reject); Name length 1/2/50/51; email valid/invalid format partitions; phone 9/10/11 digits, non-numeric.
- **Discount code:** length boundaries 5/6/10/11 chars; valid vs invalid vs expired vs already-used partitions; case-insensitivity; injection in the field; stacking blocked.
- **Integration chain (this is your strength — lean in, ties to RestAssured):**
- **Hop 1 UI form:** EP/BVA on each field, validation, submit.
- **Hop 2 API (RestAssured):** correct request built, **status codes** (200/201 vs 4xx/5xx), **response schema validation**, idempotency, auth, error paths.
- **Hop 3 email:** confirmation sent, to correct address, correct content/links — validate via mail API/inbox (e.g., Mailosaur) or DB flag, not by eyeballing.
- **Hop 4 SMS/OTP:** OTP delivered, correct length/expiry, single-use, retry/lockout.
- **Contracts & ownership:** define the contract between teams; *I* automate the end-to-end + API/email/SMS verification; another team may own the actual email/SMS gateway — I assert the **observable outcome**, mock the gateway where I can't reach it.
- **Negative/non-functional:** API down, email bounces, SMS delayed, OTP reuse, data consistency across hops.
B5 & B6. Methodologies + Communication¶
Reuse A5 and A6 — the methodology questions and the "questions for me" close don't change with the scenario set. Just deliver them fresh and unscripted.
RAPID-FIRE ROUND — 30 questions, one-line cues¶
Set a 10-minute timer. Answer each in one or two sentences, out loud, then uncover the cue. Goal: instant recall, no rambling. (Sources: 03 tools, 02 EP/BVA, 04 methodologies, 05 BFSI.)
| # | Question | Ideal one-line cue |
|---|---|---|
| Selenium | ||
| 1 | Implicit vs explicit vs fluent wait? | Implicit = global poll for presence; explicit = WebDriverWait for a specific condition; fluent = explicit + custom polling/ignored exceptions. |
| 2 | Why never Thread.sleep()? |
Fixed blind wait → flaky + slow; use explicit waits on conditions. |
| 3 | What is the Page Object Model? | Each page = a class; locators + actions encapsulated, tests call methods → maintainable, DRY. |
| 4 | How do you run cross-browser? | Parameterize DriverFactory, drive via Grid or a cloud (BrowserStack), TestNG params/profiles. |
| 5 | How to capture a screenshot on failure? | TestNG ITestListener.onTestFailure → TakesScreenshot, attach to report. |
| 6 | StaleElementReferenceException — cause/fix? | DOM re-rendered after lookup; re-find the element / wait for refreshed state. |
| 7 | Handle a dynamic dropdown? | Select for native <select>; else wait for options, click by visible text/JS. |
| 8 | Data-driven testing in TestNG? | @DataProvider feeding from JSON/Excel/DB. |
| RestAssured | ||
| 9 | Basic RestAssured structure? | given() (headers/auth/body) .when() (verb+endpoint) .then() (assert status/body). |
| 10 | How to validate a JSON schema? | body(matchesJsonSchemaInClasspath("x.json")). |
| 11 | Status code for created resource? | 201 Created (200 OK for generic success, 4xx client, 5xx server). |
| 12 | How to chain API calls? | Extract a value from response (.extract().path()), pass into the next request. |
| 13 | How to test an auth-protected endpoint? | Acquire token (OAuth/JWT), send in Authorization header; test valid/expired/missing. |
| 14 | Verify an email/SMS in automation? | Hit a mail/SMS API or DB flag (Mailosaur/Twilio test creds), assert content — don't eyeball. |
| 15 | Why API tests over UI tests? | Faster, more stable, test backend/ledger directly, great for setup & validation. |
| Playwright | ||
| 16 | Playwright's killer feature vs Selenium? | Built-in auto-waiting on actionability → far less flakiness; no manual waits. |
| 17 | What is a trace and why useful? | Recorded DOM/network/screenshots timeline → debug failures post-hoc. |
| 18 | How does Playwright do parallelism? | Workers + isolated browser contexts; projects for cross-browser. |
| 19 | When pick Playwright over Selenium? | New TS/JS project, modern SPA, want speed/auto-wait/trace/network mocking; Selenium when Java/Grid/legacy ecosystem mandated. |
| 20 | What's a browser context? | Isolated session (cookies/storage) — cheap parallel isolation, multi-user flows. |
| EP / BVA | ||
| 21 | EP in one line? | Partition inputs into equivalent classes; one test per class. |
| 22 | BVA in one line? | Test the edges of valid ranges (min, min±1, max, max±1) where bugs cluster. |
| 23 | Boundaries for a 0.01–10,000 amount? | 0.00, 0.01, 9,999.99, 10,000.00, 10,000.01. |
| 24 | EP + BVA together — why both? | EP cuts test count; BVA catches edge bugs EP would miss. |
| TDD / BDD / ATDD | ||
| 25 | TDD cycle? | Red → Green → Refactor. |
| 26 | Gherkin keywords? | Given / When / Then / And / But (Feature, Scenario, Background). |
| 27 | BDD vs ATDD? | BDD = behavior in shared language; ATDD = business-agreed acceptance criteria as done-definition. Overlapping, collaboration-driven. |
| 28 | When is BDD not worth it? | Pure unit/technical layers with no business reader — overhead without payoff. |
| BFSI | ||
| 29 | Why never use float/double for money? |
Rounding errors; use BigDecimal/exact decimal — money math must be precise. |
| 30 | One banking-specific test others forget? | Idempotency — a retried/double-submitted transfer must not double-debit. (Also: authZ isolation, audit trail, PII masking.) |
SELF-SCORING RUBRIC¶
Score each dimension 1–5 right after re-watching your recording. Total /30. Aim ≥ 24 before the real interview; any single dimension ≤ 2 is a priority fix.
| Dimension | 1 — Poor | 2 — Weak | 3 — Adequate | 4 — Strong | 5 — Excellent |
|---|---|---|---|---|---|
| Framework design | Jumps to "write a login test"; no architecture | Lists a few tools, no layers/hierarchy | Names layers + some classes when prompted | Layered diagram, named classes/components unprompted, handles env/cross-browser follow-ups | All of 4 + crisp class hierarchy, API+UI split, adapts blueprint to any domain in minutes |
| Test-design rigor (EP/BVA) | Only happy path, no method named | Names EP/BVA but vague partitions | Correct partitions + main boundaries | Full boundary set incl. format/precision, presented as a table | All of 4 + non-functional & negative cases, daily-limit/aggregation edge cases |
| Tool depth (Sel/RA/PW) | Surface buzzwords only | Knows one tool shallowly | Solid on one, basic on others | Deep on Selenium+RestAssured, sound Playwright, clear waits/POM/schema | All of 4 + confident Playwright-vs-Selenium decision narrative, API-chain mastery |
| Methodology clarity | Confuses the three | Defines but conflates BDD=Cucumber | Clear definitions | Definitions + Gherkin + step-def org + ROI | All of 4 + crisp "right thing vs right" framing, ROI nuance, data-across-envs |
| BFSI domain framing | Generic e-commerce answers throughout | Banking only when prompted | Mentions money/security when relevant | Brings money-math/idempotency/PII/audit unprompted | All of 4 + ties every section back to regulated-banking concerns naturally |
| Communication / English | Rambling, repeats questions slowly, no structure | Hesitant, some structure | Clear, mostly structured | Concise, signposted ("first… second…"), confident | All of 4 + engaging, paraphrases-not-repeats, asks sharp questions, zero filler |
Quick band read: 24–30 = interview-ready · 18–23 = one more focused pass on the low dims · < 18 = redo the matching sibling files before another mock.
Red flags to eliminate (auto-fail signals the interviewer watches for)¶
- Rambling — long answers with no landing point. Land each answer in a sentence.
- Slow, verbatim question-repeating — reads as stalling / AI-prompting. Paraphrase in one clause, then talk.
- No structure — stream of consciousness. Always "first, second, finally."
- Jumping to code before architecture in the design section.
- Ignoring non-functional / security — fatal for a banking employer. Always raise money-accuracy, authZ, PII, audit.
- Generic, non-banking answers — pure e-commerce framing when a banking lens was available.
- Eyes off-camera / reading — looks like off-screen help.
- Conflating BDD with "just Cucumber" or saying TDD/BDD/ATDD are the same thing.
NIGHT-BEFORE CHEAT SHEET (1 page)¶
One load-bearing point per topic. Read this aloud the morning of.
- Identity: "I design and own automation frameworks" — architect, not script-writer. Say it in the first 15 seconds.
- Framework (Section 3): Lead with layers → Tests → Page/API objects → Business actions → Core utils → Config/Env → Data → Reporting/CI. Then name classes:
BaseTest/BasePage,DriverFactory,ConfigReader,WaitUtils, page objects, service classes,TestDataProvider,ReportManager, listeners. Architecture before code. - Banking lens (everywhere): money =
BigDecimalnot float; idempotent transfers (no double-debit); real-time balances; authZ isolation (User A ≠ User B's data); PII masking + secrets in a vault; audit trail. Bring these unprompted. - EP/BVA (Section 4): Method first ("group into classes, test edges"). Amount boundaries memorized: 0.00 / 0.01 / 9,999.99 / 10,000.00 / 10,000.01. Include format/precision + negative + non-functional. Present as a table.
- Selenium: POM + explicit waits (never
Thread.sleep), cross-browser via Grid/cloud, fail-screenshot via listener. - RestAssured:
given/when/then, status codes (201 created), schema validation, chain by extracting a value into the next call. This is your API→email→SMS strength — lean in. - Playwright: killer feature = auto-wait (less flakiness); trace for debugging; contexts for parallel isolation. Decision: new TS/SPA → Playwright; Java/Grid/legacy mandate → Selenium.
- TDD/BDD/ATDD: TDD = build it right (red-green-refactor); ATDD/BDD = build the right thing (business-agreed Given/When/Then). Step-defs thin, grouped by domain, delegate to page/action classes. BDD ROI only when business reads the scenarios.
- The integration chain (B4-3): test each hop — UI form (EP/BVA) → API (status/schema/idempotency) → email (mail API) → SMS/OTP (single-use, expiry). Assert observable outcomes; mock gateways you don't own.
- Communication: short clauses, paraphrase don't repeat, "first/second/finally", end with 2 sharp questions about their framework and money-data handling.
- Mindset: show the room, video on, talk continuously in your own voice. You're an architect reasoning out loud — not a script reader.
For depth on any line above, open the matching file:
01-framework-design.md,02-test-plan-ep-bva.md,03-selenium-restassured-playwright.md,04-methodologies-tdd-bdd-atdd.md,05-bfsi-domain.md,06-behavioral-and-intro.md.