#2 Getting rejected from the job I didn't want

· 786 words · 4 minute read

This is a post from around late 2024 that has been sitting in my Obsidian. Not sure why I never threw it on the internet, but /frag is the meant as my content graveyard.

I got rejected from a position I thought I was qualified for. This was for a product team at a cloud provider, as a software engineer, shipping a well-made product that had to be well-designed and cost-effective to many users. After a very positive 90 minute interview and a week to sleep on it several times, a recruiter got back to me: I didn’t have enough experience in “API Design”. I remember when we talked about it, in the span of less than a minute. I said it wasn’t the focus of my prior work, but I can write a Swagger/OpenAPI file. They didn’t press me on this at all. They also asked about my preferred Go HTTP framework (giving the option of “just net/http”), and I said I picked Gin to learn it, and that the project I was on didn’t require stringent benchmarking, so a tough selection process wasn’t a consideration.

Looking bad, I was just bad at communicating. In fact I learned how to write an OpenAPI spec over the course of two days somewhat recently, had known how REST worked for close to a decade and even could’ve delivered some hot takes on where spec idealism fails. I was too focused on avoiding promising something I hadn’t done - design an API in a formal context with someone more experienced than me cross-checking, that I completely missed that I had acquired enough of this skill though curiosity that getting me to a professional level was trivial.

Then I got offered an interview for different position at the company. This wasn’t software engineering, it was just infrastructure. I did agree to an interview that at the time of writing has yet to happen, but I already dread it. Because the truth is that I don’t really want either job: I want both.

Let’s take a step back. I joined the company that introduced me to Kubernetes in a professional capacity in 2018. Kubernetes was still very much for early adopters. I don’t remember which version I started on exactly, but I do remember upgrading to 1.10. Kubernetes as a managed service didn’t really exist outside of GCP, so being on AWS, the cluster was built from scratch. It’s amazing, looking back, how much I learned in the first 2-3 months, and how much we’d build on top of this basis. Commodity tooling for Kubernetes didn’t really exist back then, and neither did a lot of companies use it, yet alone deploy on it directly. My boss back valued a saying that Kubernetes wasn’t a platform, it was for building platforms. And we treated it like that, practicing a form of modern platform engineering before it was really codified. Over the years, the team built their own PaaS for application specification and deployment, DNS server, metrics collection and pre-processing daemon, autoscaling and ingress controller, all out of need. Everything was built exactly to spec, and everyone on this small but very effective team could understand (almost) everything that was happening in our domain.

Now, you simply can not justify the expanse. Everything we build exists in one way or another. But you are left with the sharp corners of tools you just adopt instead of shape yourself, and the inconsistencies in how everything works together.

You also notice how Kubernetes evolved mostly towards tooling to get Kubernetes manifests into a cluster, and if there is an abstraction, it’s usually built on Helm. Of course the simplifications we made wouldn’t just work for everyone, but the alternative - laying out the complexity of Kubernetes in front of developers who should be able to focus on their domain - doesn’t seem like an evolution, but a step back. There are a few exceptions, like Kubevela, but even those systems are more concerned about modeling a single application, rather than an integrated stack of microservices, aware of each other during deployments.

Truth is, I had a very unique job. It didn’t pay particularly well, it wasn’t remote, and yet I learned more there than since. I was in the unique position of not just jokingly saying I did DevOps - the IT worlds possibly most inconsistently understood term. I actually regularly engaged in building infrastructure and built software to run (on) it. I feel like this specific job, at least in the context of Kubernetes, has ceased existing. Platform Engineering (or Developer Enablement if you’re fancy) might sound the same, but it is much more like assembling prefabricated parts than building something made-to-order.