Recursion is a fundemntal part of programming, beyond the self-taught junior yes I would absolutely expect every programmer to be able to do it.

You learn it in highschool level programming classes & first semester intro to CS college courses.

Even if they won't specifically need to use recursion in their next job it marks them as someone not serious or about programming.

I'd argue that not being able to program in C marks someone as not serious about programming, but that's mostly because I know and like C.

I didn't say it was the only criteria, just that it is one.

My point is that these criteria are largely meaningless. It all depends on what you're working on. In some jobs, you'll occasionally need to write a recursive function. In others, it's probably a benefit if you can't.

I never personally used it in an interview (that's generally not how I do interviewing) but for someone experienced having not heard of recursion (and it's not such a complicated subject, you wouldn't need much "experience using recursion" to be able to understand it) would mean they haven't really dug into the art & craft of programming.

Just like I'd expect a moderately senior developer to be able to program in procedural, object oriented & functional styles even if they strongly prefer one to the others (and how would they know if they haven't tried all of them?).

Honestly I think recursion is overrated. Does anyone here really write recursive functions in production? I mean it takes up stack space (which on some systems is a systemparameter), creates functioncall overhead and has rarely advantages. Trees have more natural recursive structures, but then you basically always have cache misses making your program orders of magnitude slower than if you can fit the data in a linear structure.

I mean, I would be worried if a candidate is not shy to use recursion that this will blow up software perfomance. (But then probably after hire the senior will tell: dont use recursion here)

I think I've used it twice in production code over the last 20 years. The first was to traverse a directory tree. I wouldn't write it that way now since there is now a standard library to do what I was doing then. The second was to traverse an object's children logging certain pieces of data from the sub-objects. I didn't design that one, I just wrote it so I don't know if there was a library that would have done it for me. Fun to write though.

Generally, developer interviews are just stand-ins for IQ tests since it is illegal to give a candidate an IQ test. Seeing if someone can easily write a recursive function is a pretty good IQ test.

I guess it also weeds out the smart-asses like me who would question why I need to reinvent the wheel.

Finally it all makes sense. I was wondering about it and it also explains how the 'brain teaser question' like how many google engineers do you need to change a lightbulb or were there different questions, anyway, came about.

If you can take a problem where I'm thinking of a recursive solution as the interviewer, but you can come up with an iterative solution and explain why you think it's better, I would give you full marks.

Tell me, how many recursive functions are in your companies code base. (Or course you might not be allowed to tell; but do you know the number?)

No idea, I know I've written a few.

Thanks. How did you take tje stack size into consideration?

I would guess they'd try to use tail call recursion: https://en.wikipedia.org/wiki/Tail_call

I don't know what goes on in the minds of interviewers, but if I had to guess, they use recursion to test the interviewee's ability to reason inductively --- which, of course, is necessary for writing even simple loops. Maybe a question about loop invariants might be a good replacement.

Regardless, yes, I doubt many people write a lot of recursive functions, since the data structures people use tend to either be flat, based on arrays, or neatly hidden away in libraries.

The data structures people use are choosen by people. So it is a choice to have flat datastructures (probably by people how see the diadvantages of recursion)

If you are slapping together web templates with a Python back-end, then maybe not, but if you are automating industrial processes, build tools to improve data handling or work on any technical computational stuff, then absolutely yes. I expect someone to be able to reason abstractly.

There are still plenty of jobs that require excellent technical skills.

I learned recursive programming decades ago in high school.

(Solve the Towers of Babylon with recursive algo).

So, yes. Somebody calling himself a programmer or engineer should be able to produce this.

Someone calling themselves a programmer or engineer really only needs to be able to take the requirements they're asked to implement by their employer and implement them in an agreeable timeframe.

No more, no less. Doing so will get you paid for the activity of programming.

Along the way if you don't know anything, because you can't know or remember everything, you just look it up.

The end.

To me this seems similiar to if you want to call yourself a physician, you need to be able to speak latin. Its true (at least need to pass an exam), but it is only signaling, and no just having a few latin derived labels.