The Coding Interview
blog.palantirtech.com
blog.palantirtech.com
I wish more companies would do this.
In the past, I've had lackluster success with the brain teaser, CS theory, and 'FizzBuzz' interviews. Plus, most motivated candidates had already mastered and memorized the 'Google interview secrets'. So, I wasn't getting the right people.
My goal is to recruit productive, engaged software engineers who care about the craft of software and who can learn things relatively well and are resourceful. I want collaborative team players, with passion for software, not necessarily geniuses.
So, I concocted an interview process that required new candidates to develop a small program using all of our current tools. I also gave them an existing, relatively poor code base to work with, and also asked them to recommend refactorings. I also gave them access to some of my current team members to ask questions.
It was a great process. But, here was the major problem: 75% of the candidates dropped out of the interview process instantly. I'm guessing that they had better opportunities with quicker yield.
It depends on the way you look at it I think. The 75% who dropped out were probably not that interested in your company/products anyway. Sure, they might have been computer programming aces, but in the end I think this is a good filter for people who are actually with you for the mission/job as well as the money.
You could mention the exercise should only take an hour, or such.
The basic FizzBuzz test is about the right level of complexity. It weeds out those people who cannot even do as simple loop while still giving real coders enough rope to work with to show their stuff.
To be honest, the more advanced concepts in programming can be mentored and corrected if the basics are in place. In my experience, once they pass a basic coding test, you are interviewing for culture, to determine if they are a junior or senior coder, and whether or not they know they are a junior coder and will therefore be open to improving.
FizzBuzz weeds out the entirely incompetent. It is then your job as the interviewer to do your best to select the best of the remainder.
Someone who barely scrapes out an imperative-style FizzBuzz might not be ideal. On the other hand, someone who can write FizzBuzz in functional and OOP would be better.
Even better would be someone who writes FizzBuzz with a poor order of growth, then explains why the order of growth sucks. That would demonstrate an understanding of algorithmic complexity.
I wonder if anyone looks for this when hiring.
How would you write an OOP implementation of FizzBuzz? I genuinely don't see how this would be done, short of something really contrived like fizz.Print(), buzz.print().
class FizzBuzzer():
def __init__(self, num):
self.mod3 = num % 3 == 0
self.mod5 = num % 5 == 0
def check(self):
s = ""
if self.mod3:
s += "Fizz"
if self.mod5:
s += "Buzz"
print s
def main():
buzzer = FizzBuzzer(n)
buzzer.check()
But, if they're just trying to get an idea of your abilities and critical thinking skills and coding style, it's really not that big of a deal.
"My brain doesn't work as well when writing by hand as when I'm typing. This doesn't have to be perfect. If you get stuck, ask for help, we'll talk through it. Think of this as a starting point for a technical conversation."
As a candidate, I would worry about my future coworkers if I were not asked to write code during the interview.
Perhaps I'm envisaging an ideal world but I'd much rather see some production code they have produced and ask questions about that. It's very easy to gauge someone's knowledge of a particular technology by just talking to them about it.
Then you find out they don't know what 'const' means, have never heard of size_t, and spend 20 lines on something that should be about three.
I wouldn't find that out otherwise. Instead, I'd find out after hiring someone, and spend six months to a year getting them run out. That sucks.
So: Everyone writes code.
Do whiteboard test really work better than giving someone an editor?
I never enjoy writing anything on a whiteboard, be it code or some kind of drawing for a meeting. I'm also plagued by lousy handwriting, and I don't draw particularly well.
One interview scenario that I did not mind, and was editor-free, was one where I was shown Powerpoint slides of code. I was asked to fix what I saw, or determine if anything was really wrong at all.
The problem with this - ignoring the open source part for a second - is that it is very hard to accurately judge someone's contributions to a project at their previous job from their verbal description alone.
Also, you run the risk of discarding candidates who had the misfortunate of working on boring projects at boring companies.
[1] http://steve-yegge.blogspot.com/2008/03/get-that-job-at-goog...
>> My career goal is to program useful stuff people use, with smart people.
I think if you continue to hold your work to this standard, you will be able to look back on your career with satisfaction.
Instead of coding on the whiteboard, have you ever tried setting up a work station / projector combination ? (I'd even consider dual projectors for a dual-head setup).
I think it's much more realistic to watch how a potential candidate actually "types" the solution. They may stub things out, then go back and fill it in, they may write one version from top to bottom, or they might continually copy and paste code around the place. There are a thousand possibles.
I think actually watching them type and interact with the IDE will give you a lot of understanding that watching them struggle to draw a coherent "}" on the whiteboard will not.
-Dan
Why I am saying this... In most cases (unless someone interviewing me for position where I will be developing "nanobots to build house on Mars"), if interviewer will ask me to write actual code on real white board.. i will pass this position no matter how big or cool or both this company is.
My memory and attention have better use then memorizing particular syntax of particular language, particular code of particular sorting algorithm, etc.
As someone hiring a developer, can't the submission of previously written code provide good insight into the type of person you're interviewing, or is there concern that the code is not really theirs?
About 1/2 the time my suggestion to write live code was shot down. I do fine on the whiteboard, just hate it.