6 ms·
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 impossi
by zhemao 13y ago
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.
- nikster 13y agoI 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.
- plorkyeran 13y agoA 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.
- vladimirralev 13y agoWhile 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.
- nikster 13y agoIf 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?
- deleted 13y ago[deleted]
- vineel 13y agoWhat's the right answer here? Should they start by typing or reading the docs?
- pacala 13y agoThere 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?
- zhemao 13y agoI 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.
- ambrop7 13y agoWhat 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."
- zhemao 13y agoOkay, 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.
- pacala 13y agoI 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.
- tyrchen 13y agoI 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.
- zhemao 13y agoOkay, yeah, I guess I was overthinking it a bit. It does seem relatively straightforward now that I reflect on it some more.
- unwind 13y agoThe glib hash API in question wasn't linked in the article, here's the reference: https://developer.gnome.org/glib/stable/glib-Hash-Tables.html 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).
- deleted 13y ago[deleted]
- zhemao 13y agoThat's about it, except you have to keep track of the total size of your cache so you know when to start evicting. I didn't mean that it couldn't be done, I just thought that one hour was a bit short. I tried it myself and, after setting up tests for the common use cases and tracing down all of the memory errors, it took closer to an hour and 45 minutes. I suppose if the author wasn't looking for perfection, but for something quick and dirty, it wouldn't be so unreasonable.
- deleted 13y ago[deleted]
- gchpaco 13y agoWhen 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.