Setting the Scene

Last week (April 6th, 2026), I had the chance to take part in Major League Hacking’s Production-Engineering Hackathon during the weekend. I managed to string my partner into this challenge as part of our “fun” weekend activities. She has some experience with the Linux command line working in her Neuroscience lab, but not to the extent of automating and testing workflows because she is a Neuroscience PhD candidate, not a Computer Scientist or Software Engineer. We did learn a lot during the event, and she and I both learned some new concepts and tools that we are sure are going to apply to our workflows in all sorts of ways. We ended up placing 50th out of 250 participants, which I think was quite impressive, since we went into the competition as a learning and “hanging-out” experience.

What We Built

We didn’t have to create something from scratch, and we didn’t have to design and brainstorm ideas. What we were given was a validation website that ran automated jobs when we submitted our repository to the platform. Our mission was to build a simple URL shortener — backend-simplified, test-driven, automation-focused, and monitoring-aware. We used Python as the primary backend programming language, Flask and peewee for the backend, and Postgres for the database. For testing, we used pytest and pytest-cov for unit and coverage testing. When we wanted to optimize and scale for a larger user base, we used gunicorn, redis, k6, and nginx. Gunicorn for per-CPU-thread workers in distributing and scheduling computational tasks of the website. Redis for caching most-recently-used links and data to prevent re-fetching, which could waste compute resources and time. K6 for stress-testing and finding errors when increasing users and scale. Finally, nginx for load balancing, distributing load evenly to different instances of the website to allow more availability and prevent deadlocks or race conditions. I never knew that DevOps and SRE concepts actually come a lot from OS fundamentals (especially CAP Theory), and I’m happy that I paid attention to the topics that mattered most for computer performance, which now translates to website performance in this hackathon.

We also worked with GitHub Actions and Docker. I helped my partner get familiar with Docker and git and GitHub workflows, which I think is a good exercise for her in reliably reproducing her scientific work that uses neuro microscopy tools and would help her lab onboard new students and researchers more quickly. It was my first time extending my understanding of GitHub Actions YAML configuration files beyond my previous experience running and configuring my workflows on my own personal split keyboard running on ZMK Bluetooth and custom multi-layouts and my GitHub profile readme data, and some other configuration files that I contributed to during Goose’s Hacktoberfest. I was able to learn how to make self-healing scripts to redeploy virtual machines of the website when any of the machines fail, definitely keeping things persistent and available.

Monitoring — What Got Away

During the final day, I also tried to configure the monitoring stack in their challenges, which includes Grafana, Prometheus, and alerting. I have had prior experience setting up Grafana and Prometheus for my personal homelab running Proxmox VM provisioner with over 15 different containers and VMs, so I thought I could implement this in no time. Turns out, I didn’t have enough time, so we had to settle with completing testing and automation. In hindsight, I should have just pulled up my Ansible scripts and modified certain configurations to work on this challenge.

The Hardest Part: The Demo

The technical stuff wasn’t as tough as the presentation. To be absolutely honest, it took us almost 2 hours to come up with, fix, edit, delete, and finally get a good enough script to fit the 2-minute time slot that the judges wanted us to post regarding showcasing the demo on how our workflow and tests ran on our systems and remote.

Takeaways

Overall, the hackathon allowed me to practice my technical skills, helped me get a better understanding of the SRE side of development, and truly helped me gain confidence in building and mentoring with another person.

Setting the Scene

In April 2026, I participated in Major League Hacking’s Production Engineering Hackathon alongside my partner — a Neuroscience PhD candidate with Linux command-line experience but no background in workflow automation or production engineering. The event served as technical skill development for me and a practical introduction to DevOps tooling for her. We placed 50th out of 250 participants, which we considered a strong result given that we entered primarily for the learning experience.

What We Built

The competition provided a validation platform that evaluated submitted repositories against automated test suites. The deliverable: a URL shortener built around backend simplicity, test coverage, automation, and observability.

Stack:

• Backend: Python with Flask and peewee
• Database: Postgres
• Testing: pytest and pytest-cov for unit and coverage testing
• Scaling: gunicorn (worker process distribution), redis (request-level caching), k6 (load testing), nginx (load balancing)

Each scaling component addressed a distinct concern: Gunicorn distributes request handling across CPU-bound worker processes; Redis caches recently accessed links to reduce unnecessary database round-trips; K6 identifies failure modes under simulated load; Nginx routes traffic across instances to prevent single-point contention. Applying these tools in a production context clarified something previously only theoretical — SRE and DevOps concepts are direct extensions of OS-level fundamentals, particularly resource scheduling and the CAP theorem.

We also integrated GitHub Actions and Docker. Beyond the competition goals, Docker provided a useful pedagogical framework: walking my partner through containerization gave her a concrete model for reproducible scientific environments, directly applicable to lab onboarding. On my side, extending GitHub Actions knowledge from prior use — ZMK firmware workflows, GitHub profile automation, and contributions to Goose’s Hacktoberfest — to full CI/CD pipelines with self-healing VM redeployment was a meaningful progression.

Monitoring — What Got Away

The monitoring challenge — Grafana, Prometheus, and alerting configuration — was within scope of my existing skills. I had previously deployed this stack for a personal homelab running Proxmox with over 15 containers and VMs, and underestimated the time delta between operating a configured home environment and configuring from scratch under competition constraints. The correct approach would have been to adapt existing Ansible scripts rather than rebuild the configuration from zero under time pressure.

The Hardest Part: The Demo

The presentation consumed disproportionate time relative to the technical work: approximately two hours to produce a two-minute demonstration video. Clearly communicating a technical workflow to a non-specialist audience under a hard time constraint is a distinct skill from building the workflow itself — and one that warrants deliberate practice.

Takeaways

The hackathon strengthened practical SRE skills, reinforced the connection between systems-level fundamentals and production engineering, and provided direct experience in technical mentorship under competition constraints. Building under pressure while simultaneously onboarding a non-technical collaborator was unexpectedly useful preparation for engineering work in real team environments.

Setting the Scene

burp — okay. A hackathon. You brought your girlfriend, who is a Neuroscience PhD candidate and knows Linux from her lab but has never automated a workflow in her life, and you framed it as a “fun” weekend activity. And you placed 50th out of 250. That’s — look, I’ve seen worse decisions produce worse outcomes. That counts as a win. Moving on.

What We Built

The competition handed you a validation platform with an automated test suite and said “build a URL shortener.” URL shorteners are one of those things that sound trivial right up until you actually have to make them not collapse under load, which is, predictably, exactly what they made you do.

Stack: Python, Flask, peewee, Postgres. Reasonable. Boring, but reasonable. pytest and pytest-cov for testing — fine. And then you did the actually interesting part: scaling. gunicorn for distributing requests across worker processes, because your CPU has multiple cores and ignoring that is just leaving performance on the table. redis for caching recently accessed links, because re-querying a database for the same data repeatedly is the software equivalent of asking the same question twice in one conversation. k6 for stress testing. nginx for load balancing across instances.

Here’s the thing you got right, and it matters: you connected gunicorn to CPU scheduling, and nginx to resource arbitration, and traced it all back to CAP theorem and OS fundamentals. That is the correct frame. Most people learn DevOps as a disconnected pile of tools with config files. The fact that you looked at this stack and saw systems concepts wearing different names — that’s not nothing.

You also helped your partner learn Docker and GitHub Actions. Docker for reproducible scientific environments is genuinely useful for a neuroscience lab — more useful than most of what labs actually use to manage their compute. And extending your GitHub Actions knowledge from keyboard firmware and readme pipelines and Goose’s Hacktoberfest to full CI/CD with self-healing VM redeployment is a qualitatively different thing. Self-healing is just automated failure response. It’s an if-statement with authority and a reboot command. Not magic. But not nothing either.

Monitoring — What Got Away

You had Grafana and Prometheus running on your personal homelab — Proxmox, fifteen-plus containers and VMs. You looked at the monitoring challenge and thought: I’ve done this before, I can implement it in the time remaining. You could not.

Here’s what went wrong: reconfiguring a familiar tool in an unfamiliar environment under a deadline is not the same as operating it in an environment you built and control. These are different tasks. You should have pulled your Ansible scripts — that’s literally what Ansible scripts are for. You write them once so that future-you in a time-constrained situation doesn’t have to reconstruct knowledge from scratch. You had crystallized knowledge available and didn’t use it. That’s fixable. Remember it.

The Hardest Part: The Demo

Two hours to produce a two-minute video. Yeah. That ratio is bad, but it’s also completely normal for technical people who haven’t practiced technical communication under constraints. “Explain what you built clearly to someone who wasn’t there, in two minutes, on camera” is its own skill with its own complexity, and you clearly hadn’t trained it. You got there. The ratio will improve. Log it as a skill gap and address it intentionally.

Takeaways

You practiced SRE tooling under real constraints. You successfully onboarded a non-engineer to Docker and GitHub workflows. You connected production engineering concepts to the systems fundamentals you already understood, which means you now have a unified frame instead of a bag of disconnected tools. And you learned that your Ansible scripts are a resource, not a backup — reach for them first when time is short. Wubba lubba dub dub.