Something happened recently, and I wasn't exactly sure whether it was fair, so I'm asking here to get other programmers' perspective on the matter.

In interviewing junior candidates for a junior role on a team, the key interviewer asked the person to explain why, in general, GPUs used 4x4 matrices for (complex) transformations. The question was basically thrown to see whether the candidate knew anything about homogeneous transformations (basically adding the w axis which is the origin to consider the offset of a translation, etc.)

The problem, in my perspective, was that the role the candidate was applying for was a junior role, with a specific engine in mind (Unity in this case), and that the engine itself would abstract that whole idea to a point where it would never be relevant for the developer. However, I can appreciate that gauging whether the potential developer had any idea what was happening 'behind the scenes' could have value, and that it can be a concept that's hard to grasp AFTER having started working in the industry, but it left a sour taste in my mouth that the otherwise savvy candidate would be discarded based on his ignorance of the maths behind it, given he had demonstrated results on a variety of 'complex' fronts for a junior (A*/Dijkstra, complex AI systems, etc.)

Note: the position was labeled as 'Junior Programmer' strictly, and none of the descriptive items listed any requirement of computer graphics-related experience per se (there was a mention of knowing basics such as 'draw calls' though, so up to the reader's interpretation whether the position entailed gfx-heavy computation skills).

I'll admit I'm on the fence on this one and hoping to get perspective on the matter (realistically, it isn't about whether homogeneous transformations are easy/hard to pick-up as much as it is whether this is a valid interview question to vet a junior candidate expected to work 'in-engine').

(@mods: not sure whether this belongs in Game Industry Job Advice (discussing the validity of the question in an interview and the resulting process) or one of the programming sub-threads (as it hinges on what it important/relevant for a developer), so feel free to move accordingly).

Thanks!

Fairness is always subjective. Personally it's hard for me to imagine rejecting any candidate on the basis of a single technical question.

I would have failed with the question above, too. I don't think it's a particularly important concept; but then I'm not applying for graphics jobs.

Hmm, personally this was something I was taught in 2nd year of Uni as far as I remember, may even have been first year. Though my course was specifically Games Programming. So to me it seems like a perfectly fair question to ask of a Junior programmer.
Though, I can see that there are likely the majority of candidates that would have done a Computer Science degree that likely wouldn't have covered anything like that.

You do mention though that he had demonstrated knowledge of several other areas such as pathfinding / AI. So realistically, I think the question is fair to ask a junior candidate, though I dont think it should be grounds for instantly discarding them from the job, especially if they have shown knowledge in other areas.

In interviewing junior candidates for a junior role on a team, the key interviewer asked the person to explain why, in general, GPUs used 4x4 matrices for (complex) transformations. The question was basically thrown to see whether the candidate knew anything about homogeneous transformations (basically adding the w axis which is the origin to consider the offset of a translation, etc.)

The problem, in my perspective, was that the role the candidate was applying for was a junior role, with a specific engine in mind (Unity in this case), and that the engine itself would abstract that whole idea to a point where it would never be relevant for the developer.

I'd expect anybody who works near graphics (that is, including using something like Unity to put the graphics onto the screen, not just down in the D3D trenches) to have a basic idea of why 4x4 matrices might be used. I would not reject them as a candidate for lacking that knowledge though; if they don't, I would at least expect them to be able to talk intelligently about their experience with such transforms, perhaps speculate on why 4x4 is used, et cetera. So I think the question is fair, but that (in the general sense) discarding a candidate over a "wrong answer" to it is not. It is possible to not know the "correct" answer to a question and still perform well in an interview context when responding to that question.

Do you know the candidate was actually rejected by the asker over this question alone? A poor answer to one question generally should not disqualify somebody, but poor answers to many might. It's also possible the asker simply thought, based on the rest of the interview, the candidate might know this information was trying to probe the boundaries of the candidate's experience.

What's interesting to me is that you didn't know this was going to be a question asked by your interview team. To me that suggests a lack of pre-planning or structure to your interview sessions; I see this a lot in the industry. Interviews consist primarily of a handful of team members more or less randomly selected tossed into a room with the candidate to ask whatever random questions they come up with on the spot, or whatever pet questions those developers have, regardless of the position in question or the candidates background. This is an indication, in my mind, of a flawed interview process that does disservice to everybody involved.

I'd be more concerned about that than the fairness of one question in a vacuum.

I treated matrices as a black box until I had to debug a d3d9 -> opengl es 2 porting bug involving them, at which point I built myself a solid geometric understanding of 3x3 and 4x3 matrices, and at least enough of an understanding of 4x4 matrices to debug them. (The bug was not realizing glUniformMatrix4fv ignored the transpose parameter in ES2.)

As a single reject reason, it seems rather picky for a junior position. If you've got a flood of well qualified candidates, it might be reasonable to be this picky (especially if they're expected to start working on graphics code right away). If you've got a trickle and several slots urgently in need of filling, it may be *very* worthwhile to give them a shot - you can always try and mitigate some of your risk by trying them out as a contractor first. If they work out, you can always offer them an upgrade to full time employment.

Like those above, it depends on context.

it isn't about whether homogeneous transformations are easy/hard to pick-up as much as it is whether this is a valid interview question to vet a junior candidate expected to work 'in-engine'

On its face I think the question is a good one. It asks for some general knowledge on a topic that MOST experienced game developers know, and that ALL experienced graphics developers know. It is a valid question, although it may have limited value.

Questions like that are also about the answer. If the person knows, I'd want to see how they describe it. If the person doesn't know the answer I'd love to hear how they think about it. I expect someone who is comfortable with a topic to be able to explain it easily, and to create a description that is easily understood. When I ask some technical questions and the person doesn't know, I ask them to take some guesses and describe what they think. If they show some sign of thoughtfulness and reasoning then it is still a good answer.

When I interview people one question alone is typically not enough to 'fail' a job interview. A series of questionable or factually wrong answers will get the candidate on the 'no hire' stack, but one usually won't. Most interviewers will allow for some questions to go badly, especially because people are often nervous and excited. The interview is a discussion, a way to learn about someone and their skills and experience and background. It isn't supposed to be a high-stakes trivia show. That question is somewhat trivia-like, but still gives insights to experience and background.

Doesn't sound like a graphics specific role reading the post, so what should be evaluated is his general capability around the CS domain, not the graphics domain.

Failing based on one graphics question seems to be over the top, even though the question is a basic one that is taught in entry graphics classes. Previous studios I have worked in definitely hired programmers that have never touched graphics in their life to work as junior gameplay programmers, and we had an in house engine that didn't abstract the maths as nicely as Unity as well.

So I think it's a bit tough to fail a person solely based on that.