I have interviewed somewhere between 200 and 300 people in my professional career. I’ve learned a lot from the process. In fact, I am planning to write a short book containing some of this “knowledge” about interviewing.
One thing I’ve always had an odd distaste for is interview coding questions based on some ridiculous scenario. For example: “There’s no such thing as a queue, create a queue using two stacks.” or “There’s no such thing as arrays, create a queue with something else.”
Two things immediately happen when presented with this kind of question:
- I get pissed
- I feel sorry for the interviewer
Why?
These types of questions are an attempt to trip you up. “Quick, think outside the box!” These questions are actually really easy, but the intentional psychological disorientation is like a verbal punch to the face. These types of questions are actually no different from saying “I need you to write me a program, but there’s no such thing as keyboards.” It can be done, but the problem has already been solved. This is why I get pissed.
We live in the real world where engineers have access to a wealth of information when we’re presented with a problem. I’ve interviewed plenty of people virtually and told them that they could use the internet if they wanted to while solving a problem. I’m realistic.
Early in my career, I gave an interview candidate a question based on an unrealistic scenario. I admittedly found this question while researching online for questions used by big software companies. The dude aced the question and was hired. He sucked as a programmer. Unrealistic interviews often yield unexpected employees. This is why I feel bad for interviewers who haven’t yet understood this. In case the message isn’t clear: unrealistic coding questions are no gauge of actual ability.
Consider the state of mind of someone interviewing for a position. If your company isn’t hugely known, your candidates can be in any number of mindsets. Including:
- Passively open to new opportunities – not 100% interested in your company or the position, possibly only interviewing to remain ‘in the game’
- Passively looking for new opportunities – candidate is casting a line but not expecting any bites
- Actively looking with no other prospects – your interview is the one this candidate wants (or needs)
- Actively looking with plenty of prospects (and possibly pending offers) – the candidate may be looking for more money or just there to ‘see how it goes’
- Not looking – maybe recruited by your company, which increases the feeling of expectations in the candidate
In all of these scenarios, there’s an element of uncertainty which causes the brain to do some funny things (see behavioral science field of neuroeconomics). You’re putting a candidate into an unfamiliar place by having that candidate interview with your company. If the candidate comes into your office, it can heighten the risk and uncertainty that can actually hinder the application of rational thought processes to begin with. As if this isn’t enough, interviewers asking these ridiculous questions are further taking away something familiar from the candidate (even worse if asked to whiteboard these questions or use an unfamiliar coding environment). This state of mind is nearly unavoidable. The loss aversion affecting candidates who are dying for the position only furthers the problem. These feelings are magnified if you work at a company like Expedia where many candidates would do almost anything to work with you. Many developers are anti-social, making the interaction even more unwelcoming. There’s a lot on a candidate’s plate and you’re probably making it worse.
The only way I’ve found as an interviewer and as an interviewee to overcome some of this dampening mindset is to understand that an interview is a two-way street. Your company is interviewing a candidate because you need someone good on your team, but a lucid candidate is also interviewing you to see understand if your company is where they want to be for a while. From this perspective, you’re doing both sides a disservice by asking asinine questions. I’ve been told in the past that questions like these are designed to show how well someone can ‘think on their feet.’ That’s just bullshit. You can think on your feet no matter what data structures are available to you. A candidate is less likely to be able to think on their feet when their ‘fight or flight’ instincts are engaged or they’re afraid of failing an interview miserably. One could argue that the industry is constantly in flux and developers must always adapt; the fact is that the industry is constantly improving, while ridiculous scenarios are based on unrealistic regressions.
It’d be foolish to not acknowledge why these types of questions are asked. They’re often asked to demonstrate knowledge of data structures and algorithms. They’re often asked to evaluate how well a candidate can talk through a problem and come to a solution. If you’re asking such a question, allow your candidate to speak. I’ve been in multiple interviews where I just wanted to walk out because the interviewer literally wouldn’t shut up and let me finish one sentence. There’s a difference between being helpful and being rude. If you’re being rude, not only will it make a possibly good interview go poorly but it will make a smart candidate decide against your company. You may both be at a loss.
Then, there’s the level of unrealism of your question. For instance, if there’s no such thing as arrays… how is the computer operating? If there are no stacks, queues, lists, or arrays, can the candidate assume there is no such thing as contiguous memory? If there are no arrays, can I access a .Keys property of some other data structure? Are there functionally no enumerable structures?! I know I’m being ridiculous, but so is your question.
So what can you do as an interviewer?
First, put yourself in your candidate’s shoes. Don’t just put yourself in your candidate’s shoes as someone who has worked at your company for 8 years and can attack any problem with a fully clear head. Put yourself in your candidate’s shoes, feeling completely naked in an unfamiliar interrogation room with something the candidate either wants or needs dangling in front of yourself by the thinnest of threads. Your interview question probably sucks.
Second, be more realistic. Whether you’re doing a whiteboard exercise, phone screen, or virtual coding exercise, tell the candidate that they’re more than welcome to search the internet for assistance. This will immediately put your candidate at ease. I’ve told many candidates this and I’ve only had one or two people actually use the internet. Something this simple actually works wonders to unveil the true nature of a candidate. If you end up with a candidate who searches for a solution and solves your problem immediately, this means that you either have a problem that’s no problem at all (easily accessible on the internet) or that you’ve found a candidate that can get things done quickly. This will naturally lead you as an interviewer to come up with an original and realistic coding question for the next candidate.
The challenge here is to not ask puzzlers like “all numbers occur an even number of times except one, find it.” Instead, ask a question like “model an ATM” or “create a utility that dynamically loads types from every assembly in a directory.” You could ask a more advanced question like “Write a producer-consumer using a BlockingQueue” or “Write a SIP header parser”. Don’t ask questions like “Solve this obscure IIS problem that took me 5 days of research to figure out” (paraphrasing, but I’ve seen this happen). If you’re going to ask algorithm and data structures questions and you want to evaluate an area the candidate may not be familiar with, consider a reverse polish notation evaluator and the Shunting Yard algorithm.
I was prompted to write this after reading an article on Programmers StackExchange. The question and answers are a pretty good read to get both sides of the interviewing wall.
Just to be clear: I am all for asking complex interview questions. In fact, I think most actual coding questions should be questions that can’t be written in the allotted time (a realistic, yet unfortunate, software management approach). I think it’s fine to make candidates sweat a little because of complexity, but it’s a little unfair to make a candidate sweat because of unfamiliarity.
I’d be happy to hear your thoughts so I can improve as an interviewer.