JakeWorld

Last entry in the list of game developer team positions.

This time we’ll cover production, QA, Audio, Localization and everything else.

Management

1) Exec Producer

The Big Kahuna. This is the guy who is ultimately responsible for EVERYTHING on this project. Depending on the studio, he may have one project, or several he is responsible for. EA, for example, has one EP per project, whereas other publishers have one for several. This is where the buck stops, and this is the person who make the ultimate decisions on what the game is going to be, who it’s targeted at, what the platforms are going to be, budget and so on. He hires the Producers, leads and gets the ball rolling.
NOTE – while the EP defines what the game ‘is’, per-se, he is not the one carrying The Vision. That’s the lead designer. The EP says “This game is an fps, with a budget of $20m, and will take two years, with a team of 30. We will be targeting teenage boys, have semi-realistic graphics, no gore, be a sci-fi story, and have a space combat component. We will store back end player details in the cloud and we will have a small IOS app that precedes us.” Every decision that is made on the game going forward is measured against that criteria.

2) Producer

There are usually multiples of these guys on the project. He’s the guy who is keeper of the task list, the go to guy to provide whatever the leads deem are necessary to move the project forward. He knows how much is done, what is yet to be done and is often the final authority in terms of break deadlocks between the leads. What he is NOT is a designer, art director, programmer or anything else. The producer exists to ensure progress is made, and to cut that which is not working. He’s also a leader and needs to cajole, threaten, embarrass and compliment the team into great achievements.

3) Associate Producer

An AP is basically a producer-in-training. They are often the ones doing the tedious things, like updating exec spread sheets, checking in with developers to see how they are doing, taking notes in meetings, generating posters that indicate progress and so on. Think Intern, and you’ll be close.

4) Audio Lead

The Audio lead is responsible for all audio going into the game. Now, this doesn’t sound like much for your average game. A bit of music, some sound samples. Done. But we aren’t in 1995 any more, and that’s insufficient to the task. These days we have full on orchestrated music (Hans Zimmerman wrote some of the score for Call of Duty, for example), voice recording, foley effects (IE the sound effects of object use in game), and then straight forward effects. This is not an insignificant set of tasks, and it can be argued that audio in games has never had the attention to detail of priority that it should do.

5) QA Lead

QA. Quality Assurance. Testing. Man, this tends to get ignored as “The sweaty guys over there, in the basement”, but really is so massively important to building a big AAA game these days. While QA is often a different department, for the best results, they have to feel like they are part of the team. Invited to meetings, their opinion asked. The more integrated they feel, the more effort they’ll put into what they are doing.
QA has a huge job at the end of the project, dealing with iteratively playing your game to see what might have broken recently. Automatic testing of your game is a must, but automatic tests only tests that which you tell it to. Human testing tests So Much More.

Team

6) Music lead

Fairly obvious. Often this guy is the main composer too. Bungie had one for the longest time, till there was quite a falling out and lawsuits occurred. However, most studios has someone that creates everything, from small rifs and stings, to someone who can compose something for a complete orchestra. There’s even a group of studios who use midi, and need compositions in that (so they can control tempo and pitch). There is an extra dimension when games require seamless audio track switching – so when the player goes from walking to combat, the music changes and gets up tempo and more pulse pounding. Creating music that can do that, easily, is a tough ask.

7) Sound effect lead

This is your more traditional audio designer on a video game. He that makes all the blips and bloops. However, these days he’s usually creating sound samples, rather than programming an on chip sound device, like in the days of the Commodore 64. There is more to the job though – creating echo effects, atmospheric effects, and effects that may be modified programmatically dynamically, like changing the pitch and timbre of foot steps or combat noises.

8) Writer

This one seems obvious, but it’s actually a much harder gig than you might think. In the same way that novelists aren’t always good screen writers, traditional fiction writers aren’t always good video game writers. A good video game story introduces the next bit of gameplay, in a way that isn’t forced, and makes it matter; it gives the player a compelling reason to play and to win. The problem is that all too often, the story is pulled in late to basically tie together whatever the developer has already completed. And you end up with a convoluted mess. Video game writing is also hard because narrative is the enemy of interaction. It’s a toughie, this job.

9) Voice over producer

This is an offshoot of the newer, large narrative based games. Even back on Soldier of Fortune, we had a separate producer who held the voice recording sessions with the talent, who knew how to direct them and get what we needed. This is a skill, and not one that people on a game development team normally have.

10) QA Tester

Well, this one is a very obvious one, enshrined in the movie “Grandma’s Boy”. This is actually critical for releasing a polished game, and the dev team core will love you for being good QA. It’s actually way harder than you think as a job – playing the same game, over and over, and figuring out ways to play it that aren’t the obvious ways, looking for bugs and crashes – it’s actually a skill. Most QA testers get VERY bored of the game they test, and never want to see it again once it’s released.

11) Localization Team

This one is somewhat self explanatory. There is usually someone on the team tasked with managing external localization companies. Sometimes they hire people in house to do conversions of text / speech, but mostly it’s handed to external companies that specialize in this. What’s interesting is that this is way more of an art than you think – text (particularly UI text) needs to be roughly the same length in characters, so it doesn’t disturb how the screen is formatted, and that’s often hard to do (particularly in German, for some reason).

12) Community manager

Another fairly obvious position. The community manager manages, guess what? The Community! She usually runs the forums, patrols to ensure nothing outrageous is being said, and is also often the front face of the team to the community, relaying messages, interviews and sometimes even asking what the community thinks. This job needs a thick skin, a delicate touch and a ton of patience.

13) Mainline Ops

This is an interesting position, and it’s got more to do with games that use a lot of servers. Bungie’s Destiny, for example, is server based and as such Bungie will have an online team, maintaining those servers, ensuring they aren’t going down, analyzing data throughput, watching the database servers that contain persistent data and so on. These positions are becoming more and more important as time goes on – having a great game you can’t play because the servers are down just sucks.

That’s about it for general purpose positions. Some places have other, more exotic positions – Valve had an economist, for example, analyzing steam purchasing trends. Linden Labs has a full time economy balancer. Every studio / publisher / developer / genre has their own specific positions they fill – it’s just not the norm across lots of developers.

If I’ve missed anything obvious, please don’t hesitate to drop me a line – jakesimpson100@gmail.com

So Design. Yes… Design. Where most people who want to make video games want to end up. And nothing wrong with that!

So lets run down some of the positions, shall we?

Managerial

1) Creative Director

This is the top guy for designing. He’s the one who says “Lets make a game about ZOMBIES!” and then comes up with all the justification as to why, and why making a 1st person zombie vs Kardashians game is The Bomb and why people will want to play it. This individual sets the company goals in terms of what kinds of games it’s makes, how they are going to look, what the target demographic is, and is, in general, the holder of the high level vision of what the game needs to be.

2) Lead Designer

The Lead Designer is the guy responsible for the one game he’s on. Every design decision on that project rests with him. He’s the guy the lead artist collaborates with in order to ensure they get the look he is looking for. This guy carries The Vision about the specifics of the game around with him, and is constantly reviewing everything implemented to be sure that it conforms to that vision. The lead Programmer and Lead Artist are his partners, and they are there to provide him with that which he feels he needs for the game (and sometimes they are there to say No to him, when his requests are outside of the realm of their ability to provide.)

3) Lead Level Designer

This is kind of a genre specific kind of designer – it’s for games that have world navigation in them. He’s building out the architecture for a level, with a view to what the game play is going to be in that level. So he’s both world building, placing models supplied by the 3d modeler, and also designing the flow of how the player/s may be navigating that level – what events might take place, where, and where the camera might be when that happens. He’s part scripter, part game designer and part architect. And it’s not just FPS or 3rd person games that have this position – RTS games have it, even Tower Defender games have it.
I include this as a separate position simply because with the proliferation of FPS teams, it’s a pretty common one to have.

4) Lead Combat designer / UI / Game Genre Specific area

There are usually always area’s of specificness for each genre type that may well require a specific lead. Games like Uncharted, for example, will have a combat designer, as do games like Call of Duty. Mobile card games have a UI flow designer. Games like Rez have a sound flow designer. The Sims have Object Designers, who decide what features an object in the game will have, and how they will satisfy the sims needs.
Every game has different requirements, and each game will need different leads covering those requirements.

5) Lead Story designer

Like Level designer, it’s worth calling this one out as a specific discipline. Narrative games are built around story (Uncharted, Halo etc) and as such, the story is tightly woven into what the game is. Some places tend to use story as just glue for the next shooty bit, but some integrate properly. MMO’s also have this issue – new quests and story driven aspects need to be woven in and as a result, someone needs to both be creative and come up with what the intention is of the story telling aspect and also ensure that everyone else understands that and follows it.
They will also be writing cinematic scripts, directing the voice talent and even potentially directing the motion capture actors.

Team

6) System designer

A system designer is someone who takes a reasonably isolated system and basically, designs it. So, for example, a Quest system designer for an MMO will look at what is already out there, look at what the design doc says about Questing (which usually isn’t that much) and will then sketch out what Quests are, what they could be, the component parts of a quest, how they interact, how they are communicated to the player, how they played by the player, how they are considered complete, and what effect it has on the player once that is accomplished. They will sketch out ideas for tools to help design quests, and then write all this up, for use by coders and content creators later.
System designers may handle multiple systems in a given game.

7) UI designer

UI flow is a massive thing these days, what with so many games – mostly mobile – being UI only – card games and the like, and it’s very definitely a specific discipline. UI is more than just “What we put on the screen to show the player his score” these days. It involves the entire flow of screen to screen, what information is where, when it’s presented, how it’s presented, how it’s hidden and so on.
Companies like Apple exist purely on their UI display systems; IOS is superior to Android for exactly that reason.

8) AI designer

The AI designer is more than you might think. They design the behaviors of the game objects – which can be more than just “This npc goes here and does that”. It can involve creating day / night objects, objects to handle weather, objects to make the world turn, objects to handle gravity etc etc. The AI designer also deals with designing what the bad guys in the game can do, as well as the players abilities. I can jump – can the enemy? If they can, how high? Can they jump up on walls and ledges? How do they track you through the world? Can they see you? What about hear you? What do they do if they do?
AI designer has to cover a LOT of bases.

9) Environmental (level) designer

This was a big position at the FPS shops I worked at. Part architect, part game coder. Visual flow and game flow were paramount in the level designers position. Sometimes they’d be building cinematics, sometimes multi-player maps, sometimes boss fight spaces, sometimes run and gun situations. It was always different, and level designers are constantly trying to find new ways to have new experiences for the player.
The biggest problem with level design was (and is) building puzzles. Most of the time, when this happens, the player ends up playing the level designer, and what his solution to the puzzle he’s built is, rather than playing the Game.

The next post is the last part in this series. Production, Story, Audio, translation, QA and other misc jobs.

Art! Yes, ART! (little joke there for my old friend Les Ellis)

So, we’ve covered programming, in terms of team members. A second big entry in the team is Art. You’ll notice I left out world modeling / level design in this section. That’s because, to my mind, a lot of that is actually design. It’ll be covered in the next posting.

So lets run down some of the positions.

Lead / Management positions

1) Art Director

This is the top of the chain. He’s the one, like the lead programmer, who establishes the way that art is created at the studio. He decides if particular processes are going to be used, particular software, or outside groups (e.g., we are going to use company X, who specialize in face rigging, or group Y, to do our motion capture for us). He may also be the person who generates the style guide for a given project – what is the color palette, what kind of style is it going to be (comic book, anime, photo realistic, Lovecraftian etc).

The Art director tends to be involved with lots of projects at once.

2) Lead Artist

The Lead artist is on a specific project, and is the main person responsible for every pixel that appears on screen. He (usually) manages the artists, works out texture budgets, and assign tasks. He basically cajoles and judges the artist on their work, and is the final arbiter of what gets into the game art wise and what does not.

3) Lead Technical Artist

This can sometimes be a lead position, and sometimes not. Sometimes the lead artist is this. The Technical Artist is the one who works out _how_ things are going to be made. It’s apart from the tools creator; the tools programmer is the guy who goes to the technical artist and says “Ok, we need to have complete procedural animation going on. How are we going to do that? What does the rig on the models look like? What needs to happen here?”
He will work out potential new blend modes, talking with the shader engineer about visual effects, and generally work out the how what needs to be done from the art perspective.
Sometimes this role can ever be broken down further – lighting technical artist, animation technical artist, environmental technical artist, etc.

Team members

4) Concept Artist

A concept artist is critical at the start of a project – generating imagery (in conjunction with the art director and lead designer) that gives the style and design of characters and environments. She’s the one who helps develop the style, look and feel of what the game is going to be. She’s also the #1 thing that is pushed in pitches. Plus her stuff gets packaged up in nice coffee table books at the end of the project.

5) Texture Artist

Texture artists generate the actual visuals of what gets painted on the geometry. It’s even got to the point now where there is specialization within the texture artist genre – environmental artists, creature artists, people artists. It’s amazing how far this area has come.
They also do more than just textures  – there’s normal maps (IE making flat surfaces look bumpy when light falls on it), specular maps (making a surface look shiny), and many other aspects of added value (e.g. sub surface scattering heat maps) to a given texture to make it look “Last Of Us” good:)

6) 3D Modeler / Rigger

This person is the guy with all the Maya skills. And what’s interesting is that they don’t just build characters and enemies, but also objects and buildings for environments. They need to keep tabs on polygon counts and the like, and then they hand the models they make to the texture artist for texturing, and also to the rigger (in the case of animating models). The rigger may (or may not be) the initial modeller. The rigger creates a skeleton within the model, and attaches the individual polygons to that skeleton, and also creates handles for animators to move the model around. In the case of motion captured animations coming in, they also create a second skeleton in the model, that is mapped to the dimensions of the original actor (the actor may be 6 ft tall, but the model only 5 ft tall), with connections between the two skeletons that allow animations from a larger figure to be translates to a smaller or differently dimensioned model.

7) Animator

So this is a very “art like” job. Basically, it’s posing the model skeleton for key framing, and then creating animations from those frames. It can get more complicated than that – creating partial animations that get blended at run time with other animations already running (e.g. shooting a gun while running). This is a major artistic skill, and badly built animations are very very visible.

8) VFX Artist

This is another fun job – the creation of visual effects in a game. Particle effects, lens flares, animating backdrops, changing skyboxes, gun flares, the whole shebang. This is now a full time position at lots of the larger studios – BattleField, for example, has specialists in just gun effects, never mind the rest of the game.

9) Lighter

This is a relatively new position for video games. Movies have had it for years – a dedicated group of people who place lights and render the scene to ensure the lighting looks natural (or, in the worst case, dramatic!). I didn’t even realize that video games had this position until I was introduced to a bunch from Infinity Ward! So yeah, it exists.

10) Cinematics director

This guy! Now this guy has the fun part. He basically scripts out little cinematic events, using game assets. He decides where the camera is, where it moves to during a shot, what goes on in the shot and everything else. He’s literally a digital movie director. This has been a new thing recently, and it’s very visible with games like Last of Us, Uncharted and Halo, which are all narrative driven stories.

Next up: Design!

So yeah. There are lots of fledgling indies out there – two or three man operations, and they don’t necessarily have a background in what a large team makeup is. Who can do what or not.

So I thought, what the heck, I’ll have a go at categorizing them. I intend to split this over several blog posts, one for each discipline.

So lets start with Engineering. You know. The code monkeys. The number pushers.

People like me:)

Engineering used to be just ‘programmers’ but now it’s got several area’s of specialization. It’s important to note that lots of teams combine these positions. There often isn’t a need for a specialized UI engineer, or a dedicated Networking Engineer – are one person may be tasked in lots of different area’s. The differentiation I’m using here would be evident on 30-40 programmer teams, like Bungie or Infinity Ward have. Not your average 30 people team that counts EVERYONE.

We’ll work from the top down, I think.

Management

1) The CTO

This is where the buck stops. This is the guy who is ultimately responsible for all technical decisions made. If something cannot be done, or fails, he’s responsible. He ultimately ratifies all the decisions of those beneath him, and is the guy who says “Yes, we are going to spend $1.5m on an Unreal 4 license”. He does the strategic planning, looks around and says “everyone else is in the cloud, we should be do”. He holds the 5 year plan, and is aware of the industry and what is going in a general sense, and guides the technology plan for the studio at the top most levels.

2) The Technical Director (TD)

This guy has two different modes. The first is a back stop to the lead programmer. He’s not replacing the lead, he’s someone that is an independent verifier of the leads decisions. If the lead says “We need to spend X amount of time on Y system to do task X”, he’s the one who looks at the statements, verifies they are true and that the proposed solution will both fufil the requirements, and is actually do able. He will highlight area’s of risk – and in the worst case, rush in to help firefight if need be.
A TD will often have multiple teams he is working with, but traditionally, they do not report to him – he’s an independent entity.
The second mode is as traveling help for hire. He can and will be able to go anywhere in code and help build / fix / triage as is required. His technical knowledge in general is wide (and deep in some areas) but he’s not specifically tied to one project, working on many at once.

3) The Lead Programmer

The Lead programmer is the guy responsible for getting the game done. He’s the one who makes the plan about how the game will get done, who is going to do it, what the risks are, what outside software / libraries he may want to use to get the job done. He works out the tasks and either delegates himself, or he hands it off to a manager to do it (that’s how EA works). He is the touchstone that all other coders use, and he’s the one who has to know the entire codebase and what goes into it.
He decides coding standards, what the tool chain is going to be, and also manages any outside systems that are used (remote DBs etc).
A lead programmer should be on one project at a time.

4) Technology lead

It’s entirely possible that the engine your game uses is actually owned by another part of the company – a group who’s job it is to build and support shared technology. They don’t make the games, they make the technology that the games sit on. They take requests and tasks from the game teams, who require feature X so they can ship game Y, and implement them in a way that other teams may use that feature too.

Technology Coders

There are some specific area’s of technology worth pointing out.

5) Animation

Animation coding is one of those things that is almost solved – once you’ve got the system importing models and animations, and providing an API to blend them, you are done. Except you are not. Next comes the systems that decide _what_ animations you play, why, how long, and how to interrupt them if need be. Add to that the creation of tables to decide how which animations are available for selection, and you’ve got quite a task.
The best way this can be implemented is at a data driven layer – so it’s done by external tools and the code in the engine is entirely generic.

6) Rendering

This is a biggie, and there’s a lot of specialization in this area. There’s driver optimization, new features and then shader writing, which is an area of expertise all it’s own.
The bottom line is that adding new features, new ways of rendering and getting visual artifacts is one of the easiest to see upgrades a game can get.
It’s where all the glory code is:)

7) Networking

Networking is interesting, because networking needs to be thought of as part of the initial design of a codebase. You can’t just graft networking on after the fact; you have to be thinking client server architecture from day #1. Networking impacts so many different aspects of how your game engine works, it’s definitely a specialized area.

8) Audio

Audio tends to get relegate to also-ran status when making games, and that’s a shame since there is a ton yet to be done with this area. Correct audio bounce, correct obstruction, biaural processing, waveform distortion, environmental changing, musical beat matching for switching music tracks etc – there’s a lot yet to be solved with audio, but it gets short shifted because for lots of game devs, ‘good enough’ is good enough. The issue comes with gaming rigs with radically different audio properties, and the ability of the listener to even hear the small differences.
If you can get into it though, this will be an area of expansion over the next few years. I hope.

9) UI

UI (sometimes know as UX, although there is a difference. UI is what the text / menuing / information passing looks like on screen. UX is the flow from page to page – the decision of what info is present to you, and when that happens). This is increasingly becoming a large part of game design, given how complex games can be, and how small a screen you may be providing information on (e.g. Mobile).
Good UI / UX flow can often mean the difference between a good game and a great game.

10) Tools

Tools is often an entirely separate area of the team, complete with it’s own lead. Tools programmers are responsible for creating plugins to existing tools, creating a pipeline to get stuff from content creation tools, like Maya or Photoshop, and into the game in a game (and sometimes platform) specific format.
Tools are one of the biggest area’s of expansion in the last few years. Games often live and die on the quality of their content creation tools. Better tools = better looking and more content for games.
Tools engineers relate directly to content creation parts of the team, often working with them for requirements and what the content creators need tools to actually do for them.

Game Coders

10) Scripters / AI

Interestingly, this group can often be the hardest to hire. You need logical thinkers, who are also content creators. These people are crafting your game at the highest level – using a scripting language that (hopefully) doesn’t have to be compiled. They don’t need Visual Studio on their machine, just a text editor and understanding of how a high level language like C#, python or lua work. You need a programmer who is also a game designer.
For some reason a lot of the people hired for this position tend to be graduates; I’ve no idea why.

11) Pure Game Engineers

These are the guys who *just* make the game. They don’t build technology, they use it. They are like scripters, but in pure C/C++. They create game specific objects, cameras, input systems and create the actual game experience.
These guys have the most iterative job, in that usually their code will get re-written several times over the course of development, as they try things, they don’t work and a new approach is taken.
This is actually one of the most stressful jobs, because code is thrown away so much, and so much of the final product is dependent on their work. They are the equivalent of the Formula 1 driver – everyone else is building the car – these are the guys who actually drive it.

Misc

12) Development Support / IT

This is part of team that handles things like build machines – that fire a build of code every hour, or every time something is checked into Perforce. It also builds a test harness, so the game can be run through testing of features every night. Again, this is a heavy investment in time, but in terms of finding issues with features in the game, it’s a gold mine. Coming in in the morning and looking at a webpage of lists of features in the game that are broken, or the fact that the frame rate halved that day due to some check in, is massive.

13) On Team QA

One of the nice things that large teams have is a couple of on team technically competent QA guys. They sit in the corner, look at reported bugs and try running the game through the debugger, so when it crashes, they can come find you, and you can see the crash as it happened in the debugger, with stack trace and all.
To be clear, this is a massive luxury, but if your team can afford it, it can reduce your beta development time (the time at the end of the project, where you ONLY work on bugs, and not on features any more) by almost 50%, since you are fixing crash bugs as you go along.

14) Automatic Testing Engineer

This is something new – an engineer dedicated to writing a test harness, so the game can be automatically built and tested every night, using specific human written tests. This means it can look for reduction in frame rates, crashes, game functions that aren’t according what the design calls for, etc.
This can seriously impact a build’s stability and track when things go wrong, allowing the team to address it immediately.

So there you  go. There are more specialties – path finding, facial animation, visual effects coding, and so on, but those tend to be very specific for a specific game. A football game may have a dedicated person to create large crowds, for example, where as a fighting game would not.

So, next post – Art!

I’ve been in a fair few interviews in my time, that’s for sure. Some good, some bad, some horrific. Sometimes that horrific situation has been my fault, and sometimes it’s been the interviewing party.

Anyway, over the years, I’ve learned what I like and what I dislike in a technical interview, and I thought I’d share some these thoughts. As a jobbing engineer, I like to think I’m kind of everyman. I have some math – I understand trig and all the rest of it, but I don’t spend that much time thinking about Big O notation (for a good reason – I wait for the profiler to tell me I’m spending too much time in a function before I worry about it’s speed) or stuff like that.

This is a long post – a big wall of text -, but hopefully it’s worth it.

Obviously some of this stuff is wish list and in some situations isn’t possible – preparation, for example, can only happen if you are forewarned. But most people are, and still don’t do it and it just smacks of disrespect.

General Observations

1) Prepare. Don’t walk into an interview without having looked at the resume of the person, and at least looked at the websites of places he’s worked. If there are things to see – a blog, a set of lecture notes, whatever, then look at them. From the interviewee position, there is nothing worse than the guy you need to impress rolling into the interview and desperately looking at a resume that it’s obvious he’s never even seen before.

Far too many interviews are basically just the interviewer reading a resume and groping for questions to ask about each of the jobs you’ve had. It smacks of disrespect, and that’s a killer in terms of the person trying to get the job actually wanting it.

2) Have some questions prepared. And I don’t mean of the technical variety, I mean of “Who are you?” variety. You are likely to be working in close proximity to this person – and may even be working with them directly – and as such, you need to understand if this person is someone you can work with. Whether they are likely to arrive stoned, or drunk. Whether they have flash points regarding C++ Code notation layout. Whether they are going to drone on and one about the band Gwar etc.
Basically, everyone need to get a handle on cultural fit for the individual, way beyond the root question of “Can they do the job?”

Some companies break interviews down into separating out different parts – person A does technical acumen, person B does cultural fit. This is not a good approach. What it does is concentrate all of the potential elements that go towards a “yes” answer in one persons hands. If one person doesn’t like that the interviewee doesn’t know dot product, he’s now in a position to completely torpedo that application, regardless of what everyone else thinks.

Now obviously not everyone can do technical acumen – you need to be an engineer to judge that – but everyone can ask some questions about what the candidate is into, what they like to do on their own time, what their favorite repository is, biggest mistake they’ve ever made and why they thought it was, and what they’d do about it now etc. Questions that talk to what that candidate is – or at least thinks they are – rather than just “Can you tell me the code for Dot Product?”

NOTE: Be careful that your personal questions aren’t too personal. Run them by other people (or HR) first, just to be sure you aren’t contravening a law when you ask about the candidates family (in actual fact, that’s a no no anyway).

3) Do some of your technical questioning before the person comes into the office. By the time they get to the office – and are taking up resources time to sit and talk to them – you should already be fairly confident they can do the job from a technical point of view. Make them do a test – and don’t ever do that test while they are in the office. That’s just wasting everyone’s time. The fact is, you’ll probably get one day to determine if this person is going to fit into your team. One day. So the last thing you want to do is waste  it, putting that individual in a room by themselves, while they knaw on a pencil trying to remember the syntax for using STL.

It’s also worth pointing out that tests like this are entirely artificial. The fact is, if you employ them, they are not going to be working like this day in day out. They aren’t going to be standing and writing code on a grease board in front of three board mid level engineers. They’ll be looking stuff up on the internet, trying stuff, refactoring it and so on. The only thing that on site tests really tell you about a candidate is whether or not they do well in high stress situations where you’ve got a bunch of other engineers standing watching you and judging you, and where you can’t look up stuff. If that’s how your company operates as a norm, then you’ve probably got more problems than worrying about how your interviews go.

4) Your technical questions are not a competition, nor are they an excuse to hand out “Find me a pebble” questions.

I’ve had situations where I’ve walked into the interview and it’s become instantly obvious that the person on the other side of the table has their own self worth issues and needs to prove some degree of mastery over me instantly in order that they dominate in some way. I literally had one guy correct the very first thing I said – where I was being generic – and I just looked at him. In that instant I knew I wouldn’t take the job even if I was offered it, if it meant working with this guy. Any human who feels the need to establish a pecking order in the first sentence is not someone I want to work for/with.

Also, when it comes to technical questions, a lot of engineers either have their own pet questions to ask – where in reality what they want to know is “do you think like me?” They have a question that can have many answers and they have a favorite answer and if you don’t get it, well, you’ve failed. The reality is you haven’t read their mind or come to the same conclusion they would have, ergo you aren’t as good as them.

The bottom line is, I probably know as many really-hard-to-answer questions as you do, and I can ask them back, because my time is valuable too. If all you want to do is establish a pecking order, well, I can do that too, and make you look as stupid as you are set on making me look. Then what?

For many engineers – particular those with fragile egos – interviews are about proving they are better than the candidate (mainly because a lot have a worry that they are not, even though they’ve already got the job) – even more about discovering if the candidate is good in his own right.

The fact is, even if he gives you a different solution, that’s ok too. Explore that. Don’t get frustrated that he hasn’t come to the solution you would. Thinking differently is ok, and will almost certainly get you out of a jam some day, when you can’t see a solution and someone else can.

Also, be sure that your questions can be worked out by the candidate, and don’t require an either “you know it or you don’t” question. Examples of that are asking someone to write an STL vector prototype. If you don’t remember that off the top of your head, then you’ve failed – because there’s no way to work it out. This is why some of the questions from Microsoft in the 90′s were such a hit – asking “How many ping pong balls fit in a 747?” for example, or “How many gas stations are there in Seattle?” – these are all questions where it’s more about working out ways to get an answer than it is about what the answer actually is.
The more a question relies on some esoteric knowledge, the less valuable it is, because what it’s really testing is “Has this candidate come across this before” and not “Can this candidate work it out if he’s not come across this before”, which is what you should want to know.

And while we are on that subject, the more obscure the knowledge you ask for is, the more you as an interviewer look like a prick for asking it – this goes along with with point 1), where I’ve seen a lot of engineers, struggling to retain coder dominance in the interview, resort to more and more weird and specific edge case questions in a way of tripping up an interviewee. And lets not kid ourselves, this is exactly what it is – it’s not “exploring the depth of this candidates knowledge” – it’s a way of the interviewing coder feeling better about himself because he knows some obscure fact that the interviewee does not.

Also, asking for equations sucks. It just does. No one writes equations in code. If you need to know if someone knows the code for line intersection, don’t ask for the equation. Ask them to write the code.

Which leads me on to…

5) Ask for what you want. Don’t be clever and ask a leading question and hope to gently push the individual into what you really want. I had a graphics engineer once ask me for an early box discard algorithm – which is 4 if-then’s and that’s it; can’t get much quicker than that – but he wanted something else. In the end, what he wanted was a binary search algorithm. It took half an hour of me trying to figure out what it was he actually wanted. When I finally worked out what it was, I gave him his binary search algorithm, and then said “Look, if that’s what you wanted, then ask me for it. Don’t make me spend half an hour wondering what it is you want.”

It was done purely for the sake of the engineer in question doing it, and I have to say, it pissed me off no end.

Convoluted and obscure questions just waste everyone’s time and you may think you are clever for asking it; more than likely you are making the candidate roll his eyes internally.

6) Sometimes, knowing what the use you put something to is more important that knowing how it is generated. For example, Dot Product. If an engineer can describe what a dot product is (e.g., it’s the difference of angle between two vectors, described as from -1 to 1.) and give you four or five usage cases for it, that is way more important than being able to write the code from memory.

Some engineers put great stock by remembering formula by rote, and while there is some value to this, again, this is not normal day to day coding situations. If I don’t remember the code for a dot product, I go look it up. I spend some time comprehending what it is, write the code in my way, and forget about it until I need to do it again.
There is an argument that if you remember the source code, you ‘know’ the code, but that’s not actually real. Most coders who remember the source code couldn’t tell you what happens if you feed a dot product two vectors that are *not* normalized. If you can’t do that, then you don’t understand the root math.

Questions like this tend to show up a lot because they are easy to validate – either you know it or you don’t. Questions that really plumb how someone works are far harder – and require a lot more effort on the part of the interviewer – to set up.

The answer “I’d look that up” IS a valid response, even if you are mortally offended that someone doesn’t know the exact same things you do – or worse still, doesn’t associate the same value to it that you do.

7) Understand that your value system – of what’s important or not – is not going to be the same for everyone. Value systems are generated via experience, and by definition, everyone’s experiences are different.

Therefore, quite a lot of people will have very different reactions to what they see based on their experience – and sometimes the situation they are in too. Reacting to finding an incomplete API is very different when you have a deadline to get something done by, and find it’s blocked by this, than it is if you are just perusing the API docs and find something not quite right in it.

The problem with engineers is that they tend to be very black and white in what they believe. Way X is the “one true path” and everything else is just not. Any one who comes at it from a different point of view is therefore wrong, and to be argued with, in order that they see the error of their ways. Missing the point entirely that a) no one is likely to be swayed by your superior knowledge (just pissed off instead) and b) sometimes there is more than one way to skin a cat, and that’s – god forbid – ok.

8) Understand the guy in front of you is sweating, and wondering what it is that you want to hear, and will attempt to give it to you, regardless of the reality of their beliefs.

It’s an unfortunate statement that most people who are interviewing need the job, and therefore will contort themselves to be anything they can discern that you need. If you ask them leading questions, they’ll pick up on it and then try and mold the answers to whatever it is that they think you want.

E.g. “How do you feel about unit tests?” – that’s a leading question, and the right answer here is obviously “They are great, I use them all the time“. And that’s almost certainly the answer you will get, regardless of whether the candidate hates them with a passion or not.

You just aren’t going to get the truth by asking questions like this – that’s the reality here.

It’s taken me 25 years of interviewing to understand that I need to be myself in an interview, and not try and be what the interviewer necessarily wants. If I’m hired, then I’m going to end up being me anyway, and if that’s not what they want or can deal with, then I’m better off knowing that immediately rather than uprooting my family and moving across the world to take this job, and then find out that I’m really not a fit.

I don’t want to give anyone a false impression of me, so I have to be myself. If it’s not a fit then a) either I’m really not a fit or b) the people interviewing me really don’t have a good understanding of what they want. Either way, I’m probably not going to be happy there, and neither are they, so bullet dodged by both parties.

But most people aren’t like that, unfortunately (at least, *I* think it’s unfortunate). They want / need the job too much, so they’ll twist themselves into whatever pretzel they think the interviewer wants and then get the job and have a disastrous time because they are now going to revert to type. Life is too short for that I’m afraid – but most people haven’t gotten to the point of having it happen to them repeatedly, and haven’t learned that lesson.

9) encourage them to ask questions.

And what I mean by that is not “Do you do crunch here?” The point I am trying to make is that they have as much right to test your technical acumen as you have to test yours.

A lot of engineers don’t get that an interview is a two way street. They think “Hey, you are trying to get a job here. You have to impress me and not the other way around. I’m the one asking the questions.” Well, I’ve taken two jobs in my life where I’ve not done a technical due diligence on whether the people I am going to work with can actually get the job done, and in one case, it resulted in me getting stuck in Arizona for five years (and counting). Sure, I want to ask you about your technical abilities, what your development process is, how you QA stuff, what some of the biggest hurdles you’ve hit have been. If only to get an idea if some of the experience I have will be helpful.

Some engineers have their noses put out of joint when the candidate starts asking penetrating questions – this is an attitude that needs to be beaten out of people. They have as much right to know that you are going to work well with them as you do to know if they will work with you. The more that right is denied, the more you look bad as a potential employer.

Some thoughts on things that might be helpful.

I heard a story once about an engineer who, in his technical interview, sat down opposite the candidate, and then declared “I am a debugger. There is code that is crashing. It’s supposed to do X, but crashes when we do Y. What do you do?”

The interviewee then asked for more details, and the interviewer said “I’m a debugger. I can’t answer those questions. You can’t ask Visual Studio those questions and get answers – what would you do with Visual Studio?”

Eventually, the interviewee got the hang of it, and started asking things of the debugger that the debugger was able to answer – “What’s the stack trace?”, “What are the local variable values?”, “What does the source code look like?” and so on.

This is an excellent way of assessing how a candidate thinks, but while it’s great, it’s not without it’s problems too. The interviewer has to have all this stuff in memory and be able to reproduce it accurately, based on questions he cannot predict, and that’s difficult. One wrong answer and the candidate might not be able to solve the issue at all.

But, what it does tell you is exactly what the candidate would do – and it’s done in such a way that the candidate is more interested in what is going in in the interview than they are sweating out what they think the interviewer wants to hear.

One of the techniques I use now is to sit with a candidate, and describe a current problem I am having – what I know about the problem space, what the solution needs to provide and then say “Ok, what do we do about this? Lets work together on this.”

The idea is to mirror the experience he’ll actually have if the two of you collaborated on some design or implementation aspect, and get to see what he suggests. See if it’s off the wall, or what you were thinking or if he see’s issues you didn’t.

At root, you are attempting to see what happens in the real world of development at your studio, rather than the mostly artificial situation that an interview really is. How they work, how they think and how they collaborate.

Some great questions I’ve seen in my time include this gem – “Tell me, if I hired you, what would I most regret about that decision in six months time?” It’s a terribly leading question and really puts people on the spot because I guarantee you, they won’t have a prepared answer for that one.

The interesting aspect of that question is not what the actual answer is, it’s generally how long they take in answering it. Too long, and they are trying to find something that’s positive that they think you’ll accept “Oh, I’m too much of a perfectionist”. Or too little, and they are riddled with faults and are very quick to point that out.

Speaking of questions, the questions “Describe your greatest success” questions are interesting, but I’m not sure what they tell you about a candidate vis-a-viz the job in hand? “Describe your greatest failure” questions are more useful, particularly when followed up by the relevant “What would you do to avoid this in future” and “How would you fix that situation now?”

Something else I try and do is relax the candidate a bit. Most are pretty uptight – they need the job and want you to like / respect them. They aren’t at their best in this situation – almost no one is, so its your job to get them to relax.

At some point you need to say to the candidate “Look, there are no right or wrong answers here. There is no answer that is going to get you definitely hired or not hired. We are here to see how you tick and where your technical limits are. It’s not a problem that you have them – everyone does, and it’s all to do with experience. I’m just interested to know where they are. If you don’t know something, that’s ok – you aren’t being judged on that – I’m more interested in how you deal with something when you don’t understand it. It’s more a combination of everything. So relax, lets get some work done!”

Asking their opinion on something – asking why they did something, not in an accusing way but in way that asks them about their experience that brings out their conclusion – will grant you far greater insights into the candidate.

Also, ask them if they have questions and give them time to ask them.

Ask them if they want water or the bathroom. People do need to pee.

Last, remember, while you are giving this person a job and it means you’ll see them every day – which in itself is a big deal – for them it may well mean selling a house and moving a family across or continent, or even country. This is a big fucking deal for them. Please treat it as such.

The bottom line is, have some respect for the people who are sweating bullets in front of you, hoping to god they don’t say something you violently disagree with. Because they have no clue what you expect, what you want to hear or what is going to make you drop that black ball in the sack.

Hey, so my friend Cliff Bleszinski has announced a new games company, and intends to make an FPS. A fairly unsurprising event, to those that know him (and those that don’t, I guess).

Now, I’ve read some pretty vile bile regarding Cliff (and please not, I’m not referring to him as ‘CliffyB’ any more. He wants to be called Cliff – that’s his name – and I would like to respect that. God knows the guy has earned that respect.) and it’s pissing me off a bit.

Cliff really doesn’t need me to come to his defense really – he’s laughing all the way to the bank and frankly, he has a thick enough skin, belief in himself and his abilities, and the proof of having been instrumental in the development and production at least three very large Intellectual Properties that he’s doing just fine by himself.

But I can’t help myself. People who have a pop at him have no real idea of who he is at heart. What I see is a damn smart guy who loves what he does, and loves every aspect of it. He’s just both so enthusiastic and knowledgeable about what he does, it’s sickening in some respects. I wish I had a tenth of his knowledge or energy, frankly. The only two people I know who have the same level of experience and knowledge are George Broussard and John Romero (and seriously, spending an hour talking to this guy is like being dropped in the memory pool. He even remembers the balancing values for old RGP games. It’s astounding).

The fact is, yeah, Cliff has a hot wife. Far from people assuming he is lording it over them (which is an attitude that I’ve seen a bit), my feeling is “good for him. He’s proven it’s possible to be a geek and still have a life”. Cliff is something to aspire to be rather than “something to tear down”.

In my experience, people who have to tear others down do so because they realise – usually unconsciously – they’ll never attain those heights, are the worst of what humanity has to offer, and me being my fathers son, I cannot help but point that out. Particularly when it’s someone who so completely does NOT deserve that on the receiving end.

Sure, Cliff has a media presence too. So what? He’s a clever guy – he’s got an agent and that agent earns his keep. That’s why Cliff is on Jimmy Kimmel and you and I are not. It doesn’t hurt that he actually has a personality, is funny in person, and damn well knows what he is talking about.

Again, this should be something we all aspire to, not something to bitch about.

Cliff needs to be judged on the quality of his games, not whether Kotaku decides to feature him or not. The reality is that if you do that, the man comes out ahead in just about every way possible.

Anyway, again, Cliff doesn’t need me galloping to his rescue – but for what it’s worth, I wanted to say Congrats, and Good luck. Whatever he does, it’ll make a splash and be fun, that’s for sure.