Fog Creek Software
Discussion Board




How to Interview a Programmer

Since this topic seems to hit the JoS radar with some frequency, I'm sure some of you will have an interest in this article

http://www.artima.com/wbc/interprog.html

"Recognizing good programmers among job applicants is not easy. This article contains interview techniques, garnered from a recent summit on writing better code, that can help you can find the most qualified programmers for your project. "

Just me (Sir to you)
Tuesday, February 25, 2003

What can I say, great minds syncronize.

Just me (Sir to you)
Tuesday, February 25, 2003

Heh.

I think this is great. I've found loads of useful sites from people posting them on JoS.

Thanks, guys.

Better than being unemployed...
Tuesday, February 25, 2003

before now I've been asked to provide a simple function in order to get an interview..

a function that implements some trivial rfc seems to be favourite

nice
Tuesday, February 25, 2003

"Dave Thomas: Hire for talent. " I couldn't agree more.

"Chris Sells:  ... I ask them why ... " Right again, people should know why they're doing things (right or wrong, no matter)

"Josh Bloch: I ask candidates to critique a system or platform that we both have in common" Hmmm ... I would do that only with mature candidates and not if the interview is tensed.

"Pete McBreen: I give candidates samples of our current code and ask them to explain and critique it. " Done this too. Code was a mess and I wanted to know they accept it and don't leave in 3 months.

"Josh Bloch: I like to ask a candidate to solve a small-scale design problem, finger exercises, to see how they think and what their process is: "How would you write a function that tells me if its argument is a power of 2?" ...  I'm looking to see if they get the method signature right, if they think about boundary cases, if their algorithm is reasonable and they can explain its workings ... " ... This is confusing ... for example anything can be a power of 2  (including -1). I wouldn't present a problem to a candidate unless I know it is a correct one. Here this is not the case.

"Bruce Eckel: I ask candidates to create an object model of a chicken. This eliminates any problems with uncertainties about the problem domain ...  It tests to see if they are capable of thinking about the big picture." ... God, a model of a chicken!!! At least confusing!!! We are not modelling stuff just for the sake of it, but to solve a concrete problem. What is the concrete problem in this case???

"Scott Meyers: I hate anything that asks me to design on the spot.  ... I think it's fundamentally an unfair thing to request of a candidate. " Right, more important is to get a good image of the person, not just his design skills.

"Matt Gerrans: I don't like when I'm asked to write a program that does X on a piece of paper.  ... If you want to see a person's work, ask them to write some small module or implement some interface before the interview and bring the code on a notebook PC or on hard copy. Then you can review it and discuss the design, coding style, and decisions that went into it. " I've never tried this, but sounds like a good idea.

"Kevlin Henney: I like design dialog questions that don't have a single fixed answer.  ... I dislike puzzle questions, because they don't require dialog. " Right, communication is the key.

"Josh Bloch: I want to see their code. You get to see what they pick. You learn what they value. You learn how they communicate. " But how can you? I have a big problem with programmers who want to show me code from the previous company. Assignment maybe??

"Matt Gerrans: I ask candidates, "What books have you read about programming?" If the book is beyond syntax, that's important. " and
"Randy Stafford: I find out what books they read because it's important to me that they educate themselves of their own volition. " Very good questions ...

"Randy Stafford: Good citizenship is probably more important than technical prowess ... " As important as ... 'cause doesn't matter if a person is nice if he is a complete incompetent when it comes down to programming.

"Chris Sells: I ask candidates, "Tell me about a problem you had with a boss or teammate. Tell me how you've dealt with a problem with a boss." " Wrong, wrong, wrong. I would gently refuse this question. The only thing you get to know is if you're dealing with a politically potent person or not.

"Jack Ganssle: I check references. Now, I know these people are the candidate's five best friends, and will not say anything negative. But I ask those references for names of people who know the candidate, and go to these others for insight. This way I spread the net beyond anything the candidate ever imagined. " You simply cannot do this. It is an invasion of privacy. I give you 5 names, you may ask ME for more, but not other people.

"Kevlin Henney: I try to imagine if I would go to a pub and talk non-tech with them—not if I like them, but whether I could get along with them. Are they pubbable? Could I talk to them in a non-office situation? " My God! Luckly enough I can put up with a lot of beer, but this is ridiculous. And BTW I do have a life if that's the question.

"Dawn McGee: The most likable person is often not the best person. " Prejudice, prejudice, prejudice. What if the nicest guy IS the best person???

"Dave Thomas: I think every team of a certain size needs a professional pain in the ass, because teams get complacent, fixed in their ways ... and the person who never learned that grownups shouldn't ask "Why?" all the time." FYI, people don't think faster under pressure. Professionals don't need an extra pain in the butt, it hurts enough anyway. And one can ask why? without being a pain in the ass.

"Langer: In Germany, hiring is like marrying someone. ...
The major filtering is done before the interview, based on the curriculum vitae (CV) and submitted papers, such as evaluations from former employers. (In Germany, employers must provide every employee with a written evaluation when they leave the company.) The interview itself is usually brief. The main tool in filtering is scrutinizing the CV and papers; 98 percent of all applicants are disqualified in this phase. The interview should confirm the impression you gain from the applicant's papers and allows you to sense their personality. The lucky winner then goes on a probationary period.

Probation definitely does not replace the filtering; it just keeps a last exit open until you really must commit. " It is like marriage. And it is wrong that way: too much paper work, not enough people contact.

"Andy Hunt: We've hired people who interviewed well, but they were terrible at the job. If possible, hire them in for a trial period. " Right.

"Dawn McGee: You could also bring candidates in for half a day, and have them do what they would be doing on the job. " Useless, they wouldn't even know where to start, you cannot assign them to anything decent, they need training, plus it presents some serious liabilities (what if they have a work related accident while they are at it???)


Conclusion: Treat candidates as persons and try and find out who they are, how they think, what their tallents are.  Give them a fair chance and don't disqualify them on prejudice or bureaucratic criteria. If they seem good fits for the job, try them for 3-6 months.

Conclusion 2: Interviewers sometimes forget that it doesn't matter on which side we are: interviewer or interviewee. An interview is a test for skill and ethics on both sides.

Dino
Tuesday, February 25, 2003

I like the idea of presenting the candidate with a block of code and asking them "what's wrong with that?"

This sort of activity happens a lot more in the real world. I've rarely coded anything from scratch. I've always reused other people's code and expanded an existing product, because throwing everything away and starting again is never a good idea.

What I've found is that I stumble in interviews when I'm asked to design something from scratch, simply because I've never actually done it. I'll worry about the design being "wrong" because I've got nothing to judge it against. But give me a design and ask me what's wrong with it and how I can improve it, and I can rattle off good ideas until the cows come home.

And that "write a function to see whether or not something is a power of two" question ... well if I had to do that in the real world, I could spend an hour doing it, refining it and trying lots of real world test data, and nobody would mind. No way would you allow me to do that in an interview. Then again, if I worked out you had to test that only 1 bit in the number was set and wrote a brute force algorithm around it, would that be okay in an interview situation?

Another question I like to ask is "You have estimated your project will take 3 months. The management say it must be done in 2 months. What do you do?" I've seen this situation arise a lot in the real world...

Better than being unemployed...
Tuesday, February 25, 2003

I thought Bruce Eckel was a character from The Goon Show. Now I find that he is merely someone who thinks that the chicken should be designed before the egg. How disapointing.

Fallen in the water.
Tuesday, February 25, 2003

I always create some hoops of varying colors and shapes and place them in positions around a room that I go to every day and practice jumping through them for a few years.
Despite many failures eventually I can do it easily.

Then I pull in an interviewee of the street and give them one opportunity to jump through them.

If they can't then they don't get the job, and I get to feel all superior.

Alberto
Tuesday, February 25, 2003

"Bruce Eckel: I ask candidates to create an object model of a chicken. This eliminates any problems with uncertainties about the problem domain ...  It tests to see if they are capable of thinking about the big picture." ... God, a model of a chicken!!! At least confusing!!! We are not modelling stuff just for the sake of it, but to solve a concrete problem. What is the concrete problem in this case???

?

Your boss has given you a specific task - you accomplish the task. End of story. What is so hard about modeling a chicken?

Chicken class, inherits bird
Bird class either has wing collection or leftwing, right wing properties (depending on the level of abstraction you need and how critical it is that left and right wings are *not* identical)
Feathers collection
Beak object (zero or one)
etc.

This question is all about your understanding of basic object oriented design and how your thought processes work. He chose a chicken to try to pick something that there is no way you've done before, and to stay out of the realm of specialized knowledge - he wants to keep your eyes on the general design problem, not the specific implementation issues.

For example, if he asked "design a model of a database table" he could end up in an argument about why it doesn't matter if it's Oracle, SQL, or MySQL, and that he doesn't care that the storage methods are different...

Philo

Philip Janus
Tuesday, February 25, 2003

Philo,

"Chicken class, inherits bird
Bird class either has wing collection or leftwing, right wing properties (depending on the level of abstraction you need and how critical it is that left and right wings are *not* identical)
Feathers collection
Beak object (zero or one)
etc."

I'm interested for example in chicken weight and average number of eggs / week. How is your design addressing this????? In this particular case the number of wings, feather collection and the beak are completely irrelevant.

You cannot take a model out of a concrete specification context. The first question always is "What are the concrete specifications we have to address?"

Cheers
Dino

Dino
Tuesday, February 25, 2003

"I'm interested for example in chicken weight and average number of eggs / week. How is your design addressing this????? In this particular case the number of wings, feather collection and the beak are completely irrelevant."

chicken.EggProduction.GetAverage("Weekly")

chicken.Weight

Agreed that in real world development you need a concrete specification, but there is nothing stopping you from creating a design in answer to a question.

FWIW, if I asked a candidate "How would you model a chicken?" and he refused to proceed until I gave him a concrete specification, I would not hire that candidate - inability to think abstractly.

Philo

Philip Janus
Tuesday, February 25, 2003

Philo:
>FWIW, if I asked a candidate "How would you model a chicken?" and he refused to proceed until I gave him a concrete specification, I would not hire that candidate - inability to think abstractly. <

It can go the other way. Another employer can say: "... and he proceed right away without asking me for a concrete specification, I would not hire that candidate, because a model without a concrete specification can be bloat or irrelevant. " (Say, for a KFC frozen chicken distribution system, chicken inheriting birds is totally irrelevant. But for some avian flu research, that inheritance might be useful. )

Employers always say "if ..., I would not hire that candidate." But to me this is just a bit too rash. At least let them explain.

S.C.
Tuesday, February 25, 2003

I must say I would also start down the "what do you want a chicken for" path. First get a rough model of the problem domain, then design a rough solution.

Just me (Sir to you)
Tuesday, February 25, 2003

I agree with Dino and others -- the Chicken model is meaningless outside of the problem.

I think, this is one of the potential problems with OOD/OOP, UML, patterns, etc. They all concentrate on the solution and have advanced tools to represent solution (all kind of diagrams, code wizards, etc.), but on the other hand, they are very limited to describe the problem. There's much less methodology on that side. Often, it makes developers to jump too early into the solution space, without the proper analysis in the problem space. It's not uncommon that designers come up with object model from the very beginning and then describe the problem in the terms of the objects. It's a dangerous approach, that can leads to many problems later. When you have a hammer, everything looks like a nail. :)

So, before you know the problem your Chicken has to solve, its responsibilities and collaborators, you can't come up with good design.

***

From the other hand, you can rephrase the problem this way:

The purpose of Chicken class is to provide enough fake base classes, methods and properties to satisfy Mr. Eckel and pass the interview.

It can be done, of course.

raindog
Tuesday, February 25, 2003

"Good candidates will try to get more information out of you about the problem. Who is the house for? As a policy, I will not hire someone who leaps into the design without asking more about who it's for. Often I am so annoyed that I will give them a hard time by interrupting them in the middle and saying, "actually, you forgot to ask this, but this is a house for a family of 48-foot tall blind giraffes.""

The chicken question is exactly like this.  For some problems, to model a chicken you need nothing more than the x,y, and z coordinates of the chicken and a spherical average radius.  Othertimes, you need to subclass type Bird and add chicken-specific details.  If you're really into heavy-duty chicken simulations, class Chicken aggregates two dozen different internal organs with complex interactions between them and all of which derive their properties from class DNA.

So, the correct answer to this question is not a quick answer, but a, "okay, give me some use cases for this chicken" ...

Alyosha`
Tuesday, February 25, 2003

The chicken problem is just silly. 

I've only been on a handful of interviews, and I only came across one grueling interview process.  In that case, the company asked good questions. Questions that forced me to think fast and communicate well. They didn't test me on arcane knowledge and I wasn't tested on the interviewers personal preferences for coding syle.

Go Linux Go!
Wednesday, February 26, 2003

Although I dread writing code for interviews, writing detailed models, or some archain sql statements to match the client's database I have tended to do much better in interviews like this.

By answering technical questions I can show my talent by showing them my thought process as opposed to vague questions like the one I got at an interview early this year - "what motivates you?". I felt like saying "I hate computers and I will use my pawah to dominate them!". But I guess they were looking for something like: "I am motivated by the beauty of programming".

So my suggestion is to ask technical questions to see their thought process, not if they know the latest trivial technology.

Ian Stallings
Wednesday, February 26, 2003

Can a chicken fly? Sorry, just puzzling over my answer to the question. I'm not sure whether a) a chicken can fly but only over short distances; b) it can only hop long distances; or c) it thinks it can fly but then an exception is generated and it falls over.

Catch the pigeon! Nab him! Grab him!
Thursday, February 27, 2003

*  Recent Topics

*  Fog Creek Home