Heard You Have Been Grinding LeetCode: The Data Structures and Algorithms Round in Every Software Engineer Interview

My Practice Pace
First, Understand the Problem
When You Get Stuck
After Solving: Complexity and a Notebook
Reviewing After Interviews
Quality Over Quantity
LeetCode and Premium
The Job-Hunting Series

Editor’s note (2026): This post was written in 2020, and the format of coding interviews at big tech companies has changed noticeably since. According to reporting by 404 Media in 2025 and publicly shared candidate experiences, Meta began piloting an AI-assisted coding interview in October 2025: a 60-minute CoderPad session with a built-in AI assistant, working inside a multi-file codebase. Moving the other way, Google CEO Sundar Pichai has said publicly that, in response to AI cheating, Google has restored at least one in-person interview round. Amazon asks candidates to commit not to use unauthorized AI tools, and Anthropic prohibits AI assistance during its interview process. The tools and formats keep changing, but the preparation method shared here, understanding first and quality over quantity, still applies.

First, a clarification: I am not currently grinding problems. (And I am definitely not saying that because coworkers might read this. XD) Honestly, I think people overemphasize the “grind” in grinding problems, as if you have to paint over the same wall again and again. I have seen many people share how they solved several hundred problems, redoing each one two, three, four times or more. I admire the time and persistence they put in, but I know I cannot do that, and after having kids it became even harder to get through a single pass. From my own job hunts: in 2015, after finishing a coding bootcamp, I did about 60 LeetCode problems before landing a job. At the end of 2016, when I searched more seriously, I finished about 100. This post shares how I prepare for algorithms interviews. If you are looking for a way to practice, or if you are someone who cannot imagine grinding hundreds of problems over and over, read on.

My Practice Pace

After the bootcamp in 2015, I started getting phone interviews, sometimes one to three a day. So my preparation meant researching each company and reviewing based on the role. Since I was interviewing for front-end positions, part of my energy also went to front-end material. For data structures and algorithms practice, I kept a pace of about one to two problems a day. In late 2016 I was working at the same time, so I mostly had evenings: about one problem a day, and a few more on weekends when I had more time.

First, Understand the Problem

When I see a problem, I first make sure I understand what it is asking. In a real interview, the first step is the same: confirm with the interviewer that your understanding matches what they intend, so you do not burn time only to discover your initial assumptions were wrong. I immediately write down what the input is, what format it takes, and what the desired output should be.

Once the input and output are clear, I think about which data structures or algorithms could solve it. In an interview, I tell the interviewer that I will start with a rough approach that works, and if that sounds fine, optimize from there. Once I have some direction, I write pseudo code first, explaining my solution in plain English. Only after checking each step with the interviewer do I write the actual code.

When You Get Stuck

Of course, sometimes no matter how hard I think, nothing comes out. When I practice on my own, after about 15 minutes I start reading discussions to learn from other people’s approaches. If another 10 minutes still does not crack it, only then do I look at someone else’s solution. After reading it, I still implement it again in my own code. If I get stuck during an interview, I talk to the interviewer as soon as possible. I share my understanding and the approaches I am considering, and I am upfront about which parts I am unsure of, so the interviewer can give a hint at the right moment. In general, companies want a good interview experience, and interviewers are happy to help as long as the communication is healthy.

After Solving: Complexity and a Notebook

After solving a problem on my own, I write down the space and time complexity of my solution. Interviews usually ask about this too, so I summarize it for every practice problem. If I suspect my solution is not efficient enough, I read more discussions, study better approaches, and implement a different version myself. For trickier problems I might write two or three solutions and compare their trade-offs.

When I was preparing, I kept a notebook. After each problem, I wrote down the date, which problem I did, and a very short summary of the problem and the solution. The next day, before starting a new problem, I would look at the previous day’s problem and try to recall the rough solution in my head. If I could not, I read my summary, marked the problem, and repeated the same step the next day, until I could reliably reconstruct the reasoning.

Reviewing After Interviews

After any interview, phone or on-site, I check whether the problems I got resembled ones I had practiced. If they did, was my thinking clear and correct during the interview? If they did not, did I apply the right concepts anyway? After each interview I spend time taking stock and reviewing, consolidating what showed up in interviews with what I had practiced.

Quality Over Quantity

You can see my practice style does not emphasize speed. I want deep understanding from every problem I finish, so I spend a lot of time organizing and re-checking. Even if I did not fully get it at the time, I review it again if I cannot recall it the next day, and check once more before the following day’s new problem. With enough rounds of review and thinking, the concepts a problem is really testing start to click. Interviews rarely repeat the exact problem anyway. What matters is our understanding of data structures and algorithms, and how we think when facing a hard problem.

There are many roads to Rome, and everyone prepares differently. The above is simply my way of preparing for data structures and algorithms interviews. My earlier job-hunting series never covered this piece in particular, so I wrote it up to share. Of course, I am no wizard who harvests five to ten offers from every search, so weigh my method for yourself. We all need to find the approach we can accept and that works efficiently for us.

LeetCode and Premium

Back in 2015 and 2016, when I was preparing, there were many sites for practicing algorithms. Today, LeetCode and algorithm practice go together the way Google and search do. Almost everyone I hear about who is preparing uses LeetCode.

Most friends I know who are preparing buy LeetCode Premium. Its biggest benefit is seeing which companies a problem is tagged with. Take Google, which rejected me twice (XD): users had reported 925 problems seen in Google interviews, and by 2021 that number had grown to 1,014. When a phone screen or on-site is coming up, focusing on your target company’s problems can improve your efficiency, and with it your performance. Premium also offers faster judging, official solutions, and mock interviews organized by company, but most people seem to pay mainly for the company tags. (LeetCode has since added learning resources like articles and videos, plus Study Plans. It clearly wants to become a one-stop service where people learn, prepare, and stick around.)

Given the raise most people get with a new offer, it is a good investment. (What? You say a raise is not guaranteed? Then read my negotiation posts and negotiate one: Asked About Salary Expectations in an Interview? How to Handle the Money Question and Got an Offer? How to Negotiate Salary: The Sandwich Method and a Final Move Before You Sign.)

The Job-Hunting Series

Here are the job-hunting posts I wrote before this one:

If you are job hunting in 2021, I hope your move goes smoothly and you land plenty of offers you love. If you have preparation tips of your own, please share them in the comments.

Postscript: When this post was updated in September 2021, many readers who had just arrived in the US to study wrote in asking about referrals for summer internships. If you are looking for referral resources, see The Most Effective Way to Get an Interview: Referrals, and the Network I Built Around Them.

This post was originally published on my former blog, 「半路出家軟體工程師在矽谷」, on December 30, 2020. The blog is now offline; the full text is preserved by the Wayback Machine. For this site, expired discount and giveaway information was removed and an editor’s note was added.