3 ms·

Why? It looks like a reasonable interview question.

swat535 2y ago
I suppose it depends on the position, but if your company is building CRUD apps with Postgres and you're asking candidates about Fibonacci, you're wasting both your time and, more importantly, the candidate's time. Instead, you're better off focusing on relevant topics like SQL, testing, refactoring, and soft skills. These "clever" questions are pointless. They either serve to stroke the interviewer’s ego: "Look, I know this CS 101 problem because I just looked it up!", or to create a false image of brilliance: "Everyone here can invert binary trees!"
- brulard 2y ago
  I don't think the point of the question is "do you even know wha fibonacci sequence is?". If candidate didn't know what exactly it is, I have no problem with that. If I explained to him simply the nature of the sequence and he couldn't code it, I wouldn't expect him to be a worthy addition to the team. Recursion is everywhere, SQL, UI, refactoring, data processing, etc. But I agree you can hire a shitty programmer, because his soft skills are amazing. I worked with people that wouldn't contribute much to the code, but created a culture and improved processes in the company. But you should be aware that you are not hiring for a coding position then.
- genewitch 2y ago
  > They either serve to stroke the interviewer’s ego that's why i'd ask about duff's device. I often admit i am no programmer or developer, here on HN, and that's true. I've only ever implemented recursion when it's part of the pattern or when "learning" a language. my understanding is that recursion is great for tight, small loops, where you need to do say 0<n<10 loops. But if you can't guarantee the tight loop every time, i.e., if it is a dynamic part of business logic or whatever, then you run the risk of blowing up the stack, or heap, or whatever it is. I don't remember which, and i could look it up; but my point is most developers don't need to know if the stack is at risk rather than the heap if your recursive call ends up being called a lot of times. But i really would ask about duff's; me and a friend came up with a use for duff's device maybe 2005 or 2006, and tested it, and published it as part of a forum argument; but i am curious if anyone else could "come up with one" or "remember one" that isn't the "de-facto duff's device demonstration".

I suppose it depends on the position, but if your company is building CRUD apps with Postgres and you're asking candidates about Fibonacci, you're wasting both your time and, more importantly, the candidate's time. Instead, you're better off focusing on relevant topics like SQL, testing, refactoring, and soft skills. These "clever" questions are pointless. They either serve to stroke the interviewer’s ego: "Look, I know this CS 101 problem because I just looked it up!", or to create a false image of brilliance: "Everyone here can invert binary trees!"

brulard 2y ago
I don't think the point of the question is "do you even know wha fibonacci sequence is?". If candidate didn't know what exactly it is, I have no problem with that. If I explained to him simply the nature of the sequence and he couldn't code it, I wouldn't expect him to be a worthy addition to the team. Recursion is everywhere, SQL, UI, refactoring, data processing, etc. But I agree you can hire a shitty programmer, because his soft skills are amazing. I worked with people that wouldn't contribute much to the code, but created a culture and improved processes in the company. But you should be aware that you are not hiring for a coding position then.
genewitch 2y ago
> They either serve to stroke the interviewer’s ego that's why i'd ask about duff's device. I often admit i am no programmer or developer, here on HN, and that's true. I've only ever implemented recursion when it's part of the pattern or when "learning" a language. my understanding is that recursion is great for tight, small loops, where you need to do say 0<n<10 loops. But if you can't guarantee the tight loop every time, i.e., if it is a dynamic part of business logic or whatever, then you run the risk of blowing up the stack, or heap, or whatever it is. I don't remember which, and i could look it up; but my point is most developers don't need to know if the stack is at risk rather than the heap if your recursive call ends up being called a lot of times. But i really would ask about duff's; me and a friend came up with a use for duff's device maybe 2005 or 2006, and tested it, and published it as part of a forum argument; but i am curious if anyone else could "come up with one" or "remember one" that isn't the "de-facto duff's device demonstration".