A Big Name Doesn't Mean Growth

A lot of developers dream of landing a job at a large tech company. Yandex, Sber, Google — it sounds like the obvious next step in a career. Big projects, a recognizable name on your résumé, strong teams. Surely that's where you'll grow as a developer.

I wouldn't be so sure. You can join your dream company, do your job well, and discover a few years later that you can barely do anything outside your own slice of the work. And that may have little to do with you. It may be how the job is set up.

A developer at a large company can have real responsibility. Their code goes to production, other people's work depends on it, and mistakes can be expensive. But owning your slice of the work and seeing a project through the entire development cycle are different things. The more people involved in building a product, the easier it is to spend years working on one small part of that process.

When You're Left With One Percent

Imagine getting a task after someone else has gathered the requirements, talked them through with the business, chosen the architectural approach, prepared the infrastructure, and spelled out what needs to be done. Your job is to implement your part, get it through review, and hand it off. The task may be hard. Doing it well takes skill. But other people have already made most of the decisions around it.

That's what I mean when I say you're left with one percent after the other ninety-nine are done. Those aren't measured hours; they describe your place in the work. You write the code, but you may never touch the architecture, figure out the requirements, speak to the customer, or think about how the new feature gets into production. All of that happens somewhere nearby. Other people handle it.

For the company, this arrangement may make perfect sense. It needs predictable results, and dividing up the work helps deliver them. There's no immediate disaster for the developer, either: you can do your job, get paid, and get better at your specialty.

The problem shows up over time. If you spend years handling only your stage of the process, adjacent skills won't appear on their own. You can know one service or workflow inside out and still freeze when you have to clarify requirements, choose a solution, or get a project to a working state by yourself. There isn't much incentive to learn those things in your usual role: someone else has already organized the work for you.

What My First Year Taught Me

My career started almost the opposite way. With no experience, I was thrown into a project that had to be built from scratch. I had to talk to customers, estimate timelines, work through requirements, design the architecture, write the code, and get the whole thing working. I had to go through the full development cycle right away.

It was hard. The final result wasn't very good, but it works. There was a lot I didn't know; I made mistakes and figured things out as I went. Still, in that first year I became a full-fledged senior developer: I can take on a project and work through every stage myself instead of waiting for someone to hand me a perfectly prepared task.

Everything since then has been more about sharpening my skills and building up a range of cases I've dealt with. I got better at familiar work and saw more problems and solutions. But the foundation came from that first year, when I had to own the entire result.

Do I regret those Spartan conditions? Not at all. Without them, I don't think four years on the job would have given me what I got in the first one. Skills grow when you have to use them. If everything around you has already been designed, agreed on, and prepared, you may never need to step beyond your assigned task.

What I Saw in Interviews

I noticed this while hiring, too. I've interviewed developers from Sber and other large companies. When we discussed programming and the work they had actually done, I often had no questions about their ability. They knew their area.

But as soon as I asked something deeper or moved a little off the familiar script, they started falling apart. They couldn't remember something, explain a decision, or work through a situation that differed from what they knew.

That's a problem for me. A developer can spend years confidently closing tasks inside a well-established process, then join a team where they have to clarify the requirements, choose a solution, and work without a ready-made set of instructions. Their previous job simply didn't require them to take those steps regularly. They have experience and an impressive line on their résumé, but less independence outside their familiar area than you might expect.

That's why I'm wary of the idea that experience at a large company automatically makes someone a strong developer. You need to look at what they actually did and which decisions they made themselves.

Big Companies Move Slowly

The size of the work isn't the only factor. There are also the processes. A large company has to coordinate many teams, control access, and manage changes. Otherwise, it couldn't function. Even when some of that is automated, many people and systems are still involved.

For example, a new developer needs access to GitLab but can't get it for a week. Nobody is sure who grants access, the right person is on vacation, or they have higher-priority work. Then there's another approval, another permission, another team. Two or three weeks into the job, the developer is attending meetings but still can't really start working. This illustrates what scale can do; it isn't a story about a particular employer.

Something similar happens with new features. Other teams need to sign off, the project waits for decisions from above, and managers may have little reason to invest in an area without substantial funding or attention. Pauses pile up between an idea and the work itself, and the developer spends that time trying nothing new. When that becomes the normal environment, growth can slow down easily. Why take initiative if every move runs into another chain of waiting?

I don't think you can simply remove a complicated process and expect a huge company to operate like a small team. But a developer choosing a place to grow should understand the cost of that scale. Time spent on the job, and years of experience, aren't the same as the number of tasks, decisions, and mistakes you've worked through yourself.

Who Actually Needs a Developer Who Can Do All That?

There's another question here: does every company need someone who can independently handle the entire development cycle? Probably not. I'm not saying every developer has to be full-stack, fix display bugs on a website, set up deployments, and do a complete analysis for any new service. Those things may never be part of the job. I'm talking about independence in the core development work: understanding a task, making technical decisions, working things out with people, and getting to a finished result.

Even that kind of developer isn't needed everywhere. If the tasks are clear, the domain isn't especially complex, and the process is already in place, an average developer can handle the work. It's understandable to want someone who can do everything at once, but that person may quickly run out of interesting tasks. Their salary expectations may exceed your range, and their ambitions may outgrow the role. None of that is guaranteed, but it's worth thinking about before you hire.

For developers, the point is similar. Your job doesn't have to push you to grow every single day. You can deliberately choose a clear role with good conditions and feel fine about it. Just don't confuse a comfortable, well-organized job with a guarantee that you'll know how to run an entire project a few years from now.

Look Past the Name

If your goal is to grow as a developer, I'd look first at what you'll actually get to do. Will you take part in discussing requirements? Can you propose architectural decisions? Will you see what happens to your code after review? Will you have to work through tasks that don't already have a ready-made solution?

You may get more of that at a smaller product company than at a famous corporation. You may also get more work, tougher conditions, and early decisions that are far from great. But you'll make those decisions yourself and learn why they did or didn't work. That's how growth happens for me.

If growing as a developer is your priority right now, I'd caution you against joining a large company just for its name. Don't treat Yandex, Sber, or Google as an automatic ticket to a great career. The size and fame of an employer tell you nothing about how broad your work will be. A smaller company may give you much more independence, useful experience, and reason to keep developing.

Find out in the interview how much real work and decision-making will be yours. Otherwise, you can spend years completing one tiny part of a huge process and never learn how to do the rest. A nice line on your résumé won't close that gap.