So, I just got directed to read this – thats Nick Halsteads blog who’s a developer back home in the UK.
For those of you know who know me, I’m a jobbing game developer / engineer. I’ve been doing this over 20 years now and I’ve got some pretty big games under my belt.
Now, on the subject of interviewing, I hold some Views. Mainly because I’ve done so much of it, on both sides.
Man, so much to contest here.
Tests are filters to begin the hiring process, not something you do late in the hiring process, and there certainly shouldn’t be blocks on hiring people who fail things like on site IQ tests. I’m *staggered* anywhere actually gets away with this. I can only imagine they do because certain people like to feel leet.
You can’t judge someone as a potential employee by a test. Real development is not a test environment, so the fact that they don’t do well in a test is immaterial. Thats not what they would be doing if you hired them. People equate tests to stress situations, however the two are not the same. Just because a test is a stress situation doesn’t mean that’s the kind of stress situation you run into in crunch. To judge it as though it is means you just get a bunch of good exam takers. It doesn’t mean they are going to come through in a bad situation, and it’s not really a good indicator either.
Secondly, the idea of doing the test while they are on site, or worse still, afterwards also has it’s flaws.
Tests are filters, as I said. By the time you bring some one on site you should already have found out that they posses the requisite skills to the do job. Them being on site is merely to confirm that in their presence (it is, after all, possible to ace a test by judicious use of the internet – of that more in a bit) and to see about studio fit and get an idea of what they might want.
Studio fit can’t be over emphasized. People say “well, you should be professional and then you’ll fit in” but that’s just not really reality. People are people and we all have personality types we get on with or don’t.
50% of a good team is them working together. I don’t care how smart you are, if you can’t work well with other people then you are a drain on me and everyone else around you.
You get one day with this individual, and he may be working for you for years. You want to get as good a handle on them as is possible during that day. Sticking them in a room to do an IQ test is the worst possible use of that time.
By all means throw a few general knowledge / quiz type questions at them while they are there, but wasting a couple of hours on a technical test that could have been done before hand is criminal. He could have been chatting with QA or whatever.
Now the filtering process should involve phone calls (which are far less costly than bringing someone on site to do this kind of thing) and a previously given test. A test can be faked of course, but there are methods you can employ to make that more difficult – having wordy response questions means the testee has to write the answers to these questions. He can’t just cut and paste from the internet because that’s noticeable (the change of writing style) and if he re-writes it in his words, then who cares? The act of doing so means he’s had to understand it to re-write it which is pretty much the entire point of why you want to employ him in the first place – can he do that? Putting a time limit on the test also helps.
Ulimately you want your interview process to as closely emulate real development as it can, otherwise it’s a totally artificial process and the people you get out of it will reflect that (as will the games they make).
The kinds of questions I try and ask are true dev questions- ones where I don’t always know the answers. Lead the applicant through the requirements, what might or might not be there first and then see where it goes. Make it a co-development experience rather than a grilling. That’ll give you a far better idea of what they are like as a developer than a test and rapid fire questions.
Also, don’t make people code on a white board – it’s just annoying and as much time is spent rubbing things out as it is spent writing.
Lots of devs have pet questions they like to throw at people, but most of these are bogus. I say that because most pet questions have a set answer in the mind of the dev asking the question, and the whole process becomes “Can you read my mind?”. I had this at Bungie where I was asked a question that I gave an answer to that included STL. The interviewer was most irate because what he actually wanted was a binary sort, but the question he asked wasn’t about that. I gave an answer that more than satisfied his question, but there was an essential disconnect between the question and the answer he wanted.
There are also lots of questions that are trick questions (the bumble bee question is a case in point) – either you know the trick or you don’t, and no amount of IQ is going to give you the answer in an interview situation.
And by the way, the answer “I don’t know, but I know where to look to find out” is a totally correct and acceptable answer, although most people don’t seem to understand that.
When you don’t know something as a Dev, what do you do? Research. You don’t get research in an interview situation, and so it’s unfair to expect someone to have everything at their finger tips.
I just had to comment on this because it’s this kind of thinking that leads to really bad interviews and staffing companies with people who don’t fit in no matter how smart they are.
One last thing – Nick, if you are out there? Deleting a link in your comments directing them to this blog isn’t that classy of a move. Just sayin…
- February 2015
- January 2015
- August 2014
- July 2014
- May 2014
- April 2014
- February 2013
- January 2013
- December 2012
- March 2010
- February 2010
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- January 2007
- December 2006
- May 2006
- April 2006
- March 2006
- February 2006
- January 2006