> It feels dreary because you feel you have nothing left to strive for because you're only measuring your progress by your salary
This.
In your post you mentioned nothing but salary. Sadly I think you might find the hard way that the whole FAANG salary rat-race isn't/wasn't the best choice
Do you mean "not the best choice" in that even if you do come out ahead with $1 mil+ net worth, if you ended up using your time just doing it to make money, you will regret that?
I think this write up is very fair for a solid engineering team. Is it groundbreaking and eye opening? Absolutely not, I’d say the most “hmm I didn’t know that” part of the entire thing was the part about R-Trees and S2. Is that bad? Absolutely not. These guys did the work, logged their performance and are sharing their story.
However, and I believe this is where the animosity in the comments is coming from - given the elitist (for lack of a better term) attitude of these engineering types at these orgs (think of the poster children of the Valley), this is pretty...lacking. I mean, the part about using the Read/Write lock on the second attempt and instead trying to go with an installed package just screams Node.js, and honestly made me chuckle. I guess Leetcoding and Production Engineering really are different things. I genuinely expected more.
> They delivered value to the business. That's the only thing that matters.
Except this is an engineering blog post, so the engineering part actually matters.
And, as demonstrated in the article [1] linked around this discussion, there were better engineering approaches that would have been even "better for business", as being more efficient means lower costs per transaction and/or higher throughput.
It matters for engineers reading the article. It doesn't matter for the business. What they delivered was good enough. Could they have delivered a better solutions? Yes.
Should they have searched for a better solution instead of implementing the one they found? They could have spent some time researching, but you can always miss something. It's better to err on the side of delivering something now with a not-so-good solution than constantly searching for a better one.
I say this as software developer who is obsessed with efficiency. I'm starting to turn around and focus more on just delivering.
>It matters for engineers reading the article. It doesn't matter for the business. What they delivered was good enough. Could they have delivered a better solutions? Yes.
The entire reason they posted the article is to brag about having accomplished intelligently. It's relevant if their approach was actually not so intelligent.
"We encountered a standard problem and applied standard solutions" is like "dog bites man". It's not what they were trying to say with the blog post.
>Should they have searched for a better solution instead of implementing the one they found? They could have spent some time researching, but you can always miss something. [...] I'm starting to turn around and focus more on just delivering.
I think the critics point is that the efficient way was probably also cheaper than what they did, and would take the same time to implement, and have lower recurring costs. It would have just been a matter of using off-the-shelf tools and not reinventing the wheel because that wheel is "complicated" and "obviously our case is special". (Someone did benchmarks, and their case is not special.)
You're right, there is a danger to what-if-ing everything and being stuck in decision paralysis. But the clear subtext is that they merit some kind of admiration for how well they did. If that subtext is wrong, it is worth pointing out.
That's half of the interview process. The other half is convincing your future-peers you aren't a liability. Provide value, get along well, communicate decently.
> They delivered value to the business. That's the only thing that matters.
Although hardware is relatively cheap, 170 QPS on 40 servers for this type of query is astonishingly horrible even from a Business/Product Engineering standpoint.
Boasting this as "highest QPS* engineering achievement is just awkward. It may be better suited for an article on how throwing hardware at problems is cheaper than hiring engineers.
Sure, but could there have been ways to deliver that value with lower maintenance costs and shorter lead times?
If all you care about is gross revenue and never focus on margins and cost of goods sold then you can justify any project as "adding value to the business".
P2P is for decentralization. Why would a centralized entity want to implement a decentralized service when they can create a centralized version of that same service faster, easier, and cheaper?
On server maintain list of ips. Serve ip to the client-peer. If the connection gets spotty replace it or use direct connection to your server. All State exists on your server. Caching may be an anti-pattern depending.
This is kind’ve a bait question. I mean the “no duh” answer (as others have already mentioned) is “whichever you are most comfortable with”. I’m confused as to what other answer you could want
Gonna just chime in and mention Yahoo for Hadoop (yes I know Big Table was Google), and Zookeeper. Great tech started at Yahoo, but they didn’t (unlike today) make too much of a fuss/self-pat-on-the-back about it
Those projects were initiated by Yahoo, but the designs are taken directly from Google papers. Hadoop (HDFS and Map/Reduce) was based on the GFS and Map/Reduce papers. ZooKeeper was based on the Chubby paper.
Qualifier: been here for about 2.5 years and just got a new position at a startup after 2.5 years at [big_adtech_co]
1. Angelist.co for startups
2. Bultinla.com for startups (though anglelist is better IMO)
3. Startups around here are mainly looking for mid/senior as opposed to junior (in my experience), but obviously there are Jr positions out there
4. Look for recruiters (agencies), to help, plenty of agencies around here hungry for devs (obviously you’ll have to sift through the noise to find the signal here)
I think you’ve mentioned a HUGE part of the interview process that interviewers forget: you only have 60 mins. 45 mins if you leave time for questions (which you always should). It’s an incredibly difficult task, and deserves significant effort, as opposed to just thinking “oh interviewing is easy”
Whether a user is auth'd or not can indeed be a form of application state