My Tech Interview Horror Stories
I won’t spend time talking about how broken the interview process is — there are already plenty of well-written stories about that. What I will tell you about is how broken I am. Maybe you’ll relate. Names and details have been obscured.
Sophomore year of college. I had gone to my university’s “just-in-time” career fair and walked away with a handful of brochures where companies talked about what great amenities they had.
They thought candidates would ignore less vacation, low pay, and terrible upward mobility if they focused enough on ping pong and free soda.
Turns out they were right. But anyway I digress.
I’d printed out exactly ten resumes that day and handed all ten of them away to companies that piqued my interest. Only two ended up calling me back. Fast forward a week later, and I was headed to an interview with one of them.
Given that my prior experience was being a bank teller and washing dishes, this was my first real coding interview. So I was excited — and nervous.
My nightmare started when I completely butchered an interviewer’s name. Trying to be slick, I projected an air of coolness and confidence like I was also trying to explore them (I just wanted to get an offer).
Me: So, Bruce and Mike, how long have you two been here? Do you enjoy it?
*Jacob: …Jacob. And we’ve been here 2 years and 5 years, I think.
Jacob and Mike.
To this day, I have no idea where the hell “Bruce” came from. But holy sh*t that was embarrassing.
Immediately any remaining shred of confidence I had was gone. I had just butchered a guy’s name even though he’d said it 3 minutes ago.
I was nothing.
The rest of the interview went similarly disastrous.
Mike: Tell us about a time you overcame a struggle.
Me: I, uh…
I hated questions like this. Still do. How deep should I get? Do I talk about that time I held in bad diarrhea during an important exam?
Being a pampered, middle-class guy, I didn’t really have any noteworthy “struggles” to talk about because I wasn’t an underprivileged minority working 3 jobs and taking care of a child on the side.
So in an attempt to recover from my wrong-name blunder, I tried to tell a story that made me look reliable and capable.
Me: Well, earlier this semester actually, my partner was… well, wait, let me back up. Sophomores have a semester-long project where we are assigned partners and then we build something.
My partner seemed like a cool person, but after the entire semester basically went by, he’d done nothing, so I ended up doing the project alone a week before the deadline. We got an A.
Was the story true? Mostly, but that doesn’t matter. The point is, my naive self at the time didn’t understand what interviewers really wanted when they asked questions like this.
Not only do they judge your character based on how you tell the story and speak about others; they also want to gauge your communication skills, your judgment of situations, and how you handle conflict.
What does this mean? It means I gave a horrible answer:
- I was not humble.
- I threw someone else under the bus.
- I (unintentionally) demonstrated unwillingness to communicate and work with a teammate.
- The frankness of how I told the story made me look like a dick.
Mike slowly nodded, and then he and
Bruce Jacob just glanced at each other.
By this point, I’d probably already bombed the interview and was not going to be hired. But then came the kicker.
Jacob: So, what’s your favorite programming language and why?
Me: We’re taught Java as the starting language at [my university], but I think after having the opportunity to work with it for a semester, my favorite language is C++.
I really enjoy how powerful and complicated it is. Memory management can be a pain sometimes chuckle, but the little perks C++ has — multiple inheritance, operator overloading, preprocessor directives — make it fascinating to work with.
Mike: Nice! I’m a C++ guy too! Can you show me an example of operator overloading?
…and I froze.
See, the funny thing about being a college student is that a lot of times, learning is not the priority — passing classes is.
Most humans are not geniuses. We cannot remember something long-term after seeing it or doing it just a few times.
So despite the fact I was able to list off these “strong” features of C++, I had already forgotten how to actually use them.
I’ll skip forward a few moments out of sheer embarrassment.
Jacob: Alright, I think we’re nearing the top of the hour. Do you have any questions or comments for us before we let you go?
Me: Uh, yeah. I just wanted to take a second and thank you for your time. I realize that you’re both really busy and I appreciate everything you’ve told me about [COMPANY] and the work I’ll be doing he — I mean, if I was hired, the work I’d be doing here.
I just wanted to add in one last piece that I’m a little bit shy and nervous right now, and I may come across that way at first. But at the end of the day I think I’m fairly knowledgeable, I can learn quickly, and I’d be able to contribute to the team if I was to be hired.
I’m a really determined individual, and I’ll always persevere until I get things done. Among the things I’m good at, I consider myself organized and…
…(more drivel here)
Blah. Blah. Blah. Trying to save my own ass never sounded so desperate.
Needless to say, I didn’t get that internship. And looking back, I’m grateful for that, because I certainly didn’t deserve it.
Moral of the story: Don’t try to be cool, and don’t bring up topics you can’t talk about. Also, practice interviewing so that you’re not a nervous wreck when it counts.
Summer 2018. This story stars me as an interviewer. One particular candidate we had coming in was someone we were really excited about.
On paper, everything looked incredible — experience with multiple languages and frameworks, knowledge of various testing paradigms and tools, and even experience with business development and management. A unicorn. According to the coworker who phone-screened her, she was phenomenal.
But things started off weird when she showed up 20 minutes early. Being a small company, we didn’t have a nice lobby with drinks or a desk attendant to greet her. So she sat awkwardly on the couch while someone ran to the conference room to clean up.
At the interview start time, I and a coworker (we paired up for interviews) went into the other room with her. We started off asking her about her current studies, projects she’s working on, etc. Answers were fine.
But then we started poking and prodding about some of the stuff she listed on her resume.
Me: You’ve got BGP and OSPF listed here. Could you tell us more about them?
Her: Oh, sure. Border Gateway Protocol and Open Shortest Route First.
Me: Okay, and how do they work? What are they?
Her: Uh. They’re routing protocols. BGP is um. Uh. Well… (long pause) we learned about this in uh…
Me: …was that in _[SPECIFIC PROFESSOR]_’s class?
Her: Yes! That one!
Yikes. The issue with this? That professor quite literally goes over BGP (Border Gateway Protocol) and OSPF (Open Shortest Path First) in one lecture. They show up again in one question on a homework assignment, and then there was a single question about each of them on the final.
That sort of exposure to a topic does not qualify you to put it on your resume. Anyone who’s knowledgeable about networking understands how immensely complex it can be to actually configure routers with respect to each of those protocols.
There’s a reason the CCENT, CCNA, and various other networking certifications are highly valuable.
This, right here, cast doubt on the entire rest of her resume.
My coworker looked at me, then turned back to her and started prodding at other stuff she listed.
Coworker: It says here that you have experience with test-driven development. Can you tell us what that is? What’s the scope of your experience here?
Her: Uh, yeah, that’s where you write tests for your code. My current research team uses test-driven development; we track test cases in a large spreadsheet.
She didn’t really answer the question. Of course TDD involves writing tests for your code. But the key paradigm is that you always write tests first. Then you add application code so that those tests pass.
This method of development prevents the writing of any untested application code. Read more about it here.
So she didn’t really understand TDD at its core. My coworker and I looked at each other. 3rd time’s a charm, right?
Her: I… uh… what? Static? Yes Java and C have the static keyword.
Now, I wouldn’t expect a sophomore in college to know this. But she was a graduating master’s student who listed >5 programming languages on her resume.
(Read about static vs. dynamic type languages here)
This interview was already not going well. We thought it. She could feel it.
Several other questions were asked, all with similar results. She eventually asked to use the restroom, and when she was away, my coworker and I just sat in silence, looking at each other.
Then came the coding portion.
Candidates brought in their own laptops so that they could work in their own, comfortable environments.
The prompt was simple.
Given a 2D array of integers representing a Sudoku puzzle, write a function that checks its validity.
After discussing and writing the code, they’d need to compile and run it. Test input was provided. Candidates were filled in on all of this before coming in.
It took her the first fifteen minutes to get the following code written (it’s supposed to be Java):
For those of you who know these languages, you’ll recognize that this code is a hodge-podge of Java and C. Java uses
camelCase while C uses
snake_case. Although, aligned braces tends to be a C# paradigm. I have no idea where that came from.
She forgot to initialize
i. She hadn’t instantiated her
mem ArrayList. She didn’t give a name for her input variable on
check_valid(). Her for-loop condition was incorrectly
<= 9 instead of
< 9, so her loop would’ve iterated 10 times. The
bool keyword was wrong.
The only parts of this code that were correct were the auto-generated portions by Eclipse.
At this point, I jumped in and tried to give her a chance to save herself.
Me: So, some of this looks like C code. Is that your strongest language? Do you want to write the solution in C instead?
Her: Nono, it’s fine. I know both Java and C. I want to challenge myself.
My coworker looked over at me with a “WAT DAFUQ” face.
An additional agonizing 17 minutes pass by, and she was still struggling to get these for-loops written despite us talking her through it.
At this point, I was just bewildered by her decisions. Not only was she ignoring the red squigglies / warnings that Eclipse gives to tell you you’re screwing up — she was continuing to make more mistakes.
Me: So, why did you change the for loop to not use the index?
Her: This is the optimized way.
Me: (confused) …but wouldn’t those indices be useful for checking specific elements?
Her: Nono, you don’t need index to access array elements.
She never even got to compiling and running it. There were too many errors.
After she left that day, we got back to her later that afternoon and gave her a polite rejection and some feedback for improvement.
But wait — there’s more.
That night, our manager received a long email from her professor talking about how great of a student she was, how good of a choice it would be to employ her, and that we should reconsider.
See, this is levels beyond desperate — sophomore me tried to defend myself at the end of a disastrous interview, but at least I didn’t cry to my professor that night to send a defense email on my behalf.
This candidate’s story still lives on in infamy today between all of us who were present that day.
Moral of the story: Just like in the previous story, anything you put on your resume is fair game for interviewers. If you don’t know it, then don’t claim you do. Also, your professor can’t save you from a disastrous interview — only you can.
Winter 2018. I was interviewing for a remote DevOps Engineering position with a media company.
The initial phone screen and online assessment went by without a hitch, so it was time to get on a WebEx call and have a (remote) face-to-face chat with the Director of DevOps.
Conversation started off great — got to know about the director himself, bits and pieces of the company, and was able to competently answer questions. But my concern started when 20 minutes in, the questions never got really more in-depth than “Explain how DevOps benefits companies.”
We neared the end of the call where I was able to start asking him questions. Here is where things really started to crumble.
Me: So, if I was to start working here, what would my day-to-day look like?
Him: Yeh well, right now our team is working on migrating legacy stuff over to virtualization. So you’d probably be uh, helping with data migrations and standing up infrastructure.
Me: Okay. You told me earlier you’re running your software on self-hosted baremetal. Is the team open to trying out the cloud? Have you heard of Terraform?
Him: …(longer pause, he rubs his forehead) I gotta be totally honest with ya, but a lot of the engineers here are pretty old. They’re old-fashioned, pretty reserved.
We’ve been trying to deploy our applications to VMs instead of self-hosted servers, but it’s been an uphill battle trying to upgrade the tech around here.
Me: …have you considered using Docker or Dockerizing your applications?
Him: (uneasy shifting in chair) Yeh I’ve discussed it with the board. I’m working on putting together a business case for it to present to the VP of Engineering. The other developers don’t seem too bought in to it though.
This poor man had to f*cking put together a report to explain the advantage of Docker over baremetal to his boss. And apparently the developers on the engineering team aren’t sold on it.
In my experience, most people who “aren’t sold” on widely-adopted, cutting edge technologies are usually on the decline. It’s a harsh opinion, but I’d like to be proven wrong.
Working with upper management and teammates that restrict and discourage rather than empower you is a recipe for stress and career death.
Me: I saw in the job description that part of this role includes reliability and uptime. Does that mean we’ll be on-call?
Him: Yes, that’s correct. Right now there are only 3 of us, but if we were to hire you there’d be 4. We each take 1-week rotations. Recently we sigh had a bad batch of fires to put out so Rodney has had a tough week. But usually this doesn’t happen.
They also made budget cuts to our team earlier this year, so it’s been difficult to find new hires.
…what? One-week rotations of being on-call? If things are on fire (which it sounds like they often were at this company), I could literally be up all night, every night, for a week, every four weeks. Nooooo.
And also, why make budget cuts to their DevOps team? If money is a struggle, trying to optimize your development / deployment processes becomes more important, not less!
If anything, let go of some of the crusty, settled engineers who have no interest in improving the status quo. They’re expensive, dead weight.
I called them back the next day to let them know it wasn’t a good fit.
Moral of the story (1): If you’re frustrated with your job and interviewing candidates, don’t let them in on it. If you can’t shine a good light on your employer (or the position you’re hiring for), then it’s probably time for you to leave.
Moral of the story (2): It’s just as important to dodge sh*tty jobs as it is to interview well and get offers from really good jobs.
I read all responses to all of my stories, and when possible, respond to them. Comments & questions on the above stories also welcome.
Thanks for reading!