Firstly, the OP didn't say that you had to do what they did to get through the interview, they said what they did. If you think you don't need to do that much work, great, go for it and hope for the best. However, if you really want to work somewhere fang or not, the preparation might well be the difference between getting in and not. Too many recruits I have interviewed barely bothered going onto our website - are they really going to be bothered in the job?
Secondly, these kind of posts always start the "technical interviews are terrible" bandwagon. As someone who has been on both sides of it, on the one hand, I was disappointed when I didn't make the grade at one agency but I have also wasted countless days of my life on candidates that claim to have what it takes but really don't. They might have LOTS of experience but objectively score very low in ability - honestly, people who take 5 minutes to write a 1-liner to split a string on a comma! They might be young and keen, but again, that in itself doesn't really count either way - unnaturally gifted or just over confident?
Multiply that by 1000 for larger companies who must have hundreds or thousands of applications and how are they supposed to separate good from bad? By taking your word for it? By assuming that because you have worked for 10 years in the industry that you must be really good? Because you used to work on XYZ at a previous company? Unless you wrote it single-handedly, it is hard to know what value you added personally. They will test you in the best way they know how.
Also, the testing is not just about being able to do what you and they already do, that is not worth $150K, they want someone who is flexible, a fast learner, someone who can approach problems creatively, who can tackle something that has not been done before without needing someone else to tell you how. Confidence is good unless you are unnaturally gifted and things like working well as a team etc. are minimum requirements for most organisations, not nice to haves.
The technical tests then broadly fall into two categories - 1) find out exactly what you know about e.g. scalable systems by asking very specific questions. If you don't know how redis differs from SQL or the file system for caching, you are not suitable for a senior position in a company that operates only at scale. Most interviewer probably won't care if you have forgotten a subtlety or detail but phrases like "I know they are different, I can't quite remember why", don't sound so great. 2) The really strange questions where they are not looking so much for an answer as an approach - the one I heard about was, "how much would you charge to clean all the windows in Seattle". Any decent engineer should be able to reduce that to a set of assumptions or questions and then produce some kind of mathematical model in exactly the same way as being asked to write a complex program to serve one of your fang companies.