About every six months, I interview for a few positions. My primary motivation is to see what questions folks are asking, what tools and platforms are in use, and to keep a pulse on the interviewing experience. I use this to improve my own interviewing pipelines and make it as positive an experience for my applicants as possible.

In my most recent endeavor, a significant number of job postings look for individuals with a preference for “simple solutions” or some similar sentiment. I want to dive into this idea, and why it unhelpfully flattens the idea of simplicity.

I have the following statement included in my personal marketing blurb on my website: “I have a preference for simplicity, but with an understanding that simple looks different under varied constraints.” This is a polite way of saying that your complexity has to live somewhere, and that the real consideration is constraints.

To give the infrastructure engineering example, let’s assume we are deploying some AWS. We need an ALB, Route53 entries, a couple EC2 backends in an autoscaling group, an RDS database, an Elasticache instance, and a couple Lambdas for your cron jobs. You could deploy these ClickOps style, poking around the UI and setting everything up, or you could deploy them via your infrastructure as code tool of choice.

We could also go all out, containerize the application, get a k8s cluster in a couple clicks and deploy our Helm chart. Done! Easy! “Simple”, right?

Given an organization with a couple of folks who understand Terraform, Packer, and Github Actions, a CI/CD pipeline for this would be reasonable to create and maintain. Assuming no organizational understanding of these tools, the ability to make modifications within the UI, follow the upstream AWS documentation, and lean on AWS Support may be preferable until we can perform some cross-training and up-skill the team to where Terraform maintenance is reasonable. Given a team who has never maintained a Kubernetes cluster or containerized an app, would it be simple, or even responsible, to run this on EKS?

Is the “simple” solution consuming third-party cloud services? If the organization is too financially constrained for that, but person-hours, technological familiarity, and on-prem servers are all available to deploy an equivalent open source solution, is it then wrong to accept the operational complexity of maintaining that service rather than consuming it?

Moving forwards, I am including a blurb in my own job posts that I am looking for individuals who work to understand constraints, as this is what these posts are getting at. They are not looking for simple solutions in isolation, but rather pushing against unnecessary complexity, which results from designing without an understanding of constraints. The next step will be crafting some interview questions that help tease out an individual’s thinking around complexity and constraints.