Hiring Process for Game Developers
Author
Hello,
I'll cut the commentary and get straight to the question. What process to you guys find is effective and selecting candidates for a programming position in a small game development group?
Do you guys look for demos, perhaps degrees, or is it merely a series of technical questions? Or do you just google the guys name and see what pops up?
-Ken Noland
In order of importance:
1. Computer Science degree, 3.0 GPA (B) minimum in CS classes
2. Completed game for established company/brand
3. -- or Completed game (as a hobby)
4. -- or Demo
1. Computer Science degree, 3.0 GPA (B) minimum in CS classes
2. Completed game for established company/brand
3. -- or Completed game (as a hobby)
4. -- or Demo
Author
Is this a personal preference or a company policy?
I find it odd that you list a CS degree first and foremost. It's been my experience that people without a degree are often times better then the guy who spent 6 years without a serious deadline(aside from finals week, but imagine that multiplied times 2 months and that's what a true crunch time is like). However, that's completely debateable.
Personally, I like the process of hiring interns, with a clear understanding that these guys are getting paid very little and producing very little, and then gradually, over time, building them up to Sr. Programmers. It takes a few years, but you get to really parse out the good from the bad without significant investment.
For mid level hiring, I find that working in the games industry prior is a big thing for me. I tend to look at more seriously at candidates that have worked on a couple of titles in the past and are familiar with the practices of the games industry.
For Sr. level hiring, well, I have to look at everything. What has this person done before? How will his skillset improve our chances of hitting our deadlines? etc, etc, etc...
-Ken
I find it odd that you list a CS degree first and foremost. It's been my experience that people without a degree are often times better then the guy who spent 6 years without a serious deadline(aside from finals week, but imagine that multiplied times 2 months and that's what a true crunch time is like). However, that's completely debateable.
Personally, I like the process of hiring interns, with a clear understanding that these guys are getting paid very little and producing very little, and then gradually, over time, building them up to Sr. Programmers. It takes a few years, but you get to really parse out the good from the bad without significant investment.
For mid level hiring, I find that working in the games industry prior is a big thing for me. I tend to look at more seriously at candidates that have worked on a couple of titles in the past and are familiar with the practices of the games industry.
For Sr. level hiring, well, I have to look at everything. What has this person done before? How will his skillset improve our chances of hitting our deadlines? etc, etc, etc...
-Ken
Author
okay, I can understand that. In a perfect world, what do you think is the best way to go about it?
I'm curious about this because I've always been on one side of the table, being interviewed. Now I'm sitting on the other side and, well, it's interesting to me.
Any pointers, tips, tricks to finding the best candidates?
-Ken
I'm curious about this because I've always been on one side of the table, being interviewed. Now I'm sitting on the other side and, well, it's interesting to me.
Any pointers, tips, tricks to finding the best candidates?
-Ken
A potential candidate sticks out from the beginning.
It's really not about having a completed or shipped title. It's about having a charismatic interviewee who can actually code worth a damn.
Degrees are worth nothing, more than half of the people with a CS degree I've seen so far couldn't program if their life depended on it.
Demos are pluses, and finished games are bigger pluses. I once had a guy applying for a mobile games programmer position who wrote a Bomberman Clone in pure assembly and sent in a small Tetris game for Mobile Phones. Instant hire, because the demos were good, the graphics were good (self-made!), and I knew the guy from various OpenGL classes at my former university.
But in many cases, you get only a bunch of screenshots or even a stack of bland resumes that look good "on paper", but need to withstand some trials before you can pick a winner. So, I have a small catalogue of questions; along with contextual ones that pop up during an interview.
For a Junior Programmer:
1. Please point out some advantages of OOP.
2. Can you name a disadvantage? (for instance, knowing the Fragile Base Class Problem usually means the person has at least encountered it once. Bonus points if they can point out one that's not in the books or give a real world example of one they encountered)
3. Explain single inheritance. (This weeds out between 30% to 60%)
4. What's the difference between overriding and overloading? (More a terminology question, gives insight into their experience in verbally communicating such things to others)
5. Name a Design Pattern and explain it. (This weeds out another 50%, often they go "Design what?" - notably, though, I probe whether maybe they've been using patterns without knowing it). AbstractFactoryPattern and StatePattern earn bonus points.
6. Write a small program that inverts a doubly-linked list. Pseudocode is fine. (Wipes out f§%"ing 80%, including people with degrees!)
7. Name and verbally explain a sorting algorithm. Bubblesort does not count. Alternative question: Explain the concept of search trees.
It's really not about having a completed or shipped title. It's about having a charismatic interviewee who can actually code worth a damn.
Degrees are worth nothing, more than half of the people with a CS degree I've seen so far couldn't program if their life depended on it.
Demos are pluses, and finished games are bigger pluses. I once had a guy applying for a mobile games programmer position who wrote a Bomberman Clone in pure assembly and sent in a small Tetris game for Mobile Phones. Instant hire, because the demos were good, the graphics were good (self-made!), and I knew the guy from various OpenGL classes at my former university.
But in many cases, you get only a bunch of screenshots or even a stack of bland resumes that look good "on paper", but need to withstand some trials before you can pick a winner. So, I have a small catalogue of questions; along with contextual ones that pop up during an interview.
For a Junior Programmer:
1. Please point out some advantages of OOP.
2. Can you name a disadvantage? (for instance, knowing the Fragile Base Class Problem usually means the person has at least encountered it once. Bonus points if they can point out one that's not in the books or give a real world example of one they encountered)
3. Explain single inheritance. (This weeds out between 30% to 60%)
4. What's the difference between overriding and overloading? (More a terminology question, gives insight into their experience in verbally communicating such things to others)
5. Name a Design Pattern and explain it. (This weeds out another 50%, often they go "Design what?" - notably, though, I probe whether maybe they've been using patterns without knowing it). AbstractFactoryPattern and StatePattern earn bonus points.
6. Write a small program that inverts a doubly-linked list. Pseudocode is fine. (Wipes out f§%"ing 80%, including people with degrees!)
7. Name and verbally explain a sorting algorithm. Bubblesort does not count. Alternative question: Explain the concept of search trees.
Quote:Original post by Thygrrr
Degrees are worth nothing, more than half of the people with a CS degree I've seen so far couldn't program if their life depended on it.
But more than half the programmers without one couldn't program if their life depended on it either... [grin]
(Or worse, their code regularly ends up on The Daily WTF)
Ok, so there maybe is a slight correlation between knowing how to program and having a CS degree.
But it's still entirely within the overall margin of error. :P
And trust me, I've seen a lot of nasty code... when reviewing code from potential appplicants, make sure you wear these:
...especially when it's code from a person that is in the process of graduating or just got their degree.
But it's still entirely within the overall margin of error. :P
And trust me, I've seen a lot of nasty code... when reviewing code from potential appplicants, make sure you wear these:
...especially when it's code from a person that is in the process of graduating or just got their degree.
Haha I agree.
CS that dont mean they are good coders, that just mean they have a proof that they can learn :)
And some CS come out of it with incredible demo.
CS or not, its only a matter of passion and talent.
But as "Anonymous Poster" says, generally HR dont forward your resume if there is no CS degree on it ;)
Try looking for smaller companies!
CS that dont mean they are good coders, that just mean they have a proof that they can learn :)
And some CS come out of it with incredible demo.
CS or not, its only a matter of passion and talent.
But as "Anonymous Poster" says, generally HR dont forward your resume if there is no CS degree on it ;)
Try looking for smaller companies!
I think you should look for talent, not papers. You can easily detect talent by demos, code clarity and least (but not last) - experience.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
