Skip to content
C Codeloom
DSA

What Is DSA? Data Structures and Algorithms Explained

A beginner-friendly introduction to data structures and algorithms — what they are, why they matter for interviews and real performance, and how to actually start learning DSA.

·9 min read · By Yash Kesharwani
Beginner 9 min read

What you'll learn

  • What "data structures and algorithms" actually means
  • Why DSA matters for interviews and for real performance
  • The difference between a data structure and an algorithm
  • A practical roadmap for learning DSA from scratch
  • How to practice effectively without burning out

Prerequisites

If you’ve spent any time around software engineering, you’ve heard the phrase DSAdata structures and algorithms. It shows up in interview prep guides, university courses, and almost every job description that mentions “problem solving.” This post explains what DSA actually is, why it matters, and how to approach learning it as a beginner.

What DSA actually means

DSA is two things bolted together.

A data structure is a way of organising values in memory so that certain operations on them are fast. A list, a dictionary, a tree, a graph — these are all data structures. Each one makes some operations cheap (looking up a value by key in a dictionary) and others expensive (finding a key by its value in that same dictionary).

An algorithm is a step-by-step procedure for solving a problem. Sorting a list, finding the shortest route between two cities, deciding whether a word is a palindrome — these are all problems that algorithms solve.

The two are tied together because the right data structure usually makes the algorithm obvious, and the wrong one makes it impossible.

# Finding a name in a list — O(n), we scan every entry
names = ["Ada", "Linus", "Grace", "Alan"]
print("Grace" in names)    # True

# Finding a key in a dictionary — O(1) on average
ages = {"Ada": 30, "Linus": 55, "Grace": 85, "Alan": 41}
print("Grace" in ages)     # True

Same question, two data structures, completely different cost.

Why DSA matters

There are two honest reasons to care about DSA, and they reinforce each other.

1. Interviews

Most engineering interviews at competitive companies include at least one DSA round. The format is well-known: a problem statement, a whiteboard or shared editor, and 30-45 minutes to discuss an approach and code it up. You will not be asked to “build a feature” — you will be asked to find duplicates in an array, detect a cycle in a linked list, or find the shortest path in a grid.

The skills that get you through these rounds are exactly the DSA skills you’ll learn in this series.

2. Real performance

The other reason is that DSA shapes the code you write every day, even when nobody asks you about it.

# Bad: O(n^2) — for each user, scan every order
def total_spent(users, orders):
    result = {}
    for user in users:
        total = 0
        for order in orders:
            if order["user_id"] == user["id"]:
                total += order["amount"]
        result[user["id"]] = total
    return result

# Good: O(n + m) — index orders by user once
def total_spent_fast(users, orders):
    by_user = {}
    for order in orders:
        by_user[order["user_id"]] = by_user.get(order["user_id"], 0) + order["amount"]
    return {user["id"]: by_user.get(user["id"], 0) for user in users}

For 100 users and 100 orders, both versions feel instant. For 100,000 of each, the first version takes minutes and the second takes a fraction of a second. That difference is DSA.

Data structures vs algorithms — a clearer split

Beginners often blur the two. Here’s a clean way to remember it.

Data structures are nouns. They store things.

  • Arrays / lists — ordered, indexed
  • Linked lists — ordered, pointer-linked
  • Stacks — last-in, first-out
  • Queues — first-in, first-out
  • Hash maps / dictionaries — key-value pairs
  • Trees — hierarchical
  • Graphs — networks of connections
  • Heaps — priority-ordered

Algorithms are verbs. They do things.

  • Searching — linear, binary
  • Sorting — bubble, merge, quick, heap
  • Recursion and divide-and-conquer
  • Greedy strategies
  • Dynamic programming
  • Graph traversal — BFS, DFS
  • Backtracking

A real problem usually involves both. “Find the cheapest flight between two cities” needs a graph (data structure) and Dijkstra’s algorithm (algorithm). Neither alone is enough.

Try it yourself. For each of these problems, name a data structure and an algorithm that fit:

  1. Spell-check: given a word, decide whether it’s in the dictionary.
  2. Undo button: support an arbitrary number of undo and redo operations.
  3. Friend suggestion: in a social network, recommend friends-of-friends.

Don’t worry if you can’t name them yet — just notice that each problem has a natural shape.

A learning roadmap

Here’s the order most learners benefit from. You can skip around, but each layer leans on the previous one.

Layer 1 — Foundations. Big-O notation. You cannot reason about which approach is better without it. Cover this before anything else.

Layer 2 — Linear data structures. Arrays, strings, linked lists, stacks, queues. Most interview problems live here.

Layer 3 — Hash-based structures. Hash maps and hash sets. These are the workhorse data structures of practical programming.

Layer 4 — Searching and sorting. Binary search, merge sort, quick sort. These are the patterns that appear inside larger algorithms.

Layer 5 — Recursion and trees. Trees are the natural home of recursion. Master one and the other becomes easier.

Layer 6 — Graphs. BFS and DFS. Most “real world network” problems reduce to these.

Layer 7 — Advanced patterns. Dynamic programming, greedy algorithms, backtracking. These are the techniques that distinguish strong candidates.

You do not need to “finish” each layer before moving on. Aim to be comfortable enough to recognise the pattern when you see it.

How to practice without burning out

DSA practice is famous for two failure modes: grinding through hundreds of problems without learning anything, or quitting after a week because the curve feels too steep. Both come from skipping the same thing — active reflection.

The pattern that works:

  1. Attempt the problem for 20-30 minutes. No tutorials, no hints. If you solve it, great. If not, that’s also fine.
  2. Read the editorial or a clean solution. Understand the approach in full, not just the code.
  3. Close the tab. Re-solve the problem from scratch. This is the step that builds memory.
  4. Write a one-paragraph note. What pattern was this? What would have led you to it? What’s the time complexity? Where might you see it again?
  5. Revisit after a week. If you can still re-solve it cleanly, you’ve learned it.

This is slower than “just doing problems,” and it sticks dramatically better.

Try it yourself. Pick one classic problem — “given a list of integers, return two indices whose values sum to a target.” Solve it any way you can in Python or JavaScript. Time yourself. Then look up “Two Sum” and read the hash-map solution. Re-solve it from memory. You’ve just done one full cycle.

What this series will cover

Over the next posts in the DSA series, you’ll work through:

  • Big-O notation in depth — the language for talking about cost
  • Arrays — the foundation, with traversal, search, and the patterns that appear in interviews
  • Strings — character arrays with their own bag of tricks
  • Hash maps and sets — the most useful structures in practice
  • Linked lists, stacks, queues
  • Recursion and tree traversal
  • Sorting and binary search
  • Graphs, dynamic programming, and beyond

Each post will include worked code (mostly Python, with JavaScript where natural), a “Practice problems” section, and links to the next step.

A note on language choice

This series uses Python for examples because it reads close to pseudocode and avoids syntactic noise. Where the JavaScript equivalent is interesting or surprising, you’ll see it side by side.

Don’t worry about translating idioms across languages — focus on the structure and the cost. A dict in Python and a Map in JavaScript serve the same role; the underlying complexity is what you’re learning.

A worked first example

To get the texture of DSA thinking, here’s a small problem solved two ways.

Problem. Given a list of integers, return True if any value appears at least twice, otherwise False.

Approach 1 — brute force. For each pair, check if they match.

def has_duplicate_slow(nums):
    n = len(nums)
    for i in range(n):
        for j in range(i + 1, n):
            if nums[i] == nums[j]:
                return True
    return False

print(has_duplicate_slow([1, 2, 3, 1]))    # True

Time complexity: O(n²). For 100,000 numbers that’s ten billion comparisons.

Approach 2 — hash set. Walk once. If you’ve seen this value before, return True.

def has_duplicate_fast(nums):
    seen = set()
    for x in nums:
        if x in seen:
            return True
        seen.add(x)
    return False

print(has_duplicate_fast([1, 2, 3, 1]))    # True

Time complexity: O(n). For 100,000 numbers, 100,000 comparisons.

Same problem, same answer, dramatically different cost. That’s what DSA gives you — the vocabulary and the reflexes to find the second solution before you write the first.

Practice problems

Try these warm-ups before moving on to the next post. Don’t worry about optimality yet — just get a working answer.

  1. Write a function that returns the largest number in a list. What’s its time complexity?
  2. Write a function that returns the second-largest number in a list, using only one pass.
  3. Given a list and a target, return the index of the target if present, else -1.
  4. Given two lists, return a new list containing only the values that appear in both. (Hint: a set helps.)
  5. Given a list of words, return the word that appears most often. Ties can be broken arbitrarily.
  6. Given a list of integers and a window size k, return the maximum sum of any k consecutive elements.
  7. Given a list, return True if it’s sorted in non-decreasing order, else False. Solve it in one pass.

For each one, write down its time complexity in Big-O notation before moving on.

Recap

You now know:

  • DSA stands for data structures (how data is organised) and algorithms (the steps to solve a problem)
  • It matters both for interviews and for real, practical performance
  • Data structures are nouns; algorithms are verbs; most problems need both
  • A clear roadmap exists — foundations first, then linear structures, then hashes, then trees and graphs
  • The practice loop that sticks: attempt, read, re-solve from scratch, note, revisit

Next steps

The first vocabulary you need is Big-O notation — the language for talking about how expensive an algorithm is. Without it, everything else in DSA is a guess.

→ Next: Big-O Notation Explained

Questions or feedback? Email codeloomdevv@gmail.com.