DEV Community: Emily Woods

I Spent 3 Weeks Auditing My Team’s AI-Generated Code. Here Is What We Found.

Emily Woods — Sat, 20 Jun 2026 02:17:50 +0000

The codebase we built in record time looks functional. It passes CI. It has 91% test coverage. It is also quietly becoming unmaintainable in ways that are hard to see until you look very closely.

6 months ago, my team adopted AI-assisted development aggressively and our velocity numbers became something we were genuinely proud of. We were shipping features in a 3rd of the time. The product was growing. The engineering org was happy. In May, we started hitting a wall, a series of production bugs that were unusually difficult to diagnose, some refactoring work that turned into a four-week project that should have taken four days, and a new hire who told me, candidly, that she had never seen a codebase she found so hard to reason about despite the code itself being syntactically clean. We spent the first three weeks of June doing a structured audit. The technical debt we found was not the kind that shows up in a linter or a dependency vulnerability scanner. It was architectural and behavioral — the kind that only becomes visible under the specific pressure of trying to change something.

The codebase that nobody actually understands
I want to be precise about what I mean by AI-generated technical debt because the term is getting used loosely right now.

The code my team wrote over the past year is not bad code in the obvious sense. It does not have egregious algorithmic errors. It handles most edge cases. The tests pass. The functions are named reasonably well. If you read any individual function in isolation, it reads as competent Python.

The problem is not at the function level. It is at the level of how the system holds together across functions, modules, and services.

When AI coding assistants generate code, they optimize for the problem as described in the prompt. They solve the immediate question. They do this extremely well. What they do not do — because they cannot, given how they work — is reason about the broader system consequences of the solution they are producing. They do not know what changed last sprint. They do not know that this service is being deprecated in six months. They do not know that the data model this function depends on was designed as a temporary workaround and was supposed to be replaced eight months ago.

The code that results from generating against the immediate problem, without the context of the broader system, is locally coherent and globally fragile.

The four specific patterns we found
Pattern 1: The function that works but that no one can explain
We found eighteen instances across the codebase of what I started calling “oracle functions” — functions that produce correct output and have passing tests but where none of the engineers who reviewed the PR at the time could give a confident explanation of exactly why the implementation works for all inputs.

Here is a simplified example of the category:

def normalize_user_event_sequence(events: list[dict]) -> list[dict]:
seen = {}
result = []
for event in sorted(events, key=lambda e: (e.get("timestamp", 0), e.get("id", ""))):
key = (event.get("user_id"), event.get("event_type"), event.get("timestamp", 0) // 3600)
if key not in seen or event.get("priority", 0) > seen[key].get("priority", 0):
seen[key] = event
for key in sorted(seen.keys()):
result.append(seen[key])
return result
This function was generated by the AI, passed its tests, and went into production. But when I asked three engineers to explain the bucketing logic — specifically, why the timestamp is divided by 3600 and what happens at bucket boundaries when two events from the same user occur in the same hour window — nobody could give me a confident answer. Including the engineer who merged it.

The function might be correct. Or there might be an edge case at bucket boundaries that has not surfaced yet because the test suite did not cover it. We do not know. That is the problem.

The specific AI behavior that produces this pattern: AI tools are very good at writing code that passes the tests provided. They are not good at generating tests that cover their own edge cases, because generating comprehensive edge case tests requires understanding the full behavior space of the implementation, not just the happy path specified in the prompt.

The fix is not to reject AI-generated implementations. It is to require that the engineer who merges the code can explain the implementation in their own words, without looking at it, to a colleague who is not familiar with the problem. If they cannot do that, the code does not merge.

Pattern 2: Test coverage theater
Our overall test coverage number is 91%. This number is nearly useless as a quality signal for the AI-generated portions of the codebase.

The problem is that AI coding tools, when asked to write tests, generate tests that cover the code that exists rather than tests that cover the behavior that should exist. The distinction matters enormously.

What AI generated as "tests" for the payment processing module

def test_process_payment_returns_success():
result = process_payment(amount=100, currency="USD", user_id="u123")
assert result["status"] == "success"
def test_process_payment_with_zero_amount():
result = process_payment(amount=0, currency="USD", user_id="u123")
assert result["status"] == "success" # This should probably not succeed
def test_process_payment_stores_record():
process_payment(amount=100, currency="USD", user_id="u123")
records = get_payment_records("u123")
assert len(records) == 1
Three passing tests, 94% line coverage on the function, and none of these tests would catch:

What happens when the payment provider API returns a 503
What happens when the same request is retried and idempotency is not handled
What happens when amount is negative
What happens when currency is not in the supported list
What happens when user_id does not exist in the database
AI-generated tests are optimized for coverage metrics. They test the code that exists. A useful test suite tests the contract that should exist, including the failure modes that are not yet in the code.

The fix we implemented: any AI-generated test suite goes through a mandatory “adversarial review” before merge. A different engineer from the one who wrote the feature spends twenty minutes trying to break the implementation and adds tests for anything they find that is not already covered.

Pattern 3: Invisible coupling discovered during refactoring
This was the most expensive pattern we found, and it is the one that directly caused the four-week refactoring project I mentioned.

When we decided to extract our notification service into a standalone microservice, we expected the work to take roughly four days: identify the notification-related code, move it, update the callers, deploy. Standard extraction refactoring.

What we found was that notification logic had been deeply woven into modules that had no obvious relationship to notifications. The user profile module was calling a notification helper directly. The event ingestion pipeline had notification logic embedded in three separate places with slightly different implementations. The billing module was constructing notification payloads using a local utility function that duplicated the logic in the notification module, with a subtle difference in how it handled timezone offsets.

Every one of these entanglements was introduced by an AI coding assistant responding to a prompt along the lines of “when this event occurs, send a notification to the user.” The AI generated the most direct solution to the prompt, which is to add the notification call in the function that processes the event. It did this correctly, each time, for each feature that needed notifications. What it did not do is recognize that a pattern was emerging that would eventually make the notification system impossible to extract cleanly.

The pattern has a name in architecture literature: it is called implicit coupling, and it is the natural consequence of solving local optimization problems without a global view of the system.

The fix at the code review level: require that any PR that introduces a dependency on a service or module that was not previously a dependency of the modified module be reviewed by a senior engineer. The AI will add dependencies freely. A human reviewer needs to explicitly approve each new one.

Pattern 4: Error handling that looks thorough but is not
AI tools generate error handling that is syntactically comprehensive and semantically shallow. They produce try/except blocks. They log errors. They return appropriate error codes. But the error handling they generate tends to treat all errors in a category as equivalent when the correct behavior often differs substantially based on the specific error.

AI-generated error handling pattern we found repeatedly

async def fetch_user_data(user_id: str) -> dict | None:
try:
response = await http_client.get(f"/users/{user_id}")
response.raise_for_status()
return response.json()
except httpx.HTTPStatusError as e:
logger.error("HTTP error fetching user %s: %s", user_id, e)
return None
except httpx.RequestError as e:
logger.error("Request error fetching user %s: %s", user_id, e)
return None
This catches both 404s (user does not exist) and 500s (upstream service is broken) and treats them identically: log, return None. The callers of this function cannot distinguish between “the user does not exist” and “we could not reach the service.” These require completely different handling. A 404 should result in a clean error to the client. A 500 should result in a retry, or a circuit breaker trip, or an alert. Collapsing them both into return None makes the system appear to handle errors gracefully while actually hiding failures that require operational response.

The audit process that surfaced all of this
We did not find these patterns by reading code. We found them by applying structured pressure to the codebase.

The most revealing exercise was the “change test.” We picked a feature that had been built over the AI-assisted sprint and we tried to make a specific, bounded change: add a new field to a data model. We documented every file that required modification, every test that broke, and every unexpected side effect. The radius of a change is a direct measure of coupling. Features built with disciplined architecture tend to have small change radii. The AI-assisted features had change radii that were consistently larger than expected.

The second exercise was “explain it without looking.” For the functions that tested at high coverage but that the team was uncertain about, we asked the engineer who built each feature to explain the implementation to someone unfamiliar with it. When they needed to consult the code to finish the explanation, we flagged that function for deeper review.

The third exercise was a dependency audit. We mapped every cross-module import that was introduced during the AI-assisted sprint and looked for patterns that indicated implicit coupling rather than designed dependency.

What we are doing differently
We have not stopped using AI coding tools. We use Cursor for most greenfield implementation work, GitHub Copilot for inline completion during exploratory sessions, and Claude Code for heavier refactoring tasks where the full codebase context matters. What has changed is the governance around how we use them.

New code that an AI assistant generates does not merge unless the engineer can explain it, specifically, to a level where a colleague could implement the same solution independently from the explanation alone.

AI-generated tests are treated as a starting point, not a completion. The adversarial review is now a required step in our code review process for any AI-assisted PR.

New dependencies introduced by AI-generated code require explicit senior engineer approval. The AI will add them freely. We need a human to consciously decide each time that the coupling is acceptable.

We have a standing weekly exercise where one engineer picks a module and attempts a bounded change without looking at the implementation details first. If the change is harder than it should be, we investigate why.

None of this is anti-AI. All of it is standard engineering discipline that we should have been applying consistently regardless of how the code was generated. The AI-assisted sprint revealed the gaps in our process by filling those gaps with locally correct but globally fragile solutions, faster than our review process was equipped to catch.

For individual engineers trying to build the audit muscle independently, the tools that have been most useful on my team: Sourcegraph for navigating large codebases and tracing where a specific function or pattern is used across the entire repository which is invaluable for discovering the coupling patterns described above. CodeClimate for tracking maintainability trends over time rather than point-in-time snapshots, which is the only way to see whether your codebase is getting harder or easier to change as a trend. GitHub’s code scanning (powered by CodeQL) for the security debt specifically like it catches a meaningful fraction of the vulnerability patterns that AI-generated code tends to introduce without ceremony.

One practical note for anyone who is currently job searching or keeping themselves interview-ready alongside this kind of team-level work: the skills this audit required is reading unfamiliar code critically, tracing dependencies, identifying coupling and are the exact skills companies are now testing in technical interviews. The interview bar has shifted away from pure algorithmic output toward code review and architectural judgment, and understanding what a specific company tests in their current loops matters for how you allocate prep time. For that calibration, a combination of recent Glassdoor interview reports, Blind threads from the past six months, and PracHub () is the most efficient way to understand whether a company is running algorithmic rounds, code review rounds, or a mix without wasting weeks preparing for the wrong format.

The honest version
The velocity numbers were real. We shipped more features in twelve months than we had in any comparable period. The product is better for it. Some of the AI-generated code is excellent and will be in the codebase for years with no problems.

But the maintainability cliff is also real, and it arrived on a timeline that caught us off guard. The new hire’s observation that the codebase was hard to reason about despite being syntactically clean and is the most precise description of AI-generated technical debt I have encountered. It looks fine. It reads fine. It passes review. And then you try to change something and you discover that the system as a whole has properties that none of the individual pieces would suggest.

The teams that are going to do this well are the ones that treat AI coding tools the way senior engineers already treat junior engineers: with trust, with expectation, and with the judgment to know when to override the output. The tools are excellent at what they do. What they do is not the full job.

The Age of Agentic AI: What Engineering Jobs Actually Look Like in 2026 (second half)

Emily Woods — Sun, 14 Jun 2026 20:50:57 +0000

The demos are over. Autonomous coding agents are now merging PRs into production codebases. Here is what happens to your career when you are no longer the one writing the code, and how to survive the next 6 months.

The first half of 2026 was defined by panic over AI demos. The second half of 2026 will be defined by the quiet, brutal reality of agentic AI actually doing the work. Engineering teams are not being entirely replaced, but they are shrinking and restructuring. The job of a software engineer is shifting rapidly from “writing implementation code” to “managing autonomous agents and auditing their output.” If your entire professional value is tied to turning a well-scoped Jira ticket into a React component or a CRUD endpoint, you are competing against an agent that works 24/7 for pennies. If your value is tied to defining ambiguous problems, catching architectural edge cases, and verifying that a system actually solves a business need, you are about to become more valuable than ever. The role is bifurcating. You are either an orchestrator, or you are redundant.

The end of the implementation era
We spent the last two years treating AI like a really smart autocomplete. We argued about whether Copilot made us 10 percent or 30 percent faster.

That era is dead.

Agentic AI does not wait for you to start typing. Agents pull tickets from the backlog. They clone the repository. They read the documentation, spin up a testing environment, write the implementation, generate the tests, and open a pull request. They do this while you are sleeping.

I sat with an engineering director last week who admitted his team merged 40 pull requests in a single sprint. His engineers only wrote three of them. Autonomous agents wrote the rest. The engineers spent their entire sprint reviewing code, fighting over testing frameworks with the agent, and pushing back on hallucinated dependencies.

This is what second half 2026 looks like at companies that care about margins. The bulk of the manual typing is gone. The actual coding part of software engineering is becoming a legacy skill, shrinking down to the smallest possible fraction of your day.

The new engineering hierarchy
When agents write the code, the value of an engineer changes entirely. The industry is currently restructuring around three new tiers of talent.

The bottom tier is the Prompt Jockey. This is the junior or mid-level engineer who treats the agent like a magic box. They feed it a prompt, wait for the PR, glance at the test results, and hit merge. These engineers are a massive liability. They do not understand the code the agent generated. When production inevitably breaks at midnight, they have no mental model of the system to debug it. Companies are actively firing these engineers right now because they are just expensive middle-men between a Jira board and a repository.

The middle tier is the Auditor. This engineer reads agent-generated code with deep skepticism. They understand that agents are incredibly convincing liars. An agent will confidently write an API integration that looks perfect but silently fails to handle pagination properly. The Auditor treats the agent like a brilliant but reckless intern. They enforce strict boundaries, demand rigorous unit tests, and manually trace the edge cases. This is a safe job for the next twelve months, but it is grueling work.

The top tier is the Orchestrator. This is the new senior engineer. The Orchestrator rarely touches the implementation details. Their job is translating messy, contradictory business requirements into explicit, bounded contexts that agents cannot misunderstand. They design the system architecture. They decide which microservices the agents are allowed to touch. They build the guardrails, define the failure states, and manage the deployment pipelines. Orchestrators are currently commanding massive premiums in the labor market because they are the only people keeping agentic systems from tearing production apart.

The death of the “Junior” pipeline
The most immediate casualty of the agentic shift is the entry-level hiring pipeline.

Historically, companies hired junior engineers to do grunt work. They fixed typos, wrote basic tests, and handled simple UI updates. This was how they learned the codebase. It was an apprenticeship disguised as employment.

Agents now do all the grunt work instantly. There is no economic incentive to hire a junior engineer who takes three days to complete a task an agent finishes in three minutes.

If you are trying to break into the industry in the remaining of 2026, you cannot compete on execution speed. You have to jump straight to the Auditor tier. You must prove you can read complex codebases, spot logical flaws in existing architectures, and communicate technical trade-offs. The barrier to entry has never been higher, and the grace period for learning on the job has completely vanished.

How interviews are changing right now
The way companies hire is adapting to this reality in real time.

If you are interviewing in the next six months, expect the standard LeetCode to look fundamentally different. Asking a candidate to reverse a linked list on a whiteboard is useless when an agent can write an optimized traversal algorithm in a fraction of a second.

Instead, companies are testing code review and system constraints.

In recent loops, I have seen candidates handed a 300-line pull request generated by an agent.

The prompt is simple: “This code passes all unit tests but will cause a critical failure in production. Find the bug and explain why the agent missed it.”

Interviewers are looking for your ability to hold a complex system in your head. They want to see if you catch the unhandled race condition. They want to know if you recognize that the agent used an inefficient database query that will bottleneck under load.

System design interviews are shifting from “design Twitter” to “design the boundaries for an autonomous agent.” You will be asked how to rate-limit an agent, how to prevent it from dropping a production table, and how to gracefully degrade the system when the LLM provider experiences an outage.

Surviving the next 6 months
You have a very short window to reposition yourself.

Stop optimizing for writing code quickly. Nobody cares how fast you type anymore. Start optimizing for reading code critically.

Go to GitHub. Pull down a massive, unfamiliar repository. Pick a complex PR and force yourself to review it as if your job depended on catching a critical vulnerability. Build the muscle of reading other people’s logic or a machine’s logic — and spotting the hidden assumptions.

When you prepare for interviews, shift your focus entirely toward architecture and code review. Practice explaining why a piece of code works, not just how to write it. When assessing what a company is currently testing, use the tools that aggregate real interview signals. Look at Blind for candid discussions on how different teams are deploying agents. Check Glassdoor for recent changes in technical questions. Use PracHub to see if a specific company has shifted their coding rounds toward code-review formats rather than algorithmic scratchpads. Combine these sources to understand the exact bar you need to clear.

Final thoughts
The anxiety you feel right now is justified. The profession is fundamentally changing. The work that got you promoted two years ago is the exact work that will make you redundant tomorrow.

But this is not the end of software engineering.

We are simply abstracting away the tedious mechanics of typing syntax. The core of engineering has always been solving complex problems, navigating ambiguity, and building reliable systems. The agents are taking the typing. They cannot take the judgment.

If you cling to your identity as a code writer, second half 2026 will be brutal. If you embrace your identity as a system architect and critical auditor, you are about to have the most leverage of your entire career.

9 Out of 10 Engineers Prepare for the Wrong Behavioral Interview. Here Is What the Right One Looks Like.

Emily Woods — Wed, 10 Jun 2026 23:36:53 +0000

Every senior engineer has the experience. Almost none of them have learned to narrate it in a way that produces evidence at the level they are actually interviewing for.

It is a structured attempt to collect evidence about how you have operated in the past, on the assumption that past behavior predicts future behavior at scale. The companies that take behavioral rounds seriously, and the list is longer than most candidates assume, they have built explicit rubrics that map specific types of story content to specific competency levels. Your stories either contain the evidence those rubrics require or they do not. The evidence required for a senior or staff offer is categorically different from the evidence that passes a junior or mid-level round. Most engineers who fail behavioral rounds do not fail because they lack relevant experience. They fail because they narrate what happened rather than the judgment they exercised while it was happening, and because they describe team outcomes rather than personal decisions. These are fixable problems. But they require understanding what the behavioral round is actually measuring before you can fix them.

What the behavioral round is actually testing
There is a persistent myth that behavioral interviews are the soft round which is the one where you just need to be personable, answer questions honestly, and let your personality come through. This belief is expensive for anyone interviewing above the junior level.

Behavioral interviews at serious tech companies are structured around competency frameworks. These frameworks define specific categories of behavior, leadership, conflict resolution, technical decision-making under ambiguity, mentorship, cross-functional influence and map each category to evidence standards that differ by seniority level. An interviewer walking into a behavioral round for a senior engineer is not listening for whether you seem like a pleasant person. They are listening for evidence of specific behaviors in specific contexts, and they are mentally checking whether that evidence meets the threshold their rubric associates with the level they are hiring for.

The practical implication is that a charming, articulate answer that contains the wrong kind of evidence fails the round just as reliably as a disorganized answer that contains the right kind of evidence but buries it. The content of the story matters more than the delivery. The delivery matters for clarity and confidence. The content matters for the recommendation.

What constitutes evidence at the behavioral level varies by company but converges on a consistent theme:

interviewers want to see that you have exercised independent judgment on consequential problems, that your judgment was sound and traceable, and
that the outcome of your involvement was meaningfully different from what would have happened without you. Like meaningfully different.
The level-dependent evidence problem
This is the mechanism that explains most of the behavioral failures I have seen in debrief sessions.

At the junior level, the behavioral bar requires evidence that you can communicate well, handle feedback without becoming defensive, and complete work that produces a result the team needed. The scope of the story does not need to be large. The decision-making does not need to be independent. What the junior-level behavioral assessment is looking for is coachability, execution, and the ability to work within a team. An answer that describes what you did on a project and what you learned from it is often sufficient.

At the mid-level, the bar shifts. The story needs to demonstrate that you can own a complete technical task from start to finish without requiring constant direction. You are still operating within a defined scope, but the behavioral evidence needs to show that within that scope, you are making genuine technical decisions rather than executing what others decided. A story about implementing a feature is sufficient at junior. At mid-level, the story needs to show that you identified the right way to implement the feature, made a trade-off decision somewhere in the process, and would make the same decision again for a specific reason.

At the senior level, the shift is dramatic and frequently underestimated. The behavioral bar at senior requires evidence of at least three things that almost never appear naturally in how engineers tell stories about their work. The first is that you defined the problem rather than receiving a definition. The second is that you influenced people who did not report to you — a product manager, a technical lead, a stakeholder in a different org — toward an outcome you believed was correct. The third is that you handled a specific moment where the technically correct answer and the organizationally expedient answer diverged, and you navigated that divergence consciously.

At the staff level, the scope expands again. The story needs to involve ambiguity at the level of the company strategy, not just the team’s technical decisions. Staff-level behavioral evidence often involves moments where the right answer was genuinely unclear to everyone, where you brought clarity to a situation that was blocking multiple teams, and where the downstream consequences of your decision or recommendation affected engineers you had never met.

Most engineers applying for senior roles tell mid-level stories. Most engineers applying for staff roles tell senior stories. The level mismatch is the single most common cause of the down-level outcome that candidates experience as inexplicable.

Building the story bank
The preparation mistake that causes the most damage in behavioral rounds is trying to construct stories on the fly in response to interview questions. This produces generic answers, tense inconsistencies, factual imprecision, and — most visibly to the interviewer — the pause before answering that signals the candidate is searching for a relevant story rather than selecting the best one from a prepared set.

A story bank is a document, not a mental list. It is a structured record of six to ten high-signal experiences from your professional history, each documented with enough detail that you can reconstruct the story accurately and specifically under pressure.

The structure I use for each entry in the story bank has six fields.

The situation is the minimum context the interviewer needs to understand what was at stake. This should be two to four sentences. It should include the company stage or size, the team context, and what made this situation consequential. It should not include more than three sentences of background before anything happens.

The problem you personally identified is what you noticed or diagnosed that set the story in motion. This is distinct from the problem you were assigned. If you were assigned the problem, that is a mid-level story. If you identified the problem yourself and then made the case for working on it, that is beginning to be a senior story.

The specific decision you made and the alternatives you considered is the core of what makes a story land at the right level. Every strong behavioral story contains a decision point where there was more than one plausible option and you chose one for a specific reason. Interviewers are not interested in what you did. They are interested in why you did that rather than the alternative, and whether your reasoning was sound.

The people you influenced is where cross-functional impact gets documented. Who did you have to convince? What was their initial position? What was your approach? This is the evidence that separates individual contributors from senior engineers in the behavioral record.

The outcome and its measurement is the evidence that your decision actually mattered. This needs to be specific. Improved latency by 40% is evidence. Made the API faster is not. Reduced the support ticket volume from this feature from 15 per week to 2 per week is evidence. Customers were happier is not.

The learning is what you would do differently, and this field is important specifically because interviewers at senior and above often follow up on positive stories by asking what you would change. A candidate who has already thought through the honest limitations of their decisions is demonstrating a level of self-awareness that calibrates with senior expectations. A candidate who says they would not change anything is either telling a sanitized story or has not done the genuine retrospective work.

The I versus We problem in depth
This deserves more space than it usually gets, because the failure mode is subtle and the fix is specific.

When engineers describe their professional work naturally, they use the first-person plural because that is how collaborative work feels from the inside. You are genuinely a team. The success belongs to the group. Using the singular feels like taking credit that belongs to others.

The behavioral interview does not evaluate teams. It evaluates you. The interviewer cannot offer a role to your team. They are evaluating whether you specifically meet the evidence standard, and they can only evaluate evidence about your specific actions, decisions, and influence. Every time you say the team or we where you could say I, you are erasing evidence about yourself that the interviewer needs.

The fix is not to claim sole credit for team work. It is to be specific about your personal contribution within the team context. Describing what you personally analyzed, decided, communicated, or designed — while being clear that you were working alongside others — is accurate and produces evaluable evidence. Describing what your team accomplished, with yourself as a generic member of the collective, is not evaluable and will not produce a strong recommendation.

The specific reframe is: whenever you are about to say we, ask yourself what you specifically did within that we. If you can name it — I proposed, I designed, I pushed back on, I escalated, I wrote the spec for — say that instead. If you genuinely cannot name what you specifically contributed, consider whether that story is the right one to tell for this question.

The failure story problem
Behavioral interviews at every serious tech company include at least one question about a failure, a mistake, or a time something did not go as planned. This is the question that most candidates handle worst, and the failure mode is almost always in the same direction: the candidate tells a story where the failure was small, the circumstances were unusual, and the lesson was generic.

Interviewers at senior and above have heard hundreds of versions of the story where the candidate missed a deadline because of unexpected complexity and learned to communicate earlier. They do not find this story impressive. They find it safe. Safe is a different evaluation from strong, and safe rarely produces a hire recommendation at the senior level.

The behavioral evidence that the failure story needs to contain at senior level is specific: you made a judgment call that was genuinely yours, the judgment call turned out to be wrong in a way that had real consequences, and your retrospective analysis of why the judgment was wrong is specific and narrow rather than generic. The learning that registers at senior level is not I learned to communicate more. It is I learned that my assumption about the load distribution was wrong because I was reasoning from a dataset that did not reflect the actual traffic pattern, and now I validate that assumption explicitly before making architecture decisions that depend on it.

The reason most engineers avoid real failure stories is that talking about genuine failure feels professionally risky in an evaluation context. The counter-intuitive reality is that a genuine, specific failure story with honest reasoning about why the judgment was wrong is significantly more compelling to a senior interviewer than a sanitized story where nothing really bad happened. The ability to reflect honestly on your own errors, understand their root causes, and articulate specific changes to your decision-making process is itself evidence of senior-level professional maturity.

The Amazon Leadership Principles as a case study
Amazon is worth discussing specifically because their behavioral framework is the most codified and the most transparent of any major tech company, and studying it teaches you something generalizable about how all serious behavioral frameworks work.

Amazon’s Leadership Principles are not a list of values. They are a behavioral competency taxonomy. Each principle describes a specific pattern of behavior that Amazon believes produces business outcomes at scale. When you interview at Amazon, each behavioral question is anchored to one or more of these principles, and the interviewer is collecting evidence about whether your stories demonstrate those specific behavioral patterns, not whether you seem to agree with the principle in the abstract.

The implication for preparation is that you cannot prepare for Amazon behavioral rounds by learning the principles as concepts. You have to map your story bank to the specific behavioral evidence patterns each principle describes. Customer Obsession, for example, is not satisfied by a story about how you care about customers. It is satisfied by a story where you identified a gap between what the customer was experiencing and what your team believed they were experiencing, and you took a specific action to close that gap, even when it was inconvenient or politically costly to do so.

The specific preparation move for Amazon is to take your story bank entries and annotate each one with which Leadership Principles it provides evidence for, and at what depth. An entry that provides surface-level evidence for three principles is less valuable than an entry that provides deep evidence for one. Deep evidence means that the story contains a decision point that is specific to that principle, not a tangential mention.

The broader lesson from the Amazon framework is that every serious tech company has an equivalent rubric, even when it is not publicly documented. Companies with stated engineering values or tenets — Google, Stripe, Databricks, and most companies that have been through a significant scaling phase — have mapped those values to behavioral evidence patterns in their internal calibration guidelines. The preparation for any of these companies is the same: understand what the stated values actually mean as behavioral patterns, and then find or construct stories that demonstrate those patterns at your target level.

The questions that function as traps
A small set of behavioral questions function as traps not because they are designed to deceive but because the natural, intuitive answer consistently misses what the question is measuring.

The tell me about yourself opener is an invitation to demonstrate concision, selectivity, and professional narrative control. The answer that works is a two-minute arc that establishes your current level and domain, highlights one or two experiences that are directly relevant to this role, and ends with a clear statement of why you are interested in this conversation specifically. The answer that fails is a chronological recitation of every role on your resume.

The what is your greatest weakness question is not a question about what you are bad at. It is a question about whether you have genuine self-awareness, whether you take active steps to address your limitations, and whether you can talk about professional vulnerability without either deflecting or spiraling into self-criticism. The answer that works names a real and specific limitation, describes the observable consequence of that limitation in your work, and describes a specific practice you have adopted to manage or improve it. The answer that fails names a strength disguised as a weakness or describes something irrelevant to the work.

The tell me about a time you disagreed with your manager question is looking for evidence of professional courage and the ability to advocate for a technical position through legitimate channels without damaging the relationship. The answer that works describes a specific technical or strategic disagreement where you had a well-reasoned position, explains how you presented that position and what evidence you used, and describes the outcome honestly regardless of whether you prevailed. The answer that fails either describes a trivial disagreement or frames the manager as wrong in a way that reads as poor professional judgment.

The prep approach that actually works
Effective behavioral prep has two phases and a specific sequence.

The first phase is story bank construction. This takes four to six hours spread over several sessions rather than done in one sitting, because the retrospective work of identifying your genuine decision points requires time to surface memories that were not salient at the moment they happened. The output of this phase is six to ten fully documented story entries in the format described above, covering at least one story from each of the following categories: a significant technical decision and its trade-offs, a cross-functional conflict or misalignment you navigated, a failure or mistake and your retrospective analysis of it, a situation where you mentored or developed another engineer, and a situation where you had to influence an outcome without authority.

The second phase is rehearsal under the specific constraints of a live interview. You read each question cold, select a story without excessive deliberation, and narrate the full answer out loud in under three minutes. You time yourself. You record yourself if possible and listen for the signal-to-noise ratio — how much of what you said was specific evidence versus general framing and filler. You practice the follow-up layer, which is the interviewer asking for more detail about a specific part of your story. Strong behavioral answers survive one or two follow-up questions without contradiction or vagueness.

For the deliberate practice component, particularly for understanding the evidence standard at your specific target level and company which is a combination of resources is more useful than any single platform. Amazon publishes extensive documentation of their Leadership Principles with behavioral examples. The Big Interview offer structured behavioral mock sessions with feedback from practitioners. For company-specific behavioral question patterns and what the calibration criteria have historically looked like at specific levels, Glassdoor interview reports, Blind threads, and PracHub are the most practical sources and if used together, they give you both the question inventory and the current calibration context that free sources alone sometimes miss.

I Have Run 80+ Phone Screens. Here Is Why Good Engineers Keep Bombing Them.

Emily Woods — Sat, 06 Jun 2026 23:16:11 +0000

Read this, if you think you are a good engineer and you still keep bombing your phone screen interviews.

The phone screen is not a simplified version of the full interview loop. It is a different kind of evaluation with different criteria, a different time budget, and a different failure mode profile. The candidates who fail phone screens are often the same candidates who would pass the full loop if they got there, it’s because they have never been told what the phone screen is actually measuring. A phone screener is trying to determine whether it is worth six hours of their colleagues’ time to find out if you are a strong engineer. That is a much lower bar than the full loop, and the specific way to clear it is almost entirely different from the way to clear the loop itself.

What the phone screen is actually for
The phone screen exists to solve a resource allocation problem. Running a full interview loop costs a company somewhere between 4 to 8 hours of senior engineering time, plus recruiter coordination time, plus the overhead of scheduling across multiple calendars. Doing that for every candidate who passes a resume screen would make hiring economically irrational. The phone screen is the filter that makes the full loop sustainable.

This means the phone screener’s primary job is elimination. They are looking for reasons to confidently pass you forward to the loop, or confidently not. A candidate who is clearly strong technically and communicates cleanly gets passed forward. A candidate who is clearly not at the required level gets eliminated. The difficult case can be the candidate who is somewhere in the uncertain middle and tends to get eliminated in practice, because the cost of a false negative (missing a good candidate) is lower than the cost of a false positive (running a full loop on someone who fails it).

Understanding this changes the preparation goal. You are not trying to impress a phone screener with the depth of your system design thinking or the elegance of your behavioral storytelling. You are trying to give them enough clear, confident evidence of competence in 35 minutes that the risk calculation resolves in your favor. The standard is different. The strategy is different. The prep is different.

The recruiter screen and the technical screen are completely different evaluations
Before talking about the technical phone screen, it is worth distinguishing it from the recruiter screen that often precedes it. Many candidates treat these as interchangeable. They are not.

The recruiter screen is not a technical evaluation. The person conducting it is typically not an engineer, cannot assess the quality of your code, and is not trying to. What they are evaluating is: whether your stated experience matches the role requirements at a surface level, whether your comp expectations are in the range the role can accommodate, whether you can articulate coherently what you have done and why you are interested in this company, and whether there are any obvious disqualifying factors like a gap in employment that has no explanation, a set of responsibilities that are inconsistent with the seniority being claimed, a comp expectation that is dramatically above what the role supports.

The failure modes in a recruiter screen are almost entirely communication failures. Engineers who give meandering answers to simple questions, who cannot explain what they worked on without defaulting to technical jargon the recruiter cannot evaluate, or who have not done basic research on the company create an impression of either poor communication skills or low interest in the role. Both eliminate you without a technical evaluation ever happening.

The technical phone screen is where the engineering evaluation begins. This is typically conducted by a senior engineer, a tech lead, or a hiring manager. Unlike the full loop, the technical phone screen usually covers one coding problem and sometimes a brief system design discussion, with additional time for conversational questions about your background. The coding problem is almost always medium difficulty. The system design component, if it exists, is shallow, one or two components rather than a full architecture.

The signal the technical phone screener is collecting is not primarily about your solution. It is about your process.

What the phone screener is documenting in real time
When I conduct a technical phone screen, I am simultaneously writing notes while the candidate is coding. I am not transcribing what they say. I am noting specific signals that I have learned over time predict success or failure in the full loop.

The signals I am writing down within the first ten minutes are: whether the candidate asked clarifying questions before starting to code, whether those questions were specific and relevant or generic and time-filling, whether their initial approach was stated explicitly or implied by the code they started writing, and whether they handled the moment of uncertainty that almost every phone screen problem has, the point where the problem is ambiguous and requires a judgment call with confidence or with a request for the interviewer to resolve it for them.

By the 20 minutes mark, I am noting whether the code is readable, whether the variable names mean anything, whether the candidate tests their solution against the obvious edge cases without prompting, and whether their communication has maintained a consistent level of clarity or has started to degrade under the time pressure. Communication degrading under pressure is a very common failure mode in phone screens and almost never comes up in loop prep, because mock interviews are typically run at a more relaxed pace than the real phone screen.

In the 10 minutes, it matters whether the candidate understood the complexity of their solution, whether they could articulate what they would change if the constraint changed, and let’s say if I ran a brief system design discussion whether they named a specific technology, any technology, and could say in one sentence why that technology rather than an alternative.

The notes from a phone screen that results in a pass forward typically contain 5to 8 specific positive data points. The notes from a phone screen that results in an elimination typically contain two or three generic positive notes and a specific concern that I could not resolve in the time available. The specific concern is what drives the recommendation.

The 5 specific ways good engineers bomb phone screens
The first is overexplaining the wrong thing. Good engineers who have prepared thoroughly sometimes spend the first fifteen minutes of a thirty-five minute phone screen clarifying requirements, discussing edge cases, and describing multiple possible approaches before writing a single line of code. In a full loop, this kind of deliberateness signals senior-level thinking. In a phone screen, it consumes the time budget in a way that prevents the interviewer from seeing enough to recommend a pass. The phone screener needs to see you produce something before the session ends. If you spend half the time preparing to produce and run out of time to demonstrate execution, the recommendation is uncertain, and uncertain resolves to no.

Download the Medium App
The second is optimizing for the wrong audience. Engineers who have prepared extensively for senior loops sometimes bring staff-level scope to a phone screen problem and spend time discussing distributed consistency guarantees for a problem that asked for a function that reverses a linked list. The phone screener is not evaluating depth. They are evaluating whether you can solve the problem in front of you clearly and quickly. Demonstrating depth on the wrong problem signals that you are not calibrated to the actual question, which is itself a signal worth documenting.

The third is failing the communication test without knowing there is a communication test. Many engineers work through technical problems silently when alone and have to consciously choose to narrate their thinking in an interview. In a full loop, the format and the duration give candidates time to remember to narrate and to settle into the habit. In a 35-minute phone screen, candidates who forget to narrate in the first ten minutes often realize it around the fifteen-minute mark, try to recover, and produce a communication pattern that is choppy and inconsistent. The interviewer notices the inconsistency and cannot determine whether the candidate is normally a clear communicator who had a bad session or normally a poor communicator who partially recovered.

The fourth is a mismatch between the complexity of the solution and the ability to explain it. Some engineers correctly identify a complex optimal solution, implement it correctly, and then cannot explain clearly why it is correct or what assumptions it depends on. This pattern — impressive implementation, limited articulable understanding — reliably generates a specific negative note: strong coder, concerning depth. That note is enough to cause a pass-forward hold at most companies.

The fifth is misreading the time signal. When a phone screener says something like there are about ten minutes left, it is almost always a signal to finish what you are doing and move to edge cases or complexity discussion. Candidates who hear this signal and start a new, harder approach to the same problem, or who respond by speeding up their implementation in a way that introduces bugs, create an unnecessarily negative final impression. The last five minutes of the phone screen are the interviewer’s most recent memory of the candidate. That memory is what they write their recommendation note from.

The timing problem
A full interview loop coding round is typically 45 to 60 minutes. A phone screen is 30 to 45 minutes, and that window includes introductory conversation, clarifying questions, implementation, testing, and often a brief discussion of complexity or follow-up questions. The actual coding window in a phone screen is often 20 to 25 minutes.

Most candidates do not practice coding problems under a 20-minute timer. They practice under 45-minute timers, which is the appropriate constraint for the full loop. The gap in time pressure is not linear — the cognitive experience of producing correct, readable, narrated code in 20 minutes is qualitatively different from producing it in 45 minutes. It requires faster pattern recognition, faster implementation, and a different set of decisions about what to optimize and what to leave for later.

The specific prep adjustment for phone screens is to practice medium-difficulty problems with a hard 20-minute timer and a rule that requires narration at all times. Not narration when convenient or narration when you have something interesting to say narration continuously, even when you are doing something mechanical like writing a loop iterator or initializing a data structure. The goal of this constraint is to build the habit of continuous communication under time pressure so that it does not require active cognitive effort during the actual phone screen.

The other timing adjustment is learning to read a problem faster. In a full loop, you can take five minutes to fully understand the problem before proposing an approach. In a phone screen, you have roughly two minutes. The specific skill is identifying the problem category from the first read of the prompt is that this a two-pointer problem, a sliding window problem, a tree traversaland using that identification to immediately describe the approach before fully implementing it. Saying I think this looks like a sliding window problem, let me state the approach and then we will see if the edge cases complicate it takes twenty seconds and immediately gives the interviewer something positive to write down.

The recruiter screen is also prep
One thing I did not fully understand as a candidate was that the recruiter screen requires its own specific preparation, completely separate from technical preparation. The recruiter screen is a communication test where the raw material being evaluated is your ability to describe your work clearly to a non-technical audience under mild pressure.

The specific skills it tests are: the ability to describe what your current or most recent company does in two sentences without jargon, the ability to describe what you personally built or owned in your most recent role in three or four sentences that a non-engineer could understand, the ability to explain why you are interested in this specific company and role with a reason that is more specific than the company being well-known, and the ability to give your compensation expectations without either refusing to answer or giving a number that immediately disqualifies you.

Each of these feels simple and is actually difficult to do well under the mild pressure of a live call with a stranger who is evaluating you. The preparation for a recruiter screen is to practice each of these answers out loud, by yourself, until the length and content feel natural rather than scripted. Not to memorize the words but to internalize the structure like what you say first, what level of technical detail is appropriate, what to say when you do not know the answer to something.

The preparation that specifically targets phone screens
The prep for a phone screen is a subset of the prep for a full loop, but it is not a smaller version of the same thing. It is different.

For the technical phone screen: solve medium-difficulty problems under a hard 20-minute timer with continuous narration required. Practice identifying the problem category within two minutes of reading the prompt — is this a sliding window, a two-pointer, a graph traversal. Practice stating the approach explicitly before writing the first line of code. Practice testing against the first obvious edge case before the interviewer mentions it. LeetCode’s medium problem set is the right material; NeetCode’s topic-grouped roadmap is useful for making sure you are covering the categories that appear most frequently rather than solving randomly.

For the recruiter screen: practice the four core questions like what your company does, what you personally built, why this company and role, and comp expectations like in a way that is specific, jargon-free, and appropriately concise. A good answer to any recruiter question lands between 30 and 90 seconds. Anything shorter sounds rehearsed. Anything longer loses the recruiter’s attention. Record yourself answering these questions and listen back. Most engineers discover that their answers are either too technical, too long, or both.

For company-specific calibration: the most useful input is recent interview reports from people who have actually been through the process. Glassdoor and Blind both surface these, and the key qualifier is recency, look for reports from the past three to six months, not older. Note the difficulty level, the style (algorithmic versus design-oriented), and whether follow-up constraints were introduced mid-problem. When multiple recent reports describe the same pattern, you have reliable calibration data. Levels.fyi is useful for understanding what level the role is actually being filled at, which tells you whether the phone screen is calibrated to a junior, mid-level, or senior bar. For companies where recent report volume is low on the free platforms, PracHub aggregates company-specific question patterns in a searchable format, which saves the manual cross-referencing across forum threads — but the free sources cover most major companies well enough if you are willing to dig.

Phone screen is the round where the most prepared candidates are the least specifically prepared. The people who spend weeks studying system design and dynamic programming have often spent zero time practicing under a 20-minute hard timer while narrating continuously. The people who know exactly how to answer behavioral questions in the STAR format have often never practiced describing their current role clearly to a non-technical person.

The phone screen is not hard. The problems are medium difficulty. The criteria are not opaque. The failure mode is almost always preparation targeted at the wrong test.

Fix the timer. Practice the narration at speed. Prepare two clean answers to the recruiter’s four questions. Know the typical difficulty and style of phone screens at your target company. That is the full preparation list. It takes less time to master than any single algorithm pattern from a top-tier prep course, and it is the filter that most candidates never get past.

I Have Sat in 100s of Debrief Calls. Here Is What Interviewers Discuss After the Call.

Emily Woods — Thu, 04 Jun 2026 02:11:56 +0000

After your interview loop ends, the people who interviewed you get on a call or a shared document and make a recommendation. This conversation is structured differently at different companies, but the underlying dynamics are consistent: each interviewer submits a rating and written notes, a designated calibration interviewer or bar raiser checks that the decision is consistent with the company’s overall hiring standard rather than just the team’s preferences, and the group works toward a consensus on both the hire decision and the level. The candidates who get the outcome they expected are the ones whose performance gave the interviewers clear, consistent material to work with. The candidates who get surprised by rejections or down-levels are almost always the ones who performed unevenly across rounds and left the debrief with inconsistent signals that resolved in the direction of caution. Understanding what the debrief actually evaluates gives you specific information about how to perform more consistently, not just more impressively.

What the debrief actually is
At most mid-to-large tech companies, the debrief is a structured review that happens within 24 to 72 hours of your final interview. At Google, Meta, Amazon, and most companies that have modeled their process on FAANG practices, the structure typically involves each interviewer submitting an independent written evaluation before seeing anyone else’s feedback, followed by a group calibration session.

The written evaluation submitted before the group call matters more than most candidates realize, because it is produced while the interview is still fresh and before social dynamics in the group session can influence individual positions. An interviewer who felt genuinely uncertain about a candidate is much less likely to document uncertainty clearly if they submit their notes after hearing two strong positive evaluations from colleagues. The pre-submission requirement is designed to capture independent signal. When it works, the group calibration produces a more accurate picture than any individual round alone.

The people in the debrief include every interviewer from the loop, typically the recruiter as a logistics and policy voice, and at many companies a designated calibration reviewer — called a bar raiser at Amazon, a calibration interviewer at Google, and various equivalents elsewhere. This calibration reviewer has a specific and important function: they are responsible for ensuring that the hire decision reflects the company-wide standard, not just the preference of the hiring team. A team that is under pressure to hire, has been searching for months, and desperately wants to fill the role will sometimes push toward a hire recommendation that a calibration reviewer will push back on, specifically because the calibration reviewer’s job is to be immune to that pressure.

The voting system and what the ratings actually mean
The rating scales vary by company, but the underlying spectrum is consistent. Most systems have five positions that map roughly to:

strong hire,
hire,
lean hire or
neutral,
no hire, and
strong no hire.

The relationship between individual ratings and the final decision is not simply arithmetic. A majority of hire votes does not automatically produce an offer, and a majority of no-hire votes does not automatically produce a rejection. The calibration process is specifically designed to resolve inconsistency rather than just count votes.

A strong no hire from a senior or staff interviewer in a domain-critical round, a staff engineer’s strong no hire on a system design for a senior backend role, for example- carries more weight than two hire votes from interviewers in peripheral rounds. The calibration reviewer is explicitly watching for situations where the overall positive signal is contradicted by a specific expert signal, and they will typically raise that contradiction explicitly rather than letting a numerical majority decide.

A lean hire is the most unstable position in the debrief. It typically indicates that an interviewer saw enough to consider the candidate acceptable but not enough to be confident. In a group calibration with mostly strong hire votes, a lean hire usually resolves to hire. In a group with mixed signals, lean hire is often the vote that tips toward no hire after the discussion, because it is hard to defend with specific evidence and because the people arguing for hire in those cases often cannot point to concrete moments in the interview that justify overriding the uncertainty.

The implication for candidates is specific: the interviewer who gave you a lean hire is your most important feedback signal, not your worst rating in isolation. Understanding what caused someone who was otherwise engaged and constructive to stop short of a confident positive recommendation is worth more than understanding what went wrong with the person who gave you a clear no hire.

The phrases that reliably doom candidates in the debrief
Interviewers at most companies are trained or at least guided toward structured feedback language. But the underlying evaluations behind that language are consistent enough across companies and roles that the phrases function as a readable signal.

Communication issues is almost never about clarity of speech, accent, or verbal fluency. When an interviewer writes this phrase, they mean one of three specific things. The first is that the candidate was silent during moments where the interviewer expected narration — working through a problem without explaining their thinking, making decisions without stating the trade-off, or pivoting approaches without explaining why. The second is that the candidate’s explanations were inconsistent with their code or design — they said they were doing one thing and then implemented something different, which makes the interviewer question whether the verbal explanation was genuine understanding or a memorized script. The third is that the candidate required an unusual amount of prompting to stay on track, which the interviewer interprets as an inability to structure their own thinking rather than a conversational style preference. Communication issues in a debrief report is often the most specific and most actionable negative signal available to a candidate, because the remediation is completely within their control.

Not quite at level means the interviewer saw work that would be appropriate for the role one level below the one being interviewed for. This is not a failure of technical knowledge in most cases. It is a failure of scope. A candidate interviewing for a senior role who solves problems correctly but does not proactively identify the broader system implications of their solution, or who answers behavioral questions with examples of well-executed assigned work rather than examples of self-directed problem definition, will receive this note regardless of how technically correct their outputs were. The calibration reviewer will typically flag this note as the basis for a down-level offer rather than a rejection, which is why the not-quite-at-level note is the signal most correlated with receiving an offer at a lower level than expected.

Needed prompting or required hints is a specific death sentence for a senior or above evaluation. At junior and mid-level, receiving a hint and running with it cleanly is often a positive signal — it shows coachability. At senior level, needing a hint to reach the correct approach demonstrates that you cannot independently navigate to the best solution, which is precisely what the senior evaluation is testing. Calibration reviewers watching for level consistency across the company will push back on any hire recommendation at senior or above that includes needed prompting in the coding or system design round notes.

Culture fit concerns is the phrase most likely to mean something uncomfortable and least likely to be documented with specificity. It can legitimately mean that the candidate’s stated values were inconsistent with how the team actually operates — someone who describes their ideal environment as highly autonomous but is joining a team that runs closely paired engineering with heavy process. It can also mean that the candidate was abrasive, dismissive, or condescending in a way that one or more interviewers experienced as genuine risk to team dynamics. When this phrase appears alongside positive technical ratings, the debrief becomes difficult. Strong technical signals make a no-hire recommendation hard to defend on pure competency grounds, but interviewers who felt a genuine negative interpersonal reaction will often hold their position even under pressure from the group.

The bar raiser function and what it means for you
The bar raiser or calibration interviewer role exists because of a known failure mode in team-driven hiring: teams under pressure hire people they like rather than people who meet the standard. A manager who has been searching for three months and has a backlog of work will unconsciously lower their bar for a candidate who is enthusiastic, a good cultural fit with the existing team, and technically adequate even if not strong. The bar raiser is structurally independent of the hiring team and has no stake in whether the role gets filled. Their only job is to evaluate whether the candidate would improve the average quality of the engineering org at that company, not just whether the candidate would be useful to this team right now.

The practical implication is that a bar raiser can veto a hire recommendation from a unanimous hiring team. At Amazon, this veto is explicit in the process. At Google and similar companies, it functions as a strong escalation that typically results in the decision being reviewed at a higher level rather than simply overridden. The hiring team is informed of the objection and must either address it with specific counter-evidence from the interview record or accept the block.

What the bar raiser is specifically watching for during the debrief and during the interview if they are conducting a round is whether the candidate’s performance would be consistent with what the company’s best engineers would do. They are not asking whether the candidate would be helpful to this team. They are asking whether the candidate would make the engineering org measurably better. This is a higher bar than adequate and a harder bar to hit when the candidate’s performance was solid but unremarkable.

The specific thing that impresses calibration reviewers in the debrief record is not exceptional technical output in a single round. It is consistency and agency across rounds. A candidate who designed a reasonable architecture, wrote clean and readable code, handled a behavioral question with specific examples that showed genuine judgment, and asked thoughtful questions at the end of each round has given every interviewer something specific and positive to record. The debrief for that candidate resolves quickly and confidently. The debrief for a candidate who had one exceptional system design round, one mediocre coding round with a hint required, and one behavioral round with generic answers is a much harder conversation, even if the technical peak was impressive.

What gets discussed that interviewers never tell you
The debrief surfaces information that never appears in formal feedback, both because companies are cautious about the legal implications of candid rejection communication and because the specific information is often too granular to communicate usefully in a templated rejection message.

The comparison conversation happens in most debriefs. If multiple candidates have been through loops for the same role, the calibration session often includes explicit comparison. A candidate who performed well in isolation may lose to a candidate who performed better on the specific dimensions the team weighted most heavily. This comparison is invisible to the individual candidate and produces a rejection that feels inconsistent with their own assessment of how the interview went.

The team dynamics conversation happens when a candidate has raised an interpersonal concern for any interviewer. This conversation is rarely about anything extreme. It is more often about small signals like the candidate who referred to a previous employer’s engineering team with undisguised contempt, or the candidate who interrupted the interviewer 3vtimes to correct a minor point, or the candidate who answered a question about a past failure with an extended explanation of why the failure was actually caused by other people. None of these things individually justify a rejection on the record. Together they produce a note in the debrief that influences the group’s confidence in the candidate as a teammate.

The level negotiation conversation is explicit and important. The debrief decides not just whether to hire but what level to offer. If the evidence is mixed like strong technical execution but behavioral examples that suggest mid-level scope of ownership then the group will discuss where the candidate falls and may recommend a hire at the lower level with a note that the candidate could be re-leveled after a review period. This conversation is the source of most of the down-level surprises that candidates experience.

What you can do during the interview to shape what gets said
The most useful framing is that your goal in the interview is to give every interviewer something specific and positive to write in their notes. Not impressive in the abstract. Specifically recordable. An interviewer who leaves your session with vivid, detailed, positive memories of specific moments produces a strong hire evaluation. An interviewer who leaves your session feeling generally positive but without specific moments to anchor that feeling produces a lean hire evaluation that is vulnerable in the debrief.

Making your thinking visible is the single most effective way to give interviewers recordable material. When you make a decision something like choosing an approach or selecting a data structure or like framing a behavioral story, try to state the reasoning explicitly. Not because the interviewer does not understand the technical reasoning, but because hearing you articulate it gives them a direct quote to include in their notes. The debrief note for a candidate who says nothing while implementing is inevitably thinner and less confident than the note for a candidate who narrates at the same time.

Managing your scope signals deliberately is the behavioral equivalent. In every round, look for opportunities to demonstrate that you think about the work at the level above the immediate task. In a coding round, this means mentioning observability, edge case handling, and what a production version of this solution would need before you finish the implementation. In a system design round, this means asking about operational requirements before drawing anything. In a behavioral round, this means selecting examples that demonstrate ownership of an outcome rather than execution of a task.

The questions you ask at the end of each round are recorded and discussed in the debrief. Most candidates do not know this. The questions that produce the strongest debrief notes are specific, technically engaged, and reveal genuine curiosity about how the team operates at a deep level. Questions about technology decisions the team made and what they would change, about how production incidents are handled and what the on-call structure looks like, about how the team makes architectural decisions when there is not an obvious right answer — these signal seniority and genuine interest. Questions about vacation policy and remote flexibility signal that the candidate’s primary evaluation of the role is not technical fit.

A note on finding the company-specific version of this
The debrief process at a Series B startup interviewing for a senior engineer looks meaningfully different from the debrief at Google interviewing for an L5. The number of interviewers, the weight of the bar raiser function, the formality of the voting system, and the specific behavioral competencies being evaluated vary substantially across companies and levels.

Understanding the specific process at your target company before your loop is worth the research time. What questions the company explicitly evaluates in behavioral rounds, what their calibration criteria at each level look like, and what past candidates have experienced in the debrief communication are all out there if you do your connecting the dots things from a combination of Glassdoor, Blind, and company-specific interview data. For the technical side of this, PracHub is useful specifically for the question patterns and follow-up probes that a given company’s interviewers have been using, which tells you what specific dimensions the interviewers are collecting evidence on and therefore what the debrief will be evaluating.

The offer decision is not made in your interview. It is made in a room you are not in, by people who are working from written notes of the 45 minutes they spent with you. The quality of those notes like how much specific, positive, level-appropriate evidence they contain, is almost entirely determined by choices you make during the interview itself.

Giving interviewers something specific and recordable to write down is not the same thing as performing. It is communicating. It is making the work visible instead of just producing correct output quietly. Engineers who are outstanding at their jobs but poor at making their thinking visible will consistently underperform in interviews relative to their actual capability, not because the process is unfair but because the process is measuring something real: the ability to work transparently in a collaborative environment where other people need to understand what you are doing and why.

The debrief is not adversarial. The people in that room are trying to reach the most accurate conclusion they can with the evidence they have. Give them evidence that is accurate, specific, and at the right level of scope, and the conversation resolves in your favor.

I Have Reviewed Over 400 Resumes for Tech roles. Here Is What Actually Gets You the Phone Screen

Emily Woods — Sat, 30 May 2026 19:01:13 +0000

The gap between candidates who get callbacks and candidates who get silence has almost nothing to do with how much experience they have.

Short Answer: Your resume is not being read but being scanned for approximately 25 seconds by someone who is already behind on their real work and is looking for a reason to close the tab, not open a calendar invite. Most resumes that land in a recruiter or hiring manager’s queue fail not because the candidate is unqualified but because the document was written as a career biography instead of a targeted filtering instrument. A resume has exactly one job: to create enough credibility in a specific technical area that someone schedules 30 minutes to find out more. The candidates who get callbacks are almost never the ones with the most experience. They are the ones whose resumes are the most precise match, in vocabulary and in demonstrated impact, to the specific role they are applying for. Everything else is noise.

What actually happens when your resume lands
Most candidates imagine their resume landing in an inbox, getting opened, and receiving careful attention from a thoughtful human being who is genuinely trying to assess their potential. This is almost never what happens.

In a high-volume hiring environment and in 2026, every hiring environment is high-volume because the supply of laid-off engineers has significantly outpaced the supply of open roles, a recruiter working a standard technical requisition is processing somewhere between 80 and 200 applications per week for each open role. They have a stack of other requisitions running simultaneously. They have sourcing targets, pipeline metrics, and screening calls to schedule. The resume review window for any individual candidate is not the 10 minutes you hoped for. It is closer to 20 to 30 seconds on the initial pass.

In those 20 to 30 seconds, the reviewer is doing something closer to pattern matching than reading. They are scanning for signals that answer three implicit questions, and if they do not find those signals immediately, they move to the next application. The signals are not hidden in the body of your paragraph-style job descriptions. They need to be visible at a glance.

I know this because I have been on both sides of the process. I have submitted resumes that received no response despite being genuinely qualified for the role, and I have reviewed applications as part of hiring loops and watched myself make the same fast, imperfect decisions I know recruiters are making when they look at mine. The process is imperfect on both sides, and understanding that is the starting point for working within it rather than against it.

The three questions every reviewer is unconsciously answering
When a recruiter or hiring manager opens a resume on an initial pass, they are answering three questions. Not consciously, but structurally. These questions shape everything about how the document should be written.

The first question is whether you have done the thing they need done. This sounds obvious, but it is the question that most resumes fail. A resume filled with generic action verbs and broad technology lists does not answer this question. If the role requires experience building distributed data pipelines, the resume needs to say, explicitly and near the top of the relevant role, that you built distributed data pipelines and what scale they operated at. The reviewer should not have to infer this from adjacent technologies or general-sounding project descriptions.

The second question is whether anyone else has believed you were good at this. The proxy for this is the company names and titles on your resume, but it extends to the results attached to your work. If you list a project but provide no outcome, the reviewer has no signal about whether the project succeeded or whether it was abandoned. Impact statements are not optional decoration. They are the evidence that answers this question.

The third question is whether you are a credible match for the level they are hiring. This is where level-appropriate language and scope matter enormously. A resume that describes highly autonomous technical decision-making, cross-functional influence, and system-wide architectural ownership reads as a senior candidate. A resume that describes executing tickets and shipping features reads as a junior or mid-level candidate regardless of how many years are listed. The language of scope tells the reviewer what level you are, faster and more reliably than the number of years in your header.

The format problem nobody talks about
Before any of the content decisions matter, there is a format problem that eliminates a significant percentage of applications before a human ever sees them.

Most large tech companies and a growing number of mid-sized companies use Applicant Tracking Systems to process inbound applications. The ATS parses your resume into a structured database record. It extracts your name, contact information, job titles, dates, company names, and skills. It then runs keyword matching against the job description to produce a relevance score. Resumes that score below a threshold are often never surfaced to a human reviewer at all.

The implications of this are specific. PDFs that were generated from design tools like Canva or Figma often fail ATS parsing because the text layers are not machine-readable. Multi-column layouts frequently parse in the wrong order, producing incoherent extracted text. Tables and text boxes cause similar extraction failures. Graphics, icons, and headshot photos consume parsing budget without contributing any parseable content.

The format that parses most reliably is also the least visually impressive: a single-column, left-aligned document in a standard font, generated from a word processor or LaTeX, with no tables, no text boxes, and no graphics. This is not what most resume templates sold online look like, which is part of why so many applications disappear silently.

The keyword matching layer of the ATS is a separate problem from the parsing layer. Once your resume is correctly parsed, the system looks for vocabulary overlap between your document and the job description. This is not a sophisticated semantic analysis. It is largely literal string matching and close variants. If the job description says distributed systems and your resume says large-scale infrastructure without using the words distributed systems anywhere in the document, you may score lower than a candidate with less experience who happened to use the exact phrase.

The practical implication of this is that tailoring your resume to each application is not optional. It is the minimum bar for having your document seen by a human at all.

Why the tailoring feels impossible and how to make it tractable
The standard advice is to tailor your resume for every application, and the standard response to that advice is that it is impractical when you are applying to thirty roles simultaneously. Both of these things are true at the same time, and the resolution is not to choose one over the other but to change the architecture of the process.

The approach I use, and that I have seen work consistently, is to maintain a master document that contains every experience, project, result, and technology you might conceivably reference in any application. This document is not your resume. It is a raw material inventory. From this inventory, you build targeted versions for each application by selecting and ordering the entries that are most relevant to the specific role.

In practice, this means you maintain approximately three to five resume variants, not thirty. A backend systems variant that leads with distributed infrastructure work, a data engineering variant that leads with pipeline and warehouse experience, a full-stack variant that leads with product-facing features, and so on. When a specific role has unusual requirements that do not fit neatly into a variant, you make targeted adjustments to the closest variant rather than rebuilding from scratch.

The additional tailoring step for each application is keyword alignment. Before submitting any application, read the job description carefully and note any specific technical terms, frameworks, or domain vocabulary that appears multiple times. Then scan your resume for whether those exact terms appear. If you have the relevant experience and the vocabulary is not in your document, add it. This is not dishonest. It is translating your real experience into the vocabulary the reviewer is searching for.

The anatomy of a resume bullet that actually works
The single most impactful change most candidates can make to their resume is rewriting their job description bullets to follow a consistent formula: action, system, scale, and outcome.

Most resume bullets are written in one of two broken formats. The first is the responsibility dump: a list of things the person was supposed to do in the role, written in present tense or with responsibility-oriented language. The second is the vague achievement: a claim of impact without enough specificity to evaluate it.

A bullet written in the action-system-scale-outcome format contains a specific active verb describing what you did, the system or component you did it to or built, the operational scale or complexity of the context, and the measurable result. Each element does specific work. The verb establishes agency. The system establishes technical domain. The scale establishes the seniority-appropriateness of the work. The outcome establishes that the work mattered.

A concrete example: a bullet that reads designed caching layer is missing three of the four elements. A bullet that reads designed and implemented a Redis cache-aside layer for the product catalog service, reducing average API latency from 340ms to 28ms and cutting database read load by 65% at 12,000 requests per second contains all four. The second version answers the three unconscious reviewer questions. The first one answers none of them.

The outcome element is the one that candidates most consistently omit, usually because they genuinely do not remember the numbers or were never told them. If you do not know the exact metric, use a reasonable estimate with an explicit qualifier. Approximately, roughly, and estimated all signal honesty rather than precision fabrication, and a reasonable estimate is significantly more useful to a reviewer than no number at all.

The skills section is usually doing the opposite of what you intend
The skills section of most technical resumes is a long, comma-separated list of every technology, language, framework, and tool the candidate has ever encountered. The implicit theory behind this is that more coverage means more keyword matching, which means a higher ATS score and a broader pool of roles you are viable for.

The problem with this theory is that it ignores the reviewer experience on the other side. A skills section that lists 45 technologies provides no signal about depth. It reads as a keyword stuffing attempt rather than a genuine representation of capability. Experienced reviewers — the hiring managers and senior engineers who do technical resume screens — have a strongly negative reaction to this and will often use it as a reason to reject a candidate for a senior role on the grounds that someone trying to appear qualified in 45 different areas is probably not deep in any of them.

A more effective approach is to organize skills by category and signal depth within each category by the specificity of what you list. Listing Python is universal and tells the reviewer nothing. Listing Python with specific mention of async frameworks, type annotation systems, and profiling tools tells the reviewer something about how you actually use the language. The details signal depth more reliably than the length of the list.

Technologies you learned in a single tutorial, used once years ago, or know only superficially should be removed entirely. If an interviewer asks you to walk through something you listed and you cannot do it coherently, you have damaged your credibility far more than the line item was worth.

The projects section: when it helps and when it actively hurts you
For early-career candidates with limited professional experience, a projects section is often the most important part of the resume. For mid-level and senior candidates with five or more years of professional work, a projects section is usually unnecessary and sometimes harmful.

The reason it can be harmful for experienced candidates is that it shifts the apparent center of gravity of your resume away from your professional work. If a reviewer sees five years of professional experience and then a projects section below it, the implicit message is that the professional work was not sufficient to represent your full capability. That is the opposite of the message you want to send.

The exception is when you have a side project with genuine scale or usage that is directly relevant to the role. A production-deployed open-source library with active GitHub stars and users, a tool that processes real-world data at a meaningful scale, a published API with documented external adoption, these are worth including because they represent demonstrated real-world impact outside of a controlled employment environment. A tutorial project, a bootcamp assignment, or a local CRUD application that was never deployed should not appear on a mid-level or senior resume regardless of how technically interesting it was to build.

The referral reality
Everything in this article is about optimizing your resume as a document. The honest follow-up to all of it is that a warm referral from a current employee bypasses most of this process entirely.

At most large tech companies, employee referrals go directly to a recruiter’s attention queue, skip the ATS keyword filtering, and receive a human review on the first pass. They carry implicit credibility because a current employee has staked their internal reputation on the recommendation. The conversion rate from referred application to phone screen is significantly higher than from a cold application, at some companies by an order of magnitude.

If you have a connection at a company you are targeting a former colleague, a university contact, someone you met at a conference or in an online community reaching out and asking for a referral is worth more than any resume optimization. The conversation for this does not need to be elaborate. A brief message explaining that you are applying for a specific role, that you thought your background was a strong match, and that you were wondering if they would be comfortable submitting a referral is sufficient. Most people will say yes if they know you even moderately well, because the referral bonus programs at most large tech companies provide a material incentive to do so.

The part of the job search that feels the most uncomfortable reaching out to people you know and asking for help is also consistently the highest-ROI activity in the process.

What I watch candidates get wrong the most
Having reviewed applications across a range of roles and levels, the mistake I see most frequently is not skills gaps or format problems. It is scope mismatch between the resume and the role.

Candidates applying for senior or staff roles often submit resumes that read at a mid-level scope: well-executed individual work, clearly described, with good results. The resume is accurate. The work it describes is real. But it does not demonstrate the ownership of ambiguous problems, the cross-functional influence, or the system-wide architectural thinking that a senior or staff reviewer is looking for.

The inverse is also common: candidates applying for mid-level roles who write their resumes at a staff-level scope, which makes the reviewer skeptical that the experience is real or makes them worry the candidate will be bored and leave quickly.

Before submitting any application, read the job description looking specifically at the scope language: the seniority indicators embedded in the responsibilities section. Then read your resume and check whether the scope signals in your bullets match the scope signals in the job description. If they do not, adjust. This is not about misrepresenting your experience. It is about translating the scope of your actual work into the vocabulary that matches where you are applying.

A note on where to find out what companies actually want
The job description tells you what the company is officially looking for. It tells you very little about what the interview process actually tests, what the team is specifically trying to solve for, or what the hiring bar looks like in practice compared to the stated requirements.

For that information, the sources that have consistently been most useful to me are Blind and Glassdoor for general impressions, and for technical role preparation specifically, PracHub for understanding the actual question patterns and evaluation criteria companies use at specific levels. Knowing that a company’s senior engineering bar emphasizes operational decision-making over raw algorithmic speed, for example, is information that should influence not just how you interview but how you position your experience on your resume before you apply.

The candidates who are most effective at moving through the process efficiently are the ones who treat the resume, the application, and the interview prep as connected parts of the same calibration exercise rather than separate tasks. Your resume gets you the call. The call confirms the fit. The loop confirms the level. All three are easier when you know in advance what each stage is actually optimized to find.

The resume is a filtering instrument. It is optimized when it answers three questions clearly in 25 seconds: have you done this, did it matter, and are you the right level. Everything else i.e. the design, the length debates, the choice of font is secondary to those three answers.

Tailor the vocabulary to the job description. Quantify the outcomes even approximately. Remove the technologies you cannot speak to in an interview. Write at the scope level of the role you are targeting, not the role you came from. And when there is any path to a referral, take it before submitting the cold application.

The process is imperfect and frequently unfair. The volume problem is real and it disadvantages excellent candidates every day. But the optimization is tractable, and the gap between a resume that gets ignored and a resume that gets a callback is almost never the gap between a good engineer and a great one. It is almost always the gap between a document that answered the three questions and one that did not.

I Left $40,000 on the Table in My First Tech Offer. Here Is Exactly What I Do Now

Emily Woods — Fri, 29 May 2026 00:03:55 +0000

The fear of negotiating a job offer is costing you more than a year of savings. A specific, tested framework for the 48 hours after the offer call.

When my first real tech offer came in, I said yes within the hour. I was so relieved to have the job that the idea of asking for more money felt like tempting fate. That was a $40,000 mistake measured over the two year tenure, because every raise, bonus, and equity refresh I received for the next two years was calculated as a percentage of that initial number. The offer is not a gift. It is an opening bid. Companies expect negotiation and they build room for it into their budget before they call you. The candidates who do not negotiate are not being humble they are subsidizing the ones who do. What follows is the exact framework I now use every time I receive an offer, including what to say, when to say it, what to never say, and how to handle the specific tactics recruiters use to close you fast.

The $40,000 mistake I made at 23
When I moved to New York, I had been through 23 interviews over about 14 months before I got an offer I was genuinely excited about. It came from a fintech startup in Midtown. The recruiter called me on a Thursday afternoon and told me the base salary. It was more than I had ever made. It was more than my mother had ever made. My immediate reaction was gratitude, and I said yes before she finished the sentence.

That number anchored everything for the next 2 years. My annual raise was calculated against it. My bonus target was a percentage of it. When I eventually got a competing offer and used it to negotiate a higher salary at a new company, the gap between what I was making and what the market was paying became visible in a way that made me genuinely angry at myself for not understanding the structure of the game at the start.

I have since gone through 8 more formal offer negotiations. I have also coached a significant number of friends through theirs. The pattern is nearly identical across all of them: the candidates who negotiate get more money, the process takes two to five business days longer than the people who skip it, and nobody has ever had an offer rescinded because they negotiated professionally. The fear that stops people from doing this is almost entirely unfounded.

Why you are afraid to negotiate and why that fear is irrational
The primary emotion most people feel when an offer arrives is relief. If the search has been long and exhausting and in 2026, most searches are the offer feels like the finish line. Asking for more money after crossing the finish line feels ungrateful, risky, and possibly dangerous.

This framing is wrong on every level.

Companies do not make offers to candidates they intend to walk away from. By the time the recruiter calls you, the hiring manager has already decided they want you. The calibration committee has already scored you. Legal has already reviewed the terms. The recruiter has a budget range and they are instructed to open at or near the bottom of it. This is not cynical. It is just how compensation planning works. The budget exists. The room exists. The question is only whether you ask for it.

The other piece of this that most candidates miss: if you accept the first number without any pushback, you have provided the company with information. You have told them that you either did not know you could negotiate or did not feel confident enough to do it. Neither of those signals reflects especially well on your sense of your own market value, which matters in an industry where your compensation trajectory is often tightly linked to the perception of how much others want you.

Negotiating does not make you greedy. It makes you someone who understands the market. Those are different things.

The 48 hours after the call

**
When a recruiter calls with a verbal offer, the single most important thing you can do in that moment is say nothing about the number itself. You acknowledge the offer, you express genuine enthusiasm for the role, and you ask for time.

Something like: I am really excited about this and I want to give it the thought it deserves. Can you send over the written details and give me a few days to review everything?

Every recruiter will say yes to this. Every single one. If they push back or try to get you to commit on the call, that is a yellow flag about the company’s culture, not a reason to capitulate.

Once you have the written offer and a few days, do not spend that time agonizing. Spend it gathering two pieces of information: what the market rate for this role actually is at this level and location, and whether you have any competing offers or near-term competing processes you can reference.

For market rate: Levels.fyi for total compensation at larger tech companies, LinkedIn Salary, and Glassdoor for smaller companies. Get familiar not just with the base salary range but the full comp picture like base, equity, signing bonus, annual bonus target because that is what you will be negotiating across.

For competing leverage: this is the single most powerful variable in any negotiation, and it has nothing to do with your performance in the interview. If you have a competing offer, you have leverage. If you have active processes at other companies that could plausibly produce an offer in the next two to four weeks, you have softer leverage. If you have neither, you are negotiating on the basis of market data alone, which still works but requires a different approach.

The counter

When you come back with your counter, do it in writing over email rather than on a phone call. There are two reasons for this. First, it gives you time to construct your reasoning carefully rather than responding to real-time pressure. Second, it creates a paper trail that protects both sides.

The structure of the counter email should be short and contain four things: a restatement of your excitement about the role, a specific counter number or range, a one-sentence rationale, and a collaborative close.

The rationale does not need to be elaborate. Citing market rate data from Levels.fyi for comparable roles at this level, with my current comp and a competing process I have active, a base of X feels more appropriate. That is enough. You do not need to write a brief. You do not need to explain your expenses, your student loans, or the cost of living in your city. None of that is relevant to the company and including it weakens the counter by making it emotional rather than market-based.

The specific number you ask for matters. Ask for more than you expect to get, but not so far above the market rate that it signals you have not done your research. A reasonable counter is typically ten to fifteen percent above the initial offer for a base salary, or a request to move to the top of the disclosed range if the company gave you a range. For equity, the lever is usually the number of shares or units, not the vesting schedule, since vesting schedules are often standardized.

If the company comes back with less than your counter but more than the initial offer, you have successfully negotiated. Most processes end here. If they come back at the same initial number with a statement that it is firm, you have two options: accept with a request to revisit at your six-month review, or attempt one more lever.

The levers most people do not use
Base salary is the most visible number but often not the most negotiable one. There are several components of an offer that have more flexibility and less visibility than base pay.

Signing bonus
This is frequently the easiest lever because it is a one-time cost to the company rather than a recurring expense. If they cannot move the base, a signing bonus of ten to twenty thousand dollars is a reasonable ask, particularly if you are leaving unvested equity at your current employer.

Equity
At growth-stage and public tech companies, the equity component often has more room than the base. If they gave you a range on the equity grant, you can ask to be positioned at the top of the range. If they gave you a specific number, you can ask for a refresh schedule that front-loads the vesting rather than the standard cliff structure.

Start date
This costs the company very little and occasionally costs you a meaningful amount if you have unvested equity that will cliff before you leave. Asking for a start date four to six weeks out is normal and expected.

Title
At companies with defined leveling systems, a title one band up can have compounding effects on your compensation trajectory that dwarf the immediate raise. If you were told during the process that you were being evaluated for two levels and they came in at the lower one, it is appropriate to ask whether there is flexibility on the level based on your interview performance.

The competing offer play
If you have a competing offer, use it. This is not a negotiation tactic but an honest information about your market value, and companies expect you to share it.

The way to use it is specific: you name the company if you are comfortable doing so, you state the total comp package, and you say that you prefer this role and would like to make it work at a comparable level. You are not threatening to leave. You are just providing market data in the form that companies find most credible, which is a real offer from a real competitor.

A few things to know about this. Companies will sometimes call your bluff, particularly if the competing offer is from a company in a different tier or a meaningfully different role. Let’s say, If you are negotiating at a Staff Software Engineer level at Stripe and your competing offer is from a Series B startup with significant equity risk, a sophisticated recruiter will factor in that the risk profiles are different. Be honest about the comparison and let them respond.

What you should never do is fabricate a competing offer or exaggerate one. Recruiters talk to each other. Offers can be verified. The downside risk of getting caught fabricating is dramatically larger than any salary upside, and it can cost you the offer entirely.

The exploding offer

Occasionally, a recruiter will tell you that the offer expires in 24 or 48 hours. This is a pressure tactic, and it almost never reflects a real operational constraint. Companies do not lose their headcount approval because a candidate took four days to decide. What they lose is psychological control of the conversation.

If you receive a very short deadline, acknowledge it and ask for an extension with a specific reason. Something like: I want to make this decision carefully and I have a call with my family this weekend that I need to include in that process. Is it possible to extend to Monday? In almost every case, they will extend. If they do not, you have learned something meaningful about how the company operates that is worth weighing before you accept.

What does not work
Citing your personal financial situation does not work. Citing what you were making at your last job does not work unless it supports a higher ask. Negotiating emotionally expressing that you feel the offer is insulting or unfair almost never works and frequently damages the relationship before it starts.

Being aggressive about equity at a late-stage public company does not work the way it does at an early-stage private one. At a public company, the equity is essentially cash with a vesting delay. At an early-stage startup, it is a lottery ticket. Treat them differently in negotiation.

And the tactic that backfires most often: asking for time repeatedly without eventually committing. If you have asked for two extensions and still have not responded, you are signaling uncertainty about the role itself, which makes the company nervous. Negotiate quickly, negotiate clearly, and commit when the process has run its course.

The compounding effect
The reason I care so much about this is not the immediate dollar amount. It is the compounding effect on everything that comes after it.

Your first-year performance review will reference your current compensation when determining your raise band. Your promotion will often come with a percentage increase on top of your current base. When you eventually negotiate your next offer at a different company, you will be asked what you are currently making in jurisdictions where that is legal, and even where it is not, your sense of your own market value will be shaped by the number you accepted the last time.

The $40,000 I left on the table at 23 compounded into something closer to $90,000 over the following five years when you account for the raises and equity refreshes that were calculated against it. That is not hypothetical math. I can trace it across my own compensation history.

Negotiation is not optional if you want to build real financial traction in this industry. It is a core skill, and like most core skills, it gets significantly easier the second and third time you do it.

What I use to prepare
The market rate piece of this knowing what the role actually pays at the specific company and level is the most important input into any negotiation. The more precisely you know that number, the more confident your counter will be.

For company-specific compensation data, Levels.fyi is the most reliable source for larger tech companies. For smaller companies and startups, Glassdoor and Blind give you a rougher picture. Where I have found PracHub useful is in calibrating my sense of which level a company was actually interviewing me at versus which one they offered because the interview experience and the offer level do not always match, and understanding the discrepancy is often the starting point for a meaningful conversation about whether the leveling is right.

Knowing your level, knowing the market rate for that level, and knowing where the company typically lands relative to market on each comp component is the combination that turns a vague counter into a specific, well-reasoned one.

Final thoughts

The offer call is not the end of the interview. It is the beginning of a different kind of conversation. Every company you will ever negotiate with has already decided it wants you by the time that call happens. The budget exists. The range exists. The question is only whether you are going to be the person who asks for their share of it.

Say thank you, then ask for time. Do your research. Come back with a specific number and a one-sentence rationale. Repeat once if necessary. Then commit.

That is the whole system. It takes 2–5 business days. The median outcome, in my experience and across the people I have coached through it, is somewhere between eight and twenty thousand dollars more per year than the initial offer. Over a five-year tenure, that number is not trivial.

After failing 23 times, I am sharing How I Actually Prepare for a Tech Interview Every Single Time Now.

Emily Woods — Mon, 25 May 2026 20:47:33 +0000

Not the sanitized version you read on LinkedIn. The real system, I am sharing the exact schedule, the anxiety in between, the sequence I follow from zero to offer.

Most interview prep advice is written by people who either never failed or have conveniently forgotten what it felt like to fail badly. As I have shared multiple times in my previous blogs that I failed 23 times before I cracked the process. What I built out of those failures is not a list of resources. It is a repeatable system with specific phases, daily time budgets, decision rules for when to move on, and a clear protocol for the final 72 hours before a loop. It works for me and It has worked for a number of people I have coached through it. But none of it resembles the advice that gets posted to the top of engineering subreddits, because that advice is optimized for upvotes, not for outcomes.

Why most prep advice fails you before you even start
The internet is full of interview prep advice. There are curated lists of the 75 must-solve LeetCode problems. There are YouTube channels dedicated to mock system design sessions. There are courses promising to turn you into a senior engineer in eight weeks. If information alone were enough, nobody would be failing technical loops.

The problem is not access to information. The problem is that most people approach interview prep the same way they approach a research project: they accumulate knowledge passively and assume that understanding something conceptually is equivalent to being able to produce it under pressure. But it is not as the cognitive demand of a live technical interview is fundamentally different from the cognitive demand of reading a blog post about the same topic. In a live interview, you are generating instead of consuming like basically you are talking and typing at the same time. You have a stranger watching you work. You have a timer running in the background of your head even when there is no visible timer on the screen. None of your accumulated knowledge is useful unless you have trained your brain to access it reliably under those conditions.

The second failure mode is treating prep as a binary: either you are preparing or you are not. People tend to go from zero preparation to intense cramming the week before an interview, which is exactly backwards. The skills that matter in a technical interview are clean problem decomposition, fast pattern recognition, confident architectural narration and those things can not be absorbed in 4–5 days. They are built over months of low-intensity consistent practice, the same way you build cardiovascular fitness. A week of intense running before a 10K does not substitute for months of regular training. The week before an interview should be light review for you.

The third failure mode, and the one I see most often, is practicing in the wrong format. Solving LeetCode problems silently on your laptop is not interview practice. It is homework. An interview requires you to simultaneously think, communicate your thinking out loud, write code, field clarifying questions, handle follow-up constraints the interviewer introduces mid-problem, and maintain composure when your first approach hits a dead end. If you have never practiced all of those things at the same time, you will struggle to do them under pressure even if you technically know the material.

What follows is the actual system I use. It is organized into phases. Each phase has a specific goal, a recommended time allocation, and clear signals for when you have done enough and should move forward.

Phase 0: The Inventory (Day 1, before anything else)
Before I touch a single LeetCode problem or open a system design resource, I spend half a day doing a complete honest inventory of where I actually am.

I open a blank document and work through four categories.

Technical depth. I list every major topic area that appears in technical interviews: arrays and strings, linked lists, trees and graphs, dynamic programming, system design fundamentals, concurrency and parallelism, database design, distributed systems, API design, object-oriented design.

For each one, I write a single word: Strong, Shaky, or Blank. Strong means I could solve a medium-difficulty problem in this area right now without looking anything up and explain my solution clearly. Shaky means I have seen this material before and would recognize patterns but would struggle to produce clean working code under time pressure. Blank means I would need to start from the beginning. I am honest about this even when the honest answer is embarrassing, because a false inventory leads to wasted prep time.

Behavioral story bank. I list every major project I have worked on in the past four years and for each one I write down: the specific technical challenge I personally owned, the specific decision I made and why, the measurable outcome, and any cross-functional conflict or ambiguity I had to navigate. I do not try to construct polished STAR answers at this stage. I am just surfacing raw material. If I have worked on ten major projects and cannot identify a specific personal technical decision from at least six of them, my behavioral prep is starting from close to zero regardless of how long I have been in the industry.

Target company research. I look up everything publicly available about the interview process at my target companies. I check Glassdoor, Blind, and Levels.fyi for recent interview reports. I look at what PracHub surfaces as the company-specific question patterns. I am trying to answer 3 questions: what is the difficulty distribution of their coding rounds, what is the scope and depth of their system design sessions, and how much weight does the behavioral round carry relative to the technical rounds. The answers vary dramatically across companies and dramatically change what I prioritize in my prep.

Time budget. I look at my calendar and figure out how many weeks I have before my target interview, and how many hours per week I can realistically commit. I divide the available hours across the phases I will describe below. If I discover I have 2 weeks and 4 hours per week, I adjust the plan accordingly rather than pretending I will somehow find twenty hours a week I do not actually have.

The output of Phase 0 is my behavioral material, my target company intelligence, and my weekly time budget. This document is what I return to every few days throughout prep to check whether I am actually moving in the right direction.

Phase 1: Foundation Repair (Weeks 1–2)
Phase 1 is about clearing the Blank and shoring up the Shaky items from my inventory before I touch anything else.

The specific sequence matters. I start with the topic areas that are foundational dependencies for everything else: arrays and strings, hash maps and sets, linked lists, trees, and basic graph traversal. These topics appear in roughly 70% of coding questions and underpin the more complex patterns in later phases. If these are weak, working on dynamic programming or advanced graph algorithms is premature and inefficient, because those problems build on pattern recognition that requires the fundamentals to be automatic.

Within each topic area, my practice loop is not simply to solve problems. It is to solve, explain, and diagnose.

After solving any problem, I narrate the full solution out loud as if I am explaining it to an interviewer who cannot see my screen. I describe the data structure I chose and why it was appropriate for this specific problem. I describe the time and space complexity and explain what constraint is driving each. I describe the edge cases I tested and why they are the ones that matter. If I cannot narrate the solution cleanly after solving it, I go back and solve it again the next day without looking at my previous work.

When I get a problem wrong or need more than thirty minutes to solve it, I do a specific diagnosis rather than just reviewing the answer. I write down one of three failure modes: I did not recognize the pattern, I recognized the pattern but made an implementation error, or I recognized the pattern and implemented it correctly but could not explain it clearly. Each failure mode has a different remedy. Pattern recognition failures mean I need more exposure to that category. Implementation errors usually mean I am thinking correctly but have a specific syntax or indexing habit that is producing bugs. Explanation failures mean my conceptual understanding is actually shallower than my solve rate suggests.

I keep a daily log in a simple spreadsheet. Columns are: date, problem name and difficulty, time taken, result (solved independently, solved with hint, did not solve), failure mode if applicable, and a one-sentence note of the key insight. This log is not for anyone else. It is for me, so I can look at it after two weeks and see whether I am improving, plateauing, or going in circles.

Phase 2: Pattern Saturation (Weeks 3–4)
Once the foundational topics are solid, I shift to pattern saturation. The goal is to develop the ability to look at a problem and immediately identify the category of approach it belongs to, without needing to work through the full brute force first.

The patterns I specifically focus on are the ones that appear most frequently in the difficulty range that matters: medium to hard. These include the two-pointer approach and its many variants, the sliding window technique, binary search on the answer space (not just on sorted arrays), BFS and DFS with state tracking, prefix sums, monotonic stack and queue applications, and topological sort for dependency problems. Within dynamic programming, I focus on the subset of problems that appear in actual interviews rather than the full academic taxonomy: 1D linear DP, grid DP, interval DP, and knapsack variants.

For each pattern, I do not just practice problems instead I try to write a pattern card. A pattern card is a half-page document that describes the trigger conditions for the pattern (what properties of the problem indicate this approach is worth trying), the standard template implementation, the common variations and how they modify the template, and the typical time and space complexity. Writing these cards from scratch rather than copying them from the internet forces active encoding. I have a folder of about twenty-five pattern cards that I review every three days during this phase.

The target for Phase 2 is that when I see a new medium-difficulty problem from any of these categories, I can identify the applicable pattern within the first two minutes of reading the prompt. I test myself on this explicitly: I read the problem, set a two-minute timer, and write down just the pattern name and the key data structure before looking at anything else. Over the course of two weeks, the time it takes me to pattern-match should compress noticeably.

Phase 3: System Design Depth (Weeks 3–5, overlapping with Phase 2)
I run system design prep in parallel with pattern saturation because they draw on different cognitive resources and the overlap prevents burnout from doing the same type of practice for too many consecutive hours.

My system design prep has 3 layers.

Write on Medium
The first layer is building blocks. I spend the first week making sure I have a deep, not superficial, understanding of the core components that appear in almost every system design interview: load balancers (Layer 4 vs. Layer 7, consistent hashing for session affinity), caching (cache-aside vs. write-through vs. write-back, eviction policies and when each breaks down), SQL vs. NoSQL databases (what ACID actually means and when you trade it away, horizontal sharding strategies and their specific failure modes), message queues (Kafka vs. RabbitMQ vs. SQS and what properties of the workload determine which you choose), and CDNs (pull vs. push origins, cache invalidation tradeoffs). For each building block, I want to be able to describe not just what it does but where it fails and what the operational cost of running it is.

The second layer is framework practice. I use a consistent structure for working through any design problem: establish the scale and constraints before drawing anything, identify the core read and write paths separately, design the data model before designing the API, identify the bottleneck in each path and address it explicitly, and handle failure modes and operational concerns in a dedicated section at the end. Practicing this framework on a wide variety of prompts builds the muscle memory to structure a design session confidently even when the specific prompt is unfamiliar.

The third layer is company-specific calibration. Different companies test system design very differently. What a Google L5 system design session looks for is genuinely not the same as what a Stripe E4 session looks for. Google tends to go broad and then probe the trade-offs at scale. Stripe tends to focus intensely on reliability, correctness, and what happens when the system is actively failing. Amazon layers in operational concerns and cost frugality in a way that other companies do not. Try to talk to folks at Amazon or specific companies or check on subreddits or blind or prachub specifically for this layer because it will help you with the actual question patterns with each company rather than generic architecture prompts. The difference between knowing general system design and knowing how a specific company tests it is the difference between a decent session and a hire decision.

Phase 4: Mock Loops (Week 5 onward, and every week until the interview)
Mock interviews are where most candidates underinvest, and it is the single most expensive mistake in the entire prep process.

Practicing alone is useful. It is not sufficient. The specific stressor that makes technical interviews hard is not the material. It is the performance pressure of producing in front of another person who is evaluating you. That pressure affects your working memory, your pattern recognition speed, and your ability to hold a thought while simultaneously typing and narrating. The only way to reduce the impact of that pressure is to practice under that pressure repeatedly until it becomes familiar.

I schedule at least 2 mock coding sessions and one mock system design session per week during Phase 4. My preference is to do these with peers who are also actively interviewing, because they are calibrated to the current difficulty bar and have genuine motivation to give useful feedback. When peer mocks are not available, I use structured solo simulation: I set a hard timer, open a problem I have not seen, narrate everything I am doing out loud into a voice memo, and do not pause the timer if I get stuck. Reviewing the voice memo afterward is uncomfortable in the same useful way that watching yourself on video is uncomfortable. You hear the filler words, the moments of silence that reveal where you lost the thread, the times you jumped to code before establishing the approach.

The feedback protocol for mock sessions matters as much as the sessions themselves. I do not ask my mock partner for a general impression. I ask for 4 specific pieces of information:

where my communication dropped (times when I was thinking silently instead of narrating),
whether my approach to each problem was reasonable before I started coding,
whether my code was readable without explanation, and
whether my complexity analysis was accurate.
These four dimensions are roughly what a real interviewer is scoring.

Phase 5: The Final 72 Hours
The 72 hours before an interview loop are not for learning new material. If something is not already in my head by this point, it will not be reliably accessible under pressure. Trying to cram new concepts in the final 72 hours degrades the retrieval of existing knowledge by introducing interference.

What I do in the final 72 hours is calibration and logistics.

On the 3rd day before the interview, I do a light review pass through my pattern cards and my behavioral story document. I am not testing myself, just refreshing. I solve one or two easy problems in the language I will use in the interview, purely to warm up the syntax recall.

On the 2nd day before, I do a single full simulation of a complete interview loop: one coding problem, one system design problem, behavioral narration for three stories. I treat this simulation as close to real as I can make it: same time limits, same format (whiteboard for design, IDE for coding), same narration discipline. After the simulation, I sleep. Deliberately. The research on sleep and memory consolidation is not subtle. Sleeping after a comprehensive review session is significantly better for retention than doing another review session.

On the day before, I do nothing technical. I confirm the logistics: the Zoom link, the time zone, whether there is a specific coding environment they want me to use and whether I have tested it. I eat well. I go for a long walk. The single biggest performance variable in the final 24 hours is physiological, not intellectual.

On the morning of the interview, I have a short warm-up. I solve one easy problem in the language I will be using, just to activate the pattern-matching circuits. I read through one behavioral story. I do not try to review system design components or refresh algorithm patterns. The window is too narrow and the activation cost is too high.

The harder part nobody writes about
Everything above is the mechanical system. The harder part is managing the emotional arc of a multi-week prep process.

Interview prep is psychologically bruising in a way that regular work is not. Regular work gives you constant feedback through shipped features, merged pull requests, and team responses. Interview prep gives you minimal feedback and a lot of silence. You solve problems in isolation. You do not know whether your approach would satisfy a real interviewer. You have no idea whether the company you are targeting has already filled the role internally. The uncertainty is constant, and the only antidote to it is trusting the process enough to keep going.

The specific thing I do to manage this is to measure effort rather than outcomes during the prep phase. I do not try to evaluate how ready I am by asking myself whether I feel ready, because that feeling is almost completely uncorrelated with actual performance. Instead I track concrete process metrics: how many problems I solved this week, whether I completed my scheduled mock sessions, whether I updated my behavioral document. These are the things I control. The outcome of the interview is not something I control, so I do not spend cognitive energy there during prep.

After the interview, I do a structured retrospective regardless of outcome. I write down every question I was asked, my initial reaction to each, where I felt confident and where I struggled, and what I would do differently. If I get an offer, this retrospective is still valuable because it shows me what actually worked, not what I thought was working. If I do not get an offer, the retrospective is the material that makes the next attempt better.

What I actually use
Throughout all five phases, the platform I return to most consistently for company-specific preparation is

For the first three phases, the core tools are free and widely available: LeetCode for coding practice, the NeetCode roadmap as a structured topic guide, Designing Data-Intensive Applications for foundational system design reading, and Glassdoor or Blind for surfacing recent interview reports from real candidates at specific companies.

The one paid tool I use, specifically for the company calibration layer in Phase 3, is prachub. I landed on it not because I was looking for a platform to recommend but because the specific problem it solves mapping real interview questions to specific companies and levels is tedious and time-consuming to do manually from forum posts and Glassdoor reports. Whether that particular problem is worth solving with a tool is a personal call that depends on how much prep time you have and how targeted your company list is. For me, with two or three target companies and a finite prep window, it saved meaningful time during Phase 3. It is not a substitute for knowing the material. It is closer to a study guide that tells you which chapters to prioritize before a specific exam.

If your budget is literally, the manual version works. You compile recent interview reports from Blind and Glassdoor, sort them by recency, look for patterns in the follow-up questions interviewers asked, and use that to weight your study time toward the failure modes that company actually probes. It is slower, but the information is largely there if you are willing to dig.

The system works when you follow all of it, including the parts that feel unnecessary. The inventory matters because it forces honesty. The pattern cards matter because writing them is different from reading them. The mocks matter because solo practice is not representative of the actual task. The final 72 hour protocol matters because most people spend those hours doing the wrong things.

You do not need to be the most technically gifted engineer in the room. You need to be consistently prepared, consistently communicative, and consistent enough in your process that a bad morning or a confusing prompt does not unravel everything you have built. That level of consistency is achievable. It just requires treating preparation as a craft rather than an event.

Roast my approach to solve this question: Coffee Ordering System (Salesforce interview question)

Emily Woods — Thu, 21 May 2026 01:59:06 +0000

I've been practicing system design by turning my solutions into visual diagrams (helps me think + great for review later).

Here's my attempt at the Salesforce Coffee Ordering System question that's been popping up in interviews:

[Infographic attached]

The question asks you to design:
Menu browsing + order placement (pickup/in-store)

Customizations (size, milk, add-ons) with price calculation
Payment processing
Barista queue with status updates (PLACED → IN_PROGRESS → READY)
Real-time status for customers
Scale from 1 store → thousands of stores

What I covered:

Microservices split (Menu, Order, Payment, Notification)
Event-driven architecture with message queue
PostgreSQL for orders, NoSQL for menu (read-heavy + cached)
WebSocket for real-time customer updates
Idempotency keys, retries, dead letter queue, saga pattern

Where I'm unsure:

Should payment be synchronous or async?
Is sharding by storeId enough, or should I also consider time-based partitioning for order history?
How would you handle a barista tablet going offline mid-shift?

Be brutal, what did I miss?

Question source: PracHub. Making more of these if people find them useful. Let me know in comments if you want the link.

Everyone is vibe coding but nobody is maintaining the vibe code.

Emily Woods — Mon, 18 May 2026 01:15:02 +0000

Six months after the AI-generated prototype ships to production, the engineer who wrote zero of it is on call at 3 AM trying to understand it.

Vibe coding is real and it works for what it is. You can describe a goal in plain English and get working software in an hour that would have taken a week to build manually. The demos look incredible. The prototypes are impressive. The problem is that software does not live in the demo. It lives in production, where it degrades, gets extended by new requirements, fails in edge cases that the original prompt never described, and eventually gets handed to an engineer who has to understand what it does and why. The industry right now is extremely good at generating vibe code and almost completely unprepared for the part that comes after.

What vibe coding actually is
Andrej Karpathy coined the term in early 2025 and the internet ran with it. The core idea is simple: instead of writing code manually, you describe what you want in natural language. The model handles the implementation.

You review the output, refine the prompt, iterate quickly, and end up with a working product without touching the actual syntax.

If you have used Cursor with agent mode or Claude Code with a well-structured prompt, you have done this. You describe a feature, the agent reads your codebase, writes the new code, runs the tests, fixes the failures, and opens a pull request. The experience feels like pair programming with someone who types at 400 words per minute and never needs to look up syntax.

For certain categories of work, it is genuinely transformative. Building a proof of concept in a weekend. Generating a test suite for legacy code that has none. Writing the boilerplate for a new microservice when you already know exactly what the interface needs to look like.

The vibe coding evangelists are not wrong about any of that.

The production gap
Here is the thing they are not talking about.

Software in production is not the same object as software in a demo. The demo version works because you gave it a clean prompt, a clear requirement, and a controlled environment. The production version exists inside a system with fifteen years of accumulated decisions, most of which are not in the codebase and are not in any document. They live in the memory of engineers who have already left, in Slack threads from 2021 that nobody archived properly, in the institutional knowledge of why this particular function is written in a way that seems wrong but is actually protecting against a bug in a third party library that broke everyone in 2022.

When a vibe-coded feature gets deployed and then behaves incorrectly in some edge case nobody anticipated, the debugging process requires understanding not just what the code does but why it was structured a certain way. If you did not write it, if you did not make the architectural decisions, if you did not understand the constraints the model was working within, you are going to spend a very long time reading AI-generated code trying to build a mental model of a system you never actually understood.

I have reviewed pull requests in the past few months that were clearly generated by agents, with comments left in by the model that were confident and wrong. The code was syntactically clean. It compiled. Tests passed. It also quietly violated a transaction boundary assumption that the rest of the system depended on. The engineer who submitted it had not caught it because they were reviewing AI output rather than reasoning through the logic themselves. We found it in code review, but only because a senior engineer who had written the original transaction layer happened to review it.

What happens to the junior engineer
Here is the part of this conversation that makes me genuinely uncomfortable.

The fastest path into software engineering has always been: get hired as a junior engineer, get assigned work that is a bit over your head, struggle with it, and slowly build the mental models that turn into competence. You write bad code. You get it back in review with comments. You write it again. Over a year or two of this, you develop an intuition for how systems behave that you cannot get from reading documentation.

Vibe coding is compressing this loop to the point where the learning disappears entirely. A junior engineer who can generate a working feature in three hours from a prompt is not building the intuition that will let them debug that feature when it breaks in six months. They are getting the output without going through the process that would let them understand the output.

Companies are also noticing that vibe coding lets you hire fewer juniors, because one mid level engineer with good prompt skills can ship the volume that used to require two or three people. So the junior positions are shrinking at exactly the moment when junior engineers have access to tools that make them look like mid level engineers from the outside, which makes it easier for companies to justify not hiring as many of them.

The industry is quietly eliminating the apprenticeship layer. In ten years, when the current senior engineers have moved into management or retired, we are going to want to know where the next generation of people who understand systems came from. I do not have a good answer to that question.

What actually changes and what does not
The skill that vibe coding eliminates: translating a clear, well-understood requirement into syntactically correct code. That skill is gone. The model does it better and faster than almost any human.

The skill that vibe coding does not touch: understanding what the requirement should have been before you wrote the prompt. Knowing when the code the model generated is technically correct but contextually dangerous. Debugging a production failure that involves five different services and a race condition that only shows up under load. Making the architectural decision that determines whether your system needs a message broker or whether a simple database trigger would work fine.

Every skill that was already about judgment rather than execution is still about judgment. Vibe coding just eliminated the execution bottleneck, which means judgment is now essentially the entire job.

The MCP piece
Model Context Protocol is the infrastructure layer that is making vibe coding more powerful in 2026. If vibe coding is describing what you want, MCP is giving the model direct access to the tools it needs to execute on that description. The model can now call your internal APIs, query your database, read from your file system, and commit back to your repository, all within a single agentic loop.

This means the scope of what an agent can autonomously handle is expanding significantly. You can now describe a data migration and let the agent write the migration script, test it against a staging database, review the row counts, and flag discrepancies, without a human being in the loop for each step.

That is genuinely useful. It is also genuinely scary if you have not thought carefully about what guardrails your organization needs around what agents are allowed to touch.

The engineers who will be valuable in 2026 and beyond are the ones who understand how to design those guardrails. Who understand what an agent should be allowed to do autonomously versus what requires a human in the review loop. Who can look at an MCP-connected agentic workflow and identify where the failure modes are.

That is a senior engineering skill. It is not a vibe.

I personally feel vibe coding is not a threat to engineers who understand what they are doing. It is a threat to engineers who measure their value in lines of code per day. If you are the person on your team who can debug the system, make the architecture call, and tell the product manager that a feature is going to break something in a way that is not immediately obvious, you are not replaceable by a prompt.

If your main contribution is translating tickets into code with minimal mistakes, the vibe is already coding that part.

If you are looking for structured approach to for technical interviews and want to practice questions that will be asked in your interviews, don’t forget to check out, PracHub. It has updated lists of questions with their follow-ups with company specific options.

I over-engineered the system design and it cost me the offer.

Emily Woods — Sat, 16 May 2026 20:29:36 +0000

Why trying to sound senior by adding complexity is the fastest way to fail a technical interview.

In one of my interview out of 23 I gave last year, I was asked to design a simple notification system for a startup. I wanted to look like a senior engineer, so I started drawing boxes for Kafka clusters, stream processing engines, and multi-region database replication. I thought I was showing depth. In reality, I was showing that I didn’t understand how to solve a problem with the least amount of complexity required. The interviewer didn’t want a system that could handle the traffic of Netflix. They wanted a system that could be built in a week and maintained by 2 people. I learned that senior engineering is all about when to not use tools.

Here’s what they asked
The company was a series B fintech startup in the Flatiron district. The round was system design. The interviewer, a guy named Mark who looked like he hadn’t slept since the series A, gave me a straightforward problem.

“We need a service that sends transactional emails and push notifications,” Mark said. “Things like password resets, order confirmations, and marketing alerts. We have about fifty thousand users right now, and we might double that in a year. How would you build this?”

I had spent the entire weekend reading about distributed systems. I had watched every YouTube video on “How to design Twitter” and “How to scale to a billion users.” I was ready to be a senior architect.

The over-engineered architecture
I didn’t start with the requirements. I started with the buzzwords.

I drew a Kafka cluster right in the middle of the whiteboard. I told Mark that we needed to decouple the producers from the consumers to ensure maximum throughput and durability. I suggested using a stream processing engine like Flink to handle the notification logic because we might want to do real time analytics on the delivery rates.

For the database, I proposed a globally distributed NoSQL store. I argued that as the company expanded internationally, we would need low latency access to user preferences across different regions.

I even suggested breaking the service into four separate microservices: one for the API, one for the email worker, one for the push worker, and one for the analytics aggregator.

I felt great. I looked at the board and saw a masterpiece of modern engineering. I looked at Mark and expected him to be impressed.

He was just staring at the Kafka box with a look of profound exhaustion.

The interviewer’s reality check
Mark asked one question:
“How many engineers do we have to manage this Kafka cluster?”

I didn’t have an answer. I said we could use a managed service.

“Okay,” he said.
“The managed service costs five hundred dollars a month. Our total notification volume is about three thousand messages a day. Most of those are password resets. Do we really need a distributed log for three thousand messages a day?”

I started talking about future scale.
I said we needed to be ready for when we hit a million users.

“If we hit a million users, we’ll have a different set of problems,” Mark replied.

“Right now, we need a system that works tomorrow. You just proposed an architecture that requires three different infrastructure platforms and a dedicated DevOps engineer to keep it running. Can you build this with just the tools we already have?”

I realized then that I had failed. I had ignored the most important constraint in any engineering project: the human cost of maintenance.

What a senior answer actually looks like
A senior engineer doesn’t solve for the scale of a billion users unless they are actually at a company with a billion users. They solve for the requirements they have, with a clear path for when those requirements change.

If I were to do that interview again, my answer would be much shorter and much more boring.

I would start with a simple background job library like Sidekiq or Celery, using the Redis instance the company probably already has. The notification requests go into a queue. A few workers pull from the queue and hit the SendGrid or Twilio API. If the API is down, the worker retries with exponential backoff.

For the data, I would use a single table in the existing Postgres database to store the notification logs and user preferences. No microservices. Just a well structured module within the main application.

This system can handle fifty thousand users without breaking a sweat. It can handle five hundred thousand users with about ten minutes of vertical scaling. It takes one engineer two days to build and requires zero additional infrastructure management.

That is the senior answer. It shows that you value the company’s time and money more than your own desire to play with cool technology.

The lesson
I used to think that Senior Software Engineer was a title given to people who knew the most complex patterns. I was wrong. It is a title given to people who can be trusted not to build complex things when simple things will do.

Complexity is a tax. Every box you draw on a whiteboard is a box that someone has to debug at three in the morning. If you can solve a problem with a simple SQL query and a cron job, you should do that. Only move to the distributed systems and the stream processing when the simple solution literally cannot handle the load anymore.

If you are walking into a system design interview, your goal is not to show off. Your goal is to show that you are a pragmatist.

Final thoughts
I stopped reading about scale and started reading about maintenance. It changed how I approached every interview after that. I stopped trying to sound like an architect and started trying to sound like a colleague. Remember whenever you make mistakes in any of your interview, do not forget that.. keep that mistake in the list, work on it and try not to make the same mistake again.

If you want to practice system design in a way that focuses on these realistic trade offs rather than just drawing boxes, PracHub has real interview questions that specifically test for over-engineering. They provide the constraints that force you to choose the simplest viable solution, which is exactly what top tier engineering teams are looking for.

Are all coding agents ruining the technical roles?

Emily Woods — Fri, 15 May 2026 19:14:23 +0000

AI agents are not replacing senior engineers, but they are absolutely destroying the entry level roles we used to rely on to train them.

Everyone is arguing about whether AI coding agents will replace software engineers. They are missing what is actually happening. Claude Code, Cursor, and Codex are not replacing senior architects. They are replacing the specific, repetitive tasks that we historically assigned to junior engineers, QA testers, and entry level data analysts. The industry is currently hollowing out the bottom of the career ladder. We are getting very good at generating boilerplate code and automated test coverage, but we have no plan for where the next generation of senior engineers is supposed to come from if nobody is allowed to be a junior engineer anymore.

The death of the junior ticket
Five years ago, when we hired a junior backend engineer, we had a specific process for onboarding them. We gave them simple tickets. They would update API endpoints, write unit tests for existing modules, and fix minor bugs that the senior team did not have time to prioritize.

That was how they learned the codebase. They spent a year doing the grunt work, making mistakes in safe areas, and slowly understanding how the system fit together.

Today, those tickets do not exist. Or rather, they exist, but they are not assigned to junior engineers. They are assigned to Claude Code.

If I need unit tests generated for a new service, I do not hand that to a new hire. I point an agent at the directory and get a ninety percent complete test suite in four minutes. If I need a basic CRUD API endpoint added to an existing monolith, Cursor handles it faster than I can write the Jira ticket explaining it to a junior developer.

The economic reality is that paying a junior engineer to spend 3 days figuring out how to write a database migration is no longer justifiable when an agent can draft it in seconds. But without those three days of struggle, that junior engineer never builds the mental models required to become a mid level engineer.

QA is becoming an algorithm
The shift is even more aggressive in Quality Assurance.

Manual QA testing has been dying for a decade, replaced by automated test suites. But writing and maintaining those automated test suites was still a massive human effort. You needed QA engineers who understood Cypress or Selenium to write the integration tests.

Now, agents are perfectly suited for this. You can feed an agent the user story and the frontend code, and it will generate the end-to-end testing scripts. When the UI changes and the tests break, you do not need a QA engineer to spend an hour tracking down the broken selector. The agent reads the error log, looks at the new DOM structure, and fixes the selector automatically.

The role of a QA engineer is shifting from writing tests to reviewing the tests that agents write. But reviewing tests requires a deep understanding of what exactly needs to be tested, which is a senior skill. The entry level QA role, where someone just runs scripts and logs bugs, is evaporating.

Data science and the end of the query monkey
Data science is seeing the exact same hollowing out.

Join The Writer's Circle event
The classic entry level data analyst job was essentially translating business questions into SQL queries. The marketing team would ask for a report on churn rates by demographic, and the junior data analyst would spend the afternoon writing the JOIN statements and formatting the output.

Agents have completely commoditized this. If you have a clean database schema and you give an agent read access, any product manager can type a natural language question and get the SQL query, the execution results, and a generated chart.

The data science jobs that survive are the ones that agents cannot do. Designing the data warehouse architecture. Defining the statistical validity of an A/B test. Figuring out why the business logic in the billing system does not match the data in the event logs. Those are senior problems. The query writing was the training ground, and the training ground is closed.

What happens in five years
This hollowing out creates a massive structural problem for the tech industry.

Right now, companies are enjoying a massive productivity boost. Senior engineers are using agents as force multipliers, doing the work of three people because they no longer have to write boilerplate or manually debug simple errors. Profit margins look incredible because companies are freezing entry level hiring while maintaining output.

But senior engineers do not appear out of thin air. They are junior engineers who were allowed to break things for five years.

If we remove the junior layer of the industry because agents are cheaper, we are cutting off the supply chain of senior talent. In five years, the current senior engineers will move into management or retire, and there will be a massive shortage of mid level engineers who actually understand how to design systems from scratch. You cannot become an architect by just reviewing AI generated code for five years. You have to have felt the pain of maintaining your own bad code.

The value of a software engineer is shifting rapidly. The value used to be in the typing. How fast could you translate a requirement into syntax?

The typing is now free. The value is entirely in the judgment. The value is knowing which requirements are logically impossible. The value is knowing that adding a specific feature will destroy the database throughput. The value is knowing when the AI generated code is technically correct but contextually disastrous.

If you are entering the industry right now, you cannot compete with agents on syntax. You will lose and then you have to compete on context. You have to learn system design, architecture, and business logic faster than any previous generation, because the shallow end of the pool is gone.

If you want to focus on the judgment skills rather than the typing skills, PracHub forces you to practice the architectural trade-offs and edge case detection that agents consistently fail at and all the questions are actually getting ask in interviews.

At the last, I would say the code generation is solved but the thinking is still up to you.