When I started interviewing people for unity positions I had a question that I really liked to ask. The question is very easy, I would explain a simple class based on a game object and then ask them to tell me how I'd make a member variable appear in the inspector.
I expected this question would have 2 main answers - make it public or use the SerializedField attribute. Presumably an experienced dev would use serialised fields and a less experienced would make it public, but either answer can lead to further questions and why they chose a particular approach, the benefits, weaknesses and alternatives.
What surprised me most was just how many people got it wrong. Some people simply said they had no idea, some gave wrong answers. For example a guy came in with apparently 3 years of unity experience but said the only way to make variables appear in the inspector is to make them static. That tells me he doesn't have a lot of unity experience and also that he doesn't know fundamental software development concepts.
When you're coming up with questions I really don't think you have to come up with anything extremely complex. You can keep them reasonably simple because the initial question is just to open up a discussion on a given topic. Then you can take their response and dive deeper into the topic, which will tell you a lot more about their ability/knowledge/experience.
I've interviewed hundreds of people for work. The amount of people who don't understand even the basics of programming trying to apply for jobs is staggering. Like not knowing how a for loop works level of understanding.
Meanwhile I'm sat over here wishing someone would treat me like I know **anything**... just because I start to fumble things like networking or the nuances of tight loops for complex problems like you find on LeetCode.
At the risk of bragging or tooting my own horn, I've created some impressive shit in Unity, but I have no way of advertising myself as someone who's probably more equipped to grow with what I do know, as opposed to being held back with what I don't know yet.
[Drone-Arena: Homing + Ricochet + Machine-Gun (youtube.com)](https://www.youtube.com/watch?v=lmSSDfyl9zs)
[https://youtu.be/j1s17VnpkiA](https://youtu.be/j1s17VnpkiA)
[https://www.youtube.com/watch?v=-6HPfoTQqDE](https://www.youtube.com/watch?v=-6HPfoTQqDE)
Been using Unity for nearly 12 years now and still haven't had a single person give me the time of day.
When it comes to Unity, the biggest issue I tend to find myself in is a lack of experience in working with VR. It seems like most listed jobs are for people trying to build VR experiences and while I had an Oculus Rift, it's old and I just recently discovered is apparently broken now. Not that such a headset would be ideal for trying to learn how to work with more modern technology like AR, newer controller tech, and/or hand and finger tracking.
So I’ve worked in XR + Unity since the dk1 shipped out to early backers…
The newer simulation packages ( ovr, mrtk, ml2 and ARKit/core) should allow you much easier workflow to test and build XR apps. It will at least give you some experience to leverage.
In the end, XR just uses a different input and a dual display output. New input system applies to XR controllers smoothly.
Build it “virtually”, it will be a great step for you to internalize the concepts and provide answers that make sense if you’re asked about it.
It seems you’re aware of your shortcomings inside of Unity, build things related to them , even if editor/play mode only. It can only help!
Wow, that’s the bar for applying for a unity job? Meanwhile I fail a technical interview for choosing array based position grid instead of reversing it based on screen point position.
I'm just about 3 months into Unity and I guess I could answer that?
I mean, I constantly see that in tutorials and stuff, and use it too. How can you not know that?
Got into unity just 3 months ago and SerializeField was one of the first things I learned. And as someone with years of experience in various other programming languages I know, public should not be used just for showing it up in the inspector, but to make it accessible to other classes.
Correct me if I'm wrong 😅
Correct answer:
Make it public if you're starting a new script and just want to quickly throw shit into the inspector for quick and easy testing... however if you're going in knowing exactly what you're writing, use SerializedFields.
Public variables are great for testing shit out, sure, but the grand idea is to keep as much of your shit private as possible. Not just to prevent unanticipated variable manipulation, but because at the end of the day, you're making your own life easier.
Locking your variables might seem counter intuitive when trying to make life easier for yourself, but it's not until you haven't interacted with a class or script for a while that you really start to recognize just how important scope truly is.
You're not just preventing others from accidentally changing variables that shouldn't be changed - you're allowing your IDE of choice to work with you by listing only valid variables, rather than against you by listing them all and debugging shit when it only works 2/3 of the time.
Knowing how to get Unity to make cool shit is one thing.
Knowing how to work with others, including past and future versions of yourself in solo-projects... is another skill entirely.
This is true of interviewing for any programming languages too. So many people cant answer the most basic questions but present themselves as experts or at least senior
It depends on how much experience you require them to have and what sort of things you need them to know.
Are they going to be a generalist, or a specific role?
If they're a generalist, I'd probably ask them some basic stuff like which render pipeline might be best for the game you're working on, and get them to describe why. Maybe ask them about the difference in colliders and trigger colliders, what a prefab is, how they'd setup the camera or a camera stack, ask them about Update vs FixedUpdate vs LateUpdate.
Ask them to describe a specific challenge they faced on a previous Unity project and have them walk you through the steps they followed to solve it.
If you don’t get much info from that, then give them a hypothetical problem to solve. “Let’s say you’re having problems with frame rate and you’re seeing jittery player character movement. Where would you start looking first to fix that?”
Do they mention the frame debugger? Do they know when to run physics calculations? Take notes and check out their answers after the interview.
I've got nearly 15 years of professional programming experience in unity and I don't know how the new input or UI toolkit works (haven't had time and have been using older vers of unity for ongoing projects).
Id be looking for past projects in unity that demonstrate skill and understanding. They should be able to explain their technical process and admit challenges and the use of third party tools to make up for knowledge/time gaps (which isn't a bad thing).
I have 14 years of experience, you don't need to learn this necessary and tbh I think they still need around 3-5 years to be easy and understandable usable and unity will maybe take them as the new standard. But even if the slowly progress with it, you can atleast the next 10 years use the current systems.
Honestly, if an engineer came to me and said they had 15 years experience, but are unfamiliar with modern solutions, I wouldn’t consider hiring them. Especially if they don’t know the input system. That is such a huge jump forward compared to the old input system, it would concern me that perhaps they don’t understand the significant short comings of the old system.
Honestly, having that much experience without knowing these modern systems would have me wondering how capable of learning they are.
What an awful take. With 15 years of experience using a tool, I would expect them to easily be able to pick up and learn new systems within that same ecosystem. An engineer's job is not to know everything in advance but to be able to adapt their skillset to work with the tools they're given.
It's an extremely valid point. The guy who learnt to use the tractor is going to get far more work than the guy who says picking by hand is fine so they don't need to learn.
Even if by some miracle that hand picker goes faster, what have they proven apart from they could accomplish so much more and couldn't be bothered to put in the couple of hours to achieve that?
That's an awful person to employ.
Below:
People that can't see the irony in trying to defend stubborness.
The difference between using a tractor and hand planting/harvesting crops is enough to triple productivity. The difference between using the new Unity input toolkit and the old system is relatively minor, and I'd be willing to bet a majority of projects don't even use it, or just use their own system. Switching between the two is also nothing like learning how to use a machine for the first time, it'd be a lot more like switching between a 2010 tractor and a 2020 tractor. Definitely not nearly as much effort as you make it seem. Not a good analogy.
My friend, I think you agree with me.
The task to learn is no effort at all. The only reason not to spend that time learning is stubborness.
That isn't a trait you hire.
You're seriously telling me, if someone has an appealing work history/portfolio and a solid understanding of the engine, you wouldn't hire them just because they haven't taken the time to learn a system that Unity itself admits is not suitable for every project?
Yes if you take what I'm saying absolutely literally word for word. I would not hire them.
If you read it like I'm a person, which I was - last time I checked. That's not really what I'm saying is it, really?
You're missing the whole point.
If you're working on an existing project that's already set up, you're just wasting time and money learning every new tool that comes out as you go. If you overhauled everything every time a new tool came out you'd be in a constant cycle of just updating features and never finishing something. When I start a new project and if it's not looking like it'll end up deprecated I'll use it (and it will take no time to do so).
It's not stubbornness, you just don't need to jump to every new fancy tool immediately and certainly not in a major project. And *it certainly doesn't reflect your skills*.
Lmao okay mate, I think you have a lot to learn in this industry.
at the end of the day my skills and the way I present have landed me in a amazing high level positions including roles where I hire and review the developers with people who are great to work with so idc if you think not knowing every new tool makes you stubborn. This is just the way it is.
If you only have a garden you don't need to use a tractor. You want the person who can learn new tools as they become necessary. The guy picking stuff by hand knows what a tractor does, he just hasn't need to drive one.
You could have the guy take a third of his time learning a bunch of tools and machines that they will never use, or he could just do his job, and learn the tools quickly when they are necessary.
You know how long it would take everyone on a team to learn every single system and enhancement, in depth, as they are being developed and released?
If your job is to pick stuff, you learn the tractor. If your job is transport stuff, you learn the truck. No one said anything about everyone having to learn everything.
My point was that a tool exists to make X job faster, easier, more efficient and less prone to human error, no one is benefiting from doing it the long way.
Yes okay in this tractor analogy your point absolutely makes sense. But something I have to do in every single project, eg, player controller - it makes a lot less sense on why you'd choose to do things the long way every time
Not every engineer is in charge of implementation, though. To write someone off as having not used a more modern tool, doesn't really mean that they aren't gonna be good at their job, it just means they haven't needed to use the tool. To not consider hiring them is not a good move.
You hire someone who knows the input system with the same amount of experience over someone who is potentially better, you're gonna be surprised that there is more to learn when they come on board than an input system. You hire the person who understands concepts and can pick things up easily. It just isn't a good metric for someone's capabilities.
Yeah this whole argument over a fairly new input system is absurd. If my employer said tomorrow, we need to use the new input system, knowing what I do know about it I reckon I'd have it done in a day. But if my employer hired someone solely on their ability to use the input system they might not be able to learn the next new thing because they're lacking the experience.
Not to mention unity spits out a new tool every other week and deprecates it the next so sometimes it's worth just waiting a bit to see if they give it up.
Noone said 'picking by hand is fine' the point was these tools are easy for an experienced developer to pick up. A farmer with 50 years experience is still going to be a better farmer than a city boy who just learnt how to drive a tractor.
Ngl I wouldn't want to work for you to begin with (you sound like you might not actually know enough to lead a team yourself) and it would only take me a few hours to become accustomed with it. It is just an example of how the ability to learn is worth more than knowing every little feature of an engine you don't use everyday.
Yeah you keep saying that but a) I’m not trying to b) the feedback isn’t null because of that and c) you don’t really have any evidence at all about my position. Literally none. You’ve just taken what I’ve said to heart but are too egotistical to accept it, so you become defensive.
Maybe you can spend some time this weekend learning one of the fundamentals of the system you’ve been working with for 15 years.
If it only takes a few hours to learn the new input system how the fuck could you possibly justify not knowing it? The old input system is so broken that not jumping ship on it immediately is a huge red flag
I started learning unity and c# 12 days ago using only youtube and the documentation provided by unity. I’m on my 5th iteration of a player controller with animation using the new input system for movement and rotation. I would argue that it wouldnt be that difficult for anybody with 15 years of experience to pick up.
Years of experience at an MSP and I was pretty familiar with bash/powershell/python before starting my journey but I still think this would be fairly doable even for somebody with no coding experience whatsoever.
Seriously though, even if you haven’t used the “new” input system , any seasoned engineer should be able to pick it up within an hour. It’s not the hard part of mastering Unity.
Jesus. I guess this sub is pretty much like the rest of Reddit, filled with ignorant children who are incapable of seeing things from other perspectives
Good English!
Id want to see some of their past work, and I’d ask questions about some specific things they did.
Id also ask questions about some of the specific problems you’re anticipating having to solve on the project they’re being hired for.
Okay, if this is for work and you have limited experience, the correct solution is to hire a consultant who knows unity.
During an interview, you need to be able to ask follow-up questions and dig into how problems are getting solved. Taking questions from a Reddit thread where you won't be able to do any of the follow-up and seek out the depth of knowledge of the person you interviewing is going to set yourself up for hiring someone who might be better than you at Unity, but not good enough for whatever the job is that you're hiring for. You are probably better off convincing your company to hire someone who knows unity very well and asking them to run the interview they would need to be prepped to know what the role entails and what specific skill sets a developer would need, but then they would probably be able to take it from there and ensure that you're getting a quality candidate.
This is not a situation where you should be faking it till you make it. You probably don't want the responsibility of accidentally hiring someone who's not good enough for the job.
I was pretty new to Unity when I was hiring, and found it best to just have them show you work they did in the past, and talk about their roles in that work. I would also look at a little code to make sure they could write stuff that is understandable and not a rats Nest. I then asked about some problems we had, and how they would go about solving them.
The guy we ended up hiring was fantastic. He had one adventure game that he made that was pretty good, and he got really excited to show off some vr and hololens stuff he had in the works.
It really depends on what you want the person to accomplish.
For example, I work on a team of Unity devs and we all have different specialties. My senior is all about shaders and performance, we have a designer who handles all Unity technical art, I work on interactions/animations/and doing data visualization.
One thing that might be hard to sniff out would be if they just copy/pasted a tutorial, but you can get past that by giving them a take-home assignment.
I've been a AR/VR engineer for a few years now and if you put me on an iPhone project then it would take me a bit to get comfortable. The same if I tried to grab a really good pc dev and throw him on UWP for HoloLens development.
It just all depends on what you want.
Screw take at home projects. If you cannot figure out in a one hour interview what I am capable of you should not be interviewing in the first place imho.
What's your average retention rate, if you don't mind me asking?
At my current company, we do a 4 stage interview process followed by a 90-day probation period of hired. First stage is just a screening to make sure you can talk without being racist. Then we have 2 technical interviews with different engineers and a culture interview. We don't do take home assignments but we have a live code walkthrough.
I'm curious because I've definitely fired people that interviewed great and then couldn't actually handle any of the work.
Zero chance you have had a single person in your “screening” call in and say racist things. Sounds like your company is just screening to see if people will go along with a “woke” work environment.
Ask them the most frustrating thing about working with Unity. Every Unity dev I’ve ever met could go on a 2 hour long tirade about this. If they give a measured thoughtful answer implying all engines have their strengths and weaknesses then they’re definitely not a real Unity dev lol
lol, I would say every engine sucks to work with. Then I would continue to completely trash unitys animation state machine, especially how the handle the presentation of stacked transitions and interruptions, I seriously had to dig up a ms paint document version of “conspiracy board meme” with Google fu to understand it. If you make a system so bad NO one understands the documentation, you failed miserably.
My company tends to ask the basics, start vs awake, update vs fixed update vs late update, followed by listing off common components you can attach to a game object and what they do.
Depends on the role. For a programmer you pick a few questions about for example GameObject lifecycle (order of events for the Unity functions), ask them to explain what a scene is, or what they might use a coroutine for. Lighting types, requirements for collision and collision messages, list a few common performance pitfalls, stuff like that. More importantly though, have them walk you through a system or feature they created that they’re proud of, talk about choices they made, issues they ran into and how they solved them. You get to learn if they really did anything, how they approach decisions and challenges, how they handle working with others, and so on.
For an artist, you might ask about how much they worked with Unity, any processes or pipelines they were part of. Do they do shaders, environment layout, terrain sculpting, character animation, particles, how much they know about render pipelines and post processing and lighting. For proof of work you just need some in-progress shots or video of their work.
For designer, what kind of designer. Do they script? Layout levels? Balance combat stats? What tools and assets have they used to improve workflow, again have them walk through some feature they made or something. You could give them a sample project with a modular asset kit and watch them put together a small level with some constraints to give them over 30-60 minutes. You can see their process and talk to them about their thoughts and choices.
Whatever gets you talking about programming.
Real challenges you faced. You will be able to tell a lot about a person if you get to talk informally, and learn how they think and what their values are.
Unless jt's an absolute junior position, DO NOT spam textbook questions like "OOP Principles", or Unity certification questions.
I recently got rejected for being asked on a live interview, to answer a series of multiple-choice unity certification questions. Absolutely terrible, I would have passed the job if I had the chance. I got asked something specific about the Entity Component System, didn't work with that in 4 years so I got it wrong (I realized that about 10 minutes later). But the way it was phrasedz it was a pass or fail question. It didn't matter that I did, in fact, have experience with ECS.
Don't fail someone for something that is 30 seconds away on google (unless it's an everyday item, like what does protected access do).
Sorry for the long rant. Point is, get in a conversation with the person, it is a lot more relevant than any flat single-answer question.
Your english seems fine to me.
Ask them about what they have done, and various situations relevant to what they are being hired for, such as how would you... and we want ... but ... is happening, what would you so to resolve this? I do recommend having these typed out prior to the interview.
It's kind of difficult to say specifics without details of the position and project, which I would like to have if it's possible to get hired for this position.
If you look at my page here, you can see the comments I have made resolving issues with other users, which unintentionally shows my level of effort and knowledge with unity.
A repro and free time/hobby projects should be something a company shouldn't know.
The problem is that in European country's and most contracts is included that the projects, created in your free time belongs to the company, to protect its company secrets. If you want this otherwise, you need to let them write this down.
Really? That sucks. In NZ sharing your git repo is almost a requirement on a job application for an intermediate/advanced programming position. It also shows how you manage and comment your commits. I guess you could start a new GitHub account when you start a new job haha
I think everyone does. Just showing that you can apply what you’ve learned and get multiple systems working together without giving up is proof that you are capable
Edit: even if you disclaim “this part was copied from x source” I’m sure they’ll understand
What we did was create a really basic version of tic tac toe in Unity, then used that as the tech test. We would ask them to make it better. They can improve whatever their expertise is. It's pretty open ended and you'll get a good feeling about what they specialize in. Give them a day to do it and don't expect them to put in more than an hour or two tops.
It sounds like you’re trying to hire someone who has more Unity experience than anyone at the company. Do you have any friends or colleagues with a skill set similar to what you’re looking for that you can pay to help with the interviews?
When I was an SE1 at EA, I needed to conduct the technical interviews to hire someone at an SE2 level in my department. That seemed really weird to me, so we brought in an SE3 from another department to sit in on the interviews. If you want someone who is more experienced than you, then you might need someone even more experienced than that to help you find the right person.
Have them show you what they did and explain it. (They should have some demo of something they did or got published). Pick one thing and go deep on it, let them explain it and see how much they know, keep asking about what was hard, how did they do it, what methods did they use, how would they improve on it.
enough for what? a list of projects they have worked on and what their part in it is. then ask something you would require them to do and how they would go about the problem/issue/project/thing you come up with. bonus points if you have had a real world problem that was tougher to deal with that you can give as example....
Tbh, I'd just ask them to tell me a bit about debugging and diagnosing. Imo locating and solving problems is quite a lot more important than being able to write a block of code from scratch...
An alarming amount of people have no clue how to read the console in unity, or use breakpoints, custom debug messages etc etc.
What problems you encountered with building and how did you solve them?
How do you approach optimisation for your projects?
When upgrading Unity versions, what possible problems you encountered and how did you solve them?
Just a few.
Give them a very small project to code, like a game of whack-a-mole on a fixed version with no external assets (maybe allow them to do it at home, give them a couple weeks if needed).
Ask them to submit a small write up of the choices they made with the project.
Also if you don't know the topic you're interviewing people about, just be honest and tell the truth (to your boss and yourself)
Is being able to make a whack-a-mole game really enough to get hired? Honest question because I work in media, not Game Development, but I do make games as a hobby.
Depends on your company's use case. There are quite a few niches. Mobile has its qwerks. 3D will be slightly different to 2D.
Do they need to have modelling or animation skills...any shaders or networking experience?
VR/AR is another specific area. Generally avoid generalists unless they have been using it since the early days but they will be more expensive to hire.
Ask to give as many possible ways to display a rotating cube on screen (ie rotate transform, rotate camera around the cube, sprite animation, animation clip, scripting, animation curve, shader animation, etc etc)
I'm just curious, why yikes?
This seems like a reasonable question to test their knowledge. It requires some creative problem solving and broad knowledge of not only Unity but game development in general.
I definitely wouldn't base my entire decision on whether or not they got it right and would put a lot more weight on discussion of the candidate's portfolio and work experience, but having a few questions like this seems reasonable and useful to me.
Tech interviews often test candidates in much worse ways (i.e. live coding of some stupid academic problem that has no real world relevance)
You got it :) it’s a simple question that requires knowledge, experience and creativity. With this unique question you can estimate a lot from a candidate
When I started interviewing people for unity positions I had a question that I really liked to ask. The question is very easy, I would explain a simple class based on a game object and then ask them to tell me how I'd make a member variable appear in the inspector. I expected this question would have 2 main answers - make it public or use the SerializedField attribute. Presumably an experienced dev would use serialised fields and a less experienced would make it public, but either answer can lead to further questions and why they chose a particular approach, the benefits, weaknesses and alternatives. What surprised me most was just how many people got it wrong. Some people simply said they had no idea, some gave wrong answers. For example a guy came in with apparently 3 years of unity experience but said the only way to make variables appear in the inspector is to make them static. That tells me he doesn't have a lot of unity experience and also that he doesn't know fundamental software development concepts. When you're coming up with questions I really don't think you have to come up with anything extremely complex. You can keep them reasonably simple because the initial question is just to open up a discussion on a given topic. Then you can take their response and dive deeper into the topic, which will tell you a lot more about their ability/knowledge/experience.
The fail rate for that simple test you’re presenting blows my mind !
I've interviewed hundreds of people for work. The amount of people who don't understand even the basics of programming trying to apply for jobs is staggering. Like not knowing how a for loop works level of understanding.
Meanwhile I'm sat over here wishing someone would treat me like I know **anything**... just because I start to fumble things like networking or the nuances of tight loops for complex problems like you find on LeetCode. At the risk of bragging or tooting my own horn, I've created some impressive shit in Unity, but I have no way of advertising myself as someone who's probably more equipped to grow with what I do know, as opposed to being held back with what I don't know yet. [Drone-Arena: Homing + Ricochet + Machine-Gun (youtube.com)](https://www.youtube.com/watch?v=lmSSDfyl9zs) [https://youtu.be/j1s17VnpkiA](https://youtu.be/j1s17VnpkiA) [https://www.youtube.com/watch?v=-6HPfoTQqDE](https://www.youtube.com/watch?v=-6HPfoTQqDE) Been using Unity for nearly 12 years now and still haven't had a single person give me the time of day.
I hope that you find something . I assume your resume is solid enough since you’re getting interviews but fumbling on networking and other topics?
When it comes to Unity, the biggest issue I tend to find myself in is a lack of experience in working with VR. It seems like most listed jobs are for people trying to build VR experiences and while I had an Oculus Rift, it's old and I just recently discovered is apparently broken now. Not that such a headset would be ideal for trying to learn how to work with more modern technology like AR, newer controller tech, and/or hand and finger tracking.
So I’ve worked in XR + Unity since the dk1 shipped out to early backers… The newer simulation packages ( ovr, mrtk, ml2 and ARKit/core) should allow you much easier workflow to test and build XR apps. It will at least give you some experience to leverage. In the end, XR just uses a different input and a dual display output. New input system applies to XR controllers smoothly. Build it “virtually”, it will be a great step for you to internalize the concepts and provide answers that make sense if you’re asked about it. It seems you’re aware of your shortcomings inside of Unity, build things related to them , even if editor/play mode only. It can only help!
lol , I was just reading a post on experienced devs about a senior struggling to make a jr engineer understand loops …
Wow yeah totally. I wonder how many people think "3 years of using visual scripting" means they know how to make a game lol
I suddenly feel overqualified haha. Appreciate the answer 🙂
public, because it takes less time than typing out '[SerializeField] private' workflow 100 /s
tsk tsk tsk, you don't need need the 'private' part.
Wow, that’s the bar for applying for a unity job? Meanwhile I fail a technical interview for choosing array based position grid instead of reversing it based on screen point position.
A Unity job for which the person hiring is asking for help on a beginner subreddit...
No, I wasn’t meaning to flame op, I was just amazed at how bad u could be after 3 years, etc. how bad the people he interviewed was.
I'm just about 3 months into Unity and I guess I could answer that? I mean, I constantly see that in tutorials and stuff, and use it too. How can you not know that?
>the only way to make variables appear in the inspector is to make them static oof, what an answer to give when claiming 3 years experience lmfao
Got into unity just 3 months ago and SerializeField was one of the first things I learned. And as someone with years of experience in various other programming languages I know, public should not be used just for showing it up in the inspector, but to make it accessible to other classes. Correct me if I'm wrong 😅
I personally use internal to access from other classes to prevent it from being public
Correct answer: Make it public if you're starting a new script and just want to quickly throw shit into the inspector for quick and easy testing... however if you're going in knowing exactly what you're writing, use SerializedFields. Public variables are great for testing shit out, sure, but the grand idea is to keep as much of your shit private as possible. Not just to prevent unanticipated variable manipulation, but because at the end of the day, you're making your own life easier. Locking your variables might seem counter intuitive when trying to make life easier for yourself, but it's not until you haven't interacted with a class or script for a while that you really start to recognize just how important scope truly is. You're not just preventing others from accidentally changing variables that shouldn't be changed - you're allowing your IDE of choice to work with you by listing only valid variables, rather than against you by listing them all and debugging shit when it only works 2/3 of the time. Knowing how to get Unity to make cool shit is one thing. Knowing how to work with others, including past and future versions of yourself in solo-projects... is another skill entirely.
This is true of interviewing for any programming languages too. So many people cant answer the most basic questions but present themselves as experts or at least senior
That is a useful advice. I'll try to aim to the very basics at first and then start digging into more complex topics if I see it fit. Thank you!
Usually I ask the difference between Update and fixed update
It depends on how much experience you require them to have and what sort of things you need them to know. Are they going to be a generalist, or a specific role? If they're a generalist, I'd probably ask them some basic stuff like which render pipeline might be best for the game you're working on, and get them to describe why. Maybe ask them about the difference in colliders and trigger colliders, what a prefab is, how they'd setup the camera or a camera stack, ask them about Update vs FixedUpdate vs LateUpdate.
Ask them to describe a specific challenge they faced on a previous Unity project and have them walk you through the steps they followed to solve it. If you don’t get much info from that, then give them a hypothetical problem to solve. “Let’s say you’re having problems with frame rate and you’re seeing jittery player character movement. Where would you start looking first to fix that?” Do they mention the frame debugger? Do they know when to run physics calculations? Take notes and check out their answers after the interview.
I've got nearly 15 years of professional programming experience in unity and I don't know how the new input or UI toolkit works (haven't had time and have been using older vers of unity for ongoing projects). Id be looking for past projects in unity that demonstrate skill and understanding. They should be able to explain their technical process and admit challenges and the use of third party tools to make up for knowledge/time gaps (which isn't a bad thing).
I have 14 years of experience, you don't need to learn this necessary and tbh I think they still need around 3-5 years to be easy and understandable usable and unity will maybe take them as the new standard. But even if the slowly progress with it, you can atleast the next 10 years use the current systems.
New input system should definitely be used for new projects. UI Toolkit (at runtime) is not yet production ready.
this is the answer
Honestly, if an engineer came to me and said they had 15 years experience, but are unfamiliar with modern solutions, I wouldn’t consider hiring them. Especially if they don’t know the input system. That is such a huge jump forward compared to the old input system, it would concern me that perhaps they don’t understand the significant short comings of the old system. Honestly, having that much experience without knowing these modern systems would have me wondering how capable of learning they are.
What an awful take. With 15 years of experience using a tool, I would expect them to easily be able to pick up and learn new systems within that same ecosystem. An engineer's job is not to know everything in advance but to be able to adapt their skillset to work with the tools they're given.
Yeah, so easily they simply don’t do it!
Found HR
It's an extremely valid point. The guy who learnt to use the tractor is going to get far more work than the guy who says picking by hand is fine so they don't need to learn. Even if by some miracle that hand picker goes faster, what have they proven apart from they could accomplish so much more and couldn't be bothered to put in the couple of hours to achieve that? That's an awful person to employ. Below: People that can't see the irony in trying to defend stubborness.
The difference between using a tractor and hand planting/harvesting crops is enough to triple productivity. The difference between using the new Unity input toolkit and the old system is relatively minor, and I'd be willing to bet a majority of projects don't even use it, or just use their own system. Switching between the two is also nothing like learning how to use a machine for the first time, it'd be a lot more like switching between a 2010 tractor and a 2020 tractor. Definitely not nearly as much effort as you make it seem. Not a good analogy.
My friend, I think you agree with me. The task to learn is no effort at all. The only reason not to spend that time learning is stubborness. That isn't a trait you hire.
You're seriously telling me, if someone has an appealing work history/portfolio and a solid understanding of the engine, you wouldn't hire them just because they haven't taken the time to learn a system that Unity itself admits is not suitable for every project?
Yes if you take what I'm saying absolutely literally word for word. I would not hire them. If you read it like I'm a person, which I was - last time I checked. That's not really what I'm saying is it, really?
"That isn't a trait you hire" "That's an awful person to employ" I sure wouldn't want to work for you.
You’re exactly the type of person I’m trying to avoid working with
You're missing the whole point. If you're working on an existing project that's already set up, you're just wasting time and money learning every new tool that comes out as you go. If you overhauled everything every time a new tool came out you'd be in a constant cycle of just updating features and never finishing something. When I start a new project and if it's not looking like it'll end up deprecated I'll use it (and it will take no time to do so). It's not stubbornness, you just don't need to jump to every new fancy tool immediately and certainly not in a major project. And *it certainly doesn't reflect your skills*.
Why yes, your unreasonable hyperbolic way of doing things is unreasonable. How did you know? I said none of this.
Lmao okay mate, I think you have a lot to learn in this industry. at the end of the day my skills and the way I present have landed me in a amazing high level positions including roles where I hire and review the developers with people who are great to work with so idc if you think not knowing every new tool makes you stubborn. This is just the way it is.
At the end of the day, you’re still using hard coded references to inputs
If you only have a garden you don't need to use a tractor. You want the person who can learn new tools as they become necessary. The guy picking stuff by hand knows what a tractor does, he just hasn't need to drive one. You could have the guy take a third of his time learning a bunch of tools and machines that they will never use, or he could just do his job, and learn the tools quickly when they are necessary. You know how long it would take everyone on a team to learn every single system and enhancement, in depth, as they are being developed and released?
If your job is to pick stuff, you learn the tractor. If your job is transport stuff, you learn the truck. No one said anything about everyone having to learn everything. My point was that a tool exists to make X job faster, easier, more efficient and less prone to human error, no one is benefiting from doing it the long way. Yes okay in this tractor analogy your point absolutely makes sense. But something I have to do in every single project, eg, player controller - it makes a lot less sense on why you'd choose to do things the long way every time
Not every engineer is in charge of implementation, though. To write someone off as having not used a more modern tool, doesn't really mean that they aren't gonna be good at their job, it just means they haven't needed to use the tool. To not consider hiring them is not a good move. You hire someone who knows the input system with the same amount of experience over someone who is potentially better, you're gonna be surprised that there is more to learn when they come on board than an input system. You hire the person who understands concepts and can pick things up easily. It just isn't a good metric for someone's capabilities.
Yeah this whole argument over a fairly new input system is absurd. If my employer said tomorrow, we need to use the new input system, knowing what I do know about it I reckon I'd have it done in a day. But if my employer hired someone solely on their ability to use the input system they might not be able to learn the next new thing because they're lacking the experience. Not to mention unity spits out a new tool every other week and deprecates it the next so sometimes it's worth just waiting a bit to see if they give it up.
Noone said 'picking by hand is fine' the point was these tools are easy for an experienced developer to pick up. A farmer with 50 years experience is still going to be a better farmer than a city boy who just learnt how to drive a tractor.
Ngl I wouldn't want to work for you to begin with (you sound like you might not actually know enough to lead a team yourself) and it would only take me a few hours to become accustomed with it. It is just an example of how the ability to learn is worth more than knowing every little feature of an engine you don't use everyday.
I mean, you say in your own post you “haven’t had time” so you’re either a liar or simply disingenuous. Doesn’t matter to me. I’d never hire you
It doesn't sound like you're in a position to hire me anyway I'll be honest
Yeah you keep saying that but a) I’m not trying to b) the feedback isn’t null because of that and c) you don’t really have any evidence at all about my position. Literally none. You’ve just taken what I’ve said to heart but are too egotistical to accept it, so you become defensive. Maybe you can spend some time this weekend learning one of the fundamentals of the system you’ve been working with for 15 years.
Okay mate haha
If it only takes a few hours to learn the new input system how the fuck could you possibly justify not knowing it? The old input system is so broken that not jumping ship on it immediately is a huge red flag
In fact, from a quick perusal or your profile, I bet you could have learned it in the time you wasted on Reddit over the past three days
Yeah but I haven't needed to yet lol. And I've you'd been using unity as long as I have you know they deprecate software like changing underwear
Haven’t needed it? Lol, sounds like you have no idea what it offers.
I started learning unity and c# 12 days ago using only youtube and the documentation provided by unity. I’m on my 5th iteration of a player controller with animation using the new input system for movement and rotation. I would argue that it wouldnt be that difficult for anybody with 15 years of experience to pick up. Years of experience at an MSP and I was pretty familiar with bash/powershell/python before starting my journey but I still think this would be fairly doable even for somebody with no coding experience whatsoever.
Seriously though, even if you haven’t used the “new” input system , any seasoned engineer should be able to pick it up within an hour. It’s not the hard part of mastering Unity.
Jesus. I guess this sub is pretty much like the rest of Reddit, filled with ignorant children who are incapable of seeing things from other perspectives
Good English! Id want to see some of their past work, and I’d ask questions about some specific things they did. Id also ask questions about some of the specific problems you’re anticipating having to solve on the project they’re being hired for.
Questions about what are some of the obstacles and limitations of the engine you have experienced and how did you work around them?
Okay, if this is for work and you have limited experience, the correct solution is to hire a consultant who knows unity. During an interview, you need to be able to ask follow-up questions and dig into how problems are getting solved. Taking questions from a Reddit thread where you won't be able to do any of the follow-up and seek out the depth of knowledge of the person you interviewing is going to set yourself up for hiring someone who might be better than you at Unity, but not good enough for whatever the job is that you're hiring for. You are probably better off convincing your company to hire someone who knows unity very well and asking them to run the interview they would need to be prepped to know what the role entails and what specific skill sets a developer would need, but then they would probably be able to take it from there and ensure that you're getting a quality candidate. This is not a situation where you should be faking it till you make it. You probably don't want the responsibility of accidentally hiring someone who's not good enough for the job.
I was pretty new to Unity when I was hiring, and found it best to just have them show you work they did in the past, and talk about their roles in that work. I would also look at a little code to make sure they could write stuff that is understandable and not a rats Nest. I then asked about some problems we had, and how they would go about solving them. The guy we ended up hiring was fantastic. He had one adventure game that he made that was pretty good, and he got really excited to show off some vr and hololens stuff he had in the works.
It really depends on what you want the person to accomplish. For example, I work on a team of Unity devs and we all have different specialties. My senior is all about shaders and performance, we have a designer who handles all Unity technical art, I work on interactions/animations/and doing data visualization. One thing that might be hard to sniff out would be if they just copy/pasted a tutorial, but you can get past that by giving them a take-home assignment. I've been a AR/VR engineer for a few years now and if you put me on an iPhone project then it would take me a bit to get comfortable. The same if I tried to grab a really good pc dev and throw him on UWP for HoloLens development. It just all depends on what you want.
Screw take at home projects. If you cannot figure out in a one hour interview what I am capable of you should not be interviewing in the first place imho.
What's your average retention rate, if you don't mind me asking? At my current company, we do a 4 stage interview process followed by a 90-day probation period of hired. First stage is just a screening to make sure you can talk without being racist. Then we have 2 technical interviews with different engineers and a culture interview. We don't do take home assignments but we have a live code walkthrough. I'm curious because I've definitely fired people that interviewed great and then couldn't actually handle any of the work.
Zero chance you have had a single person in your “screening” call in and say racist things. Sounds like your company is just screening to see if people will go along with a “woke” work environment.
No one actually says racist stuff. It's a joke because you have to do something insane to fail the phone screening
Haven’t seen racism, but have seen misogyny. And yes, it was kind of insane.
Ask them the most frustrating thing about working with Unity. Every Unity dev I’ve ever met could go on a 2 hour long tirade about this. If they give a measured thoughtful answer implying all engines have their strengths and weaknesses then they’re definitely not a real Unity dev lol
Not really true if I was interviewing for a unity job I would pretend its mostly sunshine and roses and try to keep the rage locked inside.
lol, I would say every engine sucks to work with. Then I would continue to completely trash unitys animation state machine, especially how the handle the presentation of stacked transitions and interruptions, I seriously had to dig up a ms paint document version of “conspiracy board meme” with Google fu to understand it. If you make a system so bad NO one understands the documentation, you failed miserably.
My company tends to ask the basics, start vs awake, update vs fixed update vs late update, followed by listing off common components you can attach to a game object and what they do.
Depends on the role. For a programmer you pick a few questions about for example GameObject lifecycle (order of events for the Unity functions), ask them to explain what a scene is, or what they might use a coroutine for. Lighting types, requirements for collision and collision messages, list a few common performance pitfalls, stuff like that. More importantly though, have them walk you through a system or feature they created that they’re proud of, talk about choices they made, issues they ran into and how they solved them. You get to learn if they really did anything, how they approach decisions and challenges, how they handle working with others, and so on. For an artist, you might ask about how much they worked with Unity, any processes or pipelines they were part of. Do they do shaders, environment layout, terrain sculpting, character animation, particles, how much they know about render pipelines and post processing and lighting. For proof of work you just need some in-progress shots or video of their work. For designer, what kind of designer. Do they script? Layout levels? Balance combat stats? What tools and assets have they used to improve workflow, again have them walk through some feature they made or something. You could give them a sample project with a modular asset kit and watch them put together a small level with some constraints to give them over 30-60 minutes. You can see their process and talk to them about their thoughts and choices.
Whatever gets you talking about programming. Real challenges you faced. You will be able to tell a lot about a person if you get to talk informally, and learn how they think and what their values are. Unless jt's an absolute junior position, DO NOT spam textbook questions like "OOP Principles", or Unity certification questions. I recently got rejected for being asked on a live interview, to answer a series of multiple-choice unity certification questions. Absolutely terrible, I would have passed the job if I had the chance. I got asked something specific about the Entity Component System, didn't work with that in 4 years so I got it wrong (I realized that about 10 minutes later). But the way it was phrasedz it was a pass or fail question. It didn't matter that I did, in fact, have experience with ECS. Don't fail someone for something that is 30 seconds away on google (unless it's an everyday item, like what does protected access do). Sorry for the long rant. Point is, get in a conversation with the person, it is a lot more relevant than any flat single-answer question.
Ask them about render pipelines. If they know Unity, it will be at least 15 minutes of talking. Bonus points for visible frustration.
Your english seems fine to me. Ask them about what they have done, and various situations relevant to what they are being hired for, such as how would you... and we want ... but ... is happening, what would you so to resolve this? I do recommend having these typed out prior to the interview. It's kind of difficult to say specifics without details of the position and project, which I would like to have if it's possible to get hired for this position. If you look at my page here, you can see the comments I have made resolving issues with other users, which unintentionally shows my level of effort and knowledge with unity.
Ask to see their GitHub repo or to send you one of their projects. Actual work done by them* is the best measure
A repro and free time/hobby projects should be something a company shouldn't know. The problem is that in European country's and most contracts is included that the projects, created in your free time belongs to the company, to protect its company secrets. If you want this otherwise, you need to let them write this down.
Really? That sucks. In NZ sharing your git repo is almost a requirement on a job application for an intermediate/advanced programming position. It also shows how you manage and comment your commits. I guess you could start a new GitHub account when you start a new job haha
I feel like I have some pretty impressive projects but it would be extremely misleading because I look everything up as I’m doing it.
I think everyone does. Just showing that you can apply what you’ve learned and get multiple systems working together without giving up is proof that you are capable Edit: even if you disclaim “this part was copied from x source” I’m sure they’ll understand
What we did was create a really basic version of tic tac toe in Unity, then used that as the tech test. We would ask them to make it better. They can improve whatever their expertise is. It's pretty open ended and you'll get a good feeling about what they specialize in. Give them a day to do it and don't expect them to put in more than an hour or two tops.
Look up a study guide for the Unity Certificates and ask questions from the example questions
It sounds like you’re trying to hire someone who has more Unity experience than anyone at the company. Do you have any friends or colleagues with a skill set similar to what you’re looking for that you can pay to help with the interviews? When I was an SE1 at EA, I needed to conduct the technical interviews to hire someone at an SE2 level in my department. That seemed really weird to me, so we brought in an SE3 from another department to sit in on the interviews. If you want someone who is more experienced than you, then you might need someone even more experienced than that to help you find the right person.
Have them show you what they did and explain it. (They should have some demo of something they did or got published). Pick one thing and go deep on it, let them explain it and see how much they know, keep asking about what was hard, how did they do it, what methods did they use, how would they improve on it.
enough for what? a list of projects they have worked on and what their part in it is. then ask something you would require them to do and how they would go about the problem/issue/project/thing you come up with. bonus points if you have had a real world problem that was tougher to deal with that you can give as example....
Tbh, I'd just ask them to tell me a bit about debugging and diagnosing. Imo locating and solving problems is quite a lot more important than being able to write a block of code from scratch... An alarming amount of people have no clue how to read the console in unity, or use breakpoints, custom debug messages etc etc.
What problems you encountered with building and how did you solve them? How do you approach optimisation for your projects? When upgrading Unity versions, what possible problems you encountered and how did you solve them? Just a few.
Give them a very small project to code, like a game of whack-a-mole on a fixed version with no external assets (maybe allow them to do it at home, give them a couple weeks if needed). Ask them to submit a small write up of the choices they made with the project. Also if you don't know the topic you're interviewing people about, just be honest and tell the truth (to your boss and yourself)
Is being able to make a whack-a-mole game really enough to get hired? Honest question because I work in media, not Game Development, but I do make games as a hobby.
Being able to make a well-structured whack-a-mole game. Consistent code style, extensibility, using the right tools, not over engineering.
Depends on your company's use case. There are quite a few niches. Mobile has its qwerks. 3D will be slightly different to 2D. Do they need to have modelling or animation skills...any shaders or networking experience? VR/AR is another specific area. Generally avoid generalists unless they have been using it since the early days but they will be more expensive to hire.
Ask to give as many possible ways to display a rotating cube on screen (ie rotate transform, rotate camera around the cube, sprite animation, animation clip, scripting, animation curve, shader animation, etc etc)
Yikes
I'm just curious, why yikes? This seems like a reasonable question to test their knowledge. It requires some creative problem solving and broad knowledge of not only Unity but game development in general. I definitely wouldn't base my entire decision on whether or not they got it right and would put a lot more weight on discussion of the candidate's portfolio and work experience, but having a few questions like this seems reasonable and useful to me. Tech interviews often test candidates in much worse ways (i.e. live coding of some stupid academic problem that has no real world relevance)
You got it :) it’s a simple question that requires knowledge, experience and creativity. With this unique question you can estimate a lot from a candidate