LeetCode is a disaster. And a necessity.

Grinding LeetCode is a waste of your time.

Unfortunately, it’s a waste of time that many companies enforce and expect. So many companies in our industry have fallen for the trap of whiteboard interviewing. It’s a dangerous way to hire software engineers.

But this article isn’t about whether companies should do whiteboard interviews. The reality is that many companies do.

If you’re interviewing for a job, you’re going to encounter these types of problems. So, should you study LeetCode problems anyway? Is practicing data structures and algorithms worth it?

It’s complicated, but maybe…

A note on terms

Throughout this article I’ll refer to “whiteboard interviews.”

I’m using that as shorthand for all types of live coding challenges. Whether you do it in-person or virtually, without tools or in an IDE, with suggestions from the interviewer or all alone.

A virtual interview on CoderPad falls in the “whiteboarding” bucket.

The problem with algo questions

Whiteboard questions are a bad proxy for what the interviewer really wants to know:

Can you do the job of software engineering?

The truth is, you can be a perfectly effective software engineer without ever solving 3Sum, Pacific-Atlantic, or K-Closest to Origin. In fact, these problems are more like brainteasers than they are actual software engineering challenges.

They don’t map well to the real problem solving you’ll do at work. Remember, at work you’ll have access to:

• Your IDE
• Tools to run and test your code
• Google
• Open source libraries that have already solved many problems
• Other engineers to brainstorm with
• Focus time with no countdown clock on how long the problem takes

Writing a simple algorithm alone at a whiteboard under a time constraint is a terrible way to simulate real work.

In the real world, you work on a complex application with teammates in your IDE with added tools on a flexible timeline.

Ultimately, the success of a whiteboard interview boils down to whether you’ve seen this problem (or a similar one) before. Unless the code is incredibly trivial (reversing a string, foobar, fibonacci). In which case, why are interviewers asking that question at all? It’s insulting.

(Before people jump in the comments and say, “As interviewers, we have to check coding skill somehow!” let me stop you right there. There are better ways to test skills and you know it. A take-home assignment or even a paid trial work week will tell you far more about a candidate’s coding abilities.)

I hate whiteboard interviews! I won’t do them!

That’s a valid response. They’re pretty terrible.

These interviews are largely pointless and don’t reliably tell companies about your abilities as a developer. For a list of examples, see rejected.us, a website of software engineers who were rejected one place and then went on to great careers.

You can totally have a successful career in software without doing whiteboarding interviews. But it’s going to be difficult.

You’ll have to say no to a lot of opportunities.

Whiteboarding is widespread. Many companies have accepted it as the de facto way to interview engineers. It’s so widespread that you’ll have a small subset of companies that it’s possible to work for.

So I should just suck it up?

That’s a personal decision. But yeah, at the end of the day you’ll have to decide:

1. Do I decline any interview process that includes algorithm questions?
2. Do I suck it up and learn some of the strategies so that I can get a job?

It’s a lose-lose choice, and I’m sorry companies have put us in this position. But it’s the reality.

I can’t tell you the answer to this dilemma.

If you feel strongly and ethically about whiteboarding, then you might pick option one. Or, if you are a bad test taker and don’t want to put yourself through the stress of those interviews, only interview at places that offer more humane, realistic coding assessments.

Option two is the path most of us choose. We need to change the system from within, so the argument goes. Getting the job is important, and then we can advocate for changes to the hiring process — offering alternatives to whiteboard interviews.

How to prepare

This system has been in place for so long that there are resources out there to help you prepare.

Here are my suggestions:

1. Go through the sections of the algorithms cheat sheet to gain a foundation in the various data structures and common patterns.
2. Use Grind75 to pick which problems to practice, based on how much time you have (between 2 weeks and 3 months is what I’d recommend).
3. Once you’ve solved a problem (or if it takes more than 10–15 minutes to think of a solution), look at the discussion to see if there are better approaches than the one you picked.
4. Create a flashcard in Anki for each problem you solve. Anki will show you the cards with spaced repetition so you don’t forget what you’ve learned previously.

Use these steps, and you’ll be ahead of most candidates because you’ll actually have a firm foundation, clear strategy for picking what to practice, and a method for remembering what you learned.

Final thoughts

I hate that I have to suggest these steps at all.

There are better ways to hire engineers and companies should be looking for them. Asking whiteboard questions is the low-effort way of hiring. There are better options that serve both candidates and companies better.

That said, the steps I’ve provided here are the best way I know to limit the amount of time you have to spend studying these questions.

That way, you can get back to actual engineering work or just enjoying your life.

More resources

7-day email mentorship — Build a meaningful software careeer

Technical interviews are insulting — More thoughts on interviews

Saying “no” to a coding challenge — Lessons I learned when I said no

Questions I ask interviewers — Turn the tables & ask them hard questions

Join Medium for $5 - Access all of Medium + support me & others