All writing

Work & Career

Translated from the original Chinese essay · Read the Chinese original →

During lunch break that day, my old colleague Leo and I were eating noodles downstairs from the office.
He had just left a small company of fewer than 50 people, and his next job was at a global giant with tens of thousands of employees.

"I'm really worn out from all the chaos." He said this while poking at his noodles with his chopsticks, not taking a bite.

At the small company, he did almost everything: writing code, configuring servers, answering customer calls, helping the boss polish PowerPoint slides, and even going to the server room himself to unplug network cables on launch day. At first it felt cool, like playing a game where the skill tree was blooming in every direction.
In those years, he learned how to negotiate prices with suppliers, how to fix broken test machines himself, and even stepped in to demo products to clients on short notice.
This "one person doing three jobs" pace made every day feel like leveling up in a game—no sooner had one problem been solved than the next one popped up.

But by the third year, he realized these skills were like a "shotgun"—broad coverage, but none of them could punch through. His resume was packed with details, but when placed in another company, many of them could only be summed up as "temporary solutions," unable to prove he had stable, replicable capabilities.

On the other hand, big company roles are as clear-cut as an assembly line. On the first day, the handbook tells you that to change this configuration file, you only need to modify these few lines of code, and the rest is handled by platform automation.
He thought he could finally focus on "specialization" in peace, but after three months, he found that the parts he actually got to work on were pitifully few.
Once, he spent two weeks troubleshooting a performance bottleneck, only to discover that the only thing he could actually change were two parameters in a configuration file; the rest required approvals and handing off to other teams. At that moment, he felt like he was tightening a single screw on a massive machine—that screw was important, but no one could see him as a person from that screw.


Don't Just Look at the Surface; Look at the "Gold Content" of Growth

Many people, when choosing a company, focus on size, salary, and title, but overlook a more critical question—can the abilities I accumulate during this time be taken with me?

Ability isn't necessarily valuable just because you do a lot.
Three years at a small company, tasks never stop coming, but if all your methods are improvised on the spot, next time you face a new environment, you might still have to start from scratch.
Three years at a big company, seemingly doing only one thing, but if that thing includes design trade-offs, stability assurance, cost optimization, and other aspects, those methodologies can be transferred to different scenarios.

I give myself three test questions:

  • If I moved what I do to another company, would it still hold up?

  • Can I standardize it and reuse it in the next project?

  • Can I clearly explain the design choices and trade-off process behind it?

If most of the answers are "yes," then whether you're at a small company or a big one, you're accumulating real capability.
If most of the answers are "no," then be wary—you might be pouring energy into tasks with low transferability.


The Resource Gap Is Narrowing, but the Gap in Extracting Capability Is Widening

In the past, when people discussed small companies vs. big companies, they were actually comparing resource density:
Small companies have fewer resources but give you a stage; big companies have more resources but a narrower stage.

In recent years, AI has scrambled this formula.
I know a friend who works as a backend engineer at a startup with only 8 people. Previously, they didn't even have the resources to build an automated testing framework, but this year they directly used AI to assist in writing tests and generating CI/CD pipelines, achieving big-company-level delivery quality without begging for help.
Conversely, engineers at big companies are also starting to use AI to quickly simulate full-link environments, running business scenarios in internal sandboxes, no longer as tightly boxed in by role boundaries as before.

In other words—
The gap in tools and resources is narrowing, but with the same tools in different people's hands, the gap in the gold content of output may be widening.


The Key Is: What Do You Want to Learn, and Where?

A few people I know who grew exceptionally fast share a common trait:
They are very clear about what they should learn at each stage—rather than "wherever the salary is highest, that's where I go."

  • Some first settle in a big company for two years to build a solid foundation in engineering methodology, then go to a small company to practice, becoming a technical lead within three years.

  • Others dive straight into a small company from the start, gain a full round of end-to-end experience, realize they lack standards and systematic thinking, and immediately jump to a big company to fill those gaps.

  • Still others use a "dual-track" approach: their main job at a big company hones their systems thinking, while in their spare time they take on remote work for startup teams, filling in cross-domain and end-to-end experience.

On the contrary, those who stay in a "vague state" are the most at risk—
At a small company, they become someone who knows a little about everything but not deeply enough;
at a big company, they become a "master of the screw," and once they leave the familiar system, they don't know how to even turn on the machine.


So How Do You Choose Without Getting It Wrong?

My judgment criterion is simple:
Look at the next stage, identify where your weaknesses are, and go to a place that can fill those weaknesses.

Just graduated, no methodology, no large-scale project experience? A big company might be a safer starting point.
Have the methodology, but lack cross-domain integration or opportunities to be directly responsible for business outcomes? A small company might let you fill those gaps faster.
You can even deliberately plan a "double jump" route—first go to a place that builds a solid foundation, then go to a place where you can spread your wings.

Don't be fooled by the labels "all-rounder" or "specialist."
True all-round ability means having one or two skills that can punch through, plus enough interfaces to connect with other capabilities;
true specialization means, beyond depth, still understanding the other parts of the system, rather than seeing only that one screw.


Leo changed jobs again later.
This time, he joined a mid-sized company—one with a complete engineering system, but also enough freedom and space.
He told me: "I finally don't feel like I have to wait until I jump ship three years later to start growing."

That day after we finished our noodles, he smiled and said something that left a deep impression on me:
"Actually, company size is just the surface. The key is whether you can fill your bag with as many things as possible that you can take with you from this position."

Many times, what we choose is not the size of the company, but the accelerator for the next stage of our lives.
First see clearly which square of the chessboard you're standing on now, and then make the right move.