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

    Knowing the difference and being able to quickly spot the error are two different things, but I REALLY hope that even the juniorest guy in the room can tell you the difference between assignment and comparison operators.

  • Anon Fred (unregistered) in reply to real_aardvark
    real_aardvark:
    Russ:
    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.
    There's a lot of stuff to learn in the world. Maybe instead of learning the standard library they learned what was new in the latest Common Lisp. Maybe instead of learning prototype.js they learned ASP.

    If I was hiring for a new Ruby on Rails project, I'd rather have a generalist who has at least done some web programming than someone who can pound out 1 or 2 ROR applications.

    a week is definitely not long enough to pick up the STL. Even to understand the goddamn error messages would take this long.
    I've never professionally used the STL, despite 2 major C++ jobs. It was because both had their own very good reasons for using a different library. I played with the STL on my own time, but as I said before I could've easily have spent that time on some other learning project instead.

    If you've used other libraries before, the STL really isn't that difficult. The functional programming component can be difficult to grasp, but I bet lots of people who consider themselves "expert" in the STL have never touched that, or Boost.

  • mauve (cs)

    The std:: issue is the inevitable fallout of a language which had been in use for 20 years before anyone got around to publishing a standardised specification (and which, when they did, was significantly different to the language people had been programming in).

    Half the printed literature doesn't mention namespaces. Your average librarian doesn't know that any C++ book prior to 1998 is worthless.

    I suspect that there are tons of people who have slipped through the cracks and who would be perfectly competent C++ programmers. Would you, for instance, exclude former C++ programmers who've had a job programming embedded C for the last decade?

  • pitchingchris (cs)

    This is exactly the reason you should make beginners learn a C type language first, cause if they can learn it (no matter how painful) the rest are a bit easier. Whereas someone who learned other languages such as vb or whatever, they won't pick up on subtle differences in comparison operators as easily

  • Some Interviewer (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.

    1. Sometimes you need a warm body; this is where the best of the worst is still better than nothing. (Sadly.)

    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?

    1. It's how the game is played. Don't whine.
  • Nobody (unregistered) in reply to Chris
    Chris:
    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"

    Hmmm.... Well, perhaps it is about defining "good". A person may be a talented programmer, but not keep himself up to date on current practices. Part of being "good" to me involves being professional and motivated, which does involve being a student of your craft and keeping up with current tools and best practices. Often times, however, particularly with a "junior" hire, that can be cultivated. If you start without talent, though, there's only so much you can do.....

  • Anon (unregistered)

    What, he knows Excel, Access and PowerPoint 2000 but not Word?

  • sc++by (unregistered) in reply to Carl

    Yeah ... you may want to actually declare x.

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

    It's not that the interviewee didn't know how to use the std:: namespace, through having avoided it for years due to incompatibilities. She circled it because she didn't know what it was!!! That's exactly the opposite of "std:: is unstable, so I don't use it, and don't know what bugs it might introduce".

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

    Knowing the difference and being able to quickly spot the error are two different things, but I REALLY hope that even the juniorest guy in the room can tell you the difference between assignment and comparison operators.

    juniorest? WTF

  • NightGod (unregistered) in reply to dpm
    dpm:
    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.
    The *only* thing I can think of here is that he means he deletes any personal copy he has of the source, so he's not tempted to reuse his own code.

    Wow...that didn't sound any better after typing it out.

  • Rookierookie (unregistered)
    Knowledge of MS Office 2000 (Access, PowerPoint, Excel)

    Markedly missing is Microsoft Word.

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

    Knowing the difference and being able to quickly spot the error are two different things, but I REALLY hope that even the juniorest guy in the room can tell you the difference between assignment and comparison operators.

    What about a developer that has only seen languages like VB where the equality and assignment operators look the same?

    They should know that assignment and equality operations are different, but they might also assume that other languages do it the same way.

  • Global Warmer (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

    I really hope yours is sarcasm because it is 5

  • Nerf Herder (unregistered) in reply to dpm

    You're all thinking way too much into this. He means that when he finishes a project, he deletes his local copy or rather probably does not save a copy. When he starts the next project, he does not leverage work he previously did, but instead starts each project from scratch.

    Hence the title of the article called Lets All Reinvent the Wheel. Sometimes you have to read slightly between the lines and not take things so friggin literally.

    dpm:
    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.
  • Saaid (unregistered) in reply to Alan
    Alan:
    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?

    I would call this a typo, I've been using C since the mid 80s and every once and a while I will type = when I mean ==. If you program in several languages, it's hard not to make this error, sometimes it's hard to see.

  • Skaven (cs)

    Well, I do regret tossing that one in there with the level of nitpicking on this site. Of course I was referring to the languages that ASP.net covers as a framework and the fact that APS.net provides the just in time compiling, so it can be used in a similar manner to a scripting language. Yes, I realize that it can be pre-compiled, so the source code may not be available, but more often than not web developers use the just in time compiling.

    As for your comment about the code being 'delivered up to the client', where did you get the misinformed idea that all scripting languages are sent to the client? Ever hear of server side scripting?

  • FredSaw (cs) in reply to OedipusPrime
    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.
  • SomeCoder (unregistered) in reply to bryan986
    bryan986:

    What about a developer that has only seen languages like VB where the equality and assignment operators look the same?

    They should know that assignment and equality operations are different, but they might also assume that other languages do it the same way.

    I would argue that someone that has only seen languages like VB should not be applying for a C++ job and is not qualified anyway.

    And I agree with a previous poster that you should learn C or C++ first. Other languages are easy to pick up if you know those two well.

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

    What's wrong with them? Being willing to admit that you're human and don't know everything and hence make mistakes is wrong? Actually learning from those mistakes is wrong?

    I know I wouldn't want to hire a candidate who's unwilling to admit they're less than perfect... that's either hubris of the worst sort or they're dishonest. I would want to hire people who've shown me that they can learn from mistakes and not continue to make the same one over and over again. People make mistakes, it happens.

    If I were to not get a job because I explained that I learned from making a mistake... well... I'd be damn glad that I wasn't hired. It sounds like a horrible environment to work in. But then that's never happened. Hell, I even, voluntarily, brought up the fact that I flunked out of uni (while working on a ChemE degree) when I was interviewing after (finally) getting my CSE degree... and landed a hell of a first job.

    On a side note... asking someone to explain what they learned from past projects sounds like a great way to seperate those who think for themselves and can actually code from those that don't and simply know syntax.

  • FredSaw (cs) in reply to bramster
    bramster:
    juniorest? WTF
    He meant to say "most juniorized".
  • Jason (unregistered) in reply to gabba
    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.

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

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

  • real_aardvark (cs) in reply to bramster
    bramster:
    juniorest? WTF
    I really can't imagine what you're complaining about on this one. Imagine you have two sets of people, and there's a one-to-one correspondence of first names between the sets. Joe (set 1) might be three years younger than Joe (set 2); Fred (set 2) might be two years younger than Fred (set 1); Bill (set 2) might be five years younger than Bill (set 1).

    Bill (set 2) is clearly the juniorest of them all. "Most junior" is not a sufficient description, because it fails to capture the relationship between the sets.

    This is clearly a useful and indeed necessary word, and you are obviously a Grammar Nazi of the most unreasoning kind. I shall report you to the relevant authorities.

  • RogerN (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)

    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?

  • rbonvall (cs) in reply to Rookierookie
    Rookierookie:
    Knowledge of MS Office 2000 (Access, PowerPoint, Excel)
    Markedly missing is Microsoft Word.
    He/she prefers to use LaTeX, of course.
  • FredSaw (cs) in reply to real_aardvark
    real_aardvark:
    "Most junior" is not a sufficient description, because it fails to capture the relationship between the sets.
    How 'bout "least senior"?

    I'm home sick today, by the way, so I can post at machine-gun rapidity and not feel guilty.

  • Rootbeer (cs) in reply to mauve
    mauve:
    Your average librarian doesn't know that any C++ book prior to 1998 is worthless.

    Except, I would assume, for understanding the millions of lines of C++ code that were written prior to 1998. Legacy code still exists in abundance.

  • Havok (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 concur

  • real_aardvark (cs) in reply to Chris Becke
    Chris Becke:
    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.
    Thread up, thread down.

    Look: it's simple. If you want to hire a competent 1980's C++ programmer, use a time machine. If you want to hire a competent 2000's C++ programmer, ask them if they've read a book by Scott Meyers. (Not a plug, but relevant to the issue in question.)

    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?

  • FredSaw (cs) in reply to Skaven
    Skaven:
    Well, I do regret tossing that one in there with the level of nitpicking on this site.
    The level of nitpicking here does not exceed the level of compile-time error reporting. Get it right, or have it reported.
    Skaven:
    As for your comment about the code being 'delivered up to the client', where did you get the misinformed idea that all scripting languages are sent to the client? Ever hear of server side scripting?
    Um... so by your remark, you only meant to say that the compiled dll's are in the inaccessible bin folder down in the bowels of the physical web root... *cough* Yeah, I *cough* picked up on that.

    So, what happened to that whole sub-thread, anyway? It seems to have disappeared, at least from this client.

  • SuperousOxide (cs) in reply to J_Random_Hacker
    J_Random_Hacker:
    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.)

    Why is copying the variable to make the pass-by-value parameter more efficient than copying the variable to make a local variable?

  • snoofle (cs) in reply to morry
    morry:
    I'd like to come up with some trick questions to ask a company in an interview some time.
    For any established organization:
    1. How many releases did you do in the past year?
      • too few = scope creep: wtf management
      • too many = either too "agile" or qty > quality
    2. Why did the person who vacated this position leave?
      • hedging: something to hide
      • he "moved on" - why so vague?
      • specific real-sounding answer: probably ok
    3. What was the last disaster that occurred and how it was handled
      • all hands on deck for 2 weeks: lack of DR planning or code (or staff) is WTF
      • 2 hours to find and fix: system probably stable
    4. How much training did the folks on your team receive last year?
      • < 1 week: they want to pick your brains but not invest in you as an asset of the company
    5. How much overtime is typical?
      • very little: good project scheduling/QA: code is stable
      • hours each day: poor planning, wtf code/staff/management
    6. Depending upon the business: what is the size of the sales/support staff w.r.t. development staff?
      • 100:1 - lots of customers: probably stable code
      • 1:10 - very new, possibly unstable code - possibly new project (might be a good thing)
    7. What is your DR setup?
      • "George goes home and fires up his laptop" - no DR: run!
      • "parallel servers, dbs, etc" - someone thought about it and management funded it
    8. May I see your wiring closet?
      • birds nest: danger danger danger
      • pc's stacked on a refridgerator with fans on top: run!
      • nice and clean - good network support
  • real_aardvark (cs) in reply to FredSaw
    FredSaw:
    real_aardvark:
    "Most junior" is not a sufficient description, because it fails to capture the relationship between the sets.
    How 'bout "least senior"?

    I'm home sick today, by the way, so I can post at machine-gun rapidity and not feel guilty.

    I'm working from home, and not (any more than usually) sick, so not only do I not feel guilty but I also feel a powerful need to go down the pub.

    On the same argument (and I'm quite proud of this argument -- it's not often I get to contradict my own most deeply cherished beliefs), "least senior" is effectively the antonym of "most junior". Visual Basic would no doubt assign the same symbol to both. "Seniorest" would also be an excellent term, were it not for the fact that it has probably been copyrighted by some mega-corporation (SoylentGreenCorp?) to describe their luxury range of care-assisted facilities, complete with an interesting suction mechanism on the toilets.

    I wasn't really getting at VB on the assignment/equality issue, btw. (Well,, not much. I still think it's a remarkably silly language design choice.) My point was that it offers up an entirely new set of interesting gotcha questions for interviews.

    I hear a pint of Theakston's Old Peculier singing strange songs of woe and insane attraction to me. Tie me to the Main Mast, quick!

  • real_aardvark (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:
    1. How many releases did you do in the past year?
      • too few = scope creep: wtf management
      • too many = either too "agile" or qty > quality
    2. Why did the person who vacated this position leave?
      • hedging: something to hide
      • he "moved on" - why so vague?
      • specific real-sounding answer: probably ok
    3. What was the last disaster that occurred and how it was handled
      • all hands on deck for 2 weeks: lack of DR planning or code (or staff) is WTF
      • 2 hours to find and fix: system probably stable
    4. How much training did the folks on your team receive last year?
      • < 1 week: they want to pick your brains but not invest in you as an asset of the company
    5. How much overtime is typical?
      • very little: good project scheduling/QA: code is stable
      • hours each day: poor planning, wtf code/staff/management
    6. Depending upon the business: what is the size of the sales/support staff w.r.t. development staff?
      • 100:1 - lots of customers: probably stable code
      • 1:10 - very new, possibly unstable code - possibly new project (might be a good thing)
    7. What is your DR setup?
      • "George goes home and fires up his laptop" - no DR: run!
      • "parallel servers, dbs, etc" - someone thought about it and management funded it
    8. May I see your wiring closet?
      • birds nest: danger danger danger
      • pc's stacked on a refridgerator with fans on top: run!
      • nice and clean - good network support
    I always love that "Do you have any questions for us?" thing. If I had the balls, it would include all of the above. Sadly, it appears to be one more reflexive piece of crap, to be answered with something like "Yes, I was wondering how long you expect it will take for your flagship product to cure malaria/cause young girls to wet themselves in the streets/take over the world?"

    What I'd really like to ask is, "Ah ... well ... you've got me stumped there. What is the air-speed velocity of an unladen swallow?"

    And before anybody cares to ask me whether that's African or European, I'm off for a Theakston's.

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

  • FredSaw (cs) in reply to real_aardvark
    real_aardvark:
    I'm working from home, and not (any more than usually) sick, so not only do I not feel guilty but I also feel a powerful need to go down the pub.
    We (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...
    real_aardvark:
    On the same argument (and I'm quite proud of this argument -- it's not often I get to contradict my own most deeply cherished beliefs), "least senior" is effectively the antonym of "most junior".
    (Sound of me flipping my lips:) Ehh, b'dee b'dee b'dee...
    real_aardvark:
    ...(SoylentGreenCorp?)...
    LOL! (literally, when I first read it)
    real_aardvark:
    Tie me to the Main Mast, quick!
    For a moment there I thought you were going to break out in the Aussie "Tie Me Kangaroo Down, Sport". But I see it's about those damned sirens. Speaking of which, If you missed out on the band Red Delicious with their song, "Siren", you really should look it up. Talk about your double entendres... whoa! The girl will have you ready to "throw yourself into her sea".
  • SomeCoder (unregistered) 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:
    1. How many releases did you do in the past year?
      • too few = scope creep: wtf management
      • too many = either too "agile" or qty > quality
    2. Why did the person who vacated this position leave?
      • hedging: something to hide
      • he "moved on" - why so vague?
      • specific real-sounding answer: probably ok
    3. What was the last disaster that occurred and how it was handled
      • all hands on deck for 2 weeks: lack of DR planning or code (or staff) is WTF
      • 2 hours to find and fix: system probably stable
    4. How much training did the folks on your team receive last year?
      • < 1 week: they want to pick your brains but not invest in you as an asset of the company
    5. How much overtime is typical?
      • very little: good project scheduling/QA: code is stable
      • hours each day: poor planning, wtf code/staff/management
    6. Depending upon the business: what is the size of the sales/support staff w.r.t. development staff?
      • 100:1 - lots of customers: probably stable code
      • 1:10 - very new, possibly unstable code - possibly new project (might be a good thing)
    7. What is your DR setup?
      • "George goes home and fires up his laptop" - no DR: run!
      • "parallel servers, dbs, etc" - someone thought about it and management funded it
    8. May I see your wiring closet?
      • birds nest: danger danger danger
      • pc's stacked on a refridgerator with fans on top: run!
      • nice and clean - good network support

    Relatively good questions and results... IF the company tells the truth :) Specifically, I can see a company saying "Oh, overtime is rarely required" when in practice, if you work less than 65 hours in a week, you are "not a team player"

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

    It's not a trick...it's an illusion. </gob>

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

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

    Lollercaust!1! A careless developer may not notice the typo, but if you don't know the difference between == and = you aren't any level of C developer. Might as well say some junior surgeons don't know the difference between heat and a heart.

  • Survey User 2338 (unregistered) in reply to Havok

    If RA is interviewing compilers this question makes perfect sense.

  • FredSaw (cs) in reply to Survey User 2338
    Survey User 2338:
    If RA is interviewing compilers this question makes perfect sense.
    I... he... y... uh...

    Huh? What question?

  • Pete Repete (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.

    Also there is a missing semi-colon.

  • GF (unregistered) in reply to gabba
    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.
    Spoken like someone who never makes mistakes and always starts his code from scratch...
  • FredSaw (cs) in reply to Pete Repete
    Pete Repete:
    The correct answer, of course, is "What would you like it to be?"
    Oh, yeah, I remember that from my freshman Sycophantics 101.
  • GF (unregistered) in reply to SomeCoder
    SomeCoder:
    Relatively good questions and results... IF the company tells the truth :) Specifically, I can see a company saying "Oh, overtime is rarely required" when in practice, if you work less than 65 hours in a week, you are "not a team player"
    I used to fall for that. If you're valuable to the company, they'll accept that your work is not your life. Otherwise, not, get out as soon as you can.
  • Velko (unregistered)

    Never make any mistaeks. -- Anonymous, in a mail discussion about to a kernel bug report.

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

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

Log In or post as a guest

Replying to comment #:

« Return to Article