[zerr]

No, they hire Competitive Programmers - this is a separate specialty, but Google assumes such programmers should be able jump into real world software engineering. They recognize the flaw but so far can't come up with a different way.

[umvi]

> No, they hire Competitive Programmers

More specifically, programmers who spend a lot of time learning how to solve algorithm puzzles. This heavily favors single people who have lots of time to devote to studying such things and disadvantages time-constrained people such as developers with a family life at home.

[zerr]

Yes, ageism is one of the consequences (or reason) of such interview practice.

[username90]

Is there any evidence that older engineers are worse at these interviews than younger ones?

[umvi]

It's not that older engineers are worse at them (from an intelligence standpoint), it's that younger engineers have more time to study for them.

Take a standardized test like the LSAT. Young single people can spend 4-5 hours a day taking practice LSAT exams. Older married people with small children barely have 2 spare hours after work let alone 4 (without neglecting their spouse/kids).

Assuming both the older and younger devs in this scenario have identical IQs, who is likely to do better come LSAT test day? It's a war of time attrition.

[p_l]

Having gone through some of their algorithmic questions, about the only thing consistent between competition programming and their questions was that N was large, often larger than resources of single machine. A very practical issue, compared to many competition problems.

The first stage of the question might be very competition-like, though.

[username90]

Front end, back end, games, data science, embedded etc are all very similar if you ignore the frameworks existing in each domain. So you can become a decent generalist in all of them if you do it bottom-up and become fluent at relevant algorithms first, while if you go top-down and learn each framework then you will never become good at all of them at once since there is just too much complexity in each domains frameworks.

For example, a person who only knows react, angular, vue and node is a specialist and will unlikely be successfully to transfer to a different kind of team. A person who built their own javascript frameworks on the other hand had to build and learn a lot of fundamental concepts which are transferable to any domain, I could use such a person. So personally I strongly favor algorithmic interviews over more specialized ones. I don't care if you learned how to use library X to solve narrow problem Y, no matter how many times you did it.