To Interviewers: stop asking questions about bugs

It’s a strategy since early 90s, at least, for the interviewers to ask questions about bugs. It’s a bad strategy and this tendency should stop: not only you don’t hire compiler writers, but you don’t necessarily want your hires to understand buggy code, you want them to write bug-free code.

I found this set of slides on the good old interwebs. It’s an interview about deep C and C++ knowledge, that brings no surprises to anyone. Please have a look at the slides, where the male is portrayed as the ignorant one and the female as the smart one, in the most politically correct manner.

I like the beginning slide. Programming is hard, it says, Programming correct C and C++ is particularly hard. And it goes on to say why – because you can write tons of sloppy code. And the presenter goes on to talk about how simple examples can be tricky. And they are. Here’s a slide with the dumb (aka less knowledgeable) male at work:

BugsInInterviews

The point is that in this case the interviewer is wrong. Not technically wrong, but my question in the role of the dumb-ass would’ve followed: “This is how you write your code? Because if it is so I don’t want to work for you”.

I actually had this dialogue and not only once. I’ve been through enough interviews to know that I don’t want to work for a firm where understanding how bad code works is important. Because what you see there in the slide is bad code from many points of view. Allow me to show you why the code is bad:

  1. Use of global variables.
  2. Functions that receive hidden parameters by using said global variables.
  3. Functions that have side effects
  4. Caller that relies on those side-effects.
  5. Repetitive code that is not caught into a loop.
  6. Use of uninitialized variables.
  7. Assumption that printf works1)this is a particularly tricky one. What does printf do? For example if you’re inside a UI application, windowed, it probably does only bad things. Of course, this is nitpicking, but why not nitpick when the interviewer does the same thing?.
  8. Unstructured output (you see three numbers, without any sense attached to it).

We basically have 6 lines of useful code and 8 different issues. It’s the kind of code that makes me get up, shake the hand of the interviewer, and wish him all the best. You don’t want to keep these people too much, they are busy people – usually they take a lot of time fixing bugs in their code. Your time with them only keeps them from writing more buggy code, and you should let them do just that.

If you want to help them, cut the interview short, and go to the HR staff. Tell them that they chose a horrible coder to interview you, and that they should be more attentive about the staff they hire. And leave, because otherwise they’ll hire you to lead the team of many such people for which the understanding that uninitialized variables are initialized by default with 0 is important.

The point is that if the code doesn’t say it it might be or might not be true. And I’ve seen enough compilers to know that if the standard says one thing that’s not a guarantee that your compiler does that properly. I’ve seen enough compilers to know that doing things explicitly is way better than relying on other components to work implicitly as you’d expect.

This is just one case from many. That pack of slides is full with such non-sense in which the male is apparently a moron (but he might be the moron to maintain this crap) and the female is the uber genius that is not able to correct faulty code because she understands it and sees nothing wrong with it. She even quotes the standard!

If you go to an interview and get harassed with bad code, you don’t have to stay put and say nothing. We’re still in an era when good programmers will not die of hunger, so you still can choose not to associate yourself with these people, so when you see bad code just say no and leave. This is especially true for big firms, but dreadfully unavoidable in smaller firms. Just go.

NOTES   [ + ]

1. this is a particularly tricky one. What does printf do? For example if you’re inside a UI application, windowed, it probably does only bad things. Of course, this is nitpicking, but why not nitpick when the interviewer does the same thing?

Comments

To Interviewers: stop asking questions about bugs — 16 Comments

  1. Sounds like you should be interviewing for a language without all those tricky parts.

    On the other hand, if you’d actually knew all the tricky parts you’d be pretty disappointed if no interviewer asks you about them, ever.

    • One should never interview for a particular language. Sure, you want core language concepts to be covered, but these are quite far from ‘core’.

      If you’d knew all the tricky parts you’d probably write bad code just because you know the tricky parts. I hate programmers knowing tricks they don’t need to know. It makes sense sometimes to have people that know those tricks. But what you generally want is to have people that can write good clean and clear code.

  2. Unfortunately, mistakes happen, no matter how good or experienced the developer is, and it could be because of lack of attention, bad day, etc. I remember the old days as C++ programmer, I did this mistakes, although I knew the best practices and dos and don’ts. My advantage is that usually I spotted fast the mistake.

    So, if I have to work with a C++ guy, I would like to make sure he is able to detect fast this kind of mistakes. Some of them are really intricate and can put down a backend system.

    • I’m not much of a programmer, or any sort of a programmer, but I think I’d prefer to have someone who can say “int a; a++; printf(“%d\n”, a);” is a problem because it reduces code clarity and increases the chance for future errors, rather than somebody who can tell me what gets printed.

      I guess knowing what the defaults are is a plus, if you want to debug what your interns did when you weren’t looking, but otherwise?… I’m not convinced.

    • Many times is not debugging what interns did, but what your (experienced) colleagues did, or (as mentioned in my comment) what I did.

    • I know that as an expert it’s easy to let code that does strange things fly because they are not unexpected for the one writing the code. For example, relying on the static variable to be zeroed first is one such thing that an expert would let fly because they know what it does. But a developer that gets corrected for not properly initializing the variable will be better off on the long run.

      To be honest, the expert responses as well as the non-expert responses in the slides attached are both horrible. Not once do the interviewees say that the code is bad and crappy. And they should.

      This sort of interviewing does select some sort of people, they might be better at knowing the intrinsics of a certain compiler but they are bad overall. The mantra of quality cannot be maintained by knowing how bad code works, but by pursuing better code constantly.

      Including in interviews.

    • Dorin, I am not even referring to intentional mistakes (AKA “hacks”), but to unintentional mistakes.

      For that specific example you put, I agree with you. There is a best practice I know that don’t declare a variable without initialize it (and goes hand in hand with RAII).

      I would definitely not select people based on their knowledge of a specific compiler, but I would appreciate the capability to fast track a mistake/bug, and to detect best practice “breach”.

      I used to present code samples just to see if people react to bad practices. I was most of the times disappointed. But… when somebody reacted, I was (almost) sure that person is interested in writing robust code. (Am I old school?)

    • I feel old school for writing this post, so we probably are old school 😀

      Interviews are tricky things, I know. Not all the time people realize they can complain about bad code in the samples you showed them. I, for one, prefer to ask people to write their own code, and see how they can write bug-free clean code solving well defined problems by themselves.

  3. Any correctness problems with the code underneath? (insert evil emoticon)

    It’s a simple structure, with a comparator first look at the string, and then if the strings are equal, look at the value. It’s a bit inefficient, as it compares the strings twice, but that’s not an issue here.

    struct St {
    std::string str_;
    double val_;
    };

    bool operator<(St& a, St& b) {
    if (a.str_ != b.str_) {
    return a.str_ < b.str_;
    } else {
    return a.val_ < b.val_;
    }
    }

    • @Vlad: Is this a test 🙂 ? Two missing consts here: bool operator<(const St& a, const St& b).

      About why to use const references? Some reasons from top of my mind: starting from constraining the usage of the written code (generic reason), that the body of the operator doesn’t change the parameters, that in general, changing the value of the passed objects as side effect of a function would be hard for code maintenance and readability, and that you will not be able to pass temporary objects to the operator, like in auto result = St() < St(); (I know this statement doesn’t make sense, but… for the sake of argument…)

    • Yeap, const is awesome and I was const-lazy :). Feel free to add consts, and maybe also a St&& version. All good for improving maintainability, readability, etc.

      However, that’s not the bug, which is far more obscure. And FWIW, I didn’t figure out the bug, it took a team months to figure it out (though they weren’t working just on that bug).

      Hint 1: val_ is a double.

    • @Vlad: Why is this a bug? The bug is either in the code that generates the nan value in the first place or in the code that assumes that St::val_ cannot be nan. The struct in itself does exactly what the c++ standard tells it should do with nan values.

      But this reminds me of a wonderful piece of production code that z-sorted a couple of thousands of GUI elements (stored as 3d objects) by calling the equality operator on said objects’ screen-space z value. Needless to say, it did quite a bit of sorting. Per frame.

    • @Cantrem – let’s say you have three values, all with the same string, a: {“A”, 1.0}, b: {“A”, NAN}, c: {“A”, 2.0}. a < b returns false, because of the nan. b < a also returns false because of the nan, so effectively b == a. Similarly, b == c. But a < c.

      This is not a proper ordering, because it’s not transitive. To be standard-precise, the < operator I showed above does not describe a strict weak ordering if nans are present.

      C++ ordered collections rely on strict weak ordering guarantees, and if you stick stuff in them that violate the strict weak ordering, well, it’s undefined behavior. There are standard compliant implementations that will even segfault in the presence of violations.

      https://www.sgi.com/tech/stl/StrictWeakOrdering.html

      Sure, if you never have nans there’s no problem.

    • Yes, but let’s not discuss corner cases in interviews. 🙂 Nobody believes that they will ever write perfect, bug-free code. But in interviews we can write simple snippets that are good enough and avoid the corner cases that are not really relevant.

Comentariul tău