Building Smarter Systems with Algorithms and Agents: A Conversation with Imran Ahmad

A machine learning educator and experienced public-sector data scientist breaks down algorithmic thinking, GenAI systems, and the shift from models to agents in real-world software engineering

From scaling fraud detection systems to embedding AI agents in robotics, algorithmic thinking is more central to software engineering than ever before. In this conversation, we speak with Imran Ahmad—author of 50 Algorithms Every Programmer Should Know—about how the definition of “core algorithms” is evolving in the AI era, what classical techniques still offer in modern architectures, and why practical experimentation, not memorization, is key to mastering real-world problem solving.

Imran is a data scientist at the Advanced Analytics Solution Center (A2SC) within the Canadian Federal Government, where he builds machine learning solutions for high-stakes use cases in public services. He is also a visiting professor at Carleton University, an authorized instructor for Google and AWS, and an experienced educator whose story-driven teaching style has resonated with thousands of learners. His 2023 book, 50 Algorithms Every Programmer Should Know, spans foundational computer science through to advanced AI systems. He is now working on his next title, 30 Agents Every AI Engineer Should Know, which explores how autonomous agents can orchestrate tools, models, and data sources to solve complex problems in the real world.

You can watch the full interview below—or read on for the complete transcript.

---

1. The first edition of your book 40 Algorithms Every Programmer Should Know came out in 2020. The second edition, published in 2023, expanded to include 50 algorithms. What changed in the industry—or in your own perspective—that led to this evolution?

Imran Ahmad:
So, first of all, 40 Algorithms Every Programmer Should Know was essentially a narration of the world around me—the problems I was trying to solve. These books are story-driven. Each chapter presents a problem, and algorithms are the tools I use to solve them. They’re very powerful tools.

When I wrote the first book in 2020, it was the early days of COVID—a difficult year. Since we were stuck at home, I thought it would be a good time to reflect on and write about the problems I had solved over the last 20 years. That’s what the first book was about.

Now, to your question—why was there a need to write the second edition? From 2020 to 2023, we saw the rise of generative AI, attention mechanisms, Transformers, autoencoders, and the increased importance of sequential data. The boom in GenAI and the surrounding ecosystem really shifted things.

Back in 2020, GenAI existed but it wasn’t everything. Today, if you ask a college student or even someone outside of data science, like a government employee, “What is AI?”, the answer is often “ChatGPT” or “GenAI.” That’s how dominant it has become.

So, the 10 additional algorithms in the second edition are focused on sequential data—things like RNNs, LSTMs, GRUs—all of which lead up to attention mechanisms. They lay the foundation for working in this new AI-driven world.

2. You also had a Discord community around the book. Did feedback from that community influence the updates in the second edition?

Imran Ahmad:
Yes, definitely. When you write a book, you have to think carefully about your target audience. As an author, you want to go broad—but not too broad. There's always a balance between depth and breadth.

Some books cover a lot of topics but don’t go deep. Others focus intensely on a single topic. With 50 Algorithms, I had to strike that balance. Covering 50 algorithms in a single book means I couldn’t go in-depth on all of them. So I had to choose which ones deserved a deeper dive—based on what I felt was needed and relevant.

Now, coming to your question: in the Discord community, most readers liked that approach. Of course, you can't please everyone—some wanted different algorithms covered in more depth. A lot of the feedback was, “Why not have a separate book just on the 10 new algorithms from the second edition?” Because GenAI, Transformers, LSTMs, autoencoders, and attention mechanisms have become so important.

And that's exactly why I’m writing another book that goes deeper into the GenAI world. But overall, most readers found the book useful across a wide variety of scenarios and use cases.

3. Let us talk about you upcoming book—30 Agents Every AI Engineer Should Know. What are the new challenges in AI engineering that you're aiming to address with this book?

Imran Ahmad:
We have a lot of hope around AI—that it can eventually replace a human. But if you think about how a person in a company solves a problem, they rely on a set of tools. Depending on the problem, they might first do a web search, then read a book, email someone, call a friend, or go to the library. After gathering information, they create a solution.

An “agent” is meant to replace that kind of human reasoning. It should be able to discover the tools in the environment around it, and have the wisdom to orchestrate a solution tailored to the problem. We're not there yet, but that's what we're striving for. The 30 agents I will cover in my next book represent the next step—the next generation of the algorithmic world we live in.

4. How would you define the term “agent” in the context of your upcoming book?

Imran Ahmad:
An agent is an entity that has the wisdom to work independently and autonomously. It can explore its environment, discover available tools, select the right ones, and create a workflow to solve a specific problem. That’s the dream agent.

Now, most agents we use today have only part of that capability. But we’re striving for agents that mimic how a person like me—a data scientist—would work when given a problem. The agent should understand the ecosystem, be aware of each tool’s strengths and weaknesses, and know when and how to use them in combination.

It might use web search, a calculus engine, an academic paper locked behind a university firewall, and a large language model—all as part of its toolkit. And that’s an important point: a large language model is not the only tool. It’s perhaps the most important one right now, but real wisdom lies outside the LLM—in the agent.

5. How do you see the definition of core algorithms evolving in today’s software landscape? Are there any areas you think will become essential knowledge in the next few years?

Imran Ahmad:
Yeah, so when we talk about algorithms, you can look at them from two perspectives: the practitioner’s and the researcher’s.

The first thing is to identify your role. If you’re a researcher, you’ll be concerned with things like partial differential equations, optimization techniques, proofs of optimality, NP-hardness, and so on.

But as a practitioner, you don’t want to dive into unnecessary details. I often use the analogy of a car. Do you want to build a car and understand every component of the engine? Or do you just want to drive it? If you want to drive it, you need to know the essentials—how to maintain it—but not necessarily every internal detail. That’s the practitioner role.

This book is written for practitioners. It does go into some depth where needed, especially to help practitioners understand where a solution is coming from. That deeper understanding helps you choose the right algorithm for the problem you’re trying to solve.

If you know a bit more about how the engine works, you can choose the right car for your needs. Similarly, with algorithms, even a minimal understanding of how they work under the hood can help you make better decisions.

6. From your own work, can you share an example where selecting or optimizing an algorithm made a measurable difference to a system’s scalability or resilience?

Imran Ahmad:
Yes, I can give many examples.

When algorithms are taught in universities or academic environments, they’re usually applied to small, curated datasets. I call this “manicured pedicure data.” But that’s not real data.

The problem is that people take online or graduate-level courses and learn algorithms in isolation. They never see the kind of messy, large-scale data we deal with in the real world. In my work, I often deal with datasets containing 2 million, 5 million, even 10 million rows. If you’re applying a graph algorithm on that scale, you need something that performs.

For example, in my first book, 40 Algorithms Every Programmer Should Know, I included the Apriori algorithm. It’s well-known for association analysis—discovering causal relationships between features in unsupervised learning scenarios, like weather data or market baskets.

But when I used Apriori in practice, I found it doesn’t scale. It generates thousands of rules and then filters them after the fact. There’s a newer, better algorithm called FP-Growth that does the filtering at the source. It only generates the rules you actually need, making it far more scalable.

That’s why in the second edition—50 Algorithms—I replaced Apriori with FP-Growth.

This ties back to the idea that in real-world applications, non-functional requirements become important—performance, security, availability. In academia, we focus on functional requirements—like "this algorithm should detect fraud." And yes, the algorithm might technically work. But in practice, you also have to consider how it performs, how scalable it is, whether it can run as a cloud service, and so on.

Sometimes you need to run the algorithm in a distributed fashion, apply divide-and-conquer techniques, and optimize how you prepare and process data. That’s what makes the solution scalable and production-ready.

7. When it comes to performance tuning or system scaling, do you often find yourself revisiting core algorithms? Or are these optimizations typically more architectural?

Imran Ahmad:
Both. Not all algorithms have tuning parameters, but many do.

Take machine learning or deep learning algorithms, for example—your batch size, number of epochs, learning rate, and optimizer choice are all hyperparameters. These are crucial for determining whether your solution will scale.

With other algorithms—like FP-Growth, which I mentioned earlier—there are fewer tuning knobs. You can still adjust things like lift, confidence, and support thresholds, but the algorithm is largely driven by its internal design.

In cases like that, the optimization often shifts to the infrastructure—finding a more performant backend to run the algorithm on. And cloud computing is perfect for this. We’re lucky to be in the cloud era; it’s a catalyst for building large-scale systems that simply weren’t feasible 20–25 years ago.

What we aim for are elastic architectures—systems that can expand and shrink based on the demands of the algorithm. This not only improves performance but also keeps costs down.

8. Have you ever encountered a situation where choosing the wrong algorithm led to long-term issues?

Imran Ahmad:
Yes. Especially in predictive analytics.

Take something like approving or refusing a mortgage application at a bank. You could start with simple intuition-based rules. Then maybe you move to a decision tree, which gives you more structure and explainability. Decision trees are often used in sectors like finance, government, and healthcare because they’re white-box models—transparent and interpretable.

But decision trees can overfit. They also don’t perform well when there’s a high correlation between features. In such cases, you need to move to more advanced algorithms. If you don’t want to go all the way to deep learning, you can use something like SVM or XGBoost. These models overcome some of the limitations of simpler ones.

This whole process is iterative. You start with a simple model, test it, and gradually move toward more complex ones. It’s usually a mistake to begin with something too complex—it can be overkill, like using a forklift to lift a sheet of paper.

9. How do you advise engineers to integrate algorithmic thinking into architecture-level decisions, especially when working with distributed systems or cloud platforms?

Imran Ahmad:
Let’s start with machine learning, since that’s where this comes up often.

ML algorithms have very different requirements during training, testing, and production. During training, you need a lot of data to establish meaningful causal relationships between features and labels. That, in turn, requires a lot of processing power—GPUs, ideally. It’s expensive and time-consuming.

This is where cloud computing really shines. The cloud gives you elastic architectures—you can spin up 2,000 nodes for 2 or 10 hours, train your model, and then shut it down. The cost is manageable, and so is the time, because of that elasticity. You might pay $100–200 for that burst of power, and you're done.

Once the model is trained and tested, the final model file is often very small. I joke that it’s like the tail of an elephant—tiny compared to the size of the data and effort used to build it. You can even deploy it on your phone.

So, the hardware and architecture needs vary drastically across different stages. If you want to optimize for cost and performance, you need elastic systems. Cloud computing—whether AWS, Google Cloud, or Azure—offers exactly that. It doesn’t matter which provider you choose, but definitely use the cloud.

10. Are there any patterns or heuristics you use to identify when algorithm choice should drive architectural decisions?

Imran Ahmad:
Yes—it depends on the complexity of the problem you’re solving.

If you’re working on something simple, then a straightforward design and algorithm are usually enough. Overdesign is a common issue—we sometimes overthink things unnecessarily.

First, ask yourself: does this problem justify the additional complexity that a particular algorithm might bring into your architecture? Then evaluate that decision along three axes: cost, performance, and time.

Whatever you implement will likely increase your hardware requirements and, therefore, your cost. So, can you justify that increase? Are you gaining significant improvements in accuracy? Are you saving time?

If an algorithm is more accurate, more time-efficient, and the cost increase is justified, then it’s probably the right choice. That’s the kind of trade-off analysis I recommend for selecting algorithms at the architecture level.

11. Classical algorithms like graph search or dynamic programming often underpin modern AI systems. Could you share an example where these “old” techniques support cutting-edge AI today?

Imran Ahmad:
Absolutely. I see them as complementary—not rivals.

Take search algorithms, for instance. When you're preparing datasets for AI, especially in enterprise environments, you often have massive data lakes—structured and unstructured data all in one place. Now, say you're training a model for fraud detection. You need to figure out which data is relevant from that massive repository.

Search algorithms can help you locate the relevant features and datasets. They support the AI workflow by enabling smarter data preparation.

Classical algorithms also play a role in things like link analysis, establishing causal relationships, and assessing data quality. Even classical NLP techniques are still useful.

I think of it like training at the gym. Maybe AI is your “main muscle,” but to build a strong body—or in this case, a performant system—you need to train the supporting muscles too. Classical algorithms are part of that foundation.

12. Could you give us an example of a specific hybrid approach—where classical algorithms support AI systems in production?

Imran Ahmad:
Sure. One example is the Apriori algorithm and its more scalable successor, FP-Growth. These are classical algorithms used for association analysis. In my opinion, association analysis is one of the most powerful and underutilized techniques.

Let me walk you through an example. A couple of hours ago, I went to a corner shop to buy milk. Now, imagine we had 30 days of transaction data from that shop—say 10,000 transactions. Each row in that dataset would list the items purchased in a single sale.

If you feed that data into FP-Growth, it will find relationships—like if someone buys milk, they’re likely to buy cheese too. Or if someone buys a shaving razor, they also buy shaving gel. These are the kinds of patterns the algorithm surfaces.

Now, where does AI come in? Well, in real-world data, labels aren’t always clearly defined like they are in academic “toy” datasets. You often have to derive labels from combinations of features. Algorithms like FP-Growth help you discover those relationships. They can even help you decide which features to treat as labels or predictors.

So here, a classical algorithm is directly informing the data preparation and feature engineering stages of your AI pipeline. It’s a great example of how classical and modern techniques work hand-in-hand.

13. Optimization is key in both classical algorithms and AI models. What are some common mistakes you've seen engineers make when trying to optimize systems that combine both worlds?

Imran Ahmad:
Optimization is absolutely critical. Let’s talk about how important it is.

Math can be cruel. If you're not careful, your problem might never converge—not in hours, not in days. If you accidentally introduce an exponential factor in the wrong place, it might take years—or even centuries—for the solution to converge. The sun might die before your algorithm finishes!

So no, it's not OK to say, “I’m not in a hurry, I’ll just let it run.” In algorithmic work, things can spiral out of control very quickly. That’s why optimization isn't a luxury—it’s a necessity.

You can optimize at multiple levels. First, hardware. For deep learning especially, using a GPU can speed up training by a factor of 1,000. I’ve dedicated a chapter to this in my book—why GPUs make such a huge difference.

Then there’s hyperparameter tuning. Traditionally, this took a lot of time—trial and error. But now we have tools like Vizier, developed by Google. It’s designed to find optimal hyperparameter configurations.

In historical terms, a “Vizier” was the advisor to the Sultan, helping the kingdom run better. In the same way, Vizier helps your training process by intelligently selecting hyperparameters. And what’s fascinating is that Vizier is based on classical heuristic algorithms—not deep learning.

There are two types of algorithms: those that guarantee an optimal solution, and heuristics, which give you a “good enough” solution without that guarantee. Vizier falls into the second category, and it’s very effective.

So, even in advanced AI workflows, we’re relying on classical heuristic methods to optimize performance.

14. In addition to Vizier, are there any other tools or techniques you recommend for profiling and diagnosing algorithmic bottlenecks in AI workflows?

Imran Ahmad:
Yes. You can profile and diagnose at several levels, but let’s start by clarifying what AI really is.

AI is about formulating a signal from patterns embedded in data. For example, say you have 100,000 records, and some indicate fraud while others don’t. AI is about detecting that differentiator—the signal—and using it to train a model.

But before you even get to model training, you go through the CRISP-DM lifecycle: understanding the data, preparing it, training the model, testing, and deploying. That first stage—data understanding—is crucial. This is where classical algorithms can help.

Let’s say your dataset has a lot of randomness and noise. If there's no clear signal, then even a Nobel Prize–winning scientist won’t be able to build a good model. So you need to assess your data before you commit to AI.

Classical techniques—search algorithms, dynamic programming, and others—help you profile the data. Your approach will depend on the type of data. For IoT data, you might use graph algorithms. For government or healthcare data, you'd need other tools.

The key takeaway is this: before jumping into training a machine learning model, use classical methods to ensure that your data even has a learnable pattern. Otherwise, you’re wasting time and resources.

15. Many developers learn algorithms for interviews but struggle to apply them meaningfully in real systems. How can learning approaches evolve to make algorithmic knowledge stick?

Imran Ahmad:
Learning algorithms for interviews is a good start—it shows initiative. But in interview prep, you're not solving real-world problems. You’re anticipating what might be asked, and the interviewer only has limited time, so the conversation stays at a shallow level.

That kind of surface-level knowledge is expected—and sufficient—for most programming roles. Of course, if you’re applying for a deep learning role at a company like Google Brain, they’ll expect more depth. But in general, you're not expected to know things like how to tune hyperparameters in FP-Growth for an interview.

To truly make algorithmic knowledge stick, you need to use algorithms to solve actual problems. That’s when you'll face real challenges, discover edge cases, and realize that you may need to know other algorithms just to get your main one working. You'll learn how to prepare the data, optimize your solution, and deploy it in a scalable way.

There’s an entire ecosystem—an algorithmic community—that supports every solution. And that’s why I keep saying: classical and modern algorithms aren’t separate worlds. They complement each other, and a solid understanding of both is essential.

16. Do you have any favorite practical exercises or projects that help solidify algorithmic understanding beyond textbook examples?

Imran Ahmad:
Yes. I recommend use-case-driven projects. In industry terms, we call these verticals. Concepts and algorithms are the horizontals—they span multiple use cases. Verticals are specific domains like government, healthcare, or finance.

I work in government, so I’ll use that as an example. Governments around the world are legal custodians of citizen data. That includes everything from criminal records to healthcare, immigration, and employment data. If used responsibly, this data can change lives.

Governments can identify vulnerable populations, deliver services more efficiently, and even lift people out of poverty. So if you want to work on a meaningful project, start with real government data.

One of the best sources is data.gov, which contains nearly half a million datasets from all levels of the U.S. government. You’ll find datasets on the environment, public health, traffic, flights, and more.

Similar portals exist for other countries too—Canada, Europe, India. The Indian government, for example, is making great progress toward open and accountable data access.

These are not “academic” datasets—they’re real, messy, and relevant. Choose a vertical you care about, download a dataset, pick an algorithm, and try to solve a problem. That’s the best way to solidify your learning.

---

To explore the topics covered in this conversation in greater depth—including practical guidance on applying algorithms to real-world systems, navigating the evolution from models to agents, and understanding the role of classical techniques in AI workflows—check out 50 Algorithms Every Programmer Should Know by Imran Ahmad, available from Packt. And keep an eye out for his upcoming book, 30 Agents Every AI Engineer Should Know, publishing later this year.

Here is what some readers have said: