Interview Preparation That Actually Moves the Needle

You have an interview in two days. The temptation is to read fifty commonly asked questions and rehearse answers to all of them.

That is close to the least efficient thing you could do. Interviewers do not reject people for lacking a polished answer to “what is your greatest weakness.” They reject people who could not explain their own resume, could not describe the work in any specific terms, and had clearly not thought about the company for five minutes.

Preparation is triage. Here is the order that actually pays.

First: read the job description backwards

Print the JD, or paste it somewhere you can annotate it. For every requirement, write one line of your own evidence — a project, a metric, a situation. Where you have no evidence, write that too.

This produces three things in twenty minutes:

• A map of what they will ask about, because interviewers are usually working from the same document.
• Your talking points, pre-attached to their language rather than yours.
• An honest list of your gaps — so that when one comes up, you are not discovering it live.

Pay attention to what the JD lists first and what it repeats. That is usually the actual problem they are hiring to solve, and the rest is wishlist.

Second: know your own resume cold

This is the most common serious failure, and almost nobody prepares for it. Candidates write a resume in March, apply in July, and cannot explain a number they put on it themselves.

For every line on your resume, be able to answer:

• What exactly did you do, versus what your team did?
• How did you arrive at that number, and over what period?
• What was hard about it?
• What would you do differently?

If you wrote “improved page load time by 40%,” know what it was before, how it was measured, and which change contributed most. An interviewer who finds one number you cannot defend will discount the entire document, which is a rational response.

The corollary: never put anything on a resume you are not prepared to be cross-examined on. Anything you cannot defend should come off, not be risked.

Third: have five stories ready

Nearly every behavioural question is a request for one of a small number of stories. Prepare five, from real experience:

1. Something you built or delivered that you are genuinely proud of.
2. Something that went wrong through your own error, and what you did about it.
3. A disagreement with a colleague or manager and how it resolved.
4. A time you worked under real constraint — no time, no budget, no information — and what you cut.
5. Something you learned quickly because you had to.

Between them these cover ownership, accountability, conflict, judgement under pressure and learning speed, which is most of what a behavioural round is assessing. Cover the situation, what you specifically did, and how it turned out — the standard STAR structure is fine as a checklist, but do not let it flatten your delivery into a recitation. Interviewers can hear a memorised template, and it costs you credibility.

Two things matter more than structure. Say “I” when describing your own contribution — candidates who say “we” throughout leave the interviewer unable to tell what they actually did. And keep each story to two minutes. Time yourself once out loud; most people are astonished at how long they run, and a five-minute answer to a simple question is itself a signal about how you will behave in a meeting.

For the failure story, pick a real one with a real cost. A story where the failure was “I worked too hard” or the fault was someone else's answers a different question than the one asked, and interviewers notice the dodge.

Fourth: twenty minutes on the company

You do not need to become an analyst. You need to know:

• What they sell and who pays for it. Surprisingly many candidates cannot say this.
• Who their main competitors are, and one way this company is positioned differently.
• One recent, specific thing — a funding round, a product launch, a market they entered, something the founder said in an interview.
• Roughly how large they are and how long they have existed.

Then use the product if you can. Fifteen minutes in their app gives you an observation nobody else in the pipeline will have, and “I noticed onboarding asks for a PAN before showing me anything — is that a regulatory constraint?” is worth more than any amount of researched enthusiasm.

Fifth: prepare questions that are not filler

“Do you have any questions for us?” is a real part of the assessment, and “What is the company culture like?” scores nothing because it has no wrong answer.

Better, because the answers actually inform your decision:

• What does success in this role look like at six months? What would have to be true?
• Why is the position open — is it new, or is someone leaving?
• What is the hardest part of this job that would not be obvious from the description?
• How is work prioritised when two stakeholders disagree?
• Who would I work with most closely, and what do they need from me?
• What has the team shipped in the last quarter?

Ask three, and listen to the answers rather than waiting to ask the next one. Hesitation on “why is the role open” is one of the more useful pieces of information you will get all process.

Technical rounds: what is actually being assessed

Whether it is a coding round, a case study, a modelling test or a design exercise, the assessment is rarely just correctness. Three things are being watched:

• Do you clarify before you start? Candidates who begin solving before establishing constraints are the ones who build the wrong thing at work. Ask about scale, edge cases, the inputs you can assume.
• Do you narrate your reasoning? Silence for eight minutes is unassessable. Say what you are considering and why you rejected the alternative — an interviewer will often nudge you if they can hear where you are, and cannot if they cannot.
• How do you behave when stuck? This is the highest signal moment in the whole interview. Getting stuck is normal; freezing, bluffing or getting defensive is what damages you.

Practise out loud, against a clock, at least once before the day. Solving problems silently in your head is a different skill from solving them while talking, and it is the second one you are being tested on.

The mechanics of a video interview

These are unglamorous and they cost people offers anyway.

• Test the link, camera and microphone the day before, in the actual application they will use.
• Have a mobile hotspot ready as a fallback, and know how to switch. If your connection fails, say so immediately and reconnect on the phone — do not spend four minutes hoping.
• Camera at eye level, light in front of you rather than behind. A window behind you turns you into a silhouette.
• Set your display name to your actual name, not Redmi Note 12.
• Use a headset. Laptop microphones pick up the room and echo the interviewer back at themselves.
• Look at the camera when making a point, not at your own thumbnail.
• Keep your resume and JD notes open, but out of your eyeline enough that you are not visibly reading.
• Allow the small delay. Video calls swallow the start of sentences, so pause briefly before answering rather than talking over the last word of the question.

Two questions people handle badly

“What are your salary expectations?” Deflect once and ask for their budgeted band; if pressed, give a researched range and say the word fixed. The full mechanics are in our guide to negotiating salary in India, but the short version is: do not name a precise number before you understand the role.

“Why are you leaving your current job?” Answer forwards, not backwards. “I want to work on X, and this role has more of it” is safe and true for most people. Criticising your current employer — even fairly, even accurately — reads as a preview of how you will describe them, and interviewers are consistent about penalising it.

How to say you do not know

You will be asked something you cannot answer. There is a version of this that helps you:

I haven't worked with Kafka directly, so I don't want to guess. What I do know is the problem it solves, and I've used SQS for something similar on the notifications pipeline — is the concern here ordering, or throughput?

Admit the gap, show the nearest real thing you have, stay engaged. Every interviewer has hired people with gaps. Almost none will hire someone who bluffed and got caught, because the inference is about honesty rather than knowledge.

Afterwards

Send a short note within a day, to whoever you have an address for. Three sentences: thanks, one specific thing from the conversation, and that you remain interested. It is not obsequious and it is remembered, largely because so few candidates do it.

Ask about the timeline before you leave the call — “what are the next steps, and when should I expect to hear?” — so that following up is a scheduled action rather than an anxious guess. If the stated date passes, one polite follow-up is appropriate. Then move on and keep interviewing elsewhere, because pipelines go quiet for reasons that have nothing to do with you.

If you are rejected, ask once what would have made the difference. Most will not reply. The ones who do will tell you something more accurate than anything you could have inferred, and it is frequently a small mechanical habit that takes one afternoon to fix.