This content originally appeared on Level Up Coding - Medium and was authored by Pavan B Govindaraju
My thoughts on what a good interviewer should ask
Anybody in the software business who tells people they enjoy coding interviews is lying. It is an obnoxious gathering in a cramped space that usually lasts an hour and can end in crying. This post aims to provide suggestions to make this a more efficient and endurable process.
There are tons of resources out there on how to be the picture-perfect interview candidate. But there is limited guidance on how to be a skilled interviewer.
One thing to keep in mind is that it’s really easy to be a bad at interviewing because you have a lot more degrees of freedom. The folks answering the questions have only one thing on their mind during the session, but it’s the exact opposite on the other side of the table. Thus, it is really hard to conduct a good interview and unless someone makes an active effort towards improving at it, they are probably very bad. Making a negative impression on the candidate is the bare minimal consequence and the downsides go much further, such as losing great talent, driving up hiring costs and inadvertently creating a toxic work culture over time.
Fortunately, there are some well-thought-out posts on how to conduct a good programming interview, particularly this one by Li Haoyi. Also, this post by Gayle McDowell on whether there is even a link between job and interview performance is a great read and highlights just how difficult a problem hiring is for software companies.
Before coming to what constitutes the aim of a good interview, taking a step back helps realize that all we need to do through this activity is identifying great fits for the current role. And the hiring process can start way before the actual interview.
One practice I strongly advocate is taking interest in someone’s GitHub, StackOverflow or any work samples. You can see their coding abilities in an unconstrained environment, the kind of problems that interest them and the approach they take. Candidates should put links to their profiles on their resume.
During the interview, the goals should be uncomplicated and never be a demonstration of power. Li’s post nicely summarizes them using four key questions that I have paraphrased here.
- Can they write good code?
- Can they discuss code and problems with us?
- Can they reason about open-ended problems and constraints?
- Can you see yourself working with them?
Based on the above tenets, I found one question over time that earned nice reviews as an opening round interview for entry-level roles. The question is short and simple — implement a basic calculator. We’ve all seen one and they can open it up on their laptop as well.
It does test your basic coding ability (#1). It is also intentionally ambiguous as we would like to test their ability to reason about such obstacles (see #3). Keep in mind that as interviewers, we should be open to multiple solutions and this question very much has several routes it can go along.
Depending on the role, one could emphasize on the frontend aspects or just focus on the calculator logic given the key pressed. It’s also really easy to judge if they are doing well and the candidates themselves have a decent idea of how things are going, thus helping them to not panic during an already stressful situation and minimizes our interventions.
The question also encourages best practices. One needs to use some form of object-oriented programming to avoid usage of global variables and it also tests everyday concepts (instead of inverting a binary tree) such as functions, callbacks, loops and even type-safety, because you are reasoning with numbers that show up as text.
But what makes this an interesting problem are the edge-cases to keep in mind.
“What happens if I hit ‘+’ multiple times?” or “What if I hit ‘+’ and then hit ‘=’ after that?”
This encourages the use of writing test cases and candidates wildly need to change their approach depending on what features they would like to cater to. They could call it a day by using the evalfunction, but the above questions would be left unanswered.
This intentional ambiguity also encourages dialogue. You would like to see #2 — how they discuss code and problems. Questions such as “Do I need to hit equals or can I just keeping doing 10+20+30?” should be applauded.
The verbal exchange also provides a good indication of their personality. Are they the type that doesn’t hesitate to ask for help when stuck or do they put their head down and wait till the levee breaks? This is bound to happen as there is no limit for this problem. You could go ahead and implement parentheses or even scientific operations if you have the appetite.
I’ve also observed people using a plethora of languages for this as it requires no fancy libraries and candidate performance was quite uniform irrespective of their choice. Most importantly, many candidates were able to complete a bare-minimum but functional version of this within stipulated time limits.
This drill also made a great impression with other members of the panel. They are, after all, the people I will continue to work with and very much appreciated the “No Flexing” rule being followed. First rounds should only set a minimum bar. There are enough competitive programming websites out there and you can fail anyone if required by setting an unrealistic standard.
At the end of the day, I do humbly agree that there is no right way to do an interview. There will always be false positives and negatives. Some advocate a “Hire Fast, Fire Fast” policy. This is a post on its own and although I do agree to some extent that not firing, particularly in higher roles, where it is harder, causes a cascade of emotional trauma and financial loss. But even that strategy boils down to companies hiring and retaining people more like their founders than doing what is the best thing.
All the best! Not just for the candidate, but the interviewer too.
Tales from a Good Coding Interview was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by Pavan B Govindaraju
Pavan B Govindaraju | Sciencx (2021-02-10T03:52:46+00:00) Tales from a Good Coding Interview. Retrieved from https://www.scien.cx/2021/02/10/tales-from-a-good-coding-interview/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.