Technical interviews are their own kind of stress. You could be working in languages that are unfamiliar to you or with problem sets outside of what you feel like you do in your day-to-day work. You might be pairing with new folks or just have people hanging over your shoulder while you code.
Ever wondered how you can up your technical interview game? I conduct a lot of technical interviews and just want to offer a couple tips and tricks on the “soft skills” side of things to help you through it.
You might have all the right technical skills, but it’s on you to make sure that interviewers can see them. Interviewers have to take what you offer in the interview at face value. They can’t make assumptions based on things you haven’t shown them in the interview.
Myself, I’ve been a lead on a software team which grew from 2 to 6. You’d be surprised how many interviews that alone involved. I also stand in as an extra hand for non-profits as a technical interviewer. I’ve interviewed folks in Canada, the States, Ireland and Norway. Time and time again the principles remain the same. Here’s my top 3 tips and tricks for getting through your technical interview:
Just Keep Talking
In our day-to-day work, and especially on our side projects, coding can be a pretty solitary endeavour. I keep a debugging duck to chat with on my desk, but quite often we have a meeting, go away with the problem, and return to a meeting with a solution you can explain. Of course there might be code reviews and check-ins along the way, but it’s not usually during the time we are actually executing the “do the code” work.
Technical interviews are a bit of a different environment. The only way the interviewer knows you know what you know is if you explicitly tell them, while you’re also in the process of doing the work.
Even in a screensharing set-up, for all the interviewer knows, you’ve got someone on the backside of the screen drawing solutions for you. Improbable, but understand that an interviewer can’t know you know what you know unless you explain what you’re doing.
I’ve had candidates reflect at me that they’re not great at thinking, talking and coding at the same time, and that’s fine.
There are a couple of ways you can approach this.
One is to “sandwich” your explanation.
So begin with
“I’m going to begin with creating a dictionary for this problem so that x can happen.”
Then code the dictionary.
Then speak again and explain “I have used python to a, b, c here. The next thing I will need to code is an input parser, but first I’m going to run a test case against what I’ve written so far.”
The other way to approach it is to just choose explaining everything at the beginning or end of your code.
So, you can code the dictionary and then immediately explain that you have coded a dictionary and what purpose that serves in the problem. Alternatively, you can explain that you will code the dictionary, and then do that, and then explain the next piece.
I like the sandwich method because it creates a strong and consistent narrative that is easy for your interviewer to follow.
Testing Testing 123
There’s a variety of ways to test things, and in an interview setting none of them might look like putting together a traditional test suite or unit tests.
The goal here is to prove that
a) you can build iteratively; and
b) that both you and the interviewer can see that your code is actually working as intended
(and if it’s not working as intended, that you can stop and think critically about where the challenge is and what you need to build next or go back and change)
You might have a 20 minute time constraint and find that a bit of a challenge in getting things coded AND tested, but it’s key that you’re “testing” somehow.
- Use an IDE (Integrated Development Environment) that can run your code and give you feedback straightaway.
You can use something like VSCode or you could choose to use an online IDE like Glitch.
Before your interview be sure to create a user login so that you’re ready to login without any challenges when you begin. Or, with something like VSCode, if you’re able to use your own laptop, be sure to download and get everything set up before the interview.
2. If the problem is tiny enough, code it straight in the Terminal (or powershell-using them interchangeably here).
Alternatively, use the Terminal to run your program file.
In Node, for example, you can follow these instructions to run the program in your Terminal.
Be sure to look up and learn how to run your favourite (or the company’s preferred) languages in the Terminal before you head into the interview.
3. Test it locally in the browser.
If you’ve got an HTML file this is super straightforward.
Save your file on your Desktop.
Double click your HTML file to make it launch in a browser on your computer.
If you’re working with something like Python you can launch a little server like so:
python -m SimpleHTTPServer
(just be sure to use your Terminal to navigate into the appropriate project folder before you run the command)
Again, this is something you can look up and learn before you head into the interview. You might search something like “how do I launch languageName localhost”
Two Roads Diverged in a Wood
I am very busy learning a 3rd language here in Norway. We started with the ABCs 16 months ago and now I’m able to sort of tell you why plastic straws are bad for the environment in a short 3 minute conversation in Norwegian.
One of the core components of citizenship, residency and language learning here in Norway is the norskprøven, which is a 4 part test spanning 6 hours that you take at each of the 4 key milestone levels of language. Fun, right?
Anyway — 1 of the 4 parts is the muntlig, the spoken exam. You have to speak for 3–5 minutes straight. If you stop before the examiner says to, you fail. If you misspeak a core word in vocabulary at the level you’re meant to be speaking at — congratulations, you fail.
One way to get around this second one, and a really helpful tactic for technical interviews, is to explain the options racing around in your head while you desperately try to Just Keep Talking.
In my norskprøven, if I’m trying to say “both brothers” but “both” in Norwegian is actually 2 different words — one is for things that are alike and one is for things that are unlike each other—and I can’t put my finger on which one is correct, I can do something like this:
“I’m not really sure if it’s både or begge here in this situation but I’m going to go with både because these two things seem pretty alike to me.”
Even if I’m wrong, the examiner knows I had the other option in my head, they know why I chose the one I did and they’re less likely to fail me because I’ve put all my possible cards on the table, so they become aware that I could’ve put my hand on the other word.
If I don’t take that approach, they will simply fail me because I picked the wrong word. With the cards-on-the-table approach, they can make a judgment of where my understanding of things is at, and they can assess whether they think it’s close enough to the level to pass me even if I did come to the wrong conclusion with my word choice.
Say you’re not certain whether you should be using a const or a let, for example.
Typically, while your head swirls with which way is best or more impressive and you’re sweating and full of anxiety, what the interviewer sees is someone staring blankly at their screen.
Instead of having awkward, sweaty silence, try and talk out the options in your head.
“Well, I am considering both const and let here. The advantage of const is that it’s going to allow me to do x later. However, there’s a challenge in that y might happen if I do that. So I’m strongly considering let because y won’t happen. I understand that’s not necessarily the traditional approach, but I’m going to try it.”
Then try it. Code.
And then you can Just Keep Talking.
Reflect on if it did as expected. Reflect on the results and error messages. Change your code.
This is iteration.
Again, you might have picked the wrong answer.
But the interviewer now has access to the possible answers you did have in your head, and they have access to how you came to the decision and what reasons you were weighing those options.
At the end of the day, that kind of transparent thinking is going to get you a lot farther in an interview than just looking like you’re staring blankly at a screen for a long while.
In a Nutshell
- Just Keep Talking
Sandwich your code with explanations of what you mean to build, what you did build and, in both cases, why —e.g. I built a dictionary because…
- Test Often
Is it working? Great.
If not, investigate errors (out loud), explain what you think is wrong and how you intend to fix it. Then do your best to fix it.
This is iteration.
- Show your hand — explain the choices you’re weighing
Transparent thinking lets the interviewer know a lot more than staring blankly at a screen.
Remember that, at the end of the day, interviewers want to see you succeed. Nobody drags themselves into a conference room for an hour because they just love sitting next to their boss with a cold coffee. Interviewers have a need —more people — for jobs they want to create in future to build cool new stuff or jobs that aren’t getting done right now because there’s not enough hands on deck, and they sincerely hope you could be the one.
You made it this far, you’re meant to be in this room, and you’ve got this. Everyone’s excited you made it this far. Now go show them your stuff — on the screen and out loud as you build.