If you’re reading this, then you’re likely a current or prospective college student looking to break into tech by landing a coveted software engineering internship. If that’s you, you're doing a great job of staying on top of your career development! Internships are the surest path to a full-time job, especially in the notoriously competitive tech industry amid a job market that’s (as of 2024) still reeling from layoffs and hiring freezes. I’ll assume that you’ve already done your due diligence of submitting applications to the listings you’re interested in, cleaning up your resume, and writing individualized cover letters and reaching out to recruiters on LinkedIn (if possible). You likely already know about all that, and frankly that’s not the hardest part of snagging an offer—that title would belong to the dreaded coding interview.
What’s So Special About the Coding Interview?
Technical interviews are, by their very nature, never easy, but coding interviews are known to be particularly challenging. In fact, I am of the firm belief that most coding interview questions are so difficult that I would not expect the typical computer science undergraduate to be able to solve them without having seen a similar problem beforehand. They test both knowledge and application of data structures and algorithms, and usually come with a “trick” to solving them. That is to say, you might be able to come up with a brute-force solution that technically works, but the algorithm takes up too much time or memory and the optimal solution is often a specific design pattern that you’re very unlikely to discern on your own.
Take, for example, the well-known and deceptively tricky question colloquially known as “Two Sum:” given an array of integers and a target integer, return two numbers in the array that sum to the target integer. You may be able to come up with the naive brute-force approach on your own—loop through the array, and for each number check all the other numbers in the array to see if there is a combination that adds up to the target integer. Now this does work, but the algorithm would have to repeatedly check every number, for each number of the array, becoming exponentially slower as the size of the array increases. In Big O notation, this is known as quadratic O(N2) time. Unless your interviewer is exceedingly lenient, this will likely not be an acceptable answer. The “trick” here is to use a hashmap: an extremely handy data structure that allows you to store and retrieve values in constant O(1) time. With a hashmap, you can bring that time complexity down to linear O(N) time by only traversing the array one time. At each number, you would check if there’s another number in your hashmap that, with this current number, sums to the target integer; if not, store the current number in your hashmap in case it can be combined with another number later down in the array to sum to the target.
Harder than it seems, right? This example illustrates the importance of having a strong command of data structures and algorithms as well as how difficult it can be to figure the optimal solution to coding interview questions. Unless, of course, you already knew the tricks to them because you’ve seen them before, in which case it would just be a matter of adapting the design pattern to your specific problem and implementing it with code. Fair or not, this is the game we have to play.
How Do I Go About Preparing for the Coding Interview?
Once upon a time, while the Internet was still maturing, the de facto guide on studying for this tricky interview process was a neon green paperback book titled Cracking the Coding Interview (also the namesake of this blog post). While that book does still hold up, nowadays there are much more streamlined and hands-on ways to prepare, the most popular and extensive of which is the website LeetCode.com. Whatever your approach, the idea is to gain exposure to a broad variety of problems, any one of which could very well pop up in a real interview (in fact, you’re kind of hoping they do). That way, you’re maximizing your chances that you will be asked a question that is at least similar to one you’ve done before, allowing you to employ the optimal solution because you already know about the trick to solving it.
What this looks like in practice is simply doing a lot of practice problems. It’s going to feel overwhelming at first and more than a little disheartening if you can’t even solve the problems marked as “Easy.” This is to be expected! In my own experience, I’ve found it most effective to give the problem an honest 5-10 minutes of trying to write my own solution; if I’m still stuck after that, any further progress is honestly pretty unlikely, so I’ll look up a solution on YouTube. However, this next part is key: I will only watch the first part while the video explains their approach, maybe with some pseudo-code, but I will always pause before any code is actually written and try to translate their explanation to workable code. This allows me to get past the hardest part (figuring out the “trick”) but still practice writing the actual algorithm, which is what I’ll have to do in an interview. Of course, if I’m still stuck after another 5-10 minutes, I’ll just finish the YouTube video. This is much more time-efficient than spending hours trying to get there on my own, but it’s still a pretty slow and oftentimes frustrating process.
Closing Thoughts and Action Items
I’d recommend following a list of problems that gradually introduces design patterns to ease your way into the harder questions. The Blind 75 is a staple, but any similarly organized list that covers a wide range of commonly-seen design patterns will do. For a free resource that has several lists of problems as well as corresponding videos that do a superb job of breaking things down with illustrations (all in Python, which is my favorite language), I can’t recommend NeetCode.io enough. I’m not sponsored or anything, it’s just been incredibly helpful and by far my go-to channel for solutions to coding interview questions.
Don’t be discouraged if your progress is slow at first because the concepts often build upon themselves. Once you can recognize the patterns it becomes a lot easier, but the only way to get there is to practice. Just keep at it and with enough diligence (and a little bit of luck), I’m sure you’ll be able to get a software engineering internship offer!
Comments