The Real Reason Tech Companies Fail at Hiring Developers
How to fix the technical interview and why most developers hate your coding interviews.
Most tech companies complain that they are having a hard time hiring developers. One of the problems is that they fail to understand that algorithm coding interviews are not effective for most developer interviews and often leads to false rejection. If algorithm coding interviews were only used when necessary, companies would have an easier time hiring developers.
I’ve worked with many developers, interviewed a bunch, and debated with many about this topic. As a CTO and team lead, I’ve interviewed many developers for junior and senior positions. I’m also a senior developer with almost ten years of experience. I’ve done hundreds of coding interviews while applying for various jobs or contracts. I’ve passed many coding interviews including FAANG’s (Facebook, Amazon, Apple, Netflix and Google) — and I’ve worked in startups, medium-sized companies and large companies. I’ve also failed more coding interviews than I can count and wasted hundreds of hours on coding challenges that were irrelevant to the job I was supposed to do.
From my years of experience working with various teams, whether they were local, remote or offshore with language barriers; I’ve found that enforcing best practices was actually more effective at reducing technical debt than hiring a developer who can pass coding algorithm questions. In this article I explain why one of the most polarizing ideas in tech — algorithm style interviews — is not ideal for every type of developers' interview, and why that must change. I’m going to share a lot of things that many developers agree with but are too afraid to share because they might not get hired.
1. Your coding interviews are antiquated and irrelevant
Modern languages changed everything
We need to match coding questions with the state of technology today. In the early days of Pascal, Java, C/C++ where standard libraries weren’t largely available it made sense to often interview for coding algorithms since developers needed to implement things from scratch. But with modern coding languages, and standard libraries this is not as important as it used to be.
Most of the historical reasons for doing algorithm questions are no longer relevant because a lot of this complexity is simplified in modern standard libraries. The majority of the development done in the industry today has more to do with low-level system design than algorithm design, therefore algorithm questions often do not test for skills a developer will need on the job. Learning algorithms can benefit all programmers, but only developers who need to implement them should be tested on them. 99% of developers shouldn’t be tested for something that only 1% of developers need to know for the job.
Modern languages have methods of managing computer program memory usage. For example, Ruby has “Garbage Collection”. The idea behind garbage collection and other memory management solutions, such as reference counting, is that instead of the developer keeping track of which objects are in use by a program, the language does. This means that the programmer can focus on the business logic or other problem being solved rather than worrying about the nuts and bolts of allocating and freeing memory.
A developer using a modern language on the job won’t be reinventing the wheel because of standard libraries – there are already many existing algorithms that already work, this is why some modern language already optimize methods for it. If you’re using a modern coding language such as Ruby or Python with Rails or Django; you benefit from the framework and standard libraries. They provide data structures and algorithms for you. In Ruby on Rails, for example, you don’t need to understand how the :sort method is optimized behind the scene to use it. In cases where optimization is a concern and you need to go behind the hood, you could look for a way to implement your own sort method by googling “what sorting algorithm ruby sort method use”, or view the source code itself; and come up with an alternative implementation.
Most companies love APIs and libraries because they help save time and cost on the development process. So most companies do not expect developers to build everything from scratch — and most developers rely on libraries to speed up development. If you’re looking to hire developers who do not use libraries and write everything from scratch then you can argue that testing them on algorithms, data structures, memory management, pointers, assembly language etc.. is necessary.
Passing a coding algorithm test has nothing to do with being a “Good Software Developer”
The majority of companies hiring developers seem to assume that you cannot be a good programmer unless you master algorithms. This type of thinking is antiquated. When you set this expectation; It’s like saying that you believe that a developer needs to understand how every library or API works behind the scene in order to implement them. When we write code to sort things, 99% of the case, all we’re doing is using a method similar to :sort. Programming is strictly arranging algorithm. A software developer makes software. The former is a prerequisite for being a software developer but a good programmer does not necessarily make a good software developer.
Hiring a developer who can pass a coding interview does not shield you from shipping terrible code. Bad code ends in production because of poor testing and bad processes. If you think of hiring as a way to reduce technical debt, you’re thinking wrong. If your priority is to reduce technical debt, you can start by prioritizing testing, continuous integration and continuous deployment. You can require that your team enforces coding style with a static code analyzer and code formatter.
Now, I’m not saying that understanding algorithms is useless. Algorithms are fundamental in computer science and therefore mastering them can only be a good thing. But It’s essential that companies better understand what they are testing for when they are using algorithm style questions during an interview, as it can often be irrelevant.
Developers do not need to know how to write an algorithm but they need to know when an algorithm is efficient. If a developer writes inefficient code they are wasting space, energy and money — so runtime analysis of code is important. Since efficiency matters, it’s important that a developer does not write code where runtime is slow. So I would argue that it’s more important to test for code analysis skills than algorithm implementation.
2. Developers really hate your coding interview
You’re NOT a FAANG!
There are two main reasons developers are motivated to study for algorithm style coding interviews:
- 1) To get into FAANG (Facebook, Amazon, Apple, Netflix and Google)
- 2) To be paid like a FAANG
Only these two reasons would justify spending months studying and preparing for algorithm style interviews — because as soon as we get hired, the pay justifies the time investment. When we’re not planning to interview for a FAANG company; it’s very unlikely that we’ll prep for that interview the same way; in general, we tend to just wing it for smaller companies— because it’s not worth it for us to waste hours of unpaid time to study for an interview that will pay us average or low rate when there are plenty of opportunities on the market.
If you’re not a FAANG, and you can’t afford to pay like a FAANG, then stop trying to hire like a FAANG.
If you want us to make the effort, and you’re not a FAANG, then you must pay like a FAANG. Algorithm style coding interview might work well for FAANG, but the rest of the tech companies are throwing away valid applicants unnecessarily by blindly copying this interviewing style. And often they are throwing away candidates who could have passed the interview if they had the motivation to study for it. If you’re not a FAANG and you can’t afford to pay a developer top rate salaries then stop trying to hire like FAANG.
Your coding interview makes experience irrelevant
A recruitment company once admitted to me that “Junior developers tend to do better at coding interviews than senior developers.” Yes, senior developers with years of experience can suck at coding interviews. Junior developers who are fresh out of college just finished studying algorithm fundamentals in order to graduate, and they are hungry and desperate to get their first job. So in the hunt for new opportunities, they spend hours prepping for coding interviews. While a senior developer who has years of experience in the field, is not subject to the same amount of pressure; they believe that their experience will be proof of their capabilities and prepping hours for an unpaid coding interview is a waste of time.
When a developer has years of experience in a field, with finished projects you can reference, domain expertise interview is more relevant than any coding algorithm.
There is no good coding, only good refactoring
I can think of two reasons people pass coding interviews:
- 1. They’ve seen the questions before or solved a similar problem in the past
- 2. They’ve studied the heck out of coding algorithms ahead
You should not assume that a good software developer will be good at coding algorithm style interviews. Most developers don’t write perfect code, they consistently refactor them. So what are you really testing with your coding algorithm tests?
You’re testing for someone that is used to solve similar problems perfectly, by using similar solutions for solving them. Most tech problems are neither coding algorithm problems nor problems you’ve seen before, and most problems don’t have a perfect solution.
Writing good code can take time. Codes are never perfect — and are consistently refactored — so why do we test for perfect answers? I’ve never worked at a company with code that did not need refactoring. This is because the perfect code doesn’t exist. There will always be room for optimization. Coding is similar to writing in the sense that just as much as writing is rewriting, coding is refactoring. The best writers rewrite, and the best coders refactor.
3. An alternative way of hiring developers that developers will love
Since developers complain that most of the interviews they go through are rarely related to what they will be doing on the job, there should be more interviews that test developers' ability to work on an existing codebase. This can be achieved in two different ways:
- Companies could invest in small projects used specifically for interviews that cover the skills they are interviewing for
2. Assessment Platforms like Codibility could start providing Interviews that are based on small applications that emulate real-life scenarios where the focus isn’t just data structures and algorithms but harnesses real-world tasks, including refactoring, bug fix and optimization. (Eg. Qualified.io)
Data structure and algorithms
Instead of testing developers for sorting algorithms which they almost never use on the job, give developers a sorting task that is very likely to happen on the job.
Some examples include but are not limited to:
- Build your own implementation of a calendar
- Build your own implementation of a clock that uses timezone
- Build your own implementation of delayed job system (queue)
It will allow you to review their implementation of loops, or recurring methods and see how they would actually solve that problem in real-life cases once they’re hired.
If the job they will be doing will involved implementing sorting algorithms from scratch, then of course they should be tested on those skills. If that’s the case, then Leetcode style algorithm would be perfect for that.
Technical skills interview
To test a developer technical understanding:
- Ask them to review an application, explain what the code is doing, how it could be optimized, then implement it.
- Ask them to review a code on Github and provide feedback in the comment
- Assign them a ticket from a test project and ask them to resolve it. You can then follow up with Github comments and see how they handle it.
To test a developer's technical reasoning:
- Ask them to review an open-source project and write a detailed answer explaining the application architecture, then what they would do differently.
- Ask them to review a project, explain the architectural choices and what they would do differently.
- Ask them to review an API service and explain how it works, and what they would do differently
- Ask them to review a Client application consuming 1–2 APIs and explain how it works, and what they would do differently
To test a developer coding skills:
- Give them a small on-site or take-home project
- Ask them to build their own implementation of a method
- Ask them to build their own implementation of a client consuming an API
- Give them a paid project to fix an issue on an open-source project
- Ask them for their portfolio. Companies could save hundreds of hours by just reviewing developers' public projects.
- Ask them for their open-source contributions. Many developers are actively contributing to open-source projects, and if those projects were more often used as a way to access coding skills that would actually be a huge incentive for more developers to contribute to open source)
To test the developer’s expertise with an API library:
- Ask them to show previous integration of the library
- Ask them to write an implementation as a coding interview
- Ask them to write a simple REST API service that utilizes the API library
- Present them with a problem similar to the one they would encounter on the job and evaluate how they think about fixing the problem.
To test a developer debugging skills:
- Present them an issue that your team experienced before, and see how they would fix it.
- Give them a test application with 1–3 bugs and ask them to fix them. If you want to test their ability at optimizing code and performance you could also use this approach.
4. The only thing that matters
Finding a developer that can solve algorithm coding interviews is not what matters; If that’s the hammer you are looking to add to your team, I have news for you: In web development, every problem doesn’t look like a nail. I’ve worked with many bad coders that were good at solving riddles and problems, and terrible at figuring out issues on the job.
What matters is finding developers who are diligent, who can implement business logic, are eager to learn and open to feedback. And if you’re looking for someone with experience, you want to work with someone who has a lot of domain expertise, who is still willing to learn and has the ability to use that experience to solve new problems.
If everyone is doing it, that doesn’t mean it’s not broken.
The quality of talent you attract also depends on your company’s interview process. Your company can use the coding skills assessment process to give candidates a strong initial impression of your engineering team’s culture. If you’re having trouble hiring talents, maybe it's time for your organization to re-evaluate the hiring process. You have to start asking yourself if your coding assessment matches the requirements you listed on the job description.
When your top candidates keep failing your coding assessment, you should start to wonder: How many automated coding algorithm interviews lead to false rejections?
Share this article on LinkedIn if you believe hiring in tech MUST CHANGE.
Like this post? it would mean a lot to me if you hit the 👏 button so that more people can read this article.
Stuff I also wrote
- The obscure world of Jruby — JRuby with Rails Under a Microscope
- Where Ruby ends and Rails begins
- How to land your first Ruby on Rails job.
- How I TRAINed to learn Rails: A Guide to Learning Rails in 2 months
- Where to learn HTML and CSS and build your first website
Feel free to send me a tweet: @Richardsondx
—
Richardson Dackam is a senior full-stack developer freelancer who often works with companies as a part-time CTO or Team Lead. Through his company RICH DX STUDIO he helps build and maintain custom applications and automate back-end processes.
