Behavioural round: failure, conflict and saying I, not we

Questions about a mistake and a disagreement are easy to prepare for and hard to fake. A well prepared story can sound good. Then the interviewer asks, "What did you do yourself?" and there is nothing behind it.

Three kinds of answer lose the interviewer's trust. The first says "we" and never says what you did. The second is a fake failure or a blame. The third is a disagreement where you won and the other person was wrong. Tradeoff's behavioural mock marks similar patterns in its report, with your exact words: for example a vague "we", blaming others, and taking the team's credit.

A strong answer owns a real mistake in the first sentence, says what changed afterwards, and treats the other person fairly.

Think of two mechanics. One says, "The part was bad." The other says, "I forgot to tighten this bolt. I fixed it, and now I check every bolt twice." You trust the second one with your car. The interviewer thinks the same about you.

The three answers that hurt

1. The vague "we". "We moved the jobs to a queue." The interviewer asks, "What did you do?" and you cannot say.
2. The fake failure or the blame. A fake failure is a strength made to look like a weakness: "My weakness is that I work too hard." Blame puts the fault on someone else: "The other team gave us the API late." Both show that you do not learn.
3. The disagreement where you won. "I showed my data and they finally understood." This shows you did not listen.

A real failure story

Choose a real mistake with a real cost. Six steps:

1. What happened. The plain fact, in one or two sentences.
2. What you missed. The step you skipped or the thing you did not know.
3. The effect, with a number. How long, how many users, how much money.
4. The first hour. What you did at once: stop the damage, tell people, check what was lost.
5. What you changed so it cannot repeat. A check, a test or a runbook. A runbook is a short list of steps to follow when something goes wrong.
6. What you do now. One habit that is different today.

Four rules for the story:

• Own it in the first sentence. "I ran a change without checking the backup."
• No excuses. Do not start with how busy you were.
• No blame. Tell only your part.
• Right size. Not a disaster that ended a job, and not a trivial slip that nobody noticed.

A conflict story

Tell a disagreement as a way to reach a good decision, not as a fight. The steps:

1. Understand the other view. Say their point in your own words until they agree.
2. Say your shared goal. "We both want the page to be fast."
3. Test with data or a small experiment. Test, do not argue.
4. Escalate only when needed. To escalate is to ask a manager to decide. Do it to decide, not to win.
5. Disagree and commit. Disagree and commit means that once the decision is made, you support it fully, even if you argued for something else.
6. Keep the relationship. Say how you worked together afterwards.
7. Give the result for both sides. What did the team get, and what did the other person get?

If the decision is unsafe or against the law, do not commit. Escalate.

"I" and "we"

Say "we" for the team and the situation. Say "I" for your decisions and your work. The interviewer scores what they hear you did.

When you were not the lead, say so and say your part: "Our lead made the plan. My part was the tests and the release." This is not weak. A clear small part is trusted more than a claim of the whole.

Expect the follow-up "What exactly did you do?" Answer with verbs: "I read, I compared, I wrote, I decided."

Real examples, not "I would"

"I usually talk to the person first" is a habit, not a story. The interviewer will say, "Tell me about one time." Ask yourself: "When did this last happen?" Then tell that time: "Last quarter, when my teammate and I disagreed about the cache, I asked him to explain his view first."

Questions that look like traps

Three questions look dangerous: "Why are you leaving?", "Tell me about a bad manager" and "What is your weakness?" Use one pattern: one true sentence about the past, without blame, then what you want next.

• Why are you leaving? "I learned a lot on the billing team in two years. Now I want systems with more traffic, and my team does not have that work."
• A bad manager. "We worked in different styles. I learned to send a short update every Friday. I look for a team that shares decisions early."
• A weakness. "I used to stay quiet in design meetings when I was not sure. Now I write my questions before the meeting and ask the first one."

Privacy

Do not use the real names of colleagues. Say "a teammate" or "my manager". Keep confidential numbers as ratios or ranges: "about 5 percent of orders". Tradeoff's mock asks for the same.

How the interviewer asks more, and how to practise

The interviewer can ask more about any part of your story. Practise like this:

1. Tell the story to a friend, or to the behavioural mock.
2. Ask the friend to question you: What was your job? What exactly did you do? What happened in the end? Who else worked on it? What would you do differently?
3. Write down each question you could not answer, and add the answers to your fact sheet.
4. Tell the story again two days later.

All people and companies are made up, and all numbers are Assumptions. We build two stories from facts.

Story 1: a failure

Arjun is an SDE-1 at a startup. On a Friday evening he ran a script on the live database (the one real users use) to add a column to the orders table. The team checklist said to check last night's backup. He skipped it, and he did not try the script on a copy first. The script locked the table, so the order-history screen could not read it. The screen failed for 30 minutes, and about 1,800 users saw an error. He stopped the script and told his lead within 5 minutes, but the database needed 25 more minutes to undo the change. The row count was 120,000 before and after.

Told badly: "It was a small mistake. The checklist was long, and nobody reminded me to check the backup. The system is old, so it locks easily. Anyway, it came back, and I learned to be more careful."

This blames the checklist, the team and the system. It has no number.

Told well:

"I ran a change on the live database without checking the backup, and the order-history screen was down for 30 minutes. About 1,800 users saw an error. I had skipped the backup step of our checklist, and I had not tried the script on a copy. I stopped the script and told my lead within 5 minutes, but the database needed 25 more minutes to undo it. I checked the row counts before and after, 120,000 both times, so no data was lost. Within the hour I sent the team a note on what happened. Then I added two steps to the checklist: a backup that was restored in the last 7 days, and a first run on a copy. I wrote the undo steps in a runbook. Now I write the undo step before any change on live data."

It follows the six steps. This answers the predict box: the weak first sentence blames the process, and so it breaks the rule "own it in the first sentence". A better one is: "I ran a change on the live database without checking the backup."

Story 2: a conflict

Meera is an SDE-2. Her lead wanted to add a cache (a fast store of copies of answers) to the product list page, because it felt slow. The average response time was 120 ms. The slowest 1 percent of requests (called p99 in lesson 4: 99 of 100 requests are as fast as this or faster) took about 900 ms. Meera wanted to measure first. She asked for one day. She replayed one day of requests through a test cache. The hit rate (lesson 57, the share of requests that the cache answers) was 85 percent, and a hit took about 5 ms. A miss took about 240 ms on average. The average after the cache: 0.85 x 5 + 0.15 x 240 = 4.25 + 36 = 40 ms (rounded), down from 120 ms. The average hides the slow requests, so p99 did not change: it stayed near 900 ms. The slowest requests were rare and different each time. The cache never held them, so all of them were inside the 15 percent that missed. They came from a query that read the whole table. The team added an index, which lets the database find rows without reading the whole table (lesson 36). Then p99 fell from 900 ms to 150 ms. Meera and her lead agreed to add the index first and to keep the cache for later.

Told badly: "I knew a cache was wrong. I showed my data, and finally my lead understood."

Told well: "My lead wanted a cache, because the page felt slow. We both wanted a fast page. I asked him to explain what he saw, and I said it back to him. I asked for one day to measure first. I replayed one day of requests through a test cache. The average fell from 120 ms to 40 ms, but the slowest 1 percent stayed near 900 ms. I found a query that read the whole table and added an index. My lead and I agreed to do the index first and keep the cache for later, and I supported that plan fully. The slowest 1 percent fell to 150 ms. My lead got a faster page without a new cache to run, and I got a decision based on data. He now asks for a measurement before we choose a fix."

It covers the steps: understand, shared goal, test, commit, keep the relationship and the result for both sides.

• Telling a real failure solves the doubt about honesty. It costs a moment of looking weaker. I would pick a smaller mistake if my first one ended in a job loss.
• Disagree and commit solves an argument that never ends, and it keeps the relationship. It costs that you sometimes carry out a decision you think is wrong. I would change it when the decision is unsafe or against the law. Then I escalate.

"A failure story should end like a success story." The interviewer wants to hear what you changed so that the mistake cannot repeat.

"Saying 'we' is modest and shows I am a team player." It hides your work, and the interviewer cannot score what they cannot hear. Say "we" for the team and "I" for your own work.

"In a conflict story I must show that I was right." The question is about how you handle a disagreement. If you were wrong, say so: that is a good story about learning. If you were right, say how you listened first.

1. List the six steps of a failure story, in order.
2. A page gets 10,000 requests in one hour. (a) How many are in the slowest 1 percent? (b) With an 85 percent hit rate, how many requests miss the cache? (c) If all of the slowest 1 percent are among the misses, what share of the misses are they?
3. A candidate answers "Why are you leaving?" with: "My manager does not understand engineering, and the team is slow." Rewrite the answer in two sentences.