This is still a terrible problem. It's simple exactly because it is familiar to the interviewer. It's easy for them to believe that anyone with half a brain should be able to answer it because they've practiced it a hundred times and have forgotten exactly what it is like to not know the answer.
I think coding problems are terrible for almost any interview because the candidate is going to be struggling to find the right answer that will please you. They're looking to avoid causing you to press the big red button that gives them the electric shock and sends them home feeling like they're the most stupid person on Earth for not solving the easiest algorithm problem known to human kind.
I get it though: as people who have to interview potential hires it gets tedious wading through the muck. Personally I don't understand how you can interview someone for a senior position without reviewing their prior work. I also find it rather insulting to assume that we should just separate them from the wheat just like all the other chaff. It's just disrespectful IMO.
I'd done a lot of interviews about a year ago. All but one of them used a programming test of some sort. From fizzbuzz to fibonacci to splitting words, finding palindromes and implementing FIFO queues. I did it all. Some of them I got right. Some I didn't. Even the ones I had practiced and came to know really well... sometimes even then I would blow it. It was a really disheartening experience and I almost gave up programming forever when I started to believe that rigmarole about how any programmer worth their salt should be able to solve these problems without thinking about it.
Which got me to thinking. I can solve these problems easily. I've got my algorithms books, I practice code kata, and I can generally golf some problems off the top of my head and they'll often compile. Why can't I do this in front of other people?
The psychology of the situation is what gets in the way. If you give a candidate a problem they're going to immediately begin to think about what you want them to say. You say it's not trivia, but that's the exact mental process that will happen in most people. Given such a problem I'm certain a good number of candidates I interview would be able to solve them on their own. They might even be able to white board them once we start working together and they get to know me. But while we're in the interview room I'm the gatekeeper with the big red button and they've doing everything they can to keep me from pressing it. That doesn't work for me because I know that's not what I want from them.
When I hire someone I look for initiative, experience, and intuition. I look for people who have taken what they've been given and made something more for themselves. If at their last job they weren't happy with something I'll ask what they did to change it. I also like to test their experience. I ask design-type questions, ask them what they like about their tools, what they don't like, patterns they've seen, how they practice... things like that. And finally with intuition I like to throw up some source code of some problem I'm working on or interesting ones I've come across (and solved) in the past and discuss it with them. I give them an over view of the code, my expectations of it, and then ask them to read it. We walk through it and I get to see how well they can spot bugs, code smell, what they focus on when they see code. IMO, these are the sort of things that I think demonstrate a person's knowledge of programming.
And from my experience I think it's a better way to find good candidates.
Personally I don't understand how you can interview someone for a senior position without reviewing their prior work.
Or what they claim is their prior work. And it really isn't reasonable to only consider candidates with lots of code on GitHub.
I think coding problems are terrible for almost any interview because the candidate is going to be struggling to find the right answer that will please you.
To some extent that's going to be the case for any interaction during an interview. At least with a coding question there's an objective fact as to whether your solution works, as compared to trying to decide whether the interviewer wants an honest or BS answer for what your greatest weakness is.
And finally with intuition I like to throw up some source code of some problem I'm working on or interesting ones I've come across (and solved) in the past and discuss it with them. I give them an over view of the code, my expectations of it, and then ask them to read it. We walk through it and I get to see how well they can spot bugs, code smell, what they focus on when they see code.
That sounds like a fine approach, but it can suffer from the same drawbacks. For example it's very easy for a bug to be "obvious" to you and not to somebody else.
Your first sentence is way off the mark. Obviously an interviewer needs to have intimate familiarity with the problem that they give to potential employees, and have hands on experience implementing it in many variations. But that does not mean that it is unfair to ask this question because you do not know the answer.
This is a lot like fizzbuzz because the instructions for writing the code are simple, straightforward, and should be understandable by any programmer. This is not a question with an answer. This is a SPECIFICATION for a program. If you know how to code, it should be easy to write some code that meets this simple specification.
P.S. most interviewers will give you bonus points for explaining your work as you do it, particularly why you chose to use a certain approach, and what you assumed even though it was not explicitly specified. This is true even if you botch the end result and provide code with severe errors.
After all, that's what good coders do most of the time, write incorrect code with severe errors. The rest of the time they fix their mistakes.
It's not far off the mark. The problem with familiarity is that it's easy to conflate with easy. Once you see the solution to the problem it's hard to believe that it's hard to implement. The solution is so easy, how could anyone worth their salt not see it?
As an example of what I mean: studying math. The majority of the time after reading or listening to an explanation of the problem and walking through an example exercise or two, I the student am left to bash my head against a set of problems. Despite the wishes of the teacher and their best efforts to illuminate the way the solutions to the problems and why they work is not clear. You have to just throw your mind against the wall until you break on through. Then when you do you see that the answer really is simple. And you wonder why it was so hard to see it. Years later you might wonder why anyone cannot recognize how simple it is. You've forgotten what it's like to be a beginner on the other side of the wall.
The other half of the problem I see with using puzzles in interviews is the adversarial nature of the situation. By posing the problem you're triggering a response in the candidate to find an answer. They want the correct answer because they want the job. Explaining to the candidate that they can think aloud and walk through the problem might help to switch them off that track, but I find only a handful of people respond to that encouragement.
I did upvote your comment though because you're right -- most of the time we write incorrect code. Despite our best efforts to write our tests up front and walk through our best laid plans, we still make mistakes. Developing software is a process and becoming a good programmer, to me, means mastering that process and cultivating the wisdom and experience to see the bigger picture.
Trivial problems trigger the trivia response. We learn trivia by rote. Once I got over the initial depression when I had to go through this style of interview process I figured out a way around it. I wrote software to train myself in trivial programs and practiced walking through problems I was unfamiliar with. I started practicing code kata and as a result have been more comfortable with these sorts of problems... but is that really a good indicator of competence? Is it even a useful signal? Of what does it signal at all?
I think coding problems are terrible for almost any interview because the candidate is going to be struggling to find the right answer that will please you. They're looking to avoid causing you to press the big red button that gives them the electric shock and sends them home feeling like they're the most stupid person on Earth for not solving the easiest algorithm problem known to human kind.
I get it though: as people who have to interview potential hires it gets tedious wading through the muck. Personally I don't understand how you can interview someone for a senior position without reviewing their prior work. I also find it rather insulting to assume that we should just separate them from the wheat just like all the other chaff. It's just disrespectful IMO.
I'd done a lot of interviews about a year ago. All but one of them used a programming test of some sort. From fizzbuzz to fibonacci to splitting words, finding palindromes and implementing FIFO queues. I did it all. Some of them I got right. Some I didn't. Even the ones I had practiced and came to know really well... sometimes even then I would blow it. It was a really disheartening experience and I almost gave up programming forever when I started to believe that rigmarole about how any programmer worth their salt should be able to solve these problems without thinking about it.
Which got me to thinking. I can solve these problems easily. I've got my algorithms books, I practice code kata, and I can generally golf some problems off the top of my head and they'll often compile. Why can't I do this in front of other people?
The psychology of the situation is what gets in the way. If you give a candidate a problem they're going to immediately begin to think about what you want them to say. You say it's not trivia, but that's the exact mental process that will happen in most people. Given such a problem I'm certain a good number of candidates I interview would be able to solve them on their own. They might even be able to white board them once we start working together and they get to know me. But while we're in the interview room I'm the gatekeeper with the big red button and they've doing everything they can to keep me from pressing it. That doesn't work for me because I know that's not what I want from them.
When I hire someone I look for initiative, experience, and intuition. I look for people who have taken what they've been given and made something more for themselves. If at their last job they weren't happy with something I'll ask what they did to change it. I also like to test their experience. I ask design-type questions, ask them what they like about their tools, what they don't like, patterns they've seen, how they practice... things like that. And finally with intuition I like to throw up some source code of some problem I'm working on or interesting ones I've come across (and solved) in the past and discuss it with them. I give them an over view of the code, my expectations of it, and then ask them to read it. We walk through it and I get to see how well they can spot bugs, code smell, what they focus on when they see code. IMO, these are the sort of things that I think demonstrate a person's knowledge of programming.
And from my experience I think it's a better way to find good candidates.