What most candidates say vs what wins

Opening a coding problem · Coding Round

✗ What most candidates say: "Okay let me think... [long silence] ... I think I can use a hashmap...

✓ What you should say: "Before I start coding, can I ask a couple of clarifying questions? [Ask: input size? duplicates? sorted? return type?] Okay. Let me think through this out loud. The brute force would be O(n²) — nested loops. But I think we can optimise using a HashMap to get O(n). Here is my approach: [explain in 3 sentences]. Does that make sense before I code it up?"

Why it works: Clarifying first = no wasted code. Stating brute force then optimising = shows problem-solving process. Asking approval before coding = collaborative.

When you are stuck · Coding Round

✗ What most candidates say: "Umm... I'm not sure... [silence for 2 minutes]"

✓ What you should say: "I'm going to think out loud here. I know the brute force is [X]. The constraint that's blocking me is [Y]. One pattern I've seen for this type is [Z] — let me see if that applies. [pause] Actually, I think if I [insight]... yes that works. Let me code that."

Why it works: Never go silent for more than 30 seconds. Interviewers want to see HOW you think when stuck. Showing you know patterns = trained engineer.

When the interviewer gives a hint · Coding Round

✗ What most candidates say: "Oh yeah! [takes hint and codes without acknowledging]"

✓ What you should say: "That's a great hint, thank you. So if I understand correctly, you're suggesting [restate hint in your own words]. That would change my approach from [old] to [new] because [reason]. Let me update my solution."

Why it works: Restating hint = shows you understood. Explaining WHY you're changing = shows technical reasoning. Interviewers note candidates who ignore hints.

After coding — before testing · Coding Round

✗ What most candidates say: "I think this is correct."

✓ What you should say: "Let me trace through the example before I declare it done. Input: [trace step by step]. Output: [expected]. Good, that matches. Now edge cases: empty input would hit this null check here. Single element: this would return [X], which is correct. One thing I could improve: this is O(n) time and O(n) space — if space was a constraint, I could [optimise]."

Why it works: Self-testing = shows engineering discipline. Edge cases = senior behaviour. Mentioning optimisation = shows depth without being asked.

Opening a system design problem · System Design

✗ What most candidates say: "Okay so I'll design [X]... here are the components..."

✓ What you should say: "Before I start designing, let me clarify scope. Are we building this for 1000 users or 1 million? Read-heavy or write-heavy? Any specific latency requirements? What are the core features in scope — let me list them and you tell me if I'm missing anything. [List features] Okay. Let me start with a high-level architecture and then we can deep-dive into the components that interest you most."

Why it works: Requirements gathering = the first thing real architects do. Asking read/write ratio = shows you think in system tradeoffs. Offering to deep-dive = interviewer-led conversation.

When asked about a technology you don't know · Any Round

✗ What most candidates say: "I don't know that technology."

✓ What you should say: "I haven't worked with [tech] directly, but from what I know, it's used for [category/purpose]. The closest I've used is [similar tech you know] where I [experience]. If I were to pick up [tech], I'd start with [approach]. Can you tell me more about how it's used in this context so I can reason about it?"

Why it works: Never just say 'I don't know'. Showing adjacent knowledge = intellectual breadth. Asking for context = turns weakness into curiosity.

Behavioural — starting a STAR story · Behavioural

✗ What most candidates say: "So at my previous job I was working on testing and we had this issue with the regression suite..."

✓ What you should say: "Sure. Let me give you a specific example. At WizzyBox — that's Testsigma's parent company — I was responsible for the automation test framework for their enterprise web platform, which serves 500+ clients. The situation was [S]. My task was [T]. Here's what I specifically did: [A — use 'I' not 'we']. The outcome was [R — number if possible]. The reason I chose this example is it shows [relevant quality]."

Why it works: Context first = interviewer understands the scale. 'I' not 'we' = ownership. Numbers in result = credibility. Explaining WHY you chose the example = meta-awareness.

Asking smart questions at end of interview · Final / HM Round

✗ What most candidates say: "No, I think I'm good. Thank you."

✓ What you should say: "Yes, I have a few. First — what does success look like for this role in the first 90 days? Second — what's the biggest technical challenge the team is working through right now? Third — how would you describe the engineering culture here — is it more shipping fast or more polish and quality?" [NEVER ask about salary in technical rounds]

Why it works: Asking about success = shows ambition. Technical challenge question = shows you want to contribute. Culture question = shows maturity. Interviewers remember candidates who ask good questions.

Salary negotiation — receiving an offer · HR / Offer Round

✗ What most candidates say: "Oh great, thank you! That sounds good."

✓ What you should say: "Thank you so much — I'm genuinely excited about this opportunity. I'd love 24 hours to review the full details before formally responding. Can I get back to you by [tomorrow]?" [Then next day:] "I've thought it through carefully. Given my background in [specific skill], the AWS certification I recently completed, and the market data I've looked at, I was hoping we could reach [target, 15-20% higher]. Is there any flexibility on the base or equity component?"

Why it works: Never accept on the spot. Counter EVERY offer — 90% of the time there's flexibility. Specific justification (cert, skills, data) = credible counter, not just asking for more.

When you realise your solution has a bug mid-explanation · Coding Round

✗ What most candidates say: "Oh wait... actually that's wrong... [panic]"

✓ What you should say: "Actually, let me pause — I see a bug in my logic here. [Point to it calmly.] If the input is [edge case], my current code would [wrong behaviour] instead of [correct]. Let me fix that: [fix]. This changes the time complexity from [X] to [Y] because [reason]. Good catch on my part — better now than in production."

Why it works: Catching your own bug = senior behaviour. Calm acknowledgement = composure. Explaining the fix clearly = real debugging skill. The last line = light self-awareness that interviewers love.