Using an actual problem you solved can also work against the candidate because most problems we encounter in our daily jobs require a lot more time than the standard 45 minutes reserved for an interview (actually only 35 minutes out of 45 because there's 5 minutes of intro/icebreaker and 5 minutes reserved at the end to answer any of the candidate's questions).
So it isn't fair to ask the candidate to solve a real bug or implement a real feature in only 35 minutes unless they've seen something similar before.
This is why big companies like Google are limited to whiteboarding interviews because they need to have an interview process efficient enough to properly vet and filter >1 million applicants Google receives each year.
Personally, I think a better interview process is a pair-programming or work audition for a day. But that is not even close to matching the scale of Google.
Let's say out of a million applications, maybe only 25% are qualified. That is still almost 1000 candidates to interview per day (number of U.S. business days in 2019 is 261; 250,000 candidates / 261 business days = ~957 candidates per business day). Pair-programming or full day work audition will not be able to accommodate 957 candidates every day.
Why did you leave out the part where he admits to name-dropping in that same thread?
Also, you also left out the part where he is actually agreeing with the name-dropper person:
"Meanwhile the points made are relatively sound, 100kLOC C firmware updater set off my BS alarm (assuming 98k of that wasn't some static data tables), and the 700TB MySQL DB while possible is extremely unlikely.. even given a huge JBOD setup which nobody in their right mind would plug into a single server, InnoDB tops out at 64TB per table in the best case, which means OP would need a single database with somewhere around 10 64TB tables"