Software Engineer Game compared to Software Engineer Film

Status
Not open for further replies.
All:

I recently became unemployed and am really looking for getting into the gaming space (which is my passion). However, after nearly 10 years being out of job searching, I'm met with a lot of tough realizations. I've met with several gaming companies based on my resume and experience in the film industry, yet NONE of them want to give me a chance into the gaming space as a graphics engine programmer. I've started online college at various gaming institutes, bought several books on OpenGL, Vulkan, etc.. to see what skills I sorely lack that would make ALL of my attempts futile. I'm going over Unity now and I've made a simple OpenGL renderer and I'm not seeing what the big deal is aside from time critical code (which film engineers have to deal with too) and knowledge of profiling hardware (which I picked up by just hearing a 1hr youtube video about it). We all have to learn the same graphics background, and while code is a lot more lenient when it comes to programming for CPUs rather than GPUs, I'm still not seeing anything that seems like someone from the film industry couldn't pick up rather quickly and then carry his array of knowledge on offline renderers to make some cool stuff in realtime. Practically every film company I know is starting to delve into GPU acceleration in one way or another. Whether it be accelerating complex particle systems, or creating shots with GPU lights/shadows for lighters.

Is there anyone that works in the gaming industry that can clarify a little on why there is so much resistance? Has there been bad hires in the past? Are software engineers in film just that clueless?

-M
 
All:

I recently became unemployed and am really looking for getting into the gaming space (which is my passion). However, after nearly 10 years being out of job searching, I'm met with a lot of tough realizations. I've met with several gaming companies based on my resume and experience in the film industry, yet NONE of them want to give me a chance into the gaming space as a graphics engine programmer. I've started online college at various gaming institutes, bought several books on OpenGL, Vulkan, etc.. to see what skills I sorely lack that would make ALL of my attempts futile. I'm going over Unity now and I've made a simple OpenGL renderer and I'm not seeing what the big deal is aside from time critical code (which film engineers have to deal with too) and knowledge of profiling hardware (which I picked up by just hearing a 1hr youtube video about it). We all have to learn the same graphics background, and while code is a lot more lenient when it comes to programming for CPUs rather than GPUs, I'm still not seeing anything that seems like someone from the film industry couldn't pick up rather quickly and then carry his array of knowledge on offline renderers to make some cool stuff in realtime. Practically every film company I know is starting to delve into GPU acceleration in one way or another. Whether it be accelerating complex particle systems, or creating shots with GPU lights/shadows for lighters.

Is there anyone that works in the gaming industry that can clarify a little on why there is so much resistance? Has there been bad hires in the past? Are software engineers in film just that clueless?

-M
Its a tough space to get into. I had an interview with a AAA firm here, and despite my experience in coding, and I have a shipped indie title that I ported, it wasn't enough for me to get into junior programming. These guys are generally looking for experienced AAA game folks, I think some people will be able to do better than others sure. But if you can't catch an interview, you need a referral for sure.
the other issue is pay. If you're used to high salaries, you're not going to find it at AAA studios. And I'm pretty sure that's a knock against you, because you're going to take a deep pay cut to do _waaaayy_ more work. And that's a high risk for them if you're in a critical role and you're just getting up and going because pay isn't matching effort (with what you're used to)
 
Its a tough space to get into. I had an interview with a AAA firm here, and despite my experience in coding, and I have a shipped indie title that I ported, it wasn't enough for me to get into junior programming. These guys are generally looking for experienced AAA game folks, I think some people will be able to do better than others sure. But if you can't catch an interview, you need a referral for sure.
the other issue is pay. If you're used to high salaries, you're not going to find it at AAA studios. And I'm pretty sure that's a knock against you, because you're going to take a deep pay cut to do _waaaayy_ more work. And that's a high risk for them if you're in a critical role and you're just getting up and going because pay isn't matching effort (with what you're used to)

I'm actually OK with the pay cut. The film companies just don't have enough work to have large teams anymore and the companies are shrinking (not expanding) and there is low turnaround - especially in the US.

I'd love to dig a little deeper though into what gaming engineers are thinking. Wanting AAA gamers I can understand, which I would assume they would just pass on my resume, but they aren't. They see something different that perhaps I can bring to the table so they engage in the interview process. Which leads to nowhere. I did very well at CCP for example, but when I told them I never profiled software before (using Perf, or VS), it was a red flag for them. Sure, film could absolutely use that to see where bottlenecks are in code, but as soon as I learned what it was, I was like "wow, this is cool!". I wasn't like "uhh.. I don't understand how to use this."
 
I'm actually OK with the pay cut. The film companies just don't have enough work to have large teams anymore and the companies are shrinking (not expanding) and there is low turnaround - especially in the US.

I'd love to dig a little deeper though into what gaming engineers are thinking. Wanting AAA gamers I can understand, which I would assume they would just pass on my resume, but they aren't. They see something different that perhaps I can bring to the table so they engage in the interview process. Which leads to nowhere. I did very well at CCP for example, but when I told them I never profiled software before (using Perf, or VS), it was a red flag for them. Sure, film could absolutely use that to see where bottlenecks are in code, but as soon as I learned what it was, I was like "wow, this is cool!". I wasn't like "uhh.. I don't understand how to use this."
Yea I could see that as being a red flag for them. Even more so if you are attempting to go into consoles, as profiling there is much different than profiling on PC space (less different with the recent release of PIX). After profiling you've got to fix the problem as well. That's probably where they were worried with it.
 
Yea I could see that as being a red flag for them. Even more so if you are attempting to go into consoles, as profiling there is much different than profiling on PC space (less different with the recent release of PIX). After profiling you've got to fix the problem as well. That's probably where they were worried with it.

Well, that's actually my concern. What does 'fixing a problem' mean in the software engineer space? For example, suppose running the profiler showed me that there was a function that was taking up several ms -- which was the detractor for the performance loss. Unless the function has assembly routines (and even then, a software dev should be able to ramp up on what that code does), we revert back to a typical software engineer with a problem that pretty much all of them share. If it's graphics related, well, a graphics programmer with 3D background would know at least what's going on and can talk about it.

I'm not seeing where the expertise would just come to a standstill having a background in film. Do you have perhaps some examples where someone in film would struggle with a particular concept so much so that they couldn't fix an issue (aside from the console dev which makes total sense)?
 
Also, there is another issue that really bothers me about the tech industry as a whole.

The whiteboarding interviews whereby questions are asked that have nothing to do with what the person works with on a daily basis. An example would be the interviewer asking you about what projects you worked on specifically.. you start by talking about all of the plugins you wrote in Maya, for example. Or how you created a cool FX tool that scattered points along a curve in a random fashion, or implementing some procedural noise filtering algorithm. Then they say, "oh that's great!".. they go up to the whiteboard and then ask you to implement a function that returns a boolean on whether a string has unique characters or something. So now you have to think .. hm.. well I guess I could just compare each element of the string with every other element until I reach the end of the string. Well, can you do it faster? So you are sitting there thinking about strings, hash tables, bit vectors, etc.. -- all stuff from way back in college instead of what you worked on for the last 2 years. LOL! I've been away for nearly 10yrs and I missed a LOT of how job interviews are now done it seems.. :(
 
Also, there is another issue that really bothers me about the tech industry as a whole.

The whiteboarding interviews whereby questions are asked that have nothing to do with what the person works with on a daily basis. An example would be the interviewer asking you about what projects you worked on specifically.. you start by talking about all of the plugins you wrote in Maya, for example. Or how you created a cool FX tool that scattered points along a curve in a random fashion, or implementing some procedural noise filtering algorithm. Then they say, "oh that's great!".. they go up to the whiteboard and then ask you to implement a function that returns a boolean on whether a string has unique characters or something. So now you have to think .. hm.. well I guess I could just compare each element of the string with every other element until I reach the end of the string. Well, can you do it faster? So you are sitting there thinking about strings, hash tables, bit vectors, etc.. -- all stuff from way back in college instead of what you worked on for the last 2 years. LOL! I've been away for nearly 10yrs and I missed a LOT of how job interviews are now done it seems.. :(
They are looking for general understanding of data structures and memory management. This comes up a lot now. Array of size 256 or hash table to determine if all unique in a string. Convert ascii into a space and mark a 1. If there is already a 1 you know the string isn't unique.

Lots of these types of questions come up for technical tests now, detecting cyclical loops, raycasting. Tree traversal with and without recursion. I think these are considered standard now for real (non web) development roles.
 
They are looking for general understanding of data structures and memory management. This comes up a lot now. Array of size 256 or hash table to determine if all unique in a string. Convert ascii into a space and mark a 1. If there is already a 1 you know the string isn't unique.

Lots of these types of questions come up for technical tests now, detecting cyclical loops, raycasting. Tree traversal with and without recursion. I think these are considered standard now for real (non web) development roles.

Yep, I know it's standard now.. but it doesn't really test whether you are getting a good candidate or not. It's a very controversial topic (as I'm not the only one who thinks this). I can learn a lot of these algorithms again by practicing these problems over and over so that I become good at them in an interview.. however, it's not going to guarantee a company that they are getting a solid graphics programmer. IMO (<<< notice the all caps), I'd much rather test them on graphics knowledge. It's more important to me that someone knows how to make an orthogonal coordinate frame given one vector, or knowing how to integrate domains, or knowing how to use finite differencing to approximate derivatives than to know how an algorithm problem in front of a whiteboard can be solved. I guess some companies can have it both ways.. :(
 
I haven't interviewed for a game developer job before, but one thing I've noticed over the years is people have certain questions they ask and your experience level doesn't matter. You may miss out on good people if the interviewee can't answer a specific question, but consistency helps in comparing candidates.
 
I don't know about game development role interviews but if they are anything like current silicon valley software engineer interviews then the interview skill set is very different than the skills needed at job. There also is many applicants and people keep changing jobs every 1 to 2 years. This makes some companies hesitant on investing senior(expensive) people who have any obvious gap in the needed skills. I guess in gaming companies hiring could be game specific and there already is shipping date and very little possibility to teach people on the fly(unless it's junior/trainee role)
 
Last edited:
I'm involved in hiring and it's very frustrating. Everyone knows we're risk averse. We bypass great candidates if there are any concerns, but then still hire people who turn out awful - or worst of all, just good enough that they never get fired.
And we've done our homework: We have hiring experts design our strategy, citing studies, tracking our results, tweaking this or that. Our process still sucks and the experts nod sagely and say, 'You know, most hiring is the same as flipping a coin.'

But, the one thing the 'experts' will tell you is that testing sucks less than other approaches. We test first, before the phone screen, before you visit. And, yeah, they're stupid synthetic tests - we can't ask you to come in and work on a feature for a week. We have maybe 45 minutes and we want to learn all we can, and screen out most applicants. Yep, we prefer a strong filter, knowing we're screening out good people, because we just don't have time to interview everybody.

On the plus side, we do include what we expect in the tests we use: The person you're replacing had to shift a lot of bits, so enjoy some annoying bit-shifting problems. Or, this team uses homegrown data structures, this test will reveal something about yours. At least where I work, when we come up with new tests, everyone on the team tries them out. So, at least we know your peers don't find them too onerous.

Tests aren't the whole interview, they're just the thing to do first, when you have to balance success rate against manpower. If we had some other more accurate way of knowing you were good, we wouldn't do it like this. (I guess that's what good old nepotism is for.)
 
I'm involved in hiring and it's very frustrating. Everyone knows we're risk averse. We bypass great candidates if there are any concerns, but then still hire people who turn out awful - or worst of all, just good enough that they never get fired.
And we've done our homework: We have hiring experts design our strategy, citing studies, tracking our results, tweaking this or that. Our process still sucks and the experts nod sagely and say, 'You know, most hiring is the same as flipping a coin.'

But, the one thing the 'experts' will tell you is that testing sucks less than other approaches. We test first, before the phone screen, before you visit. And, yeah, they're stupid synthetic tests - we can't ask you to come in and work on a feature for a week. We have maybe 45 minutes and we want to learn all we can, and screen out most applicants. Yep, we prefer a strong filter, knowing we're screening out good people, because we just don't have time to interview everybody.

On the plus side, we do include what we expect in the tests we use: The person you're replacing had to shift a lot of bits, so enjoy some annoying bit-shifting problems. Or, this team uses homegrown data structures, this test will reveal something about yours. At least where I work, when we come up with new tests, everyone on the team tries them out. So, at least we know your peers don't find them too onerous.

Tests aren't the whole interview, they're just the thing to do first, when you have to balance success rate against manpower. If we had some other more accurate way of knowing you were good, we wouldn't do it like this. (I guess that's what good old nepotism is for.)

Whatever happened to asking the interviewee specifically what they worked on in vivid detail or asking specifics about their work? When I was in some interviews, I could ask someone to describe their application and how it works and most people actually don't know how to do that.. even the really smart people who have made Siggraph papers.
 
Whatever happened to asking the interviewee specifically what they worked on in vivid detail or asking specifics about their work? When I was in some interviews, I could ask someone to describe their application and how it works and most people actually don't know how to do that.. even the really smart people who have made Siggraph papers.
We still do that, after they pass a coding test. Obviously, a high quality interview is more work than just kicking back while someone takes a premade test. Since people fail the coding test most of the time, we start with that just to save ourselves the aggravation.

I've still been fooled. A surprising number of people will pretend (or maybe even believe?) they did all the work on a team project. Maybe they sat in a lot of code reviews and daily stand-ups, so they know lots of details, but a back-channel reference will say, 'Oh, that guy? Yeah, he always had a story about what he was doing, but we got suspicious and looked at his commits and, well... that's why he's on the market.'

The people who need the jobs the most will say anything to get them... Hiring sucks!
 
We still do that, after they pass a coding test. Obviously, a high quality interview is more work than just kicking back while someone takes a premade test. Since people fail the coding test most of the time, we start with that just to save ourselves the aggravation.

I've still been fooled. A surprising number of people will pretend (or maybe even believe?) they did all the work on a team project. Maybe they sat in a lot of code reviews and daily stand-ups, so they know lots of details, but a back-channel reference will say, 'Oh, that guy? Yeah, he always had a story about what he was doing, but we got suspicious and looked at his commits and, well... that's why he's on the market.'

The people who need the jobs the most will say anything to get them... Hiring sucks!

Check your PM.
 
Status
Not open for further replies.
Back
Top