PDA

View Full Version : Good Job Interview Questions



Jambolo
01-25-2003, 01:12 PM
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?

pkaler
01-25-2003, 01:31 PM
What was the last book you have read? And what did you learn?

dorbie
01-25-2003, 01:59 PM
Well jambolo I can imagine an expert might not know.

If you're interviewing someone for a graphics position and you don't have a clue about it then maybe you should leave that aspect to another interviewer who does. Ask about what you DO know. Certainly to ask the question you did and form your opinion on that is misguided. If your question draws a blank you should go on and ask about Euler angles or why one might use quaternians, rather than making the assumption you apparently did.

Sounds like the candidate had a lucky escape to me.

[This message has been edited by dorbie (edited 01-25-2003).]

rgpc
01-25-2003, 02:21 PM
Firstly, gimbal lock is hardly a graphics question... I would most likely call it a 3d mathematics question.

Perhaps a better question might have been if they are familiar with Quaternions? Whether use Opengl and/or Dx? What they have used these API's for and what features they have used (eg. VP's etc.)

Coriolis
01-25-2003, 03:29 PM
Ask to see his/her previous work, and go from there.

V-man
01-25-2003, 03:59 PM
What could octree, BSP, etc could be used for in 3D graphics and is there principle.

There are plenty of questions one could ask, so an expert should be able to answer 90% or something.

Asking about previous experience, demonstration programs is part of the interview too.

JONSKI
01-25-2003, 10:30 PM
I would start with something more general.
For example:
"Have you done any work in...
occlusion culling
lighting effects
collision detection
physics
animation
etc.
?"


When the interviewee affirms, then I would ask for more specific information on that topic.
For example:
Interviewer: "Do you have any animation experience?"
Interviewee: "Nothing implemented, but I've read several papers on the topic."
Interviewer: "Is there anything in animation that you've studied in particular, like inverse kinematics or keyframe interpolation?"


I would make a note of the topic or topics that the the interviewee seems most enthusiastic or informed about and ask something like, "What interests you most about insert topic here?"

Jambolo
01-26-2003, 01:44 AM
Yes, dorbie. I suck at interviewing. That's why I'm asking questions so I can learn to do a better job. Why do you insult me?

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?

And talk about assumptions...you assume I "don't have a clue" and you are way off.

harsman
01-26-2003, 04:02 AM
Asking the applicant to solve or think about some sort of problem might be better than asking straight out pop quiz type questions. You might hire a bad programmer who knows lots of buzzwords that way. Try "Lately we've been thinking about shader management/shadow algorithms/geometry transfer optimizations here at Monkey Interactive and we've run into issues a,b and c. What are your thoughts on that?" Or something along those lines.

idz
01-26-2003, 08:05 AM
well, first of all "expert" sounds bit silly.

and for this question...if this "expert" didn't know 1 term you interviewed, it doesn't mean anything..

knackered
01-26-2003, 08:52 AM
Give me the job, Jambolo - I know what gimbal lock is, I've seen Pulp Fiction....

dorbie
01-26-2003, 09:45 AM
This ain't about you & me Jambolo. :-)

If someone knows a subject they will have some idea what to ask in an interview. If you DO have a knowledge of the topic and are at a loss, just have a technical discussion with the guy/gal, and see where it goes, heck ask them to explain something they know and you don't, you even learn something.

The use of the term gimbal lock has always been a misnomer IMHO, and isn't universal. Of terms I'd expect someone to know it's pretty near the bottom of the list, unless perhaps they have some simulation or instrumentation experience.

As for assumptions, I have your "he didn't know" in bold face; it tells me what I need to know. At some point in our careers we all face an interview with someone who doesn't correctly understand the subject they're asking about, it leaves a bad taste. No offence intended, really.

[This message has been edited by dorbie (edited 01-26-2003).]

Kilam Malik
01-26-2003, 10:59 PM
I read the term "gimbal lock" the first time here in the OpenGL forum about 1 year ago and I didn't know what it means. But I solved it 3 years before in an OpenGL project. I simply didn't have a name for it. So not knowing a term does not necessarily say something about the qualification.

In a job interview I always ask for the projects they did before. Then depending on their answers I can ask specific details on their software they did. When they come directly from university it's important for me what private projects they did or if they only made the projects necessary to finish the university.

Kilam.

EG
01-27-2003, 01:23 AM
Some filtering questions I like to ask are related to the level of interest the candidate has in the subject: which sites he visits? which magazines? which books? how did he came to work on the subject? does he know of some "reference" or "famous names" in the industry, etc.
That's a fast, non-aggressive way of filtering early on in the interview. If there is some substance, you can then proceed to inquiring about technical knowledge. Ask questions which require knowledge to answer, f.i. do not ask

"do you know what texturing is?"
or
"did you ever write some skeletal animation code?"

and other questions that can be answered with a yes/no and a reference to some previous work (in which it's often hard to know what part he/she played exactly). But rather:

"how would you texture/skin a sphere/zergling/whatever mesh?"

(is he/she naming 3D design tools? standard texture coordinates generation? or is he/she staying in the vague, refering other peeps in the team?)

You can also mix some plain stupid questions with regular ones, to see if his/her technical side reacts, you can voluntarily place lapsuses in your sentences: invert "mesh" and "texture" in the previous question f.i.

Walrus
01-27-2003, 12:19 PM
"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: Rotation*W vs. W*Rotation, where rotation is a rotation matrix and W is a matrix that is not axially alligned or about the origin.

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



[This message has been edited by Walrus (edited 01-27-2003).]

rgpc
01-27-2003, 12:28 PM
Originally posted by Walrus:
[BI 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)
[/B]

Yes but apparently the candidate was described as a "computer graphics expert". There's more to CG than 3D -and there's more to knowledge than knowing the names of things...

Korval
01-27-2003, 12:41 PM
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: Rotation*W vs. W*Rotation, where rotation is a rotation matrix and W is a matrix that is not axially alligned or about the origin.

What is a dot product and how is it useful in 3d graphics?

What is the viewing frustrum?

The problem with many of those questions is that they are just RIGWAT. That is, Regurgitated Information Given Without A Thought.

If I'm hiring a programmer, I want to know that he's capable of more than just RIGWAT-ing information from a text book. I don't mind a graphics programmer who carries around Foley or a linear algebra boox because he doesn't remember the precise definition of a projection matrix or the difference between "pre-multiplying" and "post-multiplying", as long as I'm sure that this person can think. A programmer who can RIGWAT but not think is useless.

A person who can think can learn graphics easily. Teaching a person to think takes far longer than teaching a thinking person any particular subject.

BTW, you first question, about representing a camera transform, is way too vague. There are any number of ways to represent a camera transform, and you use different ways depending on a situation.

Now, had you given him a particular situation and asked how a camera's transform should be represented, then you have a question that tests the applicant's ability to think.

knackered
01-27-2003, 01:22 PM
Bravo!
You've got to worry when you get someone who's answer to all those questions is 'google'...
Thing is, you've got to wonder what use any of this knowledge is when you consider the rising popularity of 3rd party renderers and physics api's...who cares if he knows what a projection matrix is, it's all done for him. He basically just needs to be good at C++, unless he actually works for Criterion... http://www.opengl.org/discussion_boards/ubb/smile.gif

john
01-27-2003, 03:02 PM
What are homogeneous coordinates and how do you convert them into cartesian coordinates?

that might not be a good question to ask given that the interviewee very well know more about projective geometry than the interviewer. Homogeneous coordinates are NOT just simply "We tack an extra value---lets call it "W"---and represent cartesian coordinates as x/w, y/w, z/w". What if the person turns around and explains the axioms of projective space (each pair of lines will intersect in one point; there must be at least four points, of which only three must be collinear), or illustrate's pappus' theorem.

How many people here know what the principle of duality is?

Although part of an interviewing process may well be like an oral maths exam, I think its more important to see if they can understand concepts if theyv'e been explained to them. Suppose the guy doesn't know what gimbal lock is; what if you explained the problem. Did he understand what you're talking about? That is more important. Maybe he hasn't heard of it before because his graphics expertise was in another field. I bet the guys who work on algorithms for rendering liquid don't necessarily need to know a lot about gimbal lock.

my 2cents worth.

cheers,
John

dorbie
01-27-2003, 03:11 PM
No, 'gimbal lock' is a bull**** graphics question, I don't care what your professor / boss says. It's a misnomer and I wouldn't be surprised if a graphics expert with a doctorate in quaternion mathematical formulations had not come across it being used.

dorbie
01-27-2003, 03:40 PM
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).]

V-man
01-27-2003, 05:33 PM
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.

john
01-27-2003, 06:06 PM
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"

:P

cass
01-27-2003, 09:47 PM
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

Jambolo
01-27-2003, 10:56 PM
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.

dorbie
01-28-2003, 12:16 AM
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).]

Humus
01-28-2003, 01:27 AM
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.

Adrian
01-28-2003, 02:57 AM
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 http://www.opengl.org/discussion_boards/ubb/smile.gif

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).]

P88_Razor
01-28-2003, 02:59 AM
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. http://www.opengl.org/discussion_boards/ubb/wink.gif



[This message has been edited by P88_Razor (edited 01-28-2003).]

Walrus
01-28-2003, 03:02 AM
"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: Rotation*W vs. W*Rotation, 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

Adrian
01-28-2003, 03:23 AM
Walrus, do you realise you posted an almost identical response earlier? I thought it looked familiar http://www.opengl.org/discussion_boards/ubb/smile.gif

Thaellin
01-28-2003, 04:33 AM
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:
- Favorite language and why it is your favorite.
- Other languages used, when and why.
- Preferred graphics API, which versions have you used, what did you like and dislike about them.
- Ever written a software rasterizer, when, and in God's name what for? http://www.opengl.org/discussion_boards/ubb/wink.gif What was the hardest part?
- If OpenGL: what extensions have you found most useful (why) and what future extensions are you most looking forward to?
- What is your opinion on the shader-language debate?
- What was the most difficult coding project you've completed?
- What was the most rewarding project you've worked on?
- What do you think is the hardest-to-resolve programming error that you've ever introduced into a code-base?
- Describe your experience working with existing code-bases.
- Have you ever quit a project and why?
- Have you ever run a project? What was it? How many people? How did it go?
- If the candidate has run a few projects: have you ever had to kill a project, and what led you to that decision?

Important non-technical questions:
- What would be your ideal career?
- What made you get into this industry?
- Why did you apply at my company?
- Where do you see yourself in 3 years.

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

rixed
01-28-2003, 04:46 AM
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 ! http://www.opengl.org/discussion_boards/ubb/smile.gif

Korval
01-28-2003, 09:04 AM
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:

- What are the benifits/drawbacks of each the graphics APIs that you have used?

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.

- If you could design a shader API, from either the perspective of maximum efficiency or that of ease of end-user use, what would it look like, and why would it look like that?

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.

dorbie
01-28-2003, 12:21 PM
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).]

Keermalec
01-28-2003, 01:48 PM
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).]

gator
01-28-2003, 08:27 PM
Originally posted by Jambolo:
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?


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.

kieranatwork
01-29-2003, 03:10 AM
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:
- how do you arrange your vertices in your arrays? A single interleaved array or separate arrays?
- what is a scenegraph? Do you understand what a transformation hiearchy is?
- what is a dot product?
- what is a cross product?
- have you any Unix/Irix experience?

Mundane questions, I think you'll agree.

My questions would be things like:
- have you written a geometry processing engine?
- how did you abstract underlying api's into generic interfaces? what issues did you face when doing this?
- how did you handle your geometry databases? Did you stream them? What issues...etc.?
- how do you do your collision detection?

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....

EG
01-29-2003, 03:54 AM
>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.

jwatte
01-29-2003, 07:10 AM
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?"

dare
01-29-2003, 01:15 PM
I wander how did Jambolo get his job when he fails on question like : what questions would you ask ? Seriously, choosing the right candidate must imply some subjektivness, like : did I like this guy/girl ? Would I like to work with him/her ? And of course, you ask questions that you thik are appropriate, but take responsability of your choice!