I submitted this because I thought it was a good and nuanced (if long) take.
FTFA:
> If I had AI in 2019, I would not have lasted 3 years before the interview crashed me. I would have lasted longer, and the crash would have been worse.
> Before AI, I got a lot of interviews. Companies would talk to anyone with a reel. Today a beginner can send out fifty applications and not even get a first call. The thing that saved me may not be available to people starting out now. I do not have a clean answer for what to do about that. I only know that interviews were the best school I ever had, and I feel for anyone who is being shut out of that classroom.
There's a great list of Fundamentals halfway through. Though I have no frame of reference for how reasonable it is. (Is the average game dev really expected to implement a rigidbody sim from scratch?)
That list missed the biggest mistake all Game Programmers make: They write code for the games industry. If you can program a videogame, you can program a shitty webapp, and the shitty webapp industry pays twice as much. Video games are great, but that's an argument for making your own game, not working for the soulless meatgrinder that is the games industry.
I was thinking about this too, and I think there are two different views you can take.
1. Do you want to work IN the games industry?
2. Do you want to make and ship your own games?
I think the overall internal engineering standard for #1 is higher, because you're ultimately assessed against that standard by others.
For #2 _as long as it works_, you can get away with some under the hood crap, but you're the one that suffers for it (and hopefully not your players). I think I'd be wary (as I'm wary of this for myself), that aiming for #2 gives you an easy out to produce crap, as no one is holding you to standard other than yourself. Doesn't mean you shouldn't do it obviously, but it's a risk.
Thanks for sharing your story, it was an engaging read.
The part about filters in interviews resonated with me because of a recent experience. The place I work has been interviewing for new developers and the team lead asked me for my opinion on one of them. Overall seemed like a good candidate. But when I took a closer look at the assignment and the solution, I noticed that while technically the solution was good, the candidate had ignored a bunch of requirements outlined in the assignment.
At first I was willing to give him a chance, but when I gave it more thought, I realized that one of the biggest issues I've had with colleagues was them not reading the issue they're given, not understanding it, not fulfilling the requirements given in the issue and/or outright ignoring what's written because they independently decide they know a better solution (without consulting anybody), which turns out to be worse because of reasons which might not have been outlined in the issue, but still lead to the given requirements.
I pointed this out and felt it was a big red flag that, in a best-case scenario, this candidate was still unwilling to follow or incapable of following clear instructions. The candidate wasn't invited to the next round.
Thanks for sharing! (Sorry the following is written before I realised you posted your own blog post!)
It does seem like a trap, although you might nit have had the raw technical skills for the job they applied (by the way why wasn't he screened out early rather than on the take home task?),
They clearly have a lot of the skills around game design.
The trouble is that they also didn't have the high level skills that someone who does have the low level technical skills might need from a lead!
I'm not entirely sure on the take that AI would make it worse. If they are satisfied with the kind of game they make. Then they could continue to make games for many years.
I do think it's right that Game Developer companies want technically highly skilled people. My favourite thing about AAA gaming is the feeling of the constant cutting edge.
On the other than, I don't see why they couldn't have a long and fruitful Indie career.
The struggle with being self-taught is that you don’t know what you don’t know. This is probably even worse in areas like Unity, where the coding part is sort of a sideshow to the main event. Nowadays the problem is you lack the discernment to evaluate AI output.
I wrote The Conputer Science Book (https://a.co/d/01e62STx) to act as that basic building block and help orient self-taught developers.
What did come out from the blog post though:
- OP writes really well
- OP has learned to be very honest with themselves (and I hope not too self-critical now)
- OP seems really good at delivering things people like, even if they’re a bit cobbled together
All of which are very valuable and harder to learn than programming fundamentals tbh.
- OP takes rectifying what they deem to be deficiencies seriously, and actively work to fill those gaps.
At first I was reading the article thinking "wtf, that can't be real" and by the end felt I had respect for OP, both for their self-reflection and their willingness to put in the effort to learn. Admirable, really.
I wonder how long/far someone can truly go without actually knowing stuff today. I don’t know about game dev but the web is certainly built on abstraction: In university I’ve met people whose portfolio sites are made in NextJS but don’t know what React, the DOM or even HTML is. I think this is bad. At the same time (with the help of AI) they are certainly shipping things and working real jobs.
At least on the web, with frameworks and stuff abstracted into magic services or libraries, you can go really far without knowing what you’re doing. At what point does not knowing the lower level stuff start becoming a hard ceiling?
> Then the interviewer asked me why I used Queue<T>. I couldn't answer
And this was before AI. Imagine the amount of people who will never be able to answer similar questions. I am going to maybe have a bad take, but if you don't know what you're doing, you shouldn't be working in the field until you do. It's not okay to wing it into new roles with more responsibility.
Just wanted to say I loved this article. In a way it didn't say anything "new", and yet all the anecdotes were spot on and I really liked the writing style.
I felt this article in my bones. I also had the same realisation years ago and eventually wrote about it on my blog: https://omeysalvi.com/blog/blog-11. I still have a long way to go but I feel encouraged that at least I'm learning with intent now.
Remembering which ones are FIFO and LIFO helps you remember what is what for etc
But yeah- had to read an article and a book- I hated most of the Unity youtube tutorials- enough info/help to get you going but they leave you stranded in the woods without a path out because you were blinding following someone else when you walked in.
Better to read/learn and understand the small bits yourself slowly as they are the breadcrumbs that lead you out.
I went to a private university to learn gamedev. And I feel like I learned game but not dev. Yes I slung a lot of code but, when the game industry dried up and I applied for a bunch of developer positions, I kept finding terms I had never heard of. Basically any methodology other than compile and fix was completely absent from my skillset. What I had learned, I had discovered while helping mates in other disciplines with their coding assignments. And the learnings I had were completely transitory. Tricking DirectX 9 into compiling was actually quite different even from DX8 or DX10/11.
I think this kind of thing is endemic, and its not just a youtube video problem. I guess you could see private education as kind of the same beast as self education.
That said, it did give me troubleshooting skills, because effectively we were taught break fix to such a spectacular level, especially in netcode, that my skills were very easily transferable. Didn't come back to code for ages.
Not the same issue as the author, as I come from programming and been toying with Unity for myself / hobby. But it's surprisingly difficult to learn, because most guides and tutorials don't teach you the fundamentals. They teach you how to specifically do X, but it's hard to apply when you want to make something else. Often they also "hack" it to work, and as an experienced dev I can then really feel that this isn't the way to actually do it, it's just a shortcut, but I don't know how it should be done.
Like the input system. Many tutorials will just assign a listener on WASD buttons or something. But that only gets you so far.
Or the mentioned Brackeys. Very cool and well produced tutorials to make certain graphical effects. But often they are impossible to combine with your actual shaders, and if mindlessly applied you haven't learned anything generalizable you can use for your own vision. Just then have to hope there exist a tutorial or asset for whatever effect you're looking for.
It takes a lot of humility and strength to admit this. Kudos to the author.
I was similar to that in the past, chasing tutorials and only having half-baked knowledge. What shook me out of that was this article: https://fabiensanglard.net/c/
I'm going to start with the things I didn't take too seriously: Internet tutorials, blogs and almost anything brought by Google (yes, it includes this article). I usually considered those sources unreliable and potentially harmful.
Like a lot of people in the industry I used to Google way too often. Overtime I found the illusion of speed and the inaccuracy of the answers to be counter-productive.
No website is as good as a good book. And no good book is as good as a disassembly output.
This set me straight and got me to look into actual authoritative sources. Instead of tutorials read a proper book. Don't scrape StackOverflow, read the reference documentation. Learn to write automated tests instead of randomly poking around in the application. The thing is, I did not even intend to learn C, but after reading that article and other articles on that website I accepted that if I want to get good at programming I should start with the fundamentals, and C was a good starting point. It was the first language I actually learned properly.
Thank you for sharing your story, and I'm so glad it worked out in the end.
This story however is also why algorithmic interviews and the supposedly "irrelevant to the real job" programming interviews are not going anywhere soon.
Having done a lot of hiring, it's surprising how many candidates do not actually know how to code despite experience and looking good on paper.
This is a great, reflective article that made me think of specific situations I've been in with people in my career that did not possess the same level of introspection. They are everywhere, which is why those interview questions he mentions get asked.
Particularly though, this hit home -
> The interviews were not silent on my end. I was not freezing and saying nothing. I was pretending. I was trying to sound like I knew, hoping the interviewer would believe me and move on. They always knew. You cannot fake technical answers in front of people who have asked the same questions hundreds of times. Looking back, that performance was worse than just saying I do not know. It wasted their time and it delayed my own learning.
This is the thing that absolutely maddens me with some people who I have worked very closely with before. They don't know enough to know that they don't know, but either are so insecure or with outsized ego, they cannot admit it publicly, because that threatens their sense of expertise. They also aren't willing or able to do the "boring" work to catch up (that the author mentions at one point). The farther you go into your career without getting past what this guy went through, the worse it gets, and you'd be shocked how long some people can last living in this world, which to me looks like hell.
I've had people confidently tell me stuff about niche areas of my expertise I knew they'd never worked on in their life, and start trying to drive decisions around those things based on that fake expertise, and being in the awkward spot of "do I protect their ego, let them fail, or tell them to please listen to me?" But I found when you do the latter, it falls on deaf ears, because they do not know enough to even understand that you can tell the confabulated responses they give to questions tell me immediately they have no effing clue what they're talking about, so any feedback will just be interpreted as threatening or incorrect.
I'm positive I have done this in the past, not saying I am perfect, but entering a mid to mid senior part of my career now and having worked with a ton of different people, when I see it now, I'm very unsure how to deal with it. This guy, bless his heart because it's so honest, likely received tons of direct feedback he wouldn't or couldn't listen to.
We're going to see much more of this. It's possible to get a lot done without actually knowing how to program now. Amusingly, this was with Unity, and didn't even involve AI. We're going to have a whole generation of developers who can't really program. But they can open the hood and mess with the internals. They're more than users, but less than programmers.
I think the author's being a bit hard on themselves.
Vanishingly few people ever learn a new thing optimally. Programming in particular takes years to learn thoroughly enough to get to a level where you can consistently produce quality work. It's normal to have gaps in your knowledge that you realise would've been better to fill earlier in your journey.
Like, there would be plenty of people who spent years studying data structures, algorithms, and other fundamentals who never actually built anything in that time.
The very first mistake you made was using Unity. Start from scratch. A game loop is really just draw(), update() positions in a loop. Even smaller effects can be done with simple programming.
Recently I played around with ChatGPT for some effects for JS game, the results were interesting and very experimental.
3D game is another beast altogether and linear algebra needs to be very solid for that.
It's an incredibly inefficient way to make a game, but you could check out Handmade Hero by Casey Muratory. I'm not speaking at all to the overall quality of the work. But he definitely bootstraps the game from scratch and there is a ton to learn about the low level graphics and input systems.
Day 004 is where he actually starts drawing on the screen. So about five hours in if you skip the C intro. Or you could start writing to the screen in under 30 minutes with some basic libraries like SDL. In my experience most game devs, even those who want to write the code and not live inside Unity are using some OS/Graphics/Input abstraction library.
The most enlightening part of learning is finding our own unknown unknowns.
For me it is different, making a best piano in the world is different from composing like Beethoven. Well what I am saying, learning unity is doable but what you do with it is most important. Back then I used to think learning photoshop, paint tools makes me artist, but I have realised being artist is actually faraway being from tool operator.
38 comments
[ 2.4 ms ] story [ 48.9 ms ] threadFTFA:
> If I had AI in 2019, I would not have lasted 3 years before the interview crashed me. I would have lasted longer, and the crash would have been worse.
1. Much of the core lesson in this article has nothing to do with Unity specifically, and applies to self-taught programmers in general; and
2. This person has a vested interest in making you believe learning Unity is especially difficult.
There, fixed that for you.
So many college educated programmers I've worked with that have zero real world experience and so make a ton of poor decisions with code design.
The goals of getting a job in the industry, and making a game people love, have completely different requirements, with surprisingly little overlap.
---
As for the latter (game industry requirements) I read this article a while back.
https://lazyfoo.net/articles/article11_top-ten-mistakes-game...
There's a great list of Fundamentals halfway through. Though I have no frame of reference for how reasonable it is. (Is the average game dev really expected to implement a rigidbody sim from scratch?)
1. Do you want to work IN the games industry? 2. Do you want to make and ship your own games?
I think the overall internal engineering standard for #1 is higher, because you're ultimately assessed against that standard by others.
For #2 _as long as it works_, you can get away with some under the hood crap, but you're the one that suffers for it (and hopefully not your players). I think I'd be wary (as I'm wary of this for myself), that aiming for #2 gives you an easy out to produce crap, as no one is holding you to standard other than yourself. Doesn't mean you shouldn't do it obviously, but it's a risk.
The part about filters in interviews resonated with me because of a recent experience. The place I work has been interviewing for new developers and the team lead asked me for my opinion on one of them. Overall seemed like a good candidate. But when I took a closer look at the assignment and the solution, I noticed that while technically the solution was good, the candidate had ignored a bunch of requirements outlined in the assignment.
At first I was willing to give him a chance, but when I gave it more thought, I realized that one of the biggest issues I've had with colleagues was them not reading the issue they're given, not understanding it, not fulfilling the requirements given in the issue and/or outright ignoring what's written because they independently decide they know a better solution (without consulting anybody), which turns out to be worse because of reasons which might not have been outlined in the issue, but still lead to the given requirements.
I pointed this out and felt it was a big red flag that, in a best-case scenario, this candidate was still unwilling to follow or incapable of following clear instructions. The candidate wasn't invited to the next round.
I believe this is one of the most humbling but also maturing moments in career and adulthood.
It does seem like a trap, although you might nit have had the raw technical skills for the job they applied (by the way why wasn't he screened out early rather than on the take home task?),
They clearly have a lot of the skills around game design.
The trouble is that they also didn't have the high level skills that someone who does have the low level technical skills might need from a lead!
I'm not entirely sure on the take that AI would make it worse. If they are satisfied with the kind of game they make. Then they could continue to make games for many years.
I do think it's right that Game Developer companies want technically highly skilled people. My favourite thing about AAA gaming is the feeling of the constant cutting edge.
On the other than, I don't see why they couldn't have a long and fruitful Indie career.
The struggle with being self-taught is that you don’t know what you don’t know. This is probably even worse in areas like Unity, where the coding part is sort of a sideshow to the main event. Nowadays the problem is you lack the discernment to evaluate AI output.
I wrote The Conputer Science Book (https://a.co/d/01e62STx) to act as that basic building block and help orient self-taught developers.
What did come out from the blog post though:
- OP writes really well
- OP has learned to be very honest with themselves (and I hope not too self-critical now)
- OP seems really good at delivering things people like, even if they’re a bit cobbled together
All of which are very valuable and harder to learn than programming fundamentals tbh.
- OP takes rectifying what they deem to be deficiencies seriously, and actively work to fill those gaps.
At first I was reading the article thinking "wtf, that can't be real" and by the end felt I had respect for OP, both for their self-reflection and their willingness to put in the effort to learn. Admirable, really.
At least on the web, with frameworks and stuff abstracted into magic services or libraries, you can go really far without knowing what you’re doing. At what point does not knowing the lower level stuff start becoming a hard ceiling?
And this was before AI. Imagine the amount of people who will never be able to answer similar questions. I am going to maybe have a bad take, but if you don't know what you're doing, you shouldn't be working in the field until you do. It's not okay to wing it into new roles with more responsibility.
Being old enough to enjoy reading technical books/articles is a + and knowing the acronym RTFM
I learned about collection types other than array/list from reading this article by the creator of the game Project Zomboid- as he used Stacks for zombie behaviors https://ia600303.us.archive.org/18/items/pdfy-G4Wm9sq1LU298r...
Then I got this book which is a great overview of C# for use in Unity https://csharpplayersguide.com/
Remembering which ones are FIFO and LIFO helps you remember what is what for etc
But yeah- had to read an article and a book- I hated most of the Unity youtube tutorials- enough info/help to get you going but they leave you stranded in the woods without a path out because you were blinding following someone else when you walked in.
Better to read/learn and understand the small bits yourself slowly as they are the breadcrumbs that lead you out.
I went to a private university to learn gamedev. And I feel like I learned game but not dev. Yes I slung a lot of code but, when the game industry dried up and I applied for a bunch of developer positions, I kept finding terms I had never heard of. Basically any methodology other than compile and fix was completely absent from my skillset. What I had learned, I had discovered while helping mates in other disciplines with their coding assignments. And the learnings I had were completely transitory. Tricking DirectX 9 into compiling was actually quite different even from DX8 or DX10/11.
I think this kind of thing is endemic, and its not just a youtube video problem. I guess you could see private education as kind of the same beast as self education.
That said, it did give me troubleshooting skills, because effectively we were taught break fix to such a spectacular level, especially in netcode, that my skills were very easily transferable. Didn't come back to code for ages.
You kinda feel that you are learning something but you only truly learn when you have to do it from scratch.
Like the input system. Many tutorials will just assign a listener on WASD buttons or something. But that only gets you so far.
Or the mentioned Brackeys. Very cool and well produced tutorials to make certain graphical effects. But often they are impossible to combine with your actual shaders, and if mindlessly applied you haven't learned anything generalizable you can use for your own vision. Just then have to hope there exist a tutorial or asset for whatever effect you're looking for.
I was similar to that in the past, chasing tutorials and only having half-baked knowledge. What shook me out of that was this article: https://fabiensanglard.net/c/
This set me straight and got me to look into actual authoritative sources. Instead of tutorials read a proper book. Don't scrape StackOverflow, read the reference documentation. Learn to write automated tests instead of randomly poking around in the application. The thing is, I did not even intend to learn C, but after reading that article and other articles on that website I accepted that if I want to get good at programming I should start with the fundamentals, and C was a good starting point. It was the first language I actually learned properly.Having done a lot of hiring, it's surprising how many candidates do not actually know how to code despite experience and looking good on paper.
Particularly though, this hit home -
> The interviews were not silent on my end. I was not freezing and saying nothing. I was pretending. I was trying to sound like I knew, hoping the interviewer would believe me and move on. They always knew. You cannot fake technical answers in front of people who have asked the same questions hundreds of times. Looking back, that performance was worse than just saying I do not know. It wasted their time and it delayed my own learning.
This is the thing that absolutely maddens me with some people who I have worked very closely with before. They don't know enough to know that they don't know, but either are so insecure or with outsized ego, they cannot admit it publicly, because that threatens their sense of expertise. They also aren't willing or able to do the "boring" work to catch up (that the author mentions at one point). The farther you go into your career without getting past what this guy went through, the worse it gets, and you'd be shocked how long some people can last living in this world, which to me looks like hell.
I've had people confidently tell me stuff about niche areas of my expertise I knew they'd never worked on in their life, and start trying to drive decisions around those things based on that fake expertise, and being in the awkward spot of "do I protect their ego, let them fail, or tell them to please listen to me?" But I found when you do the latter, it falls on deaf ears, because they do not know enough to even understand that you can tell the confabulated responses they give to questions tell me immediately they have no effing clue what they're talking about, so any feedback will just be interpreted as threatening or incorrect.
I'm positive I have done this in the past, not saying I am perfect, but entering a mid to mid senior part of my career now and having worked with a ton of different people, when I see it now, I'm very unsure how to deal with it. This guy, bless his heart because it's so honest, likely received tons of direct feedback he wouldn't or couldn't listen to.
Not clear how this plays out.
Vanishingly few people ever learn a new thing optimally. Programming in particular takes years to learn thoroughly enough to get to a level where you can consistently produce quality work. It's normal to have gaps in your knowledge that you realise would've been better to fill earlier in your journey.
Like, there would be plenty of people who spent years studying data structures, algorithms, and other fundamentals who never actually built anything in that time.
Recently I played around with ChatGPT for some effects for JS game, the results were interesting and very experimental.
3D game is another beast altogether and linear algebra needs to be very solid for that.
- if i want to make a 3d third person tactical shooter from scratch) without unreal, unity, godot etc what is the exact flow
- i know c++ and have a decade of programming experience. i am revising 3d math from that awesome 3d math primer book
- what are the steps?
if you asked me to write a program to take a postgres backup i would say, the steps are
- spin a docker container for postgres 18.1
- perform a pg_dump using directory format
- take a tar archive out of that directory
- create a brotli archives out of the tar archive above as it doesnt work directly with directories and gives better compression than tar
- copy the file from container to host
- shut the containers down
- can someone give me an overview along the above lines for gamedev?
https://guide.handmadehero.org/
Day 004 is where he actually starts drawing on the screen. So about five hours in if you skip the C intro. Or you could start writing to the screen in under 30 minutes with some basic libraries like SDL. In my experience most game devs, even those who want to write the code and not live inside Unity are using some OS/Graphics/Input abstraction library.
https://examples.libsdl.org/SDL3/renderer/02-primitives/
- Learn good programming
- Learn good 3D art
- Make a program that displays the 3D art on the screen
- Make it react to keyboard input
- Draw the rest of the owl
For me it is different, making a best piano in the world is different from composing like Beethoven. Well what I am saying, learning unity is doable but what you do with it is most important. Back then I used to think learning photoshop, paint tools makes me artist, but I have realised being artist is actually faraway being from tool operator.