Candescent SDET — Behavioral & Self-Introduction Prep¶

Round 1 prep for Section 2 (Introduction) and Section 6 (Communication Skills). Candidate: Rohan Dsouza, QA/SDET, Bengaluru. Target: SDET / Automation Engineer at Candescent (BFSI / digital-banking software, ex-NCR Voyix Digital Banking — online & mobile banking for US banks and credit unions). Everything below is truthful to Rohan's real background, with transferable framing toward banking. Do not claim banking employment you don't have.

0. How to use this file¶

Read Section 1 out loud 5–6 times until the self-intro is muscle memory (not memorised word-for-word — internalised).
Skim Section 2 before the call: it controls your Communication Skills score, which is graded separately.
Keep the STAR index (Section 6) open on paper, not a second screen.
Banking bridge: you have NOT worked at a bank. Your edge is API automation + security/VAPT + reliability discipline — all of which map directly onto what a digital-banking vendor cares about: correctness of money-moving APIs, security posture for regulated US financial institutions, and stable releases. Lead with the transfer, never fake the resume.

1. Self-Introduction Script¶

1a. Primary version (~75 seconds, speakable)¶

"Hi, thanks for having me. I'm Rohan Dsouza, an SDET based in Bengaluru with around five years in quality engineering and test automation. I currently work as an SDET-2 at Questt, an AI/ed-tech company, where I own a big part of our automation across API, UI and AI-evaluation layers.

My core stack is Java with Selenium, TestNG, RestAssured and Maven on the backend-and-UI side, and Playwright with TypeScript for modern UI work. A lot of my day-to-day is API automation — building frameworks that validate request/response contracts, JSON schemas and business logic, not just status codes.

Three things I'm proud of. First, I built a RestAssured API automation framework from scratch — around sixty-plus tests across fifteen service classes, with a clean service-and-helper layer and JSON-schema validation, so failures point straight to the broken contract. Second, I do hands-on security testing — VAPT using tools like OWASP ZAP, Burp, Nmap and Nikto — and I've reported real vulnerabilities with reproduction steps and severity. Third, I built an LLM-evaluation framework — an automated LLM-as-judge harness — that scores AI responses across several business domains, which pushed me deep into data-driven, criteria-based testing.

What draws me to Candescent specifically is that digital banking is where two of my strengths actually matter most — rigorous API testing and security. When the system under test is moving real money for US banks and credit unions, contract correctness and a hardened security posture aren't nice-to-haves, they're the product. That's the kind of quality bar I enjoy working to, and it's why I'm excited about this role."

Timing notes: This runs ~70–80s at a calm pace. If the interviewer looks like they want it shorter, cut the third achievement (LLM eval) and the banking-bridge becomes your close.

1b. Short variant (~30 seconds)¶

"I'm Rohan Dsouza, an SDET from Bengaluru with about five years in test automation, currently SDET-2 at Questt. My core stack is Java, Selenium, TestNG and RestAssured, plus Playwright with TypeScript. I specialise in API automation and I also do hands-on security testing — VAPT with tools like ZAP and Burp. I built our RestAssured API framework from scratch, around sixty tests with schema validation. What excites me about Candescent is that API correctness and security are exactly what matters in digital banking — that's the quality bar I like working to."

1c. Delivery cues for the intro¶

Open with name + role + years in the first sentence. Don't bury it.
"Five years" — say the number with confidence; don't hedge with "roughly maybe."
Name the stack as a tight list, then immediately say what you do with it ("not just status codes") so it doesn't sound like resume-reading.
The close is the most important sentence — it answers "why us" before they ask. Land it, then stop talking. Silence after a strong close is good.

2. Communication Skills — Delivery Guide (Section 6)¶

This section is scored on clear spoken English, articulation, and no repetition. You can be technically perfect and still lose points here, so treat it as its own deliverable.

Pace & clarity¶

Speak about 10–15% slower than feels natural to you. Nerves speed everyone up.
Put a full stop, not a comma, between ideas. A 1-second pause reads as "thoughtful," not "stuck."
One idea per sentence. If a sentence has three "and"s, it's two sentences.

Structure — signpost your answers¶

For any non-trivial question, front-load the shape: "There are two parts to that — first the framework design, then how I handled flakiness." Then deliver part one, part two. Interviewers grade clarity, and signposting makes you sound organised even under pressure.
For behavioral questions, say the structure implicitly via STAR: set the scene, state your task, walk the actions, land the result with a number. Never start an answer with the action and leave them guessing about context.

Avoid filler & repetition (the thing this section penalises)¶

Kill: "basically," "like," "you know," "actually," "so yeah," "at the end of the day."
When you need a beat, use silence, not "ummm." A clean pause beats a filled one every time.
Don't restate the same point in three different ways hoping one lands. Make it once, cleanly, and move on. Repetition is explicitly penalised.
If you don't know something, say so in one sentence and pivot to the closest thing you do know — don't circle the drain.

"Show the room" / no-second-screen etiquette¶

Have your camera on, well-lit, face clearly visible. If asked to show the room, do it without hesitation — pan the laptop once, calmly.
No second monitor, no phone, no notes on screen. The only thing in front of you should be a printed resume and a single page of STAR keywords on paper.
Why this matters / the AI-assistant trap: The JD flags interviewees who repeat the question back slowly and then read a polished answer — that pattern looks like someone feeding the question into an AI assistant and reading the output. So:
Do not repeat the question verbatim and slowly. If you need a second, paraphrase it briefly and naturally ("Sure — you're asking how I'd handle a flaky test, right?") and move on.
Do answer in your own conversational words, with small imperfections, real numbers from your projects, and the occasional "let me think about that for a second." Natural beats polished-and-robotic.
Look at the camera, not down-and-to-the-side (reading tell). Gesture a little. Think out loud briefly — humans reason, assistants recite.

Quick self-check during the call¶

Am I pausing between sentences? Am I making one point cleanly? Is my answer shaped (signposted)? Did I land a number? Did I stop when done?

3. STAR Stories (12)¶

Each is real, drawn from Rohan's actual projects. Format: Competency → Situation → Task → Action → Result → Banking bridge. Tell them in 60–90 seconds. Don't recite the labels — they're for your prep, not the answer.

STAR-1 — Building an automation framework from scratch¶

Competency: Framework design / ownership. - S: Questt's API testing was manual and ad-hoc — Postman collections that nobody trusted, no regression safety net. - T: I was asked to stand up a maintainable, automated API regression suite. - A: I designed a RestAssured framework (RestAssured 5.1.1, TestNG, Maven) with a layered architecture — a service layer wrapping each endpoint, a helper/utility layer for auth and payload building, and JSON-schema validators so a contract break fails loudly at the schema, not in some downstream assertion. I grew it to ~62 @Test methods across 15 classes, data-driven where it mattered. - R: Regression that used to be a manual half-day became a CI run; contract failures became pinpointable in seconds; the team actually trusted the suite. - Banking bridge: A digital-banking platform lives or dies on API contract correctness — schema-first validation is exactly how you stop a malformed balance or transfer response from reaching a bank's customers.

STAR-2 — Finding a critical / high-severity bug¶

Competency: Bug-hunting depth / risk awareness. - S: While building API tests, the happy path passed but I added negative and boundary cases around an endpoint that returned user-scoped data. - T: Verify the endpoint enforced proper authorization and input limits, not just returned 200s. - A: I crafted requests with manipulated IDs and missing/tampered tokens, and asserted on the body and access scope, not just the status code. I found the endpoint returned data it shouldn't have under certain malformed inputs. I documented exact repro steps, request/response payloads, and severity, and walked the dev through it. - R: It was fixed before release; we added a permanent regression test so it could never silently come back. - Banking bridge: In banking, an authorization gap on a data endpoint is a reportable security incident — this is the exact class of defect I'm trained to catch early.

STAR-3 — Reducing flaky tests / improving reliability¶

Competency: Reliability engineering. - S: My Playwright/TypeScript UI suite for questt.ai (Morrie) started failing intermittently in CI — green locally, red on the runner. - T: Get the suite to a trustworthy state; a flaky suite is worse than no suite because people start ignoring red. - A: I traced the flakiness to implicit timing assumptions and brittle locators. I replaced hard waits with Playwright's auto-waiting and web-first assertions, switched to role/text-based stable locators, isolated test state so tests didn't depend on each other, and added retry only as a diagnostic, not a crutch. - R: The suite went from "ignore the red" to a reliable signal the team gated merges on. - Banking bridge: A bank vendor ships on a schedule; a flaky pipeline erodes release confidence. Reliability discipline keeps the quality gate meaningful.

STAR-4 — A security vulnerability found via VAPT (strong for a bank)¶

Competency: Security testing / VAPT. - S: I was doing a VAPT pass on a web application using OWASP ZAP, Burp Suite, Nmap and Nikto. - T: Assess the app's security posture and produce an actionable report. - A: Through proxied scanning and manual verification I identified concrete issues — things like missing/weak security headers, an input-handling weakness, and exposure surfaces from the Nmap/Nikto recon. Crucially I manually confirmed each finding to weed out scanner false positives, then wrote each up with severity, impact, reproduction, and a remediation recommendation. - R: The team got a prioritised, false-positive-filtered report they could act on, not a raw scanner dump. - Banking bridge: US banks and credit unions are regulated; a vendor's security testing has to be rigorous and audit-ready. Manual confirmation and clear remediation write-ups are exactly that discipline.

STAR-5 — Tight deadline / release pressure¶

Competency: Prioritisation under pressure. - S: A release window tightened and there wasn't time to run the full regression manually and automate new coverage too. - T: Protect the release without pretending everything was tested. - A: I risk-ranked the test surface — money/auth/data-critical paths first — ran automated regression on the highest-risk areas, time-boxed manual exploratory testing on the new feature, and I was explicit with the PM about what was covered and what was accepted risk. - R: We shipped on time with a clear, written risk picture instead of false confidence; nothing critical escaped. - Banking bridge: Risk-based prioritisation and honest coverage reporting are how you ship a banking release responsibly — you never hide what wasn't tested.

STAR-6 — Disagreement with a developer / PM¶

Competency: Constructive conflict / influence. - S: A developer pushed back on a defect I raised, saying it was "expected behaviour"; the PM wanted to close it to keep velocity. - T: Resolve it on facts, not opinion or seniority. - A: Instead of arguing, I reproduced it with a minimal automated test and the exact payload, and mapped it back to the documented requirement / API contract. I framed it as "here's the expected vs actual, and here's the user impact" rather than "you're wrong." - R: Once it was reproducible and tied to the spec, the dev agreed it was a real bug and fixed it; the PM re-prioritised it. - Banking bridge: In banking you can't win arguments by volume — you win with reproducible evidence against the contract. That's how I keep conflict professional and data-driven.

STAR-7 — Mentoring / helping a teammate¶

Competency: Mentorship / knowledge-sharing. - S: A teammate newer to API automation was struggling to extend the RestAssured framework and was copy-pasting tests, creating duplication. - T: Get them productive without just doing it for them. - A: I walked them through the service/helper layering, pair-wrote one test with them end to end, and showed how the schema validators and helpers remove the copy-paste. I left them a short pattern to follow for the next endpoint. - R: They independently added several clean tests after that, and the duplication stopped. - Banking bridge: A vendor team scales only if framework knowledge spreads. I make the design teachable, not a black box only I can touch.

STAR-8 — Improving test execution time / CI¶

Competency: CI efficiency. - S: As the suites grew, feedback time crept up and slowed merges. - T: Cut the loop time without losing coverage. - A: I introduced parallel execution via TestNG, made tests independent/stateless so they could run in parallel safely, trimmed redundant setup with shared fixtures/helpers, and made sure CI surfaced failures clearly. I kept the heavier/slower checks in a separate stage from the fast smoke set. - R: Faster, more trustworthy feedback on each push; the fast smoke gate gave near-immediate signal. - Banking bridge: Fast, layered CI (smoke → full regression) is how a banking vendor keeps release cadence without sacrificing the safety net.

STAR-9 — Ambiguous requirement¶

Competency: Dealing with ambiguity. - S: On the LLM-evaluation work, "good answer" was subjective — there was no crisp pass/fail spec across the telecom/FMCG/retail domains. - T: Turn a fuzzy quality goal into something testable and repeatable. - A: I broke "quality" into explicit, scoreable criteria (relevance, correctness, completeness, tone), built an LLM-as-judge harness to score against those criteria, and validated the judge against a small human-labelled set so the scores were trustworthy. Where the spec was unclear I went back to stakeholders with concrete examples rather than guessing. - R: Subjective "is this good?" became a consistent, criteria-based, data-driven evaluation. - Banking bridge: Requirements are often under-specified; my instinct is to decompose into testable criteria and confirm with stakeholders rather than assume — which is exactly what regulated software needs.

STAR-10 — A failure / mistake and what I learned¶

Competency: Self-awareness / growth. - S: Early on I built UI tests that leaned on brittle locators and timing, and they passed in my environment but broke in CI — I'd over-trusted "works on my machine." - T: Own it and fix the root cause, not just the symptom. - A: I stopped patching with sleeps, learned Playwright's auto-waiting and web-first assertion model properly, rebuilt the affected tests on stable role/text locators, and made "no hard waits, environment-independent state" a personal rule. - R: The failures stopped, and I now design for CI-first from the start. - Banking bridge: Owning a mistake and fixing the systemic cause — not hiding it — is the integrity a regulated client needs in a QA partner.

STAR-11 — Advocating for quality / pushing back on shipping¶

Competency: Quality advocacy. - S: There was pressure to ship with a known defect on a data-returning path because "it's an edge case." - T: Make the risk visible and let it be a real decision, not an accidental one. - A: Rather than just saying "no," I quantified the risk — who hits this path, what the user sees, the data-exposure angle — and proposed a small targeted fix plus a regression test. I made shipping-with-it a conscious, documented choice, not a silent one. - R: The team chose to fix it; even if they hadn't, the decision would have been informed and on record. - Banking bridge: In banking you escalate risk clearly and let it be decided with eyes open — silent acceptance of a data/security edge case is unacceptable.

STAR-12 — Learning a new tool fast (Playwright / AI eval)¶

Competency: Fast learning / adaptability. - S: I was strongest in the Java/Selenium/RestAssured world, but a project (Morrie) needed Playwright with TypeScript, and separately the LLM-eval work needed a whole new evaluation mindset. - T: Get productive quickly without producing throwaway, low-quality automation. - A: I mapped my existing concepts (locators, waits, assertions, fixtures) onto Playwright's model, read the official docs over the vendor blogs, and built a small real suite immediately instead of just tutorials. For AI eval I leaned on my testing fundamentals — criteria, data, repeatability — to make sense of a new domain. - R: I shipped a working Playwright/TS suite and a functioning LLM-as-judge framework, both in production use. - Banking bridge: Banking stacks evolve; the ability to pick up a new tool and apply solid testing principles to it is what keeps a QA engineer valuable long-term.

4. HR / Behavioral Q&A (banking-aware)¶

"Why this role / why Candescent / why banking?"¶

"Two of my strongest areas — rigorous API testing and security/VAPT — are exactly what matters most in digital banking. When you're building online and mobile banking for US banks and credit unions, the system is moving real money and holding regulated data, so API contract correctness and a hardened security posture aren't optional, they're the product. Candescent, coming out of NCR Voyix's digital banking business, is a serious platform at real scale, and I want my testing strengths to matter that much. The domain raises the quality bar, and that's the kind of bar I enjoy working to."

"Why are you leaving Questt / your current company?"¶

"It's a forward-looking move, not running from anything — I've grown a lot at Questt and built things I'm proud of. I'm looking for a domain where the depth I have in API testing and security is core to the product rather than adjacent to it. Banking software is that domain, and Candescent gives me harder, more meaningful problems to solve at scale. I want my next few years to compound in a space where quality is genuinely mission-critical."

(Keep it positive. Never criticise Questt, pay, or a manager.)

"What are your strengths?"¶

"Three. API automation — I design layered, schema-validated frameworks where failures are pinpointable. Security testing — I do hands-on VAPT and write clean, false-positive-filtered reports. And reliability — I take flaky suites seriously and turn red noise into a trustworthy quality signal. Underneath all three is a habit of testing the contract and the risk, not just the happy path."

"What's your weakness?"¶

"My performance-testing depth is lighter than my API and security depth — I've used JMeter for basic load checks but I wouldn't call myself a performance specialist yet. I'm aware of it, and I've been deliberately leaning into it because in banking, performance under load matters. So it's a real gap, but one I'm actively closing rather than hiding."

(Pick a genuine, non-fatal gap + show action. Avoid the fake "I'm a perfectionist" answer.)

"Where do you see yourself in 5 years?"¶

"A senior SDET who owns the automation and quality strategy for a critical product area — the person the team trusts on framework architecture, API and security test design, and release confidence. In a banking context that means being deeply fluent in the domain's risk model, not just the tooling. I want to grow technically and as someone who raises the whole team's quality bar, not move away from hands-on engineering."

"How do you handle conflict?"¶

"With evidence, not volume. If a developer and I disagree on whether something's a bug, I reproduce it with a minimal automated test and tie it back to the spec or API contract, then frame it as expected-vs-actual and user impact rather than right-vs-wrong. Once it's reproducible and tied to the requirement, the conversation stops being an argument and becomes a decision. That keeps it professional and fast."

"Describe your ideal team."¶

"A team where quality is shared, not dumped on QA at the end — developers who care about testability, a culture where raising a defect or a risk is welcomed, and clear ownership so I can architect the automation properly. I work best where engineers and QA debate on evidence and ship with eyes open. I don't need a big team; I need an honest, quality-minded one."

Salary expectations — handling¶

Defer politely if it's early: "I'm flexible and more focused on the right role and fit at this stage. I'd be happy to discuss specifics once we both feel it's a match — and I'm sure your range for this level is fair."
If pushed for a number: give a researched range, anchored to the Bengaluru SDET-2 market, and say it's negotiable for the right role. Never lowball yourself or throw out a wild number.
Don't volunteer your exact current salary first if you can avoid it; talk expectations, not history.

Notice period — handling¶

State it factually and briefly: "My notice period is [X days/months]."
If long, soften with flexibility: "It's [X], though I'd do everything I can to transition cleanly and join as early as possible — I can start handover discussions early if needed."
Don't over-explain or sound apologetic.

5. Power phrases cheat-sheet¶

"Let me give you the shape of that first, then the detail." (signposting)
"There are two parts to this —" (structure)
"The key risk there was…" (risk framing — very banking)
"I tied it back to the API contract / the requirement." (evidence over opinion)
"I made it a conscious, documented decision rather than a silent one." (quality advocacy)
"Not just the status code — I asserted on the body and the access scope." (depth)
"I confirmed each finding manually to filter scanner false positives." (security maturity)
"Green locally isn't green — I design CI-first." (reliability)
"Let me think about that for a second." (natural, human, anti-AI-tell — use it)

Avoid: basically, like, you know, actually, so yeah, at the end of the day, repeating the question back slowly, restating the same point three ways.

6. Pre-interview checklist & STAR index¶

Environment & room¶

[ ] Camera on, face well-lit (light in front, not behind you).
[ ] Quiet room; phone on silent and out of reach.
[ ] No second monitor. Close all extra screens/tabs. Be ready to show the room calmly if asked.
[ ] Stable internet; test mic/camera 10 min early.
[ ] Glass of water within reach.
[ ] Printed resume copy + this one-page STAR index on paper (not on screen).
[ ] Headphones/earbuds so audio is clean.

Mindset¶

[ ] Answer in your own words — natural, with small pauses; do not repeat questions slowly or read polished text (reads as AI-assisted).
[ ] Lead every behavioral answer with context (S/T) before action.
[ ] Land a number in the result whenever you can.
[ ] Pause instead of "umm." Stop talking after a strong close.

STAR quick-index (keep on paper)¶

#	One-line trigger	Competency
1	RestAssured framework from scratch (62 tests/15 classes, schema layer)	Framework ownership
2	Auth-gap bug found via negative/boundary API tests	Critical bug / risk
3	Playwright flaky suite → trusted gate	Reliability
4	VAPT findings (ZAP/Burp/Nmap/Nikto), manually confirmed	Security
5	Tight release → risk-ranked + honest coverage	Pressure / prioritisation
6	"Expected behaviour" dispute → reproduced vs contract	Conflict
7	Mentored teammate on framework layering	Mentorship
8	Parallel TestNG + smoke/regression split	CI speed
9	LLM "good answer" → scoreable criteria	Ambiguity
10	Brittle waits/locators mistake → CI-first rule	Failure / growth
11	Pushed back on shipping data-path defect	Quality advocacy
12	Learned Playwright/TS + AI eval fast	Fast learning

Opening 30 seconds (memorise the start, improvise the rest)¶

"Hi, thanks for having me. I'm Rohan Dsouza, an SDET from Bengaluru with around five years in test automation, currently SDET-2 at Questt…"

Good luck — speak slowly, answer naturally, land your numbers, and let the close do the selling.