I have applied to several Unity developer jobs and most require just a C# exam generally with things that you never use in Unity, dont understand why dont care if they know Unity or not, they prefer a guy without no knowledge of Unity with a good c# background as if could learn unity in some days…
If you know C#, you’ll figure out unity specifics eventually.
The guys might also have HR problems.
And, yes, C# guy with no knowledge in unity would seem to be preferable to a guy with unity knowledge but zero knowledge of C#.
Yes, i mean they should test c# and unity but many just test c# as if Unity were not important
Also if you just know unity eventually will learn c#, in my case took much more time to learn unity than c#, and i am still learning…
Examples? I’m betting some of it is internal only.
Examples of what? internal only? what do you mean?
Examples of “things that you never use in Unity”.
Like gethash
There are seven references to it in the public portion of the engine source code. I’m willing to bet there are more in the private portion of the engine source code. A quick check of one of my projects shows it in one of the Unity examples concerning serialization with JSON.
https://github.com/Unity-Technologies/UnityCsReference/search?q=GetHash&unscoped_q=GetHash
Searching for GetHashCode shows 235 references.
https://github.com/Unity-Technologies/UnityCsReference/search?q=GetHashCode&unscoped_q=GetHashCode
That Unity uses internally, but i didnt say that and gethashcode is not gethash
GetHash has benefits if you need tables of objects and want to access them very quickly. My company is using it and a couple of our third party assets are using it.
Well in all companies i was i never see anyone using it , neither in Unity forums, noone uses that i have seen
It’s very uncommon but it’s there if you search for it.
GetHashCode is fairly common in many types of games, I haven’t worked on a (unity) game without it. Regardless, testing the more uncommon knowledge areas helps determine the actual depth of knowledge. No point in testing knowledge of String.Format or switch statements.
Even ~5 years ago at Disney/LF, we put a very low priority on Unity knowledge. Unity skills are 1) easy, and 2) widely available. A solid programer can easily google (or docs) their way through using unity. Someone who has only done a bunch of editor stuff and tutorials, isn’t all that useful. In fact that was often a red flag on a resume. Folks who list a role or skill as “Unity Developer” were usually tossed. (unless of course they were developer at Unity).
I have watched C#-ers come in and totally wreck a Unity application and bankrupt a company. They did not have a clue…some were marching in the first day… We need to change this to an MVVM setup… umm…no we didn’t…others were… why did 900 Unity engineers do it this way…Let me write my own buttons and audio and raycast physics because my code is so powerful[read…I don’t get how this app works]…sure pal… sounds like a good story to me. Knowing C# is not necessarily knowing Unity if it comes in filled with MS dev molarkey. The mr. powerful code dude spent two days trying to change the background on the UI. I finally told him it was the skybox and didn’t work like a webpage. Another 3 day headbanger was to separate nodes into two groups. His final solution was two pancakes a mile apart with the camera pulled back so far you could not read the nodes anymore. A simple Random.insideUnitSphere with the radius being the sqrt of the total nodes per group would have done it in five minutes with the separation being (radiusA * 2 + radiusB * 2 )/3. He would not accept any help because his code was so powerful. When surrounded by bozo the clowns there is but one option…quit and let them deal with the mess.
Also need to consider the different needs of different companies, in a small company you might need generalists that know a lot about C#, a lot about Unity, and probably qutie a bit about asset pipelines and artist workflows.
In a larger company its quite possible that a developer doesn’t need much of Unity at all, with the right framework in place its even plausible that developers in certain roles never need touch Unity (other than to run some testing).
Even if you do need Unity it may be more effective to get a solid C# programmer and train them in Unity, than to try and validate both Unity and C# skills.
And of course as others have mentioned many companies have broken hiring processes.
Can’t speak for your interviewers, but I’ve interviewed for several jobs where as long as you understood fundamental programming concepts such as stack-vs-heap-allocation and pass-by-reference-vs-pass-by-value then there was no need to test you on their development platform. It was assumed you’d have no trouble learning it if you didn’t already know.
Unless people are hiring for short-term contract work, they’re usually more concerned with your overall competency, rather than just knowledge of a specific software tool. A good programmer can quickly learn what they need to know with a language or software.
Unity and C# are both just tools. I wouldn’t want to hire anyone who’s skills are limited to either of those things in their respective areas, because that suggests that their experience is quite narrowly limited. I want people who can solve their own problems, not people who just know how to follow steps in specific tools.
If someone understands the fundamentals game development then they’ll be up and running in any reasonable toolset a team uses fairly quickly. Similarly, if they understand the fundamentals of programming then they’ll be up and running in any reasonable language which happens to be in use. In both cases I’d rather pick up someone who’s got solid foundational knowledge and train them in specifics than someone who only has tool-specific knowledge and needs to learn the fundamentals.
It could be that the people making hiring decisions don’t realise that daily development in general .NET and Unity aren’t quite the same. Alternatively, it could be that they’ve commonly hired “Unity Developers” who don’t really understand the .NET environment that their code is running in and do some really questionable stuff as a result. Asking about broader C# programming is probably a good way to filter that out fairly quickly.
I haven’t done it for a while, but I used to interview based on general game dev, general programming, and general computer graphics. None of it was tool specific. Nobody we brought on had trouble adjusting to any of the tools we used.
I am thinking i will apply for unreal jobs too, have no idea of unreal but most jobs dont care
What’s your recommendation for a good way to incorporate “Unity” into a resume? If someone’s listing regular development knowledge like multithreading, sockets, Xaml experience, whatever, what kind of non-redundant game dev keywords can supplement that?