The Coding Interview Is Testing the Wrong Skill

I was sitting in an unfamiliar office with an unfamiliar laptop in front of me.

Someone had given me a coding assignment to complete on the spot. The keyboard did not feel like mine. The development environment was unfamiliar. People were waiting to see what I would produce.

Naturally, this was supposed to reveal whether I was a good software developer.

Because, as everyone knows, the best way to test a person’s ability is to place him in a strange room, give him somebody else’s computer and watch him think.

I felt deeply uncomfortable.

It was not because I could not build software. I had already been working as a software developer from 2000 to 2007 as an employee. After that, I continued as a business owner, building websites, web applications, mobile apps, CRM systems and custom business software for clients.

I could solve real business problems. Yet that coding interview made me feel as if I had forgotten everything.

That experience stayed with me.

More recently, I was part of a company team involved in hiring. This allowed me to see the interview process from the employer’s side too. Employers face a real problem: they need to know whether a candidate can actually do the work.

But I now believe that much of the traditional coding interview process tests the wrong skill.

What is wrong with the coding interview process?

The short answer is simple:

A coding interview is wrong when it measures interview preparation more than the skills needed for the actual job.

A technical assessment is not automatically bad. Employers should confirm that a software developer can reason, communicate and work with code.

The problem begins when the interview becomes an artificial examination involving obscure algorithms, severe time pressure, an unfamiliar coding environment and an interviewer silently watching every keystroke.

That is not how most professional software is built.

A software engineering interview should resemble the work. Instead, many coding interviews have become a separate competitive sport.

Coding is not the same as software engineering

Writing code is part of software engineering. It is not the whole job.

An experienced software developer must first understand what needs to be built. That can be much harder than typing the code.

Clients rarely arrive with beautiful technical specifications.

They do not usually say:

“Good afternoon. Please design a modular event-driven architecture with clear domain boundaries and idempotent background processing.”

They say things like:

“My staff keep making mistakes.”

“Everything is inside one book.”

“Can you make it automatic?”

Then I must ask questions.

What exactly is going wrong? Who uses the system? What happens after an order arrives? Who approves it? What happens when a customer pays only a deposit? What happens when an installer changes the appointment?

The real work begins before the first line of code.

A good software engineer must uncover hidden requirements, understand business workflows, consider security, manage changing expectations and build something ordinary humans can use.

A LeetCode-style coding test may reveal whether someone has recently practised a particular algorithm. It does not necessarily reveal whether that person can build reliable business software.

One real project taught me more than any coding puzzle

I once worked with a business in Singapore that sold curtains and blinds.

The owner was overwhelmed with incoming orders. The business was doing well, which is a nice problem to have—until the nice problem starts chasing you around the office.

Almost everything was being managed through one physical order book.

The business also involved multiple salespeople, installers, customer deposits, final payments, commissions and installation appointments. All these activities had to be coordinated.

The owner told me he had no IT background. He did not even know how to explain what he needed.

But he had recorded a video.

In the video, he showed me how he searched through the large order book and tried to keep track of everything. That video became the beginning of the requirements-gathering process.

I asked questions, studied the workflow and gradually converted the business’s daily operations into a custom CRM and management system for the curtains and blinds company.

No interviewer could have described that project as a neat 45-minute algorithm question.

There was no perfect problem statement. There were no ready-made test cases. The business owner himself was still discovering what he needed.

That is real software development.

The interview has become another profession

A developer may spend years learning how to design systems, fix production problems, work with clients and maintain large codebases.

Then, when searching for a job, that developer must temporarily stop developing useful software and start practising coding-interview puzzles.

HackerRank reported that 77% of surveyed developers felt most assessments did not align with the skills required for the role. It also found that 62% felt they had to overprepare for LeetCode-style assessments because those exercises were not part of their normal work. Among developers aged 45 and above, 47% identified irrelevant questions as a reason to abandon an assessment.

This creates a strange situation.

Candidate A spends several months memorising common coding patterns.

Candidate B spends those months maintaining a production system, helping customers, reviewing code, fixing security issues and mentoring junior developers.

Candidate A may perform better in the coding test.

Candidate B may perform better in the job.

Congratulations. We have designed an assessment that can select the person who prepared best for the assessment.

Very scientific.

Why do good developers freeze during coding interviews?

Programming requires concentration.

During normal development, I can pause. I can inspect the existing code. I can check documentation. I can test an assumption. I can search for a strange error message. I can drink coffee and glare suspiciously at the screen until the bug becomes frightened and reveals itself.

During a live coding interview, the candidate may be expected to think aloud continuously.

“Now I am creating this variable.”

“Now I am considering a loop.”

“Now I am wondering why three people are watching me create the loop.”

The candidate is coding, explaining, monitoring the interviewer’s reactions and managing the clock at the same time.

Microsoft researchers compared conventional supervised technical interviews with asynchronous interviews. They found that removing the live observer reduced stress and improved the clarity of candidates’ explanations. Technical problem-solving and code quality were preserved and sometimes improved.

A person’s performance in this unusual environment may not reflect how that person performs during ordinary development.

Microsoft’s wider research into technical interviews also documented concerns about memorisation, time pressure, unsuitable tools and inconsistent results. The paper cited prior findings suggesting that only around 20% of candidates performed consistently across different technical interviews.

If the same developer can appear brilliant in one interview and hopeless in another, we should question what the process is measuring.

The day-one contradiction

Even when a developer is successfully hired, no reasonable employer expects that person to produce their finest work immediately.

A new employee needs time to understand the company’s products, codebase, tools, standards, deployment procedures, business rules, team members and customers.

A senior developer may need weeks or months to understand why certain architectural decisions were made.

Yet during the interview, we sometimes expect instant brilliance on an unfamiliar laptop in an unfamiliar room.

If I would not produce my best work on my first day in the company, why should I produce it during the interview before my first day?

Can is can. But human beings still need context.

Why senior software engineers walk away

I came across a Quora question asking why senior software engineers increasingly withdraw from hiring processes involving coding tests.

The question itself is revealing.

An experienced developer who refuses a coding assessment may not be afraid of coding. The person may be rejecting an irrelevant or disrespectful process.

Senior engineers tend to understand the value of their time. They may already have portfolios, references and many years of completed projects. They also know that an interview reveals something about the employer.

An irrelevant coding test can suggest that the company does not understand the position it is hiring for. An unnecessarily long unpaid assignment may suggest that the company does not respect boundaries. A hostile live interview may offer an exciting preview of future team meetings.

Companies are evaluating candidates, but candidates are also evaluating companies.

A good senior developer may have other opportunities. If one company demands six interview rounds and a weekend-long assignment, while another conducts a practical and respectful evaluation, the candidate’s decision is not very mysterious.

Employers still need proof

To be fair, employers cannot simply accept everything written on a CV.

People exaggerate.

A portfolio may contain work completed by an entire team. Someone with a “senior developer” title may struggle with fundamental programming. A friendly technical conversation can favour confident speakers who know how to produce impressive-sounding clouds of technical vocabulary.

“Microservices. Kubernetes. Blockchain. Artificial intelligence.”

Very powerful. Unfortunately, the login button still does not work.

A bad technical hire can be expensive. The rest of the team may spend months repairing poor code, correcting wrong decisions and managing missed deadlines.

Employers therefore need technical assessments. The answer is not to remove testing completely.

The answer is to test candidates using work that resembles the job. I discuss the wider selection process in my guide to hiring a software developer in Singapore.

Coding tests are not equally wrong for every role

The appropriate assessment depends on the position.

If a company is hiring someone to design database engines, optimise search infrastructure or develop performance-critical algorithms, advanced data-structure questions may be highly relevant.

If the role involves maintaining web applications, integrating APIs, fixing bugs and building internal systems, asking the candidate to solve an obscure graph problem from memory may offer little useful evidence.

A junior developer and a senior software architect should not receive identical assessments either.

A junior candidate may need to demonstrate programming fundamentals and the ability to learn. A senior candidate should be assessed on architecture, trade-offs, debugging, code review, communication and technical judgement.

The test must follow the job. The job should not be invented to justify the test.

Singapore employers should keep assessments job-related

This principle is relevant to hiring in Singapore.

TAFEP advises employers to use objective, consistent selection criteria connected to the position. It also recommends regularly reviewing tests to ensure they remain relevant and are not biased in either content or scoring. Assessments unrelated to the job may unfairly remove otherwise suitable candidates.

This matters especially to SMEs.

A global technology company receiving thousands of applications may tolerate rejecting many good candidates as long as enough suitable people remain.

A Singapore SME hiring one developer may not have that luxury.

Copying a big technology company’s coding interview process without understanding its purpose is like buying an airport fire engine to water your garden. Very impressive. Also somewhat unnecessary.

AI has broken the old coding test

Generative AI has created another problem for conventional coding assessments.

Many standard take-home questions can now be solved by ChatGPT, Claude, GitHub Copilot or another AI coding assistant within seconds.

Employers can respond by banning AI and treating every candidate like a suspected criminal. However, if developers will use AI tools after being hired, a complete ban may make the interview even less realistic.

The 2025 Stack Overflow Developer Survey found that 84% of respondents used or planned to use AI tools in software development. At the same time, 46% distrusted the accuracy of AI-generated output. Experienced developers showed particularly strong caution.

That suggests a better assessment question:

Can this candidate use AI effectively while still understanding, verifying and taking responsibility for the result?

Let candidates use AI when it reflects the real working environment. Then ask them to explain the generated code, identify weaknesses, test edge cases, correct mistakes and defend their decisions.

A candidate who copies an AI answer without understanding it will usually reveal the problem quickly during a thoughtful technical discussion.

AI can produce code. It cannot accept professional responsibility for deploying rubbish into production.

At least, not yet. Give the vendors another product-launch event.

What should replace the traditional coding interview?

A better software engineering interview should feel like a small, carefully controlled version of the actual job.

Begin with a real project discussion

Ask the candidate to describe a system they worked on.

Do not stop at “What technology did you use?” Ask why it was chosen. Ask what went wrong. Ask about a difficult bug, an unhappy user or an architectural decision the candidate would now change.

A person who genuinely worked on the project should be able to explain its messy details.

Use a realistic technical exercise

Give the candidate a small existing codebase.

Ask them to investigate a bug, add a modest feature, improve an API endpoint or review a pull request. This reveals how the person reads code, asks questions and handles imperfect information.

Real developers spend a great deal of time understanding existing code. We do not begin every Monday by implementing a binary tree on an empty whiteboard.

Let candidates use normal tools

Allow an IDE, documentation and search.

If AI tools are permitted in the actual role, consider allowing them during the assessment too. Observe how the candidate verifies the result.

The goal is to assess engineering ability, not memory capacity.

Test judgement and communication

Present a realistic scenario.

A client wants a feature delivered tomorrow, but the proposed approach creates a security risk. What would the candidate do?

A database query has become slow after the number of customers increased. How would the candidate investigate it?

Two developers disagree about an architectural decision. How should the team proceed?

These discussions reveal maturity, priorities and communication skills.

Use a structured scoring rubric

Every candidate should face comparable questions and be evaluated using the same job-related criteria.

Research on personnel selection supports realistic work samples and structured interviews. The United States Office of Personnel Management reports estimated validity coefficients of .54 for work-sample tests and .51 for structured interviews, compared with .38 for unstructured interviews.

Structure does not mean behaving like a robot. It means deciding what matters before meeting the candidate and scoring everyone fairly.

Respect the candidate’s time

A short unpaid assessment may be reasonable.

A project requiring an entire weekend should be paid. If the assignment produces work the company can use, it should certainly be paid.

“Please build half our product for free, and we will contact you only if successful” is not a hiring strategy. It is crowdsourcing with office furniture.

Advice for software developers attending coding interviews

Candidates cannot wait for every company to repair its hiring process. We must still operate in the world as it is.

Before accepting a technical assessment, ask what format it will take, how long it should require, what skills it measures and whether documentation or AI tools are allowed.

Practise explaining your decisions while working, but do not pretend to know everything. Asking sensible questions can demonstrate maturity.

When discussing previous projects, explain your individual contribution clearly. Describe the business problem, constraints, trade-offs and measurable result. Do not only list technologies.

If the assessment is unrelated, excessively long or disrespectful, it is reasonable to withdraw. Do it professionally. You are not obligated to participate in every hiring process merely because someone sent you a login link.

Most importantly, remember that failing a coding interview does not automatically make you a bad developer.

It means you did not pass that particular assessment on that particular day.

Learn what you can from it, but do not allow a 45-minute puzzle to erase years of real work.

Advice for employers hiring software developers

Before creating a coding test, write down what the developer will actually do during an ordinary month.

Will the person build APIs? Maintain WordPress websites? Review pull requests? Design cloud architecture? Work with mobile applications? Speak with customers? Repair old systems?

Design the assessment around those responsibilities.

Keep it short, explain the process clearly and give candidates the tools they would normally use. Train interviewers to help candidates feel comfortable enough to demonstrate their real ability.

Then review your results after hiring.

Do candidates who score highly actually perform well six months later? Are strong employees being recommended by interviewers for the same reasons represented in the scoring rubric? Are certain groups withdrawing disproportionately?

If nobody checks whether the coding test predicts success, the company may simply be maintaining an expensive tradition.

The best interview feels like working together

A good technical interview should not feel like an interrogation.

It should feel like two future colleagues solving a small problem together.

The interviewer can observe how the candidate understands requirements, reacts to feedback, communicates uncertainty and improves an initial solution.

The candidate can observe how the company discusses mistakes, gives direction and treats people under pressure.

Both sides learn something useful.

That is what an interview should achieve.

Let us test the work that matters

After more than 25 years in software development—as an employee, business owner and developer building web applications, mobile apps and custom software—I still believe technical ability must be assessed.

I simply do not believe that every coding test measures it well.

Software engineering is not a memory contest. It is not competitive typing. It is not the ability to appear relaxed while strangers watch you fight with somebody else’s laptop.

It is the ability to understand a problem, make responsible decisions and produce software that continues working after the demonstration ends.

Test developers.

But give them relevant problems. Give them normal tools. Ask them to explain their decisions. Observe how they handle uncertainty. Assess the skills the job genuinely requires.

Otherwise, the company may reject an excellent software engineer and hire an excellent coding-interview candidate.

Sometimes they are the same person.

Sometimes, very much not.

If your business needs a developer for a website, mobile app, CRM or internal system, explore my custom software development services in Singapore, browse my real software project case studies, or tell me what you need to build.

What has your experience been? Have you encountered a coding interview that accurately reflected the job—or one that made you wonder whether you had applied to become a software developer or a game-show contestant?