• Kuba (unregistered) in reply to Some
    Some:
    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...

    Nope. At the last loop the p will be equal to a. Methinks.

    The problem is that incrementing a pointer one past the end of the allocated memory area is an undefined operation per standard (IIRC). a+N-1 does not need to be optimized, it may literally take address of the array, increment it by N elements, and then move back one element. On most platforms this will work as you expect it to. But it's not guaranteed to.

    As for filling the array in C, there's no standard way IIRC. If sizeof(char)==sizeof(short) then memset will work. In C++, there's std::fill.

    I don't think there are real scenarios where the code would b0rk, unless you're on some crazy architecture. Maybe some big iron would mind such code. I mean architectures contorted enough to have a dereferenceable (w/o violations) NULL pointers.

    I can't think of a commonplace "consumer" architecture where pointer arithmetic isn't done modulo some power of two, and pointers can't store crap without further ado. I'd have to look up how Turbo C did pointer arithmetic, but in all models I think this would still work as you expect, even if the segment registers would be tweaked along the way.

    Am I missing something obvious (it's late here)?

  • tsmith (unregistered)
    "Oh, that..." she said, "I didn't know what this 'std' means."

    "I see," I said, and ended the interview immediately.

    That's pretty harsh. Did she not understand the concept of a namespace? What about polymorphism, operator overloading, virtual functions, is-a versus has-a, or other object-oriented concepts? Or did you end the interview before you could find out?

    Tool.

  • Filthy_Liar (unregistered) in reply to Kuba
    Kuba:
    Nope. At the last loop the p will be equal to a. Methinks.
    Nope. In order for loop to break the comparison 
    p >= a
    must evaluate to false. Thus p must have decremented to a pointer value before the array.
    The problem is that incrementing a pointer one past the end of the allocated memory area is an undefined operation per standard (IIRC). a+N-1 does not need to be optimized, it may literally take address of the array, increment it by N elements, and then move back one element. On most platforms this will work as you expect it to. But it's not guaranteed to.

    The concern of a+N-1 does not actually apply to this case. The calculation will be correct even if a[] takes up the last N addressable words (which is why the spec makes *(a+N) undefined to begin with).

    The problem with the original code was 

    --p
    . After the last loop, when p == &a[0], there is no gaurantee that --p will result in a p value less than &a[0]. Specifically if &a[0] = 0 (a[0] is the first addressable word), then the last --p will result in p much larger than a since pointers are unsigned.

    If sizeof(char)==sizeof(short) then memset will work.

    I don't think that matters, 

    memset(a,42,sizeof(short)*N);
    should always work.

    I don't think there are real scenarios where the code would b0rk, unless you're on some crazy architecture.

    If &a[0] < sizeof(short *) then the pointer arithmetic on p will underflow causing p to have a very large value. I'm not sure which OS would give you a data segment with a virtual address starting at 0x00000, but it is conceivable and it would die.

    Am I missing something obvious (it's late here)?

    I wouldn't call it obvious.

  • Filthy_Liar (unregistered) in reply to tsmith
    tsmith:
    "Oh, that..." she said, "I didn't know what this 'std' means."

    "I see," I said, and ended the interview immediately.

    That's pretty harsh. Did she not understand the concept of a namespace? What about polymorphism, operator overloading, virtual functions, is-a versus has-a, or other object-oriented concepts? Or did you end the interview before you could find out?

    Tool.

    Contrary to what was stated, their standards are not "immensely high", they are "exclusive." They may be high as well, but the primary effect is exclusivity. There is a difference.

    Most employers make this mistake. They will pass over extraordinarily capable candidates because "they didn't have enough knowledge of Specific Technology X." I'm sure most employers would turn down Donald Knuth for a job writing Ruby code because he didn't have specific knowledge of Ruby even though he is one of the most renowned computer scientists in the world.

  • AdT (unregistered) in reply to SuperousOxide
    SuperousOxide:
    Why is copying the variable to make the pass-by-value parameter more efficient than copying the variable to make a local variable?

    Because the pass-by-value parameter is constructed by the calling function, saving one copy operation in some cases. For instance:

    void twistAndPrint(const std::string& thestring);

void readTwistAndPrint()
{
  std::string input;
  std::cin >> input;
  twistAndPrint(input);
}

    This will create an empty string, fill the string using the stream operator >>, pass a reference to this string on to twistAndPrint, where it will be copied.

    On the other hand, if twistAndPrint accepted an std::string, the compiler could easily figure out that since "input" is no longer used after "twistAndPrint" (the only method that will be called on "input" after twistAndPrint is the destructor), the compiler could create "input" on the stack in a location suitable to the subsequent invocation of twistAndPrint, and no copy operation would be necessary.

    Of course, given sufficient knowledge of what twistAndPrint does and where it is used, the compiler might make the same optimization in the "const std::string&" case. But the point is that this requires the compiler to perform global optimization, using much more knowledge of the entire program, whereas the original optimization requires only local ("peephole") knowledge including the already known signature of twistAndPrint. Therefore, real world compilers will be much more likely to perform the optimization in the pass-by-value case than in the pass-by-reference case. Also, there could be incompatible uses of twistAndPrint which prevent the optimization in the latter case anyhow (most importantly if twistAndPrint is used in a way which prevents the compiler from altering the calling convention without breaking the linked program, i.e. exported to external programs or passed to external programs as a callback).

    For further information, see "Move Constructors" by Andrei Alexandrescu.

  • AdT (unregistered) in reply to Kuba
    Kuba:
    The problem is that incrementing a pointer one past the end of the allocated memory area is an undefined operation per standard (IIRC).

    No, that part is ok. It is fine to point one past the end of an array, as long as you don't dereference, and this is what users of the STL do all the time (remember that pointers are iterators!). The problem is that this code tries to move the pointer one past the beginning of the array, and that is illegal.

    Kuba:
    I don't think there are real scenarios where the code would b0rk, unless you're on some crazy architecture. Maybe some big iron would mind such code. I mean architectures contorted enough to have a dereferenceable (w/o violations) NULL pointers.

    Yes, segmented memory. The array could be at offset 0 in a memory segment. The corresponding pointer is not a NULL pointer, but either the decrement itself or the following comparison will easily cause mayhem.

    Segmented memory may be an oddity on x86 (32 or 64 bit) today because the flat memory model basically won, but no exotic processor architecture is necessary, only a more or less exotic rsp. outdated OS.

    Kuba:
    I think this would still work as you expect, even if the segment registers would be tweaked along the way.

    In real mode, the compiler-generated code may be smart enough to handle this case. But even then, in Borland C++ it would not work in all memory models because only in the "huge" memory model would the compiler bother to insert expensive segment adjustment code for pointer arithmetic in all cases. In other memory models, you had to use a special type of far pointer if you wanted that to happen IIRC.

    In protected mode, segment adjustment isn't even possible in the general case, so all bets are off.

  • AdT (unregistered) in reply to Erik
    Erik:
    Clearly the woman applying for the clerical position is very detail orented.

    And she has an penchant for using the wrong indefinite article. On the other hand, she does have a pleasant phony voice. :-)

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

    Oh, right, I almost forgot that MS invented the STL, and SGI (IRIX anyone?) never implemented that sucker, and never donated the code to the GNU libc++ project, and that libc++ is actually not available on a huge range of UNIX platforms be they Solaris, Linux, Mac OS X or many others. Sheesh.

  • eryn (unregistered) in reply to FredSaw
    FredSaw:
    real_aardvark:
    FredSaw:
    OedipusPrime:
    I REALLY hope that even the juniorest guy in the room can tell you the difference between assignment and comparison operators.
    Depends on the language. In VB they are the same.
    *Ahem* No they are not. They happen to be represented by the same symbol (which is idiotic) and are thus lexically the same. Unfortunately, and invisibly, they are syntactically distinct.

    Mind you, this would make for a whole 'nother set of useful interview questions if, for some obscure and twisted reason, you are seeking to hire a VB programmer.

    RA, I respect you more than to say, "What a dumbass reply." So I won't.
    i've lost count the number of times this topic has come up for discussion. wrt the = sign in vb, it's context sensitive.

    hmmm... what's that on ur face? oh it's just egg.

  • John (unregistered)

    I'm (almost) certain that the interviewed guy said that as a joke (no code reuse, just likes to start over).

  • Jim (unregistered) 
      short a[N];

    for (size_t i = 0; i < N; ++i) {

    a[i] = 42;

    As A C novice, I keep wondering why ++i is used instead of i++. Wouldn't that overflow the array at the last iteration, and keep the short with index 0 uninitialized??

  • (cs) in reply to Filthy_Liar
    Filthy_Liar:
    If sizeof(char)==sizeof(short) then memset will work.
    I don't think that matters, 
    memset(a,42,sizeof(short)*N);
    should always work.
    Of course it works. You end up with every element of the array set to 10794, but no errors occur, which I assume is your definition of the word "work".

    memset() assigns a value to every byte in the referenced memory, and your "sizeof short" looks like a clue but it's not. The function receives the address of the array, a value, and the number of bytes to fill, period . . . so instead of 002A002A002A002A002A002A the memory will look like 2A2A2A2A2A2A2A2A2A2A2A2A

  • Khanmots (unregistered) in reply to Jim
    Jim:
    As A C novice, I keep wondering why ++i is used instead of i++. Wouldn't that overflow the array at the last iteration, and keep the short with index 0 uninitialized??
    for(expr_1; expr_2; expr_3)
{
  statement;
}

    is equivilent to

    expr_1;
while(expr_2)
{
  statement;

  expr_3;
}

    The ++i or i++ is evaluated entirely in expr_3, it doesn't change when expr_3 itself is evaluated.

    The difference between ++i and i++ is what value it evaluates to... which in the case of the for loop the value the expression evaluates to is never used.

    Here's an example with behavior analogous to the for loop... notice how the choice of i++ or ++i doesn't matter... j matches i.

    int i = 0;
int j = 0;
j = i; // j = 0, i = 0
i++; 
j = i; // j = 1, i = 1
++i;
j = i; // j = 2, i = 2

    Here's an example of when it would matter.

    int i = 0;
int j = 0;
j = i++; // after this is evaluated j = 0, i = 1
j = ++i; // after this is evaluated j = 2, i = 2

    And here's another example where it matters.

    int i[N];
int j = 0;
i[j++]; // this is i[0]
i[++j]; // this is i[2]

    Hope this helps!

  • (cs) in reply to Jay
    Jay:
    ..."What is your greatest weakness?"...
    Answer: My greatest weakness is that I have little patience for incompetence... If I have to explain something more than 3-4 times to someone, I tend to insist that they make more of an effort.
  • (cs) in reply to Jim
    Jim:
      short a[N];

    for (size_t i = 0; i < N; ++i) {

    a[i] = 42;

    As A C novice, I keep wondering why ++i is used instead of i++. Wouldn't that overflow the array at the last iteration, and keep the short with index 0 uninitialized??

    Not much difference in C, the difference is in C++. The "++object" form is more efficient when dealing with real objects. Using "object++" instead would require that a copy of the object be made before incrementing the real one. The copy is then returned instead of the original. With "++object" a reference to the real one can be returned.

    Not important when you're dealing with ints, or where the value is not being used, but just a good practice to get into, especially with poorly written code that includes dynamic allocations in the object (which you don't want to have to check for). I believe there is a section in Effective C++ about this. The rule is: if you have pointers in your object, you need a destructor, an assignment constructor and a copy constructor (once again, if I remember right).

    This is also an area where different compilers may produce different behaviour -- one may produce a copy of the object, another may not. It's done behind the scenes for you, or against you when things go awry. You want to avoid that difference in programs you want to be portable.

  • usitas (unregistered) in reply to The Enterpriser
    The Enterpriser:
    All good coders use vim.. didn't you know?
    Fixed that for ya.

    I used gVIM all the time, even in windows. VIM has had syntax highlighting for years...

  • I walked the dinosaur (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)

    By "junior developers", I assume you mean high-school students?

    Seriously though, when I first looked at teh codez above, I didn't see the missing "=" either. Of course I know the difference, but "trick" questions like that are retarded.

  • noName (unregistered) in reply to Jim

    In this case ++i is the only op being done so its irrelevant. However dont do "a[++i] = 42;". "a[i++] = 42;" would be OK though... :D Search google for «C unary prefix posfix». First hit will get you:

    "The increment/decrement operators can be applied before (prefix) or after (postfix) the operand. The code result++; and ++result; will both end in result being incremented by one. The only difference is that the prefix version (++result) evaluates to the incremented value, whereas the postfix version (result++) evaluates to the original value. If you are just performing a simple increment/decrement, it doesn't really matter which version you choose. But if you use this operator in part of a larger expression, the one that you choose may make a significant difference."

  • noName (unregistered) in reply to noName

    If you test candidates for

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

    and ask for a verbose explanation of the result than you may start getting some pretty explanations: "0 is diferent of 3; therefore «not 0»!"

  • Anon Fred (unregistered)

    I must say I love these esoteric discussions of the C spec. Every time I think I know the language someone knocks me down a peg.

    But it's how I learn. Thanks guys.

  • Flavio (unregistered)

    K.D. you did not make me laugh. Why don't you just accept that the brilliant guy has never got a project wrong? As surprising as it may be, skilled and smart developers can get things always almost right (or fixed them on the go) and not let a project failed by incompetence.

    I, for one, admire his honesty. He probably knew that what he was going to say could hurt him. I think he tested you. Something like "Let's if my (potential) boss can cope with a guy like me".

  • (cs) in reply to Flavio
    Flavio:
    As surprising as it may be, skilled and smart developers can get things always almost right (or fixed them on the go) and not let a project failed by incompetence.

    "Always almost right". 2+2 = 3.99999, but consistently so.

    He probably knew that what he was going to say could hurt him.

    And he ended up saying something dumb that hurt him. Zero points awarded.

    I think *he* tested *you*. Something like "Let's if my (potential) boss can cope with a guy like me".

    I wouldn't want someone on my team who had to be "coped with". Why can't you play well with others?

  • Edward Royce (unregistered) in reply to The Enterpriser
    The Enterpriser:
    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?

    I'd rather use UltraEdit frankly.

    Not a huge fan of vi. Or of emacs.

  • Edward Royce (unregistered) in reply to eryn
    eryn:
    FredSaw:
    real_aardvark:
    FredSaw:
    OedipusPrime:
    I REALLY hope that even the juniorest guy in the room can tell you the difference between assignment and comparison operators.
    Depends on the language. In VB they are the same.
    *Ahem* No they are not. They happen to be represented by the same symbol (which is idiotic) and are thus lexically the same. Unfortunately, and invisibly, they are syntactically distinct.

    Mind you, this would make for a whole 'nother set of useful interview questions if, for some obscure and twisted reason, you are seeking to hire a VB programmer.

    RA, I respect you more than to say, "What a dumbass reply." So I won't.
    i've lost count the number of times this topic has come up for discussion. wrt the = sign in vb, it's context sensitive.

    hmmm... what's that on ur face? oh it's just egg.

    Hmmmm. Counting coup, nerd-style.

  • An oppressed mass (unregistered) in reply to Saaid

    That's why an experienced programmer will always write. if ( 5==x ) { } We had this arguement on here before: "An expert programmer shouldn't rely on the compiler to find his mistakes" vs "An expert programmer uses all the help he can get"

  • K.D. (unregistered) in reply to NightGod

    (I'm the original poster/interviewer in the story)

    Yes, that in fact, I believe, was what he meant. He didn't believe in ever going back to refer to previous work (of his or anyone else's) but rather wanted to start every single project with a clean slate. Admirable in a sense, but why on earth would you want to re-invent simple common elements over and over?

    And to the person who said that asking someone to point out their weaknesses is a flawed interview style -- well, actually, it's worked very well for me. This candidate was horrible flawed, and by opening a door, he pointed it out himself.

  • CB (unregistered) in reply to dpm
    dpm:
    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!

    Heh, the job I am about to leave gave the latter as an answer when I asked. Actually, they volunteered it as if it were a source of pride. Gah.

    Bonus points if said in-house "source control" is written in VB6.

  • Justin (unregistered) in reply to mauve

    I was about to say the same thing. To the best of my knowledge, most university classes do not discuss namespaces. I feel like many C++ programmers just know that they need to put using namespace std; at the top of their files.

    Additionally, I have to wonder how important it is that a job candidate understand namespaces on the day that they start if they show overall competence. First, namespaces are easy to understand, so, it wouldn't take long to explain to explain if your organization really is making use of them. Second, I think that maybe half of all organizations actually take care to use them in any meaningful way.

  • (cs) in reply to Some Interviewer
    Some Interviewer:
    1. Sometimes you need a warm body; this is where the best of the worst is still better than nothing. (Sadly.)
    At least there's one valid reason.
    2. Legal reasons. If a candidate is immediately turned down, they may assume it was because of their gender, race, religion, etc. and not because they failed a test.

    Fields that involve physical activity (electrician, plumber, etc.) failure is pretty obvious to spot. The light doesn't turn on, the faucet leaks all over, etc. Fields like software development aren't quite so easy. The candidate didn't even understand the test; how will they comprehend their failure?

    Because you could tell them that they failed and if they ask why, you could say you don't have time to teach them. If you did tell them, you aren't opening up a legal battle if you are right. The HIGH cost of legal battles will keep most from even attempting. People have been graded since early childhood and are going to accept it (if mentally sound and if not then you might have a valid reason.) If you ARE rejecting based on personal attributes, "not a good fit" is used a lot or you could cop out but that wasn't WhiskeyJack's point.
    3. It's how the game is played. Don't whine.
    Great argument for status quo lovers. I hope people that pick #3 get LOTS of annoying calls asking.
  • chaoticsynergy (unregistered) in reply to Flavio
    Flavio:
    K.D. you did not make me laugh. Why don't you just accept that the brilliant guy has never got a project wrong? As surprising as it may be, skilled and smart developers can get things always almost right (or fixed them on the go) and not let a project failed by incompetence.

    I, for one, admire his honesty. He probably knew that what he was going to say could hurt him. I think he tested you. Something like "Let's if my (potential) boss can cope with a guy like me".

    Honestly I'm shocked at the number of pple that posted stuff similar to this. Nobody has ever put out 100% perfect work. If you can't accept your own faults, then you'll never improve.

    Yes your projects may all have been completed successfully ... that doesn't mean there weren't decisions you made that you had to go back and change, or in hind-sight wished you could have changed.

    I hope I get asked that question at future interviews. Then at least I'll know that I'll be working with people that grow ... instead of stagnate in the knowledge that everything they produce is perfect.

  • Anonymous Coward (unregistered) in reply to Anon Fred
    Anon Fred:
    I must say I love these esoteric discussions of the C spec. Every time I think I know the language someone knocks me down a peg.

    But it's how I learn. Thanks guys.

    Yes, I agree. This is the perfect kind of question I want my company to be asking in an interview.

    Why worry about actual coding ability when they can rattle off obscure facts about the C language specification that are rarely applicable to modern architectures? After all, as we all know, everyone who is worth their salt has been coding in C since the days of segmented memory.

    Furthermore, I think it goes without saying that people who enjoy picking apart trick questions are the very kind of people I want designing my algorithms. Sure, its one thing if the algorithm works, but is it optimized? No doubt we would all agree that all algorithms we write should exhibit the same kind of cleverness as these questions. Cleverness = maintainability.

    To extend this idea a bit, I think I will ask interview questions about real-mode programming and maybe pepper in a few questions about the ALGOL specification.

  • (cs) in reply to alegr
    alegr:
    "Oh, that..." she said, "I didn't know what this 'std' means."

    That's what you get for unsafe hex!

    OK, that was just very silly. And very funny. Thanks.
  • Procedural (unregistered) in reply to FredSaw

    I was in Jonestown, Tanzania once and saw a strip mall shop sign announcing Kinko-like services and more. The shop was also offering typing services. The name, written in bold letters in front of the shop, was "Helen's Secretalrial Services".

    I didln't enquire about their serlvices.

  • Manic Mailman (unregistered) in reply to Anonymous Coward
    Anonymous Coward:
    Anon Fred:
    I must say I love these esoteric discussions of the C spec. Every time I think I know the language someone knocks me down a peg.

    But it's how I learn. Thanks guys.

    Yes, I agree. This is the perfect kind of question I want my company to be asking in an interview.

    Why worry about actual coding ability when they can rattle off obscure facts about the C language specification...

    I actually agree with you that posing trick questions about obscure trivia is not a great interview technique, but it can be a good learning technique. If you're not interested in understanding or learning why something like underflow on pointer arithmetic might result in undefined behavior, then you might want to stay away from C/C++ because those languages love to stick you with runtime bugs that result in rare instances of that undefined behavior biting you in the ass. Without a doubt, this is a major drawback of C/C++; other languages let you largely stop worring about such details.

    So, while maybe being able to pick out the obscure potential bug is not something to look for in a potential hire, I'd certainly like anyone who I'm working with on a C/C++ project to at least want to understand or learn about these pitfalls if someone's pointing them out.

  • C++ dev (unregistered) in reply to J_Random_Hacker

    Yes, I agree. It makes me wonder if the author understands the language very well himself. There certainly are cases where a mutable value parameter is preferable.

    At companies in the Seattle where I have interviewed - and worked - at (Amazon, Microsoft, Real) there is much more of an emphasis placed on higher level design than on basic language semantics. When I have interviewed for our team I always focus on finding out what the candidate can do well and how they would be able to contribute. Often intellectual horsepower is a better measure of a candidate than language specifics anyway.

  • (cs) 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.

    There is a difference between not knowing what a standard library is, and not knowing what its namespace is, or that it has one, since some implementations let you call the entire standard library (or what parts of it are implemented) without it.

  • (cs) in reply to WhiskeyJack
    WhiskeyJack:
    Some Interviewer:
    1. Sometimes you need a warm body; this is where the best of the worst is still better than nothing. (Sadly.)
    1. Legal reasons. If a candidate is immediately turned down, they may assume it was because of their gender, race, religion, etc. and not because they failed a test.

    Fields that involve physical activity (electrician, plumber, etc.) failure is pretty obvious to spot. The light doesn't turn on, the faucet leaks all over, etc. Fields like software development aren't quite so easy. The candidate didn't even understand the test; how will they comprehend their failure?

    1. It's how the game is played. Don't whine.

    Hey, I ain't whining - I got my job already. Every place that had me for an interview gave me an offer. I'm just thinking that it would be so much more practical (albeit less funny stories for sites like this) if people who are obviously unqualified, or have extreme quirks, to be told so. Might actually be an incentive for them to improve.

    Like the guy in the first story, the interviewer was ready to hire him until he said his last bit. It would be nice if the interviewer could have actually told him "I was ready to hire you until you said that last part. That's not how it's done in the industry, so, sorry..." The intent is to have these people walk out of the room thinking "Have I got it wrong? Do I need to change my way of thinking?" rather than "Bah, another jerk company that won't recognize me for the programming God that I am!"

    Granted you'll always have a few that think that way and nothing will change them, but for the rest, finding out WHY you didn't get the job should be a good teaching experience.

    The policy "Can't tell them why they're not hired for legal reasons" has always translated in my mind to "Some of our reasons for not hiring people are illegal".

  • (cs) in reply to Kuba
    Kuba:
    If sizeof(char)==sizeof(short)

    This is never true on a normal programming environment (it may be true for some exotic embedded systems) - the reason: sizeof(char) always == 1. sizeof(short) is ALMOST NEVER going to be that, because a short has to be at least 16 bits, and a char is normally eight bits.

  • (cs) in reply to snoofle
    snoofle:
    Jay:
    ..."What is your greatest weakness?"...
    Answer: My greatest weakness is that I have little patience for incompetence... If I have to explain something more than 3-4 times to someone, I tend to insist that they make more of an effort.
    I'm sorry, I wasn't really paying attention. What did you say your greatest weakness was, again?
  • felix (unregistered)

    Fresh out of uni my CV was short on content so I decided to employ a "professional" CV writer to rewrite it for me using all the tricks of the trade. I filled in her questionnaire and sent off the results, a couple of weeks later I received the finished article. There were numerous typos including the following:

    "Accurate and eloquent in witten communications."

  • Anonymous Coward (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.

    Anyay?

  • IByte (unregistered)
    Mrs. Applicant:
    I didn't know what this 'std' means.
    It's what you get when you're screwed, and you certainly are...
  • caught ya (unregistered) in reply to snoofle

    This is obviously engineered (poorly).

  • Baloney Bear (unregistered)

    Oh, please, who can remember what all those acronyms mean? The question is, does she know how to -use- std? (What does it mean, anyway? Standard? And whenever I see stdio and want to pronounce it as "studio"... Talk about poor naming conventions...)

  • lifekills (unregistered)
    Team player with independently abilities

    That's more WTF than what was highlighted although less hilarious

  • RandyLeAra (unregistered)
    Comment held for moderation.
  • AbrahamTouct (unregistered)
    Comment held for moderation.

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