Live data from Hacker News

What software engineers can learn from the rapid collapse of Fast

newsletter.pragmaticengineer.com

311–320 of 482 posts

Re: What software engineers can learn from the rapid collapse of Fast

#311

Earlier quoted context omitted.

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…

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.

Re: What software engineers can learn from the rapid collapse of Fast

#312

Earlier quoted context omitted.

How on Earth did the company raise so much money with so few milestones of any kind being achieved?

> How on Earth did the company raise so much money with so few milestones of any kind being achieved? Fast pitched itself as taking the prudent path compared with e.g. Bolt. The latter went for big clients first. Fast started with small businesses. There were clearly other issues. But the closing era of cheap capital favoured the bold, and Bolt’s seizure of the fertile low grounds cut off Fast from its growth. Despit…

this doesn't answer the question at all, it's just a bunch of bullshit words strung together. we never raised any money, and we had more to show than Fast although we were in a completely different industry. this goes to show that all that matters is knowing people, it doesn't actually matter whether you have a real business and have achieved anything at all.

Re: What software engineers can learn from the rapid collapse of Fast

#313
post #201
post #189

Earlier quoted context omitted.

> What's not to like here ? I think as a serious counter to that, look at the offers that a FAANG will give you - similar base salary, similar sign-on bonuses. Generally WLB is fine. The real differentiator - they're offering you equity which is liquid right now. If one is risk averse, one wouldn't touch Fast with a ten foot pole.

Some reasons : - FAANG aren't/weren't remote - The appeal for working at a startup vs an established company, and the sense of freedom associated with that - Some guys that would love the idea behind FAANS...but would not like the management/process in place there (OKR, reviews, career ladder) - Some guys that would love to work for FAANG... but didn't pass the interview (either failed or didn't try)

I think Fast actually built out an office just before COVID hit, they weren't remote. They had bunch videos from office with the employees that they used for recruiting. They only moved to remote with COVID like everyone else did.

Seems like the kept the office these 2 years, probably few million a year. ($85 per sq ft x 125 sq ft per person x 100-450 employees = $1M - $4.7M). A tweet from 3 weeks ago: https://twitter.com/gordoncching/status/1504641710776721409

Re: What software engineers can learn from the rapid collapse of Fast

#314
post #237

Earlier quoted context omitted.

It's always funny to read about crazy overspending on infrastructure and I have a few funny stories myself, but this was far from their biggest problem. For one, we don't know how big those costs were or how much time it would take to wind some of it down. I absolutely hate waste and was always proud of myself when I found ways to shave a thousand here and there off our AWS bill, but it was a bit depressing when I we…

>Early on, the math heavily favors worrying less about infra spend and more about product enhancements that can build revenue. YES! This is VERY true

It is a careful balance. At my last startup we knew we had scale technical debt in our SW. Not something we could fix by tossing HW at the issue. It was all great until we landed that major customer that blew past our supported scale. 6 months of engineering work and a complete stop of feature process. A more careful consideration of the tradeoffs when making them would have saved a huge headache, but no one wanted to look at the issue preferring to ignore it.

Re: What software engineers can learn from the rapid collapse of Fast

#315
post #218

Earlier quoted context omitted.

Good point, I am always surprise when well funded startups hire former big-tech engineers, rather than experienced startup engineers.

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.

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.

Re: What software engineers can learn from the rapid collapse of Fast

#318
Sorry, I read it all the time, but still - how the fuck is it suddenly normal for a fairly standard salary amongst any non exec layer in a company to be ~$250k? I know engineers and developers have to be skilled, but this is insane. No-one needs that kind of money. People in Nepal live for $10 a week. What an insanity.

Re: What software engineers can learn from the rapid collapse of Fast

#319
post #218

Earlier quoted context omitted.

Good point, I am always surprise when well funded startups hire former big-tech engineers, rather than experienced startup engineers.

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.

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.

Re: What software engineers can learn from the rapid collapse of Fast

#320
post #195

Oof, just one of our customers pays about the same as their full revenue, and we're a cockroach team. The real thing here is they're not that surprising. A lot of companies with their kind of funding use enterprise sales to force say $5-10M ARR, but there's only so much VC money can force for a leaky funnel, broken product, and overall incorrect market + fit. I didn't appreciate this until maybe a year or two ago. Va…

> Our new hires are getting paid from customer revenue Money is fungible

Cash flows aren't.
Post reply on HN