Software & Tech Interview Questions

STAR stands for situation, task, action, and result. It exists because unstructured answers drift: candidates describe context for two minutes, never say what they personally did, and stop before the outcome. The structure is a checklist, not a script.

Situation sets the scene in one or two sentences. Task states what you specifically were responsible for. Action is the bulk of the answer and should be told in the first person singular, because the interviewer is assessing you rather than your team. Result closes the loop with what changed, plus what you would do differently.

Here is a worked example for the question about leading a project under tight deadlines. Situation: the team had committed to shipping a customer facing billing change before the end of the quarter, and two of the four engineers were pulled onto an incident in the second week. Task: I was the technical lead and owned the delivery date. Action: I re-scoped the release into a minimum version that covered the two highest volume billing paths and deferred the rest, wrote the cut down plan up in a single page, walked the account team through what customers would and would not see, and paired with the remaining engineer daily so review never became the bottleneck. Result: the reduced scope shipped in the quarter, the deferred work landed early the following month, and the plan document became the template the team used for later releases. What I would change: I waited nearly a week before proposing the cut, and that week was the most expensive part.

Notice what that answer does. It names a concrete decision, cutting scope, rather than describing effort. It is told in the first person. It has a result that is verifiable inside the company. And it volunteers a weakness, which pre-empts the obvious follow up question and reads as self-awareness rather than as an admission.

A common failure mode is inflating the result. If you cannot defend a number when asked how it was measured, do not use it. A precise qualitative outcome, such as the release shipping in the quarter with the deferred work landing the following month, is stronger than an impressive percentage you would have to invent.

Reading your notes and saying your answer are different skills, and interviews only test the second one. Almost everyone who prepares silently discovers in the room that the story they thought was two minutes long is actually six, and that the result they were clear about on paper never gets said.

Say each answer aloud, standing up, at normal speaking pace, and time it. The first attempt is usually rambling. The second is shorter. By the third you will have found the version that holds together without notes. That is the one to keep.

Record yourself at least once. It is unpleasant and it works: you hear the filler words, the sentences that restart halfway through, and the moments you narrate context instead of decisions. Ten minutes of listening back tends to be worth an hour of silent re-reading.

When you can get one, practise with another person. A live listener asks the follow up questions you did not plan for, which is the part you cannot rehearse alone. A mock interview with an unfamiliar interviewer also reproduces the mild adrenaline of the real thing, and adrenaline is exactly what makes prepared answers fall apart.

Keep the practice short and frequent. Twenty minutes a day for a week beats one long session the night before, because spacing is what makes recall reliable under pressure.

Company research has two purposes: it lets you tailor your answers, and it gives you questions that demonstrate you are serious. An hour of focused reading is usually enough.

Start with the product. Use it if you can, and form an opinion. Being able to say which part you found confusing, and what you would look at first, is worth more than any amount of recited company history.

Then read the engineering material. Public engineering blogs, conference talks, and open source repositories tell you what the team actually cares about, what scale they work at, and which technical problems are live. A question drawn from a specific post lands very differently from a generic one about culture.

Next, understand the levelling structure. Knowing how a company defines the level you are interviewing for tells you what scope of story to choose and keeps the compensation conversation grounded. The level and salary guides on this site exist for exactly this: read the ladder for your target company before you talk about titles or pay.

Finally, look at the interview process itself. Reported loops tell you how many rounds to expect, which ones are coding versus design, and whether there is a values or leadership principles round. Walking in knowing the format removes a whole category of avoidable surprise.

Write down three questions of your own before the call. Good ones are specific and answerable: how the team decides what to build next, what happened after a particular launch, how the on-call rotation works in practice. Save compensation and process questions for the recruiter rather than the engineers.