DEV Community: b0gy

Hiring engineers in the age of AI

b0gy — Sun, 24 May 2026 02:39:38 +0000

Your engineering interview loop was designed for a world where the bottleneck was writing code. The best engineers in 2026 are not the fastest coders — they're the ones with the best judgment about what to build, how to direct AI toward the right outcome, and when to override what it produced.

The job title still says "engineer," but the role has fractured. The person you actually need is part architect, part product thinker, part operator, and part team multiplier — designs systems before touching a keyboard, kills bad ideas before they become features, plans for the 3am page before it fires, makes the people around them better. AI writes the code. The human decides whether the code should exist at all.

Augment Code put it well in their hiring framework: the human role has shifted from author to architect and editor. You define intent, make trade-off decisions, set guardrails, and serve as the last line of quality. Raw coding ability no longer separates exceptional engineers from competent ones — regardless of whether they're writing backends, frontends, data pipelines, or infrastructure.

CoderPad's 2026 State of Tech Hiring confirms this from the demand side — technical assessments are up 48% globally, and 82% of developers find AI at least somewhat useful. Companies leading in AI are hiring more engineers, not fewer. The bottleneck isn't code generation. It's judgment, systems thinking, and the ability to work alongside AI without losing control of the outcome.

If your interview loop still centers on "can this person write a balanced binary tree on a whiteboard," you're selecting for a skill that AI does better than any human. Here's what to select for instead.

The rubric

Six dimensions, each with sub-criteria you score independently. 3 = strong, 2 = adequate, 1 = weak. Open the scorecard (Google Sheet).

1. Architecture & design

Can the candidate think at the level of systems, not just functions? These apply whether someone is building APIs, frontends, data pipelines, or infrastructure.

Trade-off analysis under ambiguity — can they explain why one approach beats another in terms the business cares about, not just technical preference?
Failure mode awareness — do they design for the 3am outage, or only the happy path?
Scale reasoning — do they ask about constraints (current bottlenecks, data patterns, cost) before proposing solutions?
API and contract design — can they design interfaces that other teams can integrate safely?
Data modeling and storage decisions — do they choose the right storage for the access pattern, not just the storage they know?

2. AI-assisted execution

Can the candidate direct AI tools toward the right outcome — and catch it when the output is wrong?

Directs AI toward well-defined subtasks — uses AI for implementation while keeping control of the overall design. Treats AI as a tool, not an oracle.
Critically reviews and debugs AI output — can explain why AI-generated code is or isn't correct. This is the single strongest signal.
Clear boundary between AI-delegated and human-owned work — knows which tasks to hand off and which to protect. No boundary means no judgment.
Understands AI limitations in production contexts — knows where models hallucinate, where context windows break, where AI-generated code introduces security or concurrency risks.

3. Systems & operations

Does the candidate understand what makes code production-worthy?

Observability — thinks about monitoring, alerting, and SLOs from day one. Monitors what the user cares about, not what the default dashboard provides.
Debugging methodology — has a systematic approach: logs, metrics, traces, reproduction. Asks what changed recently before guessing.
Cost awareness — considers compute, storage, and API call costs as design constraints, not afterthoughts.
Incident response and on-call mindset — has a mental model for what happens after the code is merged. Designs for operability.

4. Product & problem selection

Does the candidate solve the right problems, or just the ones assigned?

Asks about users and business context before building — wants to know the success metric, not just the spec.
Pushes back on problem framing when appropriate — would rather solve a simpler problem well than an interesting problem poorly.
Chooses simple solutions over interesting ones — the boring choice that saves the team real time or pain.

5. Learning velocity

How fast does the candidate adapt when tools and practices change underneath them?

Has adopted and discarded tools based on results — not just tried things, but evaluated and made deliberate choices.
Can articulate what changed in their workflow and why — adoption without displacement usually means the tool isn't actually being used.
Stays current without hype-chasing — runs personal experiments but doesn't chase every new release.

6. Culture & collaboration

AI amplifies individual output — but a 10x individual who can't collaborate is a net negative. Score this separately from technical ability.

Curiosity — asks questions, explores unfamiliar territory, wants to understand the system beyond their immediate scope.
Navigates disagreement constructively — describes what they learned from technical disagreements, not just how they won them.
Communicates technical decisions to non-engineers — can explain trade-offs in terms a PM or exec can act on.
Shares context on AI-generated code with the team — flags AI-generated sections in PRs, documents reasoning, takes responsibility for the review burden.
Mentors or lifts others — impact isn't just individual output. Improves the people around them.
Holds opinions loosely — has strong technical convictions but adapts to team norms and new information.

The questions

Fourteen questions, grouped by what they assess. Each one includes what you're listening for and the red flag.

Architecture & design

1. "Walk me through a system you designed that had to handle a non-obvious failure mode. What was the failure, and how did your design account for it?"

Listen for: specifics about the failure mode, the trade-off they made, and whether they designed for it proactively or reactively. Strong candidates talk about the failure before it happened.

Red flag: only discusses happy-path architecture.

2. "You're designing a service that needs to process 10x its current load within 6 months. Where do you start?"

Listen for: questions before answers. Strong candidates ask about current bottlenecks, data access patterns, and cost constraints before proposing solutions. They think about what not to change as much as what to change.

Red flag: immediately proposes a technology ("just use Kafka") without understanding the constraints.

3. "Tell me about a time you chose a boring solution over an interesting one. Why?"

Listen for: a clear trade-off between technical elegance and operational simplicity. The best answer is a story where the boring choice saved the team real time or pain.

Red flag: can't think of one. Engineers who always choose the interesting solution are expensive to operate alongside.

AI-assisted execution

4. "Walk me through your daily workflow. Where does AI fit in, and where doesn't it?"

Listen for: specificity. Strong candidates can name exact tools, describe which tasks they delegate to AI, and — critically — which tasks they don't. The boundary matters more than the tools.

Red flag: vague answers like "I use Copilot for everything." No boundary means no judgment.

5. "Tell me about a time AI-generated code was wrong in a way that wasn't obvious. How did you catch it?"

Listen for: a real story with a real failure mode. Strong candidates describe a subtle bug — a race condition, a missed edge case, a security hole — that they caught through review, testing, or domain knowledge. This is the single strongest signal for AI-assisted work: the ability to be the quality backstop.

Red flag: "that hasn't really happened to me." It has. They just didn't notice.

6. "If I gave you a new codebase you've never seen and asked you to add a feature using AI tools, how would you approach it?"

Listen for: a process that starts with understanding, not prompting. Strong candidates talk about reading the existing code, understanding the architecture, then using AI for implementation — not pasting requirements into a chat window and hoping.

Red flag: leads with "I'd prompt the AI to..." without any mention of understanding the system first.

Systems & operations

7. "Your service is throwing 500s for 2% of requests. Walk me through your debugging process."

Listen for: a systematic approach — logs, metrics, traces, reproduction. Strong candidates ask what changed recently, check deployment history, and think about partial failures. Let them use AI tools during the discussion. Watch whether they use AI to accelerate diagnosis or to replace thinking.

Red flag: guesses without data. "It's probably the database" is not a debugging process.

8. "How do you decide what to monitor in a new service?"

Listen for: a framework, not a checklist. Strong candidates think about SLOs, user-facing metrics, and leading indicators of failure — not just CPU and memory. They monitor the thing the user cares about, not the thing the infrastructure provides by default.

Red flag: "whatever the default dashboard gives us."

Product & problem selection

9. "Tell me about a feature you decided not to build. What was the reasoning?"

Listen for: business judgment. The feature was technically feasible but wrong for the user, the timeline, or the system's current maturity. Strong candidates kill their own ideas.

Red flag: can't think of a feature they chose not to build. This suggests they build whatever's asked without filtering.

10. "A PM asks you to add a feature that you think is a bad idea. What do you do?"

Listen for: pushback with evidence, not ego. Strong candidates describe how they'd frame the concern — data, user impact, operational cost — and what they'd do if overruled. The answer to "what if they still want it" matters as much as the initial pushback.

Red flag: "I'd just build it, they're the PM." Or the opposite: "I'd refuse." Neither is a real answer.

Learning velocity

11. "What AI tool or workflow did you adopt in the last 6 months that meaningfully changed how you work? What did it replace?"

Listen for: a concrete change in behavior, not a tool name. Strong candidates describe what they stopped doing when they adopted the new thing. Adoption without displacement usually means the tool isn't actually being used.

Red flag: names a tool but can't describe the workflow change. "I started using Cursor" is not an answer. "I stopped writing boilerplate tests by hand because Cursor generates them and I review them" is.

12. "What's something AI tools are bad at today that people assume they're good at?"

Listen for: nuance and firsthand experience. Strong candidates have bumped into real limitations — context window issues, hallucinated APIs, broken concurrency patterns — and can describe them specifically. This question reveals whether someone has used AI tools enough to know where they break.

Red flag: "AI is pretty good at everything now." It is not.

Culture & collaboration

13. "Tell me about a technical disagreement you had with a teammate. How did it resolve, and would you do anything differently?"

Listen for: respect for the other person's view, willingness to change their mind, and a resolution that wasn't just "I was right." Strong candidates describe what they learned, not just how they won.

Red flag: every story ends with them being right. Or they can't recall a disagreement — which means they either avoid conflict or don't notice it.

14. "How do you share context with your team when you've used AI to generate a significant chunk of code?"

Listen for: a process — PR descriptions that call out AI-generated sections, documentation of the reasoning, flagging areas that need extra review. Strong candidates recognize that AI-generated code shifts the review burden to the team and own that.

Red flag: "I just push it like any other code." That's how AI-generated bugs become the team's problem.

Red flags to watch across the loop

A few patterns that span the whole loop:

Tool fluency without technical depth. The candidate is fast with AI tools but can't explain the code they produce. This is the most dangerous hire in 2026 — someone who ships faster but embeds hidden defects. Canva's interview team found the same thing: the best candidates don't just prompt — they ask clarifying questions, use AI for well-defined subtasks, and critically review output.

No boundary between AI tasks and human tasks. Every engineer needs a clear mental model of what they delegate and what they don't. If someone uses AI for everything indiscriminately, they've abdicated judgment.

Resistance to AI as identity. Some candidates treat not using AI as a badge. In 2026, this is like refusing to use an IDE. It doesn't demonstrate skill — it demonstrates rigidity.

Can't debug AI output. If you ask them to review AI-generated code and they can't identify issues, they're a liability in a codebase where AI writes the first draft.

The heuristic

You're not hiring a coder anymore. The engineer you need in 2026 is an architect who designs systems before writing them, a product thinker who kills bad ideas before they become tickets, an operator who plans for the 3am page, and a teammate who makes everyone around them better. AI handles the typing. You're hiring for everything else. Interview for judgment, not keystrokes — the candidate who pushes back on AI output is worth more than the one who prompts their way to a solution.

tl;dr

The pattern. Engineering interviews still optimize for raw coding ability — a skill AI now handles — while ignoring the architect, product thinker, operator, and collaborator the role actually demands.
The fix. Score candidates across six dimensions (architecture, AI-assisted execution, systems & ops, product taste, learning velocity, culture) with specific sub-criteria, and use questions that reveal how they direct, evaluate, and override AI output.
The outcome. You hire engineers who think like architects, challenge like PMs, operate like SREs, and use AI as a tool — not engineers who either ignore it or depend on it blindly.

Originally published at b0gy.com

The displacement gap

b0gy — Sat, 16 May 2026 16:43:44 +0000

Every few weeks a new headline lands: 85 million jobs displaced. 300 million full-time roles affected. All white-collar work automated within 18 months. The numbers are big, round, and — if you look closely — mostly about theoretical capability, not observed reality.

Anthropic published labor market research in March that introduced a distinction most coverage ignores: the gap between what AI can automate and what it is automating. That gap is enormous. And it tells a very different story than the headlines.

The gap is the story

Anthropic's key contribution is a measure they call "observed exposure" — what Claude actually does in production, as opposed to what benchmarks say it could do.

The numbers are striking. Computer and math occupations have 94% theoretical AI exposure. In practice, Claude covers 33%. Office and admin roles — the ones everyone assumes are already gone — show 90% theoretical exposure and a fraction of that in actual use.

97% of observed Claude usage falls within theoretically feasible categories. The model can do the work. Organizations just aren't deploying it that way.

This is not a technology constraint. It is an adoption constraint. The bottleneck is not whether the model can draft a financial analysis or triage a support ticket. It is whether the organization has rebuilt the workflow, retrained the team, and instrumented the process to actually use AI where it fits.

Mustafa Suleyman predicted in February that all white-collar tasks would be automated within 12-18 months. Anthropic's data says we're at a third of theoretical capacity today, with no clear acceleration in the adoption curve. Both things can be true — the capability is there, the deployment is not — but the implication is different from what the headlines suggest.

The hollowing-out is real, just quiet

No clear evidence that AI has increased overall unemployment. That's the headline finding, and it's technically correct. But underneath it, something more specific is happening.

Anthropic found a 14% drop in the job-finding rate for workers aged 22-25 in AI-exposed occupations since ChatGPT launched. Not mass layoffs — reduced hiring. The entry-level pipeline is narrowing. Companies are not firing customer service reps. They are not backfilling them when they leave.

This is the pattern that matters for anyone running an AI program. The displacement is not dramatic. It is a slow compression of roles at the bottom of the org chart — data entry, basic admin, junior financial analysis, first-tier customer support. The people in these roles are not losing their jobs tomorrow. They are losing the next version of their jobs — the promotion, the adjacent role, the career ladder that used to exist.

US data suggests roughly 25,000 jobs erased per month against 9,000 new ones created. A net loss of 16,000 per month sounds alarming until you put it against a labor force of 160 million. But zoom in on who's affected and the picture sharpens: entry-level workers, administrative roles, and — disproportionately — women.

The gender gap nobody is planning for

79% of employed US women work in roles at high risk of automation, compared to 58% of men. Of the 6 million US workers most directly exposed to AI displacement, more than 85% are women. The ILO found women more exposed than men in 88% of countries analyzed.

This is not a coincidence. Women are overrepresented in exactly the categories AI automates first: administrative support, clerical work, payroll, reception, data entry. These roles have high theoretical exposure and high observed exposure — the gap between capability and deployment is smaller here because the tasks are more structured, more repetitive, and easier to automate without rebuilding an entire workflow.

Harvard and Berkeley researchers found a 25% gap in AI adoption between men and women. The workers most exposed to displacement are also the least likely to be building fluency with the tools that could reshape their roles instead of eliminating them.

Most workforce planning we see treats AI displacement as role-neutral. It is not. If your reskilling program does not specifically account for which roles and which demographics are most exposed, you are planning for a workforce transition that does not match the actual transition happening.

Reskilling is not a slide in the deck

IBM estimates 40% of the global workforce needs new skills within three years. The WEF projects 92 million jobs disappearing by 2030, offset by 170 million new roles — but those new roles require different skills, and the people losing the old roles are not automatically qualified for the new ones.

The new jobs are real. AI trainers, explainability engineers, data annotators, forward-deployed AI engineers — 1.3 million new roles by various estimates, plus 600,000 data center positions. Workers with advanced AI skills earn 56% more than peers. The demand side is genuine.

The problem is the bridge. BCG and HBR frame it well: AI will reshape more jobs than it replaces. 50-55% of US jobs will be substantially changed, not eliminated. But "substantially changed" means the person in the role needs to learn new tools, adopt new workflows, and develop judgment about when to trust AI output and when to override it. That is a training problem. And 90% of global enterprises report critical skills shortages going into 2026.

We see this pattern in every engagement. The organization has a model in production. The AI team is shipping features. But nobody owns the question of how the people whose workflows just changed are supposed to adapt. There is no training program. There is no measurement of whether adoption is happening at the individual level. There is a Slack message that says "we now have an AI tool for X" and an expectation that people will figure it out.

They don't.

Three phases, one window

The research broadly converges on a phased timeline. 2023-2025 was task automation, hiring freezes, role compression. 2026-2028 — where we are now — is when career transition spikes and displacement peaks. 2028 onward is the new equilibrium, where the job market has restructured around AI-augmented roles.

If that timeline is roughly right, organizations have about two years to get serious about the workforce side of their AI programs. Not the model side. Not the infrastructure side. The people side.

That means identifying which roles are being compressed — not theoretically, but based on actual usage data. It means building reskilling programs targeted at the specific demographics and job families most exposed. It means measuring adoption at the individual level, not the org level, because a 60% adoption rate can mean 60% of the team uses AI daily or 100% of the team opened the tool once. Those are very different situations.

The heuristic

Your AI workforce problem is not that machines will replace your people. It is that you are changing what the work requires without changing how your people are prepared to do it. Close that gap before the market closes it for you.

tl;dr

The pattern. Organizations focus on what AI can automate in theory while ignoring that actual deployment is a fraction of capability — and the real displacement is a quiet hollowing-out of entry-level and administrative roles, disproportionately affecting women.
The fix. Treat reskilling as an engineering problem: identify which roles are actually changing based on usage data, build targeted training for the specific demographics most exposed, and measure adoption at the individual level.
The outcome. Your workforce adapts alongside your AI program instead of being hollowed out by it, and the people most at risk become the people most prepared for what comes next.

Originally published at b0gy.com

The AI divide is not about AI

b0gy — Sun, 10 May 2026 22:12:17 +0000

PwC's 2026 AI Performance Study dropped a number that should worry anyone running an AI program: three-quarters of the economic value from AI is being captured by 20% of companies. The other 80% are spending real money and getting marginal returns.

This isn't a technology problem. It's an organizational one.

The numbers are worse than they look

Stanford's 2026 AI Index puts organizational adoption at 88%. Nearly every company of meaningful size is doing something with AI. But doing something isn't the same as getting value from it.

Writer's enterprise survey of 2,400 knowledge workers found that 79% of organizations face challenges in adoption — a double-digit increase from 2025. Nearly half of leaders say AI adoption has been a "massive disappointment." And 54% of C-suite executives say it's tearing their company apart.

Meanwhile, the top 20% are pulling away. PwC found those companies are 2.6x more likely to say AI is reshaping their business model, not just trimming costs. They're using AI for growth, not efficiency.

The gap is accelerating.

Efficiency is the wrong goal

Most companies failing at AI are doing exactly what the consultants told them to do: find inefficiencies, apply AI, measure cost savings. The problem is that efficiency gains from AI are real but small. Stanford documents 14-15% productivity improvements in customer support, 26% in software development. Meaningful — but not transformative.

The companies capturing most of the value are doing something different. They're using AI to enter adjacent markets, create new product categories, and restructure how their business works. PwC's single strongest predictor of AI-driven financial performance wasn't model quality or engineering talent — it was the ability to pursue growth opportunities from industry convergence.

The winners aren't using AI to do the same things cheaper. They're using it to do different things entirely.

The strategy problem is real

Here's the part that should alarm leadership teams. Writer found that 39% of companies investing over a million dollars annually in AI don't have a formal strategy for generating revenue from it. Among those that do, 75% of executives admit the strategy is "more for show than for actual internal guidance."

Three-quarters of AI strategies are slide decks that no one follows.

We see this constantly. A company has a model in production, a team maintaining it, a budget approved — and no clear answer to "what is this doing for the business?" The AI team ships features. Leadership counts deployments. Nobody measures whether the deployment changed anything that mattered.

The people divide is the real divide

The most uncomfortable finding in the Writer survey: 92% of C-suite executives are cultivating a new class of "AI elite" employees. 60% plan to lay off those who won't adopt AI. AI super-users are 3x more likely to get a raise or promotion and 5x more productive than slow adopters.

This creates a two-tier workforce inside companies that already have a two-tier AI strategy. The people who are good at using AI tools get more resources, more visibility, and more autonomy. Everyone else gets a mandate to "adopt AI" with no clarity on what that means.

The organizations closing the divide are the ones being explicit about what AI adoption looks like at each role level — not "use AI" but "here are the three workflows that change, here is the training, here is how we measure whether it worked."

What the top 20% actually do differently

After working with organizations on both sides of this divide, the pattern is consistent:

They fund AI at the product level, not the infrastructure level. The lagging companies build platforms and wait for use cases. The leading companies start with a business outcome and work backward to what needs to change.

They measure business metrics, not AI metrics. Not F1 scores or latency percentiles — revenue per user, time to close, customer retention. If the AI team can't connect their work to a metric the CFO cares about, they rethink the work.

They treat AI as a management problem. The technology is commoditized. GPT-5.5, Claude Opus 4.7, and DeepSeek V4 all shipped within days of each other in April. Model quality is converging. The differentiator is how the organization integrates, governs, and iterates on AI-driven processes.

They accept that most experiments will fail. The lagging companies run one pilot, see mediocre results, and declare AI overhyped. The leading companies run twenty pilots, kill fifteen, and scale the five that work. The failure rate is the same. The response to failure is different.

The heuristic

If your organization is spending seven figures on AI and you can't clearly articulate what business outcome has changed as a result — you're in the 80%.

That's not a reason to stop. It's a reason to stop doing what you're doing and start treating AI as a business decision rather than a technology project. The divide isn't about who has the best models. It's about who has the clearest thinking about what those models are for.

tl;dr

The pattern. 80% of companies are spending real money on AI and getting marginal returns because they treat it as a technology project — find inefficiencies, apply AI, measure cost savings.
The fix. Fund AI at the product level with business metrics, run multiple bets with kill criteria, and define what "AI adoption" means concretely for each role instead of issuing mandates.
The outcome. AI drives growth — new markets, new products, new business models — instead of shaving single-digit percentages off existing processes.

Originally published at b0gy.com