Unity Developers Interview Preparation Guide

Download PDF

If you plan to work for a video game company, you'd better be playing games -- and you'd better be able to demonstrate that.

It's good form to mention some games that are in the same genre as the games made at that company. It's even better if you mention playing some of the games that were actually made there. Again though, don't go over the top.

At the very least, play the demo of anything they've produced. You need to be knowledgeable about the genre, what you enjoy about it, and how the development of these games is affected by the genre (as much as you can be). So research the company before the interview.

How you answer this question can be a deal breaker or a deal maker for hiring managers. They want to hire people who are demonstrably passionate about the games their company makes. Saying, "I have a level 70 mage in World of Warcraft and a level 40 druid in EverQuest," to Blizzard makes the point that you are immersed in its product genre.

Demonstrating some knowledge about older games also shows you're grounded in game history, which is never a bad thing. The wider your knowledge base, the more you can forestall going down blind alleys in terms of implementation and design, which benefits everyone, and that's exactly what a company is looking for in its employees.

► What are the core working hours?
► How do you assign or schedule tasks? Who gets to decide who does what and estimates time?
► What's the career path for this job? How do I get to progress? What is the process for promotion?
► What training approach do you use? How would I learn new skills?
► How are personnel reviews handled? Who does them and how often?
► Are there any specific development processes used here, for example, Scrum?
► Who would I report to?
► If I'm hired, what is the next game I might work on? How much input would I have on that?
► Is there a relocation package?
► What bonus structure or incentives are there?

► What is the best game that you made with Unity?
► Which app on the app store did you make most money from?
► How did you create asset bundles for your game?
► What do you think about the threading model in Unity?
► When would you use plugins?
► How can you call c# from Javascript, and vice versa?
► How active are you on the forum and answers sites? (What's your username?)
► What editor scripting have you done, and how did that go?
► What is one change/improvement you'd make to Unity?
► What source code revision software would you recommend using?

► Do you play games? If yes , then name your favorite ones.
► He/She will ask you something related to your favorite games.
► How would you design this mechanism in Unity and much more.
► How many games have you developed so far?
► Let's say I gave you a game which is lagging(poor performance), how will you find the bottleneck?
► How to find inactive gameobjects from script?
► What is the use of AssetBundle?
► What is batching?
► Can i change the script execution order?
► What are Coroutines? Does it run on different Thread?

► What do you like about gaming?
► What was the first computer or console game you played?
► What was your first computer?
► What's your favorite game and why?
► What's your favorite book? Movie? TV show?
► Do you prefer open worlds or well-defined quest lines? Do you think a game should/can have both?
► What's your favorite character class?
► How would you briefly describe the mechanics of your favorite game to a non-programmer?
► Do you usually play games to the end?
► What's your Beta test experience? (No, you're not looking for a QA person BUT it doesn't hurt to hire a programmer who thinks like a QA person at least a little, as in being able to vet their own work before they hand off a fix as "done.")
► What's your favorite game of ours and why? (If you've only published one game, they better have played it! And listen for their own words-if they sound like they're parroting what they read about your game, it's entirely possible they haven't actually played it.)
► If you could work in any other area of our industry, what would it be and why?
What makes a game fun for you?

The issue is that you can't modify the position from a transform directly. This is because the position is actually a property (not a field). Therefore, when a getter is called, it invokes a method which returns a Vector3 copy which it places into the stack.

So basically what you are doing in the code above is assigning a member of the struct a value that is in the stack and that is later removed.

Instead, the proper solution is to replace the whole property; e.g.:

using UnityEngine;
using System.Collections;

public class TEST : MonoBehaviour {
void Start () {
Vector3 newPos = new Vector3(10, transform.position.y, transform.position.z);
transform.position = newPos;
}
}

No. Texture and Meshes are examples of elements stored in GPU memory and Unity doesn't allow other threads, besides the main one, to make modifications on these kinds of data.
No. Fetching the Transform reference isn't thread safe in Unity.
When using threads, we must avoid using native Unity structures like the Mathf and Random classes:
class RandomGenerator : MonoBehaviour
{
public float[] randomList;

void Start()
{
randomList = new float[1000000];
Thread t = new Thread(delegate()
{
while(true)
{
Generate();
Thread.Sleep(16); // trigger the loop to run roughly every 60th of a second
}
});
t.Start();
}

void Generate()
{
System.Random rnd = new System.Random();
for(int i=0;i<randomList.Length;i++) randomList[i] = (float)rnd.NextDouble();
}
}

class Mover : MonoBehaviour
{

Vector3 target;
float speed;

void Update()
{
float distance = Vector3.Distance(target,transform.position);

// will only move while the distance is bigger than 1.0 units
if(distance > 1.0f)
{
Vector3 dir = target - transform.position;
dir.Normalize(); // normalization is obligatory
transform.position += dir * speed * Time.deltaTime; // using deltaTime and speed is obligatory
}
}
}

Often in game job interviews, you will be presented with a problem to solve, or even a full-blown test, depending on the position. It might be grease board work, it might be a conversation, it might be a level design test, it might even be a code test at a PC.

The premise is that the interviewer wants to see how you work. Often, once you've answered the question, the interviewer will change the parameters to see what you'll do.

But what do you do if you have no clue what's being asked, or if it's outside your area of expertise? That's a panic moment if there ever was one. Take a deep breath and realize that this is a moment where you need to say, "I'm not sure I understand the question," or "That's not something I've done before." But immediately after that, start asking questions about the problem and take a stab at solving it.

That's one of the biggest things you can do at this point -- admit ignorance then have a go anyway. Showing a willingness to try something outside your field of knowledge is huge to interviewers. It shows you want to learn and be more than what you are now. Sometimes, the fact that you tried is more important than the actual result, and sometimes, you'll have an interviewer who will give you hints toward a solution just because you showed that willingness to try. The more junior you are the more likely this is to happen.

Occasionally, interviewers will deliberately put you out of your comfort zone just to see how you'll react, so be aware!

The correct execution order of these event functions when an application closes is as follows:

Awake()
OnEnable()
Start()
Update()
LateUpdate()
OnGUI()
OnApplicationQuit()
OnDisable()
OnDestroy()
Note: You might be tempted to disagree with the placement of OnApplicationQuit() in the above list, but it is correct which can be verified by logging the order in which call occurs when your application closes.

The correct answer is 2.

The Update callback is called using a C# Reflection, which is significantly slower than calling a function directly. In our example, 1000 GameObjects each with a MonoBehaviour means 1000 Reflection calls per frame.

Creating one MonoBehaviour with one Update, and using this single callback to Update a given number of elements, is a lot faster, due to the direct access to the method.

Real time applications, such as games, have a variable FPS. They sometimes run at 60FPS, or when suffering slowdowns, they will run on 40FPS or less.

If you want to change a value from A to B in 1.0 seconds you can't simply increase A by B-A between two frames because frames can run fast or slow, so one frame can have different durations.

The way to correct this is to measure the time taken from frame X to X+1 and increment A, leveraging this change with the frame duration deltaTime by doing A += (B-A) * DeltaTime.

When the accumulated DeltaTime reaches 1.0 second, A will have assumed B value.

The inspector panel allows users to modify numeric values (such as position, rotation and scale), drag and drop references of scene objects (like Prefabs, Materials and Game Objects), and others. Also it can show a custom-made UI, created by the user, by using Editor scripts.

The project panel contains files from the file system of the assets folder in the project's root folder. It shows all the available scripts, textures, materials and shaders available for use in the project.

The hierarchy panel shows the current scene structure, with its GameObjects and its children. It also helps users organize them by name and order relative to the GameObject's siblings. Order dependent features, such as UI, make use of this categorization.

The panel responsible for referencing content in the build process is the hierarchy panel. The panel contains references to the objects that exist, or will exist, when the application is executed. When building the project, Unity searches for them in the project panel, and adds them to the bundle.

This is a common question in all job interviews. There are generally two kinds of responses: the brutally honest and damning one ("I get upset with people who don't carry their load"), and the sycophantic one ("I'm a perfectionist").

What most employers are looking for is an honest answer that is followed up with an example of something you have done to work on your weakness. For example, you can say, "My workspace tends to become extremely disorganized," as long as you follow it up with, "but recently, I've put in a lot of effort to go paperless, and I'm extremely systematic in the way I manage my email inbox."

The other secret to this question is not so much in the answer but how long you take to respond. If you answer too quickly, you might be suggesting that you already know all your worst points because they are blatantly obvious and you've been told so many times. If you take too long, it will seem as if you're searching for an answer that sounds good, doesn't make you look bad, and is something the interviewer would be happy to hear. Again, it gives the perception that you are being ingratiating rather than honest.

By the way, the best answer I've heard is, "I don't know. What do you think I'd regret in six months if I worked here?"

No. Collision events between two objects can only be raised when one of them has a RigidBody attached to it. This is a common error when implementing applications that use "physics."

During rendering, each pixel is calculated whether it should be illuminated and receive lightning influence, and this is repeated for each light. After approximately eight repeated calculations for different lights in the scene, the overhead becomes significant.

For large scenes, the number of pixels rendered is usually bigger than the number of pixels in the screen itself.

Deferred Lighting makes the scene render all pixels without illumination (which is fast), and with extra information (at a cost of low overhead), it calculates the illumination step only for the pixels of the screen buffer (which is less than all pixels processed for each element). This technique allow much more light instances in the project.

(This question implicitly includes, "Why do you want to leave where you are?" if you're currently employed.)

This question is an open opportunity to show you've done some research on the company where you're interviewing. All companies and interviewers are flattered when the interviewee knows who they are, knows what games they make, and wants to be a part of their experience. Do your homework and put on a good show!

Don't say things like, "I need a job," or "I need to move to Sacramento." Instead, pick a few things that are germane to the company in question. The more specific your reasons are tied to the company, the better. "I want to work on FPS shooters" isn't as good an answer as "I want to work on Game Franchise X because I played the first two games and still see potential for future growth of the product." It's sycophantic, yes, but interviewers are as prone to flattery as anyone else -- although don't give that as your only reason.

When explaining why you want to leave your current job, the trick is to not be negative. Pick a couple of points that are inarguable, for example, "There was no career development" or "They weren't working on the kinds of games I'm interested in," rather than "Their management is clueless and they are going to die soon." The game industry is a small community -- you could very well be talking smack about your interviewer's close buddy.

If you were let go or fired, it's better to say something like, "We decided to part ways," or "It was my time to leave," rather than go into too much detail, unless directly pressed. In that case, the interviewer probably already knows what went down and is just looking to see what you'll say. Answer the question quickly and without negativity, and move on. You want to leave a positive impression.

Normalization makes the vector unit length. It means, for instance, that if you want to move with speed 20.0, multiplying speed * vector will result in a precise 20.0 units per step. If the vector had a random length, the step would be different than 20.0 units.

Personally, I love this question because it reveals if a prospective candidate has a plan at all or is just drifting from job to job as so many are wont to do. There's nothing wrong per se with people who drift along the currents, it's just that those with a plan (or at least a desire to move in a particular direction) are generally much more interesting people. Plus, they are almost always inherently more predictable, which is always a benefit for employers.

Having a desire to move forward helps everyone. It helps you measure your progress, and it gives the company a plan to help you get there.

Of course, it does depend on you knowing what you want. Most people tend to know what they don't want, but not necessarily what they do want, which is a problem -- particularly if you express that in an interview. Interviewers would rather have a list of things you want to attain rather than things you don't.

One optimal answer is, "Still working for you making games," but it smacks of sucking up, so I'd recommend saying something a little more generic: "Still looking for a challenge and putting in that extra effort to make great games."

The best response I've ever heard to that question was, "I want your job!" and the individual who said it to me indeed has my old job! But be wary of sounding confrontational.

Vertex shader is a script that runs for each vertex of the mesh, allowing the developer to apply transformation matrixes, and other operations, in order to control where this vertex is in the 3D space, and how it will be projected on the screen.

Pixel shader is a script that runs for each fragment (pixel candidate to be rendered) after three vertexes are processed in a mesh's triangle. The developer can use information like the UV / TextureCoords and sample textures in order to control the final color that will be rendered on screen.

You'd be surprised how often this question comes up, even if you aren't interviewing for a design position. Everyone wants a developer who has design sensibilities because it inevitably means she or he will be more involved and engaged in whatever is going on.

Knowing ahead of time how you might answer this question means you'll come off sounding like you've actually thought about a game in development terms. Game studios are looking for people who think as they play -- about what they're playing, how it's done, what could have been improved, and most importantly, what they can rip off.

One downside to adopting this mentality is that it becomes harder to enjoy a game for what it is, but that's an occupational hazard in all jobs.

Believe it or not, you can answer this question in an entirely positive way. However, if you decide instead to criticize a design or implementation decision in a game, be sure you have a solution to the problem too. It's not enough to moan about the final strider battle in Half-Life 2: Episode 2; you have to have an idea of how it could have been made more enjoyable, perhaps through easier car control, or not destroying all the supply stations so quickly.

If you decide to bash a game that the company where you're interviewing developed (and that takes courage; some companies will applaud you while others will diss you for not drinking the Kool-Aid), then ensure that what you're criticizing isn't something subjective but something that everyone has had a pop at. Be ready to back up the criticism with proof that it's an agreed-upon flaw, not just you being nit-picky.

At smaller studios, this is the 64 million dollar question. My advice is to be 100 percent honest. If you won't crunch, say so now. It may well put you out of the running for a job, but ultimately that's a good thing. No, really, it is! If the company works a lot of overtime and you don't want to do it, then taking the job is going to be punishing for everyone.

Having said that, the last thing any interviewer wants to hear is, "I won't do it" because that predicates a perceived lack of involvement and passion (not that passion should equal overtime, but the perception of refusing to do something before you're even in the circumstances could be the difference between getting a job offer and having the company pass you up).

Phrase your answer in such a way that you don't sound confrontational with the interviewer. She doesn't want to get into an argument; she just wants to know where you stand. Understand that this question is meant to gauge, roughly, how you might fit into the company culture.

As a programmer, do you work on home projects? As a designer, do you doodle design ideas or make puzzles? As an artist, do you do portrait work?

Having hired many people in the past, one of the things I can speak to with authority is that those people who spend their off time working on discipline-related projects are the ones who are always up on current trends, have new ideas, are most willing to try something new, and will be the ones taking stuff home to tinker with on their own time. Now that shouldn't be expected of everyone, but the sad reality is that there is competition for jobs out there, and those who are prepared to put in the extra work are the ones that are going to be in hot demand.

Demonstrating that you learned C# over a weekend because you thought it was cool for prototyping is exactly the kind of thing a programming manager wants to hear. Suddenly your toolset expanded, and not only did it show willingness to do something without being told, it makes you more valuable.

The only care to here is to not mention an outside situation that might detract from or compete with your day job.

Everyone has a pet project they would want to make if they had the chance -- it's just inherent in the game developer psyche. This is your chance to expound on it, and the more realized your idea is, the more it will be seen as proof that you know what you're doing.

Taking an existing idea and adding, "but I'd make it cooler!" isn't the answer (the number of times I've heard Q/A staff wanting to become developers tell me they want to remake Counter Strike "but better" is staggering); it just shows you have enthusiasm, but no original ideas.

Bonus points if you can take an existing IP license and make a compelling argument for a game out of it. People who can actually do that are at a premium in our industry since most tie-ins, well, suck.

This is a general question that applies to all interviews. There are two ways to answer: the big answer and the little answer.

The big answer requires you to have some knowledge of how the company operates. Who does what? Your goal is to slot your experience, passion and skills (and if you are a student, your passion, skills, and desired career direction) into any holes the company may have -- and it should have some. Otherwise, why are they hiring?

The little answer is to name some of your previous experiences and best qualities and hope that's enough.

Care needs to be taken that a) you don't sound arrogant in assuming the company will die without you and b) you don't say negative things about the company. Statements like, "Well, you obviously can't do good Q/A. You need a good Q/A manager," are likely to go down like a lead balloon. Frame your answer to suggest that you would bring extra expertise, and therefore improvement, to something that's already in place.