At the entry level, a key point is recognizing that you're a raw beginner.

Sure, relative to other students you have been quite skilled. As a senior ready to graduate you are more skilled than all the underclassmen. You're the best of the group when you look around.

But when you get into the workforce, you're the raw beginner. You will have coworkers with 5 years, 10 years, even 20 years of doing exactly the job that you're starting. They have not only worked with the tools every day for years, they may have helped build them, and know them inside and out. Some of them may have been doing it professionally since before you were born, they made the games you enjoyed all your life, and when you enter the workforce you know nothing in comparison.

Ask questions. Assume nothing. Learn from everybody. Cut your ego. You will break things, and your employer knows it. Their hope for entry level workers is that the things you'll build and the help you provide will exceed the issues you cause as a beginner. People will double-check your work, good managers will quiz you to ensure you really understand the requirements, then you'll have one or more people give you code reviews before you submit the code. Use every one of those as an opportunity to learn, to ask questions, and as a way to better yourself.

For specific things you can focus on during your remaining time at school, I recommend getting extra comfortable with anything related to theory and the science side of computer science. Know your algorithms and data structures, because those will always be with you no matter what language you use, no matter what tools you use, no matter what platform you use. I recommend learning whatever you can about low-level systems, how hardware works, how performance works and why it matters, learning both the Big O performance when done with asymptotically large data sets, but also learning the performance when used on smaller data sets.

As hplus mentioned, learn to use debuggers, learn to use tools, learn to read code you didn't write, learn to understand what is going on in code. Learn to understand why people want things, and whenever you're able to, learn to offer up things you can do, or offer up alternatives. This comes with learning lots of theory and algorithms, but if you can tell your co-workers “I don't know how to make X, but I know how to make Y and I think it is similar, will that work?” you'll go a long ways, but in order to do that you need to understand what both X and Y are, and understand how both of them work. So learn everything you can.

I don't know what programming languages they teach at the school. If they don't teach you C++, get some good books on modern C++ and become familiar with it. You don't need to master the language, but you do need to be comfortable reading and writing it. Be sure you're learning C++ as it exists today rather than C++ as it existed in the 1990s. Many schools focus on Java and that's fine, especially if you're going to work on back ends. But also learn C++, which is the language for a lot of systems-level work. also consider learning JavaScript, the language of the web. C# is worth learning if you're going to work with Unity, and you'll likely end up doing that at some point but it's an easy language to learn if you've already picked up a few. Be able to read SQL and able to make your own basic CRUD operations. Like above, employers aren't expecting an entry level fresh graduate to have mastered the language, but they'll expect enough competency that you won't break things too badly or require too much training. If you can do more, if you can work with the tools for hobby projects that's great (they're free, do it) but they're not hiring you for your mastery.

@hplus0603 @frob Not to discredit your answers, which are great, but aren't you just describing being a software engineer in general (with some emphasis on math and systems level programming)? It seems to me (from my outside perspective) that being a game engine programmer (or systems level programmer) requires mostly technical skills whereas being a gameplay programmer, which is what OP is asking about, requires a blend of technical skills and design skills. Maybe that's just me speaking out of ignorance though.

perry_blueberry said:
aren't you just describing being a software engineer in general (with some emphasis on math and systems level programming)?

A good programmer is a good programmer, full stop. At the entry level the best thing I can hope for is to see someone on that path. It is a path of perpetual improvement, not a destination.

I have worked with too many people who are lackluster programmers, they only know a few topics and struggle terribly when something is outside their tiny little island of knowledge. I've also worked with plenty of “okay” programmers, and had the difficulty of terminating their jobs. I feel they're the hardest people to fire because there is no specific thing to improve, other than do more of whatever they do. We don't need okay programmers. When we have amazing programmers and an okay programmer shows up, the okay programmer slows everyone down. The hardest thing I've had to explain to someone is that it isn't anything about lacking a specific skills, they're okay at it all. But being okay isn't enough, at least, not with the groups I work with.

When interviewing I look for broad skills first and foremost. That's been true of every good company I've worked at. Though it has been two decades I still absolutely love the old Joel On Software article, looking for people who are both smart and get things done. If they're smart but not getting things done they won't be implementing their features and might work as a consultant, but not an implementer. If they're getting things done but aren't smart about it, people need to go back and redo their work.

When someone has those core skills down, when they're a good software engineer in general, you don't need to explain things multiple times. You can explain it once, they can ask some questions, and you can be confident that they understand, won't screw things up, and get it done.

A good programmer can learn whatever specialties are needed for the task. They have a broad base of skills, and are both willing and able to pick up more. They're both smart, and able to get things done. They may not be a perfect match, but they can adapt by virtue of being smart and getting things done. They may not have a specific specialty, but they will find and develop specialties that we can use, and someone else with that specific specialty can pair up with them, that's why we're teams.

My absolute favorite recent type of recent graduate is one who can do exactly what is described above. Specialties will come with time and experience, so I don't care so much if they do game-specific stuff. The willingness to develop the core, learning the fundamental algorithms and data structures that apply to ALL topics, learning the actual architecture of what is happening under the hood, and learning enough of the tools to actually get their hands dirty, that's what I want to see. While knowing a few game-specific topics is nice, being able to see the big picture coupled with a desire to learn smaller specialties is far, far better.

hplus0603 said:

perry_blueberry said:
being a gameplay programmer, which is what OP is asking about, requires a blend of technical skills and design skills

I think points 3, 4, and 5 of my message supports that pretty well.

In smaller indie studios, the “designer” or “producer” you have to ask questions of becomes yourself. So, at that point, you need to ask yourself enough questions to understand what it is you're trying to accomplish for the player!

Fair enough. I think I glossed over point 4 when I read it initially. I'm just basing it on my own experience prototyping stuff in game engines. It usually ends up being quite trivial to implement most features whereas when I write other software I end up spending a lot of time coming up with a good solution. But maybe that's just the nature of the gameplay features I've tried implementing where I haven't had to face scaling issues due to it just being prototypes.