It's not *Dynamic* memory allocation...



  • Interviewer: Please show how you would convert an int value to a string.

    WTFee:

    CString AString; 
    int iAValue = 32;

    AString.Format( "%d", iAValue );

     

    Interviewer: OK, now do it without using dynamic memory allocation.

    WTFee:

    CString AString( "ABCDEFGHIJKLMNOPQUESTUVWXYZ" ); 
    int iAValue = 32;

    AString.Format( "%d", iAValue );

     

    Interviewer: That still uses dynamic memory allocation!

    WTFee: No, because I preallocate space in the CString upon construction by passing it a string.

    Interviewer: Memory is still allocated and freed when the CString gets constructed and destructed.

    WTFee: OK...

    static CString AString( "ABCDEFGHIJKLMNOPQUESTUVWXYZ" ); 
    int iAValue = 32;

    AString.Format( "%d", iAValue );

    WTFee: See, now the CString is static and does not get destroyed, so no dynamic memory allocation!

    Interviewer: ...



  • I think the candidate shows a reasonable level of understanding to come up with the preallocation suggestion.  Perhaps the questioner should have been a bit more specific about what they wanted as AFAIK they cannot turn it in to a CString without some dynamic allocation somewhere.  If what they actually meant by the word 'string' was a char buffer then this is more due to ambiguity in communication than a real WTF.

     
    I would be interested so see you post what you consider the correct answer so I can see if it is more or less of a WTF.
     



  • Yes, I agree.  Lets have a look at the "correct" answer.  You seem to have an issue with the type of string he is using - but that seems secondary to the problem you are asking him to solve.  If you want him to convert an int to a const char*, shouldn't you have specified that?



  • The use of most string objects (like <font face="courier new,courier">CString</font> and <font face="courier new,courier">std::basic_string</font>-based types) usually implies that heap-based dynamic memory allocation will be used.  This has nothing to do with the "type" of string object used.

    When asked to remove dynamic memory allocation from the scenarion, string objects should have vanished right off the bat. I am not sure how much clearer without using dynamic memory allocation could have been.  True, the goal was to remove heap-based allocation, but as far as most people are concerned, you can only dynamically allocate from a heap.  If the WTFee had used <font face="courier new,courier">alloca(...)</font> to allocate the buffer, that would have been acceptable (to me) as well.

    IMHO, acceptable solutions would have been somewhere along the lines of:

    char caValue[ 16 + 1 ];

    int iValue=32;

    ::itoa( caValue, iValue, 10 );
    caValue[ 16 ] = '\0';

    Preallocating the string object's buffer still requires dynamic memory allocation (and deallocation), so the goal of removing dynamically memory allocation was not met. I am not sure how that would be considered "reasonable".

    As far as clarifying the word string, when someone says constant string or static string, not many experienced C++ developers I know think of a string object somewhere.  Specifically asking for a <font face="courier new,courier">char*</font> may not have resolved things because the WTFee still could have used <font face="courier new,courier">new</font> or <font face="courier new,courier">malloc(...)</font> to dynamically allocate memory into the pointer.  The point was not how the memory was referenced (object or raw pointer), but to remove dynamically allocated memory from the solution.



  • I would neither accept an answer involving itoa nor CString, since I would require portable standard C++ solutions :P



  • I think some of the confusion is not stating why or when you want to avoid the heap allocation.  It might be that you do not want the overhead for each number processed or that you have no heap at all.  Whether it is a pointless optimisation also depends on what you are doing with the string afterwards.

    In your code example I am intruiged by the point of setting the 17th byte to zero after calling itoa.  AFAIK itoa will have either added a terminator itself or overrun your buffer before this line is executed.  Also you have the magic number 16 appearing twice with no explanation of if or why this is big enough to avoid overflow.  WTF! :)

     I tend to find the term 'string' to be ambiguous and to mean any of std::string, char*, CString or QString depending on context, usually meaning the same type of string as in the surrounding code.  If you want a specific type you need to be specific.

     
    Finally I would not expect anyone to suggest alloca.  It is completely non-standard and very platform specific.  Then again so is CString so perhaps this doesn't matter.
     



  • I'm with the other guys on this one.  The answer you get can only be as good as the question.  Given certain states of thought and context surrounding it, this could very well be an ambiguous question, as it appears to have been in this case.  Your interviewee gave legitimate reasons for his methodology, and was actually accomplishing what he thought you were asking.  The problem was that what he thought and what you thought were different things.

    If you would have said afterwards, "Why not use a char array?" I'm sure he would have responded, "That would work too.  I didn't realize that's what you were asking."  If he instead said something like, "but that's dynamic too," then it's fair to say this was a WTF.



  • Imho this is a classic interviewer wtf, where the interviewer is a very technical person. The interviewer will want someone of his own level, thus he wants to invent some questions that only suitable applicants will be able to answer. However, in this process, the interviewer doesn't realise how rediculous and far-fetched his questions have become to make them "difficult".

     I'd be the same, but I still think it's an interviewer wtf.



  • [quote user="MET"]
    I think some of the confusion is not stating why or when you want to avoid the heap allocation.  It might be that you do not want the overhead for each number processed or that you have no heap at all.  Whether it is a pointless optimisation also depends on what you are doing with the string afterwards.
    [/quote]

    We/I often deal with multithreaded implementations, where any pointless heap abuse introduces a unnecessary serialization point as well as additional time to do the allocation and deallocation.  Having to avoid the necessary exception handling required when doing dynamic allocation is another concern, but not part of (this part of) the interview.

    The CString implementation in MFC 6.0 does not support custom allocators like std::basic_string (although it does in the shared MFC/ATL version available with the VS.Net versions) which allows per-thread heaps to be used, eliminating much of the cross-thread serialization.  In the interest of preventing a needless discussion on performance and if it is required or not, consider for this interview that performance is important and required, and the WTFee knew this.

    [quote user="MET"]
    In your code example I am intruiged by the point of setting the 17th byte to zero after calling itoa.  AFAIK itoa will have either added a terminator itself or overrun your buffer before this line is executed.  Also you have the magic number 16 appearing twice with no explanation of if or why this is big enough to avoid overflow.  WTF! :)
    [/quote]

    That is a small habit of mine to help prevent unterminated string buffers - allocate "size + 1", and use size to place the terminating NUL in the buffer.  This allows me to always ensure that a string buffer I am maintaining is NUL terminated. 

    Not all functions available to C/C++ developers will guarantee NUL termination and the habit of doing this ensures that a string is always NUL terminated and does not require detailed knowledge of which functions will and will not guarantee a terminating NUL.  16 was arbitrary - long enough for the (assumed) 32-bit value to be formatted using the indicated function, although 11 would have been the max length required (10 digits +  NUL).  For the purposes of a Q&D code sample, I did not feel the need to create a constant identfier for it nor fine-tune the buffer size - I am not taking the interview. :)

    [quote user="MET"]
    I tend to find the term 'string' to be ambiguous and to mean any of std::string, char*, CString or QString depending on context, usually meaning the same type of string as in the surrounding code.  If you want a specific type you need to be specific.[/quote]

    This is exactly why the first solution to the first question was acceptable.  However, the second request was to eliminate dynamic memory allocation from the previous solution, and regardless of the type of string used in the first solution the second request narrows down the possible valid solutions.

    Peace!



  • [quote user="GuntherVB"]

    Imho this is a classic interviewer wtf, where the interviewer is a very technical person. The interviewer will want someone of his own level, thus he wants to invent some questions that only suitable applicants will be able to answer. However, in this process, the interviewer doesn't realise how rediculous and far-fetched his questions have become to make them "difficult".

     I'd be the same, but I still think it's an interviewer wtf.

    [/quote]

     I would agree, however it's not necessarily someone of the same level that the interviewer wants. It's someone with the same mind and thinking of the same things. The interviewer in this case want the interviewee to pretty much guess what the interviewer is actually looking for. It is very difficult to properly express a programming problem in spoken word due to the highly technical nature of programming. What one person says could mean something totally different to another. That's why I think that it's very important to be as explicit as possible when asking technical questions of this nature.

     



  • [quote user="RevEng"]
    I'm with the other guys on this one.  The answer you get can only be as good as the question.  Given certain states of thought and context surrounding it, this could very well be an ambiguous question, as it appears to have been in this case.  Your interviewee gave legitimate reasons for his methodology, and was actually accomplishing what he thought you were asking.  The problem was that what he thought and what you thought were different things.

    If you would have said afterwards, "Why not use a char array?" I'm sure he would have responded, "That would work too.  I didn't realize that's what you were asking."  If he instead said something like, "but that's dynamic too," then it's fair to say this was a WTF.
    [/quote]

    The issue was not with the first provided solution, it was with the second and subsequent ones.  Once the question became "OK, now do it without using dynamic memory allocation", that should have been clear enough.  How was that second request not good enough of a question?  How is that request ambiguous given the context of the previous solution?

    BTW: simply asking "why not use a char array" could have still resulted in the WTFee resorting to new/malloc(...).  If "do it without using dynamic memory allocation" was not clear, "why not use a char array" certainly is not, either.

    Any developer that hears "do not use dynamic memory allocation" and still thinks CString, std::basic_string, etc. is doing something wrong, or lacks a basic understanding of how things work.

    Additionally, part of the WTF is how in the last solution the WTFee added <font face="courier new,courier">static</font> and thought that is completely eliminated the allocation and resulted in no destruction..  Again, a lacking a basic understanding of how CString works.  Focus on the solutions provided and what is wrong with them instead of the questions.



  • [quote user="GuntherVB"]
    Imho this is a classic interviewer wtf, where the interviewer is a very technical person. The interviewer will want someone of his own level, thus he wants to invent some questions that only suitable applicants will be able to answer. However, in this process, the interviewer doesn't realise how rediculous and far-fetched his questions have become to make them "difficult".

    I'd be the same, but I still think it's an interviewer wtf.[/quote]

    Actually, this would be a classic interviewee WTF - not getting clarification on what is required.

    Again, can someone can please tell me how asking "OK, now do it without using dynamic memory allocation" is far-fetched or rediculous.  Note - just because you cannot think of a reason to avoid using dynamic memory allocation does not mean that those reasons do not exist (and are valid).

    Peace!



  • [quote user="jtwine"]

    We/I often deal with multithreaded implementations, where any pointless heap abuse introduces a unnecessary serialization point as well as additional time to do the allocation and deallocation. ...  In the interest of preventing a needless discussion on performance and if it is required or not, consider for this interview that performance is important and required, and the WTFee knew this.

    [/quote]

    Ah well, that really does change everything and your points make perfect sense.  It might be interesting to ask candidates if they can see any possible problems with using heap allocation for printing a string.  And then ask how they might work round them in a multithreaded environment.  In which case the static string suggestion would definitely be a big WTF.  Unless they added a mutex of course :)

    [quote user="jtwine"]

    Peace![/quote]

    I don't mean to sound like I am getting at you.  Thank you for an interesting post and peace to you too :) 



  • [quote user="GoatCheez"]

    #include <disclaimer>
    char GoatCheez[]="brillant!"

    [/quote]

    'Ya know - I always wanted to ask...  I thought that having a non-const pointer/array like this was technically incorrect because the constant string memory is supposed to be read-only?  I remember doing something like that in college and while it worked (on Unix) I was told that it was incorrect to do so...?

    Peace!



  • [quote user="jtwine"]The issue was not with the first provided solution, it was with the second and subsequent ones.  Once the question became "OK, now do it without using dynamic memory allocation", that should have been clear enough.  How was that second request not good enough of a question?  How is that request ambiguous given the context of the previous solution?[/quote]

    Technically, it wasn't clear at all. You asked him to allocate a string without using dynamic memory allocation which is by definition impossible. You could have asked for a buffer or an array of characters, but the word string implies an object construct.

    Was the interviewee at fault still? Yes, but not to the degree which you claimes he was WTF'd up.

     Also, if you want to critique the "correctness" of my sig, then you're missing the Paula reference. It's not supposed to be super-duper ultra clean perfect without any errors C. It's a Cish language version that makes fun of the Paula post. Jebus.
     



  • [quote user="jtwine"]

    [quote user="GoatCheez"]

    #include 
    char GoatCheez[]="brillant!"

    [/quote]

    'Ya know - I always wanted to ask...  I thought that having a non-const pointer/array like this was technically incorrect because the constant string memory is supposed to be read-only?  I remember doing something like that in college and while it worked (on Unix) I was told that it was incorrect to do so...?

    Peace!

    [/quote]

    This is implementation-defined, and most implementations have a command-line option to switch between read-only and read-write.



  • [quote user="jtwine"]

    [quote user="GoatCheez"]

    #include <disclaimer>
    char GoatCheez[]="brillant!"

    [/quote]

    'Ya know - I always wanted to ask...  I thought that having a non-const pointer/array like this was technically incorrect because the constant string memory is supposed to be read-only?  I remember doing something like that in college and while it worked (on Unix) I was told that it was incorrect to do so...?

    [/quote]

    This particular case is correct. char foo[] = "bar"; is a special case of shorthand for char foo[4] = {'b', 'a', 'r', '\0'}; - that's not a pointer assignment at all, it's an array definition with an initialiser.

    However, if it had said char *GoatCheez = "brilliant!";, then it would be platform-specific, but wrong on just about every platform you're likely to encounter. A double-quoted string is usually non-writeable (unless you explicitly asked the compiler to do otherwise), so later writing GoatCheez[0] = 'B' would generate an access violation. That's the case you're thinking of.

    With suitable warning arguments (not just -Wall on most versions), GCC will detect these errors. As always, if you want const-strictness, you have to ask the compiler for it. It is not the default behaviour (hysterical raisins).



  • I'm with the others here that think this isn't as big a WTF on the interviewee as you think it is, and much more a WTF on the interviewer than you're willing to admit.

     

                      	 &ldquo;I know that you believe you understand what you think I said, but I&#39;m not sure you realize that what you heard is not what I meant.&rdquo;--Robert McCloskey</h3><p>&nbsp;</p><p>I think this applies aptly.&nbsp;</p><p>&nbsp;</p>



  • [quote user="GoatCheez"]

    [quote user="jtwine"]The issue was not with the first provided solution, it was with the second and subsequent ones.  Once the question became "OK, now do it without using dynamic memory allocation", that should have been clear enough.  How was that second request not good enough of a question?  How is that request ambiguous given the context of the previous solution?[/quote]

    Technically, it wasn't clear at all. You asked him to allocate a string without using dynamic memory allocation which is by definition impossible. You could have asked for a buffer or an array of characters, but the word string implies an object construct. [/quote]

    Sorry, I must be missing something...

    Interviewer: Please show how you would convert an int value to a string.
    [...]
    Interviewer: OK, now do it without using dynamic memory allocation.

    I am missing where the interviewer asked the WTFee to allocate a string.  Implying string is equal to (dynamically allocated) string object is an insult to old-school C developers, who have been manipulating "strings" long before C++.  (And there is such a thing as a string objects that manipulate stack-based memory; I have written one, and yes, it is still useful.)  So "technically", no one asked the WTFee to allocate anything.  If that is the assumption, then again, asking for clarification never hurts.

    [quote user="GoatCheez"]
    Also, if you want to critique the "correctness" of my sig, then you're missing the Paula reference. It's not supposed to be super-duper ultra clean perfect without any errors C. It's a Cish language version that makes fun of the Paula post. Jebus.[/quote]

    Easy, son...  Read my post about that again (and again, and again...) until it becomes clear that it was not a critique, it was a question and an observation.  An observation is not a critique.  Nor did I indicate or ask anyone to presume that it was supposed to be "super-duper ultra clean perfect without any errors C".  Nevertheless, asuffield corrected answered my question regarding it.  A good thing to learn, ya know...  Answering directed questions...  Paula post?  No idea, but as my signature indicates, that is OK - I do not have to know what it is about, only you do. :)

    Peace!



  • [quote user="Rodyland"]

    I'm with the others here that think this isn't as big a WTF on the interviewee as you think it is, and much more a WTF on the interviewer than you're willing to admit.

    “I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant.”--Robert McCloskey

    I think this applies aptly. 

    [/quote]

    Again, there is more WTFness than just the way the question was worded, and again:

    Interviewer: Please show how you would convert an int value to a string.
    [...]
    Interviewer: OK, now do it without using dynamic memory allocation.

    The first request was open-ended, yes (intentionally), and the second request had a more precise requirement.  What is the hard part to understand there?  About three people now have suggested that the above was not clear, but I have yet to read exactly why.  If this is a interviewer WTF then please explain to the audience exactly what is wrong with one or both of those two requests?

    Peace!



  • Oh, this is easy! Just put quotes around the number!

    char string[] = "13";

    Brillant!



  • [quote user="HeroreV"] 
    Oh, this is easy! Just put quotes around the number!
    char string[] = "13";
    Brillant![/quote]

    Nice one! :P  Not exactly what was wanted but it does answer the request in a very straightforward way...

    Peace!



  • My suggested rephrasing of the second question would be "OK, now please show how you would prematurely optimise this routine by making potentially-unnecessary use of an unsafe language feature that is notorious for being directly responsible for more major security flaws than anything else in the history of programming."

    Seriously, why was the interviewer asking this?  He could at least have asked the interviewee to assume that profiling had identified the construction and deconstruction of a CString object as a bottleneck.  (Performance-critical programming is about identifying and fixing bottlenecks, not about premature optimisation or about introducing arbitrary rules to forbid safe code.)



  • [quote user="Iago"]
    My suggested rephrasing of the second question would be "OK, now please show how you would prematurely optimise this routine by making potentially-unnecessary use of an unsafe language feature that is notorious for being directly responsible for more major security flaws than anything else in the history of programming."
    Seriously, why was the interviewer asking this?  He could at least have asked the interviewee to assume that profiling had identified the construction and deconstruction of a CString object as a bottleneck.  (Performance-critical programming is about identifying and fixing bottlenecks, not about premature optimisation or about introducing arbitrary rules to forbid safe code.)[/quote]

    Interesting - in my experience, "unsafe language features" like pointers (like those used to manage dynamically allocated memory) tend to be a source of more errors...  (Also, IME, language features are rarely directly responsible for program failures, it is how they are used/misused by inexperienced and/or lazy developers doing things like not doing simple pointer checks, verifying buffer lengths, etc.)

    Use of a CString is far from safe (or efficient) - observant developers will note the lack of any exception handling, and since any CString action that results in allocation is a possible exception point...  (Before someone argues that this is sample code, I know that.  Then it is also incorrect to play the premature optimization card as well.)

    Construction and destruction of a CString object not so heavy - you can create an empty CString, do nothing with it, and later destroy it without any substantial impact.  Actually using it for anything that can result in dynamic memory management is where time is used up, not to mention how <font face="courier new,courier">CString::Format(...)</font> works by having to build the formatted string twice.  (So if you ever see that plain CString construction and destruction is a bottleneck, it is either wrong, or due to serious misuse of CString.)  Again, knowing how things work is important.

    As was previously posted, this does not fall under the scenario of "premature optimization".  Again, for the purposes of the interview, performance was a concern for the position.  Someone else also mentioned the possibility of coding on a platform without a normal heap, or even without MFC support.  So (blindly) jumping to the premature optimization argument is in itself, premature.

    I myself have asked the first request just to see if a developer is aware of how CString works or not.   You would be surprised how many people do not know that the CString allocates memory behind the scenes(!), let alone how the Plex-based allocators work, or how <font face="courier new,courier">CString::Format(...)</font> works.  When you have a developer writing MFC code like this:

    <font face="courier new,courier">CString sWinText = _T( "The new window text" );</font>

    <font face="courier new,courier">m_ecEditCtrl.SetWindowText( sWinText );</font>

    That is demonstrative of a serious lack of how things work, IMHO.  I have even had the occasional developer argue that it is better to encapsulate all strings(!), not realizing that encapsulation without benefit is a waste (on many levels).

    However, you are entitled to your opinion...  Just be sure that you do not present it as fact.

    Peace!



  • [quote user="jtwine"][quote user="GoatCheez"]

    [quote user="jtwine"]The issue was not with the first provided solution, it was with the second and subsequent ones.  Once the question became "OK, now do it without using dynamic memory allocation", that should have been clear enough.  How was that second request not good enough of a question?  How is that request ambiguous given the context of the previous solution?[/quote]

    Technically, it wasn't clear at all. You asked him to allocate a string without using dynamic memory allocation which is by definition impossible. You could have asked for a buffer or an array of characters, but the word string implies an object construct. [/quote]

    Sorry, I must be missing something...

    Interviewer: Please show how you would convert an int value to a string.
    [...]
    Interviewer: OK, now do it without using dynamic memory allocation.

    I am missing where the interviewer asked the WTFee to allocate a string.  Implying string is equal to (dynamically allocated) string object is an insult to old-school C developers, who have been manipulating "strings" long before C++.  (And there is such a thing as a string objects that manipulate stack-based memory; I have written one, and yes, it is still useful.)  So "technically", no one asked the WTFee to allocate anything.  If that is the assumption, then again, asking for clarification never hurts.

    [/quote]

    Ten years ago it would have been an insult. This is 2006, almost 2007. The times change, as does terminology. This is especially true of an academic environment. Unless you specify otherwise, saying string usually implies a string object from some API. This is especially true outside of C and C++, but since we are talking about those languages specifically, uh.... yeah... lol.....

    I'd love to sit and respond all day, but I have actual work to do. There's not a poster yet that doesn't agree that not only was the interviewee not as WTF'd up as you portray, but the interviewer could have clarified what they were asking as well.

    Engineers are not the best at communication... Why do you think that they play with numbers and logic all day instead of writing novels?

    mmmmmm numbers......
     

     

    [quote user="jtwine"]

    [quote user="GoatCheez"]
    Also, if you want
    to critique the "correctness" of my sig, then you're missing the Paula
    reference. It's not supposed to be super-duper ultra clean perfect
    without any errors C. It's a Cish language version that makes fun of
    the Paula post. Jebus.[/quote]

    Easy, son...  Read my post about
    that again (and again, and again...) until it becomes clear that it was
    not a critique, it was a question and an observation.  An observation is not a critique.  Nor did I indicate or ask anyone to presume that it was supposed to be "super-duper ultra clean perfect without any errors C".  Nevertheless, asuffield corrected answered my question regarding it.  A good thing to learn, ya know...  Answering directed questions...  Paula post?  No idea, but as my signature indicates, that is OK - I do not have to know what it is about, only you do. :)

    Peace!

    [/quote]

    Granted, you didn't ask anyone to presume that it was "perfect C", however saying that you were not trying to critique is just plain not true. You say "I thought that having a non-const pointer/array like this was technically incorrect" and "I remember doing something like that in college and while it worked (on Unix) I was told that it was incorrect to do so...?". You refer directly to my sig and then comment that you thought the code in it is incorrect. I'd like to know how that's not a critique.

    Frankly, I shouldn't give a crap. For some reason though, I do. I don't know why and don't care to explain what I don't know so I'll leave it at that...



  • [quote user="GoatCheez"]I'd love to sit and respond all day, but I have actual work to do. There's not a poster yet that doesn't agree that not only was the interviewee not as WTF'd up as you portray, but the interviewer could have clarified what they were asking as well.[/quote]We all have work - some of us are good enough to get stuff done on time and still find time to point out how stupid some things are. :)  Not having anyone agree with the underlying WTFness of the post is OK - I already know what the real problem is, I was just presenting it to others to see reactions - it helps me further fine-tune to be able to avoid certain developers.[quote user="GoatCheez"]Granted, you didn't ask anyone to presume that it was "perfect C", however saying that you were not trying to critique is just plain not true. You say "I thought that having a non-const pointer/array like this was technically incorrect" and "I remember doing something like that in college and while it worked (on Unix) I was told that it was incorrect to do so...?". You refer directly to my sig and then comment that <font color="#cc3300">you thought the code in it is incorrect</font>. I'd like to know how that's not a critique.[/quote]A critical statement is along the lines of "that is wrong; fix it".  Putting forth that one thinks that something is wrong is am observation.  Although I can see how someone might incorrectly take the reference to my college experience and treat it as projection...  Fear not, I was incorrect in that what I thought was incorrect was not.  Nothing wrong, nothing to care about. :)

    Peace!



  • I hate interview questions like this. The interviewer says "Write me a function that does this", but what he really means is "I'm thinking of code that does this - guess what it is".

    Well, if I've never encountered this particular problem, I'm not going to write the code you're thinking about. The only way that will happen is if I've anticipated your question, looked it up on the internet, and memorised the correct answer - which doesn't exactly make me the candidate you want, does it? If it does, I don't want the job.

    The "static CString" answer to this question is definitely a WTF, but if I were the interviewer, it would get you the job.

     



  • [quote user="jtwine"]

    Again, there is more WTFness than just the way the question was worded, and again:

    Interviewer: Please show how you would convert an int value to a string.
    [...]
    Interviewer: OK, now do it without using dynamic memory allocation.

    The first request was open-ended, yes (intentionally), and the second request had a more precise requirement.  What is the hard part to understand there?  About three people now have suggested that the above was not clear, but I have yet to read exactly why.  If this is a interviewer WTF then please explain to the audience exactly what is wrong with one or both of those two requests?

    Peace!

    [/quote]

     

    OK, I'll bite and tell you why I think your questions are at least partly responsible for what you consider to be the WTFiness of the responses.


    I'm going to try and describe it in general terms rather than specifics, as I think it should be easier to understand the underlying problems.

    I think it comes down to the assumptions you are making versus the assumptions the interviewee is making, few of which have been stated in your questions, although you have clarified your thinking somewhat throughout this thread.

    It seems to me you've made two assumptions that directly lead to the perceived WTFs:

    - The interviewee knows that CString always allocates memory on the heap

    - The interviewee knows how CString works 

    - The interviewee knows about standard C char* and sprintf functions


    You've also made some other assumptions:

    - The interviewee knows the difference between heap and stack memory

    - The interviewee knows that heap memory allocation has a performance hit

    - The interviewee knows that you want to stop heap allocation because of performance problems (now I'm only assuming this is the 'reason' you had in mind when you wrote that question) 

     Now, as has been mentioned above, today's many of today's University Java Factories don't teach much in the way of low level memory stuff, and certainly don't teach C standard libraries.  If you wanted to test if the interviewee knew that CString ALWAYS allocates memory on the heap or how CString::Format works then you should have asked that question directly.  If you wanted to test if the interviewee actually understands the difference between dyanmic/heap memory and static/stack memory then you should have asked that directly.  If you wanted to test if the interviewee knew C libraries then you should have asked that directly.  If you wanted to test if the interviewee understood the inherent performance hit caused by dynamic memory allocation and deallocation then you should have asked directly.  If you wanted to know if the interviewee understood the complexities of programming in a real-time or memory-limited or performance-constrained environment then you should have asked that directly.

     

    What you did is roll all of those assumptions - assumptions about the interviewee's knowledge as well as assumptions about the problem you designed - into a single question with a pre-conceived notion of what the 'right' answer is, without giving the interviewee the benefit of the assumptions that were underlying your solution to the problem. 

     

    Now while I agree that there is a degree of WTF in the interviewee's responses, for me the bigger WTF is you and your questions.

    You obviously can't see any of this, so I'll stop trying to explain now.

     

     



  • [quote user="Rodyland"]OK, I'll bite and tell you why I think your questions are at least partly responsible for what you consider to be the WTFiness of the responses.
    I'm going to try and describe it in general terms rather than specifics, as I think it should be easier to understand the underlying problems.
    I think it comes down to the assumptions you are making versus the assumptions the interviewee is making, few of which have been stated in your questions, although you have clarified your thinking somewhat throughout this thread.
    It seems to me you've made two assumptions that directly lead to the perceived WTFs:

    - The interviewee knows that CString always allocates memory on the heap
    - The interviewee knows how CString works 
    - The interviewee knows about standard C char* and sprintf functions

    You've also made some other assumptions:

    - The interviewee knows the difference between heap and stack memory
    - The interviewee knows that heap memory allocation has a performance hit
    - The interviewee knows that you want to stop heap allocation because of performance problems (now I'm only assuming this is the 'reason' you had in mind when you wrote that question)[/quote]  This is a good point.  Yes, these are assumptions made by the interviewer - and completely appropriate based on the position (i.e. the details of the position and the experience requirements for it).  Although I admit that I did not provide a lot of color by including things like the position details, the universal assumption (read: assume I know something that you do not) should have been applied which would have resulted in assuming that the interview scenario was appropriate for these kinds of questions.  Suffice it is to say that the position was for a more senior C/C++ developer with high-performance TP experience.  For any "senior" C/C++ position, I believe that the first four assumptions are completely valid ones to have, would you not agree?  The WTFee using CString in the first solution was of his/her own volition, so the interviewer assuming that the WTFee had an in-depth knowledge of CString (and MFC, for that matter) is also correct - why offer up things that you know nothing about, unless you are really screwed and should fail the interview for that fact alone.

    However, I believe that the last two do not apply - regardless of the WTFee knowing that heap access takes a performance or not, or knowing the reason(s) why the interviewer asked to provide a solution without heap involvement or not, they were still provided with a simple request to remove heap involvement from the solution.  The reasons why they need to remove it do not matter - knowing why is not always a requirement.[quote user="Rodyland"]Now, as has been mentioned above, today's many of today's University Java Factories don't teach much in the way of low level memory stuff, and certainly don't teach C standard libraries.  If you wanted to test if the interviewee knew that CString ALWAYS allocates memory on the heap or how CString::Format works then you should have asked that question directly.  If you wanted to test if the interviewee actually understands the difference between dynamic/heap memory and static/stack memory then you should have asked that directly.  If you wanted to test if the interviewee knew C libraries then you should have asked that directly.  If you wanted to test if the interviewee understood the inherent performance hit caused by dynamic memory allocation and deallocation then you should have asked directly.  If you wanted to know if the interviewee understood the complexities of programming in a real-time or memory-limited or performance-constrained environment then you should have asked that directly.[/quote]

    Also good points - if that was the intent of this particular part of the interview, that is how it would have been done (other than the performance part - that was part of the position description).  The WTFee brought CString into the solution, they were not prompted to do so.

    Understand that my intent of posting this particular scenario was to highlight at least two WTFs from the WTFee: [1] lack of knowledge that CString is heap-based and [2] that the WTFee thought that the <font face="courier new,courier">static</font> keyword would have prevented dynamic memory allocation when used with a CString object.  Personally, I think that the first one is more of a WTF than anything else - to me, that is the same as not knowing that <font face="courier new,courier">malloc(...) </font>involves dynamically allocated memory!  But that is just me, and I expect a lot. :)

    It appears that I am going to have to provide a bit of forcing to ensure the point gets across next time.

    Peace!



  • Probably doesn't help that you were interviewing a decidedly non-senior developer for a senior position.  :)

     

    Thanks for explaining everything - your reaction makes much more sense in the whole context. 

     

     


Log in to reply