Show me your back-end

I choked in an interview today.

I was trying to explain why the dashboard that I wrote, guided by architectural decisions and research, was any different from vibe-coded slop.

The interviewer wanted years of experience. Frameworks. The standard litany: "React, Next.js, what's your ORM?" I tried explaining that our app handled maybe 200 users, and was performant on thousand-line data tables. Wrong answer. He wanted me to list some technologies and move on.

Here's what I couldn't articulate in that room: there’s a difference between using the default tech stack and actually tailoring to a project’s constraints. Every bootcamp grad and SWE intern can spin up a Next.js app with Supabase and call themselves full-stack. It’s like following a recipe. Real decisions happen when you know enough to say "we don't need this" and defend it without asking Claude code.

I've built production apps that are just Vite hitting a 100-line FastAPI server. There’s no database; everything is in JSON files because the data fits in memory and remains unchanging. That’s a codebase that requires zero maintenance.

But how do you demonstrate that judgment in an interview?

You can't. Because Systems Design interviews aren't about design, they're about as much pattern matching as Leetcode, if not moreso. When you’re asked to design Twitter, there’s one expected answer: you draw the microservices diagram everyone's seen on YouTube, mention Redis and CDNs at the right moments, and wait for the nod. Nobody asks if Twitter's architecture makes sense for the problem you're actually solving. Nobody wants to hear that your startup probably needs a monolith.

The interview game rewards people who can perform conventionally.

So when they asked me to describe my full-stack experience, I wanted to say: Let me show you my Git history. Let me walk you through the commit where I ripped out an entire Node server because I realized that we could keep it as a fully single-page application. Let me explain the afternoon I spent benchmarking serverless functions versus a $5 VPS and why the VPS won.

Instead, I said "four years" and watched that mean nothing.

There's no standard interview format for "I understand the tradeoffs." No Leetcode problem that tests whether you can ship fast by doing less. The best signal of engineering judgment is the project you didn't overcomplicate, but we've built an industry that only knows how to test for complexity.

So I'm left wondering: where are the interviews that actually want to see how I think?

I'm tired of drawing the same CDN diagram and pretending it's insight.