The 5 Types of Software Engineering Interviews (and Why You Fail Them)
Photo by Vivek Doshi @viveksphoto on Unsplash
Software engineering roles are pretty easy. Show up to a standup, claim you’re doing something and shift tickets to the right.
So, it comes as something of a shock when getting your next role is a series of disconnected tasks that have little to no relation to the skills required for the job to which you have applied.
There are so many flavors of bad interviews these days. So here are the top five types of awful interviews you might get asked to complete, and why you might end up failing them (even if you are a good software developer).
Software Engineering Interview Fails
The Quick-Fire Quiz
Photo by Cullan Smith @cullansmith on Unsplash
he Setup
You sit through a barrage of rapid-fire trivia questions.
“Define the Singleton pattern.”
“What does the ‘finalize’ method do in Java?”
In my experience these interviews can be 15, 30, 60 or 90 minutes. Your interviewer has a list of pre-prepared questions and answers, so they do not need to prepare for the interview at all.
Why You Fail it
It’s not an interview, it’s a glorified pop quiz with a host who probably couldn’t answer the questions themselves.
You might choke under the pressure. You might answer in a way that isn’t on their pre-prepared answer sheet. They might ask the question in such a way that it doesn’t elicit the answer they expect.
Memorably I failed one of these interviews by confirming a question — and instead of confirming the question the interviewer simply gave the answer and moved on.
The Never-Ending Take-Home Project
Photo by Willian Justen de Vasconcellos @willianjusten on Unsplash
The Setup
They hand you a simple project to complete on your own time. The email says it’ll take 2–3 hours. You soon realize it’s more like 12–15 hours, and the expectation is you complete it within 7 days.
Why You Fail it
Take-home projects are a thinly veiled attempt to get free labor but with laughably bad time estimates. I’ve realized that the only way to complete these projects is to sink serious time into them to make sure there are no mistakes whatsoever. If you don’t check, double-check and triple-check your work any error will be picked up on and a rejection will follow.
I once had inconsistent naming in a take-home project and quickly faced the “I’m curious as to why” question, a couple of days I got my rejection email.
The Behavioral Gauntlet
Photo by Martin Baron @elmartinbaron on Unsplash
The Setup
Someone from HR grills you on your teamwork skills and past projects. This might be an hour-long interview checking your working practices against a set of values (which may or may not have been made available to you before the interview).
Why You Fail it
The person rating your work will not have the technical experience to judge your work, and the criteria for your answers is unclear at best.
After getting rejected from a final stage interview for “not having the depth of experience we would expect” as judged by a product owner I came up with a strategy for my next interview. I asked what the interviewer wanted from their “name a time you’ve worked in a team” question — technical skill or the best show of my teamwork skill (as I’ve great examples for both, but not an example that is suitable for both simultaneously). They said (after a confused pause) both. The rejection email came after a few days.
The Whiteboard Hunger Games
Photo by Pavlo Rekun @menos on Unsplash
The Setup
You’re handed a marker and asked to solve an algorithmic problem in front of a panel of stone-faced engineers. It’s like solving a Sudoku puzzle while someone slowly judges your handwriting.
Why You Fail it
Writing code on a whiteboard is about as realistic as performing surgery with a butter knife, because let’s face it nobody codes without an IDE. It’s nerve-wracking, impractical, and has little to do with actual job performance.
I’m actually good at these type of interviews, one time passing 8 hours of them back in the days we did those things in person. Yet I’m hobbled these days by the lack of in-person interviews. Sure, I can pass the interview without an IDE. I can pass it with an IDE. What I struggle with is the IDE lite like HackerRank, where running the tests takes minutes rather than seconds.
The Lunch Interview That Isn’t
Photo by Tyson @tysonbrand on Unsplash
The Setup
You’re invited to lunch, under the guise that it’s a casual chat.
Why You Fail it
It’s another pass/fail moment where you’ll be judged according to unclear criteria. I’ve had one of these interviews (that aren’t) and didn’t even get a free lunch. Now I know there’s no such thing as a free lunch, but that’s taking it literally. Or did I fail the test? I certainly got rejected.
Honorable Mention: The Ghost Interview
Photo by Erik Müller on Unsplash
The Setup
You complete two rounds of interviews, and then…
Why You Fail it
You’ll never know.
They tell you nothing. No rejection, no feedback, no closure. Just radio silence. Bonus points if after 18 months you receive a rejection out of the blue citing “we went with another candidate”.
Why These Interviews Persist
Despite being universally loathed, these formats endure because
They’re Easy
Throw some trivia questions in a link and call it a process. Sure, it doesn’t make sense that “only a techie can interview a techie” and then expect them to run a tick-box interview, but there’s never time given to software engineers to read over a resume much less think of interesting questions.
They’re Standardized
Companies copy each other’s bad ideas (looking at you, FAANG). Whoever does this should fail their OKRs.
They’re Cheap
An awful process is a lot cheaper than a thoughtful, collaborative evaluation process.
How to Get That Job
Photo by Evie S. @evieshaffer on Unsplash
I’m not going to do that thing and say poor interviews are a red flag for any particular company. Some great companies have awful interview processes and vice-versa. The whole notion that you’re “interviewing the company” is a lie when you need a job to keep a roof over your head (and if you hadn’t heard, it’s hard times in tech land right now).
So here are some tips to get that job
Know the Game
Study the format and prepare accordingly. It’s not flawless, as in my experience the initial recruiter might not know the process that follows but it’s the best you’re going to get. See each failure as a step to getting the next job, no matter how painful it might be. Always ask for feedback but be prepared to reject it when it makes no sense.
Set Boundaries
If a take-home project is absurdly long, politely decline or ask for clarification. Even better, ask if you can use a project from a previous application. Even better, when you’ve not interviewed for a while see it as a development task and use the feedback to make sure you pass the tech interview for the next job.
Keep Perspective
It’s not all about you. You can control how you look and respond, sure. You can prepare the best you can, with the information you have at the time.
You can’t account for your interviewer being hungry. You can’t control the pressure your interviewer is under due to a production bug. You can’t control that your interviewer doesn’t know how to interview.
Let it go
I have to say that I’ve never walked out of an interview. I try to write down any learnings as I go and use each and every experience as information to help me pass the next interview. Do it, and make sure you fail harder and fail better next time.
Conclusion
Software engineering interviews often feel like a bad reality show where the only prize is a chance to spend 40 hours a week writing Jira tickets. But for all the frustration, there’s one silver lining: every terrible interview makes for a great war story to tell your developer friends. Oh, and you might just get a job.