Hacker News Reader

Comment by plorkyeran | Hacker News Reader

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.

View on HN

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.

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).

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.

Reply on news.ycombinator.com