I detailed a case where a recent deploy I had done had resulted in elevated error rates for some of our clients and how I had solved it with a quick follow up push to prod. The interviewer asked why it wasn't caught in staging and I mentioned that it could have been but as a small company we have to make velocity vs bug tradeoffs and in general it feels like we are currently at a sweet spot. The interviewer was unwilling to explore that space at all, or the concept that different companies might want to land in different places.
Later I was given feedback that I did exceptionally well in the technical interviews but the company didn't want any cowboys on their team. All of that is probably just a long way of confirming the other anecdotes in this thread that from the outside fast seemed somewhere between delivery hostile and overly cautious.
Fun fact: The 2011 article Cowboys and Pit Crews (https://www.newyorker.com/news/news-desk/cowboys-and-pit-cre...) points out that modern cowboys actually spend a lot of time on communication and checklists.
But to be deemed as a cowboy - utterly hilarious, given where they ended up. Pretty cowboy with the investor money instead I reckon?
That’s a gross generalization, but gives you the flavor. I couldn’t do what they do (huge budget, low incrementalism) and would hate the environment. But they can’t do what I do, and when hired to do so, typically fail. Not because they are dumb, or lazy, or foolish, or anything negative — typically they are none of those things. Just haven’t experienced the startup environment.
There's a big difference between the product strategy side (v0 of N different chat products) and the tech side which is that all those products are made of many of the same components arranged differently.
i'd say that if you plan on scaling, you need a bit of both. a lot of tricky scale/process/architecture questions have effectively been "solved" in big orgs, it's useful to have people who can bring this experience
to take a completely random examples: setting up a performance improvement plan, performing incident post-mortems, organising oncall rotas, branching strategies when you have a mix of small customers on standard product and big accounts with customisations etc
Quite likely to happen of the founders / existing hiring managers have no idea themselves how big corp solved these problems.
Meanwhile, good startup engineers are used to learning new technologies quick, can work across the full stack, can own all aspects of their app/feature, work without much direction, never mind a formal spec, and generally are used to solve problems over shipping code.
Often, the key drawback with startup engineers who are available after working at one or two startups, is that they pick bad companies and do not really understand the business end of the equation. However they are still excellent problem solvers.
This is from my experience as a hiring manager who has worked at multiple startups and now works for a large public tech company.
There aren't many good startup engineers with experience at successful startups who are floating around, especially from when the company in question was actually a startup.
edit: i re-read, my comment "failed startup engineer" may have read differently to what i intended. I meant they worked at a failed startup, not that they were a failure. It's largely unfair, but people do seem to think people who worked at a successful company are better than those who worked at a failed company.
For example, a pattern I noticed among the pool of BigTech engineers recruiters would pitch to me was the following. The engineer would join a startup with an immediate promotion in title, and then 18 months after the fact, they would jump back to BigTech to a higher level than the one they had when they left. When you asked what they delivered at the startup, it was clear that they didn't do much or often couldn't correlate the impact of their features to the ROI of the business. Nevertheless, the title upgrade in their resume helped them game the recruiter search and the BigTech ladder.
https://www.teamblind.com/ is full of recommendation for similar strategies that BigTech engineers use to climb the ladder.
Also, the good startup engineers aren't floating around, but you can still poach them. You'll have to give them a big signing bonus to cover the purchase of their options, but it isn't a risk to me when they are sure bets; a recommendation from my network for example.
There seems to be a significant number of tech industry employees still floating around that are convinced that instant financial independence is available for all.
This is a stupid view of motivation and competence.
First, it implies people are only motivated by money. At the first startup I worked at, one of the senior engineers had been through 4 successful exits and was in the business to build things.
Second, competence of the engineering org and individual engineers is orthogonal to successful exits. An engineer can successfully ship many iterations of a product that are just a bad market fit and the company will fail. I’d still take that engineer any day over the typical FAANG cog who’s big project was a 2 year tax billing database migration.
It's a fund raising and public marketing trick.