Hiring managers keep insisting that they want “real-world problem solvers”, yet the first thing they do is shove candidates into a gladiatorial arena of whiteboards, leet-code puzzles and stopwatch-fuelled anxiety.

No wonder the best people skip your process.

The problem in a nutshell

I’ve experienced this first-hand countless times. I’ve been a web developer since 1998 and since 2013, I’ve been a contractor. As a contractor, I often have multiple roles in a year, which means in my time, I’ve had a LOT of interviews.

Once, in an interview for a senior front-end role, I was asked to implement a quick-sort algorithm from scratch in JavaScript without using Google or any documentation.

In my day-to-day, I’ve never written my own sorting algorithm - because, surprise surprise, JavaScript has built-in methods like .sort() that are optimised far beyond anything I’d scribble out in a 10-minute panic. Of course, there are edge cases where you have to do sorting in a non-standard way but a) I've never personally had that come up and b) If I did, I'd just google it. It's not worth having that knowledge in my head.

On another occasion, I had to reverse a binary tree (again, in JavaScript!) while three interviewers watched silently. Honestly, I don’t even know what a binary tree is and guess what? In over 25 years, that has never once been an issue!

Many years ago, I was asked if I know what a closure was. At the time, I didn’t but then when I got home and looked it up, I realised that although I didn’t know what a closure was called, I actually used them all the time as this was back in the jQuery days were closures were very common.

I’ve even had an interview where I was handed a pen and paper and asked to write code! I actually walked out of that one!

These tests don’t measure how well you do your job; they measure how well you do tests under interview conditions, they measure how well you know the terminology and how good you are at memorising.

None of those things really test how good you are as an engineer.

How did we get here?

Somewhere around the mid-2010s, a myth calcified in tech hiring:

If you can solve a complicated edge-case problem while three strangers breathe down your neck, you must be a brilliant engineer.

This became convenient for companies because these types of questions are easy to grade, scale effortlessly, and create a façade of rigour - at least to non-technical stakeholders.

Ask any senior developer who spends their day reviewing pull requests, untangling vague product requirements, and soothing cranky CI pipelines if any of the stuff they were asked in their interviews applies to their workday and you’ll get a resounding 'no'.

Developers who are pro-this-sort-of-thing would argue that it tests your ability to think under pressure, my counter arguments would be that a) This is a different kind of pressure than you would face at work and b) If working under pressure is so important to the role that they specifically test for it in the interview then it’s probably not a very fun place to work.

The invisible problem of accessibility

In web development, accessibility (or a11y) is considered non-negotiable and rightly so. Yet, when it comes to developer interviews, accessibility goes out the window entirely. Anxiety disorders, neurodivergent conditions, or even just having a stressful day at your current job can transform these interviews into an insurmountable hurdle.

As someone with Autism and ADHD, I’ve found traditional technical interviews deeply challenging. My brain struggles with context-switching under pressure and intense scrutiny. Often, the high-stakes setting amplifies anxiety to the point where basic questions suddenly seem impossible. Give me 10 minutes alone, and I’ll solve problems easily but on the spot, under observation, everything collapses into chaos and I'll struggle to remember the difference between let and const.

This isn’t just tough - it’s discrimination. By designing processes that favour candidates who thrive under artificial stress, we’re silently excluding brilliant developers whose minds simply work differently.

If your company wouldn’t think twice about putting in a wheelchair ramp for someone with a physical disability then they should also have the same attitude towards people with mental disabilities.

Common excuses for not taking accessibility into account

But we can’t give people an unfair advantage, everyone has to take the same test!

Pardon my language but you can bugger off on this excuse. This is by far the most common one I have heard when asking for accommodations and frankly, it’s bullshit.

You’re not giving us an unfair advantage. You are levelling the playing field. We START at a disadvantage.

If you want to make it completely fair then don’t use the inaccessible and unfair process for everyone, use the neurodivergent friendly version for everyone. That is a proper level playing field.

We’re testing for problem solving / ability to perform under pressure

No you are not. You’re testing for the ability to pass interviews and perform in a social pantomime designed to benefit only a segment of society.

Also, this argument is bunk as a huge number of neurodivergent people (especially those with Autism and/or ADHD) become developers and engineers. We are often great at it, as divergent thinking allows us to see patterns and issues instantly that most would need a lot longer to spot (if they ever did). That same strength helps us to see answers to problems in ways a lot of people wouldn’t think of.

In fact, in the 2022 Stack Overflow Developer survey a whopping 33.6% of respondents identified themselves as neurodivergent (SO stopped asking demographics questions other than age after 2022 but the chances are high that that number has grown since) this is 10-20% higher than the worldwide estimated average according to the University of Edinburgh

There have also been studies that have shown that tech recruiters and employers vastly underestimate how many of their staff are neurodivergent. So, statistically-speaking, you probably already work with one or more neurodivergent people. You may even be one yourself and not know it (I wasn’t diagnosed until I was 40!).

I’m neurodivergent and I was fine with/loved this process!

Good for you! Neurodivergence is a spectrum which means that we all have our own strengths and weaknesses.

Ultimately, all of the excuses just boil down to one (or both) of two things:

1) We discriminate and we don't know/care

2) We can't be bothered to change our hiring practices.

How we can do better

Instead of pointless trivia quizzes, we can craft an interview process that actually test for ability:

Start with a simple chat. Assuming that you are a good developer and a good communicator, just talking to another good developer should show you that they do or do not know what they are doing and align with your working practices.

Don't grill them with technical questions, ask them to talk about a project they worked on. Ask where they added the most value, where they still saw flaws and what challenges they faced.

Look for passion and a desire to ensure things are done the best possible way. This is especially important at sub-senior levels as knowledge and experience can both be gained but attitude is ingrained.

If you want more information then move on with a portfolio walk-through. Let the candidate screen-share and talk through a project they’re proud of; be it a public repo, private code shared in a temporary session, or even a few snippets they send over. Guide the discussion by asking:

• What problem did the project solve?
• Which architectural choices felt challenging?
• What compromises were necessary, and why?
• How would they approach the same problem with today’s tools and hindsight?

You can discuss architecture (if relevant). Ask high-level questions like: "How would you ensure that a component-heavy React codebase is easy to use for existing and new developers" (one of my favourites as it tells me how much they care about documentation, modularity, readability and testing. Hits a lot of boxes in one small question).

Good developers shine at questions like this because their mental models extend towards 'bigger picture' thinking whereas many developers I've met often only consider their own small piece of the puzzle.

Finally, have a post-session retrospective. Offer candidates a few minutes to reflect, then ask them how you could improve the interview process. This fosters psychological safety and demonstrates that you value feedback and collaboration. Don't forget that they are interviewing you just as much as you are them.

Test for communication skills

One thing I have rarely seen interviewers test for - which I would consider to be very important at a senior level - is how they communicate with the product owners, stakeholders etc…

I would argue that as soon as you are at a level where you are dealing with product requirements, communication skills become equally important to the role and yet, the majority of developers that I have met (especially the ‘really good’ ones who would do well in technical tests) are actually not that great at communication.

You can test for this with a few simple questions, here are two that I have used when interviewing candidates in the past:

“A client has asked you to display a long list of data from an API but they don’t want mobile users to see that data. So if they are on mobile, they should instead see a button that when clicked, will load that data for them. How would you handle that request”

The answer I would want to hear is something along the lines of:

“I would probably push back on that request as there is a strong argument to be made that if the data is important, it should be visible on all platforms and should not require the user to perform an additional interaction to see it. If it is not important enough to be shown on mobile then we should question if it is important enough to be shown at all. I would probably recommend that instead of loading all of the data at once, we instead lazy-load it and use either pagination or an infinite scroll to show the data on request”.

This shows me that they are thinking about the 'why' of the problem and not the 'how'. They are not thinking of the cleverest solution to complete the requirement, they are thinking of the end user and how this solution will benefit them.

The answer I would NOT like to hear is a technical answer about how they would use javascript to detect if a user is on mobile or desktop and then present a different view based on that.

People with that answer are often also the sort of people who easily pass coding tests but they are not thinking big picture, they only see a list of tasks. That is not what good engineering looks like.

Another one I like using is:

Your current site has a legacy blog which has grown far larger than originally anticipated. The blog displays ALL articles on the page at once, pulling the data from an API on each page request.

The team has had an idea for a solution to the issue by implementing lazy-loading with a placeholder skeleton for each blog article alongside lazy loading each article thumbnail (along with using the next/image ‘placeholder: blur’ feature) and then either paginating the results or presenting them in an infinite scroll.

It is your job to explain that idea to our stakeholder, who has no technical knowledge, whatsoever.

How would you do that?

I’d want to see an answer that clearly explained the business and user benefits of our approach without getting into the weeds of the implementation. Terms like ‘lazy-loading’ would be used as conversational flourish (if at all) rather than as explanation and it would clearly demonstrate the complexity of the project by talking about it in ways the stakeholder can understand.

Here’s an example of how I’d answer that question:

“We have realised that there are some issues in the way we currently handle the blog section of our website. Right now, all of the articles load in at once, this wasn’t an issue at first as the blog was an experimental feature and we only planned for a handful or articles but now that the blog is commonly used, and has a lot of articles, it is time to update it to maximise the benefit to the users and the business.

We propose that we split the blog up into chunks of say, 10 articles at at time and we only load those 10 articles in at once, we can also make it so that as the articles are loading in a placeholder version of the article appears. This is good for users as it gives them an idea of what the page will look like when loaded but it’s also GREAT for performance as it tells the browser what the page will look like when it’s finished loading which makes its job a lot easier.

We’d then make it so that if the user wanted to see the next ten articles they could click on a ‘next’ button at the bottom of the page (or a ‘previous’ button if they wanted to go back) or a ‘page number’ if they want to jump ahead/back a certain number of pages (basically just like the way that google handles the search results it shows you).

Alternatively, we can make it so that the user simply scrolls down the page and the next set of articles start loading in.

Personally I would recommend the latter in this instance as we can do something called ‘lazy loading’ which only loads the articles that are visible, so rather than loading 10 in at once, we can just load them in one at a time. Not only is this a better user experience as their page will appear to be a lot faster and will get them to the information quicker, it will also put less strain on our servers as we’re only loading the necessary data.

This won’t be a super-quick feature to implement as it will require changes to our API and to our website in order to implement this but the outcome will be worth it and we will undoubtedly see a lot more user engagement on our blog. This will also mean we will be able to see actual data about how users are using the blog pages, so not only are we dramatically improving our usability but we are also getting highly valuable analytics data.

Honestly, the answer they give doesn’t need to be that long or even technically perfect, provided that it is not factually inaccurate and sells the feature to the stakeholder in a way that will make sense to them whilst also clearly describing any potential trade-offs or issues we might face (e.g. the time to implement in this case).

It honestly saddens me how many times in my career I’ve had to take over stakeholder meetings because a developer is talking to a stakeholder at their own level and not at the stakeholders level and sees no issue with what they are doing. It once even happened on my first day on the job!

That happens because it’s only the developers who pass the coding tests that get hired which leads to a ‘blind-leading-the-blind’ scenario where all of the devs are working in an echo chamber and have no idea that there is a systemic problem within their team.

If you MUST do a coding test

If you’re obligated to include a technical test, keep it brief, authentic, and respectful of the candidate’s time:

Provide a small repo with failing tests. Ask the candidate to fix them, add one small feature, and document their reasoning. Make it an offline test they can do in their own time and with their own regular tools. Suggest 60 minutes for the task (and make sure it can be done in that time!) but don't enforce the time limit - some candidates would naturally take a little longer, and ideally, compensate candidates for their time - respect costs little, but damage to your company’s reputation is expensive.

Ask meaningful, contextual questions rather than trivia:

• “Describe how you handled your last major incident. What changed afterwards?”
• “How do you decide between using a framework abstraction and writing vanilla JavaScript?”
• "Talk to me about some tech debt you’ve deliberately introduced. Why was it the right decision at the time?”
• “What role do AI tools play in your workflow? What guardrails do you put in place?”
• “Can you share a time you championed accessibility or performance and convinced your team to prioritise it?”

Context, judgment, and communication are what matter in real-world development. Memorising code is simply not a valuable skill in this day-and-age.

Also, if you are obliged to do a technical test, please push back on that decision. You don’t have to blindly follow every instruction and if you feel that something can be improved and you care about the company you work for then you should speak up. Point them to this article tell them I sent you ;)

Make the candidate feel good

I have come out of far too many technical interviews feeling deflated, anxious, useless and sometimes, angry.

Of course the goal of an interview is to find the right candidate and not to stroke that candidates ego but you should still consider their feelings in that process.

Treat the candidate with respect, talk to them like they are a person and even if they don’t meet your expectations, don’t make them feel stupid.

Also, I need to reiterate that you are LIKELY to be dealing with a neurodivergent candidate (probably multiple) at some point in your hiring process. We think differently to neurotypical people, so throwing lots of information at us in an interview and then putting us on the spot for an answer will rarely end well and honestly that’s a real shame as a lot of us are passionate and highly skilled engineers who would be solid assets to any company who would give us the chance.

I've been in a lot of interviews where me taking the time to think has resulted in the interviewer offering hints - this a) makes me feel dumb and b) derails my thought process which actually hinders more than it helps.

If you are giving them a live coding task, let them know beforehand that they can ask questions if they get stuck and then shut up and let them get on with it.

AI is changing the game

Until recently, there was a strong bias in developer recruitment towards “pure knowledge” candidates; the kind of people who could recite the difference between null and undefined, or who could code their way through an inverted sodding binary tree without blinking.

But the reality is, that skillset is becoming obsolete at a rapid pace.

Large Language Models (LLMs) have shifted the landscape. You no longer need a Wikipedia-esque database of syntax and algorithms stored in your brain. You need to know what good looks like and how to communicate your intent clearly to a human, to an AI, and to your future self when you’re staring at your that code six months later wondering what the hell you were thinking.

Knowing how to communicate well is now vastly more important than knowing how to implement merge sort on a whiteboard. It’s about breaking problems down clearly, understanding best practices, and guiding the AI to produce code that’s accessible, performant, and maintainable.

If you want a deeper dive into this, I’ve already written about it here: Mastering the art of prompting for code.

Too long; Didn't read.

The best developers today aren’t the ones who can spot a closure at 50 paces; they’re the ones who can define a problem succinctly, map out (and clearly communicate) a solution, and then either implement it themselves or orchestrate AI tools to assist them without introducing garbage into the codebase and have the ability to identify when it does.

The interview process needs to catch up with this new reality or risk hiring people for a tech landscape that no longer exists.

Great developers debug systems, mentor juniors, negotiate with product teams, automate tedious tasks, and yes, occasionally Google “whats the difference between useEffect and useLayoutEffect” because nobody remembers everything off by heart.

Our current recruitment circus filters for memorised trivia and performative coding skills, like hiring Formula-1 drivers based on who can strip an engine the fastest.

Flip the script. Hire for curiosity, empathy, communication skills and the practical ability to wield modern tools responsibly. If they don't know how to throttle a binary-tree to death then ask yourself if that's actually important to the job they will be doing. If it's not then why the hell are you testing for it in the first place?

If you are still here after what was - let’s face it - a bit of a rant then I thank you for your patience and I hope I’ve changed your mind about your hiring practices or affirmed them if you already do most or all of the above.

Feel free to drop a comment below if you want to add your tuppence worth to the discourse.