> I guess Leetcoding and Production Engineering really are different things.
This is key point.
They delivered value to the business. That's the only thing that matters.
This is key point.
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.
[1] https://medium.com/@buckhx/unwinding-uber-s-most-efficient-s...
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.
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.
But this bit isn't true during the interview process.
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".