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

Speaking as a junior, myself - yes, I would expect another junior dev to get this. In fact, I would expect a reasonably bright university student who had ever done anything related to 3D graphics to be able to answer this question. Homogeneous transformations are pretty much the first thing you learn in your first uni-level computer graphics course. I wouldn't expect a candidate to be able to throw together a homogeneous transformation matrix manually, on the spot, but I would hope that they at least know what they are. Even if you don't need someone with graphics experience right at that second, how do you know you won't a few months down the line? Given the choice between two junior candidates who both fulfill the requirements - one who can answer the math questions and understands what is actually happening when they use the math and one who can't - who would you choose?

That being said, I'm not sure I would fail a candidate solely on these grounds unless I had future graphics work in mind for the candidate.

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.

If the position was advertised as "graphics programmer" and they couldn't answer that question, I'd fail them for that alone. Yes, even a fresh out of college dev. Same for any "physics programmer" position.

If the position is not specifically somebody who should know their graphics/physics programming chops, it gets murky. If they're still expected to be doing "graphicsy stuff" and they can't answer that, it might not be an instant disqualification but it'd put them on pretty thin ice. It raises the question of how they fail too, whether we're talking about a relatively minor failure to understand the subtlety of a 4x4 transform (not so bad) or if matrices are just magic boxes to them (pretty bad).

If the position doesn't call for graphics or physics knowledge at all, I'd most likely let it slide as 'unfortunate but fixable'. It's something that could tip me to another candidate but wouldn't necessarily do so. From your description of the job listing - assuming it's accurate - it seems like this is more the box that applies but evidently that was not a shared understanding among the team.

---

On a personal sidenote, I'm hearing more and more that the democratization of engines and core tech, led in no small part by Unity, has resulted in a large junior workforce who are flubbing basics because "oh it's all abstracted away". This is not a healthy way to attempt to enter game development, a world where tools are fleeting but core fundamentals are forever. Don't do this to yourselves, people. Don't assume you can always live on top of convenient abstractions to hide you away from the scary mathematics and computer architecture.

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.

I would personally treat that as a "bonus points" question for a junior, not a "make or break" question.

There were two paths a game programmer could take through my university - Software Engineering, or Computer Science.

The compsci people were forced to do a lot of math, from linear algebra to the dynamics of a teacup of swirling flyid orbiting the moon... They got examined on homogeneous coordinates and 4x4 matrices.

Meanwhile over in softeng land, I got forced to do business-relevant math, like calculating how many lightbulbs I should order if I want to be able to deliver 10k of then with 99.99% certainty knowing that the QA yield is only 95%.
I was very interested in graphics and went on to build a career around it, but it was years after graduation that matrices stopped being just a magic black box to me. Actually it was about 4 years into my career when I was struggling to implement planar reflections on the Wii -- so I sat down with paper and constructed a matrix that performed the reflection function from scratch -- that the simplicity of matrices really started to sink in. After that I really wished that someone had explained the phrase "basis vectors" to me sooner... These aren't hard concepts to pick up when demonstrated well.

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.