During a job interview last year, I was asked to live-code a JavaScript function that would find the winning poker hand among many. I have always struggled with someone watching over my shoulder. In order to avoid awkward silence, I started typing and talking, but I had no idea how to solve this. Through sheer muscle memory I managed to type out a basic function. The only problem was that it didn’t actually work. Worse: I didn’t know how to fix it.
My interviewer was uninterested in giving hints and just sat silently while beads of sweat formed on my face. I was dying inside. With a few minutes left, they reluctantly unblocked me with a tiny clue. In the end, I was only able to solve one of the six test cases I was expected to complete. As you can imagine, I was not invited to a follow-up interview.
This was just one of many interview failures I’ve had throughout my 14 year career, but it was one of the most memorable because unlike being ghosted, it was obvious I had failed in the room. I was actually so upset with myself that I went back and completed all six test cases just to prove that I could do it. And I did it in roughly the same time I was given during the interview! It’s amazing what you can accomplish when anxiety is removed from the situation.
After I posted this on LinkedIn, other people replied with their own horror stories. I know I’m not alone, but it was nice to hear that other successful developers have failed interviews at no fault of their own.
Reminds me of when I was put into a “fullstack” interview where there was a clear bias towards frontend. Not fun since I’m able to do frontend - just not with someone watching and me talking out my solution step by step.
-- Erran Carey, Staff Incubation Engineer
Who knows why this happened. It could have been a mistake. But I imagine this happens at many companies because engineers conducting interviews are not given the time and resources to prepare questions specific to different roles. To save time, they probably decided to have a single “full stack” interview.
I also had one really bad interview where they asked me to troubleshoot errors in operating systems without allowing me to look up what those errors meant. What kind of engineer is not allowed to research while working? (that's part of the skillset), it's not like I remember every single error an operating system throws out and the solution. After the interview, I figured I had failed their test, so out of curiosity, I asked about the answer anyways, and they refused to tell me.
-- Sivaroj L., Senior Site Reliability Engineer
In a world where engineers have access to Google (and let me tell you, as a senior engineer, I use it daily to look up the most basic JavaScript methods), why would you prevent them from using it during the interview? Searching for answers is also a skill, and an important one. This is like hosting a tryout for a professional athlete and then asking them to do it blindfolded. What does it prove?
There are better ways
Along with their failures, several people also replied with success stories of good interview practices that they really enjoyed.
Pairing to solve broken code
I definitely prefer the recent approach i was given two code reviews (one Rails/one Vue) to complete up front then got to pair with someone on either to solve broken tests/missing requirements. Fortunately I left so much feedback it was like a checklist so I wasn’t very nervous at all.
-- Erran Carey, Staff Incubation Engineer
Take home project that reflects actual work
A few engineers came up with a take home project that fits the type of work our company did, and then we gave candidates a week to do it. We even let them tell us when they wanted to do it, because life is crazy. Once completed, we had them bring their work in and demo it to some of our engineers. Doing this allows people to work in a more natural environment, with their own computer and their own tools. You can't cheat because we ask people to explain their code.
-- Mike Koser, Software Engineer III
Giving candidates options
That all being said, perhaps the best way is to give the candidate a choice of how best to show their strengths. Some people are just really good at churning out code and can write algorithms on the spot when the computational objective is clear. Takes all kinds 🤷🏻♂️
-- Clayton Dunwell, Founder
The moral of my story is: if you are giving interviews, try do whatever you can to reduce the pressure for the candidate. If you can remove live coding entirely, you’ll likely get better results. The examples above are just a few of the many ways to interview software developers without (virtual) whiteboards and Computer Science trivia.
If you are interviewing for a job, forgive yourself for some failures. Even after over a decade of experience, I still fail. Follow me on LinkedIn for more horror (and success) stories in software development.