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.

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.

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.

Roles that don't involve recursion? What next, no for loops please - we are developers!!

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!

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.

@ericd, what programming roles don't deal with trees or recursion?

I've dealt with trees in every single domain I've been in, frontend or backend, whether doing "real" programming or building with no-code tools like FileMaker. I've seen admins and accountants build trees and recursion with spreadsheets. I don't think these things are as "gatekeeping" as you imagine.

They're both occasionally the best tool for the job, but I think they're hugely overrepresented in that type of interview. I haven't found that they come up very often in most web development, as an example, but they definitely come up in interviews for web developers.

Since all programming jobs deal with trees and recursion, and if you are already at Google working on another team, wouldn't it mean you already know about those (since our assumption being all jobs deal with those)? Why not just check directly if you were actually useful instead?

It's 100% not true that all programming jobs deal with trees. I worked for years on a major audio/video/screensharing communications SaaS product and never once needed to write recursive code or use a tree structure. Not all code is for processing data. There was tons of code that had very little to do with data structures or algorithms, and much more to do with implementing network protocols, business logic, managing state, abstracting the differences between the various operating systems we had to support, etc...

I was just taking GP's statement and shows that it is not consistent with the rest of his argument.

I don't agree that all jobs have to deal with trees either.

I don't think people understand that when you work at scale, efficient data structures and algorithms actually matter. I doubt there are many positions in Google that don't fundamentally require the ability to understand both.

Trees as data structures are inevitable. Did you have to balance them or perform other nontrivial graph theoretic transformations though?