The 10 habits that cost me interview signal
Across 50+ interview rounds I tracked ten verbal and structural habits that hid what I knew. Four died, two improved, and four were still there in August. The debrief loop, the drills, and what worked.
Contents
A hiring manager asks about the system you are proudest of. You built it. You know every component, every trade-off and every number. You start with “So, there are like two parts to it,” walk through the data pipeline, then the model, then a detour about a deployment issue, and the result you are proudest of arrives in the last sentence. Or it doesn’t arrive at all, because the interviewer has already moved on to the next question.
That was me in March. My early debriefs kept finding the same thing: the content of my answers was strong, and the way I delivered them hid it. The interviewer writing notes against a rubric could only score what I made visible, and I was making the best parts hard to find.
This post describes the system I used to find and fix those habits: a debrief after every round, reconstructed from memory in a conversation with Claude, a running table of ten habits, and drills built from my own answers. It is part 3 of the 35 companies, 8 offers series, which covers a search from February to August 2026 across more than 50 interview rounds.
The short version of what changed:
- Approval-seeking “right?” at the end of statements: frequent in March → gone by mid-April
- Intro order: oldest work first → most recent result first, fixed by April
- Coaching scope: content and delivery → delivery only, once content was confirmed strong across rounds
- Swapping metrics between two systems I built: first caught in April → still happening in an August team-matching call
- Google loop: the round that rewards delivery most, Googleyness and Leadership, came back Strong Hire
Background: why good content gets lost#
Interviews are lossy. You have 45 minutes, the interviewer has a rubric and a notepad, and everything you know has to pass through a few minutes of speech per question. Google’s guidance on structured interviewing describes interviewers scoring answers against predefined rubrics. Three things about that setup made my habits expensive.
The interviewer scores what they write down. A result mentioned once, at the end of a long answer, may not make it into the notes. A result stated in the first sentence almost always does.
Confidence reads as competence. In a set of experiments, Price and Stone (2004) found that people preferred an overconfident advisor over a well-calibrated one and judged the confident one as more knowledgeable. Interviewers are trained to resist this, but they are still people. Hedging on numbers from my own systems cost me credibility I had earned.
Time is the binding constraint. Every minute spent on setup is a minute not spent on the follow-up questions where senior candidates separate themselves.
None of these habits came from not knowing the material. Every one of them was a gap between knowing something and getting credit for it.
The debrief loop#
The core of the system was a debrief after every round, done the same day while the interview was fresh. I reconstructed the conversation from memory with Claude: the questions in order, what I said, where I hesitated, where the interviewer pushed back or moved on. Then we scored it in the same three buckets every time: content (was it correct and deep enough), communication (how it came across), and signals (what a rubric would record).
graph LR
A["Interview round"] --> B["Same-day debrief<br/>from memory"]
B --> C["Score: content,<br/>communication, signals"]
C --> D[("Habit table")]
D --> E["One targeted drill"]
E --> F["Next round"]
F --> B
D --> G["Loaded into every<br/>prep session"]
class A,F amber
class B,C violet
class D blue
class E,G greenThree design decisions made this loop work rather than produce a pile of notes.
One shared habit table. Findings did not live in each debrief. They went into a single profile document with each habit, its fix, and its status, and that document was loaded at the start of every prep session and mock. A habit found in a March intro call was checked for in a July mock without me having to remember it.
One targeted fix per session. The early debriefs produced long lists. Long lists produce no change, because you cannot hold ten corrections in your head while answering a hard question. Each session picked one habit and drilled it.
Delivery only, once content was proven. After several rounds, the pattern was clear: no interviewer had flagged my technical depth, and every borderline moment was about delivery. I told Claude to stop coaching content entirely and score only structure and delivery. That decision made every session about the actual problem.
The ten habits#
The table below is the habit list as it stood by summer, with the fix I used for each and where it ended up by August. The sections after it explain them in three families.
| Habit | Fix | Status by August |
|---|---|---|
| Conclusion last | State the answer in the first sentence | Improved, not gone |
| “So” and “yeah, so” openers | Pause instead | Still present |
| Losing the thread in multi-part answers | Restate each part before answering it | Fixed |
| Intro starts with oldest work | Lead with the most recent result | Fixed |
| “Right?” at the end of statements | Replace with silence | Fixed |
| Hedging my own numbers | Say verified numbers flatly | Still present under pressure |
| Volunteering weaknesses | Redirect to an adjacent strength | Improved |
| Metrics vanish under pressure | Say the number; it is evidence | Still present |
| Swapping metrics between two systems | One-page metric bank, drilled cold | Still present |
| Cutting into questions | Wait for the full sentence | Still on the list |
Structure: where the answer goes#
Conclusion last. My natural order was context, then approach, then detail, then result. Interviewers need the reverse. The military writing convention of BLUF, bottom line up front, which Kabir Sehgal describes in Harvard Business Review, was the most useful single fix. The first sentence of every answer states the answer; everything after it is support.
Openers that delay the answer. “So,” “so basically,” “there are like two parts to it,” and meta-descriptions of what I was about to say all did the same thing: they spent the interviewer’s attention before the content arrived. The fix was a pause. Silence for one second reads as thinking; “so” reads as stalling.
Losing the thread. On three-part questions I would answer part one at length and drift. The fix was mechanical: say “for the second part” out loud before starting it. This was one of the habits that fully died.
Oldest-first intros. My first introductions walked through my career chronologically, which put my least relevant work in the first minute. I rebuilt the intro to open with the most recent result and its number, then work backwards only as far as useful.
Confidence: how sure I sound#
Hedging my own numbers. I caught myself saying “as far as I remember” about metrics from systems I had designed and shipped. Those numbers were verified; the hedge was a nervous habit. The fix was to treat a resume number like a fact in a design doc: say it once, flatly, with its definition.
Volunteering weaknesses. In one round I said “let’s forget towers, I’m rusty” about a two-tower retrieval model I had built in production. In another I told the interviewer, unprompted, that I had not done high-level design in a while, and the round went downhill from there. Nobody had asked. The rule I adopted: address a weakness only if asked, and only alongside the nearest thing I am strong at.
“Right?” I ended statements with “right?” as a check that the interviewer was following. In casual conversation it is harmless; in an interview it reads as seeking approval. This was the fastest habit to die, gone within about three weeks once I started listening for it.
Filler words. “Yeah yeah yeah” while the interviewer was still talking was the hardest to self-report, because memory keeps the content of a conversation better than its tics. It reduced, but I would not claim it disappeared.
Accuracy: what I actually said#
Metrics vanishing under pressure. When a follow-up got hard, my answers lost their numbers and turned into qualitative descriptions. A number is committee evidence; “it improved quite a lot” is not.
Swapping metrics between two systems. This one cost the most. I had built two different ranking systems at Cars24: a user-level personalization model that lifted Click Recall@50 by 150%, and a separate re-ranker with its own lifts in buyer intent and conversion. Under pressure I attributed one system’s number to the other. It happened several times in April, I drilled it in June and July, and it happened again in a team-matching conversation in August. The fix that finally worked best was a one-page metric bank with every number, its exact definition and its system, drilled cold before each round.
Cutting into questions. I would start answering before the interviewer finished, and sometimes answered a different question from the one being asked. The rule is simple and I still have to remind myself of it: wait for the full sentence.
Two structural habits#
Two more patterns were not verbal but showed up the same way, and both were found by the same loop.
Algorithm before schema. In design rounds I would name a model or an algorithm before defining the entities, identifiers and data I was working with. It showed up in both design rounds of one loop in March and again in a system design round in May. The fix was a template: entities and IDs first, then data flow, then models. I wrote it into the top of every design document I used for practice.
Vocabulary slips. Saying “pre-train” when I meant “fine-tune,” or mixing up encoder and decoder architectures under pressure, made correct answers sound wrong. The fix was a short list of term pairs I reviewed the morning of any round with LLM content.
The drills#
Debriefs found habits; drills changed them. The most effective drills used my own answers rather than generic ones.
graph TD
A["Habit table"] --> B["Rewrite drill:<br/>my answer, BLUF form"]
A --> C["Filler drill:<br/>strip my openers"]
A --> D["Intro drill:<br/>reorder my career"]
A --> E["Trap drill:<br/>weakness prompts"]
A --> F["Metric bank:<br/>cold recall"]
B --> G["Mock interview<br/>scored on habits"]
C --> G
D --> G
E --> G
F --> G
class A blue
class B,C,D,E,F violet
class G amberRewrite drill. Claude showed me one of my own reconstructed answers, I rewrote it with the conclusion first, and then compared it with a reference version. Doing this on my own answers rather than textbook examples was the difference: I recognized my patterns immediately.
Trap drill. Questions designed to tempt me into volunteering a weakness (“how comfortable are you with statistics?”), practiced until the redirect was automatic.
Intro drill. My career as cards, reordered until the first sixty seconds carried the strongest and most recent result.
Mock scoring. Every spoken mock was scored on two yes-or-no axes, conclusion first and collaborative framing, plus a running filler count, with a target of zero by the end of the second week.
Claude also built a small interactive trainer as a React widget, with four sections (rewrite, filler, intro and trap), that I used in the first weeks. It was useful early; by June the habit table plus mocks did the same job with less overhead.
For the Google loop I added four framing targets on top of the habits: make my own contribution explicit inside team work, project every design to Google scale out loud, state a brute-force solution before optimizing, and always commit after “it depends.”
Results#
Four habits died: “right?” and oldest-first intros within the first few weeks, then losing the thread and an “also, also, also” connector I had not even listed. Two improved without disappearing: conclusion-last structure and volunteering weaknesses. Four survived all the way to August, especially under pressure: hedging, vanishing metrics, “yeah, so” openers, and the metric swap between two systems.
The round where delivery mattered most was Google’s Googleyness and Leadership round, which scores how you communicate as much as what you did. It came back Strong Hire. The ML domain round, where hedging still showed up on a couple of hard questions, also came back Strong Hire, which is a useful reminder that a habit costs signal at the margin rather than failing you outright.
The metric swap is the honest counterweight. I drilled it more than any other habit and still made it in August. Some habits are triggered by pressure and only partly yield to practice; for those, the reliable fix is a written reference you check right before the conversation.
What I’d do differently#
Write the metric bank before the first interview. It took me until June to build a one-page sheet of every number, its definition and its system. Built in March, it would have prevented most of the swaps.
Narrow the coaching scope earlier. I spent the first few weeks debriefing content that was already fine. Switching to delivery-only after the first handful of rounds would have saved time.
Practice aloud from the start. Written drills fixed structure. Verbal habits like fillers and openers only change when you speak, and I started spoken mocks later than I should have.
Accept that memory undercounts tics. A debrief from memory is excellent for content and structure and weak for verbal habits, because you do not remember your own filler words. I treated the filler counts from mocks as the more reliable measure.
Conclusion#
The habits that cost me signal were not knowledge gaps. They were the distance between knowing an answer and putting it where an interviewer would write it down. That distance can be measured after every round, and it shrinks fastest when you fix one habit at a time against a list that every practice session can see.
If your interviews feel worse than your knowledge, assume the problem is delivery until a debrief proves otherwise. Put the answer first, say your numbers like facts, and keep a list.
Part 3 of the 35 companies, 8 offers series. I join Google as a Software Engineer III, AI/ML, in October 2026.
Responses
Select any passage to highlight it or comment on that line. Highlights stay private, in this browser.