[jlokier]

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

[MrGilbert]

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.

[jcun4128]

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.

[the_only_law]

> 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

[taylodl]

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.

[jcun4128]

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.

[taylodl]

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!

[jcun4128]

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.

[MrGilbert]

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