• (cs)

    this comment was typed wit a minor mistake

  • (cs)

    wat mistake? i dont do mistakes!

  • veniam (unregistered)

    std::cout << "I don't think will work with that crazy "std::", but I'll try to post my comments anyway!" << endl;

  • (cs) in reply to DarkAngl
    DarkAngl:
    wat mistake? i dont do mistakes!

    I just start my comments from scratch all over again !

  • (cs)

    Hey, wait, consider me! I am a team player with some independently abilities, too!

  • (cs) in reply to veniam
    veniam:
    std::cout << "I don't think will work with that crazy \"std::\", but I'll try to post my comments anyway!" << endl;
    Did you forget endl is in the std namespace?
  • (cs)

    If "Exclusive research skills with details" means she can find stuff nobody else can find, she needs to apply to the CIA or FBI.

  • (cs)

    Dear Mr[s]. Employer-Person,

    I am good werkr. I try hard, and sometimes succeed very muchly. If yu gv me a chanc, I will send u teh codez.

    Thank you very much, Your soon-to-be humble slave...

  • David Schwartz (unregistered)

    Highly-experienced C++ programmers might have little to no familiarity with the standard library functions. This is especially true for people who have been programming C++ for a very long time and maintain codebases that still have to run on machines whose standard library support is somewhat lacking.

    One of the projects I manage has a codebase of about 730,000 lines of C++ code. It does not use the standard library at all. At the time it was initially developed, some of the platforms it had to run on did not have standard libraries that worked properly with threading, so it has its own set of libraries. We have programmers we've hired out of high school who have worked for a decade on only this code.

    Of course, if you use the standard library heavily, you may have some issues with them building familiarity with it. But a good programmer can learn a new library in a few days at most.

    It's a huge mistake to judge programmers based on whether they have skills a good programmer could pick up in a week or less. You want good programmers.

  • (cs)

    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.

  • SomeCoder (unregistered)

    I'm not saying that the C++ test is a WTF, this is just a comment about it...

    While the candidate that didn't know what "std" means was surely a WTF, I'm not sure I would have automatically circled std::string as an error.

    Truth be told, I always pass strings as const std::string& for efficiency but std::string wouldn't really jump out to me as an "error". I'd probably comment on it though.

    Hopefully your test also looks for people who use ++myVariable vs myVariable++ (where appropriate).

  • Lev (unregistered)

    I work [my] wit!

  • Resolute (unregistered)

    That resume is one of those "how many errors can you find?" puzzles, right? Using my independently abilities, I exclusively researched at least five errors in that one section.

  • Marvin the Martian (unregistered)

    OK, the <wit> typo is clearly a joke (I have the same sense of humour), but how do you explain the <independently abilities>?

    15 typos mysteriously occuring simultaneously after the <independent> part? Insanity? I think we should be told.

  • (cs) in reply to Resolute
    Resolute:
    Using my independently abilities, I exclusively researched at least five errors in that one section.
    Yeah, but you dint cum up wit no details.
  • (cs)
    ...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?

  • (cs)

    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.

  • (cs) 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?
    Perhaps, to see if/how they turn a trick?
  • (cs) in reply to David Schwartz
    David Schwartz:
    Highly-experienced C++ programmers might have little to no familiarity with the standard library functions. This is especially true for people who have been programming C++ for a very long time and maintain codebases that still have to run on machines whose standard library support is somewhat lacking.
    Not being familiar with details of the standard library is excusable, but not even knowing what it is is not.
    But a good programmer can learn a new library in a few days at most.

    It's a huge mistake to judge programmers based on whether they have skills a good programmer could pick up in a week or less. You want good programmers.

    IMO someone who's been working for years in a narrow niche and has made NO effort to keep up to date with important developments in the field (to the point that they don't even know what the standard library is) is very unlikely to be a good programmer.
  • the pope (unregistered)

    A clerical position was offered, and I've not been informed? Heresy!

  • Russ (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?

    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?

  • diaphanein (unregistered) in reply to Russ
    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?
  • Some (unregistered)

    Trick questions are the most beautiful part of any test. If someone answered it correctly, then that means one of two thinks – he saw this question before (he had many interviews and possibly for good reason – also bad candidate) or he’s a genius – also he’ll never do what he should, instead he’ll search for “very interesting” ways to do the task (no matter how much time it takes)

  • Russ (unregistered) in reply to brazzy
    brazzy:
    David Schwartz:
    Highly-experienced C++ programmers might have little to no familiarity with the standard library functions. This is especially true for people who have been programming C++ for a very long time and maintain codebases that still have to run on machines whose standard library support is somewhat lacking.
    Not being familiar with details of the standard library is excusable, but not even knowing what it is is not.
    But a good programmer can learn a new library in a few days at most.

    It's a huge mistake to judge programmers based on whether they have skills a good programmer could pick up in a week or less. You want good programmers.

    IMO someone who's been working for years in a narrow niche and has made NO effort to keep up to date with important developments in the field (to the point that they don't even know what the standard library is) is very unlikely to be a good programmer.

    What if they did C++ on a *nix platform? Not the whole world is MS centric you know.

  • Crabs (unregistered) in reply to WhiskeyJack
    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.

    Because some people don't move on. There is a small percentage of people that, if you take this approach, will completely freak out on you. To try to avoid this situation, you make it more polite. Sure, I guess it's stringing them along, but good candidates understand this answer (and should have more than one interview), and the candidates in question don't have their feelings hurt. It's a win-win.

  • Schnapple (unregistered) in reply to brazzy
    brazzy:
    David Schwartz:
    Highly-experienced C++ programmers might have little to no familiarity with the standard library functions. This is especially true for people who have been programming C++ for a very long time and maintain codebases that still have to run on machines whose standard library support is somewhat lacking.
    Not being familiar with details of the standard library is excusable, but not even knowing what it is is not.

    Especially if the job they're interviewing for uses it extensively and needs someone who is an expert at it. I think that's what the "immensely high standards" build-up was supposed to communicate to us - this person might have been a fine developer, or potentially one, but to not know what the standard library is, or to expose ones unfamiliarity in such a bonehead way, is pretty much doom in an interview like this.

    But yeah if the goal of the story was something like "this is supposed to be a great C# programmer but they don't even know what company makes Windows" then it fell flat as a WTF

  • Russ (unregistered) in reply to diaphanein
    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

  • Chris M. (unregistered) in reply to Russ
    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?

    Fails to compile, since there's no ";" after x=3 and the else has no if (the if statement ended on the ";" in 'cout<<"5";'). Watch those semicolons!

  • Vollhorst (unregistered) in reply to Russ

    [quote user="Russ"][quote user="Ytram"]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?[/quote]

    It is:

    error: expected constructor, destructor, or type conversion before ‘=’ token error: expected unqualified-id before ‘else’

    But I expect you would like to hear "5".

  • Some (unregistered) in reply to Russ
    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?

    That's not really a trick question....

  • Max (unregistered) in reply to Russ
    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?

    A compiler error? No semicolon...

  • Vollhorst (unregistered) in reply to Chris M.
    Chris M.:
    the else has no if (the if statement ended on the ";" in 'cout<<"5";'). Watch those semicolons!
    You aren't serious, are you?
  • Erik (unregistered)

    Clearly the woman applying for the clerical position is very detail orented.

  • Russ (unregistered) in reply to 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)

  • Carl (unregistered) in reply to Chris M.
    Chris M.:
    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?

    Fails to compile, since there's no ";" after x=3 and the else has no if (the if statement ended on the ";" in 'cout<<"5";'). Watch those semicolons!

    It does fail to compile, but there is nothing wrong with the if/else.

  • matt (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?

    Whist is a complicated game, man.

  • (cs) in reply to Chris M.
    Chris M.:
    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?

    Fails to compile, since there's no ";" after x=3 and the else has no if (the if statement ended on the ";" in 'cout<<"5";'). Watch those semicolons!

    Or perhaps that was the point - subtle bug is single = in if-boolean-test, more subtle bug is the compiler error: x=3<no semi>

    And yeah, I hate those sorts of questions too (I mostly always get them right, then use it as an excuse to terminate the interview, as in: interviewer doesn't know how to interview: FAIL!)

  • SomeCoder (unregistered) in reply to Chris M.
    Chris M.:

    ...else has no if (the if statement ended on the ";" in 'cout<<"5";'). Watch those semicolons!

    Umm what?

    Assuming x is defined and adding the semicolon to the end of x=3, the answer is 5 (obviously). It's not really a trick question because anybody who writes C code should be able to find that and if not... well they need to be sent packing.

  • (cs) in reply to Russ
    Russ:
    brazzy:
    David Schwartz:
    Highly-experienced C++ programmers might have little to no familiarity with the standard library functions. This is especially true for people who have been programming C++ for a very long time and maintain codebases that still have to run on machines whose standard library support is somewhat lacking.
    Not being familiar with details of the standard library is excusable, but not even knowing what it is is not.
    But a good programmer can learn a new library in a few days at most.

    It's a huge mistake to judge programmers based on whether they have skills a good programmer could pick up in a week or less. You want good programmers.

    IMO someone who's been working for years in a narrow niche and has made NO effort to keep up to date with important developments in the field (to the point that they don't even know what the standard library is) is very unlikely to be a good programmer.

    What if they did C++ on a *nix platform? Not the whole world is MS centric you know.

    Ho ho, I think we have a major candidate right here...

    To David Schwartz: although you may have a point about most libraries, a week is definitely not long enough to pick up the STL. Even to understand the goddamn error messages would take this long. Plus, as Brazzy says, if you haven't read a single relevanat book on C++ in the last ten years, you are probably toast as a potential employee.

  • Chris (unregistered) in reply to David Schwartz

    My initial thought would be that if they WERE good programmers they are keeping themselves reasonably up to date. Studying new practices, languages, and additional functionality. If a "good" programmer doesn't know about the std library in C++, then I would say they aren't that "good"

  • ChiefCrazyTalk (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'll tell you why - I once interviewed a candidate who was simply awful, could not answer a single tech question. He even apologized for doing so poorly at the end of the interview. But, I was not the hiring manager and so could not officially tell him yes or no. The real WTF was that in spite of my feedback they hired him anyway.

  • Chris Becke (unregistered)

    I dont buy the std:: thing as a reason to terminate the interview. c++ is an ancient language, and many very very competent developers have been working with it since way before the standard template library - or, during the horrible time when most stl implementations were both notoriously unstable and ... not very standard.

  • (cs) in reply to 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

    Why should it be sarcasm? It's the correct answer. It's your question, right?

  • (cs) in reply to Lingerance
    Lingerance:
    veniam:
    std::cout << "I don't think will work with that crazy \"std::\", but I'll try to post my comments anyway!" << endl;
    Did you forget endl is in the std namespace?

    I bet he was 

    using namespace std;
    anyhow, but had a different cout defined in another namespace and had to remove the ambiguity...

  • (cs)
    As soon as I've finished and installed the application, I delete the code.
    After 20+ years of working in this industry, I am ready to believe any damned thing at all that appears on this board, no matter how much people cry "shenanigans!" . . . but this one has me stumped. What could the interviewee possibly be thinking, what could he have meant? 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.
  • morry (unregistered)

    I'd be willing to believe that the "wit" misspelling is just that - wit. A joke.

    I'd like to come up with some trick questions to ask a company in an interview some time.

  • (cs)

    I'd reply but I don't know what the Add Comment button does. Oh, wait...

  • Alan (unregistered) in reply to Russ
    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)

    How junior? Pre-school?

  • J_Random_Hacker (unregistered)

    I don't think that passing a std::string as a non-const value parameter is necessarily an error; it is less efficient than passing a const reference if the strings are long (unless string copies are performed lazily, in which case the difference in performance would be negligible in typical scenarios). On the other hand, if the called function needs to modify the value for its own internal purposes (e.g. it wants to produce an uppercased version for searching some table), it is probably more efficient to modify a non-const value argument directly than to copy-construct a new local std::string variable from a const reference argument and then modify that.

    (Just to be clear, a non-const, pass-by-value parameter is a copy of the passed parameter so any modifications will not be seen by the calling function. There are many situations where this might be useful behaviour, such as the conversion to uppercase mentioned above.)

    So if that was "the most obvious error" in the buggy code, I'm concerned.

    JRH

  • (cs) in reply to dpm
    dpm:
    What could the interviewee possibly be thinking
    That's the problem right there. Thinking. Some people simply hate doing it.

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

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article