I interviewed at Fast last year as an experienced startup engineer. I was given the "describe a production incident you were involved in" question.

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.

This is hilarious - velocity vs. bug tradeoffs is a key balancing act that every startup does, and you were totally right in what you were doing, also with your point that other companies may choose differently and that's also totally fine.

But to be deemed as a cowboy - utterly hilarious, given where they ended up. Pretty cowboy with the investor money instead I reckon?

What exactly is meant by "cowboy" here?

Not OP but in tech cowboy often means "taking unacceptable risks to increase velocity". In this case, shipping code without integration tests in Staging. whether that risk was 'unacceptable' is the difference of opinion at issue.

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.

Someone who plays it "fast and loose" in terms of engineering (for example, deploying straight to prod). As parent mentions- this isn't necessarily a bad thing depending on the context (but "cowboy" here has a negative connotation).

oof, i described myself as a cowboy at a interview i did last year to a higher up, no wonder i didn't get the job even though i did well on their technical exams. I always took cowboy coder to mean someone who had independence and resilience to get things done even if the environment isn't conducive towards that.

It’s a kind of cargo cult, cf the post “you aren’t google”. The kinds of people who succeed at FAANG (MANGA?) are used to a lot of infrastructure and are (at google in particular) mostly incented to ship rev 0, not build a sustainable system.

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.

My experience of Google is very much incrementalism and long term sustainability. Very few things at Google are built "new", it's tons of cobbling together systems that already existed and making small adjustments and optimizations to them.

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 am always surprise when well funded startups hire former big-tech engineers, rather than experienced startup engineers

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

The risk, and I see that currently in non-software functions, is hiring people from big corps that know how to manage the people that solved those scale/... problems instead of the problems themselves. With the result that those senior people default back to building an organization that looks like the one they are used to. Which doesn't solve a single one of those solved problems.

Quite likely to happen of the founders / existing hiring managers have no idea themselves how big corp solved these problems.

That’s the problem. They had 0 need of scaling. It’s premature optimization 101.

nail it, then scale it

Exactly, scaling doesn't help you solve product-market fit. It adds operational complexity/overhead with, in this specific case, no benefits, and solidifies the product that doesn't have market fit. Watch this for a laugh: https://youtu.be/y8OnoxKotPQ

There is a pretty good reason. If the experienced engineer worked at a startup that went anywhere, they have a lot of money and aren't coming to work for you. So the choice in many cases is big tech engineer or failed startup engineer. It's not clear which is better, it is clear (ish) which seems better.

This is not true at all. A lot of people In BigTech companies boast of passing a tough interview as their biggest accomplishment and beyond that haven’t really done much.

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.

You've compared the worst big tech engineers with the best startup engineers. Those are rarely the choices faced.

Your comparison was similarly unfair at the other end while presenting it as a common scenario, which is why I presented a different one.

This is from my experience as a hiring manager who has worked at multiple startups and now works for a large public tech company.

But I was implying the choice isn't clear.

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.

From my experience, the choice isn't clear favoring BigTech engineers either.

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.

Yep, the choice really isn't clear.

I think judging an engineer's engineering skills by the (effectively random) chance of them being at a startup that "makes them rich" just reveals a significant lack of understanding of how the current startup world works. The vast majority fail. The ones that succeed tend to not make anyone any significant amount of money except the founders.

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.

At least in my experience, even people who understand how it works seem to have this bias. On average it might even be a fair bias.

> If the experienced engineer worked at a startup that went anywhere, they have a lot of money and aren't coming to work for you.

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.

A lot of what you are saying is true - but if you re-read my comment, it wasn't saying what you seem to be thinking it was saying. Just read it literally.

There are plenty of engineers from successful startups —- maybe the majority of them — who were lucky to get a new Honda Fit out of a very lucrative (for some) exit.

They pay them better salaries and comp too. Startups boast about poaching talent from big tech by matching compensation and putting those new big tech employees at forefront.

It's a fund raising and public marketing trick.

Or inexperienced startup engineers, given the nature of the name

Yeah...it's often a different type of person who goes from 0->1 than from 1->100. Neither type is better than the other, just different.

Hear hear.