4 ms·

I've worked everywhere from small startups, to big FAANG companies and big enterprise companies. I am in the very same opinion as op. 1. Financially the exits

I've worked everywhere from small startups, to big FAANG companies and big enterprise companies. I am in the very same opinion as op. 1. Financially the exits weren't worth it. The amount you actually learn is incredibly questionable. 2. Working at bigger companies I learned a hell of a lot more, from the mere fact that there are a bigger pool of resources with a lot of experience to go get help from. This is just not technology, but even from improving management and soft skills. You'll learn a hell of a lot more on your career path moving up to Director and VP level from a big company than the equivalent title at a startup. 3. Everything else is really dependent on you as an individual. I personally thrived at a big company. As the writer suggested at a startup its all about shipping and things are pretty much laid out for you. At a big company, it really gives you time to take advantage of resources and people .. you just have to be very aggressive and pro active in your pursuits.

mlthoughts2018 8y ago
Just adding to your point: in all of the start-ups I worked for, the main selling points were (a) more responsibility sooner and (b) chance to drive decision-making about tech stack and/or work with the best tools (new or old) without red tape. I’ve never seen (or heard of) any start-up actually fulfill these selling points any better than medium-to-large companies. More responsibility sooner typically just translates into the usual crap about “wearing many hats” — which is to say your “responsibility” means doing whatever whimsical thing that other people say you have to do, with no regard for your career goals. In start-ups, I’ve only ever witnessed people getting less autonomy and much less freedom to learn. At the same time, the earliest engineers might have made very poor commitments to certain extreme philosophies about programming and engineers who come later have to clean up these messes while experiencing a lot of dogma from the early stage people. I’ve personally seen this happen several times with ex-Google employees who join as the earliest engineers and insist on setting up copies of what they recall from Google, mostly insisting on a monorepo regardless of any use case details, insisting on using Bazel or a similar homebrewed build file system, insisting on the same style of canary deployments. You have to be really careful to avoid these places unless you’re perfectly happy to be a cog implementing these patterns based on someone else’s authority-from-big-company-X. You might even have a super senior job title, yet still just be shuffling code according to someone else’s dogma, while being told the company doesn’t want “dogmatic” engineers. All this is just to say: be careful. Taking a start-up job because you think you’ll get more responsibility or be given autonomy or discretion in project architecture or tooling decisions is often a big mistake. By this point, I believe candidates simply need to reject start-up jobs categorically. Unless the job is paying full market total compensation (excluding non-liquid equity), top of the line benefits, and provides full transparency, just say no. Investors looking to back start-ups simply have to accept that the up-front costs from day one include ensuring employees earn fair market compensation exclusive of the risks associated with start-up equity. That’s just table stakes of hiring a team, period. It does not matter what optimistic outcomes you’d like for candidates to believe about you in exchange for dramatically less compensation.
- bradhoffman 8y ago
  That was an incredible response. Thank you so much for sharing your advice!
- bluquark 8y ago
  > I’ve personally seen this happen several times with ex-Google employees who join as the earliest engineers and insist on setting up copies of what they recall from Google, mostly insisting on a monorepo regardless of any use case details, insisting on using Bazel or a similar homebrewed build file system, insisting on the same style of canary deployments. I'd be interested to hear more details of what winds up going wrong with these practices in a startup environment?
  - mlthoughts2018 8y ago
    Many things go wrong. Monorepos + bazel is an approach that’s well-suited for some use cases but poorly suited for other use cases. The problems usually happen when some early engineer “knows it all” because they saw these tools in action in a different use case (such as inside Google) and incorrectly assert they will be good solutions in some other use case (e.g. a start-up with very different reality than Google). If the company is healthy, there will be a give and take, people will acknowledge that e.g. monorepos are not universally always a good or workable choice, and compromises or trade-offs will be analyzed in earnest. If the company is not healthy, which happens often in start-ups that are forced to adopt a monoculture or extreme philosophy of the founder or early engineers (and enforcing dogma may even be a main reason why those people left other jobs to be early employees in a start-up), then usually by some argument from authority or poorly conducted confirmation bias blog post competition, the dogmatic choices about monorepos or bazel tooling (just as common examples I’ve seem turn out poorly) will just be mandated and all intellectual integrity about it will be shut down.
- acjohnson55 8y ago
  > Just adding to your point: in all of the start-ups I worked for, the main selling points were (a) more responsibility sooner and (b) chance to drive decision-making about tech stack and/or work with the best tools (new or old) without red tape. > I’ve never seen (or heard of) any start-up actually fulfill these selling points any better than medium-to-large companies. I've had that work out for me. But that was also specifically what I was hired for. Definitely, you have to look before you leap.

mlthoughts2018 8y ago

Just adding to your point: in all of the start-ups I worked for, the main selling points were (a) more responsibility sooner and (b) chance to drive decision-making about tech stack and/or work with the best tools (new or old) without red tape. I’ve never seen (or heard of) any start-up actually fulfill these selling points any better than medium-to-large companies. More responsibility sooner typically just translates into the usual crap about “wearing many hats” — which is to say your “responsibility” means doing whatever whimsical thing that other people say you have to do, with no regard for your career goals. In start-ups, I’ve only ever witnessed people getting less autonomy and much less freedom to learn. At the same time, the earliest engineers might have made very poor commitments to certain extreme philosophies about programming and engineers who come later have to clean up these messes while experiencing a lot of dogma from the early stage people. I’ve personally seen this happen several times with ex-Google employees who join as the earliest engineers and insist on setting up copies of what they recall from Google, mostly insisting on a monorepo regardless of any use case details, insisting on using Bazel or a similar homebrewed build file system, insisting on the same style of canary deployments. You have to be really careful to avoid these places unless you’re perfectly happy to be a cog implementing these patterns based on someone else’s authority-from-big-company-X. You might even have a super senior job title, yet still just be shuffling code according to someone else’s dogma, while being told the company doesn’t want “dogmatic” engineers. All this is just to say: be careful. Taking a start-up job because you think you’ll get more responsibility or be given autonomy or discretion in project architecture or tooling decisions is often a big mistake. By this point, I believe candidates simply need to reject start-up jobs categorically. Unless the job is paying full market total compensation (excluding non-liquid equity), top of the line benefits, and provides full transparency, just say no. Investors looking to back start-ups simply have to accept that the up-front costs from day one include ensuring employees earn fair market compensation exclusive of the risks associated with start-up equity. That’s just table stakes of hiring a team, period. It does not matter what optimistic outcomes you’d like for candidates to believe about you in exchange for dramatically less compensation.

bradhoffman 8y ago
That was an incredible response. Thank you so much for sharing your advice!
bluquark 8y ago
> I’ve personally seen this happen several times with ex-Google employees who join as the earliest engineers and insist on setting up copies of what they recall from Google, mostly insisting on a monorepo regardless of any use case details, insisting on using Bazel or a similar homebrewed build file system, insisting on the same style of canary deployments. I'd be interested to hear more details of what winds up going wrong with these practices in a startup environment?
- mlthoughts2018 8y ago
  Many things go wrong. Monorepos + bazel is an approach that’s well-suited for some use cases but poorly suited for other use cases. The problems usually happen when some early engineer “knows it all” because they saw these tools in action in a different use case (such as inside Google) and incorrectly assert they will be good solutions in some other use case (e.g. a start-up with very different reality than Google). If the company is healthy, there will be a give and take, people will acknowledge that e.g. monorepos are not universally always a good or workable choice, and compromises or trade-offs will be analyzed in earnest. If the company is not healthy, which happens often in start-ups that are forced to adopt a monoculture or extreme philosophy of the founder or early engineers (and enforcing dogma may even be a main reason why those people left other jobs to be early employees in a start-up), then usually by some argument from authority or poorly conducted confirmation bias blog post competition, the dogmatic choices about monorepos or bazel tooling (just as common examples I’ve seem turn out poorly) will just be mandated and all intellectual integrity about it will be shut down.
acjohnson55 8y ago
> Just adding to your point: in all of the start-ups I worked for, the main selling points were (a) more responsibility sooner and (b) chance to drive decision-making about tech stack and/or work with the best tools (new or old) without red tape. > I’ve never seen (or heard of) any start-up actually fulfill these selling points any better than medium-to-large companies. I've had that work out for me. But that was also specifically what I was hired for. Definitely, you have to look before you leap.