I love hiring people straight out of school. There is so much good energy, enthusiasm, and pure fun they can bring to a development team. Also, working in educational serious games, I appreciate their closeness to the educational system, having just been through it themselves.

Since we are aiming squarely to shift the definition and practice of public education in the US, recent graduates usually have plenty of ideas and angst to direct right back at the system that produced them, in a productive way through the medium they love and understand.

However, there are problems associated with bringing these fresh faces into an organization. There are so many who want in, how do you choose? How can you tell if they are grown up? How good are their skills, really? Can they go the distance? How long will they stick around?

Some of these are unanswerable, for experienced veterans and greenhorns alike. Others, you can get a reasonably good feeling for. Certainly, start by looking at the skills and narrow it down from there. It's not necessary to limit yourself to the superstar talent, but it probably won't hurt to weed out the bottom feeders.

Definitely get input from your existing team on this! Most producers can evaluate a candidate's skills only to a certain point, because we usually come from one of the core development disciplines like art or programming, or from project management / business administration.

If from a discipline like art, you don't have the knowledge to dig deep into a candidate's technical prowess – maybe a little, but not enough. If you are from a business background, you may well think that you do understand art and coding, but resist this self flattery.

Knowing what you like does not mean you understand art, and being logical doesn't mean you could be a programmer. So, let your experts evaluate the skills and throw your opinions into the mix for consideration.

Assuming you have a pool of skilled potential hires, then what next? I put a high value on finding a good fit with the team, personality-wise. After all, there will be some late nights, tough decisions, and fervent discussions – best to be compatible, right? I tell our leadership team to ask themselves three key questions about the candidate, beyond skill level:

Are they bright? Are they honest? Are they hard-working?

Let's face it, you don't have to be bright to make it through school. Hard-working? Probably. But we wouldn't be trying to change education if it always worked well. Honesty is tougher to gauge, but you can get a lot of information from body language, eye contact, and by comparing experiences with other people on your team who also conducted interviews with a given candidate.

Beyond this, it's hard to predict much about anybody you haven't known for awhile, and even these basic evaluations are fault prone. I think if you can get a good year or two from a hire, that's a fair deal.

Many grads are looking to get some experience under their belt and go work for a big name company. As long as they are honest about their intentions, I can help them do that. Hopefully, the benefits of being in an intimate, meaningful, fun development environment will keep them around, but it's not for everybody.

So there you have it, my patented (not) approach to hiring great team members straight out of school. But, surely there must be some downside?

In truth, there are things I wish every graduate knew. Some seasoning for all this delicious raw talent, if you will. I KNOW some of these things are taught at game schools, if not necessarily in “normal” fine arts and computer science programs, but there seems to be a universal misunderstanding of certain development truths from our freshest and finest young minds:

• Don't take it personally: your work was critiqued in school by your peers and teachers, don't expect that to end... ever. Care enough to make it good, but stay detached enough to make it better.

• Ideas are cheap: seriously, they aren't that precious, you should always have more ready to go. In fact if you ever end up out of ideas, you're done. I got a compliment once from a manager that stuck with me, he said, “most people have one good idea out of four, you hit more like 50%.” Gee, I thought they were ALL brilliant – good thing I had some stashed away. In retrospect, I think he was just buttering me up for a crappy assignment, but it was pithy nonetheless.

• Be a Finisher: this is the corollary to “ideas are cheap.” The only thing that counts is what you actually get done, not what you dream up. How many of us have cried out “I thought of that first!” but never did anything about it? One finished project, however imperfect, is worth an infinite number of good ideas.

• ITERATE, ITERATE, ITERATE: my Dad taught me that great writers don't write, they re-write. He was write. In game development, it's true for all of us. I have a hard time understanding the resentment people feel when they have to scrub back over work. You got paid to do it once, and you're getting paid to do it again; what's the problem? We live on user feedback, test-and-adjust cycles, agile methodology, and iteration. If you think you know all the development answers when you head into a project, you've probably never seen one through to it's inevitably messy completion.

So there you have it: Fresh Meat & Old Spice, yummm. Someday when you are as tough, gamey, and altogether unsavory as myself, maybe things will be different. Until then, I'd love to hear your comments, feedback, and cheap ideas!