Things I Learned Getting the Google Professional Machine Learning Engineer Certification

I recently passed the Google Professional Machine Learning Engineer certification. I've worked in data science for most of my career, so a lot of the underlying concepts weren't necessarily new to me. What was more interesting was seeing how those concepts change when you move from building models to building machine learning systems. The certification spends a lot of time on questions where there isn't a universally "best" technical solution. Instead, you have to understand the business objective, recognize the constraints you're working within, and choose the architecture that makes the most sense for that particular situation.

That distinction left me with three broader takeaways—not just about Google Cloud, but about how I think about machine learning and AI more generally.

1. Data science is about business impact. Machine learning is about business impact and tradeoffs.

As a data scientist, I've always thought about my work in terms of business impact. The purpose of an analysis isn't simply to discover something interesting; it's to help someone make a better decision. The purpose of a predictive model isn't necessarily to maximize some abstract accuracy metric; it's to improve an outcome that matters to the business. I've generally evaluated good data science by asking whether the work helps a company increase revenue, reduce costs, improve a product, understand its customers, or make decisions with greater confidence.

Machine learning engineering adds another dimension to that thinking. You still need to create business impact, but you need to create that impact within a set of technical constraints. And many of those constraints ultimately become tradeoffs between speed, size, and cost.

Take model training as a simple example. If training a model takes too long, one solution is to add more compute. You can use more powerful machines, add workers, parallelize parts of the process, or use specialized hardware. The process gets faster—but generally becomes more expensive. That might be an easy decision if a model needs to be retrained several times per day and its outputs directly affect the customer experience. It might be a terrible decision if the model only needs to be refreshed once a month. In the latter case, who really cares whether training takes 30 minutes or three hours?

The same relationship exists between scale and speed. Processing significantly more data while maintaining the same latency usually requires more resources. Alternatively, we can batch the work. Rather than processing each event immediately, maybe we process everything once an hour or once a day. That can make the system considerably cheaper and easier to operate, but we've now traded freshness for efficiency.

There's no universally correct answer to these problems because the right answer depends on the business. A fraud model determining whether to approve a credit-card transaction might need to return a result in milliseconds. A churn model that produces a list for the marketing team every Monday morning doesn't. Building both systems to the same latency requirements would be absurd.

Data scientists certainly make tradeoffs as well—accuracy versus interpretability is an obvious example—but I found these infrastructure tradeoffs much more central to the engineering side of machine learning. The question shifts from "What's the best model?" to something closer to "What's the best system we can build given the level of accuracy, latency, scale, reliability, and cost that the business actually requires?"

That's an important distinction because the most sophisticated solution isn't always the best one. Imagine that one model improves accuracy by half a percentage point but costs ten times as much to train and serve. Is it better? Technically, maybe. From a business perspective, only if that incremental accuracy is worth more than the incremental cost.

Machine learning engineering is therefore as much about optimization under constraints as it is about machine learning. The goal isn't to maximize every dimension of the system. It's to understand which dimensions matter enough to optimize.

2. Leverage Google's out-of-the-box services before building everything yourself.

One thing that became particularly clear while working through Google's ecosystem is just how much machine learning infrastructure is now available out of the box. Tools such as AutoML, Model Garden, Agent Studio, and the broader Agent Platform allow practitioners to test ideas at a much higher level of abstraction than was possible even a few years ago.

I think that's particularly important because technical teams have a tendency to start building too early.

Someone proposes an AI use case and we immediately start thinking about architecture. What model should we use? Do we need a vector database? Should we fine-tune the model? How should we deploy it? What's the orchestration layer? How do we build the API?

Those may eventually be important questions, but there's a more fundamental question that should come first:

Does this idea actually create enough value to justify everything we're about to build?

The proliferation of managed ML and AI services gives us an opportunity to answer that question much earlier. If I can use an existing model, a managed interface, or a relatively low-code tool to build 70 or 80 percent of an idea in a few days, I can start testing the business hypothesis before investing heavily in the infrastructure.

This is one of the reasons I increasingly separate prototyping from production engineering in my head.

During prototyping, I want to remove as much unnecessary engineering as possible. I want to determine whether the model solves the problem, whether people actually use it, whether its outputs are valuable, and where it fails. At that stage, I don't necessarily need the perfect architecture. I need enough of the product to learn something.

Once the use case has been validated, the equation changes. Maybe AutoML isn't flexible enough. Maybe the foundation model we're using is too expensive at scale. Maybe we need a custom model because the additional accuracy materially affects the economics of the product. Maybe latency requirements force us to rethink inference. Maybe governance, observability, security, or reliability becomes significantly more important once the prototype starts interacting with real customers.

At that point, we can move deeper into the stack.

This is where I think Google's approach is particularly useful conceptually. You can start relatively high in the stack and progressively introduce complexity as the application earns it. The prototype might begin with an existing model and a managed interface. The mature system might eventually involve custom training, pipelines, orchestration, monitoring, dedicated endpoints, and its own application infrastructure.

But you don't necessarily need to start there.

I've spent a lot of my career thinking about analytics in a similar way. If someone asks a new business question, I generally don't start by building a dashboard. I answer the question first. If people keep asking the same question, maybe I standardize the analysis. If the analysis becomes something the organization needs continuously, then I automate it.

Machine learning systems should often follow the same progression: first prove that something is useful, then make it scalable.

The availability of increasingly powerful managed services makes that approach easier than ever.

3. Don't just "throw AI at it."

Every few years, technology develops a new shiny object.

Ten years ago, companies wanted data science teams.

Five years ago, everyone wanted deep learning and neural networks.

Today, everyone wants AI, LLMs, and agents.

New technologies obviously create new possibilities. But one thing the certification reinforced for me is that we shouldn't confuse newer with better for every problem. In fact, some of the most interesting applications of modern machine learning rely heavily on ideas that have existed for decades.

Model explainability is a good example. We can build extraordinarily complex predictive models, but we still need people to understand what those models are doing. Techniques such as LIME, TCAV, and surrogate models attempt to bridge that gap. And what's interesting is that explaining sophisticated models often involves returning to much simpler concepts. A surrogate model, for example, can use a relatively interpretable model to approximate the behavior of a much more complicated one.

We build complexity, and then sometimes use simplicity to understand it.

I see the same pattern emerging with generative AI.

One of the most compelling enterprise applications for LLMs is the ability to ask questions about business data using natural language. Instead of navigating dashboards or writing SQL, someone can theoretically ask, "Why did revenue decline in the Northeast last month?" and receive an intelligent answer.

The LLM is the exciting part of that system.

But consider everything that needs to exist underneath it for the answer to actually be trustworthy.

What exactly does the company mean by "revenue"? Is it gross or net? Does it include refunds? When is revenue recognized? What constitutes the Northeast? Which table contains the canonical customer record? How is a customer defined? Which date should be used when grouping transactions? Are these definitions documented anywhere?

These aren't new AI problems. They're old business intelligence and analytics problems.

I've spent years advocating for things such as metric definitions, semantic consistency, documented columns, centralized business logic, and reliable data models. None of that becomes obsolete because we can now put an LLM on top of the data warehouse. If anything, it becomes more important.

An LLM can't resolve a business definition that the business itself hasn't resolved.

If marketing considers an "active customer" someone who purchased within 30 days while finance uses a 90-day definition, adding an AI interface doesn't eliminate the disagreement. It simply gives us a much more sophisticated way to surface inconsistent answers.

This is why I think some of the most valuable AI systems will come from combining the "old stuff" with the new stuff.

Use traditional forecasting when forecasting is the right tool. Use regression when regression is the right tool. Use business rules when a deterministic rule makes more sense than a probabilistic model. Use an LLM when language, reasoning, or unstructured information is the problem. And combine them when the combination creates something more useful than either approach alone.

A forecasting model might generate the prediction while an LLM explains it. A traditional classification model might identify high-risk customers while an agent determines what action to take. A semantic layer originally designed for dashboards might become the foundation for an AI analytics assistant. A simple model might help us understand why a complex model is behaving the way it is.

The point isn't to avoid the newest technology. It's to stop treating technological progress as if every new tool invalidates everything that came before it.

What I took away from the certification

I started the Google Professional Machine Learning Engineer certification expecting to learn more about Google's machine learning stack. I did. But the more useful outcome was probably a shift in how I think about building these systems.

First, good machine learning engineering isn't simply about maximizing model performance. It's about creating business value while navigating tradeoffs between accuracy, speed, scale, reliability, and cost.

Second, we don't need to build everything ourselves. The growing number of managed tools means we can prototype increasingly sophisticated ideas quickly, validate whether they create value, and only introduce deeper engineering complexity when the use case demands it.

And third, AI shouldn't become the solution to every analytical problem simply because it's the newest capability available to us. Many of the strongest systems will combine decades-old analytical practices with the newest models and interfaces.

There's a tendency in technology to equate sophistication with progress.

After completing the certification, I think I believe the opposite a little more strongly.

The goal isn't to build the most sophisticated system we can. It's to build the simplest system that reliably creates the business outcome we need.