Why Data Structures and Algorithms Matter in Real Apps

What are data structures and algorithms?

A data structure is a way of organising data in memory so it is easy to use, and an algorithm is a step-by-step method for doing something with that data. Together they decide how fast, how memory-hungry and how reliable your code is.

Think of a data structure as a filing system and an algorithm as the procedure for finding or sorting the files. A pile of papers on a desk (an array) is fine for ten pages. For ten thousand, you want labelled folders (a hash map) or an index (a tree). The pages are the same; the organisation changes everything.

The common structures you will meet are arrays and lists, hash maps and sets, stacks and queues, linked lists, trees and graphs. The common algorithms are searching, sorting, recursion, and traversals of trees and graphs. That is most of the toolbox, and the rest of this article shows where each piece appears in apps you might actually build.

Why do data structures and algorithms matter in real software?

They matter because real apps handle growing data on limited hardware, and the wrong choice shows up as lag, crashes, battery drain and cloud bills. Most DSA problems in production are not clever puzzles; they are ordinary features written with an ordinary mistake.

Here is where they appear in everyday mobile and backend work.

Lists versus hash maps for lookups

Suppose you show a list of M-Pesa transactions and each one needs its contact name from a phone book of 2,000 contacts. If you search the contact list for every transaction, you do thousands of comparisons per row. Build a map once and each lookup is almost instant.

// Slow: scans the whole list for every transaction
val name = contacts.firstOrNull { it.phone == tx.phone }?.name

// Fast: build once, look up in roughly constant time
val byPhone = contacts.associateBy { it.phone }
val name = byPhone[tx.phone]?.name

Search and autocomplete

Searching a sorted list with binary search takes about log n steps, so a million items need around twenty comparisons instead of a million. Autocomplete often uses a trie or a sorted index so that typing “nai” narrows results without rescanning everything.

Offline sync queues

Connectivity in many Kenyan areas is patchy, so good apps save actions locally and send them later. That is a queue: first in, first out, so a user’s edits reach the server in the order they were made. Add retries and de-duplication with a set of request IDs, and you have used three structures in one feature.

Caching with an LRU

Memory on a budget Android phone is small, so you cannot keep every image or response. A least-recently-used (LRU) cache keeps the most recent items and evicts the oldest. It combines a hash map for fast lookup with a linked list for ordering. Android even ships an LruCache class for this, documented at developer.android.com.

Graphs, sorting and pagination

Maps and delivery apps model roads as graphs and use shortest-path algorithms for routes. Recommendations (“people you may know”) are graph problems too. Sorting and pagination appear in nearly every feed: sort in the database where possible, fetch pages instead of everything, and avoid re-sorting a large list on every screen rebuild.

Performance on low-end Android phones

The Android market in Kenya leans heavily towards affordable devices with modest CPUs and RAM. An O(n²) loop that runs unnoticed on your flagship test phone can drop frames on a budget one. Understanding cost is how you build apps that feel fast for everyone, not just for the developer.

What is Big-O notation in simple terms?

Big-O notation describes how the work an algorithm does grows as the input grows. It ignores small constants and machine speed and focuses on the shape of the growth, which is what breaks apps at scale.

If your list has n items, O(n) means the work grows in line with n, while O(n²) means doubling the data roughly quadruples the work. You do not need the maths; you need to recognise the shapes.

The last row is the one to remember. A nested loop over a million items is a trillion operations, far beyond what a phone can finish in a reasonable time.

Common operations by structure

Do I still need DSA if AI writes code?

Yes. AI tools can generate working code in seconds, but “working” on three test items is not the same as working on 300,000 real ones. DSA is how you tell the difference.

Increasingly, a developer’s job is to direct, review and correct generated code. That review depends on fundamentals. Three skills in particular become more valuable:

• Judging output. You can read a suggestion and ask whether it scales, rather than trusting that it compiles.
• Spotting hidden O(n²). A contains call inside a loop, or a list search inside a map, looks innocent but multiplies work. Here is a typical example:

// Looks tidy, but contains() on a List is O(n),
// so the whole thing is O(n * m)
val missing = orders.filter { it.id !in paidIds }   // paidIds is a List

// Fix: make paidIds a Set, and the filter becomes about O(n)
val paid = paidIds.toSet()
val missing = orders.filter { it.id !in paid }

• Choosing structures and debugging. When you prompt an assistant well, you name the structure you want. When something is slow, you can locate the bottleneck instead of asking the AI to guess.

At Bridgetree we teach AI-assisted development with tools like Claude, Copilot and Cursor, but we pair it with weekly problem sets because the tools are only as good as the person checking their work. For more on this shift, read AI agents in software development.

What is a good DSA roadmap for beginners?

Learn the small set of topics that cover most real work first, and delay the rest. A sensible order moves from simple, everyday structures to the ones that need more abstract thinking.

Learn these first, in order

1. Big-O basics. Learn to name O(1), O(n), O(n log n) and O(n²) and to estimate your own loops.
2. Arrays and strings. Iteration, two pointers and sliding windows solve a surprising number of problems.
3. Hash maps and sets. The highest-value topic for app developers: counting, grouping, de-duplicating and lookups.
4. Sorting and binary search. Know what built-in sorts cost and when binary search applies.
5. Stacks and queues. Back navigation, undo, parsing, task and sync queues.
6. Linked lists and recursion. Mostly for understanding pointers and call stacks, and a classic interview staple.
7. Trees and graphs. Breadth-first and depth-first search, which cover UI hierarchies, file systems and routes.
8. Basic dynamic programming. Only after everything above feels comfortable.

Safe to skip as a beginner

Red-black and AVL tree rotations, segment trees, advanced graph algorithms such as max-flow, and competitive-programming tricks. You can learn them later if a job or interest demands it. Building a few small apps alongside your study matters more than polishing rarely used theory; our guide on what to learn as a software developer in 2026 shows where DSA fits in the bigger picture.

How do I practise DSA effectively?

Practise little and often, in the language you build with, and explain your thinking out loud. Steady weekly practice beats a frantic month before an interview.

1. Pick a weekly topic. For example, hash maps this week, binary search next week.
2. Solve three to five problems of rising difficulty on that topic, writing the solution in Kotlin or Swift rather than whichever language the site defaults to.
3. Write the Big-O of your solution in a comment before you check anyone else’s.
4. Explain it aloud as if teaching a friend. If you cannot explain why it works, you do not own it yet.
5. Revisit with spaced repetition. Re-solve problems from scratch after one day, one week and one month. Forgetting and re-learning is what makes the pattern stick.
6. Apply it. Find one place in your own app where the topic helps, such as replacing a list search with a map.

Both Kotlin and Swift have rich standard-library collections, so you can practise on real tools. The official references at kotlinlang.org and swift.org are good places to look up how HashMap, Set, ArrayDeque and Dictionary behave. In our programmes, weekly DSA problem sets in Kotlin and Swift are built into the live tracks, so practice is part of the schedule rather than something to find time for.

Does DSA matter in job interviews?

Yes, for many employers it does, though not equally everywhere. Remote and international companies, banks and large tech firms often include at least one DSA-style round, while some local and startup roles focus more on practical app work.

Interviewers use these questions to see how you reason, break down a problem and communicate trade-offs, not just whether you memorised an answer. If you build the habits described above, interview preparation becomes a short polish rather than a panic. For round formats, what to expect and how to prepare, read our software developer interview guide.

As a rule from reviewing junior candidates: clear thinking and honest Big-O reasoning beat a half-remembered clever trick every time. Say what you would try, what it costs, and how you would improve it.

How can I start this week?

Pick one small, concrete step and do it this week. Momentum matters more than a perfect plan.

• Open a project you already have and find one list search inside a loop. Replace it with a map or set.
• Write the Big-O of three functions you wrote recently, as comments.
• Solve one hash-map problem in Kotlin or Swift and explain it aloud.
• Schedule 30 minutes, three times a week, for practice, and keep to it for a month.

If you would rather learn with structure, mentors and feedback, the Foundation and Professional tracks include DSA practice alongside real app building. Either way, the goal is the same: write code that stays fast when real users and real data arrive.

Frequently asked questions

Kevin Lagat

Founder and lead instructor at Bridgetree Learn. Former Senior iOS Engineer at Safaricom, where he worked on the M-PESA app. He has shipped production apps for the UK's NHS, a Saudi digital bank and US SaaS companies, and trained Saudi Digital Academy cohorts through Coding Dojo. LinkedIn · GitHub