Interview Panic!

I had a brief (less than 30 minute) phone interview with one of my all-time favorite companies today, Blizzard. At first, I thought it might even just be a cruel April Fool's joke, but honestly, that might have been better...

Considering that I was interviewing for a Quest Design Internship on World of Warcraft, which I haven't really played consistently for quite some time now (stopped around when I started DigiPen), I was absolutely terrified. I spent a few days prior to the interview running through quests on my Death Knight and even starting a brand new character, simply to help refamiliarize myself with the various questing mechanics, narrative elements, paths, etc., etc.

I even had a whopping two-hour skype call with a good buddy of mine to just talk about WoW, so that I could hopefully get more details on things I might be missing from Cataclysm and Mists of Pandaria. I wasn't exactly sure what else I needed to look for while questing and what sort of big changes were made while I was away,

Throughout this whole process, I made sure to take tons and tons of notes. Notes which I found were essentially useless when it came to the actual interview. I managed to refer to a couple of the points that I wrote down, but honestly they weren't nearly as helpful as I had hoped. It kind of felt like I went through a meat grinder a couple of times and that's not an understatement!

The guys that interviewed me grilled me for answers about a number of areas in which I felt WoW could be improved, as well as what exactly I would do to improve these particular areas. Everything ranging from my least favorite zone for questing, spawns which could be optimized, raid encounters that could be more accessible, and even how I would go about creating my own quest hub and how it might work.

Not only was I woefully underprepared to answer these questions, but how could I even begin to tackle them without understanding the full scope of issues that the development team faces when implementing content in WoW? Let's not even mention how arrogant and wrong it feels to tell someone their game is broken and they should do X,Y, and Z things to fix it. Being limited to a mere couple of minutes to try to answer each problem certainly didn't make things any easier. I felt as if I was perpetually grasping at straws just to come up with something decent. Not an awesome feeling to say the least.

I'm pretty sure that I'm not a terrible designer and I know that I still have a ton to learn, but I'll be damned if that entire process didn't make me feel extremely lacking and just a tad bit demoralized. When it comes to design, I've always been a firm believer in, "show, not tell." If I think something is broken or wrong and I believe that I can offer a better solution, I have to get my hands into the problem, figure out how it can be solved and furthermore, what else I could possibly break in the process.

If I need to prove a design to anyone (myself included), I can just build it and show it off. That's always been the best way to gather feedback, to figure out what still needs work and how things can be fixed. Simply talking about an idea or solution never seems to come across correctly and honestly, if I can't build it, it's probably not worth talking about yet anyway.

In any case, whatever the outcome, it was an awesome learning experience. I think that I have a much better idea of what to expect next time I encounter an interview like that. No amount of research or homework can ever fully prepare you. While practice certainly makes perfect, hopefully I won't have to potentially fail a ton of interviews just to get that practice in! Hell, I've got to admit that even getting an interview in the first place with a company like Blizzard feels like a really huge accomplishment, so with that I can (hopefully) end this post on a positive note!

I swear, one day I am going to have to make a game about the insanity that is actually attempting to get a job in the game industry. Surely, this post will hold me to eventually getting around to it.

Adventures in Programming, Ep. 1

def takingBreaks(self);

{

Every time I take any sort of extended break from writing code, I find that the break serves as a sort of double-edged sword. On one hand, it feels great to recharge after working long hours in front of a computer for months on end. On the other, getting back into the swing things can sometimes feel overwhelmingly difficult. When sitting down to start work on a new project, I sometimes feel as if I am competing in a staring contest with a blank screen. The monitors always wins.

While I don't necessarily identify myself as a "Programmer," I do think proficiency in coding is an important aspect of being a good game designer. I work entirely with scripting languages and pre-built game engines, so you won't see me writing engine components or advanced AI. However, the more time I spend writing logic, systems, mechanics, etc., the better I get at understanding the underlying principles behind programming (and it's proper and efficient use as a  game development tool).

Because my brain doesn't necessarily operate in code on a daily basis, when I sit down to write stuff, I have to focus extra hard in order to reach optimal productivity. This is fine during a typical semester, but what happens when I have a Winter break, or worse - Summer and how do I rebound from it?

workResume();

}

def workResume(self);

{

In all honesty, I am still trying to figure this part out. If I sit down in front of an empty project (Unity, ZeroEngine, etc.), I almost immediately feel lost and overwhelmed. Where do I start, what do I need, how do I write it, what are my relationships? With game programming, I have a very tough time thinking linearly or working in a single direction towards an undefined destination. This is by far, simultaneously the most stressful and depressing part of trying to get to work.

If I am working with an existing project, whether it's mine or somebody else's, sometimes it helps to look at basic scripts and components. If I can make sense of a simple component, like LevelBehavior or TurnManager, I can usually work my around the rest of the game and figure out where I left off or what needs to be worked on. Sometimes it's as simple as asking someone else for an explanation of what's happening, or in the even that it's solely my project, just reading over the code comments. I ALWAYS try to leave verbose comments for myself, even if the code is already pretty readable.

betterCoding();

}

def betterCoding(self);

{

Out of necessity, I have developed better coding habits the more I work. I've gone from nonsensical variable names and magic numbers everywhere to practically creating everything ahead of time in the top of my classes. Properties, formulas, colors, sounds, strings, etc., anything that I am going to want to refer to inside of a function. I also try to write all of my code in as much plain language as possible. For example, "currentHP = currentHP - (incDamage - damageResist)"

I've also started moving away from cramming as much stuff as possible into the Update on a component, and for that matter - making an effort to separate my functionality into as many reusable components as possible. Obviously a single component with 10-20 lines of code is way easier to write, modify, and decipher than digging through a single script with a few hundred lines of code that are doing 10-20 different things all at once.

nextSteps();

}

def nextSteps(self);

{

Moving to a more message / event driven approach is the next step in improving my programming ability, but this will also come at a price. With less obvious relationships, it won't be as simple going through code and components and determining their functionality. I still have some more hurdles to overcome before I can try to break away from the comfort of the Update loop. Until then, becoming more familiar with the languages that I am using and their nuances should hopefully prove immensely beneficial in reducing the amount of time I spend trying to get back into the swing of things.

}