Discussing JS Projects Confidently

Use the situation, task, action and result structure, and keep the whole thing to about two minutes. The interviewer is not asking for a project summary, they are asking how you think.

// A small structure for describing a project in an interview.
const project = {
  name: "Order dashboard",
  problem: "Support staff could not see failed orders without exporting to a spreadsheet.",
  scale: "Around 4,000 orders a day and 30 daily users.",
  stack: ["TypeScript", "React", "Node.js", "PostgreSQL"],
  constraints: ["No budget for a new service", "Legacy API could not be changed"],
};

const highlight = (item) => `${item.label}: ${item.value}`;

const talkingPoints = [
  { label: "Problem", value: project.problem },
  { label: "Scale", value: project.scale },
  { label: "Stack", value: project.stack.join(", ") },
  { label: "Constraint that shaped it", value: project.constraints[0] },
];

for (const point of talkingPoints) {
  console.log(highlight(point));
}

The situation is the context and the constraint, and constraints are the most interesting part. A project built without a budget, against an API you could not change, to serve thirty users with a scale that did not justify a new service, all of that tells the interviewer what kind of decisions you had to make.

The task is what you were personally responsible for. Be specific here. Say that you owned the front end data layer, or that you rewrote the retry logic, rather than saying you worked on the project. The distinction between doing part of a project and owning it is exactly what the follow-up questions are probing.

The action is where you show your judgement. This is where the technical content goes, and it should be the longest part. What you considered, what you chose, and why you chose it over the alternatives. Mentioning one thing you rejected and why makes the decision sound considered rather than lucky.

The result is the outcome, and it should include a number if you have one. Latency before and after, the number of manual steps removed, the error rate before and after, or the size of the bundle you cut. If you have no number, use a concrete change instead, such as the number of files that no longer need a particular pattern.

Prepare two projects. One where you were the main contributor and one where you were part of a team, and be ready to say honestly which parts were yours. Interviewers can tell the difference between someone who owned a decision and someone who was nearby.

Behavioural questions are really questions about your judgement, and they are asked with a predictable shape. Almost all of them want to know what you did when something went wrong, so prepare for that specifically.

The classic form is a question about a conflict, a mistake or a deadline, and the follow-up questions are always the same. What was your role? What did you personally do? What would you do differently? How did you know it worked? A strong answer addresses all four without being prompted.

Three habits make the difference. First, take responsibility for the part that was yours. Saying that a colleague caused the problem sounds like you are looking for an excuse, and it is the fastest way to lose an interviewer's trust. Second, explain the reasoning, not just the action, because the reasoning is what you are being assessed on. Third, say what you would change, because an answer with no retrospective shows that you did not think about it afterwards.

For questions about your biggest mistake, the strongest structure is the one that starts with a real mistake, says what the impact was, explains what you changed afterwards, and describes the change as a system improvement rather than as being more careful. Changing a lint rule, adding a test, or writing a checklist prevents the whole team from making the same mistake, and that is a much stronger answer than promising to be more careful.

Two things to avoid. Do not give an answer in which you did nothing, because that implies you were not really involved. And do not give an answer that makes you sound like you never disagree with anyone, because technical interviews are also testing whether you would push back when the code is wrong.