Ownership, Leadership and Ambiguity

Some questions in a behavioural interview are about how you behave when nobody is telling you what to do. These are the "ownership" questions.

Ownership is a simple idea. Think of a shared kitchen at a hostel. Some people wash only their own cup. Some notice the sink is blocked and fix it, even though it is nobody's job. The second kind of person is who a team wants.

This note covers six questions that come up again and again:

1. A time you took initiative
2. A project with unclear requirements
3. A tight deadline
4. A tough technical decision and the tradeoff
5. Mentoring someone
6. Influencing without authority

For each one you get what it tests, a sample answer, and how it changes for junior and senior engineers. At the end, there is a section on getting more mileage from one story.

A reminder before we start. Every story here is invented, so you can see the parts. Your answers must come from your own work. If you borrow a story, the first follow-up question will break it. Interviewers always ask "and then what happened?" or "why that and not something else?"

How the levels differ in general

Interviewers adjust their expectations by level, so it helps to know the rough rule.

A junior is not expected to have led a team. A senior who only tells stories about finishing a ticket will look junior. Match the size of your story to your level, or slightly above it.

1. A time you took initiative

What it tests

Did you act without being asked, and did you pick something worth acting on? Doing extra is not the same as doing something useful. Rewriting a working module because you were bored is not initiative.

Interviewers also check that you did not step on others. Taking initiative while still keeping your lead informed is the right balance.

A good sample answer

Say a team had a flaky test suite. This is how someone might tell it.

"On my team of six, our build failed about 1 in 5 times for no reason. People just clicked 'rerun' and went back to work. Each rerun cost about 12 minutes, and by my rough count the team lost close to 3 hours a day.

Nobody owned it. I mentioned it to my lead and asked if I could spend two afternoons a week on it for a month. She said yes, as long as my feature work was not late.

I started by counting. I pulled the last 200 builds and found that 70 percent of the failures came from just 4 tests. Two of them depended on the clock, one relied on test order, and one called a real external service.

I fixed those four over about two weeks. The failure rate dropped from 20 percent to about 3 percent. I also added a small page that shows which tests fail most often, so the next problem would be visible.

I told the team what I had done at our weekly meeting, in two minutes, so nobody was surprised. What I would do differently is ask the team first whether this was their biggest pain. It was, but I had guessed."

Notice the steps. A problem with a cost. Permission. Evidence before work. A number at the end. A reflection.

Junior vs senior

A junior story can be small: a README that was wrong, a script that saved a few minutes a day, a missing test. What counts is that you noticed, you told someone, and you finished it.

A senior story should show the problem was bigger than one person's pain, that you got others to care, and that it kept working after you moved on. "I built a dashboard" is junior. "I built it, got two other teams to use it, and it is still the way we track flaky tests a year later" is senior.

2. A project with unclear requirements

What it tests

Ambiguity means the instructions are vague. "Make onboarding better" is ambiguous. "Add a button that exports a CSV with these five columns" is not.

Interviewers want to see that you do not freeze, and also that you do not charge ahead and build the wrong thing. The sweet spot is a loop: ask, make a small guess, show it, correct, repeat.

A good sample answer

"My manager asked me to 'make the admin dashboard faster'. That was the whole request.

I did not know what faster meant, so I asked three questions. Which page? Faster for whom? And how will we know it is faster? She did not know either, so we looked at support tickets together. Most complaints were about the user list page, which took about 8 seconds to load for accounts with many users.

We agreed on a goal: that page under 2 seconds for an account with 10,000 users. That was something I could measure. I wrote the goal in the ticket so nobody would later argue about what we meant.

I then did the cheapest test first. I added timing logs and found 6 of the 8 seconds were one database query. I added an index, and the time dropped to 3 seconds. I showed that to my manager before going further, because she might want to stop there. She said to continue, so I added paging, which got it to 1.4 seconds.

The part I would keep is writing the goal down. Vague work turns into an argument later if there is no sentence to point at."

Junior vs senior

A junior is expected to ask questions early and not stay stuck. Saying "I spent 3 days confused and did not ask" is a warning sign, but saying "I asked after about half a day" is a good sign. Make clear that you ask smartly: you bring what you already tried.

A senior is expected to create the clarity, not only ask for it. They talk to users, write a short document (a one-page plan of what will and will not be built), get the right people to agree, and cut the project into steps so the unknowns come first. A good senior line is "I picked the riskiest unknown and tested that first".

3. A tight deadline

What it tests

This is about priorities and honesty. A deadline is like a train leaving at a fixed time. You cannot make the train wait, but you can decide what goes in the bag.

The interviewer is checking whether you cut scope sensibly (do less), whether you spoke up early, and whether you avoided shortcuts that hurt later. They also notice if your only strategy is working nights. Heroics once in a while is fine, but if it is your main plan, it signals poor planning.

A good sample answer

"Say we had 3 weeks to add a payment option for a launch that was tied to a marketing date. When I broke the work down, I counted about 5 weeks of work.

I told my lead that same day, not in week 3. I brought a list sorted by how much each thing mattered to a first customer. The must-haves were taking a payment, showing a receipt, and handling a failed payment. The nice-to-haves were saved cards, refunds in the admin tool, and an email template with the new logo.

We agreed to ship the must-haves in 3 weeks and the rest in the 2 weeks after. I also named the risk plainly: refunds would be done by hand for two weeks, by one person, using a database script.

We launched on the date. About 80 payments went through in the first week. Refunds by hand happened 4 times and took 10 minutes each. The saved cards and the proper refund screen came out two weeks later.

I would keep one habit from that: split the work by what a customer needs on day one, and say out loud what is being left out and who is covering it."

Junior vs senior

A junior should show they raised the problem early and did not hide it. A story about working extra hours is acceptable once, as long as you also show you asked for help or flagged the risk.

A senior should show negotiation: they changed the scope, not only the hours. They talk to the product manager, name what will not be built, and protect quality on the parts that cannot break, like money or user data.

4. A tough technical decision and the tradeoff

What it tests

A tradeoff means you give up something to get something else. A faster car costs more fuel. Interviewers want to see that you saw more than one option, that you knew what each cost, and that you can explain your choice in plain words.

Weak answers pick a side and say it was "the best practice". Strong answers say "we chose A, and here is what it cost us."

A good sample answer

"We had a service that sent about 50,000 emails a day, and a teammate and I had to decide how to store which emails had been sent. Option one was a new table in our existing database. Option two was a separate cache service, which would be quicker, but it was something new to run.

I wrote the two options in a half-page note with the costs. The table was slower, about 15 milliseconds per check against 2, but we had 50,000 checks a day, so slow was still nothing. The cache would give us speed we did not need, and one more thing to wake someone at night.

We chose the table. I knew the cost. If the volume grew by 100 times, we would have to rethink it. So I wrote that threshold into the note: 'if we pass 5 million a day, look again'.

A year later we were at about 300,000 a day and the table still worked fine. I am glad we did not build for a problem we did not have, though I would have been fine if the other option had won, because the note had the facts."

Junior vs senior

A junior may describe a choice inside a task, for example how to structure a function or which library to use. Fine. Show that you compared two options and checked with someone.

A senior should show a decision with real stakes: money, time, other teams, hard-to-undo changes. They also show how they reduced the risk of being wrong, with a small trial, a review with others, or a point at which they would revisit.

A strong closing line at any level: "If I did it again, I would..."

5. Mentoring someone

What it tests

Mentoring means helping someone else get better at their work. Think of teaching a friend to ride a bicycle: you hold the seat first, then you let go a little at a time. You do not ride it for them.

Interviewers use it to see whether you make the people around you better. At senior level this is often required. At junior level it can be as small as helping a new joiner.

A good sample answer

"A new graduate joined our team of five and was stuck on her first ticket for nearly a week. She was too shy to ask in public.

I set up a 30-minute pairing session twice a week. In the first one I did the typing and talked through how I read unfamiliar code. In the second she typed and I stayed quiet unless she asked. I also gave her a small list of 'good first bugs' that were safe to break.

After about 6 weeks, she was shipping small tickets alone, and in week 8 she fixed a bug that had been open for 3 months. I stopped the twice-a-week sessions at that point and moved to a weekly check-in.

The thing I learned was to ask 'what have you tried?' before giving an answer. When I just gave answers, she copied them. When I asked, she started to find them herself."

Junior vs senior

A junior can mentor an intern or a new joiner, or share something they just learned, like how the deploy process works. Keep it modest. Do not claim to have "led" people.

A senior should show care for more than one person, or for a team habit: a code review style, a document that new people use, a path for someone to move up. A good senior line is "I measured success by what they could do without me."

A trap here is making the story about how clever you are. The person you helped should be the hero.

6. Influencing without authority

What it tests

Authority is the power to tell people what to do. A manager has it. Most engineers do not. "Influencing without authority" means getting people to agree and act with only your arguments and your relationships.

Think of a neighbourhood meeting about a broken street light. Nobody can order anyone, but one person with a clear case and a quick plan can get it fixed.

A good sample answer

"I wanted our team and two others to stop writing our own retry code for calls to a payment partner. I counted 5 different copies, each with small bugs, and two of them caused duplicate charges once each in the last year.

I had no power over the other two teams. So I started small. I wrote a shared library of about 150 lines and tested it with my own team first. I did not ask anyone to adopt it. I showed the numbers: 5 copies, 2 incidents, about 40 hours of engineer time spent on them.

I went to the lead engineer of the second team one on one, before the group meeting, and asked what would make it painful for them. She said they needed a different timeout. I changed the library for that and she became the person who recommended it to the third team.

In 3 months, all three teams used it. The thing I would underline is that I did not win by arguing. I made it easy and let somebody else say yes first."

Junior vs senior

A junior can show this at small scale: getting a reviewer to agree to a change, or convincing the team to try a tool for two weeks. The skill on show is listening, not rank.

A senior should show an influence that crosses team lines, includes someone who disagreed, and involves a trade. For example, "I gave up my preferred design in exchange for their support on the migration."

One story, many questions

You do not need 15 stories. A good engineer has about 4 to 6 solid ones, and each can answer 3 or 4 questions. The facts stay the same. What changes is the angle, meaning which part you put at the front.

Take the story about the slow admin dashboard from earlier. Here is how it bends.

Same facts. Same numbers. A different first sentence and different emphasis.

A few cautions about reusing stories.

• Do not use the same story twice in the same interview. If you are asked two similar questions, have a second story ready.
• Keep the facts identical each time. If the number changes between answers, it sounds invented.
• Say the first sentence of the question back in your own words, so the story feels like it was picked for the question and not pulled from a drawer.
• Do not stretch a story to fit a question that it does not fit. If you were not really the mentor, do not call it mentoring.

Writing your story bank

Make a small table for yourself. Four to six rows is enough.

Fill the table with your own work. If a row has no number, go back to the pull request or ticket and find one. Even a rough number ("about 3 hours a week") makes the story feel real.

Two honest warnings

The first is about "we" and "I". Teams do the work, but in an interview you must show what you did. If every sentence says "we", the interviewer cannot tell your part. A good split is "we" for the context and "I" for your actions. "Our team had 5 copies of the code. I wrote the shared version."

The second is about exaggeration. It is tempting to round 2 weeks up to a month, or to say you led when you helped. Interviewers often check with a follow-up like "what was the hardest part of that?" and invented stories fall apart. A smaller true story with real details beats a big vague one.

Try it yourself

• Pick one real project from the last year and write four different opening sentences for it: one for initiative, one for ambiguity, one for a tradeoff, one for influence.
• For each of the six questions above, write down your level and what "one size up" would look like. Check that your story sits between the two.
• Find one number in each story, from a ticket, a dashboard, a pull request or your own memory. Write "about" in front if you are unsure.
• Ask a friend to ask "why that and not the other option?" after your tradeoff story. If you have no answer, your story is missing the second option.
• Record yourself telling the mentoring story. Count how many times you say "I" in the first minute. Then count how many times the other person did something.