[ggambetta]

Disclaimer 1: Opinions are my own, not Google's.

Disclaimer 2: I interviewed with Google twice, and I was hired twice. This might bias me.

Are we talking about interviews by FAANG, or interviews by startups that cargo-cult FAANG? In my experience as a candidate (twice) and as an interviewer (O(100) times), I was never asked, or asked, the kind of Leetcode question people love to hate.

The questions involve a whiteboard, yes; and they involve reasoning about algorithms and writing code, yes; and I don't see anything wrong with that. I see people putting down whiteboard interviews and people almost proudly saying their job consists of gluing together fragments of StackOverflow code they don't fully understand, and that just won't cut it at a FAANG, so you need to know what kind of candidate you're dealing with.

The most complex my go-to question gets is very basic recursion and very simple caching. A surprising fraction of the candidates I interview, who always have a nice-looking CV and have gone through recruiter and phone screening, can't do basic recursion and basic caching. I'm not asking a trick question, you don't need to remember an obscure factorial formula to find the optimal solution, none of that crap.

Recursion and caching. Table stakes, IMO. You can get away with not grokking recursion and caching for some kind of role where you can copy-and-paste StackOverflow answers and random tutorials, but you probably won't do well as a SWE in a FAANG where you're handed a vague feature request and you're expected to deliver a feature that will be used by a billion people by the end of the quarter.

Not saying that every feature requires recursion, caching, and complexity analysis, but these kind of skills are a good indicator of whether you're the copy-and-paste variety or the build-something-new variety, and it's important to know which one the candidate is.

Now if you're interviewing for a startup whose product serves a small number of users and you're asked the tricky gotcha Leetcode questions for no good reason, sure, that's dumb. But don't hate the good use cases just because the cargo-culters get it wrong.

[cdelsolar]

How often do you use recursion at work? I can count on one hand the number of times I’ve written a recursive algorithm in almost 20 years of coding for work.

[e63f67dd-065b]

Any kind of tree or graph traversal in a moderately functional language? If you’re a frontend dev trying to glue together something that works I can see it, but I would wager that you’ve come across some kind of tree or graph problem that would be best formulated in terms of a recursive algorithm in 20 years of professional work.

Maybe I just have a skewed perspective as a grad student working on filesystem stuff, but I can’t imagine going for years without having to solve some kind of graph problem.

[hnfong]

> If you’re a frontend dev trying to glue together something that works

(Not the GP) I mostly do "backend" work, my limited experience with the frontend (mostly javascript) is that you actually need to deal with (explicit) tree structures more in the frontend. The DOM tree is one, for example. Other UI elements can be modeled quite nicely with a tree structure too.

[ggambetta]

Very rarely, but the point is that I could use recursion if I had to (and perhaps more importantly, that I could recognize the need to use recursion).

[thomastjeffery]

I expect that has everything to do with what language your are using.

If it has tail call optimization and clean pattern matching syntax, then recursion tends to be the more readable (and equally performant) way to traverse data structures, especially anything more complicated than a 1-dimensional list.

These two features (tail call optimization and pattern matching) have seen a surge in popularity over the last decade, notably in Rust.

[steveklabnik]

Rust does not guarantee TCO, just to be clear.

[physicles]

I honestly don’t think that’s relevant.

A whiteboard interview tests your ability to do something you do constantly while writing code: you look at the code you wrote and run it in your head with enough fidelity that you can verify it to a first approximation. If you can’t do that, you’re going to be slower and you’re going to make more mistakes than someone who can.

Small contrived problems like recursion are useful for testing this specific skill. A program to calculate e.g. Fibonacci using recursion isn’t that complicated; to me it seems like table stakes for actually writing new software.

[nunez]

All the time