Hacker News Reader

Comment by zhemao | Hacker News Reader

Although the article as a whole makes very good suggestions about keeping your skills fresh, I think his standards for the candidates he interviewed are impossibly high. Expecting an understanding of what the kernel does when malloc is called is probably fair (actually I think this is a trick question, as I believe the kernel doesn't actually page in any memory until it is accessed for the first time). But I don't think anyone without superhuman coding chops would be able to implement an LRU cache framework in one hour using a C library they have no experience with.

View on HN

A simple LRU cache is not very much code (certainly less than 100 lines even in C). Assuming the hash function in question has a sensible API, getting something that works but has a few bugs and performs suboptimally should not be at all difficult for an experienced programmer who knows what an LRU cache is.

I totally agree. This should not be a hard problem to conquer since the hash table is provided by library. I just want to see if the candidate is a competent coder and a fast learner.

Okay, yeah, I guess I was overthinking it a bit. It does seem relatively straightforward now that I reflect on it some more.

While I agree with you, writing a crappy LRU will be a poor indicator of skill for a senior developer or architect. It will be just a pointless and useless piece of code. My guess is that the author asked for production-ready high quality code. I know that I've been asked many times for production quality code in interviews.

If I was the interviewer I'd just check how they go about it - do they just start typing or do they read the docs, that's a big one right there. I wouldn't expect bug free code, just a reasonable attempt, clean code, and something that generally works because a LRU cache is really simple.

I disagree it's useless - if I have a senior developer, they better know how to do the basics. Otherwise what are they good for?

What's the right answer here? Should they start by typing or reading the docs?

There is "crappy" as in buggy / overcomplicated and there is "crappy" as in lean, simple minded LRU that just works. The latter is production-ready high quality, even if it may be not tuned or optimized. You can tweak later, first can you actually ship some code?

I think it takes more than an hour to make something production-ready. Setting up test cases and tracing down memory errors and leaks is going to take a while, even (and I would think especially) for an experienced C programmer.

What memory errors and leaks? A good coder should be able to produce error-free code on first try, provided the documentation is clear and correct, and the problem is sufficiently simple (as in this case).

Tests and debugging will only get you so far, theoretical methods can get you farther in terms of correctness (provided your compiler isn't broke etc).

Quoting Linus Torvalds: "Don't just make random changes. There really are only two acceptable models of development: "think and analyze" or "years and years of testing on thousands of machines". Those two really do work."

Okay, maybe I should rephrase it. It takes more than an hour to carefully think and analyze, and then implement the thing, and then make sure there aren't any bugs. Thinking things through beforehand makes the possibility of errors less likely, but even then you may have made a silly mistake at some point or another. That is why we have things like unit tests and code reviews, because even the best programmers make mistakes. I certainly wouldn't trust C code written by a single developer in one hour to be production-ready.

I can rephrase as well. I'm not going to rush your interview code to production, but the review cycle needs to start with a first version. We'll refine as needed, but this is a simple enough problem to expect well-structured code in one hour.

Fair enough.

The glib hash API in question wasn't linked in the article, here's the reference: https://developer.gnome.org/glib/stable/glib-Hash-Tables.htm....

I would say it's very easy to use, but I'm quite biased (through experience).

I think the difficulty of the malloc question is a bit hard to assess for non-kernel programmers. Best I could do is some educated guesses that would probably be wrong. But then I am not a kernel/systems programmer

The LRU cache on the other hand sounds trivial.

When I thought about that malloc question, I starting asking myself "so I knew the old way was eventually libc calls sbrk and the kernel adds some more pages to the page table. But I can't remember if that's still considered the right thing to do; I've heard of people using mmap for malloc for some reason I can't remember." But that's probably sufficient for his purposes.

Reply on news.ycombinator.com