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:

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 works((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.