The Strange Theatre of Technical Hiring

Hello, Angular Space community :)

It has been some time since I last sat down to write. With AI reshaping how we consume content across the web, I'm still exploring what the most valuable way to share Angular knowledge through Angular Space looks like going forward.

For now, I'm addressing common challenges that many of us have encountered or are currently navigating.

Enjoy & pass this along to your HR/Hiring Managers and technical recruiting teams 😄

They bring years of accumulated experience. They've shipped systems, reviewed architecture, mentored developers, debugged production incidents, worked through chaotic codebases, and made calls that impacted real clients and real users.

Then the interview starts:

Just a problem, a countdown, and an observer.

For the next hour, the actual job fades away.

What's left is a performance. That is the strange theatre of technical hiring.

Software engineering today is collaborative, context-driven, tool-supported, and heavily reliant on judgment. Yet many interviews still evaluate developers as though the work happens solo, from memory, under scrutiny, with most of the essential tools stripped away.

Companies claim they want engineering capability, but the interview often rewards something more limited: speed, memory, composure under pressure, and knowledge of interview conventions.

That doesn't mean those qualities are useless. It just means they don't represent the full scope of the job. For senior engineers, leads, and architects, they might not even be the most critical part.

The stories are everywhere

Lately, I've seen multiple developers describe nearly identical experiences. One staff-level engineer recounted a live coding round that left him feeling diminished despite having spent close to twenty years in the field.

Keith wasn't new to software. He had worked on distributed systems, fintech platforms, microservices, and AI workflows.

In the real world, that kind of background carries weight. In the interview, it seemed to count for less than whether he could crack a narrow puzzle under time pressure.

Another developer outlined a familiar pattern. Discussions with engineering leadership went smoothly. He could articulate his background, his thought process, and his approach to building software. Then came the coding challenge—and the rejection followed.

Jessie's observation was straightforward: coding challenges often amount to tests with a compiler.

They might reveal how someone performs in a controlled setting, but they don't necessarily show how that person learns, adapts, works with others, or builds within a real team. Another engineer contributed a valuable perspective: some individuals aren't quick on their feet live, but they excel as thoughtful deep thinkers.

In actual work, where they can digest information, leverage resources, ask clarifying questions, and validate choices, they thrive. In timed settings, they come across as less competent than they truly are.

Because software engineering isn't a speed-reading contest.

It isn't a memory contest.

It isn't performance art.

At least, it shouldn't be...

The interview often removes the actual job

A senior developer's real day-to-day work rarely starts with a blank file. It starts with context. There's an existing system. There are past decisions. There are constraints. There are tests that may or may not be reliable. There's documentation that may or may not be up to date. There are colleagues who know why something was built in an unconventional way. Real engineering isn't just writing code. It involves:

• understanding the reasoning behind the code.
• knowing what to leave untouched.
• recognizing when a straightforward solution beats a clever one.

It also involves asking many questions, such as:

• What real problem are we trying to solve?
• What could this potentially break?
• What does this abstraction actually cost?
• Will the team understand this six months from now?
• Should this even be part of the codebase?

These are the kinds of questions senior engineers ask. But many interviews don't provide room for them. Instead, the candidate is placed in a synthetic environment and assessed on how well they perform within it.

• A developer can be outstanding at the job and still appear mediocre in the interview.
• A developer can excel at the interview and still struggle with the job.

That should concern companies more than it currently does.

The Angular architect problem

This misalignment becomes even more significant when the position is senior or architectural. Another real-life example involves a company hiring for an Angular architect.

However, rather than evaluating the skills they were hiring for, they chose a generic JavaScript route, explicitly stating there would be no additional Angular-specific step in the process.

The client doesn't just need someone who knows Angular syntax. They need someone capable of making decisions that will influence the project for months or even years.

An Angular architect may impact:

• How the Angular workspace is organized (single app vs multi-project / monorepo)
• How applications and libraries are divided, and which features are bundled as reusable Angular libraries.
• How teams share code through internal libraries and dependency injection patterns.
• How state is handled (signals, RxJS, forms, server state) and where that state resides.
• How domain boundaries are maintained within a multi-project workspace or monorepo.

That represents the true value of an Angular architect.

That value isn't solely in mastering JavaScript trivia.
It isn't solely in passing TypeScript quiz questions.
It isn't solely in solving algorithm challenges.

Yet, this is often what occurs. A company says it requires someone to safeguard a client's Angular project architecture, but then barely evaluates Angular architectural thinking.

That's not just unfair to the candidate.
It's risky for the client.

An Angular project won't fail because the architect missed a JavaScript quiz question. It will fail because:

• the Business aspects were misunderstood and inadequately explored
• the wrong Angular boundaries were established (apps vs libraries, workspace structure).
• complexity was introduced prematurely through unnecessary libraries or cross-cutting dependencies.
• teams were not aligned on Angular patterns and shared libraries.
• the Angular architecture was never questioned before it became costly.

The interview assessed the wrong ability and still produced confidence in the outcome.

The AI contradiction

AI has brought this contradiction into sharper focus. The industry currently tells developers to become AI-augmented.

Use AI assistants. Use documentation. Use search. Use autocomplete. Use tests. Use code review. Use tools to accelerate progress and reduce friction.

In the workplace, modern engineers are expected to leverage all available resources to create better software. But in interviews, the message often reverses.

• Do not use AI.
• Do not use Google.
• Do not consult documentation.
• Do not use the environment you'd normally work in safely.
• Solve this purely from memory.

This sets up a peculiar contradiction.

At work, senior engineers are expected to use tools sensibly. In the interview, they may be judged after those tools are taken away. The point isn't that AI should make decisions for the candidate. That would be the wrong takeaway. The real insight is that modern engineering competence now includes the ability to work safely with AI.

• Can the candidate verify AI-generated output?
• Can they identify hallucinations?
• Can they create tests around generated code?
• Can they dismiss a plausible but incorrect answer?
• Can they articulate why a suggestion doesn't fit the architecture?
• Can they use AI as a tool while preserving their own judgment?

That would be a far more useful senior-engineer evaluation than testing recall of syntax under duress.

The question shouldn't be:

• Can you solve this alone, from memory, with no tools?

The more relevant question is:

• Can you combine tools, context, and judgment to deliver dependable software?

Software engineering hiring appears stuck

Many other technical professions have long adopted more contextual, applied approaches to evaluating experienced practitioners.

Civil and mechanical engineers are frequently assessed through portfolios of actual projects, discussions of existing designs, review of calculations, and decisions made under realistic constraints: safety codes, budgets, site conditions, regulations, and long-term maintainability.

Physicians progress through supervised clinical practice, residency, practical exams with simulated patients, and certifications that gauge applied clinical judgment rather than isolated theoretical recall.

Lawyers are often evaluated through writing samples, moot court exercises, clerkships, case analysis, and other formats that approximate the actual work of legal reasoning and advocacy.

These fields aren't easy. Their assessments can be rigorous. But they tend to honor a fundamental principle:

• Senior competence is best evaluated in context.

Software engineering hiring, by contrast, often stays anchored to formats that gained popularity in the late 2000s and 2010s, even though the work has transformed, the role has evolved...

...too many interviews have not.

Some companies are already looking for better signal

This isn't just theory. Some companies already recognize that interviews can favor performance over genuine ability. Linear stands out as a strong example.

Their hiring process includes paid work trials as a final stage. Candidates work on real or near-real projects, with access to relevant tools, context, and people. The goal isn't just to hear someone talk about work—it's to observe how they actually operate.

How they make decisions, communicate, handle uncertainty, respond to feedback, take ownership, and collaborate with the team.

This approach has yielded impressive outcomes. Over several years, Linear has brought on dozens of people through work trials with a reported 96% retention rate among those hires.

Research in personnel psychology supports this direction. Meta-analyses, including the foundational work by Schmidt and Hunter, have consistently shown that work sample tests—assessments that replicate actual job tasks—offer the highest predictive validity for future job performance among common selection methods.

They outperform many traditional unstructured or puzzle-based interviews when it comes to forecasting real-world success.

The problem is not difficulty

When developers critique coding interviews, some interpret it as a desire for easier processes. But that misses the point. A realistic interview can be significantly harder than a puzzle.

• Debugging an unfamiliar codebase is hard.
• Reviewing architecture is hard.
• Articulating trade-offs is hard.
• Working with ambiguous requirements is hard.
• Using AI without being misled by it is hard.
• Making maintainable decisions under business pressure is hard.

The issue isn't that interviews are difficult. The issue is that many interviews are difficult for the wrong reasons.

• They create stress, but not the same stress as the actual job.
• They test speed, but not always judgment.
• They test memory, but not always reasoning.
• They test isolated problem-solving, but not always collaboration.
• They test whether someone can perform engineering theatre, not whether they can do engineering work.

What should we test instead?

If the role demands architecture, test architecture.

If the role demands leadership, test communication and judgment. If the role demands debugging, test debugging.

If the role demands working with legacy systems, provide the candidate with legacy constraints.

If the role demands AI-assisted development, test whether they can use AI responsibly.

When pair programming or live collaboration sessions are used, they should take place in the actual development environment the team uses in real work—with complete access to the IDE, internal tools, documentation, version control, testing frameworks, CI pipelines, and AI coding assistants—not in artificial, stripped-down environments that remove the very supports modern engineers depend on daily.

Only then does the exercise meaningfully reflect collaborative engineering.

The best hiring process isn't the one with the toughest questions.
It's the one with the most relevant signal.

The role we picture versus the role we perform

Within many technical interview processes, an outdated vision of coding persists. A single engineer. A single task. A single solution. Yet this rarely reflects how substantial software is actually crafted. Modern development is collaborative, situational, reliant on tooling, and abundant with compromises.

It demands more than memory; it requires discernment.
It requires writing code, certainly, but equally, clear communication.
It demands technical proficiency, but also the capability to apply that proficiency within intricate, constrained systems. This is precisely why the following accounts hit home.

• The staff-level engineer, with nearly two decades of experience, left feeling diminished.
• The developer who thrived in professional settings yet stumbled on coding puzzles.
• The engineer whose thought process is deliberate, not rapid-fire, especially under manufactured stress.
• The Angular authority assessed on technicalities, yet never on the architectural solution the client truly required.

These are not separate grievances; they point to a singular underlying issue.

The nature of software engineering has evolved—tools, expectations, and risks are all different now.

Consequently, hiring practices must evolve as well.

The objective should shift away from identifying the best performer in an interview's theatrical setting.

The objective should be finding the individual capable of performing the actual job.