Coding interviews have rapidly gained popularity in recent years. Although Joel Spolsky advocated for them in 2000, they have really gained traction in the past several years. As coding interviews have gained in popularity, they’ve also attracted some criticism. One argument against coding interviews is that they are not like an actual job. That’s absolutely correct. In one coding interview, I was given an old laptop without a mouse or trackpad. It just had a trackpoint, the red dot you see in the middle of the keyboard on some laptops. Well, apparently that can move the mouse. Since I had never used a trackpoint, moving the mouse was a test in and of itself, so it was hard just to open a program to code in! For that interview, I was asked to write code through HackerRank’s platform, a web interface that doesn’t have autocomplete. Also, I could not consult Google for anything.
Already, we have several reasons why the coding interview wouldn’t simulate how I’d code on the job:
- I was working with an unfamiliar computer.
- No autocomplete. The test was in C#, which I have never coded outside of Visual Studio (which has a full range of code completion features).
- No Google, no StackOverflow. Sometimes, you flat out don’t know functions. And when you regularly work in multiple languages, it can be hard to keep things straight. Is the function to find a minimum value the same in C#, PHP and JavaScript? How about the order of parameters for a substring function?
- Three people were watching every character I typed in real-time and assessing it. You never get that kind of scrutiny on the job. The only time you’re in a situation with that much pressure is during an unexpected site outage.
So, there are several potential issues with coding interviews. But, here’s the thing: the person interviewing you knows this, or at least they should. The purpose of the coding interview is, first and foremost, to see how you think. Sure, it’s great if you write nice code that answers the coding question, but that’s not the primary objective of the interview. If it was, the interviewer wouldn’t be with you as you wrote the code. Based on that, here are some tips for your next coding interview:
1. Don’t be afraid to ask questions.
And lots of them. If a requirement seems vague, ask for clarification. I always want developers who ask questions when they aren’t sure on something. When I hear a developer ask questions in a coding interview, I think, “okay, if this person is in a product requirements meeting, they won’t be afraid to speak up if they don’t understand.”1Of course, if the requirements are crystal clear, don’t ask a question just for the sake of asking questions. In addition, if you don’t have Google or autocomplete, ask about functions you can’t remember or don’t know. At one interview, I said, “I haven’t worked in C# in six months and have been doing mostly PHP, so I may need some help with what order the parameters go.” I asked for help on function parameters several times, and it wasn’t an issue.
2. Don’t worry about writing the most efficient code, just start writing.
You can even start with stubbing out a skeleton of code with comments and filling it in later. I describe what I’m doing as I do this – “Okay, I’m not really sure how to approach this yet so I’m going to start by stubbing out the code/trying to get all these values in an array where I can handle them easier/work backwards from this result.” Once you build something that works, then you can consolidate the code and make it more efficient.
3. Work with the interviewers when they give you feedback.
Keep in mind, the interviewers have seen these questions answered in plenty of ways and have had ample time to discuss them with other developers. They have likely found some ridiculously short way to code a solution, and you probably won’t find it in the constrained timeframe you have. You’ll probably get feedback, and don’t take it personally. Usually, the interviewers are trying to lead you to a better solution without completely giving it away. Sometimes, this can come across as cryptic nonsense. So, if you don’t understand their feedback, try to ask a question to figure it out. Sometimes I’ll even just rephrase what the interviewer asked to confirm since that gives me some time to think: “So, you mean converting the integers to another data type like a string?”
4. Know algorithmic complexity.
I’ve never used it on an actual job, but interviewers love this stuff. If you write an inefficient function, algorithmic complexity will probably come up. Being able to identify the algorithmic complexity of your function can give you bonus points, even if you can’t reduce the complexity.
5. If you don’t know something, use it as a learning opportunity.
Sometimes you flat out don’t know something, so don’t pretend. That wastes time that you could be using to prove the stuff you do know. Use the situation as a chance to learn instead. In one interview, I was asked to architect an authentication system. I mentioned md5 for the password hashing, and the interviewer encouraged me to use something more secure. I hadn’t kept up on the developments in cryptographic hashes. I just said, “I’m not sure, I’d have to research this. What are better algorithms to use?” The interviewer gladly told me (people love to talk about topics they know a lot about). I still got a job offer from that company. But even if you don’t get an offer, you’ll know more for your next interview.
6. Think out loud.
When I code usually, I put in headphones and zone out the entire world. In coding interviews, I take a totally opposite approach. I’d love to just crank away without saying a word, but remember the main objective of a coding interview: the interviewers want to understand how you think. So just narrate your thoughts, even if it means you’re answering the question slower than you would under different circumstances.
7. Don’t be too hard on yourself.
When I was at ScoreBig, our coding interviews were notoriously difficult – enough that some recruiters would specifically warn candidates in advance about it. We had a few engineers who genuinely enjoyed developing the trickiest questions they could, questions that asked things you would never have to know on the spot at an actual job. But, we knew this. We weren’t expecting 100%, or even close to it. So, don’t get discouraged if you get hung up on a particular question or even a series of questions.
