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.