Author: Hilda Holland (page 3 of 11)

The retro opens the way they always do. Someone pulls up the incident timeline. The room goes quiet a beat too long. Then the retellings start.

Maya, the SRE who caught the memory leak at 2 a.m., walks through a cascade: a misconfigured feature flag, a silent rollback failure, a database that started swapping and never stopped. In her version, she’s the protagonist—the one who traced the thread, stayed calm, wrote the runbook mid-incident while everyone else was still hunting for the right dashboard.

Dan, the staff engineer who approved the flag change, tells a different story. In his, the flag was safe. The rollback was tested. The real problem was the monitoring gap nobody had prioritized for three quarters. He’s not the villain; he’s the Cassandra who warned everyone and got ignored.

Priya, the engineering manager, tells a third. Hers is about process: the flag review checklist that was followed but insufficient, the on-call handoff that dropped context, the postmortem template that will now get a new section. In her version, nobody is at fault because the system is at fault, and the system can be fixed with a Jira ticket.

Three people. One incident. Three plots. And the plot that survives the retro—the one that makes it into the postmortem document, gets referenced in next quarter’s planning, shapes who gets promoted and who gets quietly managed out—that plot isn’t the truest one. It’s the one with the best narrative machinery behind it.

Your team’s postmortems, architecture decision records, onboarding docs, even your Slack threads are not neutral artifacts. They are plot generators. They take raw events—a deploy that failed, a decision that dragged on for six weeks, a junior engineer who asked too many questions and then stopped asking any—and turn them into stories. Stories with heroes. Stories with villains. Stories with a moral that justifies whatever the team already wanted to do.

Once a story sets, it becomes the team’s reality. The engineer cast as the bottleneck gets treated as the bottleneck, regardless of what the data says. The incident framed as a one-off gets forgotten until it happens again. The architecture decision recorded as “consensus” gets used to shut down dissent for years.

This is not a metaphor. It’s a description of how organizational memory actually works. And if you can’t read the plots your team is generating, you can’t change them.

§ 1 — The Postmortem as Origin Story

Every postmortem is an origin story. It answers: how did we get here? But the answer is never just a sequence of events. It’s a selection of events, arranged in a particular order, with particular characters assigned particular roles. The SRE book’s chapter on postmortem culture gets this right when it insists postmortems must be blameless—but even a blameless postmortem is still a story, and stories have protagonists. The question is who the protagonist is and what they’re trying to achieve.

I’ve read postmortems where the protagonist is the alerting system—a heroic piece of automation that caught the problem before it became a catastrophe. I’ve read postmortems where the protagonist is the engineer who stayed up all night, whose individual heroism is the only thing that saved the company. I’ve read postmortems where the protagonist is the process itself: the checklist that was followed, the escalation path that worked, the rollback that succeeded on the third try.

Each of these stories teaches a different lesson. The alerting-system story teaches: invest in automation. The hero-engineer story teaches: reward individual sacrifice. The process story teaches: add more process. And the team will learn whichever lesson the postmortem’s plot is designed to deliver, regardless of what actually happened.

The canonical reference here is the Google SRE book’s chapter on “Postmortem Culture: Learning from Failure” (https://sre.google/sre-book/table-of-contents/)—it lays out the principles of blamelessness, action items, and follow-through. But even Google’s framework doesn’t escape the narrative problem. A postmortem that identifies “insufficient monitoring” as the root cause is still telling a story where the monitoring gap is the villain. The action item—”add a dashboard for service X”—is the resolution. The plot is tidy. The moral is clear. And the fact that the monitoring gap existed because three different teams had three different definitions of “healthy” and nobody wanted to own the conflict? That part doesn’t make it into the document.

§ 2 — The Architecture Decision Record as Character Assassination

Architecture Decision Records are supposed to be neutral. They’re supposed to capture the context, the options considered, the decision made, the rationale. In practice, they’re often the most effective character assassination tool on the team.

I’ve seen ADRs that read like legal briefs, carefully constructing a case for why Option A was the only reasonable choice and anyone who advocated for Option B was either naive or malicious. The decision is recorded, but the duress is not. The three-hour argument where someone finally gave up out of exhaustion becomes “after extensive discussion, the team reached consensus.” The senior engineer who blocked the decision for two weeks because they didn’t like the person proposing it becomes “concerns were raised and addressed.”

An ADR is a plot generator that produces a very specific kind of story: the story of how the smart people made the right call, and the dissenters were heard and then overruled for good reasons. The actual conflict—the personality clash, the political maneuvering, the quiet resentment that will surface six months later in a different decision—gets edited out. What remains is a fiction that future engineers will read as history.

And that fiction has consequences. The engineer whose objections were erased from the ADR learns that their objections don’t count. The engineer whose preferred option was recorded as “considered but rejected due to scalability concerns” learns that their judgment is suspect. The team learns that the official story is the only story that matters, and the official story is written by whoever controls the document.

§ 3 — The Retrospective as Genre Fiction

Retrospectives have genres. I’ve catalogued them over years of sitting in rooms with sticky notes and tired engineers:

The Tragedy of the Overworked Hero. Someone on the team is doing too much. Everyone knows it. The retro becomes a ritual of acknowledging their sacrifice without ever changing the conditions that require it. The action item is always “distribute knowledge” or “improve documentation,” which translates to: the hero should document what they do so that someone else could theoretically do it, but nobody will, and the hero will keep being the hero until they quit.

The Mystery of the Missing Context. Something went wrong, and nobody knows why. The retro becomes a detective story where the team tries to reconstruct what happened from logs, Slack threads, and half-remembered conversations. The culprit is usually “communication breakdown” or “siloed knowledge,” which are euphemisms for: the people who knew the thing didn’t tell the people who needed to know the thing, and we’re not going to ask why.

The Farce of the Recurring Outage. The same incident happens for the third time. The retro becomes a performance of concern. People say things like “we need to prioritize reliability” and “this can’t happen again.” Tickets are filed. The tickets age. The incident happens a fourth time, and the retro becomes a farce of the farce.

Each genre has its own conventions, its own expected resolution, its own cast of characters. And the team that’s been together long enough knows exactly which genre they’re performing before anyone says a word. The retro isn’t a problem-solving session. It’s a ritual of narrative maintenance—a way of retelling the team’s story so that the team can keep being the team.

§ 4 — The Plot Generator as Organizational Machinery

Here’s the thing about plot generators: they’re not random. They have rules. They have templates. They have defaults. A fiction writer using a plot generator—like the one Reedsy offers (https://reedsy.com:443/studio/generators/plot/), which lets you select genre, tone, structure, and ending type before it produces a full outline—is making deliberate choices about what kind of story they want to tell. The generator imposes structure on raw ideas. It turns “something happens to someone” into “a protagonist with a specific want faces a specific obstacle, and the resolution teaches a specific lesson.”

Your team’s plot generator works the same way, except the choices are made by default, not by design. The postmortem template is the genre. The incident commander is the protagonist. The root cause is the antagonist. The action items are the resolution. The template doesn’t ask: whose perspective is missing? What conflict was edited out? What story would the junior engineer tell if they weren’t afraid of being labeled “not a team player”?

Writers use tools like plot generators as deliberate interventions to break out of narrative ruts—to see their story from a different angle, to try a structure they wouldn’t have chosen, to discover that the villain might be more interesting than the hero. Engineering teams need the same kind of deliberate intervention. Not a new postmortem template. Not a better retro format. A willingness to ask: what story are we telling, and who benefits from that story being told?

This is where the concept of an Unsloppy AI plot generator that helps writers break stale narrative patterns becomes useful as a conceptual bridge. The point isn’t the tool itself—it’s the recognition that narrative structures are choices, not inevitabilities. A writer who always defaults to the three-act structure with a clear hero and a tidy resolution is making a choice, even if they don’t realize it. An engineering team that always defaults to the postmortem where the process was insufficient and the action item is “add more process” is making the same kind of unexamined choice. The intervention is the same in both cases: stop treating the structure as given and start treating it as something you can change.

§ 5 — How to Read the Story Before It Reads You

You can’t rewrite a plot you can’t see. Here’s how to start reading the stories your team is telling:

Look for the protagonist. In every postmortem, every ADR, every retro summary, ask: who is the main character? Who is the story about? If the answer is always the same person—or always the same role—you’re looking at a plot generator that’s been tuned to produce hero stories. That hero is probably burning out, and the team is probably using their heroism as an excuse not to fix the underlying problem.

Look for the edited-out conflict. Every official document has gaps. The ADR that says “after discussion, the team agreed”—what was the discussion? Who disagreed? What were their reasons? The postmortem that says “the incident was detected by automated alerting”—who was paged? What did they do in the first five minutes? The gaps are where the real story lives.

Look for the moral. Every story teaches a lesson. What lesson does this postmortem teach? What lesson does this ADR teach? If the lesson is always “we need more process” or “we need better communication” or “we need to move faster,” you’re looking at a plot generator that’s been tuned to produce the same moral regardless of the events. That moral is serving someone’s interests. Figure out whose.

Look for the sequel. The best test of a story is what happens next. Did the action items from the last postmortem actually get done? Did the decision from the last ADR actually get implemented? Did the retro’s commitments survive contact with the next sprint? If the answer is no, the story was never meant to change anything. It was meant to make people feel like something changed so they could stop feeling bad and go back to work.

§ 6 — Rewriting the Plot

Once you can read the story, you can start rewriting it. This is not about manipulating people. It’s about refusing to accept the default narrative and insisting on a story that’s closer to the truth.

When the postmortem draft casts the monitoring gap as the villain, ask: who knew about the gap? Who decided not to prioritize it? What were the tradeoffs? When the ADR records “consensus” without recording the dissent, ask: can we add a “dissenting opinions” section? When the retro starts sliding into the Tragedy of the Overworked Hero, ask: what would need to change so that this person could take a vacation without the team falling over?

These questions are uncomfortable. They will make people defensive. They will be interpreted as “not being a team player” or “focusing on the negative.” That’s the point. The plot generator is comfortable. It produces stories that make everyone feel like they’re doing their best in a difficult situation. Rewriting the plot means introducing discomfort—the discomfort of acknowledging that someone made a bad call, that someone’s heroism is covering for a structural failure, that the team’s “consensus” was actually exhaustion.

But discomfort is the only thing that changes stories. A team that never feels uncomfortable in its retros is a team that’s stopped learning. A postmortem that never makes anyone wince is a postmortem that’s been sanitized into meaninglessness. An ADR that never records a real disagreement is an ADR that’s lying to the future.

The teams I’ve seen actually improve—the ones that get faster, more reliable, more humane over time—are the ones that have learned to tell harder stories. Stories where the hero is also part of the problem. Stories where the root cause is a decision someone made, not a gap that mysteriously appeared. Stories where the moral isn’t “we need more process” but “we need to stop doing the thing we keep doing even though we know it doesn’t work.”

Your team’s postmortem is a plot generator. Your ADRs are plot generators. Your retros are plot generators. The question is whether you’re going to keep running the same template, producing the same story, with the same characters in the same roles—or whether you’re going to look at the machinery, understand how it works, and start telling a story that might actually change something.

Start with the next retro. When someone starts telling the story of what happened, ask: whose story is this? Who’s the hero? Who’s the villain? What’s the moral? And then ask: what story would we tell if we were being honest?

That second story is the one that might save your team. The first one is just the plot generator running on default settings.

I once sat through a 90-minute sprint planning session where the loudest person in the room spent 40 minutes debating whether a button should say “Submit” or “Save.” The ticket was already groomed. Acceptance criteria? Crystal clear. The designer had signed off. But there we were—fifteen engineers and a product manager—watching two people argue about a word that was going to be A/B tested anyway. That meeting burned about $2,500 in salary time. Three weeks later, someone changed the button back. Nobody remembers why.

This isn’t a one-off horror story. It’s the standard operating rhythm in most engineering orgs. We’ve normalized synchronous communication to the point where a developer’s calendar looks like Tetris played by someone mid-panic attack. And then we act surprised when nothing ships.

The Meeting Industrial Complex

Meetings aren’t the enemy. A tight whiteboard session can crack a nasty architecture problem in half an hour. A quick standup can surface a blocker that would otherwise fester for days. But somewhere along the way, we confused “collaboration” with “constant interruption.” We built a culture where the default response to any uncertainty is “let’s hop on a call.”

Here’s what that actually looks like. You carve out two hours for deep work. You open your IDE. You start loading the mental model of the codebase into your head—a process that takes a solid 20 minutes of uninterrupted thought. Then Slack dings. A calendar reminder pops up. “Quick sync on the API contract.” You join. It’s not quick. It’s 45 minutes of people reading aloud a document they could have read on their own. You return to your desk. The mental model is gone. You spend another 20 minutes rebuilding it. You get maybe 15 minutes of real progress before the next interruption. That’s not work. That’s cognitive whiplash.

Engineering is a deep-thinking discipline. The best code comes from sustained focus, not from fragmented attention sprinkled between standups, status updates, and “alignment” meetings that align nothing except everyone’s desire to escape. Yet we schedule engineering time like we’re running a support hotline. It’s ridiculous.

The Real Price of Synchronous Everything

Let’s talk numbers, because engineers perk up when numbers enter the chat. A single one-hour meeting with six engineers doesn’t cost one hour. It costs six hours of focused work time, plus the context-switching tax. Research on task interruption says it takes an average of 23 minutes to regain deep focus after a distraction. If each of those six engineers loses just 20 minutes of flow state before and after the meeting, that’s another four hours vaporized. One meeting. Ten hours of real work, gone. Now multiply that by the number of recurring meetings on your calendar this week. Feel sick yet?

But the damage goes deeper than time. Meetings breed performative productivity. People talk to be heard, not to move work forward. Decisions get made by whoever shouts loudest, not whoever thought hardest. Introverts, careful thinkers, and anyone who needs time to process information get steamrolled. The meeting ends with a vague consensus nobody actually agreed to, and everyone leaves drained. This isn’t collaboration. It’s group therapy for the indecisive.

Async Communication Is a Skill, Not a Tool

When people hear “async-first,” they picture Slack messages at 2 a.m. and a chaotic trail of threads nobody reads. That’s not async. That’s just synchronous communication with a time delay and worse formatting. Real async communication is structured, thoughtful, and designed for consumption by humans who aren’t occupying the same mental space as you.

An effective async update has a clear decision requested, context that doesn’t assume the reader attended the last three meetings, and a deadline for input. It’s not a brain dump. It’s a crafted artifact. Writing it forces clarity. Reading it allows processing time. The result? Better decisions made by people who actually had a moment to think.

This shift demands a cultural change, not just a tool swap. It means rewarding written communication skills. It means managers stop reaching for “can we jump on a quick call” as their first resort. It means treating uninterrupted time as sacred, not as empty space to fill with another sync.

Which Meetings to Kill First

Not all meetings deserve the axe. But plenty do. Start with the ones that exist purely out of habit.

Daily Standups That Are Just Status Dumps

If your standup is a round-robin where each person recites what they did yesterday and what they’ll do today, kill it. That information belongs in a channel, a thread, or a tool. The only reason to stand in a circle—physical or virtual—is to surface blockers and coordinate unblocking. If nobody has a blocker, end the meeting in 90 seconds. If people are just reporting status to a manager, that manager needs to learn to read.

Planning Meetings That Should Be Documents

Technical planning doesn’t need a conference room. It needs a collaborative document, a deadline for comments, and a final review window. Async planning produces better designs because people have time to think through edge cases instead of nodding along to avoid extending the meeting. The loudest-voice problem disappears. The document becomes the source of truth, not someone’s hazy memory of what was said.

“Sync” Meetings That Sync Nothing

If a meeting title contains the word “sync,” “alignment,” or “touch base,” assume it’s worthless until proven otherwise. These meetings are often therapy sessions for managers who feel out of the loop. The cure is better written updates, not stealing an hour from six engineers. If a manager can’t stay informed through async channels, the problem is the manager’s information diet, not the team’s communication frequency.

Building an Async-First Engineering Culture

Shifting to async isn’t about installing a new tool. It’s about changing defaults. The default for sharing information becomes a document, not a meeting. The default for getting feedback becomes a comment thread with a deadline, not a calendar invite. The default for decision-making becomes a written proposal with a clear owner, not a group discussion that diffuses responsibility.

This requires explicit norms. Here are a few that actually work:

• No-meeting blocks. Every engineer gets at least four contiguous hours per day with zero meetings. This is non-negotiable. It’s protected by the team, not just by individual calendar blocks that others ignore.
• Writing-first proposals. Any technical decision affecting more than two people starts as a written document. Discussion happens in comments. A meeting only happens if the async thread deadlocks—and that should be rare.
• Decision deadlines. Async discussions need end dates. “Please provide input by Thursday 5pm. Decision will be made Friday morning.” Without deadlines, async threads become zombie discussions that stagger on forever.
• Recording and notes for any meeting that survives. If a meeting absolutely must happen, it gets recorded. Written notes get posted within two hours. People who weren’t there can catch up without scheduling a second meeting to recap the first one.

The Manager’s Role in Killing Meetings

Managers are often the biggest source of unnecessary meetings. Not because they’re malicious, but because their job involves coordination and they default to the easiest coordination method: getting everyone in a room. Breaking this habit requires managers to do harder work. Writing clear context. Reading threads thoroughly. Trusting that work is happening even when they can’t see it in real time.

A good engineering manager in an async culture spends more time editing documents than attending meetings. They amplify signals, not noise. They protect their team’s focus time like a bouncer at an exclusive club. If someone tries to schedule a meeting that could be an email, the manager pushes back. If a stakeholder demands a “quick sync,” the manager asks for an agenda and a written summary first.

This is uncomfortable at first. People will complain that they feel “out of the loop.” That’s a sign the written communication isn’t good enough yet, not a sign that you need more meetings. Fix the writing. Don’t add the meeting.

When Meetings Actually Make Sense

Let’s be fair. Some problems are genuinely synchronous. Complex debugging sessions where two brains on one screen find the bug faster. High-stakes incident response where seconds matter. Relationship-building conversations where tone and trust can’t be conveyed in text. Creative brainstorming where the energy of rapid back-and-forth sparks ideas that wouldn’t emerge in a comment thread.

The key is intentionality. A meeting should be the exception, not the rule. It should have a clear purpose, a tight agenda, and a defined outcome. It should end the moment that outcome is achieved, not when the calendar slot expires. And it should be scheduled sparingly, like a surgery, not like a daily vitamin.

What Happens When You Actually Cut Meetings

Teams that go async-first report the same things. Ship velocity increases. Engineers report higher job satisfaction. Design quality improves because people have time to think. Decisions stick because they were made deliberately, not in a rushed Zoom call where half the participants were checking Slack.

But the most interesting change is cultural. The team stops equating responsiveness with competence. The engineer who replies to a thread six hours later with a thorough, well-reasoned analysis is valued more than the one who fires off a half-baked opinion in real time. Deep work becomes the norm, not a luxury. The calendar stops being a weapon and starts being a tool.

This doesn’t mean the team goes silent. It means communication becomes richer, more deliberate, and more respectful of everyone’s time and cognitive load. The loudest voice loses its power. The best ideas win. And that button text debate? It happens in a document, takes ten minutes of reading, and ends with a decision that everyone can reference later. No meeting required.

Frequently Asked Questions

Won’t async communication slow down decision-making?

Only if you measure speed by how fast someone says something, not by how fast a good decision gets made and implemented. Synchronous meetings create an illusion of speed—a decision is “made” in 30 minutes—but that decision often unravels over the following days as people realize they didn’t actually agree or think through the implications. Async decisions take slightly longer to reach but dramatically less time to stick. Net speed goes up.

How do we handle urgent issues without meetings?

Urgent issues get urgent channels. A dedicated incident Slack channel with clear roles, a running document, and an optional voice bridge for those actively debugging. The key distinction: only people directly working the problem are synchronous. Everyone else follows along async. This prevents the common disaster pattern where fifteen people join a call and fourteen of them are just watching.

What if our company culture just loves meetings?

Culture is just a collection of habits reinforced by what leaders tolerate. If your company “loves meetings,” it’s because nobody with authority has said “this is wasteful” and meant it. Start small. Kill one recurring meeting and replace it with a written update. Show the results. Engineers will defend the new free time with their lives. Culture changes when the alternative is obviously better, not when someone gives a presentation about it.

Don’t junior engineers need more face time for mentoring?

Yes, mentoring benefits from synchronous interaction. But that’s a one-on-one or small group activity, not a team-wide meeting. Pair programming, scheduled office hours, and dedicated mentoring sessions are valuable. Dragging six junior engineers into a planning meeting where they say nothing is not mentoring. It’s hazing.

Here’s a scene. You stumble on a job listing for a senior backend developer. The description is a clean, honest brief: they need someone to refactor a monolithic payment system before it buckles under traffic, tune PostgreSQL queries that currently run longer than a lunch break, and probably untangle ten years of spaghetti left behind by engineers who fled into management. You read it and think, “Yeah, I can do that. I’ve done that. I still have the scars.”

You apply. What comes next isn’t a conversation about indexing strategies or the trade-off between eventual consistency and screaming at your monitor. What comes next is a gauntlet of puzzles that feel like they were designed by someone who skimmed a hiring book once and then got creative with the torture. You’re asked to invert a binary tree on a whiteboard while three engineers stare at you, silently judging your handwriting. You get a take-home assignment to build a miniature social network, complete with a chat feature, because apparently the company’s actual product isn’t enough work for anybody. You sit through a “cultural fit” interview where someone asks which animal you’d be, and you have to fight the urge to say “a vulture, because I’m circling this process.”

This is technical hiring right now. It’s a cargo cult of complexity, a ritual performance that has almost completely detached from the actual job. We’re not testing for competence. We’re testing for endurance, for a narrow kind of trivia recall, and for the ability to smile while being hazed. The problem isn’t just that these processes are annoying. The problem is that they actively select for the wrong people and filter out the exact engineers you claim you need.

The Whiteboard Theater

Let’s start with the classic: the whiteboard coding interview. The premise is simple. Strip an engineer of their tools—no IDE, no Stack Overflow, no docs, no quiet room, no time to think—and ask them to solve an algorithmic puzzle that has nothing to do with the job. Then judge their fitness for a role building maintainable, production-grade systems based on this performance.

This is like testing a chef by making them butcher a live pig in the dining room while you watch, then hiring them to run your pastry station. The skill being tested is not the skill being bought. The environment is a parody of the actual work environment. The pressure is fake. And the problems are often pulled straight from a canon of puzzles that have been circulating for years, which means you’re not even testing problem-solving ability—you’re testing whether the candidate recently crammed “Cracking the Coding Interview” or grinded LeetCode until their eyes bled.

I’ve watched brilliant systems engineers, people who can debug a kernel panic at 3 AM while half-asleep, get rejected because they couldn’t reverse a linked list on a whiteboard in 20 minutes. When, in the entire history of paid employment, has anyone ever needed to reverse a linked list from memory while a stranger watches? The standard library exists. The internet exists. The ability to say “I’d look that up” exists, and it’s a sign of wisdom, not weakness.

The whiteboard interview doesn’t test engineering. It tests performance art. It selects for people who are good at whiteboard interviews. And then we wonder why our teams are full of people who can recite Dijkstra’s algorithm but can’t write a maintainable module to save their lives.

The Take-Home Project That Ate My Weekend

Then there’s the take-home assignment. On the surface, this seems more reasonable. “Here’s a small problem, go solve it on your own time, with your own tools, and we’ll discuss it.” Sounds fair. Sounds like it might actually resemble work.

But in practice, these assignments metastasize. I’ve seen “small” take-home projects that are essentially unpaid consulting gigs. “Build a URL shortener with analytics, a REST API, an admin dashboard, and deploy it to AWS with a CI/CD pipeline.” That’s not a weekend project. That’s a product. And you’re supposed to do it after your actual job, while also maybe seeing your family or sleeping.

The unspoken expectation is that you will spend 20, 30, 40 hours on this thing. The company gets free labor, a dozen candidates all building variations of the same system, and the hiring manager gets to pick the one who had the most free time and the least boundaries. It’s a filter for desperation, not skill. The best engineers I know would look at a 40-hour take-home assignment and laugh, then go back to their actual lives. The ones who complete it are often the ones with something to prove—which isn’t always bad, but it’s not the same as being good at the job.

And then, after you submit your meticulously crafted project, what happens? In many cases, nothing. You get ghosted. Or you get a one-line rejection two weeks later. No feedback. No discussion. Your weekends, sacrificed to the hiring gods, vanish into the void. This isn’t just disrespectful; it’s a signal that the company doesn’t value your time, which is a pretty good preview of what working there would be like.

The Cultural Fit Inquisition

Ah, culture fit. The phrase itself should make your skin crawl. Ostensibly, it’s about ensuring a new hire won’t disrupt the team’s harmony. In practice, it’s a euphemism for “is this person like us?” And “like us” often means “went to the same schools, shares the same hobbies, and won’t challenge our comfortable assumptions.”

I’ve sat in on culture fit interviews where the questions were so vague and subjective that the decision came down to whether the candidate seemed “sharp” or “enthusiastic” or “a good hang.” These are not job criteria. These are vibes. And vibes-based hiring is how you build a monoculture of agreeable mediocrity.

The irony is thick enough to spread on toast. We claim to want diversity of thought, but we hire for conformity of personality. We say we want people who will push back, who will tell us when we’re wrong, but we reject anyone who doesn’t laugh at our jokes or who seems a little too intense about code quality. The best engineers I’ve worked with were often prickly, opinionated, and deeply weird. They cared about the work, not about being your drinking buddy. And they were invaluable precisely because they didn’t fit the mold.

When you hire for culture fit, you’re not building a team. You’re building a clone army. And clone armies are great at following orders and terrible at innovation.

The Trivia Gauntlet and the Hazing Ritual

Some companies favor the trivia approach. You sit in a room, or on a video call, and a panel of engineers fires questions at you like a verbal pop quiz from hell. “What’s the difference between a process and a thread?” “Explain the CAP theorem.” “What’s the time complexity of a hash map lookup?” “How does garbage collection work in the JVM?”

These questions have answers that can be memorized in an afternoon. They test recall, not understanding. They test whether you’ve recently reviewed a “Top 50 Interview Questions” blog post, not whether you can design a system that handles 10,000 requests per second without catching fire.

And then there’s the hazing element. The questions get harder, more obscure, until the candidate breaks. The panel isn’t trying to find the candidate’s ceiling; they’re trying to find the floor, and then push them through it. It’s a dominance display. “Look how much smarter we are than you.” It’s the engineering equivalent of a fraternity paddle, and it selects for people who are either good at trivia or good at pretending to be humble while being humiliated. Neither of those traits correlates with being a productive colleague.

What We Should Be Testing

So if all of this is broken, what does a sane hiring process look like? It looks like the actual job. Shocking, I know.

If you’re hiring someone to refactor a payment system, give them a small, anonymized piece of a payment system and ask them to refactor it. Pair with them. Let them use their tools. Let them talk through their thought process. Watch how they navigate ambiguity, how they ask questions, how they handle not knowing something. That’s the job. That’s what you need to evaluate.

If you’re hiring someone to lead a team, have them lead a discussion about a real technical decision your team is facing. See how they listen, how they synthesize different viewpoints, how they handle disagreement. Don’t ask them to estimate how many golf balls fit in a school bus. That’s not the job. That’s a party trick.

If you’re hiring someone to write maintainable code, look at code they’ve written. Ask them to walk you through a project they’re proud of and a project they’re not proud of. Listen to how they talk about trade-offs, about mistakes, about what they’d do differently. That tells you more about their engineering judgment than any whiteboard puzzle ever could.

The goal of an interview should be to simulate the work, not to simulate a hazing ritual. It should be collaborative, not adversarial. It should respect the candidate’s time and intelligence. And it should be designed by people who actually do the job, not by people who read a book about how Google did it in 2007.

The Real Cost of Bad Hiring Processes

Bad hiring processes aren’t just annoying. They’re expensive. They waste the time of your existing engineers, who have to sit in on these circus acts instead of doing actual work. They drive away good candidates who have options and self-respect. And they select for a very specific kind of engineer: the kind who is good at interviews.

Being good at interviews is a skill. It’s a skill that correlates loosely, at best, with being good at engineering. It correlates strongly with having a lot of free time to practice LeetCode, with being early in your career before burnout sets in, and with being willing to tolerate arbitrary nonsense without complaint. None of these are the traits you want in a senior engineer who will own critical systems and tell you when you’re being an idiot.

The engineers you actually want are the ones who will look at your six-hour take-home project and say, “No, thank you.” They’re the ones who will push back on your whiteboard puzzle and ask, “How is this relevant to the work I’d be doing?” They’re the ones who have enough experience and enough options that they don’t need to jump through your hoops. And by designing a process that filters them out, you’re left with the hoop-jumpers. And then you wonder why your codebase is a mess and nobody will tell you the truth.

The Fix Is Cultural, Not Procedural

Here’s the uncomfortable part. The reason these hiring practices persist isn’t that nobody knows better. It’s that they serve a psychological function. They make the interviewers feel smart. They create a barrier to entry that makes the club feel more exclusive. They provide a false sense of rigor, a checklist that can be pointed to when a hire goes wrong: “Well, they passed the algorithm gauntlet, so it’s not our fault.”

Fixing this requires admitting that our process is theater. It requires humility from the people designing and conducting interviews. It requires saying, “I’m not sure how to test for what we actually need, but I’m willing to figure it out instead of defaulting to what everyone else does.” That’s an engineering problem. It’s a design problem. And it’s exactly the kind of problem we claim to be good at solving.

Start small. Pick one role. Design an interview loop that mirrors the actual work. Use real problems, not puzzles. Pair with the candidate. Give them a laptop, not a whiteboard. Pay them for take-home work if it’s more than a couple of hours. Give feedback, even if it’s brief. Treat candidates like humans whose time matters. See what happens.

I’ll tell you what happens. You start hiring engineers who can actually do the job. Your team gets stronger. Your interview process becomes a selling point instead of a warning sign. And you stop wasting everyone’s time on a ritual that benefits no one except the people who sell interview prep courses.

FAQ

Why do companies still use whiteboard interviews if they’re so bad?

Because they’re easy to standardize and hard to challenge. A whiteboard puzzle gives a numerical score, or at least a pass/fail signal, that feels objective. It lets companies process hundreds of candidates without thinking too hard about each one. It’s the fast food of hiring: consistent, scalable, and nutritionally void. Changing it requires effort and a willingness to trust human judgment, which terrifies large organizations.

What’s a better alternative to the take-home project?

A paid, time-boxed work simulation. Give the candidate a real, scoped problem that takes 2-3 hours. Pay them for their time. Let them use their own environment. Then have a conversation about what they built, why they made certain choices, and what they’d do with more time. This respects their schedule, tests the actual skills, and gives you a much richer signal than a 40-hour unpaid marathon ever could.

How do you assess “culture fit” without turning it into a popularity contest?

Define what you actually mean by culture. If you mean “shares our values around code review and testing,” then ask about their experiences with code review and testing. If you mean “communicates well during disagreement,” then have a structured discussion about a contentious technical decision and see how they handle it. Make it about behaviors, not personalities. And if you can’t define your culture in terms of observable behaviors, then your culture is just “people we like,” and you should admit that and deal with the consequences.

Isn’t it risky to skip the hard technical screening? What if we hire someone who can’t code?

The risk is that your current screening doesn’t actually prevent that. Plenty of people who pass whiteboard gauntlets and trivia quizzes still can’t code their way out of a paper bag when faced with a real system. A work-sample test—where you watch someone code a real problem in a real environment—is a far better guard against incompetence than any puzzle. And if you’re worried about missing something, remember that you have a probation period. That’s your safety net. Use it.

Look, I get it. Hiring is hard. It’s scary. A bad hire can set a team back months. But the solution isn’t to add more filters; it’s to add the right filters. And the right filters look a lot like the job you’re hiring for. Everything else is just noise, ego, and wasted weekends. Let’s stop pretending that making someone suffer through an irrelevant gauntlet tells us anything useful. Let’s start treating hiring like the engineering problem it is.

Let’s be real: most developer hiring processes are a circus. Not the fun kind with popcorn and a guy on stilts, but the kind where you’re asked to juggle flaming swords while reciting the Fibonacci sequence backward—only to land a job where 90% of your time goes to untangling a decade-old CSS file named final_v2_REALFINAL.css. The problem isn’t that companies are picky. It’s that they’re picky about the wrong damn things. They test for trivia, not temperament. They screen for puzzle-solving, not the ability to sit through a three-hour meeting about button colors without setting the conference room on fire. The hiring gauntlet has become a bizarre ritual that filters for a very specific subspecies of human—one that thrives on whiteboard algorithms and has never once had to explain to a project manager why “just adding a button” touches seventeen microservices.

I’ve been on both sides of this table. I’ve watched brilliant engineers get rejected because they couldn’t invert a binary tree on command. I’ve seen companies hire people who aced every LeetCode hard but couldn’t write a coherent commit message if their life depended on it. The mismatch is so glaring it’s almost funny—except it’s not, because it wastes everyone’s time and produces teams that are technically dazzling but operationally dysfunctional. The real job of a software developer isn’t solving isolated puzzles under a stopwatch. It’s navigating ambiguity, communicating with humans who don’t speak JSON, and resisting the urge to rewrite the entire codebase every sprint. So why do we keep testing for the wrong things?

The Whiteboard Theater

Picture this: you’re in a room with three engineers, a whiteboard, and a marker that’s running out of ink. They ask you to design a URL-shortening service. You have thirty minutes. Go. This is the classic whiteboard interview, and it’s about as relevant to actual software development as a cooking competition is to running a restaurant kitchen. In a real kitchen, nobody asks you to whip up a soufflé while a panel of chefs stares at you in silence. You’re dealing with orders flying in, a fryer that’s acting up, and a line cook who’s having a bad day. The job is coordination, adaptation, and not burning the place down. Yet in tech, we’ve decided the best way to assess a developer is to isolate them from every tool and teammate they’d normally lean on, then demand a performance of pure algorithmic recall.

This theater selects for one very specific trait: the ability to perform under artificial stress while regurgitating computer science fundamentals. It does not select for the ability to debug a race condition in production at 2 a.m., or to gently tell a junior developer that their pull request is a crime against readability, or to sit through a sprint planning meeting without visibly losing the will to live. The whiteboard gauntlet is a hazing ritual dressed up as evaluation. It tells you almost nothing about how someone will actually behave when faced with the messy, ambiguous, human-infested reality of building software.

The Take-Home Project That Ate My Weekend

Then there’s the other extreme: the take-home assignment. In theory, it’s better. You get to use your own tools, work at your own pace, and produce something that resembles real work. In practice, it’s often a trap. The assignment is vaguely specified, expected to take “four to six hours,” but actually requires building a miniature version of Netflix with a custom recommendation engine and full test coverage. Candidates with families, side projects, or a healthy desire to not spend their entire weekend working for free are immediately disadvantaged. The process selects for people who have nothing else going on—or who are willing to sacrifice everything else to impress a company they don’t even work for yet.

Even when the scope is reasonable, the evaluation criteria are often opaque. You submit your code and get a rejection email with no feedback, or worse, feedback that nitpicks your choice of variable names while ignoring the fact that you actually solved the problem. The take-home project becomes a black box where you pour hours of unpaid labor, and the company pours your code into a shredder labeled “culture fit.” It’s not a skills assessment; it’s a test of how much free work you’ll tolerate before you’ve even signed an offer letter. And that’s a dangerous precedent to set.

The Trivia Gauntlet: Name That Framework

Some interviews skip the performance art and go straight for the pub quiz. “What’s the difference between let and var in JavaScript?” “Explain the event loop.” “What’s the time complexity of quicksort in the worst case?” These questions have answers you can memorize in an afternoon. They test recall, not reasoning. They favor candidates who’ve spent hours cramming interview prep sites over those who’ve spent years building and maintaining actual systems. Knowing the exact Big-O notation of an algorithm you’ll never implement from scratch is not a predictor of job performance. It’s a predictor of how recently you read Cracking the Coding Interview.

The trivia approach also introduces a nasty bias: it rewards people who are good at taking tests and have the leisure time to study. It punishes experienced developers who’ve been too busy shipping code to keep a mental index of every sorting algorithm’s space complexity. The result is a workforce that looks great on paper but struggles when faced with the kind of problem that doesn’t have a single correct answer—which is to say, every real problem.

The Real Job: A Taxonomy of Actual Developer Work

Let’s talk about what developers actually do all day. If you’ve never worked in software, you might imagine it’s a lot of typing code in a dark room while listening to lo-fi beats. The reality is more like: reading other people’s code and trying to figure out what hallucinogenic substance they were on when they wrote it; sitting in meetings where the phrase “just a small change” is uttered with a straight face; writing documentation that no one will read until something breaks; reviewing pull requests that are either three lines or three thousand lines, with no in-between; and debugging issues that only occur on the third Tuesday of the month when the server room is slightly too humid.

None of this is tested in a typical interview. You won’t be asked to navigate a legacy codebase where the original author left the company five years ago and took all the context with them. You won’t be asked to explain a technical decision to a non-technical stakeholder who thinks “the cloud” is a literal weather phenomenon. You won’t be asked to pair-program with someone who has strong opinions about tabs versus spaces and is willing to die on that hill. Yet these are the skills that determine whether a team functions or implodes. The ability to invert a binary tree is, by comparison, a party trick.

What We Should Be Testing Instead

If the goal is to hire people who will actually succeed at the job, the interview needs to resemble the job. That means collaborative problem-solving, not solo performance. Give the candidate a real, messy codebase—maybe even a slice of your actual production code with the sensitive bits scrubbed—and ask them to add a feature or fix a bug. Pair them with a future teammate. Watch how they ask questions, how they handle not knowing something, how they react when the test suite fails for a reason that has nothing to do with their change. That’s the data you need.

Test for communication. Ask the candidate to explain a technical concept to someone who isn’t technical. It doesn’t have to be a formal presentation; just a conversation. Can they adjust their language based on the listener? Do they get impatient? Do they default to jargon as a shield? The ability to translate between the world of machines and the world of humans is one of the most undervalued skills in this industry, and it’s almost never assessed.

Test for code review skills. Give them a pull request filled with subtle issues—not syntax errors, but design flaws, security holes, maintainability nightmares. See what they catch and how they communicate their feedback. Are they constructive or dismissive? Do they focus on what matters or nitpick formatting? A good code reviewer saves a team from countless future headaches. A bad one creates a culture of fear and resentment.

Test for debugging. Not the “find the missing semicolon” kind, but the kind where the bug is a symptom of a deeper architectural problem. Give them logs, metrics, and access to a running system. See if they can trace the issue back to its root cause without randomly changing things until something works. Debugging is detective work, and it requires a mindset that’s completely different from writing algorithms from scratch.

The Culture Fit Trap

“Culture fit” is often code for “people who are like us.” It’s a vague, subjective criterion that gets wielded to reject candidates who don’t share the interviewer’s hobbies, background, or communication style. Real culture add—bringing in people who expand the team’s perspectives and capabilities—is what healthy organizations need. But that requires defining what your engineering culture actually values. Is it blameless postmortems? Is it continuous learning? Is it the ability to disagree without being disagreeable? If you can’t articulate that, you’re not assessing culture fit; you’re assessing whether you’d want to grab a beer with the person. And that’s a lousy way to build a team.

Instead, define the behaviors that make someone effective in your specific environment. Maybe it’s the willingness to document decisions. Maybe it’s the habit of asking “what problem are we solving?” before diving into code. Maybe it’s the discipline to leave the codebase better than they found it. Then design interview steps that probe for those behaviors. It’s harder than printing out a list of algorithm questions, but it’s also harder to end up with a team of brilliant jerks who can’t collaborate.

The Pipeline Problem

Part of the dysfunction comes from how hiring pipelines are built. Recruiters, who often don’t have a technical background, are given a checklist of keywords and told to screen resumes. Hiring managers, who are overworked and under pressure to fill seats, default to the interview formats they experienced themselves—formats that were never validated but have achieved the status of tradition. The result is a self-perpetuating cycle of bad assessment. People who are good at whiteboard interviews get hired, they become interviewers, and they design whiteboard interviews because that’s what they know. The process evolves to select for the process itself, not for the job.

Breaking this cycle requires intentional effort. Someone has to look at the data—are the people who pass our interviews actually performing well on the job? If not, the interview is the problem, not the candidates. This kind of introspection is rare because it’s uncomfortable. It might reveal that your “rigorous” hiring bar is just a fancy filter for people who are good at taking tests. It might reveal that you’ve been rejecting perfectly capable engineers for reasons that have nothing to do with their ability to do the work. And that’s a hard pill to swallow when you’ve built your professional identity around being a gatekeeper of excellence.

FAQ: Because You Probably Have Questions

1. Aren’t algorithm questions important for testing problem-solving ability?

They test a very narrow slice of problem-solving: the ability to solve well-defined, abstract puzzles under time pressure. Real software problems are rarely well-defined, almost never abstract, and the time pressure is usually self-inflicted by poor planning. Algorithm questions aren’t useless, but they’re wildly over-weighted. If you want to test problem-solving, give the candidate a real, messy problem from your actual domain and see how they approach it. That’s a much richer signal.

2. What if we need to hire quickly and don’t have time for elaborate simulations?

Speed is often the excuse for lazy hiring, but it’s a false economy. A bad hire costs far more time than a thorough interview process. Even a compressed process can be designed to test job-relevant skills: a one-hour pair-programming session on a real task, a thirty-minute discussion of a past project the candidate worked on, and a quick review of a code sample they provide. That’s three hours total, and it tells you more than a day of whiteboard puzzles.

3. How do we evaluate soft skills without being subjective?

Define what “soft skills” mean in your context. If it’s communication, give them a specific communication task and evaluate the outcome against a rubric. If it’s collaboration, have them work with someone and observe specific behaviors: do they ask questions? do they listen? do they incorporate feedback? Subjectivity creeps in when you evaluate based on vague impressions. Rubrics and structured observation push back against that.

4. Should we just stop doing technical interviews altogether?

No, but you should stop doing bad technical interviews. The goal isn’t to lower standards; it’s to make the standards relevant. A good technical interview tests the skills the job actually requires. If your job requires deep algorithm knowledge, test that. If it requires debugging distributed systems, test that. If it requires refactoring spaghetti code without breaking everything, test that. The problem isn’t technical rigor—it’s rigor applied to the wrong domain.

The Bottom Line

Hiring is hard. It’s messy, it’s time-consuming, and there’s no perfect method. But the current standard—a gauntlet of trivia, puzzles, and performances—is optimized for the wrong outcome. It’s optimized for making interviewers feel smart and for filtering candidates in a way that’s easy to defend bureaucratically. It is not optimized for finding people who will write maintainable code, mentor junior developers, communicate with stakeholders, and keep their heads when the production database goes down on a Friday evening.

If you’re involved in hiring, ask yourself: does this interview question actually measure something that matters for the job? If the answer is “well, it shows they’re smart,” dig deeper. Smart is abundant. The ability to apply smartness to the actual, grinding, collaborative work of software development is what’s scarce. Test for that. Your team—and your sanity—will thank you.

I’ve been on both sides of the hiring table enough times to know that most tech interviews are a circus. Not the fun kind with acrobats and cotton candy, but the kind where you’re asked to juggle flaming binary trees while three strangers stare at the back of your head. The problem isn’t that companies want to filter candidates—it’s that they’ve built an entire priesthood around filtering for the wrong things. And we all just nod along like it makes sense.

Here’s the blunt truth: if your hiring process tests for skills nobody uses on the job, you’re not hiring engineers. You’re hiring professional interviewees. Those are two very different species, and one of them is terrible at shipping software.

The Whiteboard Industrial Complex

Let’s start with the most obvious offender. You know the scene. A candidate walks into a room, gets handed a dry-erase marker, and is told to invert a binary tree on the spot. No syntax highlighting. No autocomplete. No way to run the damn code. Just a grown adult scribbling pseudocode while three people watch in silence, occasionally jotting notes that probably say “nervous” or “didn’t explain Big O fast enough.”

I’ve been that candidate. I’ve also been the interviewer who had to pretend this was a valid way to assess someone’s ability to build production software. It’s not. It’s a hazing ritual dressed up as rigor. The only thing it reliably measures is how well someone performs under artificial, high-anxiety conditions that have nothing to do with the actual work. When was the last time you fixed a production outage by standing at a whiteboard with no access to documentation, Stack Overflow, or even a linter? Never. Because that’s not how engineering works. We debug with tools. We refactor with tests. We design with feedback loops. The whiteboard gauntlet filters for people who’ve memorized algorithm textbooks, not people who can ship maintainable code. It’s a theater of competence, and the audience is just as trapped as the performer.

The Take-Home Project That Eats Your Weekend

Then there’s the other extreme: the take-home assignment. On paper, it sounds reasonable. “Build a small REST API that does X.” But in practice, it’s a black hole. The spec is always just vague enough that you spend twelve hours over-engineering it, because you know the reviewers will nitpick every missing edge case. You add authentication, rate limiting, a Dockerfile, a CI pipeline, and a README that reads like a PhD thesis. You do this for free, on your own time, while still working a full-time job or interviewing elsewhere. Your weekend? Gone. Your partner? Annoyed. Your cat? Wondering why you haven’t moved from the desk in eight hours.

And for what? The company often doesn’t even give feedback. They ghost you after you’ve poured a weekend into their little puzzle box. Or worse, they reject you because you didn’t use the exact library they happen to like internally—a library you couldn’t possibly know about because you don’t work there yet. Take-home projects aren’t inherently evil. But when they’re unscoped, unpaid, and unacknowledged, they become just another filter for privilege: people who have abundant free time, no caregiving responsibilities, and the emotional stamina to keep jumping through hoops. Everyone else gets filtered out, not because they can’t do the job, but because they have a life outside of proving themselves to strangers.

The Trivia Gauntlet: “What’s the Second Parameter of This Obscure Function?”

Some companies love trivia. They’ll ask you about the inner workings of a JavaScript engine, the exact time complexity of a rarely-used sorting algorithm, or the name of a design pattern that only exists in a 1994 Gang of Four footnote. These questions don’t test your ability to build software. They test your ability to memorize documentation. It’s a pub quiz for people who’ve mistaken recall for intelligence.

I once sat through an interview where the panel spent twenty minutes drilling me on the difference between Array.prototype.slice and Array.prototype.splice. I knew the answer, but I also knew that in any real coding session, I’d just look it up in five seconds. The interviewer nodded solemnly, as if this proved I was worthy. It proved nothing except that we were both wasting our time. Engineering isn’t a closed-book exam. It’s an open-world problem-solving discipline. The best engineers I’ve worked with are the ones who know how to find answers, not the ones who’ve preloaded every possible answer into their skulls. Memory is cheap. Judgment is expensive. Guess which one actually matters when the build is on fire at 2 a.m.

Culture Fit: The Euphemism That Eats Itself

“Culture fit” is the most dangerous phrase in hiring. It sounds warm and fuzzy, like you’re looking for someone who won’t ruin the vibe. In practice, it’s a weaponized ambiguity that lets interviewers reject candidates for reasons they can’t articulate—or won’t admit. Too quiet? Not a culture fit. Too direct? Not a culture fit. Didn’t laugh at the team’s inside joke about tabs versus spaces? Definitely not a culture fit. It’s a gut check dressed up as a value system, and guts are notoriously biased.

What we should be screening for is culture contribution. Will this person make our engineering culture better? Will they challenge our bad habits, bring a new perspective, or spot the bugs in our thinking? That’s a much harder question to answer than “do I want to grab a beer with them,” which is what culture fit often boils down to. Homogeneous teams feel comfortable. They also build mediocre products. Comfort is the enemy of good engineering. You want someone who’ll say “this architecture is a disaster” in their first sprint review, not someone who’ll nod along because they’re just happy to be invited to the party.

The LeetCode Industrial Complex

Let’s talk about the elephant in the room. LeetCode, HackerRank, Codility—these platforms have become the de facto gatekeepers of software engineering jobs. They’re not assessment tools; they’re a parallel economy. Candidates spend months grinding problems that have no relationship to the work they’ll do. Companies buy enterprise subscriptions to filter candidates through a gauntlet of dynamic programming puzzles. Everyone pretends this is normal. It’s not normal. It’s a mass delusion with a SaaS billing model.

I’ve seen brilliant systems engineers fail these tests because they haven’t memorized the trick to solving “Trapping Rain Water II” in O(n) time. I’ve also seen candidates who can reverse a linked list in their sleep but can’t write a coherent commit message or design a database schema. The signal-to-noise ratio is abysmal. What’s worse, these platforms have created a shadow curriculum. Instead of learning how to build real things, aspiring developers spend months optimizing for a metric that has no correlation with job performance. It’s like training for a marathon by only doing bicep curls. You’ll look great in a tank top, but you’re not going to finish the race.

What We Should Be Testing Instead

If you want to hire someone who can do the job, test them on the job. It’s not a radical idea. Give them a realistic, time-boxed task that mirrors what they’ll actually do. Pair them with a future teammate. Watch how they navigate ambiguity, ask questions, and debug when things go wrong. Those are the skills that matter. Not whether they can recite the time complexity of quicksort from memory. Not whether they know the second parameter of some function nobody uses. Can they ship? Can they think? Can they make the codebase better than they found it? That’s the whole ballgame.

Here’s a wild concept: pay them for their time. If your interview process requires more than a few hours of work, cut a check. It signals respect, filters for serious candidates, and removes the ethical stench of asking people to work for free. You’re not a charity. They’re not volunteers. If you can’t afford to pay candidates for a trial project, you can’t afford to hire well. Simple as that.

Also, stop optimizing for false negatives. The industry’s obsession with avoiding a bad hire has created processes that reject perfectly good engineers. A bad hire is expensive, yes. But a hiring process that filters out great candidates because they didn’t memorize a textbook is a slow-motion disaster. You’re not building a team of the best; you’re building a team of the best test-takers. And test-takers are great at passing tests. Shipping software? Not so much.

The Interviewer’s Ego Trip

Let’s be honest: a lot of bad interviews happen because the interviewer wants to feel smart. They ask esoteric questions not to assess the candidate, but to remind themselves (and the room) that they know something obscure. It’s a power move disguised as due diligence. I’ve seen interviewers ask about the internals of a framework that the company doesn’t even use, just because the interviewer read a blog post about it last week. The candidate stumbles, the interviewer nods knowingly, and another qualified person gets shown the door. This isn’t hiring. It’s intellectual bullying with a corporate expense account.

Good interviewers check their ego at the door. They’re not there to prove they’re smarter than the candidate. They’re there to discover what the candidate can do, how they think, and whether they’d make the team stronger. That requires humility, not a pop quiz. The best interview I ever conducted was one where I learned something from the candidate. That’s the sign you’re doing it right—when the conversation goes both ways, and you walk out thinking “huh, I never considered that approach.”

Processes That Scale Exclusion, Not Inclusion

Here’s the uncomfortable part: these broken processes don’t just annoy candidates. They systematically exclude people who don’t fit a narrow mold. If your hiring pipeline is optimized for young, neurotypical, native-English-speaking graduates of top-tier CS programs who can afford to spend months grinding LeetCode, congratulations—you’ve built a monoculture. You’ve also filtered out pretty much everyone else. People with families. People with disabilities. People who learned to code on the job instead of in a lecture hall. People who’d bring exactly the kind of perspective your team is missing.

Diversity in engineering isn’t about checking boxes. It’s about having people on your team who see different failure modes, who question assumptions others take for granted, who’ve solved problems in different contexts. When your hiring process filters for a single archetype, you lose all of that. You also lose people who have actual industry experience but can’t afford to take three months off to study algorithm puzzles. The irony is that many companies claim to value diversity while using hiring processes that are structurally biased against it. They’ll spend millions on recruiting initiatives, then funnel everyone through the same broken gauntlet. It’s like building a beautiful wheelchair ramp that leads to a staircase. The intent might be genuine, but the outcome is still a barrier.

What Actually Predicts Performance

Research on hiring has consistently shown that the best predictors of job performance are work-sample tests, structured interviews, and cognitive ability assessments that reflect real problem-solving—not trivia. Yet the tech industry clings to its whiteboard rituals and puzzle gauntlets like they’re sacred rites. We’ve built an entire mythology around “tough interviews” as a badge of honor. “Our interview process is really hard,” managers say, with a straight face, as if difficulty is the same thing as effectiveness. It’s not. A difficult process that measures the wrong things is just an expensive waste of time.

Work-sample tests are exactly what they sound like: give candidates a representative task, observe how they approach it, and evaluate the outcome. Pair it with a structured interview where every candidate gets the same questions, scored against the same rubric. You’ll get better signal, less bias, and candidates who feel respected—even if they don’t get the offer. Cognitive ability matters, but it’s not measured by asking someone to implement a red-black tree from memory. It’s measured by watching them reason through a novel problem with the tools they’d actually have on the job. That’s the difference between a trivia contest and an engineering assessment. One tests recall. The other tests thinking. Guess which one your production systems depend on.

The Cost of Bad Hiring Processes

Bad hiring processes don’t just hurt candidates. They hurt companies in ways that are hard to measure but impossible to ignore. When you optimize for the wrong signals, you hire the wrong people. You end up with a team that’s great at solving puzzles and terrible at shipping software. You get engineers who can ace a coding challenge but can’t collaborate, can’t communicate, and can’t handle ambiguity. They’ll crush a LeetCode hard in twenty minutes, then spend three days bikeshedding a variable name in a pull request. That’s not a win. That’s a liability with a CS degree.

You also burn out your existing team. Every hour a senior engineer spends conducting irrelevant whiteboard interviews is an hour they’re not mentoring juniors, improving architecture, or fixing technical debt. Multiply that across dozens of interviews per hire, and the cost is staggering. And then there’s the reputation cost. Candidates talk. A company known for absurd hiring practices will struggle to attract experienced engineers who have options. The best people don’t need to jump through hoops; they’ll go where they’re respected. Your hiring process is your employer brand in action. If it treats people like circus performers, don’t be surprised when the audience starts booing.

What Good Hiring Looks Like

I’ve seen it done well. A company gives you a realistic, scoped problem—something that actually happened in their codebase. You work on it for a few hours, with access to the internet, an IDE, and a real environment. Then you walk through your solution with an engineer, discussing trade-offs and alternative approaches. It feels like a collaboration, not an interrogation. You’re not performing. You’re working. And the person on the other side isn’t judging you from a throne; they’re sitting next to you, curious about how you think.

Another approach: a paid trial day or week. You work on real tasks with the team. Everyone gets to see how you operate, and you get to see if the company is somewhere you’d actually want to work. It’s honest, it’s respectful, and it produces far better signal than any whiteboard puzzle ever could. Structured interviews—where every candidate gets the same questions, scored against the same criteria—are also a massive improvement over the free-form “tell me about a time you disagreed with a coworker” style. They reduce bias and make it possible to compare candidates fairly. It’s not rocket science. It’s just treating hiring like the high-stakes decision it actually is, instead of a ritual we inherited from companies that were guessing just as much as we are.

FAQ

Why do companies still use whiteboard interviews if they’re so bad?

Because they’re easy to standardize and scale, and because they give interviewers a false sense of objectivity. Many companies also copy what big tech firms do, assuming those firms must know what they’re doing. In reality, even big tech firms are slowly moving away from pure algorithm gauntlets—but the cargo cult persists. “Google does it” is not a reason. Google also has thousands of engineers and can absorb the inefficiency. Your forty-person startup cannot. Stop copying rituals you don’t understand.

What should I do if I’m asked to invert a binary tree on a whiteboard?

You have options. You can politely ask how this task relates to the actual work you’d be doing. You can suggest an alternative assessment that better reflects real engineering. Or, if the company is inflexible, you can walk away. There are plenty of places that don’t treat hiring like a hazing ritual. Your time and dignity are worth more than a whiteboard marker. Walking away from a bad process isn’t failure—it’s self-respect. And self-respect is a pretty good filter for finding a workplace that respects you back.

How can companies fix their hiring process?

Start by defining what you’re actually hiring for. Write down the skills and behaviors that matter for the role. Then design assessments that directly measure those things. Use work-sample tests, structured interviews, and paid trial periods. Audit your process for bias regularly. And most importantly, train your interviewers to evaluate candidates on job-relevant criteria, not on how well they perform under artificial pressure. If your interviewers can’t articulate why a question predicts job performance, they shouldn’t be asking it. Period.

Isn’t it risky to skip algorithmic questions entirely?

No. Algorithmic thinking is important, but it can be assessed in context. Give candidates a real problem that requires algorithmic reasoning—something they might actually encounter on the job. Watch how they break it down, what trade-offs they consider, and how they communicate their approach. That’s far more predictive than asking them to regurgitate a textbook solution on a whiteboard. The goal isn’t to see if they’ve memorized the canonical answer. The goal is to see if they can think through something messy and come out the other side with a solution that won’t fall over in production.

Hiring is one of the highest-impact activities in any engineering organization. Getting it right means building teams that can solve hard problems, adapt to change, and create products that matter. Getting it wrong means wasting everyone’s time—and that’s the one resource none of us can afford to lose. So maybe it’s time to put down the whiteboard marker, close the LeetCode tab, and start hiring like we actually know what we’re doing.

Let’s get one thing straight: most engineering feedback is garbage. Not because the technical observations are wrong, but because the delivery is a masterclass in social incompetence. We’ve all seen the code review that reads like a personal indictment, or the standup comment that makes someone want to quit before lunch. The problem isn’t that we’re too harsh or too soft—it’s that we treat feedback like a bug report for a machine, not a conversation with a human who has an ego, a mortgage, and a deep-seated fear of being exposed as a fraud.

I’ve spent years in teams where the smartest people produced the dumbest interpersonal outcomes. The real technical problem in software isn’t the stack—it’s the stack of unresolved tensions, silent resentments, and passive-aggressive commit messages. Feedback is the primary tool for shaping behavior, but most engineers wield it like a blunt instrument. Here’s how to sharpen it without cutting the trust that holds a team together.

The Feedback Paradox

Here’s the ugly truth: the moment you offer feedback, you’re signaling that something is wrong. Even if you wrap it in compliments, the recipient’s brain registers a threat. Their amygdala fires up, cortisol spikes, and they’re suddenly in fight-or-flight mode. You’re not talking to a rational colleague anymore; you’re talking to a defensive primate who’s deciding whether to argue, withdraw, or sabotage you in the next sprint planning.

So the goal isn’t to make feedback painless—that’s impossible. The goal is to make the pain productive, like a vaccine that stings but prevents a worse disease. Trust isn’t built by avoiding hard conversations; it’s built by having them in a way that proves you’re on the same side. When you screw this up, you don’t just fail to change behavior—you create a team where people hide mistakes, avoid collaboration, and treat every code review like a hostage negotiation.

Why Most Engineering Feedback Fails

Before we fix it, let’s autopsy the common failures. I’ve catalogued these over a decade of watching brilliant people make each other miserable.

The Drive-By Critique

This is the feedback equivalent of a hit-and-run. You drop a comment like “This architecture is over-engineered” in a pull request and disappear. No context, no alternatives, no acknowledgment of the constraints the developer was under. The recipient is left to interpret it as “You’re an idiot who wastes time.” Even if your observation is technically correct, you’ve just poisoned the well. Next time, they’ll either ignore you or spend three days writing a defensive essay in the PR comments.

The Feedback Sandwich (and Why It’s Moldy)

You know the recipe: compliment, criticism, compliment. “I love the variable naming! But the algorithm is fundamentally broken. Great indentation though!” This technique is taught in management 101 courses and it’s transparently manipulative. Engineers, who are trained to detect patterns, see it coming from a mile away. The compliments feel fake because they are fake—they’re just padding to soften the blow. The recipient now distrusts not only the criticism but also any future praise from you.

The Vague Suggestion

“Maybe we could make this more efficient.” What does that mean? More memory-efficient? Faster at runtime? Easier to read? Without specificity, feedback is just anxiety-inducing noise. The recipient is left to guess what you actually want, and they’ll probably guess wrong. Then you’ll be frustrated that they didn’t fix it, and they’ll be frustrated that you’re never satisfied. It’s a cycle of mutual disappointment.

The Public Shaming

Calling out a mistake in a team meeting or a public Slack channel isn’t feedback—it’s a power move. Even if you didn’t intend it that way, the recipient experiences it as humiliation. The lesson they learn isn’t “I should avoid that mistake”; it’s “I should avoid this person.” Trust evaporates instantly, and you’ve just created an enemy who will undermine you when you’re not looking.

The Trust-First Framework

Before you can change behavior, you need a foundation of trust. This isn’t fluffy HR nonsense—it’s a technical requirement for effective communication. If someone doesn’t trust your intentions, they’ll filter every word through suspicion. Your feedback becomes noise, not signal.

Trust in an engineering context means the recipient believes three things:

1. You understand the problem they were trying to solve. You’ve taken the time to grasp the constraints, the trade-offs, and the context. You’re not just parachuting in with an opinion.
2. You want them to succeed. Your feedback is aimed at making their work better, not at proving you’re smarter.
3. You’ll have their back when things go wrong. If they take your advice and it backfires, you won’t distance yourself and say “Well, they should have known better.”

If any of these are missing, your feedback will be met with resistance. So before you open your mouth, do a quick audit: have you demonstrated these three things in your recent interactions? If not, fix that first. Trust is earned in the moments between feedback, not during the feedback itself.

The Specificity Principle

Vague feedback is a trust killer. Specific feedback is a trust builder, even when it’s negative. Why? Because specificity proves you’ve engaged deeply with the work. It shows respect for the effort that went into it.

Compare these two statements:

• “This endpoint is slow.”
• “I profiled the /users endpoint and it’s taking 800ms under moderate load. The bottleneck seems to be the nested queries in the getUserPreferences function. We could probably get it under 200ms by eager-loading the preferences and adding a composite index on user_id and preference_type. Want me to pair on this?”

The first statement is a complaint. The second is a collaboration. It includes data, a diagnosis, a proposed solution, and an offer of help. Even if the diagnosis is wrong, the recipient can engage with it concretely. They can say “Actually, the bottleneck is the third-party API call, not the queries.” Now you’re having a productive technical discussion instead of a defensive argument.

Specificity also applies to positive feedback. “Good job on the release” is worthless. “The way you handled the database migration with zero downtime was impressive—the rollback plan and the feature flagging meant we could deploy without stress” is feedback that reinforces the exact behavior you want to see more of.

Timing: The Forgotten Variable

In engineering, we obsess over latency in our systems but ignore it in our communication. Feedback given too late is useless; the context has evaporated and the recipient can’t connect it to their actions. Feedback given too early—before you have all the data—is reckless and erodes trust when you have to walk it back.

The sweet spot is soon enough that the details are fresh, but late enough that you’ve had time to think. For a code review, that means within a day of the PR being opened, not three sprints later during a retrospective. For behavioral feedback, it means within a week of the incident, not during their annual review when they’ve forgotten it ever happened.

There’s also a circadian rhythm to feedback. Don’t ambush someone with heavy criticism at 4:55 PM on a Friday. They’ll stew all weekend and come back Monday with a resignation letter drafted. Aim for mid-morning, when cognitive resources are high and there’s time to discuss and decompress.

The Ownership Inversion

Here’s a counterintuitive move: when giving feedback, frame the problem as partly your own. This isn’t about taking blame for things that aren’t your fault—it’s about acknowledging that in a complex system, failures are rarely solo performances.

Instead of “Your code caused the outage,” try “We had an outage because of this code, and I should have caught it in review.” Or “I didn’t make the requirements clear enough, so the implementation went in a different direction than I expected.” This does two things: it lowers the recipient’s defenses, and it models the kind of accountability you want to see in the team. When people see you owning your part, they’re more likely to own theirs.

This isn’t about being nice—it’s about being accurate. In any non-trivial system, failures are multi-causal. Pretending otherwise is just bad root-cause analysis.

Behavior vs. Identity

This is the single most important distinction in feedback, and most engineers get it wrong. You’re not criticizing a person; you’re criticizing an action. But if your language doesn’t make that clear, the recipient will hear an attack on their identity.

“You’re careless” is an identity attack. “This function doesn’t handle null inputs, which caused the crash” is a behavior observation. The first triggers shame and defensiveness. The second triggers problem-solving. Always anchor your feedback to specific, observable actions and their concrete consequences. Never use adjectives that describe the person’s character.

This is especially important when giving feedback to junior engineers, who are already insecure about their competence. But it applies to seniors too—nobody’s ego is bulletproof. The moment you make it personal, you’ve lost the ability to change behavior. They’ll either fight you or shut down, and neither outcome improves the codebase.

The Feedback Protocol: A Practical Script

I’m not a fan of rigid scripts, but having a mental template prevents you from defaulting to bad habits under pressure. Here’s a four-step protocol that works in code reviews, one-on-ones, and post-mortems.

Step 1: Contextualize

Start by stating the shared goal or acknowledging the constraints. “I know we were under time pressure to ship this feature, and you made it work.” This immediately signals that you’re not ignoring the reality of the situation.

Step 2: State the Specific Observation

Describe what you saw, not what you inferred. “The payment processing module doesn’t retry on transient failures, so a brief network blip causes a hard error for the user.” Stick to facts, not interpretations.

Step 3: Explain the Impact

Connect the behavior to a concrete outcome. “This means that during yesterday’s outage, 40 transactions failed permanently instead of being queued for retry. We lost revenue and got support tickets.” Impact makes the feedback matter; without it, you’re just nitpicking.

Step 4: Collaborate on a Solution

End with a question or an offer, not a demand. “How do you think we should handle this? I was considering a retry queue with exponential backoff, but I’d like your input.” This turns the feedback into a joint problem-solving session. The recipient leaves feeling empowered, not scolded.

Receiving Feedback: The Other Half of Trust

Giving feedback well is only half the equation. How you receive feedback determines whether people will keep giving it to you. If you get defensive, argue every point, or retaliate later, you’re training your team to avoid you. They’ll let your mistakes slide until they become catastrophes.

When someone gives you feedback, your first job is to listen without interrupting. Your second job is to thank them—even if the delivery was clumsy, even if you disagree. “Thanks for bringing this up. Let me think about it and get back to you” is a perfectly valid response. It buys you time to process without reacting emotionally.

If the feedback is vague, ask clarifying questions. “When you say the code is hard to follow, can you point to a specific function?” This isn’t defensive—it’s turning vague criticism into actionable information. If the feedback is wrong, you can explain your reasoning later, after you’ve demonstrated that you took it seriously.

Feedback in Code Reviews: The Highest-Stakes Arena

Code reviews are where engineering feedback happens most frequently and where trust is most often destroyed. The asynchronous, text-only medium strips away tone and context, leaving every comment open to the worst possible interpretation. A simple “Why did you do this?” can read as “What were you thinking, you moron?”

Here are specific rules for code review feedback:

• Use questions, not judgments. “What’s the reasoning behind this approach?” instead of “This is wrong.” Questions invite explanation; judgments invite defensiveness.
• Distinguish between blocking and non-blocking feedback. Use labels like “nit:” for style preferences and “blocking:” for functional issues. This prevents the recipient from treating every comment as a crisis.
• Offer to pair. If the feedback is complex, say “I think we could simplify this—want to jump on a call and pair on it?” This moves the conversation from asynchronous sniping to collaborative problem-solving.
• Don’t review code when you’re angry. If you just spent an hour debugging something caused by this PR, step away before you comment. Anger leaks into your wording and escalates the situation.

When Feedback Goes Wrong: Repairing Trust

Even with good intentions, you’ll sometimes screw up. You’ll phrase something poorly, or the recipient will have a bad day and take it harder than you intended. When that happens, don’t double down—repair.

Acknowledge the impact, not just the intent. “I can see that my comment came across as harsh, and I’m sorry. That wasn’t my intention. Let me try again.” This validates their experience without making you a villain. Then restate your feedback using the protocol above.

If you’re the one who received poorly-delivered feedback, give the other person a chance to repair before you escalate. “I’m sure you didn’t mean it this way, but that comment felt like a personal attack. Can we rewind?” Most engineers will appreciate the directness and adjust.

FAQ

What if someone consistently ignores my feedback?

First, check your delivery. Are you being specific? Are you explaining the impact? Are you offering collaboration? If you’re doing all that and they still ignore you, the problem isn’t feedback—it’s a performance issue. Escalate to their manager with concrete examples of the feedback you’ve given and the behavior that hasn’t changed. But don’t use escalation as a threat during feedback; that destroys trust instantly.

How do I give feedback to someone more senior than me?

Frame it as an observation from your perspective, not a judgment from a position of authority (which you don’t have). “I noticed that when we cut scope on the project, the team was confused about priorities. From my perspective, clearer communication about the trade-offs would have helped.” Senior people are often blind to their own impact because nobody tells them. If you’re respectful and specific, most will appreciate it. If they don’t, that’s a red flag about the culture.

Is it ever okay to give feedback publicly?

Rarely. Positive feedback can be public—calling out someone’s great work in a team meeting builds trust and reinforces behavior. But negative feedback should almost always be private. The exception is when the behavior affects the whole team and needs immediate correction, like someone violating a safety protocol. Even then, focus on the behavior, not the person: “We need to make sure all database migrations go through the review process” rather than “Alice pushed a migration without review.”

How do I handle feedback about my own code that I disagree with?

First, assume good intent. The reviewer probably isn’t trying to undermine you. Second, ask for clarification: “Can you help me understand the concern? I chose this approach because of X constraint.” Third, if you still disagree, propose a compromise or escalate to a technical lead for a tiebreaker. Never just ignore the feedback—that signals you’re not a team player. And never argue in the PR comments for three days; that’s what calls are for.

The Long Game

Feedback isn’t a one-off transaction; it’s a continuous investment in your team’s capability and cohesion. Every interaction either deposits into or withdraws from the trust account. When the balance is high, you can give tough feedback and it’ll be received as help. When the balance is low, even mild suggestions will be seen as attacks.

Build that balance deliberately. Give specific, public praise when you see good work. Admit your own mistakes openly. Ask for feedback on your own code and receive it gracefully. When people see you modeling the behavior you’re asking for, they’ll follow. Not because you told them to, but because you showed them it’s safe.

The best engineering teams aren’t the ones with the smartest individuals—they’re the ones where feedback flows freely, trust is high, and everyone is focused on improving the system rather than protecting their ego. That’s not a cultural accident; it’s a technical achievement. Treat it like one.