When I was a student, I had a picture in my head of what working at a big tech company would be like. It came from the places any student's picture comes from: open-source projects, side projects, and coursework. That picture turned out to be accurate about some things and completely off about others.
None of that is a knock on the job. It's just that the day-to-day of large-scale engineering is genuinely different from what smaller-scale work prepares you for, and most people don't find that out until they're in it.
So if you're a student, a new grad, or someone eyeing the jump, here's the honest picture of what it's actually like. Not the recruiting version. The real texture of the work.
Most of the design is already done
In school, almost every project starts from a blank page. Build a distributed system. Model this domain. Pick an architecture and defend it. The blank page is the whole point — you're being taught to make decisions.
At a large company, you're usually joining something that already exists, and it exists at a scale that took years and many people to build. The architecture is set. The service boundaries are drawn. The data model and deployment patterns are in place, and usually for good reasons that predate you.
So your work happens inside that structure. You still make design decisions, but they're smaller and more local — how to build your piece well, not what the whole system should look like. The big architectural questions were answered before you arrived.
This surprises a lot of new grads, and it's worth understanding early, because it reframes what "good work" means. It's less about inventing structure and more about working skillfully within it. Different muscle, and a genuinely valuable one.
Your tools will be unfamiliar, even the familiar ones
I came in comfortable with the standard open-source stack — Maven, Gradle, the usual deployment tooling. I could build, test, and ship, and I'd done it enough to feel solid.
Then I learned that a company operating at this scale tends to build its own internal versions of almost everything. Its own build system, its own deployment tooling, its own monitoring and service frameworks, shaped around problems most open-source tools were never designed for.
The interesting part is that the concepts transfer even when the tools don't. It's all still builds, pipelines, and dependency graphs underneath. But knowing the open-source version doesn't mean you can skip learning the internal one — you learn it fresh, and lean on the concepts rather than the specifics. It's a humbling first few months, and then one day the internal tools stop feeling foreign and start feeling like tools.
A tip for anyone about to go through this: the discomfort of relearning familiar-feeling things is normal and temporary. It's not a sign you were underprepared.
A lot of the job is understanding, not writing
Here's something school doesn't quite prepare you for: at scale, the systems are too large for any one person to hold in their head.
That changes the nature of the work. A big part of senior engineering turns out to be holding context — knowing why a service behaves the way it does, which team owns which piece, what was tried before and why it didn't work. Much of that knowledge isn't written down. It lives with people, and it moves through conversations.
Which means the job is more collaborative than the heads-down stereotype suggests. Not in a politics sense — just that the information you need often isn't in any document, and knowing how to find the right person and ask a good question becomes a real, everyday skill. Learning who knows what is part of learning the system.
Debugging is more like detective work
When a project is small enough to fit in your head, debugging means reading code until you find the problem.
At scale, you're usually tracing a path through components you didn't write, owned by teams you haven't met, with behavior that emerges from how the pieces interact rather than from any single piece. So debugging becomes investigative: follow the trace, check the runbook, find the person who's seen this before, form a hypothesis, test it, learn from how it fails.
It's a skill in its own right, and a satisfying one once it clicks. The mindset shift is going from "I will read my way to the answer" to "I will investigate my way to the answer." Both get you there. They just feel very different.
You'll be oriented by firehose
Onboarding at scale is a lot at once. Documentation, access, a mentor with their own deadlines, and fairly quickly, a real task.
And that task usually assumes context you don't have yet, simply because the person who wrote it has that context and can't easily see what you're missing. So a good chunk of early work is figuring out what a task even means before you can start on it.
I've come to think this is one of the most valuable things large-scale work teaches, and nobody names it: rapid orientation with incomplete information. You get dropped into something complex, with partial docs and limited time, and you learn to find your footing and produce anyway. It's uncomfortable at first and then it becomes one of the most portable skills you own.
What it adds up to
Put it all together and the shape of the work is clear.
School and side projects mostly teach you to make things from scratch. Large-scale engineering mostly asks you to understand things that already exist, well enough to change them safely and add to them well.
Those are different skills, and the second one is underrated — it's harder to show off, harder to interview for, and closer to what a lot of senior engineering actually is. You learn what operational rigor really means. You learn how systems behave when the rare failure happens every day. You learn to work through people, and to orient yourself fast in unfamiliar territory. Small-scale work mostly can't teach these, because it doesn't generate the problems that force them.
If I could send one note back to my student self, it wouldn't be a warning. It'd just be a heads-up: the picture in your head came from open source and coursework, and the real thing is different in ways that are worth knowing in advance. Not harder or easier. Just different, and genuinely interesting once you see it for what it is.
If you've made the jump from school or smaller companies to big tech, what surprised you most? Always curious how universal this is.
Top comments (2)
"Your tools will be unfamiliar, even the familiar ones"
This one is always interesting. Half the time when there is an internal tool (or an internal version of an open source tool), there is a good reason why which predates you. The rest of the time is because long ago, an engineer no one could say no to made a bad decision that everyone has been stuck with for decades.
I once worked at a medium sized but well known tech company that used a fully internally developed email program for everything. It was incredibly out of date, was missing every feature you would want, and had an team sinking real hours into it all the time.
I have heard that it has finally been replaced with an off the shelf solution and everyone is much happier.
Agreed! the "engineer no one could say no to" origin story is so real. My guess for the email one: it probably started as someone's promo project. Build a thing splashy enough to get to the next level, and then the builder moves on and the thing becomes load-bearing forever. Add in the company's understandable nervousness about letting an external tool touch internal data, and you've got a system that no one loves but no one can kill either.
The part you mention about a team sinking real hours into it is the quiet cost nobody counts when these get built.
The thing I'd add from my own experience: the pain is sharpest when you're new to on-call. The first few rotations are already stressful, and being slow with an unfamiliar internal tool makes it worse, because you're learning the tool on the page, live, while something is actually broken. I've had moments where I couldn't work a service's metrics dashboards well enough to tell what had actually gone wrong, simply because I didn't know the tooling yet. The signal was probably right there. I just couldn't read it fast enough.
Glad to hear the email one finally got replaced with a solution everyone is more happier with!