Do employers care about language/API used?
Author
Hi,
The question says it all.
Will future employers care about which language / API I'm using to create games?
Or will they only look at the game design / programming techniques?
I'm afraid that years of studying with a specific API will get me unemployed just because I chose the wrong API to start with.
Thanks for any insights given,
- dadads -
These years of studying with a specific API will give
a lot a experience and then, you will be able to
use another API or programming language without having
to begin from scratch.
Well, many employers require experience in a specific
platform, but others no.
Consider this: When an employer hires a programmer to
make games for a new gaming machine platform
(like playstation, X-BOX etc) he don't expect him to be
experienced to this platform that is not even released!!!! :-)
Another example:
If you use Windows for the gaming platform good knowledge of
C/C++ and Direct3D and OpenGL api is OK!
Another issue is that many gaming companies have already a 3D Engine
and the most of a new game is the Artificial Inteligence and the gameplay.
A good and experienced programmer can easily step from
a language to another without much effort.
a lot a experience and then, you will be able to
use another API or programming language without having
to begin from scratch.
Well, many employers require experience in a specific
platform, but others no.
Consider this: When an employer hires a programmer to
make games for a new gaming machine platform
(like playstation, X-BOX etc) he don't expect him to be
experienced to this platform that is not even released!!!! :-)
Another example:
If you use Windows for the gaming platform good knowledge of
C/C++ and Direct3D and OpenGL api is OK!
Another issue is that many gaming companies have already a 3D Engine
and the most of a new game is the Artificial Inteligence and the gameplay.
A good and experienced programmer can easily step from
a language to another without much effort.
A good programmer should be able to pick up a new language or API very quickly. If you can't adapt to a new language or API, you're a "coder", but you're not a "software engineer".
When I worked on an Unreal Engine game, I was given a week to learn Unreal Script and Unreal's C++ API. They didn't care that I wasn't familiar with them, they just expected me to learn it quickly.
However, it would be different if they were hiring, for example, "Unreal Engine Experts" - in that case the employer would expect you to be very familiar with that API/language.
When I worked on an Unreal Engine game, I was given a week to learn Unreal Script and Unreal's C++ API. They didn't care that I wasn't familiar with them, they just expected me to learn it quickly.
However, it would be different if they were hiring, for example, "Unreal Engine Experts" - in that case the employer would expect you to be very familiar with that API/language.
Do employers care about language/API used?
Ooooh, yes, very much so. ESPECIALLY so if you go to work in the government sector. Established organizations tend to have an established work structure and process (and if they don't, they tend not to get to the "established" level). Moving outside of the "box" that an organization is used to is typically met with resistence unless you can adequately justify your intent.
That's not to say new ideas and processes aren't accepted. But many organizations, especially large ones, will expect you to conform to their standards, not the other way around.
This doesn't mean that you can't study on your own; in fact, I would recommend you do. Many organizations keep a record of resumes on file, and having multiple language and platforms on an IT resume is a good thing. Personally, I would recommend a good focus across Java and C++ on both the Windows and *nix platforms.
Programming is logic first, syntax second anyway. Many of the languages you will use will seem remarkably similiar. Once you understand for loops, case statments, conditionals, ADTs, etc, such concepts can be applied to more than one language.
Except PL/SQL... evil freakin' language...
Ooooh, yes, very much so. ESPECIALLY so if you go to work in the government sector. Established organizations tend to have an established work structure and process (and if they don't, they tend not to get to the "established" level). Moving outside of the "box" that an organization is used to is typically met with resistence unless you can adequately justify your intent.
That's not to say new ideas and processes aren't accepted. But many organizations, especially large ones, will expect you to conform to their standards, not the other way around.
This doesn't mean that you can't study on your own; in fact, I would recommend you do. Many organizations keep a record of resumes on file, and having multiple language and platforms on an IT resume is a good thing. Personally, I would recommend a good focus across Java and C++ on both the Windows and *nix platforms.
Programming is logic first, syntax second anyway. Many of the languages you will use will seem remarkably similiar. Once you understand for loops, case statments, conditionals, ADTs, etc, such concepts can be applied to more than one language.
Except PL/SQL... evil freakin' language...
Quote:Ooooh, yes, very much so. ESPECIALLY so if you go to work in the government sector.
That isn't entirely true. I know people who've been hired right out of college to work on projects that use Ada, something which is given almost no attention in today's college curricula. Where I work (major government contractor) we also hire college grads with an exorbitant amount of java and almost no C/C++ to work with C/C++.
Basically, most places just want some indication that you are capable of quickly learning the tools you need to do the job. In the end, the language is a tiny, TINY part of the job... processes, "background" on the subject area of the project, third party libs, etc., dwarf the actual programming language in terms of requisite absolute knowledge.
Quote:Original post by dadads
Hi,
The question says it all.
Will future employers care about which language / API I'm using to create games?
Yes, they do. If they are searching for someone who is experienced in C++, they won't hire you if you can only prove that you're good at Java. Different languages means different techniques, different APIs, and different knowledge.
Quote:Original post by dadads
Or will they only look at the game design / programming techniques?
No, but they're going to give a look at it if they feel you can be the right guy. However,
Quote:Original post by dadads
I'm afraid that years of studying with a specific API will get me unemployed just because I chose the wrong API to start with.
This is a common concern. But remember that you're not likely to deal with the gritty details of a particular API when you'll get hired. A lot of game studio out there are using middleware solutions (granted, these middleware solution are to be tweeked, but most of the time this is done by some guy who has the needed experience). You're not going to be hired for the senior graphic engine programmer position for your first job (unless you prove that you are able to handle that position, of course).
While API and languages are important, knowing them is more important than mastering them. You must know they exist, how they work, and maybe some of their flaws. You must have experienced them. The reason for that is not to build your resume, it's that you must have a clear understanding of how things work. This is the key to adaptability, and adaptability is a key factor to a successfull transition to the professional world.
If you know only one API/language, your knowledge regarding the inner working of your code will be (at best) weak.
Now, I don't know what is your education level, but a strong curriculum will probably help you more than having studied an API or a language on your own if you want to enter in the game industry.
Quote:Original by Hodgman
A good programmer should be able to pick up a new language or API very quickly. If you can't adapt to a new language or API, you're a "coder", but you're not a "software engineer".
That's true.
Regards,
Quote:Original post by Jimmy Valavanis
[...]
You don't need to hit enter at the end of each line unless you want to start a new paragraph or apply particular structure; just type and the forum software will wrap the text for you. As-is your post is quite difficult to read at higher resolutions.
Quote:A good programmer should be able to pick up a new language or API very quickly. If you can't adapt to a new language or API, you're a "coder", but you're not a "software engineer".
This is the most important thing to understand.
Once you understand what the difference between an API and software development is, you will know the answer to your question. You'll also know why someone chose to hire you, and why someone else rejected you.
Some jobs require X years of exact version of a specific API experience. There's a reason for that.
Some jobs require broad familiarity with *all* APIs of a specific domain. There's a reason for that as well.
Some require in-depth knowledge of a domain and don't even care about languages or APIs. Justified as well.
Some HR people are idiots. They don't know why they want something, they don't even understand what they need, but they'll simply want you to list experience with something. For example, when .Net 1.0 launched, there were companies asking for 3-5 years of extensive C# experience. These companies for example only need cheap labor and use revolving door employment policy.
Can knowing only an API make you unemployable? Yep. Will it? Not unless you choose to sit idle and not investing into yourself for at least 3-5 years. And idle means not learning a single things whatsoever, about either your business, your domain or the tools you use.
This can pay the bills and make for some extremly stressless life, but it'll come back and haunt you. Today, it's usually hard to get stuck with that if you have even a shred of motivation, since the resources are so broadly available that it's easy to expand your horizon.
Quote:Original post by AntheusTo build on what I said before, I think Antheus is correct. I disagree that companies usually care about experience with a particular language (sometimes they do, but not usually), but they will VERY often require experience with a domain of APIs or third-party tools, which essentially is, in most cases, a de facto language requirement.
Some jobs require X years of exact version of a specific API experience. There's a reason for that.
Some jobs require broad familiarity with *all* APIs of a specific domain. There's a reason for that as well.
Some require in-depth knowledge of a domain and don't even care about languages or APIs. Justified as well.
Think about someone hiring a web developer. If that company is using java, they probably don't care if you are a java expert, as long as you have something indicating that you understand web development and development processes similar to theirs. If you know ASP.NET, they might be willing to hire you.
However, most java development jobs are going to want experience with libraries like Struts, Spring, Hibernate, etc., because knowledge of those goes above and beyond the language, and are ultimately much more difficult to master than syntactic differences between C#, C++, and java. So while java experience may not be a requirement for the job, it might as well be.
I game development, C++ as a requirement is almost a given. It is the only popular language which requires the sort of low-level knowledge of memory-management, etc., that is still required for game development.
Quote:I game development, C++ as a requirement is almost a given. It is the only popular language which requires the sort of low-level knowledge of memory-management, etc., that is still required for game development.
Yes, that's the point. They don't really care about C++ (in a sense), but you need to show that you have experience with problems where C++ features are crucial. Memory management is one of them. It's both, its finest hour, and the bane of C++.
Someone coming with Java background may be excellent designer, but won't have any concept of what memory management means, and what the consequences are for design.
And this falls under domain knowledge, not API. Someone with vast experience in C++ memory management will be quite suitable for embedded Java programming - same issues, slow allocations, fragmentation, limited heap, controlling allocations of large number of objects, ....
But at the same time, a Java developer will be completely incapable of developing in Java for embedded platforms, since they don't understand these concepts, and they won't be able to grasp why things aren't working out, are slow, application runs out of memory, although it should have more than enough.
Domain knowledge is what's important. Sometimes, domain knowledge *is* API.
The general domains you should be familiar with are:
Procedural, Object oriented and functional programming.
Single-threaded vs. multithreaded.
Synchronous vs. asynchronous.
Common system architectures (memory models, IO, threading)
Knowing these will allow you to pick up any language and any API and learn to use it quickly. So showing experience in these areas regardless of APIs used is more important than showing you used *an* API.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
