Live data from Hacker News

What software engineers can learn from the rapid collapse of Fast

newsletter.pragmaticengineer.com

301–310 of 482 posts

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

#301

Earlier quoted context omitted.

May help explain some Meta offers I've seen... 2 years out of college? Sure, come as a Senior! That's not enough? Principal it is!

> Meta > Sure, come as a Senior! That's not enough? Principal it is! Do you mean staff (E6, the level above Senior)? Also, no one is getting E6 offers 2 years out of college.

[deleted]

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

#302
post #149

I never heard about Fast - till now. So my opinion is that they failed in advertising. Maybe they spent too much on engineering but definitely not enough on advertising.

Do you own a major e-commerce site? If no, why should they have spent on advertising to you? They’re a sales company, not direct to consumer.

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

#303
post #270

Earlier quoted context omitted.

This echos my experience at a $100M startup that I worked for and that ultimately failed. HR would tell us we were extraordinary, we would have world-class catering for lunch every day, and yet we had no customers, no contracts, and no money except the investors'. It was a sobering realisation on the damage that can happen when you are submerged in toxic positivity. You forget that companies still need to earn actual…

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. Despite Fast taking the orthodox path.

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

#304
post #196

I was an engineer at Fast for over a year and wanted to clarify a few points-- - engineers did have access to data and could write their own queries to check revenue (but few people did until the article came out). - the strategy leadership decided on was to go after massive enterprise sellers which would, in theory, result in step-change functions in revenue. Many people knew about the low numbers but were willing t…

An overly positive culture is default behavior for most startups. It does appear to be poisonous and there is nothing you can do about it. If you call people out on BS, you are painted as a negative person. Not sure there is a fix.

If you rock the boat, you are toxic and not a team player. That’s how it works at most startups. It’s career suicide to say anything else other than what the team wants to hear.

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

#305
post #223

Earlier quoted context omitted.

> this is done for legitimate reasons What could be a legitimate reason for giving silly titles? If it were a startup, it would be a huge red flag for an auditor.

A title is free to give and can motivate people who want them.

Mightn't titles motivate the wrong kind of people?

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

#307
post #35

I think the most applicable warning for engineers when it comes to the actual work, as opposed to whether one should join a particular startup, is this: > Engineers calculated the load Fast had in needing to serve their traffic. The Fast button was rendered less than 500,000 times per day - rarely needed to ever serve more than a few requests per second. > One of the few warning signs engineers noticed is how Fast sp…

And if you think this is undersized for comedic effect I did ops for a company that went from <1mil to 15mil revenue (with the same sales strategy of targeting lots of small clients) on 4 1u white label supermicros. Two app servers and two MySQL dbs. Never in my life had such reliable infrastructure.

We have 10 petabytes of storage and a ~terabyte scale Postgres instance. It runs on a few racks and we get a respectable amount of traffic. It’s not “WeBScALe” but it’s not peanuts. Better uptime than AWS and our operational expenses are negligible. People forget how insanely powerful and cheap hardware is nowadays. Now, you can buy a 64 core chip for $7k. That alone could handle some serious traffic.

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

#308

Earlier quoted context omitted.

Going after large enterprise sales is a well known trap, and it's just so easy for a startup to spin its wheels for months, and eventually years, and realize that all the efforts got nowhere. The first 1B+ seller is precisely the hardest: Even when you are a relatively well known company, you'll still see reticence in bids if they know you are going to be their biggest costumer by volume. The companies I know that su…

But didn't Bolt succeed (order of magnitudes more revenue) by taking those enterprise customers while Fast was only getting SMBs? I'm currently at a seed-stage startup with a few Fortune 500 companies as users. We're lucky to have a great sales team that can bring that business in. If we're solving a problem for them, they're willing to use us regardless of our size, though they do care about some small particular is…

I work for a competitor to Bolt (and Fast) though not in one-click checkout. To say "Bolt Succeeded" is premature IMO. The federated checkout space is very crowded, with razor-thin margins and huge competitors. If I was going to pick a winner it would be Apple or another org with their network and leverage. Bolt is definitely doing better than Fast ever did by several magnitudes, but still not profitable (though that doesn't seem to matter these days).

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

#309

I think the most applicable warning for engineers when it comes to the actual work, as opposed to whether one should join a particular startup, is this: > Engineers calculated the load Fast had in needing to serve their traffic. The Fast button was rendered less than 500,000 times per day - rarely needed to ever serve more than a few requests per second. > One of the few warning signs engineers noticed is how Fast sp…

This is pretty hilarious to read. I did an interview screen with them at the end of last year for a data engineering position (former coworker was high up on the design side of things and he gave a referral). The first bit of the technical question was just "write a SQL query" and boiled down to doing a group by, count, and limit. The second was something like "what if we needed to return this query from a distribute…

What is a time-windowed hash-map? Just a time based key-value store?

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

#310
post #270

Earlier quoted context omitted.

I joined Fast towards the end of last year. I didn't get as much exposure to the rest of the company as parent comment, but I'll say I saw a weird air of complacency and assumed success. I first ignored my instincts that something was wrong, but as I saw more of how the company operated, I became convinced that the single largest problem the company had was the culture. On the surface, I agree with the parent comment…

This echos my experience at a $100M startup that I worked for and that ultimately failed. HR would tell us we were extraordinary, we would have world-class catering for lunch every day, and yet we had no customers, no contracts, and no money except the investors'. It was a sobering realisation on the damage that can happen when you are submerged in toxic positivity. You forget that companies still need to earn actual…

Well, they don't. The toxic positivity is the product and the investors are the customers.
Post reply on HN