I’ve had the chance to interview a few people lately. It’s just getting started, my calendar includes 3 interviews this week.
There are 2 parts to the interviews I give. In the first part, I like to talk about general interest in what’s going on in our field. In the second part, I ask people to code for me.
First Part: Passion
I ask about tech news websites that the applicant is using, if any. I ask about blogs that are read. I ask about RSS feeds that are reviewed.
I also like to ask “what’s going on right now in the industry? what’s the buzz?”
Another one I’ve been using: “what’s the next programming language you want to learn?”
I’ve been wanting to ask about portfolio. If you have been programming for a few years, I’d like to think you could show me something you’ve done. If we expect artists to bring a portfolio of their work, can’t we expect the same from programmers?
Personally, I’ve got 3 webapps up and running that I’d like to show and talk about. The thing you see in my glittering eyes and my wide smile is passion. I’m looking for that in others.
Second Part: Skills
At this point of the interview, I probably already made my opinion.
But I’d like to see some code too.
At first, I thought I would ask people to code: group_by. This is something I coded myself a few times, in Ruby for fun and in Javascript for practical purposes. However, I realized that it was not something I’d like to code under pressure. I decided to water it down.
What I used for the last 2 interviews was: any or all. Let’s just say that the results were not… productive. The problem with ‘any or all’ is that you either get it or you don’t. I needed better resolution.
One of the problems is that function pointers are just not part of the repertoire of most of the programmers I know. Thank you Javaschools!
I decided to change my approach. I decided to combine bullet-in-the-brain-easy programming with elephant-in-the-room function pointer enlightenment.
Here is the coding test I came up with. I’d like to get some honest opinions. Also, feel free to use it for your own interviews.
*** If you want to have a go at the test, everything that follows could be considered a SPOILER. (Thanks Fred) ***
Now, I believe there are 3 outcomes out of the questions in this test.
- brute-force code all 3 questions (worst)
- brute-force code all 3 questions but realize that there’s something wrong (better)
- abstract away the act of summing from what is being summed up (best)
I’m going for reactions, insights and skills.
I want to believe that I don’t have to resort to FizzBuzz.
I submit my own answers. I spare you the inner private class magic that would be required in Java.
I think that will definitely tell you who understands function pointers vs who doesn’t!
I wonder if I would have come up with the correct answer myself had I not read your entire post first. I like to think I would have, but who knows? Maybe you should put the spoilers in a *SPOILER* section and render the text white-on-white. ;-)
The way the questions are asked it seems as though you just want a single function for each. I wouldn’t provide the type of answers you are looking for even if in my own code I’m always passing function pointers around using each, collect, pluck, etc…
I think a lot of it has to do with the way the questions are asked on the sheet of paper. If you asked a more general question like so:
“Your colleague needs to know the sum of x:
1) for x from 1 to 100
2) (x-2) power of 2 from 1 to 100
3) cos(x) from 1 to 100
How would you write the code?”
It would leave room for more interesting answers.
xutopia:
I am looking for a single function for each. Whatever else happens is just bonus. In that sense, the code I ask for is even easier than FizzBuzz.
I gave that question for the first time in an interview yesterday. The guy “bruce-forced” the 3 functions.
Of course, my question was “So, you basically had to write the same code 3 times, do you know of any way to make it more general?”
And since this guy was most comfortable with Java, I added: “What design pattern could help you?”
In the end, it’s not about the actual code as much as the following discussion.