Note: I have never directly interviewed anyone for an internship, but alas, here are my thoughts :).

Most coding challenges are pattern recognition tasks that take some time to learn. In my opinion, it is similar to the standardized testing that students use to apply to colleges. As a corollary to this analogy, being only good at interviews doesn’t correlate to how well you will perform at your new job; since most coding jobs don’t require people to implement dynamic programming algorithms. However, knowing how to solve these problems can help you get your foot in the door. I’ve definitely gotten better at coding challenges with more practice, and I hope these suggestions will help you.

Decide on a language to code in (use python!)

Although most people can code in multiple languages, choosing one language to program in for all coding challenges will save you a lot of time.

I get confused between different function names in different programming languages. Is it len() or length()? Normally while coding, I’ll google “how to find the length of string python,” but I don’t want to waste precious time asking my interviewer these questions.

Furthermore, coding interviews don’t appear to test how well you know the coding language your actual job is using (especially for new grads), but rather how you think through the problem. If you frequently get tripped up by the language, it’s not worth the stress and frustration of using a language you aren’t comfortable writing in.

Also, some languages take longer to write than others. I used python in all my interviews, even though most of the apps I wrote were in Java and objective-c at the time. The syntax and the verboseness of Java weren’t something I wanted to deal with in a coding interview.

Leetcode is not the ‘solution.’ Don’t only do leet code problems

I’m personally not a fan of “just doing leetcode.” Leetcode seems designed explicitly for technical interviews, and their problems are uninteresting and frankly quite dry. I think there are more exciting problems to solve than reversing strings. Furthermore, people who only practice leetcode problems (and review only their algorithmic solutions) won’t exactly improve their ability to write in a specific programming language and their style. We’re going to eventually forget all the fancy log(N) algorithms we used. But hopefully, through practice, we’ve also become better at writing code because that will benefit you far into the future. Only looking at hacky solutions can give you a skewed version of what ‘good code’ looks like. It also looks terrible when you know the exact algorithm to solve a problem, but a simple for loop trips you up. 

There’s also something special about trying to set up your environment on your computer (instead of coding online) and working on a simple script to try an idea out.

But I digress; other sites with more narrative and fun problems can make practicing more enjoyable and akin to real-life problem-solving. I’d recommend checking out Project Euler (more mathy), UIL computer science (the coding part — easier on algorithms and harder on implementation), USACO (it’s all about the cows), working on an online hackathon project, and code forces (battle other people).

Get good at analyzing runtime complexity and associated data structures

One fortunate (or unfortunate) thing about technical interviews is that most solutions use one of the basic data structures to solve the solution. If the problem is looking for an optimal log(N) runtime, hashes and binary trees immediately come up to my mind. Because of this, knowing the different types of data structures and the general problems they are used to solve can be helpful.

Analyzing runtime complexity is also a great way of proof checking if the solution you proposed is better than brute-forcing the solution.

Lastly, I’ve messed up many interviews by starting on the wrong foot and writing an entire algorithm that used the wrong data structure when the data structure was evident, given the problem. Before thinking of any solution, I’d recommend first finding the brute-force solution, calculating a runtime, and trying to find solutions that are logN better or N better than the brute-force runtime.

Try and try (again selectively)

Just because I got the problem right the first time means I’ll understand it in the future. Especially if it took a while the first time or I needed some outside help. I occasionally went back and tried solving older questions that I knew I struggled with. That was super helpful for me.

I also only began studying a few weeks before my internship search began. Starting too early can make it easy to forget, and anyway, only coding challenges can be good practice if you review what you did wrong afterward.

As a counterargument, if you’re good at something, it’s less critical to work on those skills. If you feel confident in implementing a binary search, skip the binary search problems once you figure out that binary search is the solution.

It’s just like the SAT: Coding ability isn’t the only thing that gets you in. And luck plays a huge part.

No matter how much coding you’ve done in high school, some people are just better. The point of an internship is to develop students earlier to become better coders. Thus, creating a balance of practice where you enjoy coding is of utmost importance so that you will enjoy coding once you get a full-time offer — and not burn out and hate coding for the rest of your life. You shouldn’t ‘need to study’ to get an internship, and I know so many people who didn’t do leetcode and succeeded. Interviewers know this and look for other things than how quickly you can write an algorithm.

Never view a bad interview as “I should’ve done more leetcode.” Sometimes interviews go badly, or a question is just, so niche, and you weren’t ready. :) Staying optimistic during the process is essential to ensure you don’t drain your enjoyment of CS.