Being prepared for the 3d math is pretty easy.

There is a book by Eric Leyngel on mathematics for games and a book on real time collision detection by Christer Erickson.

If you have those books then pick a random page and see if you understand the math behind it. If you can do that 20 times then you'll be fine. If you can't well you might have a gap in your knowledge.

It's not extremely important to memorize every algorithm in those books but generally if you've been working with math for games for a long while you pick up all the tricks behind those algorithms so they are generally pretty easy to derive yourself.


-= Dave

True, but it's easy to forget the basics... I know exactly what a cross-product is but I'd have to double-check the way it's calculated (or work it out from scratch) since I haven't had to code it in about a decade. You don't really need to know how to write code to multiply 2 4x4 matrices, but it's those kind of basics which are likely to be tested in interview or a technical test.

The most important information you need for a technical interview is what you know and what you don't.

The most important ability you need for a technical interview is reason - being able to draw a conclusion about something you don't know based on what you know.

You should feel:
* completely free to respond with "I don't know. [think] If you combine fact X and fact Y, the solution should look something like f(X, Y)."

* mostly free to respond with "I don't know. [think] With fact X and Y, I think the answer looks something like f(X, Y, Z), but I don't know Z." (be clear whether you have no idea what Z even is - you don't know what information you're missing - or whether you know what Z is but can't remember the details - such as mentioning a constant/formula/etc by name)

* somewhat free to respond with "I don't know, and I'm not sure how to figure it out." (perhaps with a mention of how you'd start were your full resources available to you at the time, except when it means repeatedly mentioning a search engine)

Be very sure to make it clear when you are presenting reasoned answers and when you are reciting facts from memory. You'll seem a complete fool if you present a reasoned answer as a remembered fact and happen to be wrong about it, but you'll seem at least somewhat thoughtful and intelligent if you present a false conclusion along with the reasoning, assumptions, and facts that led you there.

"but I'd have to double-check the way it's calculated (or work it out from scratch) since I haven't had to code it in about a decade."

It's amazing how many companies sweat over testing the sort of coding that gets done once a decade, put inside a class and then pretty much forgotten about and ignore things like checking that the candidates can (say) read a spec and derive a sensible OO design from it. The stuff that they'll actually be doing week in and week out.

A friend of mine had a technical interview with some other company once that was pretty funny. He was asked how to manipulate the binary representation of a signed integer in order to negate it. The answer he gave was "flip the bits, and then add 1." They were like "um, no" because answer they were looking for was, "flip the sign bit", which of course is incorrect for almost every modern processor. I just thought it was interesting that these guys asked a question that a) could be looked up by a resourceful programmer in 5 seconds if needed, b) they apparently didn't know the answer to, and c) requires knowledge that they evidently make no use of whatsoever at their company.

The vast majority of technical interviews I've done have useless questions such as these. I've read tons of rants about it, too, so it really seems to be an almost universal phenomenon.

ND is unlikely to do that, though, so I guess my post is rather useless except as a funny anecdote. I interviewed with ND once, and even though I didn't get the job, I felt the questions seemed thorough and fair.

I for one never had a technical interview, as such I would appreciate you sharing the details afterwards.

I had questions such as:

(physics:) If I drop a ball how far will it fall after 5 seconds.
(3d math:) What 4x4 matrix would transform a vector A to vector B.
(c++:) What does private, public and protected mean?

Luckily I didn't have to answer all the questions. Hooray!

I guess you need more info for the first question with the ball. That might be what they were expecting you to say :/

... or not :/

http://answers.yahoo.com/question/index?qid=20090128184018AAJlRqX

Quote: Original post by animator
I had questions such as:

(physics:) If I drop a ball how far will it fall after 5 seconds.
(3d math:) What 4x4 matrix would transform a vector A to vector B.
(c++:) What does private, public and protected mean?

Luckily I didn't have to answer all the questions. Hooray!

I know I'd think too hard on the physics question and end up giving a really smart ass answer like:
"Well, it depends on how high it is from the surface! and it also depends on the gravity! Dropping a ball on jupiter is much different from dropping a ball on the moon!"

and then they'd say:
"Okay... while you're technically right, you seem to be too worried about irrelevant details. Here's the door, have a good day."

I hate technical interviews. I always fail the technical part.