Things to Avoid Saying in Tech Interviews (and What to Say Instead)
Interviewers do not have a banned phrases list, officially. But there is an unofficial one, and it is surprisingly stable across companies. Certain sentences reliably cost candidates points. Not because the underlying idea is bad, but because the phrasing signals something specific that the hiring committee has learned to distrust.
This guide is a field catalog of those phrases, why each one hurts, and what to say instead. Every entry is drawn from patterns that show up in engineering debrief notes across companies in 2026.
The goal is not to police your speech. It is to give you more accurate wording for the signals you actually want to send.
Table of Contents
- Why phrasing matters more than you think
- Ownership and credit phrases
- Competence and confidence phrases
- Disagreement and conflict phrases
- Technical vagueness phrases
- Motivation and fit phrases
- Closing and question phrases
- Phrases about AI and tooling
- Meta-phrases that undercut your whole answer
- Calibration checklist
- FAQ
- Conclusion
Why Phrasing Matters More Than You Think
The same idea expressed two different ways can score completely differently. This is not because interviewers are shallow. It is because phrasing is a high-bandwidth channel for underlying attitudes, and engineers reveal those attitudes whether they mean to or not.
Consider the difference between "I think we were able to fix the latency issue" and "I brought latency down from 1.8 seconds to 320 milliseconds." Same underlying accomplishment. The first sentence signals uncertainty about your own role, hedging, and vagueness. The second signals ownership, specificity, and numeracy. A hiring committee reads them as different people.
The phrases below are the high-frequency offenders. For each one, the pattern is: the phrase, what the interviewer actually hears, and a replacement sentence that preserves your intent while sending the right signal.
Ownership and Credit Phrases
"We just did X."
The word "just" is a minimizer. Engineers use it to sound humble. It reads as "this work was not important, even to me." If the work was not important to you, why should the interviewer care?
What the interviewer hears: you do not know how to claim credit, which means you probably do not know what you actually contributed.
Say instead: "X was one of the higher-leverage changes we shipped that quarter, because it unblocked Y." Or just describe what you did without the minimizer. "We migrated the service off the monolith in seven weeks."
"My team did X."
This is the credit-blur. You are trying to be modest, but the interviewer now has no idea what you specifically contributed, and they cannot score that.
What the interviewer hears: this person may have been a passenger.
Say instead: "Our team shipped X. My specific part was the migration tooling and the rollback plan." You can always credit the team without erasing yourself.
"I was lucky that..."
Luck erodes the story. If your contribution was load-bearing, do not attribute it to luck. If it was not load-bearing, do not tell the story.
What the interviewer hears: this person does not understand which of their moves mattered.
Say instead: "The reason that worked out was..." and name the specific mechanism. "The reason that worked out was that we had invested in CDC events six months earlier, so the migration was instrumented from day one." That is the same idea as "lucky," but now it is a story about foresight, not chance.
"I kind of led..."
The word "kind of" is the modal verb of weak ownership. If you led it, say you led it. If you did not lead it, say what you actually did instead.
What the interviewer hears: this person is hedging, probably because they did not actually lead it.
Say instead: "I was the primary driver of X, which meant writing the design doc, coordinating the three teams involved, and owning the rollout plan." Or, if you did not lead: "I was the implementation lead on X, working under our staff engineer who owned the strategy."
Competence and Confidence Phrases
"I'm not really an expert in X, but..."
This is a pre-apology, and it is poison. It installs doubt before you have said anything. The interviewer is now filtering everything that follows through "they said they are not an expert."
What the interviewer hears: this person thinks they will underperform, so they probably will.
Say instead: "My experience with X is mostly in the context of Y, so I'll answer from that angle." You have framed your experience honestly without announcing weakness. Or just answer the question.
"That's a good question."
This is a filler phrase that interviewers are specifically trained to notice. At best, it buys you two seconds of thinking time. At worst, it sounds rehearsed, sycophantic, or both.
What the interviewer hears: either a trained delay or flattery.
Say instead: nothing. Pause. Three seconds of silence to think reads as much more senior than "that's a good question." If you genuinely need the time, say "let me think for a second." That is honest and not flattery.
"I hope that makes sense."
This is the closing pre-apology, and it reads as uncertain about your own answer. If you think your answer did not make sense, give a better one. Do not ask permission to have given the one you gave.
What the interviewer hears: this person is asking me to confirm their own answer for them.
Say instead: "Does that answer what you were asking, or do you want me to go deeper on any part?" That is functionally similar, but it is specific and inviting, not self-undermining.
"I'm pretty sure..."
A hedge that halves your signal. If you are sure, be sure. If you are not sure, say "I'd want to verify X, but my understanding is Y" which is both more honest and more senior than "I'm pretty sure."
What the interviewer hears: this person is uncertain about their own claim, so I should be too.
Say instead: "My understanding is X. I haven't worked with the 2026 version, so I might be behind on that." Specific uncertainty beats vague hedging every time.
"Anyone could have done it."
This line is fatal. It sounds modest. It lands as "I am trying to opt out of this story."
What the interviewer hears: this person does not believe their own contribution was real.
Say instead: acknowledge the work and the team at once. "The technical part wasn't the hard part. The hard part was getting three teams with different incentives to agree on a rollout order, and that took five weeks of one-on-ones." You just claimed the part that mattered without claiming the parts that did not.
Disagreement and Conflict Phrases
"They were being difficult."
The moment you describe another person as "difficult" in an interview, the interviewer starts wondering what you are like to work with. The framing is about them; the signal is about you.
What the interviewer hears: this person struggles to empathize with people they disagree with.
Say instead: "We had different priorities. They were optimizing for reliability, I was optimizing for velocity, and both were legitimate." Now it is a technical disagreement, not a personality one.
"They didn't understand what I was trying to do."
A close relative of the above. You are implying you were right and they were wrong, which is fine if you have evidence, but the phrasing makes you sound unwilling to steelman the other side.
What the interviewer hears: this person assumes their own understanding is definitive.
Say instead: "I initially thought they didn't understand my proposal. After our second conversation, I realized they had context from a 2024 incident that made the naive version of my plan unsafe. I adjusted." Now you have a disagreement story with a real turn.
"I just pushed back hard."
"Pushed back" without a mechanism is a red flag. It sounds like you escalated volume rather than changing minds.
What the interviewer hears: this person escalates through force, not evidence.
Say instead: "I disagreed strongly, so I wrote a two-page doc laying out both positions with the data I had. That moved the conversation from opinion to evidence, and we reached a decision in about ten days." The mechanism (doc, data) is the actual signal.
"I got them to agree."
"Got them to agree" is persuasion framing. It suggests the other person was an obstacle you overcame, not a partner whose position shifted.
What the interviewer hears: this person thinks of collaboration as winning.
Say instead: "We ended up aligning on X after a couple of discussions where we both had to update our positions." Or be specific about your own update: "I came in wanting option A. After looking at the data they surfaced, I moved to option B."
Technical Vagueness Phrases
"We had a lot of traffic."
"A lot" is not a number. In a technical interview, any quantity-word that is not a number is a missed opportunity.
What the interviewer hears: this person either does not know the number or does not know it matters.
Say instead: "Peak was about 40,000 requests per second on the order service, and the tail of users doing flash-sale workflows pushed specific endpoints to 120,000." Numbers, even approximate ones, are signal.
"It was a pretty complex system."
"Complex" without specifics is vapor. If it was complex, name the axis of complexity. Data volume? Failure modes? Team coordination? State space? Latency budget?
What the interviewer hears: this person uses the word "complex" to avoid explaining the complexity.
Say instead: "The state machine had about twenty transitions, three of which could happen concurrently, and that was the hardest part of the design." Now the complexity is legible.
"We used the latest best practices."
This is a signal-free phrase. "Best practices" are whatever everyone does, which is often neither best nor best-suited for your problem.
What the interviewer hears: this person describes their decisions with buzzwords instead of reasoning.
Say instead: name the practice and why you chose it. "We used optimistic concurrency because our write contention was low and a pessimistic lock would have added 40ms of latency at our percentiles." Now the choice is defensible.
"I'm familiar with all the major frameworks."
"Familiar with" is a low bar that claims a high one. The interviewer will follow up with a specific question, and your "familiarity" will get tested at depth you did not prepare for.
What the interviewer hears: this person is overstating their exposure.
Say instead: "I've shipped production code in React and Vue. I've read a few articles on Svelte but haven't used it." Calibrated specificity is much more valuable than vague coverage.
Motivation and Fit Phrases
"I'm looking for something that's a good fit."
Content-free. The interviewer cannot calibrate whether their role is "a good fit" for a person who has not said what they are fitting to.
What the interviewer hears: this candidate has not thought about what they actually want.
Say instead: "I'm looking for a team that ships high-trust, high-autonomy work with a clear user. I work best when I can own an area for six-plus months, and I want a manager who prioritizes written design review." That tells the interviewer something real.
"I want to work on impactful projects."
Every candidate says this. It means nothing, because no one says "I want to work on projects without impact."
What the interviewer hears: this candidate could not name a specific interest, so they reached for the word everyone uses.
Say instead: name the domain, the scale, or the type of problem. "I want to work on infrastructure that gets used by other engineers, because I've noticed I'm most productive when my work unblocks people." Specific, and now they can evaluate fit.
"I'm open to anything."
Do not tell a hiring manager you are open to anything. It sounds like you do not know what you want, which is a yellow flag at senior levels and a red flag at staff levels.
What the interviewer hears: this person is looking for any job, not this one specifically.
Say instead: "I'm optimizing for two things, team quality and problem domain. This team scores well on both." Even if you are genuinely open, frame your openness as selection, not availability.
"Your company's mission really resonates with me."
This phrase is so common it has lost all meaning. Everyone says it, therefore no one says it.
What the interviewer hears: this person prepped by reading our About page.
Say instead: name one specific thing about the company or team that you would not have noticed from a surface read. "I noticed your infra team has been publishing postmortems publicly for the last two years. That signals a healthy culture around incidents, and it is part of why I'm talking to you." That lands.
Closing and Question Phrases
"I don't have any questions."
The single most damaging closing answer. Interviewers read it as disinterest or unpreparedness. You should have questions. Always.
What the interviewer hears: either this candidate does not care or did not prepare.
Say instead: have three questions ready, scaled to the role. For the hiring manager: "What does the first 90 days look like, and what failure mode worries you most?" For a peer: "What is the team disagreement that has been unresolved longest?" For an engineering leader: "Where is the biggest gap between how you want this engineering org to work and how it currently works?"
"Do you have any concerns about my background?"
This can work, but it often backfires. You are explicitly inviting the interviewer to name a doubt, which is a high-risk move.
What the interviewer hears: this candidate is fishing for reassurance or, worse, surfacing their own doubts.
Say instead, if you want the same information: "What does success look like in this role, and where do you think the first hard stretch would be for someone with my background?" Same information, different frame.
"When will I hear back?"
This is neutral, not bad, but it loses a small amount of signal because it is a logistics question not an engagement question.
Say instead, if you care about pace: "What are the next steps, and is there anything I can prepare for them?" That last clause signals that you are still leaning in.
Phrases About AI and Tooling
"I don't really use AI tools."
In 2026, this phrase is a flag. Not a disqualifier, but a flag. Most engineering orgs assume some fluency with AI tooling for IC work. Disclaiming use reads as either ideological or out of date.
What the interviewer hears: this person may not be current on the tooling the team uses daily.
Say instead: "I use AI tools selectively. Copilot for boilerplate, Claude for sketching design options. I don't trust either for anything that touches correctness without tests." You have named the tools, named the limits, and shown judgment.
"I just let the AI write it."
The opposite failure mode. This phrase sounds like abdication, which is a hard negative at senior levels.
What the interviewer hears: this person does not read their own code critically.
Say instead: "I use the AI as a first-draft tool and then rewrite for correctness and style. For anything non-trivial, I rewrite more than I keep." That describes real usage at a senior level.
"AI will probably replace this in a few years."
Offering unsolicited futurism about your own role is almost always a losing move. Either you believe it (in which case why are you here?) or you do not (in which case why did you say it?).
What the interviewer hears: this person is either performatively humble or signaling they might leave the field.
Say instead: do not say this. If asked, answer specifically about how you expect your own work to change. "I think the parts of my job that are greenfield coding will shift a lot, and the parts that are design, review, and debugging under pressure will become more valuable." That is a thoughtful answer, not a doom loop.
Meta-Phrases That Undercut Your Whole Answer
"This might not be exactly what you're asking..."
A pre-emptive invalidation of your own answer. The interviewer is now listening to an answer you have already told them is wrong.
What the interviewer hears: this candidate does not trust their own comprehension.
Say instead: "Let me check I understood the question. Are you asking about X or about Y?" If you need clarification, ask for it. If you have decided to answer a slight reframe, own the reframe: "I'll answer this with an example from adjacent work, because my direct experience is there."
"I'm going to ramble a bit..."
You just told the interviewer to discount everything you are about to say. Do not do this.
What the interviewer hears: this candidate cannot structure their thinking.
Say instead: start with structure. "I'll answer this in three parts: what we did, what I learned, and what I'd do differently." You have promised structure, which sets expectations, instead of apologizing for not having it.
"Sorry, that was a long answer."
Apologizing for your answer at the end is the worst possible capstone. It tells the interviewer "I wasted your time," which primes them to agree.
What the interviewer hears: this person doesn't edit their own thinking.
Say instead: end with a bookend. "To tie that back to the original question..." and restate your thesis in one sentence. If the answer was genuinely long, the bookend fixes it. The apology does not.
Calibration Checklist
Before any interview, check your baseline speech against these:
- Have I practiced answering without "just," "kind of," and "pretty sure"?
- Do I have numbers for the quantitative claims in my stories?
- Do I have a disagreement story that does not describe the other person as difficult?
- Have I prepared three questions for each interviewer role?
- Have I replaced "a lot of traffic" and "complex system" with specifics?
- Can I describe my AI tooling usage in two sentences with judgment in them?
- Do I have a bookend phrase ready for long answers?
If you can answer yes to five or more, your baseline is sharper than most candidates.
FAQ
Isn't this all just vibes?
It is all vibes, and vibes are the signal interviewers have to work with. Every phrase in this guide correlates with a real rubric item that committees are scoring.
What if I accidentally use one of these phrases?
You will. Everyone does. The goal is not perfection, it is reducing the rate. One slip in a forty-five minute interview is forgettable. Five slips make a pattern.
Do these apply outside of tech?
Most do. The ones that are tech-specific are the AI-tooling and technical-vagueness phrases. The ownership and confidence phrases apply to any interview.
Am I supposed to sound corporate?
No. Several of the fixes in this guide make you sound less corporate, not more. "I brought the error rate down from 0.3% to 0.01%" is less corporate than "we delivered significant reliability improvements."
What if my natural speech includes these phrases?
Then rehearse until it does not. Speech patterns are trainable. Record yourself for a week and count the hedges. You will be surprised how many are reflex, and how easy they are to replace once you notice them.
Do interviewers really notice this level of detail?
They notice it cumulatively, not phrase by phrase. Five small weaker-phrasing choices across an interview add up to a debrief note like "candidate seemed unsure of their own work." You rarely get flagged for one sentence. You often get flagged for the pattern.
Conclusion
Interviews are a compressed medium. In forty-five minutes, every sentence is doing work for you or against you. The phrases in this guide are the ones most likely to be working against you without your knowledge.
Strip the hedges. Replace vague quantities with numbers. Name your own contribution without erasing your team. Ask real questions. Trust your answer enough to not apologize for it.
The phrasing is not cosmetic. The phrasing is the signal.