Skip to content

How to approach DSA

~6 min

In short

  • Learn a small set of data structures and patterns, practise them in order of difficulty, and explain your reasoning out loud.
  • "Interview level" is not a published standard. No company publishes one.
  • Steady practice, several times a week, works better than long weekend marathons.
  • DSA and system design are the two skills that matter most. Practise as much as you can: competitive programming and DSA practice is the most direct way to build the problem-solving ability that strong companies test. It does not guarantee an offer, but it raises your odds more than anything else on this site. Aim for 1,000 or more problems over time, with at least 250 of them hard-level, aiming at the hardest-selecting companies (see the hard-company bar), spread across the question styles of many companies, not one (see topic order).

What "interview level" means

No company publishes a standard for DSA interview difficulty. The most a primary source says is about process. Amazon's careers page lists four stages (online application, assessments, phone screening, interview loop) and says the process "differs from role to role" (source: Amazon, fetched 18 Oct 2026).

So "interview level" here is the author's working definition, not a company's. For a fresher it usually means: you can take a medium-difficulty problem you have not seen before, reason to a correct approach without a hint in a reasonable time, write working code in one language without an IDE, test it on edge cases, and state its time and space complexity. Ask yourself whether you can do that on a new problem, not on one you have already solved.

How to approach it

  1. Learn the core structures and their costs. Arrays, strings, hash maps, stacks, queues, linked lists, trees, heaps and graphs. For each, know the main operations and their complexity.
  2. Learn patterns, not answers. Two pointers, sliding window, BFS and DFS, binary search on the answer, and dynamic programming each solve a family of problems. Recognising the family is most of the skill.
  3. Work in topic order. The order and the reasons are on topic order. Stay on a topic until you can solve its typical problems without looking things up.
  4. Practise with a time box and a review. The loop is described in practice method. Solving alone is not enough; the review is where most of the learning happens.
  5. Keep a log. A log of mistakes is what stops the same bug from coming back in every interview.

A simple weekly rhythm

A workable minimum for people with a job, a college timetable or other commitments is four sessions a week, each 45 to 60 minutes. If you have more time, do more; volume with review is what builds speed:

  • Two new-problem sessions on the current topic: one or two problems, each in a time box.
  • One review session on the mistakes log and the problems due for review that week.
  • One mixed session of random problems from topics you have already finished, to keep them fresh.

If you have more time, add sessions rather than making each one longer. Short, frequent practice keeps the review schedule workable.

Common traps

  • Watching videos without solving. Watching explains a solution; it does not build the skill of finding one. Solve first, then watch.
  • Jumping between sites. Each new site restarts your practice. One sheet and one problem site for the first pass is enough.
  • Reading solutions too early. If you read the answer in the first five minutes, you have not practised. Use the time box.
  • Skipping the review. Solving a problem once is a small part of learning it. The review and the repeat are the rest.

Where to practise in Python

If you want to practise in Python, the Python course has two parts that fit this:

Use them as your Python practice set alongside the free sites in free resources. Check each part's contents before you start, so you know which topics it covers.

Try this

Pick the first topic in the order, arrays and strings. Set a 30-minute timer, solve one easy problem in Python on paper or in a plain text editor, and write down its time complexity. Then check the answer and note any mistake in your log.

Sources

  • Amazon, "How we hire": https://www.amazon.jobs/content/en/how-we-hire
  • Tech Interview Handbook, coding interview study plan: https://www.techinterviewhandbook.org/coding-interview-study-plan/