Stack Frames...

Last night at dinner the discussion turned to interview questions and how hard interviews are at different places.  Nino had interviewed me when I first applied for GA Sullivan (a company now assimilated into Avanade) and if I hadn’t been studying for my MCSD at the time for VB6 I don’t think I would have been hired.  Nino had a vicious reputation at GA for giving some rough interviews.  I think he made a few people cry.

Anyway, one interview question that was brought up was “given some generic method signature, what would the stack frame look like when it is called? “.  All of us (including Nino)  were a bit baffled by this question’s purpose other than for perhaps someone interviewing for a job that would require coding in C, C++ or assembly where management of memory was on the developer, not the system.  With VB6 and .Net all the memory management is done for you, behind the scenes.  You wouldn’t need to actually know what a stack frame looked like.  In fact, I’d wager that most VB6 developers don’t even know what a stack frame is.  I knew what they were in the general case, but certainly not what they would look like during a method call. 

So, being intrigued by the question I did a little searching and found a couple of pages from a computer science course with online notes that may answer the question.  If you’re interested check out the following: Stack Frames (1) and Stack Frames (2).  This gives a description of what Stack Frames are on the first link and an example of what one may look like in memory on the second link before, during and after a method call.

This brings up a good question as to how deep should your technical knowledge be?  If you are primarily a .Net developer, should you have to know what a stack frame looks like during a method call?  Does that give you some edge in your development designs?  Maybe it would matter if you understood about how things were allocated to the stack vs. the heap for performance reasons, or if you were developing code for a system that is greatly memory constrained (like a smart phone or pocket pc) and needed to maximize your memory footprint.  But even then, .Net handles the memory management for you.  Have developers gotten lazy as the system takes over memory management?  How often have you heard “just run it on faster hardware” when you see performance issues in an application?

What do you think?