Let me paint you a picture.

A candidate sits down for a technical interview. They're given a whiteboard - or its digital equivalent - and 45 minutes to write code from memory while a stranger watches their every keystroke. No Stack Overflow. Definitely no AI assistant.

Meanwhile, back in the real job they're interviewing for, every working engineer has a tab open with ChatGPT, Copilot, or Claude. They're generating boilerplate, asking for code reviews, debugging at the speed of conversation.

We're testing people on skills they will never use in the way we're testing them. Something has to give.

The Problem With the Whiteboard

The classic coding interview was designed to test problem-solving ability under pressure. And honestly? For its era, it made sense. When writing code meant typing everything from memory, it was a reasonable proxy for engineering skill.

But that era is over.

LLMs can produce a working quicksort, a binary search tree, a REST API boilerplate; in seconds. Any engineer who isn't using these tools daily is working slower than they need to. So when we refuse to let candidates use them in interviews, we're not testing real-world ability. We're testing a specific, increasingly irrelevant sub-skill: code recall.

Worse, we're accidentally selecting for the wrong things. The candidate who memorised algorithm patterns performs well. The candidate who is exceptional at prompt engineering, code review, architectural thinking, and knowing when the generated code is wrong - they might stumble. And those second skills? Those are exactly what matters now.

What a Better Interview Looks Like

Here's a simple shift: stop asking candidates to write code. Start asking them to work with it.

Give them a real, reasonably complex task. Let them use whatever tools they'd use on the job — including AI. Then evaluate what actually matters:

Design decisions. With AI writing the boilerplate, what choices did they make? Did they structure it sensibly? Did they handle edge cases? Did they spot where the LLM cut a corner?

Can they explain it? Sit down with the output and ask them to walk you through it. An engineer who understands what they built, even if they didn't type every line, can explain every part of it. An engineer who just vibed with the AI output will fall apart the moment you dig in.

How do they think about quality? Did they add tests? Is there any documentation, or did they assume the code speaks for itself? How do they talk about maintainability and what happens when a colleague picks this up in six months?

Debugging instincts. Break something in the code - either intentionally, or ask them to review AI-generated code with a deliberate bug - and see how they approach it. This is still a deeply human skill.

These signals tell you far more about working ability than watching someone implement a linked list from memory.

The Fear Under the Hood

I understand the resistance. The immediate concern is: "If we let candidates use AI, how do we know they can code?"

But I'd flip the question: in 2026, what does "being able to code" actually mean?

It means knowing what to build and why. It means understanding the output well enough to own it. It means catching the subtle bugs, asking the right questions, and making the call when the AI is confidently wrong. None of that is tested by a 45-minute whiteboard session.

The interview process should reflect the job. Right now, for most roles, it doesn't.

A Starting Point

You don't need to throw out your entire interview process overnight. But a few changes go a long way:

• Replace one coding round with an AI-assisted design challenge

• Add a "walk me through this code" component. Give candidates something pre-written and ask them to explain and critique it.

• Ask explicitly how they use AI in their daily workflow. Candidates who use it thoughtfully and critically are showing you something valuable.

• Evaluate documentation and communication as seriously as logic

The engineers who thrive in the next decade won't be the ones who refused to use AI tools. They'll be the ones who learned to work with them well: critically, creatively, and deliberately.

It would be nice if our interviews were designed to find those people.

What does your team's interview process look like? I'd love to hear whether others are making this shift — or still stuck in the whiteboard era.

It hit me on a Tuesday morning. I was configuring alerting thresholds for a service that handles millions of requests per day. If latency spikes above 200ms, I get a Slack notification. If error rates exceed 0.1%, my phone buzzes. If a deployment goes sideways at 3 AM, I know about it before the coffee machine does. Then I alt-tabbed to my browser and manually typed in a URL to check if Euribor had changed this month. The irony wasn't lost on me. I spend my professional life building systems that watch other systems. Observability isn't just a buzzword in my world - it's how we sleep at night. We instrument everything. We dashboard everything. We alert on everything that matters.

But my mortgage? The single largest financial commitment of my life? I was checking it like it's 2005. Manually. Sporadically. Usually when I remembered. Something felt deeply wrong about this.

Here was a number - Euribor - that directly determines how much money leaves my account every month. A number that changes. A number published by the European Central Bank on a predictable schedule. A number that is, frankly, trivial to fetch progammatically.

And I was manually refreshing a web page for it. Like some kind of caveman.

That Tuesday morning, I decided to fix this. Not because I'm obsessive about automation (okay, maybe a little), but because I realised something important: the SRE mindset isn't just for work. It's a way of thinking about any system where reliability and visibility matter.

When it comes to the roof over my head, both of those matter quite a bit.

This is the story of how I built a Prometheus exporter for Euribor rate, and what it taught me about applying SRE principles to real life.

The SRE Mindset

What SRE Actually Teaches Us

Before diving into the technical details, I want to talk about why this works. Not the code - the mindset. SRE isn't really about Kubernetes or Prometheus or whatever tool is trending this week. At its core, it's a set of principles for managing complex systems. And here's the thing: your personal life is a complex system too.

Think about it. You have inputs (salary, investments), outputs (bills, mortgage, groceries), dependencies (your job, the economy, interest rates), and failure modes (unexpected expenses, rate hikes, job loss). It's not that different from a distributed system, just with higher emotional stakes.The principles that keep production systems healthy can keep your finances healthy too.

Let me expand on the principles that mattered most for this project.

Observability: You can't fix what you can't see.

At work, we invest heavily in metrics, logs, and traces. Not because dashboards are pretty, but because you cannot respond to problems you don't know exist. The same applies to personal finance. If you don't know your current mortgage rate, how can you know if it's time to refinance? If you don't track trends, how do you spot trouble before it arrives?

Alerting: Let the system tell you when something matters.

Good alerts are specific, actionable, and timely. They wake you up for real problems, not noise. For my mortgage, I don't need to know every tiny rate fluctuation. I need to know when Euribor crosses a threshold that affects my budget. One meaningful alert beats checking manually every day.

Toil Reduction: Automate the repetitive stuff.

Toil is work that is manual, repetitive, automatable, and scales linearly with load. Checking a website for rate updates? Pure toil. It adds no value, teaches nothing new, and steals time I could spend on things that matter. Automating it away isn't laziness. It's good engineering.

SLOs: Define what "good" looks like.

Service Level Objectives force you to answer a simple question: what does success mean for this system? For my mortgage monitoring, my SLO is straightforward: I should know about any rate change within 24 hours of it being published. That's it. Clear, measurable, achievable.

Once I started seeing my mortgage through this lens, the solution became obvious. I needed metrics, a time-series database, a dashboard, and alerts.In other words, I needed the same stack I use at work.

The Problem: A Number That Controls My Money

If you have a variable-rate mortgage in Europe, your financial life is tied to a number called Euribor.

Euribor - Euro Interbank Offered Rate - is the average interest rate at which European banks lend to each other. It comes in different flavours: 1-month, 3-month, 6-month, and 12-month. Your mortgage contract specifies which one applies to you, plus a fixed margin from your bank. So if your deal is "12-month Euribor + 0.9%", and Euribor sits at 2.5%, you're paying 3.4%.

Simple enough. Except for one thing: Euribor moves.

The European Central Bank publishes new rates daily. Depending on your mortgage terms, your rate gets recalculated periodically - often every 6 or 12 months. When that recalculation happens, your monthly payment changes. Sometimes a little. Sometimes a lot.

Here's the frustrating part: nobody tells you proactively. Your bank doesn't send a friendly heads-up saying "Hey, Euribor moved, expect your payment to change next month." You find out when the new payment hits your account. Or when you happen to check. Or when someone at a dinner party mentions interest rates and you suddenly feel a knot in your stomach.

This is a terrible way to manage a major financial commitment.

Building the Solution

Once I decided to treat my mortgage like a production system, the architecture practically designed itself. I needed three things: a way to fetch the data, a way to store it, and a way to visualise and alert on it.

In other words: an exporter, Prometheus, and Grafana. The same stack I'd use at work.

Why Prometheus?

I considered simpler options. A cron job that emails me. A script that writes to a spreadsheet. But I already know Prometheus. I trust it. I've seen it handle millions of metrics without breaking a sweat. More importantly, I already have it running at home for other monitoring.

Using familiar tools isn't laziness, it's reducing cognitive load. When something matters, I don't want to learn a new system. I want to rely on something I understand deeply.

Why Go?

The exporter needed to be simple and reliable. Go gives me a single binary with no dependencies. No Python virtual environments. No Node modules.

Why these data sources?

I started with the European Central Bank's Statistical Data Warehouse - the authoritative source that every bank and financial institution uses. Clean JSON format, no authentication required. Perfect.

Except for one thing: the ECB API only updates once a month.

For historical data and official records, that's fine. But I wanted to see rate movements as they happen, not four weeks later. So I added a second source: euribor-rates.eu, which publishes daily updates.

This is a pattern straight from work: primary and fallback data sources. The ECB gives me authority. The daily feed gives me freshness. Both matter.

The Hardware

You don't need much. My entire home monitoring stack runs on a Beelink Mini-S12 - a tiny mini PC with an Intel N95 processor, 16GB of RAM, and a 500GB SSD. It sits quietly on a shelf, draws minimal power, and handles everything I throw at it.

The Platform

For orchestration, I run k3d - a lightweight Kubernetes cluster that runs inside Docker. Overkill for a single exporter? Maybe. But it means I deploy the same way I do at work: container images, manifests, declarative config. When I want to add another exporter or upgrade a version, the workflow is identical. Muscle memory matters.

And I do keep adding exporters. Euribor was just the start. Once you have the platform running, the marginal cost of monitoring one more thing is almost zero. That's the beauty of treating your home like infrastructure - it scales.

The Metrics

The exporter exposes four simple metrics:

euribor_daily_rate_percent{maturity="1W|1M|3M|6M|12M"} # The actual rate euribor_daily_last_update_timestamp # When data was last fetched euribor_daily_scrape_duration_seconds # How long the fetch took euribor_daily_scrape_success # 1 = healthy, 0 = problem

Alerting

Alerting: Your Personal PagerDuty

Metrics and dashboards are great, but let's be honest - I'm not going to check Grafana every day. The whole point of this project was to stop manually checking things. That's where alerting comes in. Let the system watch the numbers. I'll pay attention when it tells me to.

At work, I've learned that good alerting is an art. Too many alerts and you get fatigue, and start ignoring everything. Too few and you miss real problems. The goal is for alerts to be meaningful, actionable, and rare enough that you actually pay attention when they fire.

For my mortgage monitoring, I set up a tiered approach; just like we do for production systems.

Warning: "Start paying attention"

This is my early warning. At 2.4%, nothing is on fire, but it's time to start thinking about options. Maybe to look at fixed-rate offers, or maybe to just keep a closer eye on the trend.

Critical: "Act now"

        - alert: Euribor12MCritical
          expr: max by(maturity) (euribor_daily_rate_percent{maturity="12M"}) > 2.6
          for: 30m
          labels:
            severity: critical
            category: personal_finance
            namespace: monitoring
          annotations:
            summary: "Euribor 12M critically high"
            description: |
              ⚠️ Euribor 12M reached {{ $value | humanize }}%!

              Your mortgage costs are significantly impacted.
              Consider immediate action to lock in rates

At 2.6%, the cost impact is real. This isn't "keep an eye on it" territory anymore - it's "call the bank and discuss options" territory.

The tiered approach matters. At work, we don't page engineers for every warning. Warnings go to Slack. Critical pages go to phones. The same logic applies here. A warning means I'll check the dashboard when I have time. A critical alert means I'll stop what I'm doing.

Where do alerts go?

I use Discord. It's free, it's already on my phone, and setting up a webhook takes five minutes. When an alert fires, I get a notification just like any other message. No extra apps, no subscription fees, no complexity.

Visualisation

The Dashboard: Everything at a Glance

There's something deeply satisfying about seeing your finances on a proper dashboard.

All four maturities on one screen. Historical trends. Current values. No clicking through bank websites, no PDFs, no guessing what the rate was last month.

The repo includes a ready-to-import Grafana dashboard if you want the same setup. But honestly, the specific panels matter less than the feeling: I know exactly where I stand.

Conclusion

Was It Worth It?

The investment:

• Beelink Mini-S12 home server: €273

• Setting up k3d and Prometheus: ~1 day

• Writing and deploying the exporter: ~1 day

• Total: €273 and a weekend

The actual value:

Missing a Euribor rate hike at the wrong time could cost thousands. When my annual rate recalculation happens, I'm locked in for the next 12 months. If rates are spiking and I don't notice until after that date, I've missed the window to refinance or renegotiate. That single missed opportunity could easily dwarf the cost of a mini PC and a weekend of tinkering.

And beyond the money:

• Peace of mind: I don't think about Euribor anymore. The system thinks about it for me.

• Early warning: If rates move toward my threshold, I know in hours, not weeks.

• Historical data: When recalculation time comes, I have months of trend data to inform my decisions.

• A platform: The server and cluster now monitor other things too. The marginal cost of adding a new exporter is nearly zero.

The real ROI isn't time saved. It's risk reduced and cognitive load removed. Every system you automate is one less thing occupying mental space.

The Bigger Point

SRE isn't just a job title. It's a way of thinking about systems - any systems. The same principles that keep production infrastructure reliable can keep your personal life a little more sane.

You don't need to monitor your mortgage. But you probably have something in your life that you manually check, worry about, or forget to track. Something that a bit of automation and alerting could take off your plate.

Maybe it's utility prices. Maybe it's investment portfolios. Maybe it's your kid's school calendar. The specific problem doesn't matter. The mindset does.

Build the dashboard. Set the alerts. Let the system do the watching.

You've got better things to think about.

The Code

The full exporter, Kubernetes manifests, and Grafana dashboard are available on GitHub:

👉 github.com/GoGstickGo/euribor-prometheus-exporter

If you build something similar - or apply SRE thinking to a different real-life problem - I'd love to hear about it.