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.
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.
Thats not the point. I think it is possibly harmful to focus on recursion in teaching and interviews. (Of course if the understanding is, that you do not use it in real life, then its ok, but still why not test people on skills they need for the job; its like making people jump through hoops for a swimmers position).
Of course I will be embarressed soon, when it is only me who doesnt use recursion in production. :-)
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)
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.