"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".
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?
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)); }
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.
int fctl(int n){ return ( (n == 1) ? n : n * fctl(n)); }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.
My hobby-programming experience suggests...
simple - int add(int a, int b){int result; result = a + b; return result}
recursive - um, I like fibonacci sequences: void fib(int term){if term = 1 return 0; if term = 2 return 1, else return fib(term - 1) + fib (term - 2)}
SQL join: no idea, I haven't used SQL for years. I assume you mean something like for(i = 0; i < table1.length; i++) do {newTable.fullname[i] = oldtable.firstname[i] + anothertable.lastname[i]}
Car as an object: well I guess I'd have a struct with variables for size, weight, power, turning circle and so on, and methods for accelerating, setting direction [steering heading, speed (forward and reverse, or multipliers for forward gearing)] and braking...then I'd have create multiple instances of that object using a table of values...do you make racing games?
I'm not looking for a job, but I'm interested in knowing what sort of answers you were after. The above seems super-simplistic to me, I'd feel nervous they were trick questions of some sort and the obvious answers are actually the failing ones.