You're Not Interviewing for the Job. You're Performing for the Job Title

I once had a job interview for a backend position. Their stack was Node.js, MySQL, nothing exotic. The interviewer asked: "If you have an array containing a million entries, how would you sort the data by name?"

My immediate thought was: If you have a JavaScript array with a million entries, you're certainly doing something wrong.

The interviewer continued: "There are multiple fields that you should be able to sort by."

This felt like a trick question. Surely the right answer was to explain why you shouldn't be sorting millions of records in JavaScript. Pagination, database indexing, server-side filtering. So I said exactly that.

I was wrong. He wanted me to show him Array.prototype.sort().

My crime? Prioritizing real-world efficiency over theatrical scale. The interviewer didn't see a practical engineer, he saw a candidate who "lacked vision."

The Theater of Technical Interviews

I once read that "a complex system usually reflects an absence of good design." It's brilliant. True. And if you're prepping for a system design interview, forget it immediately.

In real-world engineering, simplicity is king. In interviews, complexity is currency.

Job interviews aren't assessments. They're auditions for a job title: The Architect Who Solves Hard Problems™.

You're not being evaluated on whether you can build the described system efficiently. You're being evaluated on whether you can perform the role of someone who could theoretically build Google.

The Unwritten Script

Every system design interview follows the same theatrical formula:

Act I: Summon the Dragons First, you assume infinite users and planetary-scale traffic. Multiply every reasonable number by 1,000. Treat a todo app like it's handling the New York Stock Exchange. The interviewer nods approvingly as you describe millions of concurrent users for what is essentially a digital notepad.

Act II: Draw the Arcane Symbols Next, you cover the whiteboard in boxes, arrows, and at least one redundant Kubernetes cluster. Add a message queue, Kafka obviously, regardless of whether you need one. Sprinkle in some microservices because monoliths are for peasants, and draw load balancers like protective talismans around every component.

Act III: Invoke the Gods of Tech Finally, you debate consensus algorithms for a blog comment system, mention observability and SLOs for good measure, and whisper "eventual consistency" like an incantation that will ward off all future scaling problems.

The performance has nothing to do with the actual job. It's about proving you know the vocabulary of scale.

Interview World: Complexity = Competence

• Show knowledge of distributed systems patterns
• Demonstrate familiarity with enterprise-grade tools
• Prove you can architect for theoretical millions

Real World: Simplicity = Good Design

• Start with the simplest solution that works
• Add complexity only when genuinely needed
• Optimize for maintainability, not theoretical scale

I've seen great engineers fail interviews because they suggested using a relational database instead of a distributed NoSQL cluster, for a system that would handle 100 requests per day.

I've also seen mediocre engineers get hired because they could fluently discuss sharding strategies for problems that didn't need sharding.

Why the Theater Exists

This isn't malicious. It's structural, driven by several interconnected forces:

Signal vs. Noise: Complexity is easier to evaluate than judgment. Anyone can memorize CAP theorem and recite the differences between SQL and NoSQL databases. But wisdom about when not to use distributed systems? That's harder to assess in a 45-minute conversation. Interviewers gravitate toward what they can measure.

Risk Aversion: Hiring committees fear false negatives more than false positives. A "simple" answer feels risky. What if this person can't handle complexity when it's genuinely needed? A "complex" answer feels safer, even if it's complete overkill for the actual problem at hand.

The Aspiration Gap: Companies hire for their aspirational selves, not their current reality. They want "Senior Staff Engineers" who can theoretically scale to millions of users, not "People Who Write Maintainable Code" for their current 10,000 daily active users. The fantasy of future scale drives present hiring decisions.

Interviewer Incentives: Discussing load balancing strategies and distributed consensus is more intellectually stimulating than talking about boring CRUD operations. Even if CRUD is 90% of what the actual job entails. Interviewers are human, and humans prefer interesting conversations over practical ones.

Once you're hired, the script flips entirely. You'll spend your days deleting unused microservices that "future-proofed" against scale that never came, arguing against message queues for problems that cron jobs solve perfectly, and consolidating databases that were split "for scalability" but now just create maintenance overhead. You'll find yourself explaining to eager junior developers why the new feature doesn't need its own Kubernetes namespace, and why sometimes a simple bash script is more reliable than a distributed system.

The very complexity that got you hired becomes the tech debt you'll spend years dismantling. I've worked with engineers who aced system design interviews by proposing elaborate architectures, then spent their first year on the job simplifying systems that previous hires had over-engineered using the exact same interview logic. It's a cycle of complexity creation and subsequent complexity destruction, driven entirely by hiring theater.

The Cost of Honesty

What happens when you try to be pragmatic in interviews?

The Backpressure Question: "How do you handle backpressure in your system?" - Honest answer: "We don't generate enough load to need backpressure handling." - Interview answer: "We implement exponential backoff with circuit breakers and queue depth monitoring."

The Database Question: "SQL or NoSQL for this use case?"
- Honest answer: "Postgres handles this fine and the team knows SQL." - Interview answer: "We'll use a polyglot persistence strategy with Redis for caching, Cassandra for time-series data, and Neo4j for the social graph."

The Scaling Question: "How do you handle 10 million users?" - Honest answer: "We don't have 10 million users. We have 10,000. Let's solve that first." - Interview answer: "We'll implement horizontal sharding with consistent hashing and auto-scaling Kubernetes pods."

The honest answers demonstrate experience. The interview answers demonstrate vocabulary. Guess which ones get job offers?

How to Win the Game

I'm not advocating dishonesty, I'm acknowledging reality. Interviews are a ritual, and rituals have rules. Here's how to navigate them:

Separate Performance from Practice: Playing the interview game doesn't make you a hypocrite. It makes you pragmatic about a broken system. You can excel at interview theater while still being a principled engineer once you're hired.

Learn the Sacred Texts: Study distributed systems patterns even if you'll never use them. Memorize the CAP theorem even if it's mostly irrelevant to your daily work. Practice drawing architecture diagrams that look impressive on whiteboards. Think of it as learning a foreign language you'll only speak during interviews.

Embrace the Tropes: Always start discussions with "At scale, we'd need to consider..." Mention monitoring and observability early and often, even for simple systems. Add redundancy everywhere, even for non-critical components. Use the magic words that signal competence in interview-land.

Then Drop the Act: Once hired, advocate ruthlessly for simplicity. Be the voice of reason who asks "Do we actually need this complexity?" Use your hard-earned credibility to push back against unnecessary over-engineering. This is where the real engineering work begins.

This system is frustrating but not permanent. Some companies are starting to recognize the disconnect and experiment with better approaches. They're giving candidates real problems the company actually faces rather than theoretical scaling challenges. They're rewarding engineers who question complexity, not just those who can implement it. They're asking candidates to identify over-engineering in existing systems rather than create new complexity from scratch.

But until these practices become widespread, we're stuck with the performance. The theater continues because it serves too many psychological needs: it makes interviewers feel smart, companies feel rigorous, and candidates feel like they're solving important problems.

---

Technical interviews exist in a parallel universe where different rules apply. The stage demands a performance of complexity; the job rewards mastery of simplicity.

The system is broken, but individual actors can't fix it by martyring themselves. Play your part, get the role, then use your position to advocate for sanity.

Remember: the goal isn't to perpetuate the theater forever. It's to get inside the building where you can help others see that the emperor's distributed microservices architecture has no clothes.

The best revenge against interview theater isn't failing the performance, it's succeeding at it. Then you can spend your career deleting the unnecessary complexity it celebrated.

---