Systems, Scanners, and Software Agents: Why I Still Love the "Interview"

I recently went through an interview process that didn't feel like an interrogation. It felt like a high-level strategy session.

I got to dig into how my past as a network and systems engineer informs how I build cloud infrastructure today, why I've embraced AI agents as a force multiplier, and how I approach system design with a focus on inputs and outputs.

Solving My Own Problems (The Project Lab)

I've always believed that the best way to stay sharp is to solve a problem you actually have. During the interview, we dove into my recent GitHub activity, focusing on three projects that bridge the gap between hobbyist curiosity and production-grade engineering.

Live Transcription & Alerts

I have an old fire/police/EMS scanner, but I don't want to listen to it all day. I built a tool using Whisper and WebSockets that transcribes the audio feed in real-time and sends me an email alert only when specific keywords are detected. There's also a web frontend that I can use to view past transcripts and listen to archived audio snippets.

The Auto-Video Editor

Editing video can be time consuming. Manually cutting "ums" and "uhs" is a waste of human potential. I wrote a local tool that uses CUDA-accelerated Whisper and silence detection to automatically strip filler words and frozen frames from screen recordings.

Unmuted

This is a "human-in-the-loop" experiment. It takes silent screen recordings and uses GPT-4o to decipher what's happening, offering the user options to interactively build a transcript. It's a great example of where pure AI needs a human hand to get the best results.

AI Elephant in the Room

I was very upfront during the interview: I've been coding for decades and I've trained hundreds of IT professionals, but my workflow has changed.

In my recent repos, you'll see heavy use of AI agents. I don't hide that. Using agents in modern software development isn't "cheating." It's a requirement. If you aren't using these tools to speed up the boilerplate so you can focus on the architecture, you're falling behind. I still know how to write it by hand, but I'm not going to pass off AI-generated code as my own hand-written work. I'm the architect, and the agents are my crew.

It All Comes Down to Inputs and Outputs

When I'm asked to design a system, whether it's a GPS tracking pipeline for a fleet of trucks or an AI-enabled curriculum generator, my motto is always: What are the inputs and what are the outputs?

Once you define the schema and the goal, the middle part usually solves itself. I thought through a hypothetical ingestion engine for real-time GPS tracking: Kinesis for low latency and DynamoDB for those thousands of writes per second. But I'm also looking for the "hidden gotchas." Is the truck in a dead zone? We need to queue updates and ensure no duplicates. The ingestion API must be secure and scalable, so Kong or API Gateway would make sense. Is the data going to sit in DynamoDB forever? No, keep it there temporarily, but periodically dump it to S3 and query with Athena for historical analysis.

Troubleshooting is in My DNA

My background is in networking, and that Layers 1-7 mindset never leaves you. I've spent years fixing "intermittent" problems that turn out to be exhausted NAT translation tables on aging firewalls or unauthorized web browsing saturating office bandwidth.

That history makes me a realist when it comes to infrastructure. Sure, we can "roll our own" elastic services, but is it worth the time and effort? I'd rather use EKS or Fargate to get to market, but I'll lean towards Kubernetes to maintain the flexibility to migrate between cloud providers or back to on-prem without vendor lock-in.

Code is for People

Finally, we talked about maintainability. It's easy for me build out infrastructure, develop an app, and then deploy it on the infrastructure. I know the stack, so it's easy for me to maintain. But what about the team that has to monitor and troubleshoot it at 3:00 AM? System design has to consider the person who inherits the system, not just the person who builds it.