Slashdot Mirror
How Should You Interview a Programmer?
phamlen asks: "Having hired several programmers who haven't worked out, I'm wondering if other people have better success with interviewing techniques. Usually we have a two 'technical interviews' and a final interview. The technical interviews tend to be a combination of specific technical questions ('Is friendship inherited? How would you find out?') and algorithmic ('Given the numbers from 1-10 missing one number, how do you find the missing number?'). In addition, we essentially try to interview for: intelligence/performance. technical skills (algorithmic, etc.), and team compatibility. Unfortunately, we've been burned a couple of times by people whose performance didn't measure up to what we expected from the interviews. So I'm wondering if other people wanted to share their interviewing tricks - how do you find out if someone is a good programmer?" Surprisingly enough, we've done a series of these, so if you are interested in similar questions for sysadmins,
network engineers, or the one who will follow in your footsteps, then we've got it covered. We've also covered core IT questions as well. What special ways do you have of evaluating potential coders? How well have they worked out?
... the swap function. It may be simple and about three lines long, but you'd be surprised how many people it weeds out who simply don't understand pointers.
And understanding pointers (even if you use non-pointer languages) seems to be a common trait of most "Good Programmers".
When I applied for my current programming job, they gave me a barrage of tests and compiled an aptitude and personality profile of me.
It was really freaky how accurately it described me... the main point was to evaluate me with reference to the type of person that excels at my job (Programmer/Analyst with some support duties)
They also asked for source code I had written and numerous references.
THe problem with an interview is it's too easy to bullshit. You need to go beyond the interview, as my current employers did.
Robots are everywhere, and they eat old people's medicine for fuel.
The original posters questions and theories are a little weak. Testing a programmer's skills in constructing algorithms for random scenarios is a great idea.. if they need to use lots of algorithms.
The key to interviewing is to scope out the person's general work ethic, overall personality, and how well the person can do the job they have applied for. That's it!
In previous Slashdot threads we have learned that it's not wise to sit programmers down with a pen and paper and get them to write C code on the fly! Yet... the interview techniques you are mentioning are a lot like that.
Getting people to 'think on their feet' is good, if you're just talking concepts and ideas, but don't expect people to get things 100% right sitting at an interview table. These guys are programmers, not TV evangelists with all of the answers at the tip of a hat.
From the sound of your post it seems like you have interviewed people, found them to be great at algorithms and answering your questions, but then have found their work ethic stinks or that they're not as ingenious as you thought they were. That's because you assume that someone who can answer questions quickly and proficiently is a good programmer. Wrong!
Instead, look out for programmers who list extra-cirrucular projects on their resume. Look for programmers who have worked on their own projects, and can demonstrate them for you. Would you rather employ someone who coded a great deal of Gecko, or some gimp who can answer your algorithm questions?
Look for people who don't need incentives to work, but those who will program whether they get paid or not! Those are the people who will stick with you, and aren't just learning new languages to make a quick buck.
mogorific carpentry experiments
At my company, since we're small, we need to know that new developers will click quickly. We do a technical paper exam (one hour) with some standard programming/algorithm questions. We then do a few riddles and logic puzzles. These are the best way to test raw intelligence, IMHO, since you have to think abstractly and quickly. We then do a few more design questions at a white board to test their skills at high-level design and diagrams.
;-).
However, the one thing that is difficult to test but really seems to be the deciding factor of a new hire "working out" or not, is whether or not they have the "passion". One way we try to determine their take on programming (just a job vs. a fun hobby) is to ask them to describe one software project that they have developed on their own time (not on the job or necessarily part of schoolwork). It's amazing how few actually code for fun or just to continue the learning process.
We then ask them what their favorite joke is just to jolt them a bit and see if they have a sense of humor. Most people fail this question, unfortunately
--- witty signature
I have to agree whole heartedly. One of the nice things about programmers is that you don't have to guess whether they are good or not. You can look at their code or ask them to interpret some that your team has already created and critic it to see if they code in similar ways etc. Since it sounds like you are employeeing multiple programmers. Have one of them sit in with the guy and talk shop, work on functions, etc. If your guys are good programmers, they should have a pretty good BS detector. Artists have portfolios, why shouldn't programmers (PDA's aside).
Paul,
I've been in this biz only a little longer than you have and agree with your approach.
A couple things I've noticed about the better programmers I've worked with/hired are:
Most play a musical instrument of some kind.
Most enjoy and are good at strategy type games such as chess and go.
Left handedness seems to be higher than in the general population.
They do crossword puzzles.
John
If you're not living on the edge, you're taking up too much space.
... to simple questions.
People who have "training" but lack skill or experience are desperate to show you what they know. You can ask a very simple question, and they'll throw out names of tools they think might be relevant, and buzz words they've heard. They're unlikely to give you the simplest answer.
I once was asked in an interview for a DSL installation tech job, "if you installed a memory upgrade into a laptop, and upon boot up the new memory wasn't recognized, what would you do next?"
I felt kind of foolish saying "Well, I'd open up the laptop, reseat the memory, and try again." But the interviewer nearly wept... he'd been interviewing people with all kinds of "qualifications" all day, and I was the first person who had given this answer. He told me how everyone else had said "Well, I'd start up Tech Tool..." or "I'd get out a memory tester and..." without even checking that the installation had been done right in the first place.
That, of course, is not a comprehensive method for finding a good person for a job, but it might make your technical questions a little more effective.
Don't you wish your girlfriend was a geek like me?
In one of my previous companies we actually tracked engineer recomendations for new hires (i.e.: how well did a person you recommend to work at the company is actually doing after a period of time X), and after about 18 months I came up on top of the list after 98% of the people I recommended ended up being described as "outstanding".
If you care how I can tell the good ones from the bad ones, read on.
It all boils down to someone being proactive in learning things, entusiastic about the field he/she is going in, being able to communicate effectively, and basically have the capability to look at things in more than one way.
In my experience the best thing during interviews is to let them talk as much as they want, you will be surprised how much you can learn from them in just a few minutes. Encourage more conversation by asking short questions along the form of "can you explain that part a little bit more for me?".
Also, to avoid the "bullshit talker", once in a while interrupt them and ask them to described how exactly (in pseudo-code) they solved a specific problem.
It's also a great idea to ask them to draw visual diagrams that explains how things work. This tells you a lot about the way they solve problems.
If you have the time, place them in front of a computer and hand then a piece of pen and paper and tell them to write a made-up documentation for a fictitious project. This will tell you how well they communicate and how well they express their ideas.
During all this, it is up to you to figure out what makes this person special from the others. Is he great at explaining things? is she great at understanding what you mean and putting it down into a design on a piece of paper? Does he come up with novel ideas to solve problems?
That's basically it. I usually refrain (unless it is a basic requirement) from asking language-specific questions (C, Java, VB, etc), since usually a smart programmer can pick just about any other language in a few weeks, and besides, usually newcomers don't start from scrach programming, there's usually an installed based of development tools and written code which can bring him/her up to speed.
Those are my 2cents of wisdom.
It hardly ever happens this way in real life. Many interviewers have no clue what they are looking for. Most questions are egoistic - just to prove that they know something that the candidate doesn't. Last year, a business software company asked me questions about Turing machines and the Halting problem. I answered him and further added that I had never thought about those since school and did not expect to use them at his company. So why did he ask me that? He said he just wanted to test me!
An interview is not a quiz. If you are looking for a software developer to write Servlets, don't ask him higher math and complex algorithmic questions. Try to find out his views on software engineering itself (good practices that we all know about) and technologies related to his job (HTTP protocol, for example).
Also, don't ask a programmer about any specific api or libraries (unless knowing that is specifically his job!).
Don't ask him about tools ("how comfortable are you with Visual Cafe?" is a stupid question").
And so on. Bottomline: Know what you need from him and see if he has that!
All your favorite sites in one place!
2 . Scan through the list of numbers and stick them in their respective slot.
3 . Scan through the array and return the element index that is empty (or invalid value, as the case may be)
This is simple, straight-forward, easy to debug and only O(n). Why complicate things beyond necessity? With n unsorted elements, you are going to anyway arrive at an O(n) algorithm (atleast).
Programmers don't write code to fix problems frozen in time. The requirements keep changing and the code must be easily readable and maintainable! These are more desirable features in programmers.
In real life, in 3 months, the problem statement could be changed as - "atleast 2 elements may be missing and you have to return the highest, unless the lower missing number is 3, in which case you need to return 7".
Will the complex algorithms proposed handle this change gracefully?
All your favorite sites in one place!
I found this a worthy enough read to bookmark it. The author has some good ideas about preparing for an interview and formulating a meaningful evaluation of that individual's skills beyond the basic text-book Q/A dialogue. http://www.joelonsoftware.com/articles/fog00000000 73.html
Fools ignore complexity; pragmatists suffer it; experts avoid it; geniuses remove it. ~A. Perlis
> Give them a question they don't know the answer to
> (this may take a few tries). If they try to feed
> you some BS they're probably not a good candidate.
> Its always good to know you've got people willing
> to give the honest answer, "I don't know".
Heh. I went to an interview once for an administrative/support position. From the questions the interviewer asked, I got the opinion that he had an overestimation of his own abilities.
Anyway, he asked me a question but first gave some background. He said that he had a SCSI problem with a server that had taken himself and 5 other engineers over 6 hours to diagnose. He then asked me the question. I asked him a question about the system and instantly knew I was on the right track by his reaction. He said to me that it was ok if I didn't answer it correctly in the the next few minutes. I then asked him the second question about the system (zeroing in on the solution) whereupon he began looking uncomfortable. I asked the third question and hit the nail on the head. He said he'd get back to me and that I had figured it out.
I never heard from him again. To this day, I guess I intimidated him or he thought I was a smart@ss.
I'm not trying to brag or anything... it's just that I like to know my stuff. I like solving problems and fixing things.
I guess the moral to this story is that sometimes you have to feign stupidity? Don't look better than the boss... I dunno. I just get the feeling that they are looking for YES men who make them look good rather than people who know what the fsck they are doing. Heh whatever.
Codifex Maximus ~ In search of... a shorter sig.