Sounds reasonable. I was referring more to the gatekeeping type, like a heavy focus on things like balancing trees and recursion for roles that clearly involve neither trees nor recursion.
It's really not that at level. Once at Google you really get the benefit of doubt of clearing a high bar. It's mostly a talk around your work / perf / CLs and then team fit.
what is CL?
Change List: internal Google lingo for what is more commonly known as patch, diff, or pull request in the Open source wold.
If it's anything like amazon they will just be able to look at all of your code for the last N years which is a very strong signal to go along with interview questions. For internal transfers I general focus more on design questions and check the code history for "can they code IRL". Design is harder to check for and also is more dependent on "can we work together to solve problems" which isn't always apparent from just artifacts.
Roles that don't involve recursion? What next, no for loops please - we are developers!!
We hired an engineer once. He wrote a tail recursive function. We had to fire him. We hadn't tested him on that on the whiteboard.
Shrug recursion, where it makes sense, is wonderful and fun. I’m always happy when I find a problem where it makes sense, because those tend to be interesting problems. But in a lot of roles, working in languages like Python and Java, it just isn’t the best option very often.
Yes of course, traversing directories or dependencies is hard.
We are developers, not mercenaries!