A Rejected Candidate From a Big Tech Company
A few days ago, I interviewed a candidate with an impressive resume — he came from a major tech company and could rattle off his tech stack:
"I've read the Kafka source code, K8s tuning is my specialty, and I can recite high-concurrency design patterns from memory..."
You know what? I rejected him.
Not because his skills were weak. Quite the opposite — he was too good, obsessed with "using the most impressive technology."
I asked him: "The business team needs to launch an experimental project next week. Initial DAU will be around a few thousand. How would you approach it?"
His eyes lit up and he served up a luxury package:
- Microservices decomposition
- Full distributed tracing
- Database sharding
- Redis cluster
- Not enough time
- Not enough people
- Not enough budget
- A mountain of technical debt
- When do this feature's peaks occur?
- What's the rollback strategy if it fails?
- Which paths can be degraded, and which must be guaranteed?
- Cutting requirements with product: "This logic is too complex, terrible cost-benefit. Cut it."
- Battling sibling teams over boundaries: "Why should this dirty work land on my side? Push it to the gateway team!"
- Pitching the boss for resources: "Without more machines, Double 11 will definitely crash. Don't come crying to me when it does."
- Comforting developers: "The schedule is too tight. Write the code ugly for now, ship the business first. Next sprint I'll buy everyone bubble tea and we'll definitely refactor — though there probably won't be a next sprint."
Watching his fanatical expression, I had only four words in mind: this company is doomed.
The Truth About Architects: Not a Hidden Master, but a Neighborhood Committee Auntie
Many programmers have a chuunibyou-style fantasy about architects: the silent master of the team who, when a crisis hits, puts on noise-canceling headphones, bangs out beautiful code, saves the system, and disappears without leaving a name.
But anyone who's actually done architecture work knows reality is nothing like that.
What is an architect, really?
Not a perfectionist, but a master of coordination and compromise.
Back to that interview question: launch next week, a few thousand DAU — what do you do?
A real architect grits their teeth, picks the most monolithic, oldest framework — or even just hacks out a branch inside the existing system — and gets it shipped in three days.
Why? Because they know that if the business model doesn't validate next month, the entire project gets cut. What's the point of a month spent on high-availability architecture?
Technology always exists to support the business.
Carving flowers on a mountain of legacy code while guaranteeing it won't collapse for three years — that's the core architect skill. Not rewriting everything from scratch at every opportunity.
If You Can't Stomach Legacy Code, You Can't Be an Architect
Programmers all have technical OCD — that's normal. Early in my career, seeing inherited code made me itch to refactor on the spot: bad comments? Refactor! Terrible variable names? Refactor! Wrong design pattern? Refactor!
But I later realized this compulsion is a disease in architects. It needs curing.
Because the business world isn't a lab. You can't say "wait until I've refactored this system perfectly before we ship."
The market won't wait, competitors won't wait, and investors' patience won't wait either.
An architect's job is finding the optimal solution under a pile of constraints:
So you push through anyway, find a walkable path through the mess, and write it down: there's a pit here, a landmine there — if the project is still alive in three years, remember to pay it back.
Carving flowers on a mountain of legacy code and keeping it standing — that's real skill.
What's Wrong With CRUD?
There's a toxic attitude in the industry: people writing low-level code look down on people writing business logic. In meetings, when product managers explain business context and monetization, half the room plays with their phones; the moment implementation details come up, everyone is energized.
But as long as you think business CRUD lacks technical depth, the architect role is out of reach for you.
Why? Because talking architecture without business is pure nonsense.
A company's core is making money. If you don't know where the core conversion funnel is, which five-minute outage doesn't affect revenue, or whether this business will grow 10x or shrink next year — how do you design degradation? High availability? How do you allocate your scarce server resources?
Architecture grows out of the business. It isn't drawn at your desk with diagramming software.
I've seen too many architects produce beautiful architecture diagrams, then watch the system collapse three months after launch when traffic grew 10x — because they never understood the business's growth pattern.
Architects who truly understand the business ask from the start:
The answers aren't in technical books. They're in the heads of the business team.
Architects Spend More Than Half Their Time Arguing
This is what deters 80% of programmers.
If quiet, headphones-on coding all day is your idea of bliss, don't become an architect. You'll be depressed.
Producing an architecture proposal with a UML diagram takes two days at most. What do you do with the remaining two months? Being a social butterfly and neighborhood committee auntie across departments:
Architect isn't a technical role. It's a hybrid of technologist + manager + salesperson.
There Are Only So Many Seats
The workplace is brutally realistic. In a 100-person dev department, how many architects does it need?
Two or three, tops.
The underlying logic: building a tower doesn't require 100 people thinking about the foundation. Two or three people draw the blueprints; the other 97 just need to lay bricks honestly and efficiently.
What the boss pays for is your proficiency, not your architectural thinking.
This isn't a knock on CRUD. Quite the opposite — writing CRUD that is fast, stable, and bug-free is itself a scarce ability.
I've seen too many people fixated on becoming architects end up neither here nor there: no architectural thinking developed, coding skills atrophied. At 35 they get laid off with "former architect" on their resume, yet can't cleanly write a single complete module.
Are You Actually Suited to Be an Architect?
If you insist on the architect path, stop burying yourself in technical books. Try these:
1. Listen to what product and operations argue about. Their arguments are usually the business pain points — and the starting points for architecture. 2. Volunteer for messy cross-department projects. The ones everyone hates. The best training ground for coordination skills. 3. Explain a technical plan to a completely non-technical boss. If you can do it in three sentences, you truly understand it.
After that, if you think:
"God, this stuff is disgusting. I just want to quietly write brilliant code."
Then settle in as a senior developer. That's perfectly fine.
Not everyone is suited to be an architect, just as not everyone is suited to be a manager. Finding your position matters more than forcing yourself into an ill-fitting one.
Look Beyond the Code
Three parting thoughts:
> Look beyond the code to the system, beyond the system to the business, beyond the business to the commercial model.
This is the architect's perspective — but every programmer should have it, even if you only want to write great CRUD.
When you understand why the business needs a feature and how the company makes money from it, your code naturally changes: you'll add caching on critical paths, save resources on non-critical ones, add monitoring where errors are likely, degrade where revenue isn't affected.
This isn't an architect's privilege. It's the professionalism of every serious programmer.
---
Final Words
"95% of programmers will be CRUD writers until retirement" — this isn't an insult; it's reality.
But the gap between CRUD writers can be enormous. Some mechanically complete tasks. Others can step outside the code and see the system and business behind it.
The latter, even without the architect title, already think like one.
And that is the real dividing line in career development.
---
*Do you think you're better suited to being a technical expert or an architect? Share your experience in the comments.*