“He replied that employers instruct him not to send them World of Warcraft players. He said there’s a belief that WOW player can’t give 100 per cent as their focus is elsewhere, their sleeping patterns aren’t great, etc. I mentioned that some people have written about MMOG leadership as a career positive, and he shook his head.”

After a little searching I found the original source of this quote and the proper context in which it was delivered. Although the opinion was that of a single recruiter and was merely a brief comment in a conversation, it seems to have generated a surprising amount of publicity (nearly 90k hits on the forum alone). Much of this was no doubt due to the telephone game nature of how this story was reported; in some reports it was a job interview, in others a huge employeer. The story had a life of it’s own and was reported in various incarnations, some widely inaccurate from the original. It did however touch a nerve and I was forwarded the same link several times from both gamers and none gamers.

It wasn’t so many months ago that I was reading about “the striking similarities between the skills required for online gaming and those required for real world leadership”. Jim Spohrer, Director of Services Research IBM said, “What we’ve found is that success as a business leader may depend on skills as a gamer”. Some people even went as far as to say that these games should be thought of as “a potential educational medium for complex social skills”. Others even contemplated resumes that include a line reading “level 60 tauren shaman in World of Warcraft.”

I have come across many hardcore MMO gamers who poses in-game qualities that any employer would jump at, but do these really translate into real world qualities? Are guild masters really project managers or lead developers in another guise? I’ve seen guild masters that organize every part of their weekend raid but I really wouldn’t be confident of letting them run the project schedule. Virtual world skills may help improve real world skills but I personally haven’t seen a correlation between the two. Guild masters may make great project managers but I wouldn’t personally use this status as an indication of potential ability.

Since reading the quote in the edge magazine, I’ve read more negative opinions about the impact these games have on individuals. Some anecdotal observations claim that playing these games is causing college drop-outs and led to people neglecting their studies. The results from a small poll even showed that 55% of people thought that MMO gaming affected their own school or work performance. The sample is small, but it’s still quite interesting that the very people playing the game claim it affects their own performance. Many follow up comments from the original story come to a similar conclusion; playing games makes you a less effective employee. But is that really true?

Balance and separation seem to be the dominating factors. Those gamers that I’ve really enjoyed working with were able to leave their gaming lifestyle at home, it’s something they do in an evening but it doesn’t take over their life. Those that really cause headaches think nothing of discussing group tactics and tech tree analysis during work, with the lunchtime forum reading quite easily turning into an afternoons reading. Morning naps are a common occurrence to make up for lost sleep when they were too busy the night before slaying the latest boss. But is this really any different to any other evening activity?

Everyone spends their spare time in different ways, but if that spare time activity starts affecting work on a regular basis, an employeer is completely justified to be unhappy about this. It doesn’t have to be a late night playing games, it could quite easily be a late night at the local pub or 4am coding on your own pet project. It doesn’t matter if last night you were a Death Knight, a Shaman a Warlock or just out partying, if you come to work an absolute wreck and the rest of the team have to make up for it, that’s just not on. When hiring staff, level 70s need not apply?

We recently produced quite a basic job specification with pretty standard requirements, a competitive wage with benefits and asked for several years of relevant experience. Having looked at all of the various job postings I would have thought there would be a wealth of talent looking for an opportunity like this. We were looking for around ten resumes to sift through as a starting point.

The number of available candidates and skills is a very difficult ask at the moment. There are simply not a huge number of candidates available with the required skill set. There isn’t just one problem; the number of candidates and skills are both big problems at the moment, there isn’t enough of either.

Our first thought was that wage might be an issue, so what if we were will to increase the wage offering?

Wages aren’t really the issue. It’s quite a general problem that people are unwilling to move jobs right now. The economic state is not conducive towards it. People just don’t know if the company is going to be around next month, or if they’ll be forced to cut costs. If Microsoft and Sun are having to do it, then who will be next?

But surely if there are scores of people being made redundant there should be talent available for hire.

Typically, most of the people being made redundant on the news aren’t highly skilled technical types. Some of them are but the majority are unskilled. Of those technical staff looking for work, many of them are contract staff who haven’t reach the point of really having to work yet. Some of them need to work, but many of them can “play it cool” for a while yet.

So is the industry really in crisis, or is it actually faring quite well at the moment? Are there tens of thousands of skilled developers out there struggling to find work, or just a few more than usual? I’m sure there must be a large number of skilled people who have recently lost their job, but if so where are they and why don’t they seem to be looking for work?

The List of Technical Questions

The candidate is presented with a list of technical questions that start with basic questions and slowly move towards more difficult ones. These could be about language specifics, API’s they claim to know or anything technical that is related to their potential position. Anyone with a basic knowledge of development principles stands a good chance of getting a reasonable score with the basic questions. Most people can memorise answers to the general technical questions, but does that really give you an insight into their ability?

The Example Code Test

The candidate is asked to write some general purpose code or possibly something resembling code they might be expected to work on. Anything general should be quite straight forward for the candidate, but anything that expects them to write code to specific API’s could produce undesirable results. If the candidate has claimed to have a good working knowledge of an API they have no excuse, but if they didn’t use the API yesterday, last month or ever, should that really sway your hiring decision? Is this candidate really better or worse than the one before?

A Different Way?

Joel Spolsky keeps his criteria for hiring staff quite simple; smart, and gets things done. If we approach hiring with such simple criteria; development is about solving problems and a good developer needs to excel at this regardless of their chosen language. They need a natural aptitude to understand a problem, break it down and arrive at a a solution. Presenting a candidate with technical questions or example code rarely tests those natural problem solving abilities in any great deal.

Rubik’s Research

A recent batch of company branded merchandise contained a single rubik’s cube. Over the course of a couple of months, the rubik’s cube was passed around the office, each member of the team having differing degrees of success. One team member was a rubik’s cube wizard, spinning and flicking the squares around to complete the puzzle in what seemed like seconds. This team member also happens to be exceptional at their job and has amazing problem solving skills. This team member is not a developer, but I have no doubt that if they decided to turn their hand to it, they would be an exceptionally productive one.

Some of the other team members just couldn’t break the problem down and struggled to find the patterns that advanced the puzzle. Even after training from the rubik’s cube wizard and written instructions on how to solve the puzzle, some team members still couldn’t progress from the jumbled mess. Some of these individuals could be classified as average (not exceptional, but not bad) developers and this puzzle really seemed to highlight the distinction.

The rubik’s cube is only one example of a problem solving challenge (some would argue one of the hardest), but even when supplied with the answers it still provides a good challenge. Fan’s of the classic game show Krypton Factor might already have an idea of the kind of challenges a candidate could undertake; from the impossible to the absurd. The idea here is simply that by augmenting a normal interview with a puzzle element, it may add some insight into the candidates puzzle solving approach.

Conclusion

The difference between average, good and excellent developers can often be traced back to their aptitude to solve basic problems. If team members are given the solution to problems but still can’t progress further, does this give us an insight into their general analytical approach? Problem solving skills can be taught to some degree, but does the rest just come naturally, is there only so much you can teach? Typical interviews often only touch on this ability and don’t look at it from a pure approach.

Puzzles like the rubik’s cube are a great way to test an individuals problem solving abilities, potentially putting them on a level playing field. These kind of puzzles force individuals to look for patterns, understand the process and apply it; after all isn’t that what development is all about? Next time you have a candidate in for an interview, should you include the the rubik’s approach?

Note: I have tried to find more information on this subject but as yet I’ve found very little real research. I’d be interested to hear about the links between problem solving and programming ability.

Over the past six months the IT job market seems have all but disappeared (in some regions). Projects have been postponed, contracts have dried up within a hundred mile radius and the number of advertised permanent roles has drastically reduced. This isn’t really a surprise given the current economic climate, but for companies who are actually still looking to hire, the problem seems strangely just as familiar.

Many of the candidates currently looking for work simply do not have the skills required and the good developers seem to be holding on tight and riding out the recession. The current raft of resumes are frequently from contract developers, most of these developers are quite honest about their reason for seeking a permanent role, they simply can not find contract work. These developers aren’t typically looking for a permanent role in the longer term however, so should the market conditions improve, hiring a new developer might be a problem all over again.

Joel Spolsky said that the “best people in every field, are quite simply never on the market” and during a recession that seems even more true. With the recession forecast to continue well into 2009, it looks like the good developers are going to stay in their current role and hiring will continue to be a problem. Which leaves the question, the right developer, or the developer right now?

Let me just start by saying, if you’ve got this far you really aren’t one of the people I’m talking about! Hopefully you’ll see this as a good thing .

A previous project I worked on was mainly composed of short-term contract staff. The project saw large staff turnover and the code quality was generally quite poor. Many of the developers simply weren’t interested in the project and why should they be? Team members that don’t have to take long term ownership of a project don’t really have to worry about it’s quality or longevity. They can stumble through a project putting in the minimum amount of effort required to get the job done. They can move onto a new project and leave behind all the problems for someone else. When working with transient staff, you just have to be pragmatic about this, it’s just life. Some of these staff will be true professionals and give a project their all, others won’t.

Now I know this sounds like an obvious thing to say, but when putting a team together, you need to hire developers who actually take an interest in what they do! Many people involved in the hiring of staff really don’t understand this, and instead focus on finding someone who claims to be buzzword compliant. Having the right skills is an obvious requirement, but this isn’t the only consideration that needs to be made. A large percentage of developers out there, just aren’t interested in the project they are working on and more importantly they aren’t interested in software development in general. The more developers I talk to and the more horror stories I hear from them, the more I’m convinced that these people are on the rise.

Developers that aren’t interested in what they do, don’t invest in themselves and don’t strive to improve not only their skills, but also those of their team mates. They don’t take pride in the code they develop, and a real danger if you work under a developer like this is that you will stop taking pride in yours as well. They will never read technology blogs or articles, they will never be found viewing DZone, TSS, infoQ and they will never pick up a technology book. They have no interest in development outside the hours of 9am-5pm and they probably never will. They are basically happy treading water, just getting by.

They are probably perfectly nice people and outside of work you might have plenty of things in common with them. In a workplace however, teams incorporating individuals like this are always fighting an uphill battle. The knowledge transfer will always be a one-way process. Opinions in important decisions will seem like a diversion from everything else they could be doing. The most reaction you’ll ever get in a discussion is a nod of their head or a shrug of their shoulders. In the past I’ve found this can actually be somewhat infectious and it gradually starts to have a negative effect on the entire team.

You’ve basically got the worst kind of code monkey. One that doesn’t really know what they are doing, doesn’t understand what they should be doing, doesn’t care that this is the case and just isn’t interested!

Now if you are a code monkey who’s happy hacking away for eight hours a day, you aren’t interested in what you do and you really don’t want to learn, that’s absolutely fine and good luck to you! In my experience however, if you want to build a team that’s going to produce a product of quality and longevity, you need to steer well clear of these people! These people will drain your other team members, slow you down and will generally cost you lots of money!

You’ll find these people everywhere. They’ll always be too busy to help, but they won’t be shy in asking other people to help them. They won’t want to develop things the same way everyone else does and instead they’ll develop their own style. They will never want to get their hands dirty and instead want to do the cool R&D jobs. When everyone is too busy to help, instead of rolling up their sleeves they’ll turn to the wealth of free labour on the Internet forums. The majority of posts on forums are from hard working developers, but you’ll also spot the other type as well.

So as a cautionary tale, if you have employees who fit this profile, do a quick search on the Internet for package and class names that match your project. You might find nothing, on the other hand you might find the original author of your code on an Internet forum. Why not contact them and offer them a job, you might as well if they are writing code for you anyway.

If someone really isn’t working out in the team, you need to do something about it. The longer this goes on, the greater the negative impact will be on the team. This can very quickly go from one problem to several. If there is a hint of promise at all in this developer (and as an eternal optimist I’d like to believe there always is), work with them to try and understand what the problems are.

Get them involved in the team: find something they are good at or interested in and try and develop this talent. Encourage them to go off and find out more about this and report this back to the team, make them feel important and make them the subject area expert. You need to do everything you can to make these people integrated and motivated. If nothing interests or motivates your developer you’re in trouble. If it doesn’t work out, in many cases it’s better for these people to do nothing at all, such is their negative impact on team performance. At the end of the day, do you really need people like this in your team?

When you are looking to hire new team members, you need more than just buzzwords. Go for the developer that shows real enthusiasm and interest in what they do. Go for the developer that’s contributed to open source software or forums to help other people out. Go for the developer who is willing to admit they don’t know the answer to your question, but they do know how to find it. Go for the developer that asks questions and has opinions on things that matter. Go for the developer who is excited that you have a library of books for them to read. These are the people you can work with, you can encourage and you can help to become better developers. These are the people that will be an asset to your team and will help you become a better developer as well. One developer who’s passionate and highly motivated, is worth so much more than a bunch that aren’t!

Above all else, avoid the contradiction of the developer who isn’t interested in development.