Some of my early interviews were laughably bad. I remember that on pretty much all of them I was answering their questions like a game show. "Is it answer B? I'm pretty sure it might be answer B." Looking back on it, it's probably a big part of why I had trouble getting hired at first. I was reading books at the time, which was good. But they were more beginner level books. I tried reading some advanced books but I just didn't understand them at all.
Finally, I got a job. I think that's really what made a difference more than anything. I got a job that helped me get a second job and a couple years of actual job experience. Once I had the job experience, not only did the stuff in the beginner books start making sense, but after a couple years the stuff in the advanced books started making sense.
With a couple years of experience, a whole lot of reading in several advanced books, and a fair amount of experience doing job interviews, I got where I can do a job interview pretty well. I know what kinds of questions they're going to ask from having been through so many job interviews (and messing up quite a few of them in the beginning). I know the answers to their questions out of a combination of actually having done the job and having read the advanced books on the subject.
Now that I have several years of experience and a little bit of insider knowledge, I can pretty much ace an interview. Even then, I know that I haven't had to do an interview in a couple of years and I need to go read probably a thousand pages or so of reading out of the advanced books to not only review but catch up on all the latest innovations in the industry. I know without some serious reading I would be ill prepared for my next interview.
What I do now is working on big corporate servers where it's difficult to setup the same situation at home. For something like game programming, you have a huge advantage because you can practice the skill and get better at it at home. Where as, if you're working with software that runs primarily on corporate networks and $60,000 servers it's much more difficult to set that up at home and practice. So, all you can do is read, pretty much.
If I were trying to get a job as a programmer, especially a game programmer, I would not only be reading every book on the subject that I could get my hands on, I would also be writing code every week putting what I was learning to use and practicing.
And I think ultimately the key to ace-ing the interview is wowing them with how much you know about the subject. And that comes from a combination of experience (which you can get at home when we're talking about game programming - less so with a lot of business stuff) and a whole lot of reading well into the advanced level.
In the beginning, you're going to have to accept that you're young and fresh out of school. It's going to be somewhere between difficult and impossible for you to have any experience or knowledge. The good news is that's somewhat to be expected. The bad news is it's a brutal job market and people are less likely than ever to hire someone with no experience.
But again, with programming (especially game programming), you can get experience at home.
If you were interviewing for me for a business programming job, and I knew you were straight out of college, I would expect that you don't know much. That might not lower the expectation I have for the requirements of the job though. First of all, if I'm considering someone straight out of college, I'm almost certainly trying to fill a junior position. If it's mid-level to advanced, I'm probably not even going to look at a resume or do an interview with someone straight out of college. For the advanced position, I expect at least 5 years of experience or more anyway.
First, I would ask you every difficult question I could think of that allows me to get a feeling for how much you know about the things that are important in the job.
One of the questions I was asked on an early programming job interview was something along the lines of "How many bytes is a float datatype?" At the time, fresh out of my first programming class, I thought that was a stupid, off the wall, crazy question. Now with my experience it's the exact sort of question I would ask. The reason is that the size of datatypes can make the difference between the system running like a Ferrari or the systems locked up and not running at all. If you chose a datatype that's 4 bytes when you could have chosen a datatype that's 2 bytes in size you've wasted 2 bytes. To the beginner, that's a laughable amount of memory. To someone experienced, I know that when that value in that datatype is repeated 2 billion times it becomes 4 Gigabytes of memory. And when you waste 4 GB of memory, that 4 GB can make the difference between the computer taking 10 seconds to do the job and 10 hours to do the job depending on the specs of the system it's running on. It means not only 4 GB of wasted disk space (which is the way people typically think of it) but it can also mean 4 GB of wasted memory (which is much more critical) and a massive amount of extra time reading in a wasted 4 GB off disk that didn't need to happen at all and it can also mean 4 GB of wasted bandwidth on the network, etc.
I once helped someone at work with a report that was taking 10 hours to run. I saw that he was using a 16 byte datatype when he should have been using an 8 byte datatype. It's an 8 byte savings. They had made this mistake all over the company on numerous systems. This was just one place where the mistake had been made and I told him he needed to change it. He did and the report immediately started running in 2 hours instead of 10. That was because the mistake was repeat over many billions of rows of data. That was a 5 fold improvment from one super simple change because it was correcting a mistake that was causing a problem. Even in his code there were likely additional places where similar mistakes had been made, and I know for a fact that the exact same mistake had been made all over the company. The beginner sees a savings of 8 bytes there. Someone with experience knows that those 8 bytes are repeated billions of times and that those 8 bytes cost 8 hours of wasted time on the server.
This is stuff they don't usually teach in school. So, you come out of school totally oblivious to how important this is most of the time. Then someone asks it in a job interview and it seems unimportant and maybe a bit ridiculous.
But it's the exact sort of question I would ask to see whether you understand the problems that can be caused by wasting memory or not. I'm really asking, "Do you understand the concequences of choosing the wrong datatype?" But I wouldn't be that forward with the question. I would bury it in a question more along the lines of "How many bytes is a float datatype?" If you know the answer, it indicates to me that you are aware there's a potential problem there and you have spent time in the past avoiding the problem, which is why you know the answer off the top of your head. If you don't know the answer, you probably are not even aware of a potentially serious problem you could be creating by constantly choosing datatypes that waste memory. (And for C++ programming the size of the datatype can have other concequences. For example it might be important for something like figuring out heap fragmentation problems.)
Anyway, I would ask a lot of probing questions like that to guage how knowledgable you are and whether you're going to make a lot of rookie mistakes that are going to cause headaches for me or whether you're going to be someone so knowledgable that I will soon be able to trust you to work unsupervised.
For a junior position, some rookie mistakes are kind of to be expected I think. You should expect a rookie to act like a rookie. But you're still going to try and get the candidate for the job that's going to perform the best.
So, if I were wanting a job as a game programmer. I would probably start by reading every book on the subject I could get my hands on, especially the ones regarding programming. And I would practice like crazy, which means writing game after game after game. That doesn't mean writing GTAV or Madden 2013 or Call of Duty 843. It means writing simple programs that are so simple that they stretch the definition of "game", but that involve a new programming concept that I didn't know about before. I would constantly look and say "Ok. What do I not know how to do?" and then I would write a program that does that. Maybe I don't know how to move a character around on the screen. So, I write a program that does that until I know how to do it. Then maybe I don't know how to play background music. So, I write a program that does that. Then maybe I don't know how to get the computer to recognize when a bullet object collides with an enemy. So, I write a program that does that. But, maybe I don't have a clue how to make objects collide like that. So, I google it. I read tutorials on the Internet. I go buy three books that cover the subject and read them. Whatever it takes, I figure out how to make the bullet collide with the enemy and trigger the appropriate reaction when it happens.
If you're constantly learning new aspects of game programming every week, you're growing and getting closer to your goal. At first that won't be all that impressive, but after you've done that week after week after week for a couple of years, you're going to know a lot about game programming. Eventually, you'll be reading the advanced books and wowing everyone with how much you know. And that's the sort of thing that's likely to land you a job.
So, bottom line is read read read and then do do do. There's no substitue for time spent writing code. But be careful that you don't spend your time writing stuff you already know how to do. If you're just writing programs that you already knew how to write, you aren't learning and you aren't growing. You're at best getting better at what you're already good at. So, every week you need to be challenging yourself and forcing yourself to learn something that you have no idea how to do. A lot of times there will be no one who can teach you what you need to know available. I mean, you can ask around on forums and whatnot, but once you get to something that starts approaching an advanced level, you will often find that your questions on the forum aren't finding answers. You have to just go out there and do what it takes to find the answers on your own.
I think I've asked about 4 or 5 questions on this forum in the half year I've been here. I think only 1 of them got an answer. But just because I posted the question on the forum didn't mean that I didn't keep pouring through books and scouring the Internet for the answer. And generally, I have the answer to my own question within about 24 hours. And if you go back and look at my threads, you'll see I'm usually the one answering my own questions because within 24 hours I know the answer and no one has responded to the question during that time. There are some very knowledgable people here, but that doesn't mean they're always around to answer every question you have. Or it just may not be a question within their area of expertise.
Anyway, read read read and then get out there and write code. And make sure the code you're writing involves stuff you've never done before and don't know how to do. Then go do whatever it takes to figure out how to do it. Keep that up for a few years and you'll be a force to be reconed with. Keep it up long enough and you'll be reading the advanced books and wowing them in the interviews.
This post has been edited by BBeck: 14 September 2012 - 06:14 AM