I Thought I Was Building a Weather App. Then an AI Interview Changed the Way I Saw It.
What started as a simple weather monitoring project became a lesson in cloud architecture. An AI interview pushed me to look beyond AWS services and start thinking about events, failures, scalability, and the decisions behind the architecture.
A few days ago, I walked into an AI interview thinking I was prepared.
I had been learning cloud computing, experimenting with AWS, and building a small serverless weather monitoring application. I could explain what Lambda was. I knew what EventBridge did. I knew how an API works.
But during the interview, I realized something important:
Knowing what a cloud service does is very different from knowing why you would use it.
That realization completely changed the way I looked at the project I was building.
It started as a simple weather application
The idea was straightforward.
I wanted to build a small application that could periodically retrieve weather information from the OpenWeatherMap API, process it, store relevant data, and eventually notify users when certain conditions were met.
My initial architecture looked something like this:
Amazon EventBridge → AWS Lambda → OpenWeatherMap API → Amazon DynamoDB → Amazon SNS
At first, this seemed like a collection of AWS services connected together.
But I slowly started asking a different question:
Why does each service exist in this architecture?
That question turned out to be much more valuable than memorizing the services themselves.
Why serverless?
I didn't want to begin by creating a server, configuring it, worrying about operating systems, or keeping infrastructure running when there was no work to do.
The application didn't need a server running continuously.
It needed computation only when a weather check was triggered.
That made AWS Lambda a natural fit.
With Lambda, I could focus on the actual logic:
- Receive the trigger
- Call the weather API
- Process the response
- Store the required information
- Trigger a notification when necessary
The infrastructure was no longer the primary concern.
The code became the unit of computation.
Then came EventBridge
But Lambda raises another question:
Who invokes the Lambda function?
This is where Amazon EventBridge comes in.
Instead of manually calling the function, I could create a scheduled event that triggers Lambda at a defined interval.
Conceptually:
"Every X minutes, check the weather."
This was one of the first moments where I understood the difference between simply using AWS services and actually designing a cloud system.
The services weren't isolated features.
They were solving different responsibilities.
EventBridge handled scheduling.
Lambda handled computation.
Lambda handled computation.
But external APIs fail
This is where the project became more interesting.
What happens if the weather API is unavailable?
What if the request times out?
What if the API returns an error?
What if I keep requesting the same weather information unnecessarily?
These questions weren't part of my original "simple weather application."
But they are part of building something that can actually be trusted.
That led me to think about caching and persistence.
DynamoDB: more than just "a database"
I initially thought:
"I need a database, so I'll use DynamoDB."
But that's not really a design decision.
The better question is:
What information do I actually need to store, and why?
For this application, DynamoDB could store weather observations, timestamps, locations, or cached responses.
Caching can also reduce unnecessary calls to an external API.
That means DynamoDB isn't simply a place to put data.
It can become part of the system's strategy for:
- reducing external API calls
- retaining historical observations
- handling repeated requests
- improving resilience
That distinction was important for me.
And then there is SNS
Suppose the application detects a condition such as extreme temperature or heavy rainfall.
The system shouldn't necessarily stop everything and wait for someone to manually check the result.
It can publish a notification through Amazon SNS.
So the architecture becomes more event-driven:
EventBridge triggers the computation.
Lambda performs the work.
DynamoDB stores the information.
SNS communicates an important event.
Each component has a responsibility.
And that is when the architecture started making sense to me.
The interview changed the questions I was asking
The biggest takeaway from the AI interview wasn't a particular question or a particular technology.
It was the realization that I had been approaching projects from the perspective of:
"How do I make this work?"
But real engineering often starts asking:
"How should this behave when things don't work?"
That difference is huge.
A working application is only the beginning.
A better system also considers:
- What happens when an API fails?
- How do we handle retries?
- How do we prevent duplicate processing?
- Where should data be stored?
- Can we reduce unnecessary API calls?
- How do we monitor failures?
- What happens when traffic increases?
- How much does each component cost?
- How do we secure credentials and permissions?
Suddenly, my small weather application didn't feel so small.
It had become a playground for understanding distributed systems.
From services to architecture
Before working on this project, I often learned AWS services individually.
Lambda.
DynamoDB.
SNS.
EventBridge.
Each one seemed like another topic to learn.
Now I'm beginning to see them differently.
Cloud engineering isn't about collecting the largest number of AWS services you can name.
It's about understanding responsibilities, trade-offs, communication, failure, and scale.
For example, I don't use Lambda because "Lambda is an AWS service."
I use it when I want event-driven computation without managing servers.
I don't use DynamoDB simply because "DynamoDB is NoSQL."
I use it when its access patterns, scalability, and operational model fit my application's needs.
And I don't use EventBridge just because I learned about EventBridge.
I use it when events and scheduling need to be decoupled from the computation itself.
That shift in thinking is probably the most valuable thing this project has given me.
What I would improve next
The current application is still a learning project.
And that's exactly why I like it.
There are several things I want to explore next:
- Better error handling and retries
- API response caching
- IAM least-privilege permissions
- CloudWatch monitoring and logging
- Handling duplicate events
- Dead-letter queues for failed processing
- Cost optimization
- Infrastructure as Code
- Better observability
- More meaningful weather-based alerts
Each improvement represents another cloud engineering concept I can learn by actually building.
The bigger lesson
I'm learning that cloud computing isn't really about putting an application "on the cloud."
It's about changing the way we think about applications.
A small weather-monitoring system can teach you about:
events, APIs, distributed systems, databases, failure handling, asynchronous communication, monitoring, security, scalability, and cost.
And sometimes, an interview can expose gaps in your understanding that tutorials don't.
That happened to me.
I entered the interview thinking about whether I could explain the technologies I had used.
I came out thinking about whether I truly understood the decisions behind them.
That changed how I approached my project.
And perhaps that's one of the most valuable parts of learning technology:
You don't always learn the most when you successfully build something.
Sometimes, you learn the most when someone asks you why you built it that way.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article