A Note About Interviewing as a Software Engineer

Warning: Rant to follow

After three and a half years, a belated college degree, and tons of experience gained after I started my first software job, I decided it was time to move on. I had absorbed all I could, and it was time to find the next gig. I sent out a million applications to a million different places (don’t do that). I used stuff like Hired (don’t use Hired), recruiters, and leaning on my network, no bites. Cut to six months later; I got a random email from an internal recruiter at a FANG company looking for engineers. I jumped at it immediately. That is when I got my first peek into the world of technical interviews.

While not the most communicative of recruiters (go figure), he sent me a whole packet of stuff to read. It was about how to succeed in the interviews, the types of questions I will run into, and a mock study plan. Despite the week of obsessive prep and three years’ worth of making software, I tanked the initial technical screen. The questions were nothing I’ve ever seen before; I was utterly baffled. I was at a loss. And yet, you don’t make it the first time you try again or die on an ice float, right? So, I began wading my way into the swamp of the technical interview prep industry. Website after website, YouTube video after YouTube video, paid course after paid course looking to teach you to beat a technical interview. Everything talked about how to think about problems, practice, how to read the questions, and many other tips. It very quickly started to feel like when I took MCAS prep courses in high school, teaching you to beat a test rather than apply the ideas being taught.

I signed up for a premium subscription for Leetcode. I split my time between reading, doing Leetcode problems, and little else. Going on like that didn’t help much either when I later bombed an interview at another FANG company. I was ignoring my friends and family to study. Long days of coding just to come home and code all night. Getting my degree while working a full-time software job wasn’t this hard. I was taking on a second job to get ready to interview for another job. Going on like this was unsustainable for me, and I quickly burnt out.

Take an industry that conforms to entrenched out of date practices, add to that gatekeepers that think these logic puzzles are how you weed out engineers, and you have some a situation brewing. Rather than looking for people who can or have the potential to do the job, some companies seem to want to cling to these antiquated notions of what a prospective hire should be. Another layer of complexity to this issue is that I think that these idiotic New York Times crossword puzzles do have a use other than gauging technical acuity.

After reflecting on these thoughts, I came to a few conclusions: Hiring software engineers is a broken process (we know that). It is starting to change as some companies recognize these cool twenty years ago approaches are often counterproductive. For example, at my current company, we give a mini-project that reflects what the candidate will work on and work with the candidate to help solve it. Secondly, the old guard is keeping whiteboard interviews alive despite knowing these issues. Lastly, learning algorithms and data structures can be helpful in other ways aside from preparing for interviews.

I just spent a couple of paragraphs denigrating studying DS and Algos, so this needs an explainer. While I don’t believe that solving Leetcode problems measures a software candidate’s potential, they can be a helpful exercise. For example, using those problems to practice and deep dive into languages is a valuable exercise. For people just starting out making software, hyper-focusing on one language is a good thing. Practicing data structures and algorithms in Python forced me to dig into the small nuances of Python. As a result, when my coach and I started to collaborate, he was blown away by all the things I knew in Python. Learning about these problems could be an opportunity for others to get into a language. A more intangible benefit is that they force you to think in terms of how best to optimize code. I noticed that I became more comfortable coming up with more complicated algorithms by spending time practicing questions that you see on Hackerrank or Leetcode.

I don’t believe that software is about how well you do brain puzzles but how you communicate and collaborate to solve real-world issues. Learning brain puzzles that don’t accurately reflect the work is not how you find people to hire. However, that is not the world we live in, so I want to try something. My hope is to use this as a jumping-off point to get in regular data structure and algorithm practice and pass on some knowledge. So, I hope to follow this rant with a series of posts that break down technical questions that I have solved and explain the underlying technology and techniques. I will not make a specific commitment because there’s a lot of good TV shows out right now. I will, however, strive to put forth my best effort on solving “Leetcode style” problems to share what I have learned and maybe help someone while I get in some practice. More to come; stay tuned.

Rant Over