« Vertical Slice vs. Horizontal Layer | Main | Today's blog is brought to you by... »

May 06, 2009


Kevin Waddell

"If we fail we all fail together, if we succeed we all succeed together."
Great team philosophy :)

Ken Noland

Sorry for the long reply, but being on the other side of the table(meaning looking for a job as opposed to hiring) I had a few thoughts I wanted to dump out.

When choosing an unknown candidate, that is someone who is not in the circle of friends you already know, its hard to get an idea for who they are and what they are like, both on a professional level and on a personal level. I've been on both sides of the table on this(most recently the person applying for the job) and I've got some gripes when it comes to the interview process.

The interview questions that I hate are the standard programming tests where they ask you to reverse a string, or to convert an integer to a string... how many of these tests were just "borrowed" from other studios? The answers are stupidly simple, and I understand this weeds out the jr. level guys, but after a few years experience, do you really have to rehash programming 101?

Also, I hate tests where they expect you to write complex functions on a piece of paper, as opposed to having the development studio right in front of you. It doesn't show the other person anything other then you know some basic syntax. I do make a distinction between writing on a piece of paper versus whiteboarding(see: how to torture candidates). I don't mind whiteboarding(I know, I'm strange) simply because I've been on the other side of the table and it really does show how the person thinks and if they can pick things up quickly, and explain complex thoughts to the team. That's important when choosing a candidate, and I realize that when I'm in front of a team and I'm trying to show them how awesome I am. :)

Well, that's all the thoughts I have so far. I'm no longer on the job hunt, but now just sitting and waiting for a visa to come through which should happen any day. I can't wait to get back to work!

Cheers guys!


I like the part about "how many cycles a cache miss may burn" when you should be more concerned about how many cycles you burn when flushing pipelines, and how many cycles before you start getting meaningful operations happening again.


Of course you need to be concerned about more than just the cache, it's only one question. The idea is to make sure that the candidate understands the idea that the computer isn't just a black box and that how you program it can have a huge effect on performance. There are plenty of different kinds of performance hazards and they tend to vary pretty drastically depending on the architecture you are on. For example TLB misses, branch mispredicts and any other kind of funky penalties a particular machine has.


From interviewing heavily for my group I have found there are two sorts of candidates I run across (I'm sure many will flame me on this), those who life revolves around coding and can whip out the programming 101 answers without hesitation, and those who may not know all the syntax 100% but understand the computer as a whole from top to bottom. I prefer to recommend the latter of the two cases because while they may not know c++ or whatever language/technology is being used for the project they understand the platform in which the project is being executed. I can always find domain specific experts on c++ or directx :).

Yes... sometimes I run across candidates that fall in both categories but it is pretty rare. I'll also make sure to add in some cache related questions... lol :).

Good luck guys.

The comments to this entry are closed.