Your fibonacci algorithm is crap. You're tree-recursively calculating the exact same values over and over and over and over again. Just try running it sometime on a large n if you want to test your computer's ability to stall and ramp up the cooling fans.
"do you make racing games?"
That's a question to ask first, not second. Maybe he's making a "Pimp My Ride" style game where the actual driving part is less important but you need detailed modeling of the seats and the ability to add a bunch of random shit to the interior of the car. Maybe he's making a CAD tool for people to do body design, so you need to be able to do computational fluid dynamics on it and test weight balances, but also be able to visualize it in high resolution to see if it looks cool and to print mockups for focus groups to say "this looks like a kickass car".
Agreed, but this is the very question I'm getting at - does Flemlord want to know the quality of algorithms someone naturally comes up with, or is this just to screen out the total BS artists?
Hence my mention above of how it feels like a trick question. I really don't know whether the interviewer wants the autistic-but-informative answer or the quick of-course-I-know answer. Trying to guess what sort of answer you are seeking induces mild panic in me: I don't know you, but if your response in an interview was 'what a crap algorithm' I'd be thinking 'this guy is a bit Machiavellian...'.
I mean, I can think of a much faster way (than this) to get a given term in the fibonacci series using a loop, but this one recurses, which was what was requested - I had to quickly choose a problem domain in which to demonstrate it. Towers of Hanoi would have been more impressive, but I don't know if I could just rattle that off correctly, verbally. See what I mean?
If I was interviewing you (I've never interviewed anyone) and you gave that fibonacci algorithm, I would probably say, "Hmm, and how does that algorithm perform? Can you think of a better one?" If you said "its performance is crap, storing the previous two results and using iteration is better", I'd be happy. If you said "exponential" and "linear" instead of "crap" and "better" you'd get bonus points. Volunteering that information at the outset would get more bonus points because it shows that you really care and that you don't even feel comfortable writing down an exponential-time algorithm without loudly warning everybody they shouldn't use it.
The standard interview question is "write a function to solve this problem which has an elegant recursive solution", not "think of a recursive function". But if you do want to think of a recursive function, try factorial.
int fctl(int n){ return ( (n = 1) ? n : n * fctl(n)); }
(Don't use that code in an interview. It's questionable style for C, and the ternary operator is scary to people.)
I was asked to write a fibonacci function once, and I actually said, "you can do this recursively but the performance is awful" and wrote an iterative solution.
The point of an interview is for you to show off. If you start going on and on and on and on about unnecessary details the interviewer might stop you, but if you launch into a talk about the space and time properties of recursion vs. iteration and show some judgment for how to use recursion and how not to use recursion, then I know how knowledgeable you are.
Heh. Our actual interview question is similar but we ask them to add instead of multiply. We ask them to add up all positive whole numbers equal to or less than x. Good developers (who make it to the next round) bang out the answer in literally 30 seconds. Ok developers (who still make it to the next round) usually struggle for a while, maybe implementing it non-recursively first. The other 70% just type nonsense until I cut them off after 15 minutes.
If somebody makes a mistake I tell them and give them hints until they fix it. Well... it depends on the magnitude of the mistake I suppose. If they're not even in the right ballpark I keep my mouth shut.
Thanks for your considered and interesting reply. I agree that a discussion is much more informative (for both parties) than a rapid-reaction test, but with the rise of a speed-dating approach to business in recent years it's hard to know what people are looking for, sometimes.
Your better employers will thoughtfully talk with you though, and this is a good way for you to pick a good employer. That's an unseasonably optimistic attitude during this recession though.
"do you make racing games?"
That's a question to ask first, not second. Maybe he's making a "Pimp My Ride" style game where the actual driving part is less important but you need detailed modeling of the seats and the ability to add a bunch of random shit to the interior of the car. Maybe he's making a CAD tool for people to do body design, so you need to be able to do computational fluid dynamics on it and test weight balances, but also be able to visualize it in high resolution to see if it looks cool and to print mockups for focus groups to say "this looks like a kickass car".