Not in the games industry but have worked as a developer for a few years so take with a grain of salt… “Fluency in…” is recruiter talk I believe. If I were to guess I would say a non-technical person wrote it and then they are likely looking for some sort of “proof” that you have the skills, which means documented experience in some formal setting which most likely is a job. That person will likely do the filtering of applicants. Then you probably get to speak to a technical person where you can explain exactly how much you know and they will get a fairly accurate picture of your skills.

Most recruitments are relative. Fluency in something is relative and whether you have fluency or not will be determined based on the other applicants they get and their experience. The company will likely have a base-level where they discard everything below that. But after clearing the base they will take the best applicant they find (or that has become my understanding over the years). So what does it mean for you? Considering your lack of professional experience (as I understood you?), for some jobs you will be at the minimum required level and for some jobs you will be below it. Since you are at best at the floor of what they are looking for, they will not get in contact with you until they have had the job posting up for enough time that they can see if there is someone better suited for the job. So if you are lucky to get a chance for an interview, expect them to call after a couple of weeks after you sent in the application.

I think this is the general picture when applying to popular jobs without much experience. It may sound a bit cynical but it's just business. After a few years of dev experience you may realize that the tables have turned and you are the one sitting on most the cards.

Don't have much input on your other question. One suggestion is for you to download the source and take a look at that, along with reading the C++ API on the Unreal website. I would say the best way to understand any system of code is to try to write it yourself. Getting thrown into a big software project can be quite daunting. One way to make it a whole lot easier is if you already know some of the code and concepts present. Some of it will be specific to the project and can only be understood once you get to the job. But much of the stuff will likely be adapted from tutorials and industry best practices. Being able to see what is what makes it so much easier to make sense of it.

Just wanted to add an idea I thought about just now for getting yourself familiar with Unreal Engine faster.

The obvious first thing to do would be to simply read the code. But just reading code can become demoralizing when you realize you still don't understand a class after having looked at it 500 times. What you then probably do is to look at the commits and if you can find the pull requests then even better. You can then look at that code in the context it was added and start thinking “aha, now I know what this class is supposed to do… but I still don't understand how it does it). So the last step then would be to rollback the code until before that commit and try to implement it yourself. Only then you will realize what how much you didn't know and see all the reasons of why things were done the way they were done (hopefully at least). Compared to a real job where you are responsible to implement the feature, now you instead have the ”real answer" to compare your solution to.

Obviously this is very time consuming and takes a lot of work and I haven't tried this myself. But it is similar to what you will be doing in a real job. And I'm sure you will start getting a good grasp of the code this way. But I think this should act as a complement to trying to implement your own game engine since that will give the most bang for your buck.

I graduated last April in a degree in Computer Science and Game Design. It's tough finding work in this industry, especially when you first start out, and especially right now. Like what was mentioned by perry_blueberry stuff like “fluency in a coding language” is jargon made by Human Resource Managers, they probably just mean “do you know how to read code/ write in this language”. It's possible this is also what's happening with the request for someone who can “Suggest, design and implement improvements to the inner workings of game engines.”, since that's a very tall order for what I'm assuming to be an entry level position. They are probably just looking for someone who knows enough about a game engines to have actionable opinions on them. I personally think it's really dumb that the industry is gate kept by a bunch of people who have very little or no understanding of what it is you'd actually be doing, but that's the hand we're dealt.

I've talked a lot with friends who are also trying to work in the games industry after graduating. Those who have found work have all said the same thing, “At this point, it's just luck”. Every company has their own unique needs that they want filled, and you wont know what those are until you interview with them. So I'd suggest casting a wide net and applying to a large number of companies, worst case scenario you'll get some good constructive feedback on your resume.

Hope this helped ?

Strawhatsheik said:
As an example one job asked for fluency in C# or C++. I have worked in both those languages, more so in C++ with Unreal engine. I understand all the basics. Do you think they mean several years plus? Has anyone been in an interview and could give me an idea what skills I need to sharpen?

As another mentioned, that's really something done by recruiters, not by people who interview you. “Three years with language” doesn't really help much, nor is it particularly meaningful to assess your skill.

Every company has their own practice. Many will give you a programming test, either as something they email to you and expect you to complete, or as something where you write code during an interview. They may have you write code in an editor of your choice, a web interface that records everything, or a whiteboard in a conference room. They will also ask you questions about your understanding of the language.

While it might be useful to brush up on data structures and algorithms, generally during interviews people ask about simple, standard tasks. Show you can work with pointers by reversing a string in place, following a linked list chain. Show you can manipulate data by building or working with a container class, sorting data, or otherwise doing something simple. Either you're comfortable doing basic programming tasks or you aren't, there isn't much of an in-between.

Interviewers are not out to trick you or deceive you. They aren't trying to ask trick questions. They're trying to understand if you can do the job or not.

Any questions they ask should be related to doing the job. Sometimes people who are unskilled at interviewing will miss the focus and ask about things that are theoretical or completely unrelated. If you're not comfortable with a question, or don't think it's something you'd be doing, feel free to ask the interviewer back, “Oh, how often will I be asked to do that kind of work?” A question like that should straighten out an interviewer and bring them back around to the proper topics. If you don't know the answer, tell them you don't know, then suggest a modification of the question into something you do know and ask to solve it instead. Or ask for clarification, maybe they're describing a problem in a way you aren't familiar and rephrasing will help something click.

Strawhatsheik said:
Also, a little unrelated, but the same job wanted “Suggest, design and implement improvements to the inner workings of game engines.” As I said I worked in Unreal engine quite a bit, including plugin’s and APIs, but don’t know the ‘inside’ of an engine well. Any suggested tutorials or workthroughs to give me better understanding of that?

That can mean radically different things depending on the company and people involved. You can't know it in advance what they're looking for. Present yourself as who you are with your current background and experience. When you get to the interview, ask them what they mean exactly. They'll probably bring it up first, but if they don't, you should ask. The interview process is not just them interviewing you, it is also you interviewing them. You need to understand what work they're looking for, and you need to understand that you will be comfortable doing it. As you discuss it, figure out if it is something you're comfortable with, something you're unsure about, or even something you've never touched before and have no idea how to approach it. It will help both you and them.

Just like understanding your skills with a language, nobody is trying to trip you up or trick you. They just want to understand if you can do the job. If the honest answer is that you can do the job but it will take some learning curve, most companies are okay with that. This is extra true if they're hiring at the entry level because they know you will need hand-holding and training. Even at senior levels studios know it takes several months before senior workers are up to speed on the code base, and it can take a year or more for industry veterans to reach similar speeds as their peers.

It is impossible to know in advance what companies are looking for, and every company is looking for different things. So just be yourself, don't worry about it. You might happen to be exactly what they wanted. You might happen to be an incomplete fit but still the best match of the people they're interviewing. You might happen to not match any of their current needs, but that doesn't mean you won't match with another company. Just keep applying at companies until you find a match.