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.
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.
It also really bugs me when I've put more time into reporting an issue or setting someone up for success than they've spent working on a solution.
You would know best, but it struck me that one reason to skip parts of a take-home interview assignment is that it was taking far longer than it "should". A sufficiently senior candidate should have noted this but (I'm feeling charitable towards junior candidates this lazy Sunday afternoon) maybe that's something that's a reasonable thing for them to learn in a real job.
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.
The struggle with being self-taught is that you don’t know what you don’t know.
yes, but he knew. i mean he should have known that he used stuff without knowing why.
i am mostly self taught too, and i agree with your statement, but i don't see an excuse for using stuff and not trying to understand why. i mean sure, when i follow a tutorial , at first i'll copy things i don't understand, but do that a few times, understanding should eventually come. that's how i learned how OO programming works. i followed the motions for a while, and one morning i woke up and it clicked. if you keep using something without understanding it, then it is time to ask questions. what is this thing that i keep using? how does it actually work, and what are other ways to solve the same problem?
things that i don't know are things that i never came across. i just recently had an interview that asked me questions where i honestly had to respond: i never touched this issue in my programming career so i can't give you an answer, just my best guess. but i never had a situation where i kept using something without eventually understanding why.
There are activities where this type of realization is constant, and activities where it is rare.
Interviewing a marketing manager is dominated vibes and optics, and driving that clarity about what their actual skills are is an uphill battle. With a software engineer I can usually get there in a few minutes.
But many creative activities are susceptible to avoiding harsh realizations. And tfa was about the creative side of gamedev.
That doesn’t mean that engineers are better than English majors. If anything, technical people should have more respect for great creative talents, because those people got almost no feedback and still figured out how to become great.
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?)
I feel there was a very narrow time window in the 90s when a bunch of game franchises were started where the devs could get away with shipping stuff with a ton of bugs. The first two Fallout games come to mind. So does the original Deus Ex. This is definitely the exception not the rule though! Hardware constraints weed out shitty (or at the very least suboptimal) code very quickly.
This is the exception not the rule however. If there's one unifying thing about games that succeed despite major issues with the code its that the developers tend to have extensive experience playing board games and can make a compelling gaming experience without having a game with all the bells and whistles.
I think maybe that was just when YOU were playing games, because games today still ship with tons of bugs - it usually isn't until a few years later that there is stability
There's numerous studios across the games industry that have high coding standards, mandatory code reviews, and expect upskilling. Game complexity keeps increasing, and live service games in particular need to be stable and well maintained and very well engineered in the first place. For many games, the days of games being pressed to disk, shipped out and done with (where bad code is fine) are long gone.
Do you have data supporting that? My favorite games (Factorio, Noita, Song of Syx to name a few) all share in common devs' passion and expertise. I don't have any example of a good game with shitty code.
I had an experience developing The Sims 1, which confirms the "Worse is Better" hypothesis, which is a harsh reality of the games industry and the software development industry in general: I pointed out to my manager that the code was shit, and we really needed to clean it up before shipping.
So he sat me down and explained: "Don, your job is TURD POLISHING. If you can just make your turd nice and shiny, we will ship it, and everybody will be happy with you, because that is what we hired you to do."
But then at least he gave me a few weeks to clean up and overhaul the worst code. The moral is be careful what you ask for, or you might have to be the one who shovels out all the shit.
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?
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.
> 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.
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.
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.
It also really bugs me when I've put more time into reporting an issue or setting someone up for success than they've spent working on a solution.
You would know best, but it struck me that one reason to skip parts of a take-home interview assignment is that it was taking far longer than it "should". A sufficiently senior candidate should have noted this but (I'm feeling charitable towards junior candidates this lazy Sunday afternoon) maybe that's something that's a reasonable thing for them to learn in a real job.
Extremely well-written and honest post.
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.
The struggle with being self-taught is that you don’t know what you don’t know.
yes, but he knew. i mean he should have known that he used stuff without knowing why.
i am mostly self taught too, and i agree with your statement, but i don't see an excuse for using stuff and not trying to understand why. i mean sure, when i follow a tutorial , at first i'll copy things i don't understand, but do that a few times, understanding should eventually come. that's how i learned how OO programming works. i followed the motions for a while, and one morning i woke up and it clicked. if you keep using something without understanding it, then it is time to ask questions. what is this thing that i keep using? how does it actually work, and what are other ways to solve the same problem?
things that i don't know are things that i never came across. i just recently had an interview that asked me questions where i honestly had to respond: i never touched this issue in my programming career so i can't give you an answer, just my best guess. but i never had a situation where i kept using something without eventually understanding why.
> But interview after interview, the story started to make sense. They were not wrong, I was not ready, and it took me a long time to admit that.
I believe this is one of the most humbling but also maturing moments in career and adulthood.
There are activities where this type of realization is constant, and activities where it is rare.
Interviewing a marketing manager is dominated vibes and optics, and driving that clarity about what their actual skills are is an uphill battle. With a software engineer I can usually get there in a few minutes.
But many creative activities are susceptible to avoiding harsh realizations. And tfa was about the creative side of gamedev.
That doesn’t mean that engineers are better than English majors. If anything, technical people should have more respect for great creative talents, because those people got almost no feedback and still figured out how to become great.
Marketing is easy, just ask the interviewee what metrics they use in their job. If they can answer (at all), hire them.
The expected answer is something like LTV/CAC.
Hey, I'm the original author. Thanks for sharing this. I saw a spike in my analytics and couldn't figure out where it was coming from, now I know :)
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.
It's worth pointing out that:
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.
Yeah, the actual point is "For a long time I avoided learning programming and it turns out you do actually need that for a game programmer job."
The issue was compounded by the author getting a lot of positive feedback on their game, because people respond to how the game looks, not the code.
For the solo indie approach that's not really an issue (many such cases!), but getting a job is a separate beast.
> 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.
What nobody told him is that it doesn't matter. The most beloved games have the shittest code.
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?)
I feel there was a very narrow time window in the 90s when a bunch of game franchises were started where the devs could get away with shipping stuff with a ton of bugs. The first two Fallout games come to mind. So does the original Deus Ex. This is definitely the exception not the rule though! Hardware constraints weed out shitty (or at the very least suboptimal) code very quickly.
This is the exception not the rule however. If there's one unifying thing about games that succeed despite major issues with the code its that the developers tend to have extensive experience playing board games and can make a compelling gaming experience without having a game with all the bells and whistles.
I think maybe that was just when YOU were playing games, because games today still ship with tons of bugs - it usually isn't until a few years later that there is stability
There's numerous studios across the games industry that have high coding standards, mandatory code reviews, and expect upskilling. Game complexity keeps increasing, and live service games in particular need to be stable and well maintained and very well engineered in the first place. For many games, the days of games being pressed to disk, shipped out and done with (where bad code is fine) are long gone.
> The most beloved games have the shittest code
Do you have data supporting that? My favorite games (Factorio, Noita, Song of Syx to name a few) all share in common devs' passion and expertise. I don't have any example of a good game with shitty code.
I had an experience developing The Sims 1, which confirms the "Worse is Better" hypothesis, which is a harsh reality of the games industry and the software development industry in general: I pointed out to my manager that the code was shit, and we really needed to clean it up before shipping.
So he sat me down and explained: "Don, your job is TURD POLISHING. If you can just make your turd nice and shiny, we will ship it, and everybody will be happy with you, because that is what we hired you to do."
But then at least he gave me a few weeks to clean up and overhaul the worst code. The moral is be careful what you ask for, or you might have to be the one who shovels out all the shit.
https://donhopkins.com/home/TheSimsDesignDocuments/TDSEditTo...
https://donhopkins.com/home/TheSimsDesignDocuments/Comprehen...
The Simpson’s Hit & Run and Fallout 3 come to mind
The entire Fallout series, lol.
Just played Fallout 2, and there's still unpatched game breaking bugs in there.
There are countless great games with a lot of bugs and performance problems. Maybe most of them have pretty code behind the scenes, but I doubt it.
What TFA describes is not someone who wrote poor quality code, but someone who could write no code at all, before the era of AI.
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?
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.
> 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.
On one hand, now anyone can ask AI to explain Queue<T>.
On the other hand, most people aren't curious enough to ask.
What's with all the Unity articles on the front page recently? Seems suspicious.