Tech Interviews are Broken
Full Disclosure: It's important to do whatever is necessary to succeed in interviews. While we acknowledge that interviews can be flawed, the reality is not always what we would like it to be. The true purpose of this article is to encourage change in the interview process and to offer a different perspective. If you are an engineering manager or tech lead reading this, please read till the end to understand why the interview process needs to change.
Note: This article might apply to hiring more experienced folks rather than people fresh out of college. But the general principles apply to all.
Introduction
This article is not clickbait or a rant but expresses a genuine concern I have regarding the direction the tech industry is headed in.
I can't speak for the MBA or medical exams, but Chat GPT was able to clear a Google tech round interview. However, it's important to note that Chat GPT is not equivalent to or better than a human. GPT and other generative AI models learn from existing data. If Chat GPT was able to clear the interview, it means that similar questions have already been asked before.
These days, tech interviews are mostly about pattern matching. This is not to say that learning computer science fundamentals like data structures and algorithms isn't necessary. However, solving problems within a specific time frame, such as one hour, is not necessarily a test of knowledge, but rather a test of whether you can quickly whip up a solution within that time limit. It's not a test of knowledge, but a test of whether you can recall the appropriate pattern. For example, it's close to impossible for anyone to solve algorithms like Floyd's cycle-finding algorithm within an hour.
Real-World programming is different
One of the main reasons I dislike LeetCode-styled interviews is that they do not reflect real-world programming skills. When was the last time you had to invert a binary tree on the job? Here are some of the most crucial skills required for a job, which are not necessarily tested in interviews:
Understanding and working with a large codebase.
Most companies have existing codebases that require constant improvement, feature development, and maintenance. Having a balance between what needs to be done and what should be ignored is a crucial skill.
Language internals.
Understanding programming language internals is the difference between a novice and a senior developer. Knowing how Go-Routines and Channels work in Golang and implementing advanced concurrency features are important for building complex and scalable systems. This skill is not only specific to one language but applies to implementing concurrency in any language.
Low-level design.
Understanding how to design a business entity that translates to a database table, a class/interface, and how they interact with each other is essential for mid to senior-level developers, and even entry-level developers.
Data Structures & Algorithms.
Instead of asking LeetCode-styled questions, it's better to give a real-world problem like "Design a URL router."
Debugging.
Debugging code is not just running through with a debugger but quickly getting to the root of the problem and saving time for the customer or user. It has a direct impact on software quality.
Communication with stakeholders.
Understanding the problem by talking to the right people first, and then building a solution for the problem, is important when working for a company. Communication and coordination between teams are one of the most crucial jobs of an engineering manager.
System Design and Software Architecture.
Self-explanatory, but read the caveats.
Specific Knowledge
Acquiring the skills listed above is difficult, so testing them is important. Quoting Naval Ravikant -
The most important knowledge can't be taught. It can only be learned by pursuing the things you're curious about.
When hiring someone experienced in the industry, it is a waste of time to ask them textbook algorithm questions. Their experience provides a wealth of information that can be tested on many different dimensions of skill sets. For example:
Why did they choose to solve the problems they solved? Understanding what kind of problems they chose to solve can tell a lot about a person.
How did they shape their career? What are their interests for further pursuit?
Have they made any open-source contributions? Open-source repositories/codebases are extremely complex. Even a one-line contribution requires a variety of skills like reading through a codebase, understanding the problem deeply, coding rigor, and design, as open-source codebases are very selective about it.
How did they collaborate? How did they build their team and hire engineers?
These are just a few examples. There is a goldmine of data sitting in their experience. Leverage them to ask better and directed questions.
Would recommend reading another post of mine -
Caveats & Anti-Patterns
While what I have listed is important, there are anti-patterns to it.
Asking about a specific library function and how it works. This makes no sense; even experienced programmers look at the documentation or consult sites like Stack Overflow or use Github Co-Pilot.
Broad questions don't perform well. This applies to low-level design and system design. For example, I have seen companies ask questions like designing an airport management system, which can be extremely complex and is not practical to ask in a timed interview or as a take-home interview task.
Another example is how to design Twitter. That is an insult to the engineers who work at Twitter because the architecture there evolved over so many years with efforts from hundreds of engineers. If someone can design that without any knowledge of it, then perhaps they should consider immigrating to Krypton. A better version of this is to ask how Twitter solved its fan-out problem. However, this may or may not be an ideal question depending on whether you are near Twitter's scale or have problems similar to theirs.
Assuming the solution and working backward from there is another classic mistake interviewers make. There can be multiple solutions to the same problem, so focusing on whether they arrive at the solution that we thought they should is pointless.
These are just a few examples.
The Ideal Interview
There's no one-size-fits-all approach to interview preparation, as everyone has their own version. Here's mine, which may inspire you:
Be realistic and hire for the right skill sets.
Focus on the thought process instead of the solution. In a timed interview, arriving at a working solution depends on various factors. The focus should be on how the person understands the problem, whether they are asking the right questions, and what assumptions they make.
Take time away from the timed interview. Take-home assignments are an excellent way to assess one's skills. They allow candidates to work at their own pace, which is more realistic and mimics the real world. But make sure that this is not a complex or day-long assignment.
Hire for your own team. I have seen these mistakes in companies where completely unrelated people take interviews. While this is useful for a first hire in a new team, it is not good for a team that is already built. Have a different perspective by taking opinions of screen rounds by different technical leaders but let your own team build organically.
Be human. You're hiring your potential co-worker. It's important to be empathetic and mindful.
Quality over quantity. Software engineers are not factory robots that spit out code. It's easy to calculate your cloud bill because you get a bill. Wrong hires can often result in bad code, improperly built systems that require constant maintenance/re-architecture, and performance issues. Very hard to quantify these but this is for sure more than leaving an EC2 instance on overnight.
Referrals work really well. There's only so much you can evaluate in an interview. There's no better way to evaluate someone than working with them on several projects/initiatives.
And last but not least, hire people who give a shit. Some of the world’s greatest companies were built by people who were passionate about solving the problem.
Remember, people can make or break a company. Spending time drafting the interview process and carefully interviewing people are some of the best ways for engineering managers and tech leads to use their time.