bnoordhuis

I've been going back and forth on this.

On the one hand, I feel that positive discrimination is just as bad as the other kind and that its proponents are not thinking things through as clearly as they should.

On the other hand, board members are humans too. Given the choice, and whether consciously or unconsciously, they will typically elect people much like themselves, because that's the kind of person they can understand and relate to. It's an understandable human trait but it does perpetuate the status quo.

I do wish the focus was less on gender and more on diversity in general. We have sizable ethnic minorities in the Netherlands but they are quite underrepresented in upper management and I'm not sure it can be fully explained by the socioeconomic and education gap.

Interesting results, thanks for sharing. I can perhaps shed some light on the performance differences.

> Buffer 4.259 5.006

In v0.10, buffers are sliced off from big chunks of pre-allocated memory. It makes allocating buffers a little cheaper but because each buffer maintains a back pointer to the backing memory, that memory isn't reclaimed until the last buffer is garbage collected.

Buffers in node.js v0.11 and io.js v1.x instead own their memory. It reduces peak memory (because memory is no longer allocated in big chunks) and removes a whole class of accidental memory leaks.

That said, the fact that it's sometimes slower is definitely something to look into.

> Typed-Array 4.944 11.555

Typed arrays in v0.10 are a homegrown and non-conforming implementation.

Node.js v0.11 and io.js v1.x use V8's native typed arrays, which are indeed slower at this point. I know the V8 people are working on them, it's probably just a matter of time - although more eyeballs certainly won't hurt.

> Regular Array 40.416 7.359

Full credit goes to the V8 team for that one. :-)

On and off kernel hacker here. Compile and test the release candidates Linus puts out every fortnight. When the inevitable breakage happens, use `git bisect` to track down the offending commit.

It's tedious and time consuming but you will make people very happy. The only way to test something as big and critical as the kernel is by having users actually run it.

That's a regression we'll probably have fixed in 0.6.1.

Note that I/O read performance is up 35%, from 19.7 mb/s in 0.4 to 26.6 mb/s in 0.6.

linux doesn't have kqueue. But kqueue is only an API, you could emulate it with io_submit() and io_getevents().

A bigger obstacle is that not all file systems support asynchronous I/O, the io_*() syscalls won't help you there.

That was the impression I walked away with too: much CS ivory tower thinking, little real-world relevance. But they're only interviews, everyday life at Google is probably (hopefully!) different.

As a counterpoint to the HR horror stories: my recruiter was a friendly woman who always responded quickly and politely. No complaints here.

There isn't a shred of the original mongrel parser left. I'm not 100% sure but http-parser looks more like it's inspired by nginx than that it actually contains nginx code.

Disclosure: I know both http-parser and nginx fairly well. I'm one of the 'other Node contributors'. :-)

Maybe I can help. I'm relatively local (Gouda, ZH) and I've managed teams like the one you mention before. Shoot me an email, address is in my profile.

The language was C and my solution (adapted to the article) was something like this:

    // TODO enforce! see also: soylent green
    #define MAX_AGE 100

    struct student {
        const char *name;
        int age;
    };

    struct students {
        long n_students;
        struct student *students[10e6];
    };

    struct students all_students[MAX_AGE];

    void insert(struct student *s) {
        struct students *ss = &all_students[s->age];
        ss->students[ss->n_students++] = s;
    }

So O(1) insertion and O(n) post-processing to stitch the arrays together again. Seems like pretty acceptable performance to me but the Google guy thought otherwise, the answer he was looking for was (probably) a counting sort.

I tried to argue that my solution was a fair bit faster and simpler to boot. That's probably why I didn't get a follow-up interview - no-one likes a smart arse. :-)