Item — HN Reader

if I may offer some advice as game/engine programmer.

If you want to get hired at a company as a programmer, make really really small things, like tiny games. I am talking start with hangman, then sudoku in the console. Then move on to minesweeper and tetris. If confident do space invaders. At this point maybe get started with 3D? Maybe Unity and Unreal?

There's SO much stuff you'll learn making those games. Maybe you end up making a fancy menu, or adding sound effects. Maybe you come up with some basic particle effects. It doesn't really matter, what matters is you went through it and have something to show.

Don't get side tracked with big projects and trying to be a designer at the same time. Keep it small.

If I am interviewing you and see some solid and polished small games and we can talk about stuff you found cool you're already punching way above most entry level coders.

4 comments

This idea is extremely prevalent in the games industry and I'm really not a fan of it. It doesn't matter how good of a developer you are, what complicated projects you're working on or have shipped, if you don't have a portfolio of games you've made then you might as well not bother.

Which if you think about it is a real issue. Imagine applying at a courier company for a developer role and they keep asking you about the tracking software you've built, parcel measurement integration you've done etc., instead of asking you about your development skills. Having done those things is of course a huge bonus, but excluding 100% of people that don't have that experience excludes a great majority of candidates that could have been a great fit.

The problem is even bigger than that if I think about it. In this example they don't want to know about individual pieces of industry relevant software that you've built, they are expecting you to have shipped enterprise wide solutions that fit the criteria and that doesn't match your skillset. The role they're advertising might be a senior tech lead/developer, but you're not being hired as a programmer, you're being hired as a game maker. They want you for the games you've shipped, not for the code you've written.

Does your little games have "juice"? That's going to get you hired 100%, but mainly because of your skills as a designer, artist, tester, audio engineer etc., coding only made up 20% of that package.

> It doesn’t matter how good of a developer you are, what complicated projects you’re working on or have shipped

You’re bringing the topic of industry experience into a thread about how to get your first game dev job. If you have industry experience, you have a different problem, and there are different recommendations. The question at hand in this article, and from the comment you replied to is how to start getting industry experience, when you haven’t shipped anything before.

I agree. It is better to finish a small project than start a big one and never finish it. I have seen a few people, and a few groups of people, who had big impressive plans... and never delivered. It is easy to imagine big: this game should be 3D, full of action, but also logical puzzles, and strategy, with an AI opponent, and also multiplayer; perfect graphics and a great storyline, but also allow complete freedom of movement... and then, five years later, you have five characters made in Blender, a map of the world where the story is supposed to happen, a list of fifty magic spells divided into multiple categories, and a tech demo where one of those characters is walking across an endless green plane.

If you can't make a small game, you can't make a big game. So make the small game first; it should take much less time than the big game, so if you are afraid that doing the small game would waste too much of your time, you are definitely not ready for the big game.

Even the small game requires a lot of work to make it look nice. Consider minesweeper: after implementing the minimum mechanism (click on a field to expose it, you either die or not, the number of adjacent mines is displayed), you are not even half done. You need the recursive exposure for fields with zero adjacent mines, editing the flags, showing the unflagged adjacent fields. Preventing the first click from being a mine. A hi-score table, where you can write your name, and it gets automatically saved, and loaded at start of the game. A menu to choose between simple, medium, and hard version of the game, maybe also custom dimensions. Should the game pause when minimized? All these details matter for user experience. Maybe also an installer?

On the other hand, if you can do the minesweeper right, you can easily create a new interesting game by tweaking some details. Maybe, play on a hexagonal map? Or play on an infinite map that scrolls to the right when you completely clear the leftmost column (except for the fields containing mines)? Add some bonuses (that you can collect by clearing a certain area) that allow you special moves, such as eliminating a mine, or reshuffling the existing mines? Would it be possible to create a version where you can have more then one mine per field? (Just a quick idea I had now, I don't even know whether that makes sense.) Maybe add some time pressure, like you need to make a click before the timer runs out, or maybe every twenty seconds a new mine is added to the plan (make sure it is not right under the user's cursor)? Or just make some non-functional feature, such as displaying a pretty picture in the background, and you get a new pretty picture when you complete the level.

My game is both "small" and "large" in scope at the same time. Its large in the sense that its a Multiplayer Online Game. But the scope of the gameplay is rather limited. I'm not trying to make a full-out MMORPG with all the content expected of one. And that was never my intention. Its an MMO in the sense that the server architecture can support a lot of players and AI units in the world.

Yet I feel like I get wrongly misjudged as a delusional person trying to make a full-out MMORPG. No my game doesn't have a focus on questing, professions, or theme-park areas and raids. People in this industry are too quick to Pidgeon-hole you into existing game genres when you may be trying to do something new entirely.

I have a playable demo, some interested players who provide feedback in discord, etc. The game mechanics started simple but have gotten more complex with each update. A lot of work is spent in improving the AI and making them behave "smartly". I pay for server hosting and manage the servers. Its just me. But it feels like I don't even get my resume looked at when I'm applying to jobs in the industry. Because I don't have any prior experience?

paused minesweeper game is a thing?

I haven't played it for decades. Actually pausing would be cheating, because most of the time is spent thinking. But it would make sense to stop counting time when the app is minimized. I guess, unless the player made a screenshot before that...

Okay, pausing is a bad idea if the hiscores are supposed to mean something.

I'm finding that dedicating yourself to working on your own game can be a detriment to finding an actual job in the industry? It feels like employers are wary about your intentions and whether or not you will stick around.

Employers also don't seem to take home-grown experience seriously? Even if you know more about the niche side of things like networking, graphics, AI programming. If you don't have exact experience in whatever tools/framework they use (UE blueprints, Unity, etc), they think you won't be a good fit. Even though tools are just tools and concepts are more important.

>> dedicating yourself to working on your own game can be a detriment to finding an actual job in the industry

That's why I say to make small games that already exist. There's no need to even innovate, you're learning. As soon as it's "your game" the focus is elsewhere and the scope usually gets out of hand. Nothing wrong with showing an original idea, but is it finished and polished?

>> employers are wary about your intentions and whether or not you will stick around

I guess it depends on what the person is showing. If what they show is some big design for a game they want to make and some unfinished pieces of code relating to that that doesn't inspire the confidence that they can finish the work, that they can commit and see it to the end.

>> If you don't have exact experience in whatever tools/framework they use (UE blueprints, Unity, etc), they think you won't be a good fit.

I personally think that's a huge mistake the industry is doing. I have seen it and agree with you that those are tools, and they change often. Being (or only hiring) Unreal programmers will limit you

How is this relevant in 2025? Gemini one-shots all of those. You have to be able to do something LLM can’t.

The interviewer wants to know you can make them. They can quickly figure that out in the interview.

Actually doing them teaches you how to make them, which will give you foundational knowledge you'll take with you into more complex endeavours. And it will show, I can tell if you actually understand why you built the more complex thing the way you did. If you just cargo-culted a bunch of patterns together in an effort to seem more competent than you are, a lack of fundamentals will show during interviewing.

I don't mean university course fundamentals, I mean pragmatic software fundamentals you get from building stuff.

It isnt about the product, it's about the journey. If you choose not to learn how to do basic math because the calculator can do it for you, you are missing out on huge swaths of understanding of math.

If you want to show somebody you can run a marathon, you don’t take a bus.

Humans knowing how to add is still relevant even though calculators exist.

If you can't do it yourself, you shouldn't let the AI do it for you.