How I learned Unity the wrong way
TL;DR: I spent 3 years copying tutorials from Brackeys and Code Monkey, shipped Skeletons AR to the top of r/gamedev, and still failed a Belgrade interview because I couldn't explain why I used Queue
. Tutorial hell made me look like a developer without teaching me how to actually debug or think.
A week before the interview, I told everyone I was moving to Belgrade. I had just submitted a take-home task I spent 7 days on. This was before AI, and 7 days was normal. I built the best looking version of the game they had ever seen, and I was sure I was getting the job.
Then the interviewer asked me why I used Queue<T>. I couldn't answer. I had used it because I watched a Code Monkey tutorial on grid search and he used it there. I had no idea how a queue worked or why I picked it. That was the moment I knew I failed, and I did not move to Belgrade.
I had been making Unity games for years. I thought I was a developer. That one question showed me I was not.
Years of Unity without writing code
I had been using Unity for 3 years before that interview. I watched everyone. Brackeys, Code Monkey, Jason Weimann, plus a lot of random YouTube guys whose names I never bothered to remember. I followed along, paused the video, typed what they typed, pressed play. If it worked, I moved on.
In those 3 years I built Skeletons AR. It was a playable AR game for Android. You printed a Vuforia marker, pointed your phone at it, and skeletons came out of it and fought on your desk. At the time, most AR demos were business cards that spun a 3D logo. Mine was a game. I built it in about a month. It hit the top of r/gamedev and stayed the top post of all time for a year. People messaged me, people shared it, and I thought I was somebody. Commenters on Reddit thought I was some next John Carmack level programmer because AR at the time looked like something from the 22nd century. In reality it was just the Vuforia SDK doing most of the work and me writing maybe five scripts on top of it. I built the whole thing by copying tutorials and stitching forum scripts together. I could not have explained a single system in it, but it ran, it looked good, and the internet told me it was great. That was enough proof for me that I knew what I was doing.
I did not know what I was doing. When something broke, I did not debug. I did not know what debugging was. I would change a line, press play, see if it worked, change it again, press play again. A single bug could take a full day. I never once used Debug.Log to check a value, I did not use breakpoints, and I did not use git.
When I needed new code, I opened Unity Forums, Reddit, or another tutorial. I searched for someone who had done the thing I was trying to do, copied their script into my project, and if it worked, I left it. If it did not, I searched again. I could build things but I could not explain them. I could not write a script from an empty file without something to copy from. I could not tell you what a class was, or why you would use a list instead of an array. I used Queue<T> in my take-home because Code Monkey did. I thought this was programming.
Everyone uses Google, and it is okay
At some point I started to feel bad about how much I was Googling. I did not know how to write anything on my own. So I Googled the question directly. Do senior developers use Google? The answer everywhere was yes. Every senior developer uses Google. Nobody memorizes everything. This made me feel better, and I kept coding the way I was coding. What I did not understand, and what nobody on those Reddit threads made clear to a beginner, is that seniors and beginners use Google for completely different things. A senior forgets the exact syntax for a LINQ method and Googles it. A senior cannot remember a specific flag on a CLI tool and Googles it. I was Googling "how to rotate a character around its axis Unity" and pasting someone's script into my project. They were filling in tiny gaps in knowledge they already had. I was downloading the knowledge itself. It looked the same on the screen. It was not the same thing.
I never actually tested anything
I would run the thing once, see that it worked, and ship it. If it ran on my computer, it ran. I had no concept of edge cases. I had no idea that a user would do something I had not thought of, or that someone would try to abuse a feature on purpose. I was playing Skyrim at the time, which was full of bugs and was still one of the biggest games ever made. On every forum I read, people said bugs were normal and everyone makes them. That was true in a sense, but I was not making the kind of bugs experienced devs make. They ship rare edge cases. I was shipping things where the user had to close the whole app to get unstuck.
I never wrote a unit test, and I would not hold that against my past self too hard. Unit tests are not standard in game dev. Budgets do not support them, and a lot of 3D work is not a natural fit for that kind of testing. What I should have been doing was manual testing. Trying to break my own thing before handing it to a user. I did not do that either. When a user hit a bug, I would tell them it was normal, restart the app, I will fix it in the next update. I was using real users as my QA team, and I did not know that was what I was doing.
I also had no idea what a regression was. I would add a feature, break an older feature without noticing, and ship both. Months later a user would tell me something stopped working, and I would have no idea when.
What actually changed this for me was working on real projects with a dedicated QA team. They found every bug I missed, and they found bugs I did not believe were possible until they showed me. I hated QA at first. Nobody enjoys being told their work is broken. But I learned more from that back and forth than from any tutorial I ever watched. I still do not write unit tests in game dev often. In web work I do, because web apps get abused in ways games do not. The real shift was not the tests. It was learning to look for the thing I had missed, before somebody else did.
The project I lost because I did not use git
Before the interviews, there was another lesson I should not have had to learn the hard way. I was building an AR CMS for a client. The idea was that non-programmers could build AR content without writing code. The only reason I could pull it off was that I found an open source project from someone who had already solved the hard parts. Looking back, I still do not know why that person open sourced it. It was incredibly valuable. I made $20,000 on the project he created.
I worked on it for about a month. Then the project got corrupted. I was not using git, I was not using any source control, and I had one copy of the project on one machine. One day it was gone. I told the client what happened. He was not a programmer, and he said it was fine. He thought this was a normal thing that happened to developers. It is not a normal thing that happens to developers. It is a thing that happens to people who do not use source control. I rebuilt the project in a few days because I still had the open source base and I knew what I had written. That is the only reason this story has a soft ending. I started using git the next day. I cannot believe I worked in Unity for years without it, and if you Google it, you will find thousands of people who lost entire projects the same way. It is more common than it should be.
The Blender guy who knew more than me
The biggest shock did not come from an interviewer. It came from a guy I collaborated with on a project. A friend introduced us. He would have told you he was not a coder. He had been doing Blender for a few months. I had been "programming" in Unity for 3 years.
He knew more than me.
What I did not understand at the time, and what he did not understand either, is that he had been writing Python inside Blender the whole time. That was his path into programming. He did not call it programming, he called it Blender. But he was reading docs, writing scripts, and building things from the ground up. He had the fundamentals without the label. I had the label without the fundamentals.
He had an eye for research. He read things properly before he used them. At one point he was looking at my code and he asked me why I was not using continue inside a for-loop. I did not know continue existed. I had written hundreds of for-loops in 3 years and I had never heard of it.
Another time he asked me to explain what a MeshFilter was in Unity. Not what it does in a vague sense, actually explain it. I could not. I also could not explain MeshRenderer. I knew you dragged both onto a GameObject to make a 3D model show up. I had no idea what each one was for, or that one depended on the other. I had shipped Skeletons AR without understanding the two components that made every model in the game visible.
I failed that project. Not in some small way. Badly enough that I knew it, and badly enough that I refunded my friend who hired me. That was the moment the story I had been telling myself stopped working. Somebody who did not even think of himself as a programmer was running circles around me. I could not blame the interviewer this time. There was no interviewer.
Later I managed to sell him to a company I knew. He proved himself quickly. Today he works at a AAA studio and he is a respected name in the industry. I was already years into Unity when we met, and he thought he was just a guy who did Blender. The gap between us was not experience. It was how we learned.
I did not follow the instructions
Going back to the Belgrade interview for a minute. Before the take-home task, they sent me a list of requirements. One of them was to install an exact version of Unity. They specified the version number. I ignored it. I worked in a newer version because that is what I had installed, and because I thought it did not matter. I was getting ahead of myself. I told myself they just wanted the game working, not the version.
It never clicked. I thought I was smarter than the interviewers.
I did not understand that the version requirement was not a technical constraint. It was a filter. They were checking if I could follow simple instructions. When you are interviewing a lot of candidates, you do not have time to download a different Unity version for every applicant, fight with package conflicts, and hope the project opens. If you say "use version X" and the candidate sends you a project in version Y, you are already going to have a bad time opening it. A lot of those candidates get cut right there, before anyone looks at their code.
I sent them a project in the wrong version. I wrote Queue<T> I could not explain. I then told everyone I was moving to Belgrade.
Only years later, reflecting back, I understood what I had actually done. There was no conspiracy. There was no unfair filtering. They had told me exactly what to do, and I had not done it, and I had not even noticed. That one line in the instructions was worth more signal to them than any of the code I wrote. I was busy trying to impress them with a game. They had already found out everything they needed to know.
Ten interviews
The Belgrade one was not the last, and it was not even the first. I failed about ten interviews. Most of them were the same story. I looked good on paper, I had shipped things, I had the reel. Then someone asked me a question and I went blank.
I could not explain what an interface was. I could not explain the difference between a perspective and orthographic camera. I could not explain the difference between coroutines and async. I was asked about stack vs heap once and I had never heard the words before. I did not know what a using statement did. I did not know how memory worked. I used Time.deltaTime in every project I had ever made and I thought it was just something you multiply by a speed variable. I had no idea what it actually was.
Some companies used filter questions on purpose. One question, wrong answer, call ended. I failed those in under five minutes. Most interviewers were polite. They did not hire me, and that was it. I was bitter for a while. I told myself they did not deserve me. I was watching too much self-help stuff on YouTube back then. 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.
The interviews were the best school I ever had
Every question I failed in an interview, I went home and learned properly. Not the shallow version. The real thing. Then I used that knowledge to prepare for the next interview. I was not applying to fake jobs for practice. I was applying because I needed a real job, and I knew I was not going to learn anything meaningful alone in my room watching tutorials.
I was bitter about the questions I missed. I am still bitter about some of them. I remember them years later. That is how deep the shame went. To this day, when I write a technical article, I will often stop and say, "this is a common interview question, you should learn it", because I remember the exact moment I could not answer it and the exact room I was sitting in.
This is where the self-taught path starts to show its cracks. In college, you do not get to skip the boring stuff. Someone forces you to sit through data structures, algorithms, memory, compilers. You hate it at the time, but by the end you can at least explain what a heap is. Self-taught people skip all of that. We only learn the things that feel exciting, like gameplay mechanics or shaders. We never touch the foundations. Interviews are where that gap gets exposed. Companies are not being cruel when they ask about stack vs heap. They are testing the stuff college would have forced you to learn. If you never went to college and never got interviewed, you will never know you are missing it.
I want to be honest about one thing. 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.
The interview I finally passed
The turning point came in an interview I actually passed. I was asked about pathfinding. I could tell them about Dijkstra. I could also tell them games usually use A* instead of Dijkstra, and why. They asked about garbage collection and I could walk through it. They asked about low-level vs high-level languages and I had an answer. They told me afterwards that I was the only candidate who named the exact algorithm. Every one of those answers came from an interview I had previously failed. I had carried those wounds forward and studied them until they became strengths. That was the first time I felt the years were starting to compound.
I also got one piece of feedback I will never forget. I failed a final round interview. Final round. I was close. The interviewer called me afterwards and told me, kindly, which specific question I had failed and what the right answer looked like. It was not a rejection email. It was a real conversation. I took that feedback, learned the topic, and landed the next job without much trouble. To this day I remember that person as one of the best interviewers I ever had, and I still think kind, honest feedback is the most valuable thing a senior can give a junior.
By the time I hit 5 years of experience, interviews stopped scaring me. By now, 11 years in, I often know more than the person interviewing me. I do not say that to brag. I say it because the anxiety I felt at 3 years in took another 2 years of failing and learning before it went away. Interviews taught me what tutorials could not. They taught me what was actually expected of a professional.
I should also say this, because it is the truth and it bothers me. I was lucky. 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.
Starting over, from the thing I should have learned first
After enough failed interviews and the Blender guy, I stopped blaming everyone else and started over. Not from zero exactly, I still had all my Unity skills. But I admitted the thing underneath them was missing. I needed fundamentals.
I discovered LeetCode. The first problem I tried was Two Sum. It took me a few hours. That is how bad I was. For years I had been building Unity games, and I could not solve the first problem on a website built for interview prep. Up to that point I had been doing "Unity patterns", which is really just attaching a component, calling Rigidbody.Move, and hoping things work. I had no idea how code actually worked. I had no idea how a loop walked through a list. I had no idea what a hash map was.
I did about 100 LeetCode problems. Mostly easy, some medium. After 100 the returns started to drop, which is a good sign. You have seen enough patterns that new problems feel like variations instead of new languages. I stuck with C# because I wanted the language I actually used every day to become automatic. People online say Python is easier on LeetCode. In my experience C# and C++ work just as well. I also tried Go once and never again. For years I had read posts from people claiming they solved 100 easies without looking up a single solution. I used to think they were smarter than me. Today I know they just had fundamentals their fingers could type without thinking. I was learning those fundamentals from zero.
Then I went into design patterns. I read Game Programming Patterns by Robert Nystrom, which I still recommend to every serious beginner. I also read Cracking the Coding Interview, which is the standard interview prep book and worth every page. For Unity specifically, the Infallible Code channel on YouTube taught me more than any tutorial playlist ever did. I had already used Singleton and Object Pool for years because tutorials drop those everywhere, but I never understood why. After patterns, they stopped being words I had memorized and started being tools I chose on purpose. The biggest one for me was the State Machine. Once I understood state machines, half of my debugging problems disappeared. A lot of what I used to call "weird Unity bugs" was really just me writing code without knowing what state it was in.
The terminal, Vim, and autism
Around this time I also got into the terminal. Not because I had to. Because I wanted to understand what was happening under my editor. I do not use many commands. cd, ls -la, cat, git. That is most of it. The point was never to memorize commands. The point was to learn how the file system works and how computers actually run programs. I do not let my students use graphical git clients for this reason. They rob you of the chance to learn how your operating system works. The terminal is not an aesthetic, it is a teacher.
I did make the letters in my terminal green for a while so it looked like a hacking movie. I removed it because it was actually hurting my eyes. A small word of advice, do not pull the green-letter terminal on girls. They will not think you are cool. They will think you are trying to hack their phone.
Vim came much later, maybe two years ago, after watching too much ThePrimeagen. I love it. I cannot type in a normal editor anymore. But this one is not for beginners. Do not touch Vim until you actually know how to program and you feel like you want it. Chasing Vim before fundamentals is the same trap as chasing Unity before C#. Tool first, skill second, is backwards.
This whole rebuild took about a year of serious, daily work. Years later, once the fundamentals had settled and I had real experience behind me, I went back and built Skeletons AR 2022. The original was my "I thought I was somebody" project, stitched from tutorials and forum scripts. The 2022 version was me rebuilding the same concept with everything I had learned since. State machines where they belonged. A real architecture. Code I could explain, line by line, to anyone who asked. That project is the part of my portfolio I am actually proud of, and it exists because I took the long way.
The other thing that changed, and this is the part seniors will recognize, is how I read other people's code. I used to see code as magic. Now nothing is magic. I will read Godot's source just to understand how a different engine makes the same decisions. I cannot do that with Unity because it is closed source, and that closed-source nature is one of the reasons Unity hides its fundamentals from people for so long. Today I outsource a lot of the actual typing to AI. I design, the model writes. But that only works because I can read the output and spot the nonsense. A beginner cannot do that no matter how good the model gets. Experience is still what makes AI useful. That is not changing soon.
I want to be clear about one thing. Brackeys, Code Monkey, Jason Weimann, and every creator I mentioned in this article are legitimate educators who have helped millions of people. This is not about them. Their tutorials are good. The problem was never the tutorials. The problem was me skipping the fundamentals and expecting tutorials to replace them. That is not something any creator can fix for you. That one is on us.
What I wish I had known
I still think about that interview sometimes. The Queue<T>. The Belgrade thing. The seven days I spent polishing a project I could not explain.
For a long time I thought that interview was the moment I failed. It was not. I had been failing for 3 years. I later collected the full list of mistakes I made learning Unity alone in a separate article, and the Queue<T> story is only one of them. The flip side, the habits I would build today instead of repeating those mistakes, is in How to become a better Unity C# Programmer in 2026. The interview was just the first time somebody looked at my code with me sitting next to it and asked a real question. Everything after that, the Blender guy, the ten interviews, the LeetCode, the year of rebuilding, was me catching up to what that one question had already told me.
The scary part is that today it is easier than ever to be where I was. In my time, copying code meant opening Stack Overflow and pasting a function. Today it is called vibe coding. You describe a feature, an AI writes it, you paste it in, it runs. The code is not yours. You did not choose the data structure. You did not name the variables. You cannot explain why it works. 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 worry about every beginner who is learning this way right now. The project will look great. The understanding underneath it will not exist.
Copying code is not knowing code. Nobody around me said that out loud, and I did not figure it out on my own. I figured it out because somebody asked me something simple and I could not answer. If you are reading this and the same thing is happening to you, it is not the end of anything. It is the start.
Read next
How to Actually Learn Unity in 2026 in the Age of AI
Why "Learn C# First" Is Bad Advice for Unity Beginners
C# in Unity 2026: Features Most Developers Still Don't Use
