Acing the code interview as an interviewer
Well, hello there. To be honest, this article wasn’t for you, but rather for a good friend of mine who had to do her first interviewing session, but since you’re here…
This article deals with code interview, so we don’t cover some architect-level interviews and focus less on problem-solving (which is arguably even more important) and more on the code.
Anyways, let’s first clarify the basics:
Be a Pro or GTFO
To ace a technical interview, you must be proficient in the technology stack, or, at least, be more proficient than the candidate. There’s no way around it, no amount of “Top-69 JavaScript interview questions” would help an HR or an early-stage start-up CEO with zero tech experience whatsoever to successfully handle a technical interview.
And here’s why:
Reason 1: Everybody wins, nobody gets hired
You want to determine the knowledge level of the candidate. Why? Because after the interview, you want to say one of two things: “This is that guy’s ceiling” or “I salute to them, they are as good as a candidate could be”.
It’s not that it is not possible to choose between 50 “as good as a candidate could be” guys (desired salary, how nice of a person they are, how beautiful their smile is), but, especially for the less senior positions, you do want to compare candidates’ “ceilings”.
Reason 2: They know you don’t know
If the candidate is any good (and you want them to be so), they’ll easily spot the lack of knowledge in the interviewer. It may be somewhat OK if a Middle-level engineer gets to interview some system architect — both of them (hopefully) understand this is a formality.
But the larger the knowledge gap, the uglier it becomes.
I know a guy who got so pissed at the fact that the entire “technical interview” process was one HR girl who went ahead asking him questions printed on a sheet of paper and comparing his answers to the correct ones that he just stood up and left.
Somebody more opportunistic might just take advantage of the poor HR girl or some self-proclaimed “Java Guru” (God, do people still call themselves gurus and rockstars?).
Even if none of that happens, the candidate would be left with the feeling that your company’s processes are garbage and are ran by unprofessional people. If this is the case, normally you’d want them to find it out after at least three months into the contract, not after 10 minutes of the interview.
Now you may be asking: but Alex, what if I’m a non-technical founder and I’m screening for a potential co-founder? What else other than Top-69 JavaScript interview questions do I have? Well, you probably have your network. Ask somebody from your network to interview them or get references. As we’ll learn later, years of experience are not always the answer.
Read the Top-69 JavaScript Interview questions
Haven’t I just disregarded them altogether in the last section? Nope. You see, they are like Whey Protein. Whey Protein should not be your only source of protein, just like the Top-69’s should not be your only source of questions. Would I personally expect a health advice in an article about interviewing people? I do not think so (if you didn’t see that one coming, please, take a break from reading and hit that Clap button).
But what I ‘d be expecting is that the candidate either knows the answers to them or they have at least bothered to check these lists.
When I’ve been interviewing for one of my largest client’s (Angularjs-based application — yeah, not the freshest stack by all means and, eventually, it’ll be upgraded), well, my favorite question was “How does Angularjs data-binding work” which later would transform to “what is dirty-checking” and some code questions on topic. If your best answer was something like “well, you type {{field}} in your template, yeah… and… that’s it”, I’d be very sad.
I don’t care if the last time you worked worked with Angular was in 2015. You come to an interview, and I expect you to either know the answer or show that you have at least bothered to google the Angularjs interview questions. Your job as an interviewer is to find out if they know the technology/principles or googled the questions.
My point is, google the questions yourself. Not only you may find some good ideas, but you’d have a better understanding of what a potential candidate would/should be ready for.
Tests are for school kids
Ask the candidate “what would be the output of this function” and you may hear a valid answer. Ask them why they answered so, and you’re in for a ride.
When I was in high-school, the teacher who trained the team for the Math Olympiad would call tests the “guessing game” (here in Belarus we have something similar to SAT). It’s OK to give candidates some sort of a test as a filter, but it’s never a good idea to base your hiring decisions solely on them. Or not to ask questions about both wrong and right answers.
Speaking of Junior developers, you can’t imagine (and neither did I at the time) how many people would answer correctly but wound’t be able to explain why.
Experience in dog years
The saying goes: “Age is just a number and prison is just a room”. A consent age joke should go somewhere here, but that is beyond the point. 1 year in web dev agency that builds e-commerce websites on WooCommerce ≠ 1 year in a big outsourcing company ≠ 1 year in a startup.
There are some things that people can get only with experience, and, contrary to claims of many outsourcing companies, both here and around the world, 3 years of experience ≠ Senior developer (maybe some day I’ll even write an article about one person 6 months into their first job at iTe**art getting sold as seniors developer to the client). So do not expect a hot-show 2 years into the industry to come and design your enterprise-level app’s architecture, that’s a bad idea.
On the other hand, what about people with 2 years as “System Architect”, 1 year as “Team Lead” and over 7 years on industry experience in total?
Verify every single company the candidate had listed is especially complicated when the candidate is in a different country. Considering my experience interviewing remote developers, I would be very, very cautious with people who should have relevant experience but you do not get the feeling they do.
Never ever trust Linkedin entries more than you trust your opinion.
Trust your gut.
If you are making the decision yourself, trust your gut. If no, tell the HR/Manager what you feel about the candidate. Don’t hold it to yourself.
There are more impostors or unskilled Senior System Solution Architects than one may expect. This is applicable not only to IT but all industries. I highly suggest you get a copy of this book, there are a few sections dedicated to impostors.
Take no sh*t at all
You should pay respect where it’s due. Pavel Shabalin is the person who taught me to take no bs explanations and always get to the core of the problem. It applies to both meetings/standups and interviews.
In case you don’t understand something, maybe due to accent or simply because it’s not clear what the candidate means (or you have even a slightest shadow of a doubt), ask. If the question is unclear, repeat.
If you feel like the candidate it getting tricky or dodges questions, ask them a Yes/No question and get them to commit to a certain answer. The following dialog is based on an actual interview I’ve conducted for that Angularjs project.
- Will this code snippet work?
- *one-minute-long reply that doesn’t exactly answer the question*
- So, will this code snippet work?
- *10 seconds of silence* This will not work, because so-and-so
- Here we do this and this, so what you’re saying is incorrect. Will this snippet work?
- Yes, right, I was saying it will work.
- No it won’t. We’re not binding the context correctly.
- Yeah, I was saying it won’t work.
If you are afraid to look bad by re-iterating some things or asking that System Architect some simple questions, just imagine how stupid you’d look if you don’t ask them + they can’t answer + they get hired.
If you have at least a shadow of a doubt, re-iterate.
I know how weird it feels, especially when you’re interviewing people with more years of experience than you who are oldern than you. Do not forget though, assunimg they know the answer to your question (unless it’s about how to output “Hello world” in console) is a bad idea..
Ask concepts
I can open some js wtfs and start asking people if typeof null === "object" or some prototype-inheritance questions that nobody uses anymore in this age of Babel and that I’d be puzzled by myself. Would that be helpful? No.
One thing I tried a few times is trying to persuade the candidate that in React, instead of using Redux or GraphQL one should just load data from the backend via axios and pass it through props, because the entire Redux thing is a conspiracy to make web development more difficult so that developers get paid more.
You rarely win this argument, but it’s fun.
Take notes
Unlike this article that you can open at any time (hopefully), your interviewer would not be there for you to repeat all of their answers. This would be especially severe if you have 6 interviews in a row (it sort of burns you out btw). So take notes. Write down the good things as well. By the end of the interview you should be able to have something like that:
Started well with the tests, failed the pure function question, does not know how Redux works, took 40 minutes to solve the coding question. Hard pass.
or:
Somewhat understands binding, good on code smell question, little experience in the field though. 8/10, better then previous ones
You’ll either need those yourself if choosing the hire is your call or you’d be able to provide that to the HR/Manager. Some short report like that is much better than “Well, I think he’s not perfect, but he’s OK”.
Code smell question
I have dedicated 50% of my blogging career to talking about code quality. In every single interview I have I 100% add a “bad code” question, varying from “what’s wrong with this stupidly bloated 600-loc function with 12 arguments” to “is there something wrong with the following approach”. And so should you. I highly recommend Bob Martin’s video course on code quality — you could formulate your questions as simple as just taking all the worst practices and shoving them all into one code snippet, then ask candidates to find all of them. Don’t forget to talk and ask “why” whenever you feel the candidate could fail to answer, especially when interviewing Junior/Middle developers. Whenever you feel like they might not know, you gently push till you get a clear answer.
Coding question
It’s a must when interviewing Junior developers, and, it becomes less important when the more high-skill the candidate is. I prefer Codewars for this. Find some relatively complex katas, nothing too special, seat back and enjoy the show.
Stress, Sandwhich and Solomon’s Judgement
Make sure everybody’s comfortable. Nobody wants an interrogation. Smile, offer them some coffee if you’re conducting an on-site interview. If you push, do so gently and politely. Don’t be a jerk unless the candidate had asked for you to be a jerk, like the “Yes, right, I was saying it will work” guy.
Out of 50+ interviews I conducted last year there were two where a candidate was visible saddened by their inability to answer. One girl would just go silent instead of answering. If this is the case, don’t push. By then it’s pretty clear that this interview would not end with a hire, so no need to push.
Always start on a positive note and always end on one, especially with Junior developers who are looking for their first position. They may be not competent enough, but no need to tell that to their face.
Don’t give them “We’ll contact you later” unless you don’t plan on doing so.
“But what about stress? What you’ve described here sounds super stressful! It’s not nice and not good.”
Usually, if the candidate is really good, you don’t have to push at all. If they are right away bad, you don’t push either. You push when you are not sure. The company you work at (or even your company), businesses of your clients and well-being of your company’s employees and, of course, your own well-being and career all rely on you making right hiring choices.
If the candidate can’t handle an interview because of stress, either consider re-scheduling, or, if working at your company is quite stressful, reject them right away. This is the Solomon’s Judgement: if you’re in a startup, rushing out features and trying to please your customers & investors at the same time, you probably don’t want people who can’t work under pressure. So, if someone fails your interview because it was somewhat stressful, they fail it.
PRO TIP #1. If you’re 10 minutes in, but you’ve already got a clear understanding that continuing this interview call would be a complete waste of time, let the candidate say that. Ask the candidate their opinion on how the interview has gone so far and if they were you, would they continue.
Conclusion
If you are an interviewer, your judgement is trusted. Understand that you may be wrong, but never let the “Probably they mean this”, “I feel like if I ask more questions that might disappoint the candidate” and “There’s no way they don’t know what I just got a suspicion they don’t know” get in the way of properly doing your job.
If you’d like me to work with you, hit me up on Linkedin or drop me a line at alex@xfuturum.com. Or follow me on Instagram.
