P.S. one of the better interview questions I heard was, “Have you ever experienced any problems with zbuffer rendering? Discuss.” the answer can give you a good insight into the individual’s experience. The guy who told me about this question simply answered “no”, he didn’t get the job. It’s probably a bit dated now, this was a few years ago. Things are a bit more advanced now.
[This message has been edited by dorbie (edited 01-27-2003).]
I think that John expressed it pretty well.
But I don’t see why some people are saying not knowing what gimbal lock is, isn’t surprising. It’s all over the net, in every discussion forum about 3D graphics.
Of cource, if you don’t know english then you haven’t seen that term, but for sure, you have encountered the problem as you began experimenting with 3D.
I have had one interviewer ask me if I know what Inventor was. I said yes and also said I haven’t used it. She said that’s good because some other people she interviewed havent heard of it even.
A few random questions can tell you if a person is a “3D graphics expert”. In my book, that means you know popular things + much more.
Mayeb that guy who got the z-buffering question was really a modest genius. “Have YOU had any problems with Z-buffering?” The guy might haev thought “well… no. I mean, there are issues with z-buffering, like z-fighting… but i wouldn’t call it a problem because I can overcome it by shifting the near plane forward, and if that becomes a problem then I can do multipel render passes with different z-passes… so… what kind of problems do I have with it? None, really” and he asnwers “no”
My personal preference is to get interviewees to discuss what they know about various graphics-related topics, starting with generalities, then moving toward specific probing questions based on what they seem to have experience with.
Still, there are plenty of “cold” questions that any potential candidate needs to know. I don’t think gimbal lock is one of them, but sometimes seemingly random questions are the best way to identify the boundaries of a candidate’s knowledge. Sometimes I ask people about perspective correction, but I consider it bonus points if they can actually explain it. 
Some questions are extra-credit, some (very few) are sudden-death.
Cass
Just to inject some context into the discussion…
A “3D graphics expert” could range from someone doing microcode at Nvidia to John Carmack to Bruce Naylor to someone with a “doctorate in quaternion mathematical formulations” to “guys who work on algorithms for rendering liquid”. So, dorbie (et al.) has a point.
However, I’m talking video games – where broad knowledge is more important than deep knowledge. Sorry for being vague. I just assumed…
BTW, only one of the above experts would probably get hired.
John, in this particular instance that wasn’t the case, the guy was an intern back in the UK and was interviewing for his next gig, I explained why his response was such a … career limiting move. I thought at the time it was a very good question, one almost any good ‘real-time’ graphics programmer would ace. FWIW if I were personally asking any question and got a terse answer or it drew a blank I would drill deeper to see if I could extract any semblance of understanding. I’m with Cass on the old discussion of past work & experience.
I do agree jambolo that graphics is such a diverse field that there are many areas someone could specialize in and be an expert.
V-man, I have a good text book called “quaternions and rotation sequences” and many good graphics books. None of them mention gimbal lock AFAIK. I can google the term and it might find some hits on the web but you could understand the issues without encountering that phrase. The only time I’ve encountered it was at Marconi 10+ years ago. FWIW my quaternian book mentions the Euler angle issues in section 3.10 Singularities in SO(3). Maybe I should ask about that in an interview. Even at this the actual problem w.r.t. dynamic motion models is only related, it’s the flipping of the axis of pitch through the vertical that can cause an actual ‘lock’ in bad software (in my experience), you actually need to write that broken code, it’s not a given that your Euler angle model will break like that, you need to try.
P.S. aw crap, the quaternion book has a small note in the margin right there in section 3.10 mentioning “Gimbal Lock” :-). It does relate it to mechanical systems.
[This message has been edited by dorbie (edited 01-28-2003).]
If someone had asked me about gimbal lock only a year ago I wouldn’t have known. But the concept as such had passed my mind long before I started with doing serious 3d programming.
I would ask them if they had experience in per pixel lighting, shadowing, pixel/vertex shaders. Ask them to describe the shadow volumes and mapping techniques, what are the advantages and disadvantages of each. Do they have examples of where they have implemeted these.
I would ask them what terrain rendering method they would use in a flight sim to make best use of current hardware.
It’s one thing for someone to program something but are they able to fine tune it for maximum performance. I would ask them about the fastest way to render static geometry, what extensions they might consider using etc. Would they use a different method for dynamic geometry.
Of course it is important you know the answers to the questions you are asking and often there is not only one correct answer 
I would also ask to see code to check the style is ok, enough comments etc.
I would be interested to know how they go about problem solving. Would they use the internet, which sites, what other resources might they use?
At the end I might ask a question about how soft shadows could be acheived and what other things might soon be possible in realtime graphics. This would show whether they are capable of creative/forward thinking and not just happy to copy existing techniques.
As has been said before, probably the most important thing is to see previous work and to determine that it is their OWN work.
You may want to ask about different areas of 3D graphics depending on what type of games you are making. I am asuming you have other programmers to deal with AI and physics? What about collision detection?
I agree with dorbie etc. on the gimbal lock question.
[This message has been edited by Adrian (edited 01-28-2003).]
Ofcourse you should ask him some basic stuff like :
What’s the difference between a vertex and a vector.
or : How do you normalize a vector.
If he/she doesn’t now those basics you shoudn’t even proceed with the interview. 
[This message has been edited by P88_Razor (edited 01-28-2003).]
“I think the fact that he had never heard of gimbal lock is very telling. How many people on this board have never heard of gimbal lock?”
I got asked that question for the position i’m working at now doing 3d software developing. It is a valid graphics related question and is a great quesiton to ask in an interview (according to one of my old 3d Graphics professors as well as my current boss)
Additional questions that may not have posted already are (these are generally applied math questions but should generally be known by anybody who works in 3d graphics development):
How do you represent a camera transformation?
What is a projection and what is the difference between orthographical and prospective projections?
What are homogeneous coordinates and how do you convert them into cartesian coordinates?
What is the difference of a post multiply and premulitply when dealing with matricies? (for example generalize the different effects that the following two statements have: RotationW vs. WRotation, where rotation is a rotation matrix and W is a matrix that is not axially alligned.
What is a dot product and how is it useful in 3d graphics?
What is the viewing frustrum?
Additionally you could ask them about illumination models(specular, diffuse), shading (flat vs. gouraud)…etc
Walrus, do you realise you posted an almost identical response earlier? I thought it looked familiar
I think I would be insulted if I came into an interview for a non-entry-level graphics prgramming position and was asked if I knew the difference between a vertex and a vector.
If it were entry-level, I’d probably just wonder about the quality of the interviewer.
An oral test for knowledge may be a good first-pass screening technique, but I’d probably only use it if the resume were dubious or I were hiring an intern (who could, realistically, not have a clue). Additionally, I’d handle any such test over the phone instead of wasting my time and the candidate’s time getting them on-site for an interview.
I like a lot of the open-ended questions presented by others in this forum.
‘Technical’ questions I would ask:
What was the hardest part?Important non-technical questions:
These non-technical questions will give you a better sense for how ‘retainable’ a candidate is. Nothing is more frustrating than hiring someone and training them up and have them jump ship at the first opportunity.
I would not feel constrained to a script. I would flag 3-4 technical questions as ‘must ask’ and ensure those were covered during the interview. I would have someone in the project group the candidate would be assigned to spend 15-20 minutes in a semi-formal interview without my presence.
I would probably give a silly short coding test to see how the applicant’s mind worked and learn about their style.
You should count on HR to do the kind of ‘is this person clueless’ screening that it sounds like you want to do. If you don’t have an HR department, then you should still make sure to do that screening /before/ the candidate comes in.
deep breath
My post is too long to be 2 cents, so I’ll say that’s my $1.50… of course, that’s in Canadian, so my opinion may be worth more or less depending on your exchange rate and cost-of-living index.
Have fun,
– Jeff
A little out toppic, but I always considered this gimbal lock trick silly ; the obvious solution beeing to consider that your 3 angles of rotation are rotations about the axis of the object instead of a fixed axis (that is, the 3 axis themself rotates with the object).
untill I read this :
http://www.hq.nasa.gov/office/pao/History/alsj/gimbals.html
So, your question about gimbal locks would have been more appropriate to interview designers for the NASA !
John, in this particular instance that wasn’t the case, the guy was an intern back in the UK and was interviewing for his next gig, I explained why his response was such a … career limiting move. I thought at the time it was a very good question, one almost any good ‘real-time’ graphics programmer would ace. FWIW if I were personally asking any question and got a terse answer or it drew a blank I would drill deeper to see if I could extract any semblance of understanding. I’m with Cass on the old discussion of past work & experience.
The question itself is a trick question. You don’t really care if he has run into these problems or not. Instead of asking, “Have you use z-buffer algorithms, and what problems may crop up in z-buffer renderers?” which is a much more lucid and direct question, you ask this trick question that can get false negatives.
It’s important, when asking any question in an interview, that a conversation-limitting answer (like “No.”) means that the interviewee knows nothing about the subject. If someone said that there are no potential problems with z-buffer algorithms, then there is an obvious hole in his knowledge. If he said that he never encountered any problems (and, even with 16-bit z-buffers, they don’t crop up that often), then that’s a different story.
- Favorite language and why it is your favorite.
- Preferred graphics API
- What is your opinion on the shader-language debate?
I don’t like these questions, because they tend to be the start of a flame-war. And it reveals nothing about the programmer except that he has taken a side (that is largly, at this point, meaningless).
The first question is a pet-peve of mine: a programmer should use the language most appropriate to the task, not necessarily the most favored one.
The preferred graphics API should be learned from the Resume. If it isn’t there, then he probably doesn’t know one.
And the third question is something that many people, graphics professionals included, are not necessarily aware of. I presume you are referring to high-level vs. low-level shading languages, correct? Why aren’t more graphics professionals hearing of this debate?
Because they’re more interested in DX9/new GL programming extensions than what some people are deciding down the road in terms of API programmability. If it’s low level, they’ll use it. If it’s high level, they’ll use it. It doesn’t really concern them heavily how they gain access to programability, only that they do. And those who prefer a high-level approach can certainly build one on the low-level one.
I would not be adverse to asking questions like:
This tells you how open-minded a person is. Not only that, it tells you whether they can form an opinion about the quality of an API.
This, when properly and completely answered, is a 20-30 minute question. It tells you their ability to think on their feet (if they haven’t thought about it beforehand) and tells you their ability to think at all. An excellent question.
I would probably give a silly short coding test to see how the applicant’s mind worked and learn about their style.
Just FYI: the place where I now work gave me a short coding test. Basically, implement a breadth-first maze search algorithm; no big deal, right? It turns out that they get a lot of applicants that spend 8+ hours getting that program to work, or who never do. They don’t actually hire these people, but it is interesting to know. Which is why a coding test is important, for more than just coding style. You never know when you might get someone who says all the right things but can’t code worth anything.
If you don’t have an HR department, then you should still make sure to do that screening /before/ the candidate comes in.
Definately. To me, people who get to the interview should be people who are going to be hired if they don’t blow it.
You should realize that for good candidates the interview cuts both ways. They are evaluating the company and the people who work there.
As for “blowing it”, this implies that they’re in unless they slip up, suggesting it’s some kind of transient thing and they must perform right on the day. Nobody’s going to show up and blurt out a mea culpa, you need to explore the technical stuff. If they don’t know it then not slipping up shouldn’t be possible.
[This message has been edited by dorbie (edited 01-28-2003).]
Jambolo, if you didn’t know what question to ask the interviewee, why were you surprised when he didn’t know the answer to your question?
Dorbie is right, not knowing a term does not mean not knowing a subject. I for one had never heard the term before this forum but I did come across the problem and have worked out solutions for it before.
Asking the interviewee to write a turnCamera function right then and there would probably have been more astute.
[This message has been edited by Keermalec (edited 01-28-2003).]
Originally posted by Jambolo:
[b]Recently, I interviewed someone who was described to me as a computer graphics expert. Being my first interview, I didn’t know what kind of questions to ask him in order to evaluate his expertise. Luckily my first question was, “What is gimbal lock?”, and to my surprise, he didn’t know. I can’t imagine a person at an “expert” or an even “advanced” level not knowing what gimble lock is.
Anyway, if I have to interview more people, I can’t go in armed with just one question! What are some effective interview questions to determine a person’s knowledge of 3D graphics? [/b]
I don’t memorize useless facts for the fun of interviewing.
I have many books on my shelf, and if I want to implement a breadth-first maze
search algorithm, I use code from the book or from the net.
Maybe you are expected to memorize facts because it is the college-thing
to do, but I don’t play that game anymore.
Call me stubborn or old-fashioned, I use my brain for more important things.
What distinction do you draw between a vertex and a vector?
A vertex represents a position? Or does it simply represent a direction and magnitude from the point of origin in the coordinate system? Which is a vector of course…
A vertex has position as well as other attributes such as texture coordinate, normal, colour? Is that the difference? If so, why does opengl treat position with the function glVertex/glVertexPointer instead of glPosition/glPositionPointer?
That’s not a clear cut question.
Questions I’ve been asked in interviews:
Mundane questions, I think you’ll agree.
My questions would be things like:
Things like that - not “what is perpixel lighting?”. That kind of knowledge is merely a speck of dust compared to the overwhelming issues of creating a simulator engine you can reuse - knowledge of which can only be gained by enourmous amounts of reading and huge amounts of practical experience. Nobody’s going to hire you to write shadowed, perpixel lit cubes…it just shows you can use the functions given to you by the API.
“What language do you use?” - why, C++ of course, what a silly question in the context of realtime geometry engines…
>I have many books on my shelf, and if I want to implement a breadth-first maze
>search algorithm, I use code from the book or from the net.
Books/reference works help if you want the “best” implementation in some particular case. But that’s not what you’re after with such a test: if someone is unable to spill a simple graph search logic out of his mind in a few minutes (not necessarily the best or even a good one), you are definetely safe to assume he’ll have trouble handling anything more life-sized, and if he does, that it is/was/will be packed with incoherencies and/or inefficiencies.
My personal opinion:
I agree with EG on the importance of having candidates solve problems in interviews. Even high-level managers should be expected to be able solve that kind of problem
I also like asking something detailed and hands-on first (“what is a tangent basis?”); if that doesn’t work, back up a little bit and see if the candidate can work to the solution (“how does bump mapping work?”); if that doesn’t work, try getting the candidate to derive the solution from first principles (“how do you calculate the diffuse and specular light contributions?”).
Someone who answers don’t know on the first two, but can derive the tangent basis formulation when being prodded onwards from the per-pixel lighting formulation, could be very valuable to the team.
Also, asking about details is usually a good way of telling someone who pads his resume from someone who has implemented it: “could you write that on the whiteboard?” “how would you implement that on <hardware of choice>?” “could you attempt writing the code for that, don’t worry about syntax errors?”