The problem I see with your question is that you have a bias towards a solution.
"The goal of that question from my perspective is to watch them solve a problem that requires recursion"
I wouldn't use recursion for my solution. It takes up stack space for no reason. If I'm going to be allowed to use more space, I'd just loop through the list, add them to a set, and check if I've already seen it. No recursion, but extra space. Is it more space than another stack frame? Depends on the type of set I'm using. But at least I know I won't blow up the stack (maybe the heap :-)
Since you are asking for opinions from others, I'm going to assume you wouldn't be upset with me solving it this way. So am I less of an engineer because I didn't immediately go for recursion?
With that said, everyone has a baseline - answers they expect to see. But everyone has to keep an open mind.
My company is trying to come up with a corpus of questions and answers to those questions at the junior, normal, and senior level. I've voiced my opinion that it is a slippery slope. If you get someone who isn't a skilled interviewer, and the interviewee doesn't use one of the prescribed 3 answers, what happens to that candidate? Granted it is one data point in the loop, and not the only data point. But as I stated, it becomes easier to be "lazy" during the interview.
>So am I less of an engineer because I didn't immediately go >for recursion?
No, not at all. a stack is a stack, whether it's the call stack or one you maintain in code.
Its not the recursion that's important to me, it's holding a problem of moderate complexity in your head in order to be able to come up with a solution. Problems that lend themselves to recursion seem to present a bar that some engineers struggle with, and others find easier, in my anecdotal experience.
I know I said recursion is important all over the place, clearly my thinking is sloppy on this and needs to improve.
I have this idea that there is a class of problem, that lends itself to recursion, that separates the wheat from the chaff in some ways. maybe that's nonsense.
What I really want to test for is the ability to juggle abstractions while working through code problems. there's probably a better way to do it.
Thinking about this corpus of questions and answers, I guess the common idea of fixing broken code might have a bit more merit because it removes the risk of an interview focusing too much on judging the approach and turning it into a trivia contest (have you seen this before and do you remember how to do it).
I'm going to assume your answer is "on the job performance". If not, this is going to be a difficult conversation, and I'd ask why you are trying to measure for something you aren't going to be paying for.
The best predictor of on the job performance is ... on the job performance. Everyone but the most junior person has experience. Look at that.
All of these exam type questions usually rely on knowing a trick, or being recently well versed. I TA'd a graduate course in Algorithms. That's rather relevant, I would think, since you aren't offered that if you don't have ability. Yet you know the last time I've done, say, dynamic programming? It's been awhile. I know about it, I know when to decide whether to pull it out, but ask me to do it, in a high pressure interview (all interviews are high pressure), and well, I'll probably fail. I'm working on other things like Bayesian inference. Bet you'd fail doing that stuff, even though it is just simple multiplications and such, when you get down to the implementation. Unless, of course, you are working on that sort of stuff right now.
I find the situation in SV somewhat ridiculous. To go out and interview means a lot of prep. Google recommends spending a month reviewing algorithms before applying. You know, I have an actual job, and I have open source side projects, and I have a family, and hobbies, and an old dog I want to spend all my time with. It is trivial to find out my skills by looking at what I have done and asking me questions about it. Have me give you a 1-2 hour tech talk, for example (I like public speaking, most don't so that is not a universal solution). Have me write some code with you, if you must. I work at a very high level, but I am not necessarily 'clever' at seeing the right trick in 10 seconds under pressure in an interview.
Also, how important is that sort of thing, really? For some jobs it is, undoubtedly. If you want me to write a load balancer for your cloud infrastructure, there are some algorithms I need to understand. Even then, not knowing something now is not evidence I can't do the job. I can learn - it's how I've done everything up to now. I can learn your thing too. More importantly (to my mind) - am I a hard worker? Can I mentor others? Can I lead a team? Can I put a schedule together, and recognize when that is appropriate and not appropriate? Can I make a budget? Can I talk to clients? Do I meet my deadlines? Do I solve problems - not implement the cards in this sprint - but see friction of some sort at work and engineer a solution? Do my peers like working with me? Do I get shit done? Is my code maintainable, readable, modular, commented? Can I write? Can I teach? Can I work with the CEO?
I've been to so many interviews where they don't even try to learn any of that latter stuff, where they show no interest in what I have done, where they don't try to figure out if I can do the actual job they are doing, but are deeply interested in if I can program a smart pointer, from scratch, to some arbitrary set of requirements. It is all just deeply puzzling to me.
I understand what you mean about ridiculous SV interview practices. And your point that all we should really be measuring is on the job performance is an important one.
All I'm really going for is to ask someone to write some code live, on their laptop with their tools, so I can watch how they debug, how they think through things, etc. I want the problem to be hard enough that the person has to model execution in their head and that it's challenging to do so.
I have found that there are people who can code decently well but get badly stuck when the complexity hits a certain level. I'm trying to not hire them in senior positions.
For example, I had a recent project where we were analyzing user data and producing a bunch of edges representing potential connections detected between users, as a way of sniffing out fraud rings.
One feature associated with this was a banning UI, allowing loss prevention types to navigate through the graph, select groups of users according to certain criteria, and generally look for patterns that are evidence of fraud rings manually, to supplement the automatically generated analysis.
There are a lot of front end people who will go into brainlock on this kind of thing. I need to make sure I have some people around who don't.
When making senior hires, I want people who can write code for this sort of thing without making a huge mess or just getting stuck for weeks.
Presenting a real sample from a problem like this needs way too much context though.
I'm going to keep thinking about how to precisely define the type of task that i'm really talking about here. My fuzzy definition about ability to model execution of X complexity in one's head is obviously weak and probably flat out wrong.
The best questions have levels. Speaking to recursion specifically I had Flood Fill as a question the last time I interviewed. I solved it with recursion as it's the more ... "elegant" method. Then the interviewer asked about other ways to solve it, which went to iteration. After which we could briefly chat about stacks, bounds checking, etc.
So when it comes to "junior, normal, senior" they dont have to be different questions, in my opinion. Opened ended questions give flexibility for the candidates inclination and complexity in answering. Depending on how the candidates doing add increasing complexity, discuss improvements, or try again with a simpler setup. Something like Word Count can go many different ways; If they like C talk about char and buffers and syscalls. If they like javascript, well then you can make fun of their tail call recursion.
"The goal of that question from my perspective is to watch them solve a problem that requires recursion"
I wouldn't use recursion for my solution. It takes up stack space for no reason. If I'm going to be allowed to use more space, I'd just loop through the list, add them to a set, and check if I've already seen it. No recursion, but extra space. Is it more space than another stack frame? Depends on the type of set I'm using. But at least I know I won't blow up the stack (maybe the heap :-)
Since you are asking for opinions from others, I'm going to assume you wouldn't be upset with me solving it this way. So am I less of an engineer because I didn't immediately go for recursion?
With that said, everyone has a baseline - answers they expect to see. But everyone has to keep an open mind.
My company is trying to come up with a corpus of questions and answers to those questions at the junior, normal, and senior level. I've voiced my opinion that it is a slippery slope. If you get someone who isn't a skilled interviewer, and the interviewee doesn't use one of the prescribed 3 answers, what happens to that candidate? Granted it is one data point in the loop, and not the only data point. But as I stated, it becomes easier to be "lazy" during the interview.