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.
Ugh... I've had two bad hires in two years that were exactly like this - if you can't follow simple instructions, how have you survived in this career for this long?
Ugh... we have a new colleague who does this repeatedly. Most recently, I said in order to build, you need to do this:
- git clone <repo1> <dest1>
- git clone <repo2> <dest2>
- git clone <repo3> <dest3>
What do they do? git clone repo1, 2, 3 without giving <dest> parameter, which clones into default folders named after the repos. Build fails of course because repo1 depends on repo2 and 3 being named specifically. He sends me the error log (remote colleague, yay) and I say: you gotta rename those folders. Instead of renaming them, tries other things for hours, then comes back and shows me other build errors. I look over the errors and realize, again, the folders are still named incorrectly. Rinse and repeat 2 more times before finally the build process works. Lost a few hours to this. This kinda stuff keeps happening with this colleague. It's really a huge time-sink. If I had more time, I would do remote call and watch over them, but I'm so deep in my own stuff that I don't have time to babysit (not to mention calls take 1-2 hours with this person just trying to explain really basic things, over and over and over again).
If he is young enough he probably did not know how the file systems worked (and I mean: what a directory is, what files are). Supposed to be quite common now for people using only mobile devices. So he lacked the fundamentals to understand what you wanted.
That's definitely a valid argument, but I highly doubt it since they know their way around Windows and Linux just fine. I honestly think it might be related to attention span, miscommunication, language barriers and/or maybe a heavy reliance on AI tools (though to be honest, even local LLMs would have spotted the error immediately).
But you know what's also frustrating? Code bases which involve multi-step manual steps to build.
You should be able to get a working local environment with a single command.
You should be able to get a working local build with a single build command.
If you have depedent projects, they should either be in a monorepo, or delivered through a packaging system so they are not depend on the specific local naming of other repos.
Having a repo depend on a different repo being in a specific place on the file system is bad, having multiple of them is terrible.
Stick what's needed in an onboarding script, and make sure it works before onboarding someone.
Ideally that script should be kept to a minimum, if it grows too large that's a sign you've split things artificially instead of finding natural splits.
I agree, and there are other fun gotchas that even more frustrating and convoluted. But everything is thoroughly documented and I even explicitly pointed out those potential issues before I gave them the assignment. When the errors first occurred, I pointed out the fix, which was ignored, multiple times. Should it be that difficult to rename a couple folders? The compiler errors were fairly easy to understand: can't find repo2. Is that too much to expect from someone?
In an ideal world and in retrospect, you are right. But the build process is very old, created by someone long gone, of which multiple projects depend upon, each with minor tweaks and always reliant on the same hard-coded paths which IMO isn't that bad and can easily be rectified - it's really not worth the time or energy to allow dynamically named folders, not to mention dangerous since it's a critical production system that's worked forever. Nobody wants to break a running system, nor has the time to clean things up properly, especially since there are tons of build scripts that all rely on these paths, and trying to fix all of them would be a huge amount of work, spread across multiple projects, all requiring sign-off from higher-ups who will never be able to justify the cost to fix something that already works.
at the very least there's no excuse for not having a shell script to check everything out in the right places! I've been the new person in teams with this sort of fragile setup and it's no fun whatsoever.
I hear you, but I still feel for the coworker, and if I newly joined a company and learned on my first day that they are failing the Joel Test[1] here in 2026, I would get that sinking feeling in my stomach that I made a huge mistake. There is no longer a valid excuse for having a build like that. "It's documented..." and "Nobody wants to touch..." "Not worth it to..." "Can't justify..." are all huge red flags.
Nice list, somehow I missed that one. I love Joel's wisdom.
The full build literally works in one step but the main prerequisite is to perform a few git clone commands which can be copy/pasted from the readme. Can't help it if they want to manually do git clone and let it name folders incorrectly and then subsequently ignore compiler errors and my advice to rename. Changing our antiquated workflow would have required changing a lot of other sensitive dependencies. What ever happened to the old adage "never change a running system" ? ;)
And people here are concentrating on our build system, which I will be the first to admit isn't perfect, but this isn't the only instance of me telling this person how to do things, them not listening to me and doing something else, letting me debug only to realize they didn't listen, telling them how to fix, only to be ignored _again_, rinse and repeat. It's unfortunately a recurring theme. I initially thought it was a communication error on my part, but I've heard similar complaints from several other colleagues as well.
See, you are probably right about that new hire. But the way you say things here, you do come across (at least to me) as "that guy". You know? "That guy" that says "we've always done it this way and that is why it's good and why we still do it that way".
What happened to "never change a running system" is that if the system is barely running at all, you better do change that system.
If I'm the new guy and you tell me how to do things and those things seem bad and there's no explanation for why they need to be that way, I'll also ignore you, coz I know how I want to do things and how things can be done better. Don't tell me to do things X way. Many roads lead to Rome and some are better than others. See my other reply. At my very first job I was also told how things work and how to do things. But things sucked and so I made them better anyhow.
Now, in the other part of the thread you also did mention how they just sent you error logs without reading and thinking about them themselves and such. That definitely is a red flag and the kind of thing that will make me fail someone's probation period. Definitely. But just because someone doesn't think that "the way we've always done things" is a good reason to keep doing something bonkers is where I'm no longer with you. And again, probably just your wording/what you disclose in various parts of these threads but it explains why "we concentrate on certain things only" ;)
With you on this one - I worked with a hopeless tester years ago - gave him a detailed test plan with a nice sequence of steps to follow to set up the scenario. I have no idea why but he decided to do the steps out of order, then wondered why my patch didn't do what it was meant to.
See, I would probably have been the guy that ignores the dest part. On purpose. Just to see whether this pile of poo shits itself and how much.
I would also recognize what happened when I see the error messages though and then silent quit until I've been with you guys for long enough my resume doesn't take a hit just because your interview process duped me into starting at your place.
Yes this sounds harsh. I know. Nothing against you personally. But I've been at too many such places. One can do things better.
haha I would totally empathize with you. But see, you would realize immediately that it doesn't work and why, but you are smart enough to realize it and would just rename the folder (as mentioned in the readme as the very first thing to do), hit build and voila, everything works as expected, instead of sending me log files, letting me debug your errors, ignoring my repeated instructions, waste my time helping you debug, back and forth until finally you just rename and move on. I had to say it 4x before it finally stuck. This guy seemingly wanted to get an initial build done so he could move on to actually fixing bugs. Maybe it's intentional to waste everyone's time so that he can book hours in the system and get paid for futzing around? :shrug:
and btw the system doesn't shit itself that much: the compiler errors are fairly straight-forward: this folder doesn't exist.
Of course everyone can always do better, but it's a legacy inherited system, and works fine, as long as things are named correctly. The readme is actually very short - literally the git commands are there to copy/paste and will create the correct directory names. There are plenty of other things to get hung up on, but naming folders correctly should IMO not be one of them.
Hehehe, definitely been there and dealt with that guy that I definitely didn't let pass his probation period. I see we do understand each other.
And I might not silent quit right away and try to actually improve things and see how it goes/how you "let me".
This does actually remind me of my very first job actually. It's been many, many, many years now. I found a stinking pile of disparate shell and perl scripts that made up the "backend" of the application I was hired into working on. Grown histerically for almost 15 years prior to me being hired fresh out of university. I started extracting common library code out of every single one of these every time that I was tasked with adjusting one of those scripts. I introduced a proper deployment from source control to production the second time I "broke" something, because someone had previously fixed a bug directly in production and forgot to check the fix into source control (and no, I didn't believe that it was not the guy that was working on the project w/ me for one second after seeing how they coded and how they defended everything that was bad about that pile of poo and how "it's too complicated to do X".
Well guess what, this new grad did all of that anyway. Without AI and without IDE refactoring support (I mentioned Perl and shell scripts, did I?) and without a single QA person in sight. And yes, every single one of the readers here very probably has bought a product that was "touched" by that software, without knowing, since it was an in-house administration tool.
I agree but it's probably more common than you think. I had a job where the setup involved running one setup command twice because the first time always failed. But that was called out in the documentation so it was fine. The reason it wasn't fixed is because the project was well on the way to being end of lifed so it wasn't worth it at all to fix the crappy set-up process.
> If you have depedent projects, they should either be in a monorepo, or delivered through a packaging system so they are not depend on the specific local naming of other repos.
Our git master actually considered this, but it would have caused other issues that I can't recall right now, so we got stuck with lots of repos. The readme literally has all the git commands, all they had to do was copy/paste them into the terminal.
No, I've onboarded a few people people over the years and everyone until now has been able to follow instructions. In one case the guy had stuff going in his personal life but it wasn't a case of me being unhappy with his output (which I would have understood) but he just didn't follow instructions. In the other case I'm 99% sure my manager and the recruiter misrepresented the job and he didn't want to be here but... grind it out until you find something new (which he did after 6 weeks). Instead he wasted my time and ended up leaving with a bad reputation.
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.
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.
> he should have known that he used stuff without knowing why.
We all use stuff without knowing why. Many of the folks on here are deeply curious people who love learning about the world around them, especially for the tools we use in our daily careers and hobbies, but even then there's a huge number of things in our lives that we just do because it's what we do and it works. If you went to a "being a person" interview, and they asked you why you used a bow knot to tie your shoes and what the pros and cons of it were versus other knots, would you really have an answer?
ok, to be fair, i have been sailing, so i learned a thing or two about knots, but i am also the inquisitive type that questions why things are the way they are. (your typical HN reader, as you say, i suppose). furthermore i have been moving around in the world a lot, which has naturally challenged many preconceived ideas.
i guess maybe my point is that being inquisitive is a natural part of learning and we should all be inquisitive when learning something.
i am unable to come up with an example of doing something without thinking about it, but i guess that is another case of not knowing what i don't know, or rather i can't think about it because i am not thinking about it.
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?)
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.
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.
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 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
Yeah try some early access games! I also don't remember thinking the games he mentioned were particularly buggy at the time. They worked fine for me on my PC. Why are you so sure they were unusually buggy? Just curious. You may be comparing what you heard to what you have seen.
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.
Hell, Minecraft is a perfectly good example. It's code is a mess, but it made it's developer a billionaire, and has to be one of the most played games ever.
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.
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.
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.
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.
There is an ocean between the level of complexities of the examples you gave. For the database side, it would be the equivalent of "write postgres from scratch", not "how do I take a postgres backup", assuming you want to do no frameworks at all (like you qualified for the game side).
Sure, here are the "steps" for creating that from scratch:
1. Setup lighting
2. Create a mesh importer system
3. Create an animation runner system
4. Create your 3D models + all animations needed (walk forward, crouch, run, jump, death, etc.)
5. Setup a camera system for following your character
6. Setup a physics engine for your character
7. Add support for collisions and high speed elements (i.e. Bullets)
8. Setup an AI system
9. Setup a particle system
10. Setup a player input system
11. Setup a save/load system
Follow those and you should be able to get from 0 to hero in a few years. Or you can use an engine and do it in a weekend.
I might have missed a step or twenty but people who want to avoid engines usually end up spending most of their time building an engine, and basically re-doing all things engines already provide.
And yes, making a postgres backup is orders of magnitude easier than making "just" a game, even the most basic one.
Are you interested in the graphics (how to render 3d, opengl/directx, shaders etc), in the “game engine” aspect (all of the various parts of a game coming together), game design, networking, or something else? All of it?
As people used to say on stack overflow - what have you tried so far?
- i have started brushing my c++ and learning 3d math for now
- i am interested to know for starters what does the 10000 ft landscape look like
- what are the major steps involved?
- what have I tried? I spent a lot of time looking into what kind of libraries exist. Rust has something called bevy which I would not touch given it is new and I dont want to work with double unknowns
- C++ has a library called raylib that seems to have a lot of functions for basic stuff.
- There seems to be a library called jolt which claims to handle physics well
- how is rendering / graphics pipeline stuff handled in c++. what libraries do we have for loading models, working with shaders, handling networking for gaming etc?
- the thing is i need to get a complete picture inside my head of how a 3d game is put together like how this https://visualrambling.space/neural-network/ gives you the picture you need to understand how a neural network works
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.
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.
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.
> 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.
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 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.
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.
Knowing the literature is criminally underrated. Nobody even asks for it anymore. I used to ask candidates when was the last time you implemented something described in a paper or textbook, and walk me through how you did it, and after 2010 or so, people stopped even being able to come up with an answer. I've worked with junior developers who get stumped with basic things like what units or format for arguments to pass to some SDK provided function, and they try everything besides reading the official SDK docs.
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?
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.
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.
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.
> 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.
And that kicker has been around since salaries have been high. I've interviewed people who flat out had zero interest outside of work in the field. Who only took a degree because of the salary.
It's incredible how a creative field that also happens to be critical to so many things can be infested by people who just don't care.
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.
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.
> 3D game is another beast altogether and linear algebra needs to be very solid for that.
Or you can use an engine, like Unity.
Edit: you responded and then deleted a post about "games that don't look like Unity on Unity". Ignoring that the looks of a game usually matter less in the long run than gameplay, a very, very short search shows that Escape from Tarkov[0] is made in Unity.
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.
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.
- git clone <repo1> <dest1>
- git clone <repo2> <dest2>
- git clone <repo3> <dest3>
What do they do? git clone repo1, 2, 3 without giving <dest> parameter, which clones into default folders named after the repos. Build fails of course because repo1 depends on repo2 and 3 being named specifically. He sends me the error log (remote colleague, yay) and I say: you gotta rename those folders. Instead of renaming them, tries other things for hours, then comes back and shows me other build errors. I look over the errors and realize, again, the folders are still named incorrectly. Rinse and repeat 2 more times before finally the build process works. Lost a few hours to this. This kinda stuff keeps happening with this colleague. It's really a huge time-sink. If I had more time, I would do remote call and watch over them, but I'm so deep in my own stuff that I don't have time to babysit (not to mention calls take 1-2 hours with this person just trying to explain really basic things, over and over and over again).
But you know what's also frustrating? Code bases which involve multi-step manual steps to build.
You should be able to get a working local environment with a single command.
You should be able to get a working local build with a single build command.
If you have depedent projects, they should either be in a monorepo, or delivered through a packaging system so they are not depend on the specific local naming of other repos.
Having a repo depend on a different repo being in a specific place on the file system is bad, having multiple of them is terrible.
Stick what's needed in an onboarding script, and make sure it works before onboarding someone.
Ideally that script should be kept to a minimum, if it grows too large that's a sign you've split things artificially instead of finding natural splits.
In an ideal world and in retrospect, you are right. But the build process is very old, created by someone long gone, of which multiple projects depend upon, each with minor tweaks and always reliant on the same hard-coded paths which IMO isn't that bad and can easily be rectified - it's really not worth the time or energy to allow dynamically named folders, not to mention dangerous since it's a critical production system that's worked forever. Nobody wants to break a running system, nor has the time to clean things up properly, especially since there are tons of build scripts that all rely on these paths, and trying to fix all of them would be a huge amount of work, spread across multiple projects, all requiring sign-off from higher-ups who will never be able to justify the cost to fix something that already works.
1: https://www.joelonsoftware.com/2000/08/09/the-joel-test-12-s...
The full build literally works in one step but the main prerequisite is to perform a few git clone commands which can be copy/pasted from the readme. Can't help it if they want to manually do git clone and let it name folders incorrectly and then subsequently ignore compiler errors and my advice to rename. Changing our antiquated workflow would have required changing a lot of other sensitive dependencies. What ever happened to the old adage "never change a running system" ? ;)
And people here are concentrating on our build system, which I will be the first to admit isn't perfect, but this isn't the only instance of me telling this person how to do things, them not listening to me and doing something else, letting me debug only to realize they didn't listen, telling them how to fix, only to be ignored _again_, rinse and repeat. It's unfortunately a recurring theme. I initially thought it was a communication error on my part, but I've heard similar complaints from several other colleagues as well.
What happened to "never change a running system" is that if the system is barely running at all, you better do change that system.
If I'm the new guy and you tell me how to do things and those things seem bad and there's no explanation for why they need to be that way, I'll also ignore you, coz I know how I want to do things and how things can be done better. Don't tell me to do things X way. Many roads lead to Rome and some are better than others. See my other reply. At my very first job I was also told how things work and how to do things. But things sucked and so I made them better anyhow.
Now, in the other part of the thread you also did mention how they just sent you error logs without reading and thinking about them themselves and such. That definitely is a red flag and the kind of thing that will make me fail someone's probation period. Definitely. But just because someone doesn't think that "the way we've always done things" is a good reason to keep doing something bonkers is where I'm no longer with you. And again, probably just your wording/what you disclose in various parts of these threads but it explains why "we concentrate on certain things only" ;)
I would also recognize what happened when I see the error messages though and then silent quit until I've been with you guys for long enough my resume doesn't take a hit just because your interview process duped me into starting at your place.
Yes this sounds harsh. I know. Nothing against you personally. But I've been at too many such places. One can do things better.
and btw the system doesn't shit itself that much: the compiler errors are fairly straight-forward: this folder doesn't exist.
Of course everyone can always do better, but it's a legacy inherited system, and works fine, as long as things are named correctly. The readme is actually very short - literally the git commands are there to copy/paste and will create the correct directory names. There are plenty of other things to get hung up on, but naming folders correctly should IMO not be one of them.
And I might not silent quit right away and try to actually improve things and see how it goes/how you "let me".
This does actually remind me of my very first job actually. It's been many, many, many years now. I found a stinking pile of disparate shell and perl scripts that made up the "backend" of the application I was hired into working on. Grown histerically for almost 15 years prior to me being hired fresh out of university. I started extracting common library code out of every single one of these every time that I was tasked with adjusting one of those scripts. I introduced a proper deployment from source control to production the second time I "broke" something, because someone had previously fixed a bug directly in production and forgot to check the fix into source control (and no, I didn't believe that it was not the guy that was working on the project w/ me for one second after seeing how they coded and how they defended everything that was bad about that pile of poo and how "it's too complicated to do X".
Well guess what, this new grad did all of that anyway. Without AI and without IDE refactoring support (I mentioned Perl and shell scripts, did I?) and without a single QA person in sight. And yes, every single one of the readers here very probably has bought a product that was "touched" by that software, without knowing, since it was an in-house administration tool.
Yes. That's what bash scripts are for.
Git submodules is a thing ...
edit: removed stupid hack that wouldn't work.
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.
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.
We all use stuff without knowing why. Many of the folks on here are deeply curious people who love learning about the world around them, especially for the tools we use in our daily careers and hobbies, but even then there's a huge number of things in our lives that we just do because it's what we do and it works. If you went to a "being a person" interview, and they asked you why you used a bow knot to tie your shoes and what the pros and cons of it were versus other knots, would you really have an answer?
actually, yes i would.
ok, to be fair, i have been sailing, so i learned a thing or two about knots, but i am also the inquisitive type that questions why things are the way they are. (your typical HN reader, as you say, i suppose). furthermore i have been moving around in the world a lot, which has naturally challenged many preconceived ideas.
i guess maybe my point is that being inquisitive is a natural part of learning and we should all be inquisitive when learning something.
i am unable to come up with an example of doing something without thinking about it, but i guess that is another case of not knowing what i don't know, or rather i can't think about it because i am not thinking about it.
I suggest an edit to fix the typo.
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.
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.
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.
Hell, Minecraft is a perfectly good example. It's code is a mess, but it made it's developer a billionaire, and has to be one of the most played games ever.
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...
Just played Fallout 2, and there's still unpatched game breaking bugs in there.
I believe this is one of the most humbling but also maturing moments in career and adulthood.
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.
The expected answer is something like LTV/CAC.
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.
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.
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.
It doesn't even have to look that good. Relying on vapid positivity from Reddit will do that to you.
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.
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.
- 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?
1. Setup lighting 2. Create a mesh importer system 3. Create an animation runner system 4. Create your 3D models + all animations needed (walk forward, crouch, run, jump, death, etc.) 5. Setup a camera system for following your character 6. Setup a physics engine for your character 7. Add support for collisions and high speed elements (i.e. Bullets) 8. Setup an AI system 9. Setup a particle system 10. Setup a player input system 11. Setup a save/load system
Follow those and you should be able to get from 0 to hero in a few years. Or you can use an engine and do it in a weekend.
I might have missed a step or twenty but people who want to avoid engines usually end up spending most of their time building an engine, and basically re-doing all things engines already provide.
And yes, making a postgres backup is orders of magnitude easier than making "just" a game, even the most basic one.
As people used to say on stack overflow - what have you tried so far?
Also - this might be a good starting point: https://www.gameenginebook.com/
- i am interested to know for starters what does the 10000 ft landscape look like
- what are the major steps involved?
- what have I tried? I spent a lot of time looking into what kind of libraries exist. Rust has something called bevy which I would not touch given it is new and I dont want to work with double unknowns
- C++ has a library called raylib that seems to have a lot of functions for basic stuff.
- There seems to be a library called jolt which claims to handle physics well
- how is rendering / graphics pipeline stuff handled in c++. what libraries do we have for loading models, working with shaders, handling networking for gaming etc?
- the thing is i need to get a complete picture inside my head of how a 3d game is put together like how this https://visualrambling.space/neural-network/ gives you the picture you need to understand how a neural network works
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.
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.
Not clear how this plays out.
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 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.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?
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.
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.
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.
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 the other hand, most people aren't curious enough to ask.
It's incredible how a creative field that also happens to be critical to so many things can be infested by people who just don't care.
Huh? Those aren't unrelated facts. The people who don't care are there because the field is critical to many things.
If it wasn't, they'd leave, because they don't care.
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.
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.
Or you can use an engine, like Unity.
Edit: you responded and then deleted a post about "games that don't look like Unity on Unity". Ignoring that the looks of a game usually matter less in the long run than gameplay, a very, very short search shows that Escape from Tarkov[0] is made in Unity.
https://en.wikipedia.org/wiki/Escape_from_Tarkov
It seems I've underestimated Unity, thank you for changing my mind!
You kinda feel that you are learning something but you only truly learn when you have to do it from scratch.