Photo by Clem Onojeghuo on Unsplash
Coding interviews are a love/hate relationship for most software engineers. There are radical vantage points on what is the right way to interview an incoming software engineer for a specific or general position. These interviews can be high-level conceptual conversations, screen-sharing interviews (i.e., Collabedit), whiteboarding, paired-coding, or a variety of other styles. There is not a consistent pattern or style of interview within the tech industry.
What does that mean? It means that engineers and developers do not know how to properly prepare for every single interview. These interviews vary drastically different in topic and level of difficulty from company to company.
Common among clients in the past, these interviews center on writing code on a whiteboard while having the interviewee “think out loud” and explain themselves every step of the way. It’s an odd and somewhat dated process, but these interviews aren’t structured this way in order to optimize for modern implementation.
Why Coding Interviews Are Standard
If you ask an engineer about their experience in a coding interview, every engineer’s answer is going to be drastically different depending on their background. It is a very sensitive and controversial topic. You do not want me to repeat some of the comments and stories that I’ve heard over the years. (You may end up with bloody ears or a sore stomach from laughing.) Most engineers believe that technical interviews are not relevant to the actual position, nor do they show the individual’s true technical competency.
And these people have a point — these interviews don’t represent real work. Developers never really have to write in-depth code on a whiteboard during the day-to-day job. In addition, the majority of topics covered in coding interviews are never seen outside of interviews. How often, for example, will a front-end developer specializing in React have to traverse a B-Tree in a specific, algorithmic way? Never, unless they’re doing something deeply wrong.
When a candidate does run into an interview that represents real-world problems that would need to be solved in the day-to-day of the actual position it’s mind-blowing. I have had candidates leave an interview with a coding assignment that they were actually excited to complete because they felt like they would understand the company’s problem and add real value.
Even more aggravating? Coding interviews are often entirely unfair. Even the creator of Brew — with tens of millions of installs — was invited to interview at Google and then rejected because he couldn’t solve a B-Tree problem.
Software engineers love to trick the interviewees and give extremely challenging questions. If you get the initial problem, it’s then common practice for an interviewer to throw a wrench in your solution, make the problem even harder, and create arguably unnecessary stress.
So why are they given?
For all their faults, coding interviews prove three things:
- The candidate really wants the job and has put significant effort into preparation. If an interviewee hasn’t spent the time to get good at the process, it’s quite obvious. Companies want to hire people who put in the effort.
- The software engineer can solve problems and actually code. Engineers who have to copy/paste scripts other people made or who don’t have enough experience with a language will often make big mistakes while problem-solving and coding up solutions.
- The software engineer can effectively articulate their problem-solving. Engineers often will fail to solve the problem, only to find that they actually passed the interview. How? The interviewer decided their thought process was good enough.
How Coding Interviews Vary Across Companies
How a company interviews people is a direct correlation with the quality of talent they attract. The best companies optimize their recruiting processes to reduce false positives. A bad hire that made it through the process will hurt the company much more than rejecting a potentially good hire. The best companies tend to have the hardest interviewing process.
Therefore, when you find that a hiring process especially easy, it’s likely the company has weaker engineering. This isn’t always true, of course, but it’s certainly something to keep in mind.
Since it’s extraordinarily tough to guess which topics will be covered in an interview, the keenest strategy to prepare is to literally prepare for everything. That is, if you really want a great job. Otherwise, ask the recruiters or hiring managers for something to study/prepare prior to the interview. If you need time to prepare, be direct and honest.
#programming #software-development #coding-interviews #coding #interview
