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.
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.
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.
I'd like that. I always feel a little skeptical, applying for an open position, that I'll be seen. But with a test I know it'll weed out the thousands of applicants and the company might actually be hiring on merit.
You could mention the exercise should only take an hour, or such.
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.
Not all companies have the luxury of time to train a new hire about higher levels of complexity, especially if they should have learned that stuff in school or at a previous job.
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.
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.
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().
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.
I'm curious - how can one show off with FizzBuzz? I think as an interviewer, an overly complicated answer would risk looking like an incompetent answer.
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.
Well, if somebody walked out on me I guess that would end the interview. :) I have candidates write code on a white board, but not terribly difficult problems, and I always issue this disclaimer:
"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.
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.
Perhaps judging them on previous projects or open source work they have contributed to would be a better approach.
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.
I hated writing semicolons by hand for a paper & pen coding test I did a long time ago - I spent more time than I really should've in trying make them not look like colons. I find my sense of penmanship is very difficult to overcome (God knows why - my handwriting is atrocious!)
Do whiteboard test really work better than giving someone an editor?
For me, I think having an editor in front of me gets my mind "in the mode". Heck, I can break a period of procrastination just by firing one up.
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.
How many tech companies have you interviewed with? I've never seen one, big company or tiny startup, that doesn't ask you to write code by hand in the interview.
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.
>> My career goal is to program useful stuff people use, with smart people.
I think at a high level that is a fine career goal. You want to work on interesting problems in an intellectually challenging environment (that's where smart people are), and you want your work to have meaning to society.
I think if you continue to hold your work to this standard, you will be able to look back on your career with satisfaction.
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.
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.
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.
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?
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.
I wish more companies would do this.