If you’re going to determine my skill level as a developer by merely testing whether I can do something that an AI tool can do, go ahead.
But I’d rather look for opportunities that go beyond that.
Tech job interviews are meant to assess a candidate's suitability for a role, but some outdated practices do little more than create unnecessary stress and anxiety. One of the most glaring examples of this is the interview format where you're handed a blank code editor and expected to solve a problem using an abstracted, unseen function. These types of interviews often test nothing more than your memorization skills - an approach that is not only outdated but also counterproductive.
The Problem with Memorization-Based Interviews
These types of interviews amplify a phenomenon known as "coder's block." This is a situation where, despite your deep understanding and experience with a programming language, you freeze when expected to produce code in a high-pressure environment. The stress of having to recall syntax and solve problems from scratch, combined with the expectation to use a vague, abstracted function, can severely inhibit your ability to think clearly and logically. Instead of assessing your problem-solving abilities, these interviews often become an unfair test of your ability to recall syntax under duress.
The Abstracted Function
A common issue with this interview style is the use of abstracted functions. Interviewers often present these functions as "helper functions," but how much of a help are they really? You're expected to imagine how this function is written without any useful context. This is problematic because, in reality, the function could be implemented in numerous ways, and your interpretation might not match what the interviewer envisioned.
This mismatch creates unnecessary confusion and frustration. Instead of focusing on solving the problem, you're left guessing how the abstracted function behaves. How often, in a real-world job setting, do you have to code in such an isolated, context-less manner? The answer is almost never. In your day-to-day work, you have the context, documentation, and the ability to explore and understand the functions you're working with. This makes the entire exercise of guessing how an unseen function works during an interview both unrealistic and unproductive.
Memorization vs. Real Skills
At the heart of this interview style is the assumption that being able to write the correct syntax from memory equates to a strong command of a programming language. This is a flawed assumption. The ability to memorize syntax does not reflect how frequently you've used it or how well you understand the underlying logic. You might have written a for loop a thousand times, but in the stressful environment of an interview, coder's block might prevent you from writing even the simplest code.
Everyone familiar with programming knows about coder's block. It's a common occurrence during interviews, yet it's often dismissed as a sign that the candidate lacks fundamental knowledge. This is far from the truth. What these interviews are really testing is not your coding ability, but your memorization skills - something that is not, and should not be, a core skill for a developer in an age where tools and resources are readily available to assist with syntax.
And then there are the types of interviewers who will go so far as to claim that if you don’t know basic syntax by heart, you couldn’t possibly understand programming logic, so there’s no point in giving you more complex tasks.
Stay away from those as well, because this is a complete fallacy.
Understanding programming logic and solving complex problems require deep analytical thinking and a strong grasp of concepts - not rote memorization. Logic is about how you approach a problem, break it down, and think through solutions, not about whether you can instantly recall a piece of syntax. Memorizing syntax is just a small, mechanical part of coding, something that can easily be supported by tools or references. Not remembering syntax has no bearing on your ability to handle more advanced concepts; it’s just a weak excuse to prevent further evaluation.
This is what I call 'screening out,' not 'screening in'.
Dealing With Unproductive Interview Practices
If you find yourself in an interview that tests your ability to recall syntax rather than your problem-solving skills, take note of how the interviewers react. There are generally two scenarios:
Negative: They might criticize you for lacking 'fundamental' knowledge of the language, completely overlooking the possibility that you’re experiencing coder's block. Instead of adapting the challenge or trying a different form of evaluation, they rigidly stick to the original test, missing the opportunity to fairly assess your true skills. This often stems from the interviewer's own inability to create a new challenge on the spot or their reliance on pre-prepared answers, which limits their capacity to evaluate creative or unconventional problem-solving approaches.
Positive: They recognize that you’re experiencing coder's block and offer assistance to help you break through it. They may encourage you to write pseudocode, explore different concepts, or approach the problem from a new angle, which reflects a more understanding and supportive work culture. This response typically comes from a more experienced developer who can adjust and create a new challenge on the fly, demonstrating flexibility and a genuine interest in assessing your problem-solving abilities rather than just your memorization skills.
However, my advice is to stay away from such interviews altogether. They deliberately put you in a disadvantageous position, and there's little to no benefit in putting yourself through that. Instead, seek out interviews that test your ability to work with a codebase, understand logic, and apply your knowledge in practical ways.
Rather than memorizing syntax, focus on developing your problem-solving skills and your ability to understand and work with different approaches to a problem.
If avoiding these types of interviews isn't an option due to financial or other constraints, I also offer supportive free of charge mentorship sessions, and premium mock interview sessions, to help you prepare and adapt while ensuring you're practicing in a safe and constructive environment.
More Effective Option
A far more effective interview format would involve giving the candidate two sets of code - two different implementations - and asking them to choose which approach they would take and why. This method is superior for several reasons.
First, it shifts the focus from rote memorization to critical thinking and problem-solving, which are the true indicators of a developer's skill. By comparing two implementations, the candidate is encouraged to engage with the code at a deeper level, analyzing its logic, efficiency, and appropriateness for the given context. This approach also helps prevent coder's block by providing a concrete starting point, rather than a blank screen that can trigger anxiety and mental blocks.
Moreover, this method tests a candidate’s ability to work with the language in a meaningful way, rather than just their ability to recall and write syntax out of context. It reflects real-world scenarios, where developers often need to evaluate existing code, understand its nuances, and decide how to improve or extend it. In doing so, the interviewee demonstrates not just their familiarity with the syntax, but also their understanding of best practices, design patterns, and the trade-offs involved in different coding approaches. This is a far more accurate measure of a developer's ability to contribute effectively to a team and solve real-world problems.
I strongly believe that memorization is not a skill that developers should be expected to excel at, especially in a world where we have so many tools available to assist with syntax.
If I find myself in an interview that emphasizes memorization in any form, and the interviewer quickly jumps to conclusions without considering potential underlying reasons, I immediately reconsider whether that job is the right fit for me.
If there’s already an AI that can handle the job of recalling syntax and basic functions, why is the company testing whether I can do the same thing?
At this point in time, shouldn’t the value and expectation come from what I can do that the AI can’t ???
Things like creative problem-solving, critical thinking, and working effectively within a real-world context?
We all know that AI, at this point, struggles with understanding and applying context. So why should there be so much overlap in our roles? If we're both expected to do the same basic tasks, it’s no wonder people worry about AI replacing developers.
Instead, why not divide the tasks more sensibly? Let the AI handle the routine, context-free tasks, while we, as developers, focus on what AI struggles with -navigating complex, nuanced problems that require a deep understanding of context and a creative approach.
I prefer to seek out opportunities where my true skills are valued and tested in a realistic and supportive environment, and I encourage others to do the same.
It’s time to rethink how we assess developer talent - let’s focus on what really matters.