Comment by earl | Hacker News Reader

Comment by earl | Hacker News Reader

I personally hate graph algorithms and all the stupid associated questions. I have to spend two weeks reviewing all that stuff every time I change jobs to go ahead and never ever use it again. It simply never comes up in the type of work I do.

At my current place of employment, one of the engineering managers was complaining that an interviewee bombed a graph algorithm question. I asked, "Where -- if anywhere -- in our codebase do we use any graph algorithms?" Answer: "We don't." At all. Yet knowing graph algorithms is apparently a requirement for working here, which means that at minimum, I am unqualified to do my job. Sigh.

I'd much rather candidates spent time understanding memory implications of different types of java/jvm data structures, or know how to diagnose and fix memory pressure, or have experimented with design patterns to reduce memory requirements, etc. But nobody asks me. If you know off the top of your head that in the hotspot jvm an Integer is 4x as big as an int and that a Double is 24 bytes, and can figure out the rough size (8.5KB!!!) of a 100 entry TreeMap<Double, Double>, and know what compressed oops does and why it works, you'll almost certainly get a "please hire" vote from me.

edit: note that knowing a bunch about jvm memory use isn't a requirement, but knowing it will impress me. It probably also means you've been burned by jvm memory use before and that's why you know this stuff.

I've been interviewing recently and my opinion is more or less the reverse. I preferred the interviews where I was asked algorithms - only got asked on graphs once, but my last job did involve a lot of those so I was pretty comfortable with them. They seemed more useful to me than asking "trivia" type questions which you could learn in fifteen seconds - for example, I got one elsewhere about access to members of nested classes in C++, which I just couldn't remember at the time. The thing is, you can solve that immediately if given a compiler.

Personally I'd rather have a coder who understands the concepts behind these things, even if they don't necessarily know the answer right then, than one who is simply able to rattle off definitions by heart. In the example you gave, I agree that it's valuable to know that an Integer is significantly bigger than an int, and that a Double is bigger, and that your TreeMap<Double, Double> might be bigger than you expect, even if they didn't know the exact sizes of any of those things - but I guess I'd want them to be able to take a stab at working them out.

I think the point is not that someone who doesn't know about Java memory issues is useless. The point is just that someone who knows those things, but doesn't know graph theory well may be a better fit for the job, but the interview process doesn't account for this.

Well, I think the goal of these graph questions is not so much figuring out if they "know graph theory". But, rather, figuring out if the candidate had a solid Computer Science education and if they can think about a problem in abstract terms (as a proxy for being smart in general). The idea being that if those two things hold true, they can learn everything else on the spot.

I don't have a solid CS education (I studied EE in college), and I've had no trouble getting interesting, satisfying jobs at startups. Frankly I've found little correlation between CS background and whether a candidate is a good developer or not.

What the fuck made you use java if savimg memory was your concern?

That's a disproportional response based on just one aspect of whatever solution the OP is working on.

What is so offensive about JVM memory management? Out of interest what is better in that regard?

Java is pretty well know for being a memory hog.

One of the problems is that nearly everything is an object so you end up with a lot of pointers which takes up additional space. Garbage collection isn't free either.

In this case it would have made sense to go with C++ and allocated as much as possible on the stack. It is cheaper memory wise (because you don't have to keep whatever malloc requires around and because they are removed as soon as you are done with it) and it gives better performance too.

For what you can't allocate on the stack, you a smart pointer.

There are of course pitfalls here -- smart pointers (via reference counting) can be slower than garbage collection and they have trouble dealing with cycles. You may also have to take special care if they are shared across threads.

Please cite some references on it being a memory hog, and in relation to what?

Using C++ makes the assumption that the developer can manage memory a lot better than the JVM. Especially when said developer(s) are developing high level business or web applications for example. And do you really expect developers to spend time writing code that manages memory as opposed to shipping functionality.

I don't know if you have used Java, although I get the impression that you've written C++ programs. You shouldn't be so hasty in pinning your colours to the mast so aggressively over a language. As many people on HN have pointed out it's not the language, but what you do with it that counts.

Reply on news.ycombinator.com