#1: Definitely agree, I'm surprised I don't hear this more often.
#2: ...Make him code using the same tools he would use in the position he is applying for....
What sort of tools is he referring to? I've always been given free reign on my work box, and I put what I want on it. It has to be interoperable, of course.
#3: Good idea, but why leave and come back? Why not just have them talk you through it? I much prefer interactive interviews.
#4: Make sure their personal website doesn't have a link to their Google Apps verification page.
It has to be pretty basic, as you obviously can't give him all your production frameworks and libraries to work with.
A reasonably competent program will be able to create reasonable code without the perfect environment. You probably don't need a full IDE and heavily customized desktop with test and development staging grounds and SCM just to write fizzbuzz.
Depends on your environment. I'm often asked if I'm familiar with Joomla | Wordpress | <insert PHP framework here>.
For a lot companies, their entire infrastructure is a stack open source software and I don't think it's unreasonable to ask if someone is fluent in, say, LAMP.
I've always thought the opposite, which is estimation is fuzzier than design. I mean, who here hasn't been off on an estimate in the last month or so? Developers are notorious for making bad estimates. See http://www.codinghorror.com/blog/archives/001284.html.
You could let a candidate be fuzzy with estimation, but it's much better to dig in. If they say something will take 40 hours, ask why. The "why" answers are going to tell you a lot about how they design, code, and test, and those answers are going to come under pressure (you want the smallest reasonable time, and they know it, but you also want to detect BS).
Also, I think design skills are less valuable than estimation skills. If you can estimate reliably, you can design. The reverse isn't true.
Potential interviewers please note that leaving the candidate in a conference room with blank paper and pencil potentially filters excellent developers who are just not used to literally writing code on paper.
We used to call the code writing section of the interview a typing test. You could literally tell if the person was going to make it by listening to them type. Someone who is comfortable writing code types confidently and with long bursts. We saw plenty of applicants who talked a big game, but clearly couldn't put together even the simplest program without resorting to cut and paste.
I found it hard to believe also, but it happened plenty. I think it's more common once you get outside of silicon valley startups. For the startups I worked at, we were almost always able to hire from within the community and most people we interviewed already had public demonstrations of code. They weren't all perfect candidates, but they could at least write fizzbuzz.
When I took the interview for my current place the first question I was asked is "what is the difference between the public and private keywords". After I responded with the obvious answer the interviewer sighed with relief and told me I was the first candidate that day (out of 5) that managed to answer the question correctly.
Some interesting and good ideas. However, I don't think there is a recipe for finding good software engineers. If you always use the same method you're going to end up with a team of people with the same strengths. Know your teams strengths and weaknesses and find candidates that balance things out.
I think this is very important to take into consideration. I've heard a lot of stories about like-hiring-like and ending up with an imbalanced team. Part of that is the interview process, part of it is the interviewers.
Good interviewers should be able to recognize strengths in the candidate that they lack.
I might sound a bit hypersensitive here, but couldn't the author easily avoid using "he" and "him" when referring to potential candidates for software programming positions?
Except the interviewee is not plural. We lack a singular gender-neutral pronoun in English that it is acceptable to apply to people, and appropriating "they" doesn't seem like the right fix.
Personally, I vote we either appropriate "he" to be gender neutral or realize that stereotypes influence language more than language influences stereotypes.
I prefer to leave them alone in a room with only pencil and paper. I want to see every piece of paper when I return, including diagrams, notes, and most of all, the entire audit trail of what they did (cross outs, revisions, etc.) I don't care how it looks or how well it compiles or runs. What I really care about is the thought process they went through. Pencil and paper shows me that much better.
Am I the only person who gets insane cramp when having to write a lot on paper? Unless i've only got to write one short function i'm gonna be screwed up by your test.
That's exactly what I want to see. I don't care how well you type or how well you navigate an IDE. I care how well you think and approach an unstructured problem under pressure in an unfamiliar environment.
(FWIW, I would never give a problem whose solution would require more than 30 to 50 lines of code. Lots of people would put in one line for the function and then explain the function to me later. No one has ever complained about cramping. You're the first.)
While I can't really argue with the points made (though perhaps the exhaustiveness of the list is debatable), the quality of the English significantly diminishes my opinion of the article.
Incorrect use of or failure to use indefinite articles; run on sentences or comma splicing (e.g. in point #3); subject-verb agreement...
I might have overlooked these things in another context, but the article is trying to present tips on "how to judge how good a candidate is", and even talks about communication skills.
These are good. One of my favorite questions is "what have you done in the past when you had conflicting requirements?"
If you say it never happened and have more than a year or two of experience, I'll be very surprised.
In our interviewing process we divide up the type of questions to ask the applicant with some overlap. So one guy will ask mostly process-oriented questions (what kind of unit testing do you do), another will ask CS/programming related questions (what are common problems in multithreaded apps and what are some solutions), and another will ask team-oriented and "soft-skills" stuff like the one I mentioned above.
It gives us a more rounded view of the candidate than whether or not he can code.
My problem with the first point - Make them Design Something - is that design is a lot harder to grade than the second two. It's easy to see if someone can write fizzbuzz, or find the bug, but it's significantly harder to grade a design.
Good design operates in the face of real world constraints, unlike typical interview questsions (see the article on Apple design about Real Artists Ship).
As an interview question, I used to ask people to design the DB schema for Netflix. Almost everyone could get something that would kind-of sort-of work. Of course there was a gradient of bad to good answers, but a passing or better grade on the question did not help predict whether the candidate would get an offer. Asking FizzBuzz was a better predictor of whether they would pass the interview process.
33 comments
[ 3.5 ms ] story [ 84.3 ms ] thread#2: ...Make him code using the same tools he would use in the position he is applying for....
What sort of tools is he referring to? I've always been given free reign on my work box, and I put what I want on it. It has to be interoperable, of course.
#3: Good idea, but why leave and come back? Why not just have them talk you through it? I much prefer interactive interviews.
#4: Make sure their personal website doesn't have a link to their Google Apps verification page.
http://www.makinggoodsoftware.com/google50f905a7cdbdd588html...
I assumed he meant languages, frameworks and other things in a project that can't be swapped out as easily as, say, text editors.
A reasonably competent program will be able to create reasonable code without the perfect environment. You probably don't need a full IDE and heavily customized desktop with test and development staging grounds and SCM just to write fizzbuzz.
For a lot companies, their entire infrastructure is a stack open source software and I don't think it's unreasonable to ask if someone is fluent in, say, LAMP.
Also, I think design skills are less valuable than estimation skills. If you can estimate reliably, you can design. The reverse isn't true.
http://lesswrong.com/lw/jg/planning_fallacy/
Potential interviewers please note that leaving the candidate in a conference room with blank paper and pencil potentially filters excellent developers who are just not used to literally writing code on paper.
Be VERY afraid. :D
Good interviewers should be able to recognize strengths in the candidate that they lack.
Personally, I vote we either appropriate "he" to be gender neutral or realize that stereotypes influence language more than language influences stereotypes.
Where the gender is not known, the correct pronoun is "he." A spokesman is a he; a spokeswoman is a she; a spokesperson is a he.
I prefer to leave them alone in a room with only pencil and paper. I want to see every piece of paper when I return, including diagrams, notes, and most of all, the entire audit trail of what they did (cross outs, revisions, etc.) I don't care how it looks or how well it compiles or runs. What I really care about is the thought process they went through. Pencil and paper shows me that much better.
That's exactly what I want to see. I don't care how well you type or how well you navigate an IDE. I care how well you think and approach an unstructured problem under pressure in an unfamiliar environment.
(FWIW, I would never give a problem whose solution would require more than 30 to 50 lines of code. Lots of people would put in one line for the function and then explain the function to me later. No one has ever complained about cramping. You're the first.)
Incorrect use of or failure to use indefinite articles; run on sentences or comma splicing (e.g. in point #3); subject-verb agreement...
I might have overlooked these things in another context, but the article is trying to present tips on "how to judge how good a candidate is", and even talks about communication skills.
If you say it never happened and have more than a year or two of experience, I'll be very surprised.
In our interviewing process we divide up the type of questions to ask the applicant with some overlap. So one guy will ask mostly process-oriented questions (what kind of unit testing do you do), another will ask CS/programming related questions (what are common problems in multithreaded apps and what are some solutions), and another will ask team-oriented and "soft-skills" stuff like the one I mentioned above.
It gives us a more rounded view of the candidate than whether or not he can code.
Good design operates in the face of real world constraints, unlike typical interview questsions (see the article on Apple design about Real Artists Ship).
As an interview question, I used to ask people to design the DB schema for Netflix. Almost everyone could get something that would kind-of sort-of work. Of course there was a gradient of bad to good answers, but a passing or better grade on the question did not help predict whether the candidate would get an offer. Asking FizzBuzz was a better predictor of whether they would pass the interview process.