Fog Creek Software
Discussion Board




question on Joel test #11


>Do new candidates write code during their interview?

... and do new candidates show how they read code during their interviews?

At a previous job we had the following C++ interview question - the candidate was given a short text in C++ (one page) containing obvious errors. The task was to
pinpoint those errors - shows more about the candidate then if you make him write some stupid linked list or circular buffer,

Really, in most places people don't start to work from scratch, it is often more important how you can understand and extend existing code.
I think that reading code is the lost art in software engineering.

As a kid they first teach you how to read, writing comes later. why is writing code different?

Michael Moser
Thursday, August 14, 2003

I agree that code should be readable by humans, and that reading code is an essential skill for new hires. That being said...

What about learning to read code before learning to write it?

I would like to see more of that. The main challenge is how secretive our industry is. What we need are 'classics' that everyone reads as part of their education.

Not just design patterns... those are like reading twelve haikus. But real, full length, elegantly written classics. Like the Smalltalk80 source code. Or VisiCalc. Or the original Unix Kernal.

It would be wonderful if there were CompSci courses where students reviewed sections of the code and wrote essays on its characteristics, on why the authors made the choices they did, and so on.

Our CompSci programs are more like grammer classes than literature classes. What we need is our "literature" in the public domain where we can read it.

http://www.braithwaite-lee.com/

Reginald Braithwaite-Lee
Thursday, August 14, 2003

some knuth?

i like i
Thursday, August 14, 2003

This is 'classic' code out there to review in book form.

One of the earliest (if not _the_ earliest) is "Lions' Commentary on UNIX 6th Edition, with Source Code".  Since it contained the source to Unix, Bell Labs stopped it from being published for 20 years (until 1996). It was passed around (as photocopies) for those 20 years and was used in many comp-sci classes. It was finally published in 1996 and is still a classic. Its at http://www.peer-to-peer.com/catalog/opsrc/lions.html

Coriolis Press tried the same thing with a line of "Commentary" books (Apache Server Commentary, Linux Core Kernal Commentary, ...) but they were never as successful (the commentary part of the books was weak).

RocketJeff
Thursday, August 14, 2003

Thanks for the link, the bill is already on its way.

Satanic Cultists' Operation
Thursday, August 14, 2003

I have another reason for preferring reading over writing in an interview. It avoids what I call the "Blank Page Syndrome". Being asked to create something from scratch causes some people to freeze up. After all we all use references, cut paste old code etc. in real life.

Having someone review a piece of exisiting code gives an easier starting point and lets you get to more specific issues in less time.

sgf
Thursday, August 14, 2003

Reginald, I would say that Peter Norvig does a good job with writing such literature, with his Paradigms book.  Instead of novels, he writes little short stories of code, which he refines in front of your eyes and builds into more robust and optimized versions.

We really need great literature, perhaps living epic documents.  Graham/Knuth/etc's Concrete Mathematics book has students' notes scrawled in the margins.  Maybe Structure and Interpretation of Computer Programs could benefit from this, if it were in a modifyable version.  PHP docs do this; peoples' notes are right under the refs, and some legal traditions also have annotations under the laws.

My first computing job was actually far more about reading code than writing it.  And even now, it is very easy to just cut 'n paste code rather than write it -- if you deal with many languages, it's better not to try remembering if it's null, nil or None.  I prefer to manipulate prewritten symbols than create them character by character.  Funnily enough, we may simply create new code through refactoring!  Maybe there will be various archetypal pieces of code that we choose and then refactor into what we want.

Tayssir John Gabbour
Thursday, August 14, 2003

I know what Joel is trying to accomplish, but I have found tests to be _very_ limited in value.  In a page of code, does the ability to determine a pointer isn't initialized correctly tell you anything about the person? 

Tayssir makes an excellent point in that the more languages a person knows the more they are apt to confuse Null from Nil from Zero.  As someone else pointed out yesterday, it may also depend on what compiler you used, and the defaults enforced if you get zero or null back.  Does that mean a total lack of skill should be forgiven? Of course not.  What it does mean is that in a 100 point evaluation, coding tests get 5 points in my book.

When hiring, I want to know they have coded in the language, how long and what.  I then want to know how well they understand concepts of good analysis and design.  Then how well do the communicate, present themselves and articulate how to accomplish tasks. 

I find a much higher success rate than when we were using testing houses.  In those we tended to get people very well versed in language constructs, but terrible at taking concept to production. 

As for the idea that "just because someone speaks, and acts great in an interview, it does not make them a developer." I agree.  But if they cannot do that at a minimum, they cannot be either. 

If you are looking for heads down coders, give the tests.  If you are looking for developers, lift up your head. 

Mike Gamerland
Thursday, August 14, 2003

I agree.  Programmers should learn to READ before learning to WRITE code.


When I taught software engineering, I finally realized how valuable that was.  I think it helped my students tremendously.

Also, the BEAUTY (from an instructor's perspective) is that the test is VERY VERY easy to GRADE!!


And remember, part of the quality of a test (at least in Xtreme programming) is the EASY with which you can evaluate whether somethign passed the test. That test you test a lot an learn a lot quickly.

Entrepreneur
Thursday, August 14, 2003


> In a page of code, does the ability to determine a pointer
> isn't initialized correctly tell you anything about the
> person? 

Mike,

with C++ there are many ways to screw things up - understanding those situation assumes that

  - you know something about computer organisation, and  -  - that you know how to apply this knowledge.

In my book that's a skill far more valued then just repeating some coding patterns.

some Examples situations are
- returning pointer to a stack based variable
- calling virtual functions in constructors.
- assumptions on heap allocations versus stack based objects.
- ability to identify error situations like stack overruns.
- etc. etc. etc.

A few of these situations can be neatly expressed on one page.

Ability to pinpoint those situation also identifies people who know how to 'make things work' in C++.

Michael Moser
Thursday, August 14, 2003

To rephrase the last post in a more general way (one that does not depend on computer language):

ask 'can you name some tough problem from past experience, and explain how you tackled them?'

How would you test, if a person can get things done, in a gerneralized way? One that does not involve specialized knowledge? I would argue that this is nearly impossible.

Michael Moser
Thursday, August 14, 2003

I think we all agree that writing code is harder than reading it.  Thus the "we learn to read before we write" comments.  If this is the case, I would want to test my applicants on the harder task rather than the easier.  If it's harder to write code than read it, I want to see if they can write code more than knowing if they can read it.

Now, knowing how to read code is important, too.  But I think the skill to write good code is more important for a developer than the skill to read bad code, and there's only so much time in an interview.

The Pedant, Brent P. Newhall
Thursday, August 14, 2003

I think the reading code test is a good idea, but I wouldn't be testing for nitpicky things like why this code doesn't work:

    for(int i = 0; i < 10; i++);
        cout << "i is " << i << endl;

(that's a real example from an interview I did btw)

A more useful test would be to step up a level and give people code with basic design errors in it and ask them to tell you what's wrong.

For example:

class Car : public Engine
{
};

Andrew Reid
Thursday, August 14, 2003

The key is to ask them to code some brief function or class, but tell them up front that you aren't going to be picky about syntax.

Like others have said, it is very rare to start coding from a blank page.  Also, a good IDE makes it very easy to forget various language nuances, like exactly where you need semicolons in header files or whether null is capitalized or not.

So, make the interviewee comfortable up front that if they forget a brace or something, you aren't going to dock them.  What you're looking to see is someone go through their thought processes.  Do they solve the problem quickly and correctly, do they account for bad input, etc.

David
Thursday, August 14, 2003

I agree with the whole 'let them know you aren't going to be picky about syntax'. I finished a university degree last year, and I remember throughout the years sitting exams that required writing pages of code. I was always annoyed at being asked to write a few pages of code, without being able to compile it.

We had been taught some nice programming methods such as, compile compile compile, ie write the skeleton, compile, add a class, compile.....Then come exams I used to write a half page essay expressing that I could not guarantee the syntax was correct, and if I had a compile I can guarantee that the little errors would not survive long!!.

It was about half-way through my degree that a lecturer advised us that in the exams they are lenient on the syntax. A small thing, but I really would have liked  to be advised of this before, or during the exams.

my 2cents

NB. What are the design errors in this? I am curious
For example:

class Car : public Engine
{
};

An Aussie Chick
Friday, August 15, 2003

> What are the design errors in this? I am curious
> For example:
>
> class Car : public Engine
> {
> };

This is not a "IS A" relationship, so it shouldn't be modelled with inheritance. It is a "HAS A" relationship, which usually is represented like this:
class Car {
    //...
    Engine engine;
  //...
};

ice
Friday, August 15, 2003

I see. Thanks for the explanation.

An Aussie Chick
Friday, August 15, 2003

An OO design question a friend of mine got once (from a college professor, not an interview):

"You're working on a dairy farm simulator. You've got a cow class and a milk class.

So, in milking the cow, should the milk object tell the cow to milk itself, or should the cow object tell the milk object to de-cow itself?"

Anyone see the trick?

Chris Tavares
Friday, August 15, 2003

Which is why CLOS has Generic Functions ;-)

Just me (Sir to you)
Friday, August 15, 2003

The question defines 'milk' as both the white liquid, and the process of extracting that same white liquid from the cow.

the class 'milk' can only be one of these?

An Aussie Chick
Friday, August 15, 2003

"So, in milking the cow, should the milk object tell the cow to milk itself, or should the cow object tell the milk object to de-cow itself? Anyone see the trick?"

If I had to guess at what he was after, I would say that it isn't properly modeled. The "milker" is neither the cow nor the milk, but the person (or machine). What peculiar personification. :)

Brad Wilson (dotnetguy.techieswithcats.com)
Saturday, August 16, 2003

I've never been asked to read let alone write code in an interview. OK, I'm relatively young, and have only had three interviews for software development positions. But still, this did surprise me. All of these places have had technically sharp people leading the development groups (yes, I got the job in all three), so it's not like interviews were driven by HR.

On the other hand, when my father interviewed at his current company two decades ago, he was shown some Cobol to "comment on". It turned out to have been written by one of the interviewers. This made commenting on it a delicate balancing act (not wanting to damage the ego of the interviewer).

MugsGame
Sunday, August 17, 2003

Brad got it.

The intent of the question was to demonstrate that in general, contained objects should be independent of their containers, and vice versa.

At least I think that was the idea. It was a class in OO programming, and the professor was using Scheme of all things. Go figure.

Chris Tavares
Monday, August 18, 2003

Well in this case an argument exist that indeed there could be an explicit  "milker" entity that is not a technical artifact. The general problem goes beyond this though.
Smalltalk like OO sytems are peculiar in that they model things in an "objects receiving messages" paradigm. If you think of this in classical function terms, you can model this as a set of functions having a special hidden first parameter "this".  mySquare.area() could just as well be written as area(mySquare). The function dispatch, which of all the functions named "area" should I call, works by examining the class of the first parameter.

The problem arises when an operation does not have a "natural" dominant participant. suppose I have an algorithm for calculating the area of an intersection of a square and a triangle. Am I going to put the algorithm inside of the Square class by adding a method for intersecting with a triange, so I can do mySquare.intersectionArea(myTriangle), or do I add it to Triangle for doing mytriangle.intersectionArea(mySquare)?
Of course you do not want to duplicate the algorithm code so you pick an arbitrary choice and just add code to "reflect" the request in the other class to the first.
We could introduce an Intersector class but that would just be an artifact of our "special first parameter" model constraint.
CLOS can do dispatching based on the complete parameter list, not just on the first (hidden) parameter. This allows you to write methods that are dependant on a Triangle AND a Square, without promoting one over the other.

LISP rocks! :-)

Just me (Sir to you)
Tuesday, August 19, 2003

*  Recent Topics

*  Fog Creek Home