
The Coding Interview - rs
http://blog.palantirtech.com/2011/10/03/the-coding-interview/
======
mapleoin
The best job application process I've been through was when the employer asked
for a small program to be submitted with the CV. The program had to use their
infrastructure and existing products, which gave me a quick tour of their
processes, the tools they use and the quality of their existing code base. I
assume that in turn, my code gave them a clear view of the way my code looks
in real life, the tests, the comments, the docs etc. This was followed by a
short mostly non-technical interview.

I wish more companies would do this.

~~~
ap22213
Recently, I tried something similar with my interviews.

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.

~~~
mapleoin
That's really cool.

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.

------
synnik
Maybe it is because I have been stuck working with .NET environments so much,
but they seem to be focusing on stuff that is too complicated.

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.

~~~
achompas
This is an interesting idea: why not use FizzBuzz to show off your
understanding of different paradigms?

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.

~~~
georgieporgie
_someone who can write FizzBuzz in functional and OOP would be better._

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().

~~~
achompas
It would definitely be contrived. Let's see how contrived! ;)

    
    
        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()
    

Yeah, that's really contrived. Still, you display a familiarity with
encapsulation, objects & their attributes/methods, etc.

~~~
Harkins
Sorry to nitpick, but it fails to give "FizzBuzz" for 15 and other multiples
of 3 and 5.

------
philparsons
Asking people to write code on a whiteboard in the pressure of the interview
environment doesn't seem very reflective of how they work day to day to me.
Perhaps judging them on previous projects or open source work they have
contributed to would be a better approach. If someone gave me a pen and a
whiteboard and asked me to draw code I think I would likely say thanks but no
thanks and walk out of the interview.

~~~
thaumaturgy
Yeah, I'm not sure I'd walk out -- depends on how bad I wanted it I guess --
but I would point out that I tend to write marginal code first and then go
back and make it pretty in a second (or sometimes third) go-round, later. It's
like that funny old saying, "I apologize for the length of this letter; I
didn't have time to make it shorter."

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.

~~~
sukuriant
That's more than likely what they're intending. They're coders too. They know
what sort of code can he pushed out in 5 minutes.

------
SoftwarePatent
I'm currently preparing for my first coding interviews, using a blog post
about interviewing at Google as my guide. [1] In addition to studying the
subjects in the post (algorithms, data structures, discrete math), I'm taking
the three public Stanford classes and writing an iOS app that I will put in my
github. Any advice re this approach? My career goal is to program useful stuff
people use, with smart people.

[1] [http://steve-yegge.blogspot.com/2008/03/get-that-job-at-
goog...](http://steve-yegge.blogspot.com/2008/03/get-that-job-at-google.html)

~~~
mapleoin
You should find a better career goal for yourself; _program useful stuff
people use, with smart people_ is about as generic as you can get.

~~~
llambda
Maybe the way you worded that is a little harsh: I think that's a fine goal
but when you approach an employer you might want to put that goal in the
context of the company you're interviewing with. So in effect, you want to use
your career goals as an angle by which you might sell yourself to the
prospective company.

------
grecy
Can't submit comments on the site. I wanted to submit: \----

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

------
pavelkaroukin
It depends a lot on what company actually do, but lets be honest - not so many
companies out there need some tricky algo implemented. Most stuff already
invented and you, as programmer, have to know when to use what, how it should
work together and what is approximate complexity of two or more algos, which
could be used in particular situation..

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.

------
Osiris
I'm starting to do some job hunting for a professional programming position
and I'm a bit nervous about these types of interviews. I think I have the
skills, but having been a solo programmer for a long time, I'm nervous about
people looking over my shoulder and watching while I try to think through a
problem. It's probably more a lack of experience with these types of
interviews than anything else.

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?

~~~
wnight
Part of the job is being able to do your job in a meeting, or with a client.
You don't need to be perfect, just don't freeze.

------
foolinator
I've also found that having a laptop with you with your preferred IDE ready to
go is a great idea. I suck at hand writing but type like a champ, and feel
that "whiteboard" coding is more of an exercise for those who were TAs in
college than someone who can show how to really code in person.

About 1/2 the time my suggestion to write live code was shot down. I do fine
on the whiteboard, just hate it.

