I’ve recently subjected myself to what the software industry lovingly refers to as the “technical interview” process. The claim is that by asking complicated puzzle or algorithm questions, you are guaranteeing the top candidates. Across the different fields I have prepared to interview for. It is by far the most time-consuming. The expectation for your own free time to prepare for the technical interviews is genuinely unprecedented. You speak to others in the industry, and everyone agrees they are horrible. Yet, no one knows how to fix them. These are my thoughts on why technical interviews need to change and why it fails to keep its claim for the top candidates.
The Technical Interview
It generally consists of the following flow:
- A conversation with a recruiter
- (optional) A conversation with the hiring manager to see if you’re a fit
- A phone screen that consists of a puzzle type algorithm
- An on-site screen that generally consists of 4-6 hours of puzzle algorithms. They may replace one or two of these time slots with something more focused on engineering design or architecture
Preparing for technical interviews
The format is geared to try and filter you out on the phone screen. On-site screens are expensive and costly for a team to commit. The overall theme of the interview process resonates around algorithmic puzzle-solving interviews. The market of job seekers has established well-known preparatory practice routines to survive the process.
Over the last number of years, golden guides or handbooks have risen to be king for preparing for technical interviews, such as the Cracking The Coding Interview book. (I often jokingly call Cracking The Coding Interview the software engineer’s tech interview bible). Leetcode is another critical resource, which is a collection of algorithmic puzzles that have been reported from technical interviews. There are many other resources geared to help software engineers and developers pass these hurdles. I’d argue there is a whole meta industry now forming to help developers pass these interviews.
The software developer’s Leetcode arms race
Various resources around the internet have suggested one must answer at least 300 problems on Leetcode to prepare themselves for the algorithms’ difficulty. (Such as this one by Mohsin Ali, which is a great one to prep.) A recruiter from a large social network company told me the expectation is to pass two Leetcode medium questions or one Leetcode hard question to perfection in 40 minutes or less.
To make matters worse, unless you are practicing on Leetcode often, you lose these skills. If you get absorbed into learning other things like being proficient at your current job, you’ll find yourself a non-hireable engineer. Next time you hit the job market, it might be another 300 hours. Not to even mention, by then, the race to be the best interviewer may have made the questions even harder.
I heard that this style of interviewing is all about “trying to see how you think.” However, these problems are not the kind of problems one has to solve daily. Especially with a whiteboard and without preparation or a support team.
The difficult process inspires many good developers not to enter the job market
Most engineers do not continue to practice and prepare to solve algorithmic puzzles; why waste time. There is bigger fish to fry. They optimize to be excellent at their day to day craft.
When experienced engineers want to hit the job market, they are now penalized by the need to be experts in solving algorithmic puzzles. When compared directly to others that may have already prepared 300+ problems of Leetcode, they will fail. (At least without also having to study ~300 problems to compete against others with a high bar of study time). This on the fly puzzle-solving is not how most engineers think. When everyone knows they need to prepare 300 hours, the interview process suddenly does less of a job filtering people out. What do the interviewers do? They incorrectly learn that they should make their questions more tricky.
Trading time to become artificially good for technical interviews
We see a nuclear arms race of technical algorithm capability. While there may be certain individuals who have a high IQ, enjoy algorithmic puzzle questions, or have committed to being a top coder to game the technical interview system to their advantage. For everyone else they have a hard time spending weeks on end studying and preparing. Most succumb to repeated failures and hair-pulling frustration. Some of the processes seem to be the luck of the draw. Different interviewers may ask questions you crush or get crushed by. Perhaps you knew the question from prior studying. Perhaps you can’t explain why but it just wasn’t your day (we’ve all been there). The whole thing is F*ing ridiculous.
How technical interviews need to change and to fix this mess
How on earth do we fix this mess, and how long can the arms race continue? Let’s claim mutually assured destruction (MAD) and end it already! But how can we find the best candidates otherwise? Let me provide my opinion on what I believe is the right way for employers (and, by proxy, the interviewees).
First, figure out what kind of candidate you are looking for. Check out this prior article that highlights 2 different prominent skill sets the industry needs to think more on. Once you know you’re looking for an engineer or a developer/coder, then you have two established paths forward.
Developer focused interviews
A coder/developer will need to be much more proficient at coding to succeed in productizing the blueprints. Communication is important but less critical than for the engineer (not that it isn’t essential); at this point, the scope is more transparent and objective from the blueprints. If the engineers that created the design are reasonable, there will be little to no unknowns. The interview process should focus on programming languages, features, evaluating performance (big(O) of memory and speed), knowing performance concerns around the specific area, building tools, making unit/functional tests, and ensuring quality in the product. After 2-3 hours here, you should have a good feeling this individual is worth being on the team.
These types of questions dig a lot more into the individual’s behaviors. Their personal thoughts on how the process should be. This, at the very least, inspires a dialogue between the interviewer and interviewee. From there, that will allow one to dig in and truly see how they think. Further, their technical aptitude can be explored throughout this conversation.
Engineering focused interviews
An engineer must be capable of thinking about the blueprint; they need to express themselves well with others and work with people to understand the problem space. Design questions focused on building products and understanding the system design, architecture, and design patterns would be adept. I figure 2-3 hours of these questions would be enough to tell you if they are proficient enough at their craft for your team.
How employers can better attract talent
Be sure to have your senior staff conduct the interviews. The more experienced engineers and developers will have a stronger gauge of what to look for. I can’t count the number of times I interviewed by a junior interviewer that gave a strong impression that they did not want to be interviewing. They spent time on their phone or laptop, and overall gave me a negative disposition of the work environment. I was asked to solve some arbitrary puzzle algorithm on the whiteboard. Minimal stimulating conversation was had over the team, the culture, the projects, and the environment. Sadly this happens so often it almost seems the norm.
Also, by nature, it gives a better idea of who the established tech leads or generally influential team members on that team are. They should provide the value to attract the interviewer more to the group by showing that the more senior staff are inviting and can work well with the interviewee.
Get rid of algorithmically complex questions
Further, I know there are plenty of you out there who love your algorithmic puzzles. Do consider toning them down several notches. If whiteboard coding is involved, it should be focused on being a “fizz buzz” coding question where you are only throwing a minimally complex algorithm at the interviewee. This will show “can they code and how does it look.” Treat it like a code review rather than a coding challenge—problems involving knowing the right data structures or library APIs to use the fair game. Suppose the focus is on using something built-in to common SDKs and knowing what to use for the right situation.
Associate the interview questions around the actual work
Most importantly, coding and design questions need to be associated with the work that the candidate is being interviewed for. For example, you are hiring someone to fill a specific need on the team. Be it a new feature or on-going work. Introduce the candidate to this piece of work, what’s coming, and see how they might tackle some of the real problems associated with designing or building it. This takes a touch more preparation on the interviewer’s bit and can be more subjective. If the interviewer and interviewee connect with confidence over these questions, it is a strong indication that they will do just fine on the job.
The expectations for what the interviewer conceptually accomplishes should capture a small part of what they will be expected on the job. For example, the interview may be around thinking of a solution or coding a function to solve a scoped problem. By the end of it, review together as you would being part of the team.
You (the interviewer) will see how the interviewee takes criticism, how they work with you to solve real problems, and then take constructive feedback on how things could be improved. This collaboration is the type of engagement that is missing in most interviews as they are today.
The movement to change technical interviews starts with you
I’ve interviewed several candidates over the last number of years and get the challenges of this industry. I’ve moved to this more collaborative model to encourage better communication, personality, engineering rigor, and more insight on the job ego. Quite frankly, I would never go back.
It will take a movement to make the change the industry standard, though. There is no need to change in general until the demand is there for businesses to do so. So it is all up to you (the interviewers out there) to demand change and refuse to interview at these companies sticking with the Leetcode race.
Ensure you communicate that you feel their style of the interview process is too much of a chore and won’t highlight your strongest attributes. You can even suggest to them to look at the method I pitched here. Look for companies trying a fresh and new approach to the process and find a team with a good fit amongst the businesses pioneering a better interview process.
Employers also need to drive the change
If you are an interviewer, talk to your co-workers and see if you can adopt this better approach (or develop something you consider to be better). Think beyond for things that may apply to your team and what will work for them.
The interview is a two-way street; you want to get a good idea of how and who the candidate will be on the job and want to get a good idea if they are a good fit for the job and the team. Don’t mask this information, and you will find the right candidates, not just the ones that have studied the most. Do you want your only bar for the job to be “study x hours and you get the job”?
Let me know your thoughts in the comments below; do you agree? If so, I’d love to hear if you have more ideas to drive the change. Do you disagree? If so, do you acknowledge there is a problem? Do you feel it is optimal as is (and why)? I may write more on this subject and dive deeper into specific topics discussed at a high level here in the future. Let me know if there is any interest. Check out my other opinionated articles written here.
