How to fail a technical interview

Quick recap. Last year, I walked away from being a founder/CEO to return to the job market as a software engineer. This is a piece of that story.

---

At SharpestMinds, I helped folks start their careers in technical roles. The biggest help came from the mentors they found on our platform. But SharpestMinds had amassed a canon of job search advice over the years. A significant part of that advice concerned the technical interview. It sucks. It’s nerve-wracking. It’s not a great indicator of job performance. But you can’t avoid it so you better prepare for it.

The thing is, everything I knew about the technical interview was second hand. I had never really done a real interview. I felt a stab of imposter syndrome every time I tried to offer guidance to a struggling mentee. So as I geared up for the job search, I was anxious. I would finally have to face this fearsome beast of the tech job search myself.

My first interview (the one that humbled but inspired me) was an exception to the rule.—they had me work with them on a real project for two days. But that doesn’t scale. Most job postings get way too many applicants and they need to be narrowed somehow. I understand why the technical interview exists—but it still sucks.

My first taste was a 15 minute live coding exercise with the CTO of a series B startup watching my screen. I had to write a simple python function—take a roman numeral string as input and return its corresponding integer.

I overcomplicated it. Big time. Anxious to write something, I kept starting half-baked solutions, second guessing myself, and getting nowhere. I was thinking recursion. I was thinking multiple nesting cases to handle.

In the end, the logic was annoyingly simple. My interviewer gave me enough hints that I eventually arrived at a solution. There were two simple rules to read a roman numeral. Rules I may have discovered quickly if I had took a breath, ignored the empty page, the ticking clock, and thought through a few examples. Easier said than done.

I knew I didn’t preform well but I was still hopeful that my startup experience would land me a follow up interview. I was confident in my ability to preform on the job. Where presumably I’d be building things, not solving puzzles.

No such luck.

“In terms of feedback,” my interviewer elaborated in his rejection email, “I would say it's mostly around speed and efficiency.  We usually want to see the candidate getting to the end of the problem more quickly… I know you're a bit out of practice with these kinds of coding puzzles, but on the other hand, I think there would be some expectation to have… of brushed up on them a bit.” (Emphasis mine).

That rattled me. I spent my summer up-skilling and I was proud at how much I had learned. I got familiar with new tools, frameworks and languages by build a working application with actual business value. I ventured far out of my comfort zone and contributed to Chroma, an open source vector database. I was a builder. I could get productive quickly. I knew I would be a good hire. But I couldn’t get a second interview because I hadn’t been grinding coding puzzles?

A few breaths. A night to sleep it off. I got over it. You just started the job search, Russ—you knew this would happen.

But knowing something is different than experiencing it. And this would not be the first technical screen that got the best of me.

---