We never got to the question of recursive or iterative methods.
The most worrying thing is that the LLM were not very useful three years ago when he started university. So the situation is not going to improve.
The reason we ask people to do fizzbuzz is often just to weed out the shocking number of people who cannot code at all.
When the client knows absolutely nothing about it and is not supported by someone competent, they end up employing just anyone.
This applies to both construction, IT and probably everthing.
I think it will be a hot minute before nothing has to be known and all human knowledge is irrelevant, but, specially in CS, there is going to be a tremendous amount of rethinking to do, of what is actually important to know.
Really?
If I were to rank the knowledge relevant to this task in terms of importance, or relevance to programming in general, I'd rank "remembering what a Fibonacci number is" at the very bottom.
Sure, it's probably important in some areas of math I'm not that familiar with. But between the fields of math and hard sciences I am familiar with, and programming as a profession, by far the biggest (if not the only) importance of Fibonacci sequence is in its recursive definition, particularly as the default introductory example of recursive computation. That's all - unless you believe in the mystic magic of the Golden Ratio nonsense, but that's another discussion entirely.
Myself, I remember what the definition is, because I involuntarily memorize trivia like this, and obviously because of Fibonacci's salad joke. But I wouldn't begrudge anyone in tech for not having that definition on speed-dial for immediate recall.
> He was unable to explain to me how he would have implemented the Fibonacci sequence without chatGPT.
An appropriate answer could have been "First, I look up what the Fibonacci sequence is on Wikipedia..." The interviewee failed to come up with anything other than the chatbot, e.g. failed to even ask the interviewer for the definition of the sequence, or come up with an explaination for how they could look it up themselves.
Any difficult problem will take the focus out of coding and into the problem itself.
See also fizz-buzz, which it is even simpler, and people still fail those interview questions.
LLM are very poor in areas such as real time and industrial automation, as there is very little data available for training.
Even if the LLM were good, we will always need someone to carry out tests, formal validation, etc.
Nobody want to get on a plane or in a car whose critical firmware has been written by an LLM and proofread by someone incapable of writing code (don't give ideas to Boeing ).
The question about Fibonacci is just a way of gently bringing up other topic.
I see nothing mention here as something that a human inherently needs to concern themselves with, because none of these things are things that humans inherently care about. CS as a discipline is a layer between what humans want and how to make computers do these things. If todays devs are so far detached from dealing with 1s and 0s (which is not at all how it obviously had to develop) why would any of the other parts you mention be forever necessary given enough artificial intelligence?
Sure, it's fun (as a discipline) for some of us, but humans inherently do not care about computer memory or testing. A good enough AI will abstract it away, to the degree that it is possible. And, I believe, it will also do a better job than any human ever did, because we are actually really, really bad at these things.
I once got that question in an interview for a small startup and told the interviewer: with all due respect what does that have to do with the job I’m going to do and we moved on to the next question (still passed).
If someone tells you not to do it recursively, you should be able to figure that out too.
Interview nerves might get in your way, but it’s not a trick question you need to memorize.
"Let's implement a function to return us the Nth fibonnaci number.To get a fib (fibonacci) number you add the two previous numbers, so fib(N)=fib(N-1)+fib(N+2). The starting points are fib(0)=1 and fib(1)=1. Let's assume the N is never too big (no bigger than 20)."
And that's a problem if they can't solve it.
OTOH about 15 years ago I heard from a friend that interviewed candidates that some people couldn't even count all the instances of 'a' in a string. So in fact not much has changed, except that it's harder to spot these kind of people.
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!"
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.
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".