Most interview advice stops at "be confident" and "research the company". This is the layer underneath: what to prepare, how to hold an answer together while you are speaking it, and what to do in the days either side. None of it is complicated, and all of it takes practice.

Before the interview

Research past the "About us" page

Reading the company website is table stakes. The interviewer assumes you did it. What actually gives you something to say is everything around it:

News from the last three months: funding, layoffs, a new market
Recent leadership moves or team growth on professional networks
Your interviewer's own background, if you know who they are
The company's engineering blog, case studies or changelog
The product itself, used for twenty minutes if you can get access

The point is not to recite it, but to be able to say something specific: "I saw you moved into the healthcare vertical this year, and I have worked with medical device customers. Where is the compliance work sitting at the moment?" That is impossible to fake, and it changes the register of the conversation.

Prepare stories, not answers

Preparing an answer per question does not scale, because you cannot predict the questions. Preparing stories does, because most behavioural questions ask for the same handful of experiences from different angles. Build a bank of eight to ten real episodes covering:

Something you achieved that you can describe concretely
Something that failed, and what you did next
A conflict inside a team, and how it ended
A project you led or pushed through
A genuinely hard technical or commercial problem
A large change you had to adapt to
A time you brought someone else up to speed

Write each one down once, properly. After that you are adapting material rather than inventing it under pressure, which is the difference between an answer that lands and one you assemble as you speak.

Use STAR, and weight it towards the action

Situation, Task, Action, Result is well known. What people get wrong is the proportions. Situation and task are context, so give only what makes the rest make sense. The action is what the interviewer is actually assessing, so it should be the bulk of the answer, and it should be what you did, not what the team did. The result closes it.

The common failure is a long preamble, a vague middle where "we" did some things, and a result with no mechanism attached. The interviewer ends up knowing about a project and nothing about you.

Be concrete about your own numbers

Specifics are checkable, which is why they carry weight. Where you have them, give them: team size, budget, time saved, latency, volume, things shipped.

Weak: "I improved the system's performance."

Stronger: "I brought median API response time down from about 500ms to 300ms. It mattered because the checkout page called that endpoint three times before it could render."

If you do not have a number, do not invent one. Give the mechanism instead: what was broken, what you changed, how you knew it worked.

Prepare questions that reveal how you think

The questions you ask at the end are part of the assessment. "What is the culture like?" tells the interviewer nothing about you. These do:

"What does success in this role look like ninety days in?"
"What is the hardest problem the team is sitting on right now?"
"What would make you confident, six months from now, that you hired the right person?"
"What is the thing about working here that people only find out once they have joined?"

They are useful to you as well: the answers tell you whether the role is the one the advert described.

Practise out loud

Thinking an answer through is not the same skill as saying it. The gap only appears when you speak, and it is widest on the first two or three attempts, which you do not want to spend in a real interview.

Record yourself and watch it back. It is uncomfortable and it is the fastest feedback available. Listen for filler words, for how long the answer actually ran (almost always longer than it felt), and for whether your main point survived to the end.

If you want something more structured than a voice memo, that is what Beacon does: you paste your CV and a real job advert, it generates questions for that role and seniority, and it marks each answer out of ten against criteria it shows you rather than hides. Next to the mark it puts two model answers, an acceptable one and an excellent one, beside your own. You can type or speak, and spoken answers are transcribed and marked identically. Sessions are kept, so you can answer the same question again next week and compare.

During the interview

The opening minutes set the register

The logistics are the easiest part of an interview to get right, and the only part you cannot redo.

In person: arrive early, wait in the lobby, and present yourself about five minutes before. Be decent to whoever is on reception, because they are sometimes asked. Stand up when the interviewer arrives.

Remote: join a couple of minutes early, test audio and camera beforehand rather than in the first thirty seconds, sit facing a window or a lamp rather than with the light behind you, and look at the camera when you make a point rather than at the face on your screen.

Bracket your answers

Open with a direct answer in one sentence, tell the story, then close by tying it back. It looks mechanical written down and does not sound mechanical out loud.

Open: "Yes, I have led cross functional teams, most recently three of them at once."
Middle: the story, with the detail in the action.
Close: "So the coordination between engineering and product in this role is familiar territory."

Without the brackets, a good story can leave the interviewer unsure whether their question was answered, and they do not always ask again.

Pause before the hard ones

If a question is broad, ask which way they want it taken, the technical angle or the people one. If it is hard, take two or three seconds before you start. Silence costs nothing, buys a better answer and reads as composure. "Let me think about which example fits best" is a perfectly acceptable thing to say out loud. The instinct to fill silence instantly is what produces rambling, and rambling costs more than a pause. Nerves make everyone speak too fast, so slow down on purpose, and work from bullet points rather than a script, which is audible on a call and visible on camera.

"Tell me about yourself"

This is a framing question, not a biography request, and it is the one part of the interview you fully control. Present, past, future, in two to three minutes.

Present: what you do now and what you own. Past: how you got here, keeping only what is relevant to this role. Future: why this role specifically, and not just any role. The trap is chronology, because starting at university and working forwards spends your best minutes on your least relevant experience.

Answer the weakness question honestly

"I work too hard" is heard as evasion, and evasion is worse than the weakness. Name something real and relatively contained, say what made you notice it, say what you changed, and say where you are now. Ongoing is fine. "Solved" is not believable. For example: delegation, noticed while running three projects at once, addressed by writing the process down and handing two pieces of it to junior colleagues, still something you have to be deliberate about.

Handle salary without flinching

If it comes up early, it is reasonable to defer once: "I would rather work out whether this is the right fit first, and I am confident we can find a sensible number if it is." If they press, give a range rather than a single figure, based on what you have found for similar roles in that market, and talk about the whole package rather than base alone. Declining twice reads as awkward rather than strategic.

Difficult questions: brief, honest, forward

Employment gaps, short tenures, being let go. Be honest, because most of it is verifiable, and be brief, because over explaining signals that you think it is worse than it is. Then move on. "I took six months out for a family health situation. I used part of it to finish two certifications in the area I wanted to move into. I have been fully available since March." That is the whole answer.

When you do not know something

Say so, then do three more things: connect it to the nearest thing you have done, describe how you would get up to speed, and ask how their team uses it. That beats a bluff, which tends to unravel in the next question.

Technical and behavioural questions

Narrate your thinking

Even when you know the answer immediately, say the reasoning out loud. Restate the problem in your own words, ask what is fixed and what is flexible, outline the approach before you start writing, talk while you work, test it against an example, then say what you traded away and what would change at ten times the scale.

Interviewers assess how you think as much as whether you arrive, and a sound approach with a wrong answer often scores better than a correct answer produced in silence.

Show the other people in the story

Behavioural answers are partly about whether you are pleasant to work with, and that comes through in whether other people appear in your stories as people rather than obstacles.

Weak: "They disagreed with my approach, but I convinced them I was right."

Stronger: "Their concern came from a migration that had gone badly two years earlier. I took the parts of that objection that applied to us, and we ended up with a rollout plan neither of us would have written alone."

Be enthusiastic about the work, not the logo

Plenty of candidates are visibly excited about the company and vague about the job. It is a recognisable pattern and it does not read well.

Generic: "I would love to work somewhere like this."

Better: "The part that interests me is infrastructure at scale. Taking milliseconds off a path that runs billions of times a day is the kind of problem I am still thinking about on the walk home."

Raise the obvious objection yourself

If there is a visible gap, an industry switch, a short stint, a technology you have never touched, name it before they have to. You get to frame it, and self awareness reads as confidence.

"I am coming from outside fintech, so let me say how it transfers. The regulatory work I did in healthcare was the same shape: the constraint arrives before the design, not after it."

After the interview

Write the thank you note within a day

Not generic gratitude. Thank them for the time, reference one specific thing from the conversation, restate your interest with a reason attached, and add something small if you have it: a thought about the problem they described, or an answer you did not give fully at the time. Four or five sentences is plenty, and a long one looks anxious. If you promised anything, a portfolio, references, a writing sample, send it the same day.

One follow up, then let it sit

If their stated timeline passes, wait a couple of business days and send three lines: you are following up on the interview of whichever date, you remain interested, is there an update. Then stop. They are either interested or they are not, and a longer email does not change which.

Debrief yourself while it is fresh

Within an hour, write down the questions you were asked, the ones you fumbled, and what you would do differently. Do it especially for the interviews that went badly.

This is the part few people do, and it is the part that compounds. Anders Ericsson's work on deliberate practice draws the distinction: repetition on its own does not improve performance, repetition against specific feedback does. A few interviews with a debrief after each will teach you more than a long run of interviews without one.

The mistakes that actually cost people offers

Speaking badly about a previous employer. Justified or not, the interviewer hears how you will talk about them.
Exaggerating. It surfaces in the reference check, or worse, in your first month.
Being late and silent about it. Late happens. Not messaging ahead is the part that disqualifies.
Looking at your phone. There is no version of this that goes unnoticed.

Practice is the whole trick

Reading this changes nothing on its own. Interviewing is a performance skill, so the first rehearsal is always the worst one, and the only question is whether you spend it on an opportunity that matters.

Pick three things and rehearse them out loud this week: your story bank, your opening two minutes, and the one question you dread. If you want them marked, Beacon is free during the beta, with no card and no limits.