Backend Technical Interviews: An Interviewer’s Perspective
I’ve recently started taking technical interviews for candidates applying for backend positions at various levels ranging from Junior, Mid Senior, and Senior levels. I couldn’t find much content for budding interviewers and I wanted to share how it feels from the other side of the table.
Candidate’s Resume
Every time I get an interview scheduled, a resume is the first thing that catches my eyes. I do spend a decent amount of time going through them to get an idea of their skillsets and try to frame the difficulty levels of the interview. The key things I look for are years of experience, current role, most recent projects, technologies used, etc. There are times I wished candidates to be a little more thoughtful on their resumes to make them more concise and less verbose.
What am I looking for in a candidate?
At a very high level, we need people with a positive attitude who can solve real-world problems and can learn fast and adapt quickly. Most importantly I would look at how it would be like to work with this candidate if he gets hired. I look for many signals throughout the interview and the expectations differ based on their seniority.
For junior engineers, I check whether they can think through a problem with some minor hints and write clean and working code in languages they are comfortable with. I check whether they can communicate the solutions clearly and have the potential to be a fast learner.
For senior engineers, I expect them to solve the problems with almost little to no help and expect them to ask insightful questions to clarify unknowns. I try to bombard them with lots of questions and see how they can handle challenges.
My Interview Strategy
- I usually spend the first 5 minutes introducing myself, setting the expectation of what the next 55 minutes will look like, and making the candidate familiar with the platform whether it's coderpad, codesignal, etc.
- The next 50 minutes are dedicated to either problem-solving questions or a full-scale system design depending on the seniority of the candidate and the interview round.
- If it's the first round, irrespective of seniority I usually start with a medium/hard problem-solving question and I expect them to code it up in 15~20 minutes. This also gives me enough time to know the candidate and plan the second half of the interview. In some cases, if candidates are too smart, I would make slight adjustments to the problem statements to increase the level of difficulty.
- For the next 30 minutes, I would either ask another medium/hard problem or give a systems design question depending on the seniority. Since time is too short to cover a full systems design, I usually give a broken architecture and ask them to improve it for better availability and scale. I would challenge every design choice they make.
- If I’m taking the second or later rounds, I plan based on the feedback of previous interviews. Typically for an experienced candidate, I would go with a full systems design from scratch and also make them code some parts of the system. For junior candidates, it's either a hard problem-solving question or I ask them to explain their current project on a whiteboard or I give them a scenario to debug a live production issue.
- I always keep the last 5 minutes reserved for them to ask me any questions.
Big Red Flags During an Interview
- Getting late! Most interviewers have a very tight schedule during the day and a candidate is expected to take it seriously and be on time. I’ve had cases where candidates casually joined 15 minutes late without an apology and these are not acceptable. If it’s a genuine case, I try to check with the recruiters to reschedule for a later time.
- Giving up easily! I’ve seen candidates who would just spend some 5 minutes on a problem and then start asking for a solution and they contemplate whether to continue the interview. I’d prefer folks who keep fighting till the last minute.
- Arrogance and “I know everything” attitude.
- Cheating or conducting malpractices. Candidates can get blacklisted and can never apply to any positions if they get caught doing these.
Final Decision
This is the hardest part of the whole process. For candidates who performed well it's pretty straightforward as it going to be a yes. And if they performed extremely well, I do vouch for the candidate and suggest traits of potential A-Player or request for further interviewers to check for senior traits if needed.
For candidates who couldn’t perform well, I would decide to drop if they failed to give the key signals I was looking for. For senior candidates, sometimes I do suggest going ahead with a slightly lower position if applicable. Also, in the case where I cant come to a fair decision, I discuss with my colleagues and try giving one more chance by giving feedback for the next interviewers on which areas to focus more.
Are you preparing for interviews? check out my stories:
