The Trap of Building Everything Yourself
There is a certain kind of engineer who, when asked to solve a problem, immediately reaches for a blank file and starts writing a custom solution — even when a battle-tested, widely-adopted tool already exists. This instinct feels virtuous from the inside ("I understand exactly what it does, I control every line") but is one of the strongest negative signals a Bar Raiser looks for in senior and staff-level candidates.
Not Invented Here (NIH) Syndrome is the irrational preference for building internal tools over adopting existing standards, driven by ego, distrust of external code, or the desire to write interesting code rather than deliver business value.
The Interview Trap in Action:
| Scenario | Response Type | Signal |
|---|---|---|
| "We need a message queue." | "I'll use Kafka or SQS based on our scale and operational constraints." | ✅ Senior thinking |
| "We need a message queue." | "Kafka is too heavy. I'll write a custom in-memory queue in C++ for performance." | 🚩 NIH — strong negative signal |
| "We need a cache layer." | "Redis fits here. Let me walk through the eviction policy trade-offs." | ✅ Senior thinking |
| "We need a cache layer." | "I don't trust Redis. I'll build a custom LRU cache service." | 🚩 NIH — strong negative signal |
Why NIH Fails the Bar Raiser Test:
- Maintenance burden: Your custom solution is a "snowflake" — it exists nowhere else in the industry. When you leave, no one can maintain it. Every new hire has to learn your idiosyncratic system instead of a standard tool they already know.
- Wasted Innovation Tokens: Every engineering organization has a finite budget of time and attention for novel work. Spending that budget on plumbing (message queues, caches, load balancers) instead of the product is a strategic failure. Staff engineers understand this instinctively.
- Ego signal: NIH often signals that the engineer prioritizes "interesting coding problems" over business outcomes. A Bar Raiser reads this as: this person will make decisions that serve their own intellectual satisfaction rather than the company's needs.
The Nuance (Senior Depth):
NIH is not always wrong. There are legitimate cases where building custom infrastructure is the right call — when you are operating at a scale where off-the-shelf tools genuinely cannot meet your requirements (think: Google's Bigtable, Amazon's Dynamo, Meta's Scuba). The key is that the decision must be driven by evidence of a specific constraint that existing tools cannot satisfy, not by preference or distrust. In an interview, if you propose a custom solution, you must be prepared to articulate exactly what constraint forces that choice and why every existing alternative fails to meet it.