• tanisha (unregistered) in reply to Ytram
    Ytram:
    ...and get the trick questions wrong, as did most people...

    What's the point of asking a trick question? Is it so you can see how people deal with trick requirements? Or trick designs?

    The point is, that in Israel , where the post came from, the idea of an interview is to prove to the candidate that the interviewer is smarter than him/her. You think I'm kidding, but I'm not. In general, job candidates are considered scum of the earth and treated as such. There are entire web sites and discussion groups dedicated to this. People even came up with protest posters. Regretably, it's all in Herbrew.

  • (cs) in reply to tanisha
    tanisha:
    Regretably, it's all in Herbrew.
    Well, at least Israel is starting to get with the Women's Lib thing.
  • (cs) in reply to Jason
    Jason:
    gabba:
    Two excellent examples of WTFs on the part of those conducting the interviews. Asking people to criticize their own work is just stupid. It's your job to find out what's wrong with them; don't ask them to volunteer that information. And asking people to find flaws in some artificial "Where's Waldo" bad code is equally stupid. Give them a realistic problem and ask them to solve it, already.

    Wrong. Simply flat out wrong. Examining your past performance to see where you went wrong and what you could have done better is the most critical component of self improvement. Nobody is perfect and nobody ever writes perfect code. Even well-written code can be improved on. To think otherwise leads to egos we all hate to work with as well as stagnation because you never think you have anything to improve on.

    I know I wouldn't want to work with someone who is not capable of self-reflection and analysis. Yes, this should only be a part of an interview that also includes realistic problems for them to solve but it should NEVER be left out.

    So, what you are saying is that you are unwilling to entertain the idea that maybe someone could have enough time, insight, or perhaps even the assistance of a good enough team, in a past project that would lead to a well designed and executed implementation of which he has no regrets?

    If you only look for mediocrity in your developers, that's probably what you'll find.

    -dZ.
    
  • German (unregistered) in reply to dpm
    dpm:
    Not even the dumbest moron I've been forced to work against^H^H^H^H^Hwith would have actually deleted the source, but I can't imagine what he might have been referring to.

    The dumbest morons need their source code so their bugs can be fixed. However, this guy made no mistakes, and his applications were made in the best possible way. In that case, source code is a waste of disk space. Don't try it unless you have independently abilities.

  • Dave Grammar (unregistered) in reply to Russ

    A compiler error, I hope.

  • what (unregistered) in reply to David Schwartz

    If she said "I don't know what std:: is" that's a whole other can of worms than, "I'm not familiar with this namespace, so it may or may not be wrong since I don't have the std:: namespace in the example code."

  • Anonymous (unregistered) in reply to DZ-Jay
    DZ-Jay:
    So, what you are saying is that you are unwilling to entertain the idea that *maybe* someone could have enough time, insight, or perhaps even the assistance of a good enough team, in a past project that would lead to a well designed and executed implementation of which he has no regrets?
    Then the candidate shall explain why he/she thinks it was a complete success, e.g. which pitfalls they moved around by careful planning.

    Apart from that, it's highly unlikely that said candidate delivered perfect code from the first time he/she touched a keyboard, so there is bound to be some code that he/she is no more confident with today.

  • (cs)

    Here's a trick question. Observe the following snippet, which is supposed to set every element of the array to 42. N is a positive integer.

    short a[N];
    
    for (short * p = a + N - 1; p >= a; --p)
      *p = 42;
    

    This code, besides being literally backwards, looks normal, right? Right?

    1. Why is this code wrong from the theoretical point of view? Bonus points for citing relevant portion of the standard.
    2. Name a real scenario in which the code would b0rk.
    3. How would you do the task (that is, fill an array with 42's) in C? In C++?
  • (cs) in reply to OedipusPrime
    Russ:
    It is a bit of a trick question, as some junior developers might not know the difference between

    if (x==5)

    and

    if (x=5)

    This is why you always write comparison statements against literals:

    if(5 == x){...}

    Very hard to get incorrect assignment operations wrong written this way. So hard, in fact, it would require discovery of a compiler that doesn't work properly.

  • (cs) in reply to too_many_usernames
    too_many_usernames:
    Russ:
    It is a bit of a trick question, as some junior developers might not know the difference between

    if (x==5)

    and

    if (x=5)

    This is why you always write comparison statements against literals:

    if(5 == x){...}

    Very hard to get incorrect assignment operations wrong written this way. So hard, in fact, it would require discovery of a compiler that doesn't work properly.

    I believe "FORTRAN" is the word you are looking for there ;-).

  • Walleye (unregistered) in reply to Disgruntled DBA
    Disgruntled DBA:
    too_many_usernames:
    Russ:
    It is a bit of a trick question, as some junior developers might not know the difference between

    if (x==5)

    and

    if (x=5)

    This is why you always write comparison statements against literals:

    if(5 == x){...}

    Very hard to get incorrect assignment operations wrong written this way. So hard, in fact, it would require discovery of a compiler that doesn't work properly.

    I believe "FORTRAN" is the word you are looking for there ;-).

    Brillant!

  • Some (unregistered) in reply to Spectre
    Spectre:
    Here's a trick question. Observe the following snippet, which is supposed to set every element of the array to 42. N is a positive integer.
    short a[N];
    
    for (short * p = a + N - 1; p >= a; --p)
      *p = 42;
    

    This code, besides being literally backwards, looks normal, right? Right?

    1. Why is this code wrong from the theoretical point of view? Bonus points for citing relevant portion of the standard.
    2. Name a real scenario in which the code would b0rk.
    3. How would you do the task (that is, fill an array with 42's) in C? In C++?

    At the last loop p will run outside the "a" momory-section and will cause Memory Access error...

  • diaphanein (unregistered) in reply to FredSaw

    [quote user="FredSawWe (at my company) don't do "work from home" here... at least, not for pay, although we do all have VPN access (in the event of a late-night weekend emergency, don'tcha see). And I'll be damned if any of us could get away with going down to the (American equivalent of a) pub on the clock. Perhaps I should consider moving to the UK...[/quote]

    Depends on who/where you work. Myself and some of my coworkers routinely go to the pub (and yes, I'm an American, in America) and throw down a few pints. My director knows, too. As he told us one day, "I don't care if you go out for a few drinks, but answer your fucking phone." To which I responded, I would have had it rang, and proceeded to show him that I had no missed calls.

    Oh, and as for being on the clock, if you're an exempt, salaried employee - you're always on the clock.

  • (cs) in reply to snoofle
    snoofle:
    morry:
    I'd like to come up with some trick questions to ask a company in an interview some time.
    For any established organization: {...}
    That's a good list, but the one I always ask is "what do you use for source code control?"

    There are some good answers and some poor ones, depending on the scale of the projects involved. But the two that always raise red flags are "none" and "we use a system we developed in-house". Danger Will Programmer!

  • (cs) in reply to Some
    Some:
    At the last loop p will run outside the "a" momory-section and will cause Memory Access error...

    No, because we don't dereference it.

  • diaphanein (unregistered) in reply to Spectre
    Spectre:
    Some:
    At the last loop p will run outside the "a" momory-section and will cause Memory Access error...

    No, because we don't dereference it.

    You do if a==0. Your loop will also never terminate in that case (at least not without an access violation/segfault). That being said, it should never occur as address "0x0" is generally reserved.

    Instead of comparing p >= a, I would suggest the following:

    short a[N]; for (short *p = a + N - 1, *end = a - 1; p != end; --p) *p = 42;

    This is essentially how rbegin/rend work in STL. rend symbolically points to the element before the beginning of a container.

  • Manic Mailman (unregistered) in reply to Spectre
    Spectre:
    Here's a trick question. Observe the following snippet, which is supposed to set every element of the array to 42. N is a positive integer.
    short a[N];
    
    for (short * p = a + N - 1; p >= a; --p)
      *p = 42;
    

    This code, besides being literally backwards, looks normal, right? Right?

    1. Why is this code wrong from the theoretical point of view? Bonus points for citing relevant portion of the standard.

    2. Name a real scenario in which the code would b0rk.

    3. How would you do the task (that is, fill an array with 42's) in C? In C++?

    • The problem is that --p is undefined when p == &a[0]. The relevant portion of the standard (ISO/IEC 9899:1999) is 6.5.6 Paragraph 8. Other versions of the standard (C or C++) have similar paragraphs, just with different numbering. I admit I had to look up the section in the standard, so I wouldn't have gotten this in the interview.

    • I suppose some scenarios when this code would b0rk is when (&a[0] < sizeof( short)). Not too likely, but could maybe happen if you're on a architecture where alignment issues don't matter and aren't taken into account by the compiler and the short array happens to be located at address 1. Or you could be working on an architecture where the compiler can locate objects at address 0 - just because the NULL pointer is represented by 0 in C source code does not mean that address 0 is off limits to an implementation. The only restriction is that the null pointer constant cannot compare equal to a pointer to any object or function - a compiler is free to do some dirty work behind the scenes so that this holds true for pointers to objects or functions whose bits happen to be all zeros (not that I'm aware of any actual compiler that does this).

    • here's one way to init the array that I believe is correct

        
        short a[N];
        for (size_t i = 0; i < N; ++i) {
            a[i] = 42;
        }
    

    I'm not sure what might be different in C except that the declaration for i would have to be located prior to the 'for' statement.

    Do I get the job?

  • James Schend (unregistered) in reply to WhiskeyJack
    WhiskeyJack:
    So my question for the interviewers is, in situations like these, why do you have to keep stringing along the candidate, say "we'll call you if you get the position", etc., even though in their minds they've already cemented their decision as a 100% no?

    With candidates like these you should be able to just say "Well, um, that's not really what we're looking for, so thank you for your time". Get it over with quickly, let the interview candidate know that he's done here, everyone moves on.

    I think most IT companies do do this. At least, I've been told several times when interviewing that if the candidate is a clear thumbs down to simply send them home after my segment of the interview and save everyone.

    The problem I think is that most people want to get second opinions, thinking that a later interviewer might have a different experience. Despite having that policy, I've only witnessed it happen once the years I've been working here.

  • LEGO (unregistered) in reply to FredSaw
    FredSaw:
    Ytram:
    ...and get the trick questions wrong, as did most people...
    What's the point of asking a trick question? Is it so you can see how people deal with trick requirements? Or trick designs?
    Perhaps, to see if/how they turn a trick?

    Don't interviews of that nature consist solely of negotiating a "rate"?

  • Anonymously Yours (unregistered)
    "besides, I couldn't go back and rework a project anyway. As soon as I've finished and installed the application, I delete the code. I like to start every project with a clean slate, I don't believe in copying from what I did previously. I just start it over brand-new!"
    Imagine if he was an automotive engineer. "Besides, I couldn't go back and change the operations anyways. As soon as the first car rolled out I burned down the factory. I like to start every job with a clean slate and a new mark on my criminal record."

    Perhaps he was one of the contractors who first answered the Call of Codethulu...

  • Anonymously Yours (unregistered) in reply to DZ-Jay
    DZ-Jay:
    So, what you are saying is that you are unwilling to entertain the idea that *maybe* someone could have enough time, insight, or perhaps even the assistance of a good enough team, in a past project that would lead to a well designed and executed implementation of which he has no regrets?

    If you only look for mediocrity in your developers, that's probably what you'll find.

    -dZ.</div></BLOCKQUOTE>What use is a developer who's never worked in a less-than-ideal environment?
    
  • SomeCoder (unregistered) in reply to Manic Mailman
    Manic Mailman:
    3) here's one way to init the array that I believe is correct
        
        short a[N];
        for (size_t i = 0; i < N; ++i) {
            a[i] = 42;
        }
    

    I'm not sure what might be different in C except that the declaration for i would have to be located prior to the 'for' statement.

    Do I get the job?

    I think you're right... it's been a while since I've done C but I believe you'd have to say:

        
        short a[N];
        size_t i = 0;
        for (; i < N; ++i) {
            a[i] = 42;
        }
    

    Again, it's been a while so I could be wrong.

  • (cs) in reply to dpm
    dpm:
    I always ask is "what do you use for source code control?"

    There are some good answers and some poor ones, depending on the scale of the projects involved. But the two that always raise red flags are "none" and "we use a system we developed in-house". Danger Will Programmer!

    What about RCS for a decent sized project? After years of CVS and Subversion, I get to use RCS... is it wrong that after a few months I actually like its rawness? (Don't worry, it's getting ditched soon).

  • (cs) in reply to Manic Mailman

    Damn, I didn't expect this one to be solved so quickly. 8=]

    Manic Mailman:
    1) The problem is that --p is undefined when p == &a[0]. The relevant portion of the standard (ISO/IEC 9899:1999) is 6.5.6 Paragraph 8. Other versions of the standard (C or C++) have similar paragraphs, just with different numbering. I admit I had to look up the section in the standard, so I wouldn't have gotten this in the interview.

    Bingo.

    2) I suppose some scenarios when this code would b0rk is when (&a[0] < sizeof( short)).

    You mean sizeof(short *).

    Not too likely, but could maybe happen if you're on a architecture where alignment issues don't matter and aren't taken into account by the compiler and the short array happens to be located at address 1. Or you could be working on an architecture where the compiler can locate objects at address 0 - just because the NULL pointer is represented by 0 in C source code does not mean that address 0 is off limits to an implementation. The only restriction is that the null pointer constant cannot compare equal to a pointer to any object or function - a compiler is free to do some dirty work behind the scenes so that this holds true for pointers to objects or functions whose bits happen to be all zeros (not that I'm aware of any actual compiler that does this).

    Agreed. And there is a real-world example. Hint: the system I'm talking about was widespread about, say, 15 years ago.

    3) here's one way to init the array that I believe is correct
        
        short a[N];
        for (size_t i = 0; i < N; ++i) {
            a[i] = 42;
        }
    

    I'm not sure what might be different in C except that the declaration for i would have to be located prior to the 'for' statement.

    Yeah, that's obviously correct; but for C++ I was hoping for a more standard library-esque solution. ;-)

    Do I get the job?

    Uhm, yeah, sure! As soon as I start my own company, that is.

  • Some (unregistered)

    Actually integer positive means that the value is >0.

  • (cs) in reply to Some
    Some:
    Actually integer positive means that the value is >0.
    Only if you don't live in Bizarro World.

    Which is basically where the rest of us live.

  • Jay (unregistered)

    I thought the "what would you go back and re-work" was an excellent interview question. When I read it I immediately started thinking of how I would answer it. If I was interviewing someone and used that question and the candidate replied that he had never made a mistake, that every project he had ever worked on had been perfect, the best possible interpretation I could put on it would be that he was nervous.

    I think it's quite different from the lame question I've gotten in numerious interviews, "What is your greatest weakness?" Do they really expect me to volunteer some serious character flaw? The last time someone asked me that, I got pensive and said, "Let's see, I think I've put prison behind me, and the drugs don't really interfere with my work ..." Then I laughed and brushed it off.

  • Numeromancer (unregistered) in reply to diaphanein

    FAIL!

  • Bob N Freely (unregistered)

    To be fair, the bullet point stated "wit minor errors." Instaed of "wit zero errors."

  • WW (unregistered) in reply to Russ
    Russ:
    Russ:
    diaphanein:
    Russ:
    Ytram:
    ...and get the trick questions wrong, as did most people...

    What's the point of asking a trick question? Is it so you can see how people deal with trick requirements? Or trick designs?

    No so people know how to find bugs in code. For example

    x=3; if (x=5) cout<<"5"; else cout<<"not 5";

    What is the output?

    1. Next?

    I really hope that was sarcasm

    Actually my bad.. haven't had my morning coffee yet.

    The answer should be 5. It is a bit of a trick question, as some junior developers might not know the difference between

    if (x==5)

    and

    if (x=5)

    If only it was just junior developers. I've made that same damnfool mistake in my own code mumble times, in more than one language.

  • fist-poster (unregistered) in reply to UpNDown
    UpNDown:
    Russ:
    No so people know how to find bugs in code. For example

    x=3 if (x=5) cout<<"5"; else cout<<"not 5";

    What is the output?

    The correct answer, of course, is "What would you like it to be?"

    After all, the type of x is not given. So I can declare x to be of type MyClass, which happens to have overridden operators that let me control this flow however I want.

    Now, my c++ is rusty, so I'll not attempt to give an example, I'm sure someone else is up to it.

    Ok: #include <iostream> using std::cout;

    struct False { False() {} False(int) {} operator bool() const { return false; } };

    int main() { False x; x=3; if (x=5) cout<<"5"; else cout<<"not 5"; } Do I get the job?

  • (cs) in reply to Spectre
    Spectre:
    Manic Mailman:
    Not too likely, but could maybe happen if you're on a architecture where alignment issues don't matter and aren't taken into account by the compiler and the short array happens to be located at address 1. Or you could be working on an architecture where the compiler can locate objects at address 0 - just because the NULL pointer is represented by 0 in C source code does not mean that address 0 is off limits to an implementation. The only restriction is that the null pointer constant cannot compare equal to a pointer to any object or function - a compiler is free to do some dirty work behind the scenes so that this holds true for pointers to objects or functions whose bits happen to be all zeros (not that I'm aware of any actual compiler that does this).

    Agreed. And there is a real-world example. Hint: the system I'm talking about was widespread about, say, 15 years ago.

    Good ol' x86 segmented memory. That was exciting to program for.

  • Jason (unregistered) in reply to DZ-Jay
    DZ-Jay:
    Jason:
    gabba:
    Two excellent examples of WTFs on the part of those conducting the interviews. Asking people to criticize their own work is just stupid. It's your job to find out what's wrong with them; don't ask them to volunteer that information. And asking people to find flaws in some artificial "Where's Waldo" bad code is equally stupid. Give them a realistic problem and ask them to solve it, already.

    Wrong. Simply flat out wrong. Examining your past performance to see where you went wrong and what you could have done better is the most critical component of self improvement. Nobody is perfect and nobody ever writes perfect code. Even well-written code can be improved on. To think otherwise leads to egos we all hate to work with as well as stagnation because you never think you have anything to improve on.

    I know I wouldn't want to work with someone who is not capable of self-reflection and analysis. Yes, this should only be a part of an interview that also includes realistic problems for them to solve but it should NEVER be left out.

    So, what you are saying is that you are unwilling to entertain the idea that maybe someone could have enough time, insight, or perhaps even the assistance of a good enough team, in a past project that would lead to a well designed and executed implementation of which he has no regrets?

    If you only look for mediocrity in your developers, that's probably what you'll find.

    -dZ.</div></BLOCKQUOTE>
    

    I don't believe in perfection. I do believe in striving for it because that's how we get better. Even if you are completely satisfied with a well designed and executed implementation there is probably something which could have been done even better. Especially when, as in the question, you include new insights or technology that experience and time has given. It's not bad to write imperfect code. We're humans, we're imperfect and imperfect code can still be great and work with no problems.

    Additionally, the question looks back over the programmer's whole body of experience. If someone honestly thinks they never wrote some code that needed improvement I don't want to work with them.

    Even those born with great aptitude must develop their skill by learning from many failures.

  • Gus (unregistered)

    "Exclusive Research Skill with Details"? Is that like "Friends with Benefits" or a "Massage with Happy Ending"?

  • corey (unregistered) in reply to UpNDown

    You are all so silly! No need to add a semicolon. You are all forgetting that this is just a code fragment (notice how x isn't defined). The correct code looks like this (with the missing part in red):

    #include <iostream> using namespace std; void main () { int x;

    #define if ;if x=3 if (x=5) cout<<"5"; else cout<<"not 5"; #undef if }

    which will of course output "5" as expected. Sheesh. Doesn't anyone teach the preprocessor anymore? :-P

  • Ken Sykora (unregistered)

    The last one's a little sketch...

    I'm all for having programmers that come in for interviews write code, but any good interviewer/technology manager should know that a good programmer doesn't need to know the language you use at your organization, and they shouldn't be held to the (exact) syntax. A good programmer has many other great skills (logic!!!, general software design, general debugging skills, knowledge of algorithms/runtimes, the inner workers of managed languages, pointers, etc.) will become fluent and an expert in a language/framework in a matter of weeks/months and finding someone that is fluent in the language AND has all the other great skills of being a good programmer is just an added bonus.

    But to be fair, if the interviewee claims to have Excellent knowledge of C++, has used it everyday in the last year, and claims to be able to teach C++ to a 4-year-old in 2 hours, you would hope they know what std:: represents.

  • (cs) in reply to snoofle

    It is a fact of California labor law (and probably other US states -- haven't checked) that, if you're an "exempt" employee (aka "salaried," meaning you don't get paid by the hour, and thus don't get overtime pay), then the company cannot refuse to pay you your regular salary for any day where you did at least some work. That's right; if you're salaried, then flextime comes with the job!

    The company can still terminate employment for cause (or not), of course, but if the company attempts to order overtime, then the company has two choices:

    1. realize that not everyone will work the overtime or
    2. convert employees to non-exempt, and pay overtime

    Also note that there are specific requirements for employees to count as "exempt" and thus not get overtime pay, and ALL of those requirements must be fulfilled for the position to be exempt. This, of course, was part of the big lawsuit against Electronic Arts a few years ago, having to do with overtime for game developers.

    Personally, I wouldn't work at a place where an hour here or there, one way or the other, was a big deal. There are more important things to focus on, and if the organization is myopic, there are likely better opportunities for my talents to grow.

    Btw: If you want to base any life-altering decision on something you read on a web site, then I suggest you first double-check with a lawyer in your jurisdiction, as web sites weren't licensed to practice law last I checked ;-)

  • (cs)

    "Oh, that..." she said, "I didn't know what this 'std' means."

    That's what you get for unsafe hex!

  • Cronus (unregistered) in reply to FredSaw
    FredSaw:
    Velko:
    Never make any mistaeks. -- Anonymous, in a mail discussion about to a kernel bug report.
    Wow, what a dumbass! Can you spell "looser"? -- Not anonymous, in the middle of a forum confrontation, but I will keep him so anyay, bless his uneducated little heart.

    While I enjoyed the sarcasm ( a la "looser"), even the most professional worker can miss a typo (or two) in a report. Or even a brief sentence commenting on said misspelling.

    However, this statement ("Never make any mistaeks.") is taken out of context. Its funny out of context, or if there was an "I" in front of the sentence. However, seeing that its a "kernel bug report." couldn't the statement be instructional, thereby warning about the dangers that a mistake might incur?

    (Don't flame too hard, still studying Comp Sci)

  • (cs) in reply to Manic Mailman
    Manic Mailman:
    3) here's one way to init the array that I believe is correct
        
        short a[N];
        for (size_t i = 0; i < N; ++i) {
            a[i] = 42;
        }
    

    I'm not sure what might be different in C except that the declaration for i would have to be located prior to the 'for' statement.

    Do I get the job?

    I agree on your points 1) and 2), but on point 3) my opinion differs for the C++ case: you should imho not be using C arrays at all. You should instead be using

    std::vector<short> a(N, 42);
    

    For the C case I agree with you again, as I'm not sure how I'd initialize the array other than with an iterated assignment.

    Certainly I wouldn't be using a memset as that operates on the byte level rather than the short level and the resulting code would then only operate correctly if the short type happened to be one byte large on the target platform/architecture/compiler/etc. and byte and short value 42 would both share the same representation at the byte level. Meaning; portability nightmare.

  • PrepositionJoe (unregistered)

    I feel the need to say that the "type wit no mistakes" thing is because nobody ever proof-reads any more! They spell-check instead and think it's the same thing.

    So, if it had been "type wiht no mistakes", it would have been found, but guess what, some typos are words -- just not the intended word.

    Same goes double for people who don't know the difference between "they're", "their" and "there". All good words, spelled correctly. But only one of them is right for a given context.

    The one I see all the time, and it drives me crazy, is people who don't know the difference between "lose" and "loose". Once you start noticing it, it's everywhere!

  • (cs) in reply to FredSaw
    FredSaw:
    bramster:
    juniorest? WTF
    He meant to say "most juniorized".

    juniorest n. Someone who more juniorer than the most juniorized of juniors.

  • David Schwartz (unregistered)

    "If you want to hire somebody who is going to work extensively with the STL, ask them about the STL. Why is this so hard to understand?"

    Maybe, if you're hiring someone for a week or two. But if you're looking for a serious developer who is going to work on projects for you for years, having to learn the STL is no big deal. A programmer who has dealt with a large number of other libraries can pick up the STL in no time.

    Which would you rather have, someone who knows the STL very well and only the STL, or someone who doesn't know the STL but can pick up new libraries in a week or two?

    Which is the better long-term investment?

  • (cs) in reply to fist-poster
    fist-poster:
    Ok: #include <iostream> using std::cout;

    struct False { False() {} False(int) {} operator bool() const { return false; } };

    int main() { False x; x=3; if (x=5) cout<<"5"; else cout<<"not 5"; } Do I get the job?

    Looks good to me, although I haven't tried to run it. I was thinking more on the lines of redefining the assignment operator. In C, the result of an assignment expression is the value of the right hand side. In C++ you have more leeway :)

  • Russ (unregistered) in reply to David Schwartz

    Listen, I'm just an ignorant, unattractive ColdFusion developer and I could probably learn the STL given a week or two.

  • (cs) in reply to too_many_usernames
    too_many_usernames:
    Russ:
    It is a bit of a trick question, as some junior developers might not know the difference between

    if (x==5)

    and

    if (x=5)

    This is why you always write comparison statements against literals:

    if(5 == x){...}

    Very hard to get incorrect assignment operations wrong written this way. So hard, in fact, it would require discovery of a compiler that doesn't work properly.

    Actually thats why you use a modernday compiler to tell you that you've done this. 5 == x looks awkward because it is. You aren't seeing if the value 5 is the same as x, you are seeing if the value of x is 5.

  • Edward Royce (unregistered) in reply to RogerN
    RogerN:
    Russ:
    The answer should be 5. It is a bit of a trick question, as some junior developers might not know the difference between

    if (x==5)

    and

    if (x=5)

    See, this is exactly why I hate trick questions. There's frequently more than one trick. Far too often, the questioner screws something up unintentionally (such as the missing semicolon for x=3). Then I start to second-guess myself. Did he forget that semi-colon intentionally? Is that the trick? Or is it the improper assignment instead of quality test within the if statement?

    shrug personally I'd be wondering why the IDE and/or compiler hadn't picked up on an assignment in an if() statement.

  • Edward Royce (unregistered) in reply to FredSaw
    FredSaw:
    tanisha:
    Regretably, it's all in Herbrew.
    Well, at least Israel is starting to get with the Women's Lib thing.

    And beer!

    Believe it or not but there really is a "He'Brew" beer. Website at www.schmaltz.com if you're interested.

    L'Chaim!

  • Edward Royce (unregistered)

    Hmmmm.

    The question I like to ask:

    1. What is the source code repository used on the project.

    2. What is the bug tracking software.

    ...

    I'm amazed at how many times the answer is, in order, "none" and "Excel".

  • (cs) in reply to Edward Royce
    Edward Royce:
    *shrug* personally I'd be wondering why the IDE and/or compiler hadn't picked up on an assignment in an if() statement.

    All good coders use vi.. didn't you know?

Leave a comment on “Let's All Reinvent the Wheel... Again, and More”

Log In or post as a guest

Replying to comment #193572:

« Return to Article