141–150 of 482 posts
Earlier quoted context omitted.
I believe startups should implement levels once you hire 2 engineers. It's hard to retrofit a system, especially if you're trying to be thoughtful about any pay imbalances.
> 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.
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…
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.
Basically, to move development velocity faster we "load everything". Seems like a really bad idea on the surface. In practice, we only ran into an issue with a single customer that was literally 1000x as large as the other customers. It took about two weeks by 1 engineer to rework a select few calls that were egregiously slow and we were back at it.
----
In other words, even with some arguably inefficient technical decisions, I've rarely if ever seen performance issues at early stage startups.
Earlier quoted context omitted.
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.
> 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.
Earlier quoted context omitted.
> We get job candidates with high competing offers for companies I know to be rotten inside, I fell for this trick once when I was younger, but never again. As it turns out, when companies are bleeding talent and struggling to hire they suddenly find ways to pay well above market rate. You can have a fancy title, too! We had a competitor do something similar at a prior company. I would tell candidates that we can't m…
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!
It's hard to tell the difference between "stop the bleeding" title/pay inflation and "aggressively competing for talent" inflation.
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…
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.
Spending time on needless infra (scale you don't need, AI you don't need, infra you don't need, things could have been postgres as in this case, ...) both prevents building useful stuff ($-generating features/experiences/...) and increases operational cost (maintenance, debugging, ...). Both the lost revenue growth and the increased costs are compounding. Imagine a maniac steadily piling on a bit more technical debt every day and eat a bit more of the seed corn every day instead of growing it.
A good phrase for this is "playing house": http://www.paulgraham.com/before.html
> 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 employee happiness was a priority.
What's not to like here ? Working for huge amount of money, in a company whose culture puts employees happiness first, and provides an amazing working experience.
Management did "all the right things" : remote ? check ! competitive salaries ? check ! amazing experience working there ? check ! employees-first culture ? check !. Why would you even need to look elsewhere.
And when it all crashed and burned, the feeling is :
> There are people who are frustrated and disappointed with company leadership, and how the bust came out of nowhere.
Trick is that it did not come out of nowhere, people just chose to look away. It's easier to blame management (which is definitely at fault as well !) than to say "I was paid way too much compared to the actual value I was providing". When you are paid $200k / year, you should easily be able to justify that your work generates more than several thousands of USD alone, if you are unable to do that, you need to have a conversation with your mirror as well - or just accept the fact that you are benefitting from a system, which may crash and burn if too many people are in this situation, or keep on living if you are an exception.
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…
I run a company in the e-commerce tech space. We handle ~1M requests per day and run it all on a few medium sized VMs on Google cloud for like $1k/mo.
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…
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.
Programmers love to add the latest tech to their resume then move on to a new position within ~18 months