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