DEV Community

Cyber Janitor
Cyber Janitor

Posted on

Excel At Coding Interviews

If I were to go back all over again and re-learn data structures & algorithms, Leetcode, and interviewing under pressure I would do the following:

  1. Mix between the depth & breadth approach
  2. Learn to type faster
  3. Let your brain do the work, and don't over stress

1. Mix between the depth & breadth approach

There's a lot of topics to cover: graphs, trees, linked lists, arrays, dynamic programming, tries, queues, stacks, etc. So how do you get good at all of these since any one of them can show up on your interview? There's two approaches

Breadth

Like a breadth first search, the breadth based learning approach allows us to expand outward in each direction, meaning study all topics at once. Although we may not become experts or specialized in any given thing with this approach, we still gain a lot of experience in a wide variety of things. So don't just master linked lists then move on to trees, then after mastering that move on to graphs. That will take you a long time. Just like in school they don't make you only take math, then after passing it you only take English. The topics are different enough that you can practice both in the same session without feeling drained. So try to practice a wide range of questions with different topics as early as you can. Don't wait to perfect one then start learning another.

The breadth based philosophy also applies to the way you practice a given problem. Let's say you can't figure out the problem after 15 minutes, that's fine, just look at the solution. Although problem solving is important, learning from other people's solutions and not spending too much time on one thing will also help a lot. Let's say you struggle on one problem for a whole hour while someone else attempts 4 problems then looks at the solution. They've learned 4 patterns in that hour. You've only learned only one. Although arriving at the solution yourself makes your problem solving ability much better, you don't need to do that for every problem. That will get in your way more than it helps. It can be good to build a foundation from other peoples solutions and explanations and then after you gain enough experience you can challenge yourself more. Basically use the training wheels while you can to ease the process, then once you are an intermediate you can take them off.

Depth

The depth based approach allows you to zone in on one particular thing. This is where you "specialize". This method is used to get to the next level. The breadth approach is better for beginners since it's harder for them to specialize when they don't even have a foundation. But once you do you can zone in on a given problem type. This helps your brain see the patterns better since you keep attempting the same type of problem until eventually they become second nature.

The depth philosophy is the opposite of breadth when it comes to how you approach the problem. With this approach I want you to not give up until you solve the problem. (Unless it's extremely hard and you really know you can't do it). But you can take breaks, or do another problem, or come back the next day. But what is important is that from the moment you start the problem to the moment you end, your reasoning is entirely yours and not influenced by anyone else. That gives you confidence in your own problem solving ability and also improves that part of your brain. Secondly it allows you to speed that process over time. A problem that may have taken you 3 hours to get the optimal approach for this year may take 5 minutes and seem trivial in the future.

So mix these two approaches. You can do both at the same time. For beginners I'd say practice mainly the breadth approach. For more advanced people do more of the depth approach. But an approximately even balance of both is still great regardless of level.

2. Learn To Type Faster

This is a no brainer and pretty self explanatory. If you type faster you code faster, and if you code faster you can solve more problems, they take less time, and you are less likely to fail due to time constraints. Also you can impress your interviewing with your lightning fast hands. But how do you do it? There's two things I think are necessary. One is general typing practice using sites like monkeytype or typeracer. These allow you to practice typing quotes, random words, and paragraphs of text. This will increase your speed very quickly and then you will start to plateau. You can push harder if you want but going from 120 wpm to 150 wpm is a much slower process than going from 40 to 100 wpm. And 120 is sufficient but feel free to aim for faster, it doesn't hurt.

Once you hit that plateau a better "bang for your buck" is to practice code specific typing. So you might be great at typing regular alphabet characters, but do you slow down when you type semicolons, brackets, or even numbers? These characters are prevalent in code and so practicing them will make you stop or slow down less when you code. I developed a site called CodeRacer. At first this site was a project just for me to improve my coding speed. It worked wonders and so I decided to share it. It's absolutely free and you can practice typing out real code snippets for free in 10 different langauges. No sign up needed! There's also other sites out there for practicing code. In my biased opinion of course I enjoy mine the most.

3. Let your brain do the work, and don't over stress

When I first started doing Leetcode I would attempt a problem, come up with a solution I thought was really good, then realize it's either flawed and can't pass the test cases, or it's too slow and times out. I'd search up the solution and then think to myself how I could never come up with a solution like that. I'm not smart enough. Funny thing is, those were easy level problems! Now I look back at those problems like they are nothing. I can code an optimal solution with my eyes closed in 30 seconds.

A mental model that would have helped me a lot when I started is to think of learning the same way I think about exercise or weight lifting. If you challenge yourself with sufficient weight and go close to failure then your muscle will grow because you've put your body under a new stimulus that it needs to adapt to. You don't tell the muscle how to grow, the body just does that for you in the background. Similarly when you do Leetcode you challenge yourself with a problem you know is slightly above your pay grade. Then once you complete it and feel exhausted your brain realizes it needs to adapt to make you more efficient at doing this. And by the time of the next session your brain has magically made you slightly better at this. So ignore any discouraging thoughts that make you believe that if you can't solve an easy problem now then you will be destined to stay that way your whole life. You'd be surprised how fast you can adapt to these things.

Extra Little Tid-bit

Hey if you stuck around I want to give you one more little tip. Always challenge yourself. If you've never heard of the 10,000 hour rule it states that if you practice something for 10k hours then you'll be a master in that field. I watched an interview with Andrej Karpathy where he said that those 10k hours have to be quality hours where you are close to your ceiling and you are actively challenging yourself. For example if you want to get better at math and keep practicing addition with single digits then you won't get better. The cycle is simple. Practice something close to your ceiling -> adapt (sleep, rest, eat) -> repeat. After every practice session you develop a higher ceiling! And if you're wondering how you can determine if something is close to your ceiling I say just pick something that you don't immediately know the solution to, especially if it's slightly exhausting or hard to figure out.

Thanks for reading!

check out my site coderacer to improve your code typing speed in 10 different languages!

Until next time!

Top comments (0)