If I was a FAANG hiring manager, I’d tear up any resume from these get rich quick dollar chaser wannabes
What software engineers can learn from the rapid collapse of Fast
171–180 of 482 posts
Re: What software engineers can learn from the rapid collapse of Fast
#172Earlier quoted context omitted.
> Sounds like the engineers were just entertaining themselves with shiny toys rather than solving the problems they actually had. This is often the problem when hiring too fast. New employees don't have context or direction but generally people try to be productive, so they start inventing work. Management team is new too, and not built up either direct or handle the bandwidth and they also are lacking the direction.…
I find it absolutely crazy that companies do this. My company's strategy is get one extremely solid person across all our verticals (Android / iOS / Backend / Infra) to minimise communication overhead and maximise iteration speed (since we throw out half the code we write anyway). I would be very hard pressed to hire more than 2-3 people in each role even if we were offered 10s of millions.
> My company's strategy is get one extremely solid person across all our verticals (Android / iOS / Backend / Infra) to minimise communication overhead and maximise iteration speed (since we throw out half the code we write anyway).
but ... but ... that makes sense ...
I have found that having fewer good engineers is much better than lots of bad ones.
That approach is treated as heresy, in today's tech industry.
Re: What software engineers can learn from the rapid collapse of Fast
#173Earlier quoted context omitted.
Lol. L6. Look no further folks. This guy Dominic was clearly LARPing a startup. Leveling frameworks before traction is a joke to me.
Even startups benefit from job titles and hierarchy. Even startup employees benefit from a visible promotion path. Remember, they had hundreds of employees. Not just a couple people in a small office somewhere. Most likely, the levels corresponded to pay bands and helped determine where people fit into the seniority hierarchy (such as determining who receives sensitive daily information updates)
You are 100% right — for late stage startups where you would normally see 500 people.
At the Fast stage, the only viable promotion path is ship work that impacts the business or close deals that bring in revenue. The promotion levels game is something you play in larger organizations to engineer a rat race for people because it turns out they really like that. But no, a startup does not benefit from hierarchy quite the opposite in fact. That crap is all overhead it’s necessary as you grow but actually detrimental to your success.
Re: What software engineers can learn from the rapid collapse of Fast
#174Earlier quoted context omitted.
> Sounds like the engineers were just entertaining themselves with shiny toys rather than solving the problems they actually had. More like, sounds like management was trying to get as much money as quickly as they could from their VCs before it all imploded. The engineers aren’t at fault that management didn’t have a real product or vision.
We all know plenty of engineers who want to build things for inappropriate scale. The company was a disaster, but part of building a disastrous company is hiring the engineers who want to make everything webscale and have no sense of pragmatism.
> The company was a disaster, but part of building a disastrous company is hiring the engineers who want to make everything webscale and have no sense of pragmatism.
I mean, the engineers held up their side of the bargain. They were hired for webscale, the company got webscale…
Now, if this was a more strategic startup, that had tried to hire pragmatic engineers, that insisted on webscale, I would blame the engineers. However, in this case, I think it’s pretty clear that the engineers did exactly what they were hired to do.
Re: What software engineers can learn from the rapid collapse of Fast
#175I 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…
The TailScale folks caught a bunch of flak for their "do things that don't scale" approach to databases. But, honestly, most startups would be better off following that approach than what Fast did. Sounds like the engineers were just entertaining themselves with shiny toys rather than solving the problems they actually had.
> The TailScale folks caught a bunch of flak for their "do things that don't scale" approach to databases.
I've seen this repeated on HN, but never saw the alleged flak.
Re: What software engineers can learn from the rapid collapse of Fast
#176> every small business needed custom engineering work to be done, making integration slow
This is the killer for SMEs. If you're not selling to enterprise, find a solution you can whitebox and quickly ship with minimum customisation.
Re: What software engineers can learn from the rapid collapse of Fast
#177Earlier quoted context omitted.
> startups should implement levels once you hire 2 engineers I think OP is cracking a joke about a $600k company having six levels of hierarchy.
Nobody wants to be a level 1. So the real level 1 was probably L4.
L1 is junior data center tech and junior helpdesk.
Re: What software engineers can learn from the rapid collapse of Fast
#178The key informations are here : > Fast offered $200-240K/year in base salaries with full remote work > Sign-on bonuses were common and large. Those who asked for almost always received sign-on bonuses of $20-50K as a one-off payment > Equity issued was lavish and presented as potentially life-changing > A good part of people are echoing how working at Fast was an amazing experience. People liked the culture, and how…
>When you are paid $200k / year, you should easily be able to justify that your work generates more than several thousands of USD alone
Revenue per Employee used to be a real metric that people used. Of course, P/E ratios used to be sane as well.
Re: What software engineers can learn from the rapid collapse of Fast
#179Earlier quoted context omitted.
I find it absolutely crazy that companies do this. My company's strategy is get one extremely solid person across all our verticals (Android / iOS / Backend / Infra) to minimise communication overhead and maximise iteration speed (since we throw out half the code we write anyway). I would be very hard pressed to hire more than 2-3 people in each role even if we were offered 10s of millions.
> My company's strategy is get one extremely solid person across all our verticals (Android / iOS / Backend / Infra) to minimise communication overhead and maximise iteration speed (since we throw out half the code we write anyway). but ... but ... that makes sense ... I have found that having fewer good engineers is much better than lots of bad ones. That approach is treated as heresy, in today's tech industry.
Perhaps the thinking is that it's easier to hire multiple good-enough programmers to get dependable productivity, and to replace one if something goes wrong. In the extreme case, if a company has one programmer who is very good when they're working at peak productivity, but then they have a period of low productivity for whatever reason, that company is in trouble. I've been that person.
Re: What software engineers can learn from the rapid collapse of Fast
#180Earlier quoted context omitted.
Lol. L6. Look no further folks. This guy Dominic was clearly LARPing a startup. Leveling frameworks before traction is a joke to me.
I worked at a company where the founder manufactured an inane 13 level hierarchy (at seed!!!). We had two engineers, all level one, lol.
So there were 14 employees total, if I had to guess? /s