What is the piece of work you are proudest of, and why that one?

The choice is most of the answer

This looks like an invitation to talk about your best project. It functions as a values question, because what you select tells the interviewer what you think good work is before you have justified anything. Two candidates with equivalent experience choose differently: one picks the most technically ambitious thing they ever built, the other picks the unglamorous change that removed a recurring source of customer pain. Neither is wrong, but they read very differently, and the second reads better in nearly every hiring context because it suggests the candidate's satisfaction is tied to whether the work mattered.

So decide deliberately rather than reaching for the largest item on your CV. Ask what the work changed for someone other than you. If the honest answer is that it was beautiful, hard and used by almost nobody, you can still tell that story, but you need the "why" to be about something other than difficulty, or the interviewer will file you as a candidate who optimises for interesting problems and will need managing away from them.

Making the "why" do some work

The weak version of this answer explains scale: the project was big, it took a year, it involved five teams. Scale is context, not pride. The strong version names a standard you hold, and the standard is what the interviewer takes away.

A "why" that says nothing	A "why" that reveals a standard
"It was the biggest system I have built."	"It was the first thing I built that the on-call rota stopped mentioning. Nobody has been paged for it in two years."
"It used an interesting architecture."	"We deleted more code than we added, and the next two features took days instead of weeks because of it."
"It was very high-profile internally."	"The support team went from about thirty tickets a week on that flow to a handful, and I only found out because their lead mentioned it."
"I learned a huge amount."	"I was wrong about the design twice and changed it in the open, and the team started doing the same thing."

Each right-hand entry hands the interviewer a durable impression: this person cares about operability, or about leaving the codebase easier to change, or about the people downstream of their work. That impression outlasts the details of the project, which the interviewer will forget by the afternoon.

Impact stated in someone else's language

Pride is easier to believe when the benefit is expressed in terms the business used at the time. Latency numbers, throughput figures and test coverage are inputs; the interviewer will accept them, but they will accept them more readily when you connect them to something a non-engineer noticed. A page that stopped timing out during the seasonal peak. A finance close that stopped requiring a weekend. A cohort of customers who stopped abandoning a form.

Be careful about how you attribute the number. If a revenue figure moved during a quarter when three things shipped, say so and describe what you could and could not isolate. Interviewers do not expect clean causality from real work, and a candidate who volunteers the confound is far more persuasive than one who claims the whole movement. If you genuinely do not have a number, describe the before and after concretely instead. "The team stopped doing the Monday morning manual reconciliation" is evidence even without a figure attached.

Where a proud story turns into an overclaim

The characteristic collapse of this answer is not exaggeration of the outcome. It is the slow expansion of your own part in it. Because you are proud of the work, you narrate the whole of it, and "we" becomes ambiguous somewhere around the third minute. Then a follow-up asks who else worked on it and what they did, and the specific, confident description of the architecture you gave earlier turns out to have been someone else's design that you implemented well.

The way to be safe here is not modesty, it is precision. State the shape of the team early — how many people, over what period, who led it — then say what you owned inside that. Being the person who owned two components of a five-person, nine-month programme is a perfectly good answer at most levels, and it is a far better answer than an inflated one that fails a single question. If you led the whole thing, saying who did the difficult parts under you costs you nothing and makes you sound like someone who has led before.

There is a smaller trap in the follow-up about what you would change. Candidates hear it as an attack on work they have just praised and defend it. It is not an attack, it is a check that your standards have moved since. Naming the compromise you would not repeat, or the thing you now know was overbuilt, is the answer that closes this question well.

When the proudest work is not the most impressive

It is entirely legitimate to pick something small. Mentoring one person through a difficult year, killing a project that should not have continued, or writing the document that stopped a bad decision are all defensible choices, and at senior levels they can be the strongest available. The requirement is the same in every case: name what changed for other people, and say why that is the thing you value. What does not survive is a choice you cannot justify beyond the fact that it was the last big thing you did.

The interviewer is reading your selection criteria, not your project. Pick the work whose "why" tells them what you will hold to standards here.