A senior engineer joins a technical interview...

Hi Angular Space community :)

It’s been a while since I pushed myself to write something. AI is changing the way we consume literally everything online, and I’m still trying to figure out what the best and most compelling way forward looks like for sharing Angular knowledge through Angular Space.

For now, I’m touching on some universal problems that many of us have either already faced or are facing right now.

Enjoy & share with your HR/Hiring Managers and technical recruiting team 😄

A senior engineer joins a technical interview...

They have years of experience behind them. They have shipped systems, reviewed architecture, mentored developers, debugged production issues, worked with messy codebases, and made decisions that affected real clients and real users.

Then the interview begins:

Just a problem, a timer, and someone watching.

For the next hour, the job disappears.

What remains is a performance. That is the strange theatre of technical hiring.

Software engineering today is collaborative, contextual, tool-assisted, and deeply dependent on judgment. But many interviews still test developers as if the job happens alone, from memory, under observation, with most of the important tools removed.

The company says it wants engineering ability, but the interview often rewards something narrower: speed, recall, confidence under pressure, and familiarity with interview rituals.

That does not mean those skills have no value. It means they are not the whole job. And for senior engineers, leads, and architects, they may not even be the most important part of the job.

The stories are everywhere

Recently, I saw several developers describe almost the same experience.One staff-level engineer wrote about a live coding round that left him feeling humiliated despite nearly twenty years in the industry.

Keith was not someone new to software. He was someone who had worked on distributed systems, fintech platforms, microservices, and AI workflows.

In real work, that kind of experience matters. In the interview, it seemed to matter less than whether he could solve a narrow puzzle under pressure.

Another developer described a similar pattern. The conversations with engineering leadership went well. He could explain his experience, his thinking, and his approach to building software.Then the coding challenge arrived and the rejection followed.

Jessies point was simple: coding challenges are often tests with a compiler.

They may show how someone performs in a test environment, but not necessarily how they learn, adapt, collaborate, or build inside a real team. Another engineer added an important perspective: some people are not fast live performers, but they are excellent deep thinkers.

In real work, where they can process information, use resources, ask questions, and verify decisions, they perform well. In timed interviews, they look weaker than they are.

Because software engineering is not a speed-reading contest.

It is not a memory contest.

It is not performance art.

At least, it should not be...

The interview often removes the actual job

A senior developer’s real work rarely begins with an empty file. It begins with context. There is an existing system. There are old decisions. There are constraints. There are tests that may or may not be trustworthy. There is documentation that may or may not be current. There are teammates who know why something was built in a strange way. Real engineering is not only writing code. It is:

• understanding why the code exists.
• knowing what not to change.
• recognizing when a simple solution is better than a clever one.

It is also asking mamy questions such as:

• What problem are we actually solving?
• What could this break?
• What is the cost of this abstraction?
• Will the team understand this in six months?
• Does this belong in the codebase at all?

These are senior engineering questions. But many interviews do not create space for them. Instead, the candidate is placed in an artificial environment and judged on how well they perform there.

• A developer can be excellent at the job and still look average in the interview.
• A developer can be excellent at the interview and still struggle with the job.

That should worry companies more than it does.

The Angular architect problem

This mismatch becomes even more dangerous when the role is senior or architectural. Another real life story is with a company hiring for an Angular architect.

However instead of checking the skills that they are hiring for they decided to go with a generic JavaScript route openly saying there is no additional Angular related step to the process.

The client does not need someone who merely knows Angular syntax. The client needs someone who can make decisions that will shape the project for months or years.

An Angular architect may influence:

• How the Angular workspace is structured (single app vs multi-project / monorepo)
• How applications and libraries are split, and which features are packaged as reusable Angular libraries.
• How teams share code through internal libraries and dependency injection patterns.
• How state is managed (signals, RxJS, forms, server state) and where that state lives.
• How domain boundaries are protected inside a multi-project workspace or monorepo.

That is the value of an Angular architect.

The value is not only in knowing JavaScript trivia.
It is not only in answering TypeScript quiz questions.
It is not only in solving algorithm puzzles.

And yet this is often what happens. A company says it needs someone to protect the architecture of a client’s Angular projects, but then barely tests Angular architectural thinking.

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

Angular project will not fail because the architect forgot a JavaScript quiz answer. It will fail because:

• the Business side of things in misunderstood and under-investigated
• the wrong Angular boundaries were chosen (apps vs libraries, workspace layout).
• complexity was introduced too early through unnecessary libraries or cross-cutting dependencies.
• teams were not aligned on Angular patterns and shared libraries.
• nobody challenged the Angular architecture before it became expensive

Interview tested the wrong skill and still felt confident in the result.

The AI contradiction

AI has made this contradiction more visible. The industry now tells developers to become AI-augmented.

Use AI assistants. Use documentation. Use search. Use autocomplete. Use tests. Use code review. Use tools to move faster and reduce friction.

In real work, the modern engineer is expected to use everything available to produce better software. But in interviews, the message often becomes the opposite.

• Do not use AI.
• Do not use Google.
• Do not use documentation.
• Do not use the environment you normally use to work safely.
• Solve this from memory.

This creates a strange contradiction.

At work, the senior engineer is expected to use tools responsibly. In the interview, they may be judged after those tools are removed. The point is not that AI should be allowed to do the thinking for the candidate. That would be the wrong lesson. The real point is that modern engineering skill now includes knowing how to work with AI safely.

• Can the candidate verify AI output?
• Can they spot hallucinations?
• Can they write tests around generated code?
• Can they reject a plausible but wrong answer?
• Can they explain why a suggestion does not fit the architecture?
• Can they use AI as a tool without outsourcing their judgment?

That is a much better senior-engineer assessment than asking someone to remember syntax under pressure.

The question should not be:

• Can you solve this alone, from memory, without tools?

The better question is:

• Can you use tools, context, and judgment to produce reliable software?

Software engineering hiring appears stuck

Many other technical professions have long used more contextual and applied ways to assess experienced professionals.

Civil and mechanical engineers are often evaluated through portfolios of real 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 advance through supervised clinical practice, residency, practical examinations with simulated patients, and certifications that test applied clinical judgment rather than isolated theoretical recall.

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

These fields are not easy. Their assessments can be demanding. But they tend to respect an important truth:

• Senior competence is best evaluated in context.
  

Software engineering hiring, by contrast, often remains anchored in formats that became popular in the late 2000s and 2010s, however the work has changed, the job has evolved...

...too many interviews have not.

Some companies are already looking for better signal

This is not theory. Some companies already understand that interviews can reward performance more than real ability. Linear is a strong example.

Their hiring process includes paid work trials as a final stage. Candidates work on real or close-to-real projects, with access to relevant tools, context, and people. The goal is not just to hear how someone talks about work - it is to see how they actually work.

How they make decisions, communicate, handle ambiguity, use feedback, take ownership, and collaborate with the team.

This approach has produced excellent results. Over several years, Linear has hired 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 found that work sample tests - assessments that simulate actual job tasks - show the highest predictive validity for future job performance among common selection methods.

They outperform many traditional unstructured or puzzle-based interviews in forecasting real-world success.

The problem is not difficulty

When developers criticize coding interviews, some people hear they want the process to be easier. But that is not the real argument. A realistic interview can be harder than a puzzle.

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

The issue is not that interviews are hard. The issue is that many interviews are hard in the wrong way.

• They create pressure, but not the same pressure as the job.
• They test speed, but not always judgment.
• They test recall, 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 requires architecture, test architecture.

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

If the role requires working with legacy systems, give the candidate legacy constraints.

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

When pair programming or live collaboration sessions are used, they should happen in the actual development environment the team uses in real work - with full 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 rely on daily.

Only then does the exercise meaningfully reflect collaborative engineering.

The best hiring process is not the one with the hardest questions.
It is the one with the most relevant signal.

The job we still imagine

There is an old image of programming that still lives inside many technical interviews. One developer. One problem. One correct answer. But it is not how most serious software gets built. Real software engineering is collaborative, contextual, tool-assisted, and full of trade-offs.

It requires memory, yes, but also judgment.
It requires coding, yes, but also communication.
It requires technical knowledge, yes, but also the ability to use that knowledge inside messy systems with real constraints. That is why these stories resonate.

• The staff engineer who felt humiliated after nearly twenty years.
• The developer who could succeed in real jobs but not in coding challenges.
• The engineer who thinks deeply but not quickly under artificial pressure.
• The Angular architect evaluated on everything except the architecture the client actually needed.

These are not isolated complaints, they are symptoms of the same problem.

Software engineering has changed, the tools have changed, the expectations have changed, the risk has changed.

Now technical hiring has to change too.

The goal should not be to hire the person who performs best in the theatre of the interview.

The goal should be to hire the person who can do the job.