Candidates: Please prepare!

(Like this article? Read more Wednesday Wisdom! No time to read? No worries! This article is also available as a podcast).

Here is one of the banes of my existence: Experienced and good candidates who do not adequately prepare for interviews.

To be fair, experienced people often ask themselves (and me) why they should prepare at all: They have a great track record and lots of experience. Doesn’t their resume speak for itself? Why should they prove to someone that they can invert a binary tree or design a key-value store? And, all things considered, should they really be working for a company that asks them these dumb questions and that seems to be unable to divine their awesomeness from a resume and a handful of reference calls?

The answers to these questions are: No, see below, and probably.

Starting with the first question: Your resume does not speak for itself. It might look great (and I hope it does), but unfortunately almost everyone has been to resume school and with the help of a template, a tool, a coach, and ChatGPT, even total nincompoops can write compelling resumes. Furthermore, people lie on their resumes, or at least embellish them, and so companies would be foolish to rely on the information in resumes alone. Another reason your track record does not speak for itself is that our industry is huge these days and so, with very few exceptions, everyone is a nobody. I worked at Google, Meta, and Amazon, but so did more than 100,000 other engineers. Why would I expect anyone to know me unless they are in a very small group of people whom I worked with directly and who can say something meaningful about my work?

What about referrals then? Why go to the trouble of interviewing candidates who are referred by people who are already at the company? Surely your current employees can be trusted to refer only the best and brightest that they ever worked with?

Unfortunately: No.

Referrals are great and referrals from existing staff are consistently the best performing source of new employees. But even referrals only have a pass-through rate of 50% (or so my recruiting friends tell me). Apart from reasons yet to discuss in this article, the main cause of this drop rate is that referrals are often (too) easily given. When it comes to referrals, I am considered a bit of a hard ass: If we never really worked together or you just reached out to me on LinkedIn, I typically do not refer you. But, even I want to be nice to people sometimes, so if a former colleague whom I worked with some years ago and whom I vaguely remember, asks for a referral, I will usually put one into the system.

So, for better or for worse, companies need to interview. Unfortunately, as I wrote in a guest article on interviewing.io last year, not all interviewing that we see in the wild is good interviewing. That is sad, but also understandable. Good interviewing is hard and, for a variety of reasons, most companies I know do not spend nearly enough time training their interviewers and making sure that they do a great job.

Except for my current employer obviously, where all the interviewers are nothing short of amazing.

In terms of interviewer training, the best a candidate can typically hope for is that they get an interviewer who sat through a two hour training on how to prevent being sued for whatever happened during the interview and who has done a few interviews shadowing and being shadowed by another interviewer. If the candidate is extremely lucky, they will meet an experienced interviewer who is prepared and who is trying to do the best job possible. But they can also meet someone who is significantly more junior, who has done five interviews in their entire life, and who has little clue about what they are doing.

The problem is that, as a candidate, you never know who you are going to find on the other side of the virtual table. It might be an amazing interviewer who is able to engage you in a deeply technical discussion through which they are able to figure out your knowledge, skills, and experience. Or it might be a junior interviewer who is just looking to see if you hit all the points that are written down in the lead sheet for the pre-canned question they are asking. And since you don’t know this in advance, your best bet is to prepare well for all types of interviews and interviewers you might encounter. This means not relying on a great interviewer recognizing your excellence, but instead spending time on some good old fashioned preparation.

Let’s start with the coding interview.

Almost all companies that are hiring software and system engineers are doing coding interviews and rightly so. Whatever the details of your job, our field concerns itself with making computers do useful things and that always involves code. You might not be writing code every day or maybe not every day anymore, but if you work with computers at our level, you need to be able to code in order to be effective.

A lot has been written about the terribleness of coding interviews and I agree with most of it, but the fact is that you will probably be treated to one or two coding interviews during your job application and it is imperative you do well on them. Unfortunately, most coding interviews still work the way Google instituted them in the early 2000s: You get 45-60 minutes and a problem: Go! It is up to you to solve that problem in the time allotted and, and this is important, to solve it in the way the interviewer wants to see it solved.

An entire industry has sprung up to help candidates prepare for exactly this format. There are books, websites, and mock interview programs that prepare candidates for the standard coding interview. An unfortunate side effect of all of this candidate support is that it not only helped candidates do better, it also shaped the expectations of most interviewers. All interviewers were candidates at some point and a lot see it as their job to interview in the same way and to the same standard as they were interviewed way back when they got the job. This sad fact entrenches the current way of interviewing and adds to the already massive inertia that hiring systems are subject to.

As a candidate you might think this is all terrible, and you might well be right, but you have precious little influence over how companies interview. For better or for worse, this is the game and the only question is whether you will play it or not.

Preparing for coding interviews mostly comes down to practicing with well known interview questions. Sites like leetcode are perfect for that, but there are many others like “Advent of Code” and CodeWars. Senior engineers often scoff at the idea of preparing for leetcode style interviews because that style of coding has so little to do with what they actually do for a living. They are right, but again, it doesn’t matter. Most companies do some form of leetcode style coding interviews and if you want the job, you’d better be good at that. I have been coding professionally for almost 37 years and I prepare. Every time I am gearing up for interviews, I spend many evenings slogging through standard coding problems in order to sharpen my skills and dig up long forgotten knowledge about algorithms that I have never ever used in my professional career.

By the way, even if you run into a company that is smarter than average when it comes to coding interviews, practising leetcode style coding interviews will help you do better at those good interviews too!

When preparing for coding interviews, you are well advised to prepare to do your coding interviews in Python.

“Wait, what now?” I hear you think: “Weren’t you the person who wrote that Python is a terrible programming language?” Yes, I am, and yes, it is. But that is not important right now. Unless the job you are interviewing for requires expertise in a specific programming language, most generic SWE interviews are overindexed on the use of Python, even if the role itself requires little or no Python. Lots of reasons for that and if you know any Python, you can probably figure out why it is so popular for interviews.

Coincidentally, I also wrote an article on why Python is also amazing 🙂

I sometimes run into candidates who think Python is crap, about which they are right, and therefore they want to interview in C++ or Rust, about which they are wrong. Unless the interview is specifically to test your knowledge of C++ or Rust, using these otherwise amazing languages for interviews is asking for trouble in situations where the interviewer expects Python style performance during the interview.

Python is great for writing more-or-less working code fast as it doesn’t care much about types, memory allocation, and other things that are hard to get right, but important to get right in production code. In C++ and Rust, writing code is slower, but once you get there, the code is better. Unfortunately, this is not what most interviews optimize for. A great interviewer can totally deal with this and adapt the question to the language and adapt their expectations accordingly, but most interviewers are not great interviewers! Too many interviewers get a lead sheet with a pre-canned interview question and are looking if you hit the points that are on that sheet. If you complete only part one of the question that is a strike against you, even if the code you wrote for that part is fast, type safe, thread safe, does not leak memory, and does not suffer from garbage collector induced performance problems.

This is obviously a terrible state of affairs, but this is the reality for most interviews. You can lament about it all you want, but this is the game we are playing, whether you like it or not.

The other types of interviews need similar preparation. Let’s look at system design interviews. As is the case with coding interviews, it is hard to pass a system design interview if you have little or no practical experience with the subject matter. But, even people who do have that experience regularly fail because their interview strategy is suboptimal.

In a system design interview, you typically get an underspecified question and you are asked to design a system for solving that particular problem. However, the key aspect of any system design is tradeoffs, and which tradeoffs you should make is dictated mostly by the specifics of the problem, which are usually not specified in the question. To learn these details, interviewers expect you to engage in a round of requirements gathering where you need to figure out all the relevant details, usually things like: How large is the user base? Where are they located? What do they expect with respect to latency, consistency, and integrity? How much data is involved?

A shocking amount of candidates do not engage the interviewer in requirements gathering but instead immediately start shooting from the hip, making assumptions about the details that drive the specifics of the design. Your assumptions might be reasonable, but the absence of requirements gathering is a problem in itself! Another problem I often see is that candidates introduce magical components in their design.

Magic, as you might recall from Harry Potter, is a way of doing things without understanding how they work. Witness the following dialogue from chapter two of “Harry Potter and the Methods of Rationality” where Harry sees professor McGonagall turn into a cat:

"You turned into a cat! A SMALL cat! You violated Conservation of Energy! That's not just an arbitrary rule, it's implied by the form of the quantum Hamiltonian! Rejecting it destroys unitarity and then you get FTL signalling! And cats are COMPLICATED! A human mind can't just visualise a whole cat's anatomy and, and all the cat biochemistry, and what about the neurology? How can you go on thinking using a cat-sized brain?"

Professor McGonagall's lips were twitching harder now. "Magic."

A magical component in a system design does just that: It solves an important problem in an unknown way that a knowledgeable observer (the interviewer) will have all sorts of questions about. You, the candidate, better have all the answers. If you don’t, that is a strike against you. The magical component might be the right component for the job, but if you don’t understand exactly why it is the right component, the interviewer will be unimpressed.

Back in the days, candidates would often throw an Oracle Real Application Cluster (RAC) into the mix, which opened them up to all sorts of questions on how RAC really works, how it scales, how it guarantees consistency, and what the optimal data model for the problem is.

As is the case with coding interviews, a system design interview has expectations about the method the candidate uses and the acceptable outcomes for the design. The best way to get the answers right is to know what the interviewers want to see and how they want you to organize the design process. Fortunately, there are books and websites about this too. You should read those, because your in-depth knowledge of distributed systems won’t do you much good if you do not follow the well-established recipes for the interview.

Which brings us to the dreaded behavioral interviews. The purpose of these interviews is to figure out how you work by asking questions that often start with the sentence: “Tell me about a time when…” If you have more than just a few years of experience, it will be hard to a) come up with the best anecdote on the spot, b) phrase your answer in an easy to digest way (for instance using the Situation, Task, Action, Result (STAR) method), and c) frame the whole story in a way that matches the culture of the company you are interviewing with. Fortunately, preparation can help here too. When I interviewed with Amazon I created a Google Doc with the most popular behavioral interview questions and I spent a few evenings formulating the “perfect” answers to each of them. The night before the actual interview I read that document and during the actual interview I kept it handy, which made the entire behavioral interview a cake walk. Of all interview types, the behavioral interview is probably the most difficult to do well at without preparation.

Then, last but not least, there is the technical deep dive interview. This is an interview where the candidate showcases a technical project they worked on, interspersed by questions from the interviewer. There are very few people who can give a good off-the-cuff presentation on a complicated topic without preparation and you would be foolish to yolo it. I really, really, advise everyone to prepare a presentation, with slides, speaker notes, and all, and, use that presentation during the interview. This is the only way to be sure that you have a logical and easy to follow narrative that hits all the right points. It also shows that you are taking this whole interview thing seriously, which is never a bad impression to make.

If you are unsure on how to structure your narrative I have two tips for you. First, it is never a bad idea to use the aforementioned STAR method (Situation, Task, Action, Result). It might not be the most innovative way to structure a presentation, but you are not there to get points for creative writing. Next, I can recommend the fantastic book “Made to stick”, which contains boat loads of advice on how to structure stories to make them compelling and easy to remember.

Oh, and here is another TDD interviewing tip: Avoid the word “we”. One of the things that the interviewer will be looking for is what you did, which problems you solved, and what you contributed to the project. By constantly talking about “we”, it will be unclear to the interviewer what your personal contribution was and that is actually what they are interested in!

I understand that all of what I am asking you to do might seem like a lot of work and, let there be no mistake about it: It is! But, you gotta remember that at this particular point in time, competition for good jobs is sky high and the companies who are still hiring are very picky. I myself have sat in on hiring committees that decided to pass on candidates that not too long ago would have been scooped up in an instant. Interviewing is a skill and, much like penalty shootouts during major soccer tournaments, can be trained. Raw talent helps, but in a pinch, preparation beats talent and experience nine times out ten.