On: Why 37signals Doesn't Hire Programmers Based on Brainteasers

[jlarocco]

I would rather be tested by making changes to the the multi-kloc codebase. It's more similar to what I actually spend my time doing at work. And it's a good chance to see the code I'd be working on.

As for coding Pascal's triangle? It took me <30 seconds to Google it and find code I could copy/paste.

[ori_b → jlarocco]

I've had interviews where I've been asked to take a moderately obfuscated code sample, find out and describe to the interviewer what it does, and then find all the bugs in it.

To be honest, seeing about 200 lines that looked like this:

    typedef struct Abc {
        Abc *n;
        Abc *p;
        void *d;
    } Abc;

    Abc *foo(Abc *p, void *x)
    {
        Abc *n;

        n = malloc(sizeof(Abc*));
        n->p = NULL;
        n->n = p;
        n->d = x;
        p->p = n;
        return p;
    }

Note, there are at least 3 (edit: at least 4) bugs in the above code. None should be syntax errors.

Sorting it out was a bit of a challenge. I think the specific question that I was looking at deobfuscated into reading words and definitions in from the command line and maintaining them in a sorted list, then looking up the words and printing their definitions.

And I agree, it was a great interview question. I even had the ability to sit in front of the computer and test my fixes to make sure it worked.

[peterhunt → ori_b]

Let me try (I do not often write production C code)

1. You need to malloc 3 words, and you're only allocating one (you want sizeof(Abc)) 2. Abc in the struct will not resolve (change to struct _Abc and the struct name to _Abc) 3. You should cast the result of malloc/check for failure 4. This is bad memory management practice, I think.

[ori_b → peterhunt]

1) Right.

2) No, 'struct Foo' is in a different namespace from the typedef'ed name. 'typedef struct Foo Foo' is perfectly valid.

3) Yes, absolutely.

4) Not sure what you mean.

Here's a hint: You'll likely miss one of them unless you realize what the algorithm is trying to do. It's an algorithmic error. The other one is findable from looking at the code without context, but the correct fix isn't entirely obvious without realizing the way the code works.

Pretty good, though :)

[2arrs2ells → ori_b]

Abc is a node in a doubly linked list.

I think function foo is supposed to insert a new node (n) into the list before node p, but it's not done properly (while n points to p and p points to n, n does not point back to the item before p).

[ori_b → 2arrs2ells]

I was going for foo as 'dlist_prepend()', not dlist_insert(), but figuring out that it's putting a node into a list is good enough for me. (Edit: to me, 'prepend' implies that there are no nodes before the head of the list you're prepending to)

That should be enough for you to figure the last 2 errors, in any case.

[2arrs2ells → ori_b]

Prepend is probably a better way of expressing "insert before" :P

n->p = p->p

I don't see the last one - unless foo should be returning n?

[ori_b → 2arrs2ells]

Yes, it should be returning `n`. And the final one I was thinking of was a segfault on an empty list

     prepend(NULL, &something);

would die if you don't do;

     if (p != NULL)
         p->p = n;

I think, this would be easier in a larger problem where you had context that gave you usage examples. I probably wouldn't ask someone to debug a function floating an a vacuum like I did here. I'd use a trivial but full working program.

I don't think I'd expect everyone to get every bug without a little bit of prodding in the right direction. Being able to step through the code and show what it's doing to the data structures would be a first step that would make me happy. Recognizing that the data structure looked like it's a linked list, and finding and and fixing a couple of the bugs, and I'd be very happy.

[altxwally → ori_b]

Thanks for providing the example, this thread was very entertaining and made me become more interested in learning more about how C works.

[ori_b → altxwally]

Glad you found it interesting.

[rayval → ori_b]

Function should return n rather than p.

[gsg → peterhunt]

Casting the result of malloc isn't a good idea in C because it can hide the lack of a prototype if you forget to #include <stdlib.h>. It's also a redundant mention of the type name in question, making for more work / noisy diffs under code change.

Unfortunately C++ requires the cast.

[sanderjd → jlarocco]

I agree that the real test is how well you do on the real codebase. But (as an interviewer) I'm not going to let you see that codebase or spend time describing its architecture to you until I'm convinced you are worthwhile. Hence, walk me through the steps to generate something programmatically; Pascal's triangle or anything else. I don't give a shit that you found code for it on Google, I'm not looking for a solution - I'm looking to understand how well you can solve problems.