Hacker News new | ask | show | jobs
by MrGilbert 1759 days ago
Here I am, writing B2C applications, wondering, why after 8 years of professional programming, I never encountered the need for a "heap".

Then I looked it up, read about it, and realized that I'm using it without naming it. I know it by the name of the special class I'm using in my language.

I wonder if I would fail miserably in an interview, or if it just depends on the questions that are being asked in the domain I'm working in. Or maybe I'm just not FAANG.

4 comments

"Heap" has at least two meanings.

Often when asked about "the heap", it's in the context of heap versus stack. "What's the difference between a heap-allocated object versus a stack-allocated object", or "what's the diffence between the heap and the stack"?

That sometimes comes up in early phone screen interviews.

Some languages don't have that distinction: Everything is heap-allocated. So it's understandable how you could work without encountering the difference in some environments. But many of the commonly used "big" languages make the distinction, and if you've been working professionally for 8 years, interviewers who ask about it will take into account if you know the difference. Especially if the job is in a language where it matters.

(If you're looking at working with any of the async-await-patterned languages, you might be asked a trickier question about how does async change heap vs stack allocation.)

As a sibling comment points out, "a heap" is used in a second way, to mean a heap data structure, which is one of many ways to implement a priority queue data structure. Realistically, this rarely comes up in real life except that you might use an efficient priority queue without caring how it's implemented. In interviews, it might be asked about to assess the depth of your CS or performance knowledge. The same way they may ask about other basic data structures like balanced binary trees, linked lists, etc. Heaps are among the simplest "CS-ish" data structures. Even if you're not that interested in CS, I'd say it's worth reading what heaps are and how they work, even if you never implement one.

Yeah - I was aware of the "heap" as in "stack vs heap". Though I could not explain, without looking it up, what the difference is between values being put on the stack or the heap.

Now, of course, after reading about it in the linked article, I looked it up and now I have an understanding of it.

But I wonder how much this will be taken into account during an interview. I could, from the technology I'm working with, explain what the pitfalls of an async/await-pattern are, or what the difference between the logical and the visual tree in WPF is.

I wonder if you loose some knowledge on the way while working in a certain domain for a long time, and if that's a bad thing per se.

I remember this was one of the first things they teach you in Java but in web world eg. react do you even think about that stuff... Unless you see call stack exceeded.

That's why part of me does not consider myself a programmer since I'm just building out applications/basic server admin but I'm not worrying about nLogN or memory management. Unless something is really just blatantly bad/noticable lag/bad performance. I only recently started to learn about BST but personally have not had to use it yet.

> That's why part of me does not consider myself a programmer since I'm just building out applications/basic server admin but I'm not worrying about nLogN or memory management. Unless something is really just blatantly bad/noticable lag/bad performance. I only recently started to learn about BST but personally have not had to use it yet.

There’s a comment I found from a few years back[0] that touches on something related. There are some oversimplifications in the latter part refuted and expanded on in the replies, but the general idea struck me as probably mostly correct.

At this point I’d kill to just get out of the industry entirely, but there’s no desirable path out.

[0]https://news.ycombinator.com/item?id=12079697

You're focused on delivering solutions. I've been programming for 35 years now and I know all this fancy-schmancy CS stuff - have a degree in CS and mathematics to go along with it - and you know how often I need to worry about this? Especially these days? Hardly ever. So don't worry about not considering yourself to be a programmer.

Build solutions, delight your customers, and call it a day.

Yeah I mean I still get paid/can't complain. I just feel concerned when people rattle off these algorithms and what not and I don't use it day to day... maybe it's FOMO.
Yeah, I've found there's two kinds of programmers: those who consistently deliver value, and those who pontificate over which algorithm to use and miss deadlines! :)

99.9% of the time it makes no difference whatsoever and when it does, Stack Overflow is only a click away!

Yeah I'm definitely currently in group 1, I'm working towards 2 regarding robotics/vision but I also am aware that I am not good at math even if I try. At the very least I can take part in group 2 as a hobby.

I also wonder to what extent can you consider yourself good/bad regarding resourcefulness/desire/aptitude to learn. If you took a developer and had them learn Post/ghostscript while having not worked with printers before, how quickly should they be able to learn it? That's a thing I'm dealing with now, it's not as easy as just pulling a popular library from GitHub and plugging it in.

[0] really resonates with my "feeling" about it. Thanks for the link!

Although I wonder if I would want to get out of the industry. While I admire the works of Torvalds and Bellard, and every once in a while dip my toe into low-level works, I feel happy about end-user feedback and making someone's life easier by providing a useable UI to a dataset.

I used to read a lot of programming books in my early 20s, but experience taught me that everything I don't use on a daily (or at least weekly) basis will end up forgotten in no time. So now I'm just trying to work diligently and integrate stuff that offers immediate benefits. Of course, there are certain situations where, say, mad complex analysis skills would have meant shipping a significantly better product. But hey, perhaps those jumps aren't for me to make.

Individuals who learned data structures and algorithms in university 20 years ago and can recall 95% of it do exist, but there's far less of them than most people think. There's no real progress without keeping your personality and your situation in mind.

Yeah, that's what I also experience. Some kind of "erosion of knowledge" is happening over time - and I wonder if that makes me a "bad developer" if I don't actively fight against that.

Sometimes I think I should be able to come up with a sort algorithm from my mind, for instance - but I would have to look up how quicksort is working. I know that something like quicksort or bubblesort exist, but I couldn't tell you how the algorithm behind it works.

This happened to me many years ago when I was a teen and working on personal projects, but even worse. I forgot exactly what it was (something in C#), but it was something as fundamental as classes, I wondered if I'd ever need them, looked it up, turned out I was already using them.

On interviews, I have the same fear as you. I know very little on the theory side of things (and don't have much of an interest to either), but I can get the job done. Maybe I should read up on the theory a bit more, or maybe I will another day ;)

Heap has multiple meanings. For example it could mean the datastructure typically used in priority queues.