A startup probably won't be able to afford the standard of engineering that you can find at places like Google. There are good practices you can learn there that you probably won't see at a startup.
As a company scales up, coordinating effort across teams becomes more important for getting stuff done, even as a senior IC. You no longer know the whole stack (assuming you're an early employee) and have to ask other teams to adapt interfaces and add functionality to get your stuff to work.
However, that's the default at FAANG. Coordination is the name of the game and it's so meeting heavy because it's a lot of work to keep everyone aligned, on the same page.
You can learn interesting technical things either way, but it's easier to find a niche as a specialist at a large company. Startups usually need generalists in the early days.
I spent eight years at a startup (4th engineer, rose to chief architect after CTO left, was most senior engineer of 40 or so in co) and joined Google last March.
I learned a lot when I joined the startup (Rails was new to me) and I added some hard yards of scaling up database utilisation with very little extra hardware over the years, but the pace of learning declined over time and my degree of specialization increased as I focused on the biggest bottleneck the business had, technically - even while the business was of course more interested in fattening up its product line for valuation.
I learned a huge amount when I joined Google too, though a lot of that is due to the parallel universe quality of working at a company that had to solve many scaling problems for the first time and did so with inhouse tech which didn't become industry standard (I blame monorepo - it makes it too easy to have incestuous dependencies). A bigger part of the learning was the mode of getting things done between teams. I haven't learned much in terms of transferrable tech, but I have seen better engineering practices put into action, that we could not afford - and didn't have strong enough singular opinions on - at the startup.
I can say it's not the same things every day, everywhere. There is no end to the code at Google, there is more than you can ever hope to understand and it changes too fast anyway. At a startup, you can understand almost everything. More work is political at largeco, necessarily because the org tree sometimes needs shaking to get things moving, but also simply sociologically - a startup is a small team, largeco is a whole nation with internal rivalries and whole divisions that never need to communicate much.
> As a company scales up, coordinating effort across teams becomes more important for getting stuff done, even as a senior IC.
And that is the root of all evil. Everything comes down to a screeching crawl. What could be done in a week by a couple startup folks now takes months or quarters (!). So yes, I don't think "standard of engineering" applies here :-)
In addition to all that was already said, this has the disadvantage of misaligning incentives. At FAANG (or any other big co for that matter), it pays to stretch projects and blow their complexity outside of any reasonable measure, just because the folks in charge of such projects benefit materially from more people and "bigger architecture". It is engineering bureaucracy at its worst, unfortunately.
In contrast, at startups it pays to move fast and one simply cannot afford growing unnecessary "fat", gotta stay lean or die. Obviously, some folks are more comfortable with the former (FAANG/big co) approach, because at the end of the day they just want to get their paycheck and go home, it's not about this job or that job at all. It's a tradeoff, for sure.
> A startup probably won't be able to afford the standard of engineering that you can find at places like Google.
A "standard of engineering at Google"? You must be joking.
Best examples of engineering I have ever seen were done at 5-15 people startups.
I'm proud of participating in some of those. FAANG on the other hand is a mire of bullshit.
Yes, I do mean it. The approach to data migrations, feature flags and testing with fakes that themselves have conformance tests, has been of a high engineering standard in my team. Automated release to production Monday to Thursday.
I can easily see it being different elsewhere, of course.
A startup probably won't be able to afford the standard of engineering that you can find at places like Google. There are good practices you can learn there that you probably won't see at a startup.
As a company scales up, coordinating effort across teams becomes more important for getting stuff done, even as a senior IC. You no longer know the whole stack (assuming you're an early employee) and have to ask other teams to adapt interfaces and add functionality to get your stuff to work.
However, that's the default at FAANG. Coordination is the name of the game and it's so meeting heavy because it's a lot of work to keep everyone aligned, on the same page.
You can learn interesting technical things either way, but it's easier to find a niche as a specialist at a large company. Startups usually need generalists in the early days.
I spent eight years at a startup (4th engineer, rose to chief architect after CTO left, was most senior engineer of 40 or so in co) and joined Google last March.
I learned a lot when I joined the startup (Rails was new to me) and I added some hard yards of scaling up database utilisation with very little extra hardware over the years, but the pace of learning declined over time and my degree of specialization increased as I focused on the biggest bottleneck the business had, technically - even while the business was of course more interested in fattening up its product line for valuation.
I learned a huge amount when I joined Google too, though a lot of that is due to the parallel universe quality of working at a company that had to solve many scaling problems for the first time and did so with inhouse tech which didn't become industry standard (I blame monorepo - it makes it too easy to have incestuous dependencies). A bigger part of the learning was the mode of getting things done between teams. I haven't learned much in terms of transferrable tech, but I have seen better engineering practices put into action, that we could not afford - and didn't have strong enough singular opinions on - at the startup.
I can say it's not the same things every day, everywhere. There is no end to the code at Google, there is more than you can ever hope to understand and it changes too fast anyway. At a startup, you can understand almost everything. More work is political at largeco, necessarily because the org tree sometimes needs shaking to get things moving, but also simply sociologically - a startup is a small team, largeco is a whole nation with internal rivalries and whole divisions that never need to communicate much.