12

A 'bad code' interview is one where the interviewee is shown a snippet of 'bad code' and asked to correct it or point out things that are wrong with it. I have trouble with these interviews because it takes me some time to read the code, figure out what its doing, and point out the flaws. In a situation where there's time pressure, I tend to freeze up and I see that the code 'should' work, even when it doesn't.

What's a good way to handle this sort of interview, and, more generally, what are some good techniques to read and understand code quickly?

quanticle
  • 955
  • 7
  • 14
  • 8
    Why "quickly"? If you need time to think, what's wrong with taking time to think? – S.Lott Mar 29 '11 at 19:08
  • Is this part of written/aptitude test ?Then you need to do your homework on such type of tests for companies in concern. – Aditya P Mar 29 '11 at 19:15
  • @S.Lott Well, I mainly wanted some techniques that would help me avoid cognitive lock in that sort of situation. Techniques that can be applied quickly tend to work better for me. – quanticle Mar 29 '11 at 20:10
  • @AdityaGameProgrammer Well, its not a written test. You're handed a sheet with source code on it, and you're expected to go through the source and discuss its shortcomings. It would actually be better if it was a written test, as I feel less pressured in a written format. – quanticle Mar 29 '11 at 20:13
  • @quanticle: How is "stop and think" not the first "technique" you would use? Indeed, what other possible technique is there than "stop and think"? – S.Lott Mar 29 '11 at 22:28
  • The best technique to read and understand code quickly is to practice. I used to forgo documentation and instead read the implementing code. – dietbuddha Mar 30 '11 at 00:33
  • ["That's When I Blow It"](http://www.youtube.com/watch?v=jCyaXh-VZco) – jmq Mar 30 '11 at 00:44

9 Answers9

18

Bad Code Interviews (if they're properly done) should show you code with the following:

  • A bad language technique (not using the using statement in C# when needed, or using an ArrayList instead of a List<T>)
  • A bad design decision (why the heck are we passing strings everywhere, or using ref and out parameters so much?)
  • Syntax errors (This shouldn't even compile!)
  • Run-time errors (such as a Stack Overflow caused by a property referring to itself in C#)

There's a mental checklist you should go through, hitting each of the points above. If you can't look at code and do that, that's a point of improvement. Whatever language you claim to be 'proficient' in, you should be able to look at a block of code and point out those four types of errors.

I recently blogged about a piece of code that exhibited all these problems, it should help you to go through the same mental process.

Ayende takes it deeper with his Wages of Sin series.

George Stocker
  • 6,388
  • 2
  • 31
  • 55
  • Thanks for the checklist idea. Its all fairly 'obvious' stuff, but in the situation its easy to lose track of some of those things if you don't consciously keep them in your head while you're reading the code. – quanticle Mar 29 '11 at 19:29
  • Great blog post. Always funniest when the piece of code the expert holds up as an example has massive bugs. I'm hoping my comment doesn't continue the bug demonstration you and Scott have going. – Ben Voigt Mar 29 '11 at 22:00
  • The other thing that is used in bad code interview is logic error. For example, they show you a small function, they tell you what it's suppose to do and you have to tell them why it won't do it or in which case will that not work. – HoLyVieR Mar 30 '11 at 02:50
  • +1. One more point for the checklist: Check how the code handles border cases (Empty list, empty string, 0, Inf/NaN for floating point numbers, a `List` that contains `null` elements...) – nikie Mar 30 '11 at 08:12
9

Don't try to understand it quickly. The goal here is not to see if you can understand the code like a guru, but rather to see how you think.

The key IMO is simply to think out loud. So even if you freeze up - then just just say, "I am stressing here, but let me go through this slowly out loud".

Assuming you have the skill thinking out loud will slow you down enough to get your mind right. If the interviews are savvy enough they will see your situation and help you along until you are thinking clearly. They are not out to try and trick you into looking stupid - just a powerful technique to seeing how you think.

Stephen Bailey
  • 2,236
  • 14
  • 14
2

Odds are, the 'time pressure' you feel is entirely self-imposed. It has more to do with your own feelings of insecurity and worrying over how well you measure up.

The best advice anyone can give is: Relax. Take your time, look at the code and just talk about what you see as you see it. Feel free to talk about the good parts as well as the bad; it will help reduce your nervousness and inwards worries that too much time is passing.

In addition, going through different 'passes' might make it a bit easier to spot specific details. Take one pass looking for mismatched braces or typos. Take another pass looking for obfuscated lines. Take another one looking for semantic pretzels. Focusing on one type of "wrong thing" might make it easier to spot those details and (again) reduce your inner voice questioning whether you're doing it fast/well enough.

Above all, talk thru what you're doing and thinking - it will help you and the interviewer both.

Tim O'Neil
  • 277
  • 2
  • 3
1

I've never been in this kind of interview, but when I'm trying to work on a tricky piece of code that I may suspect of being bad, I sometimes talk quietly to myself. I find vocalizing sometimes helps problem-solving. Also in an interview, you could try tracing the steps of of execution as a diagram or something with a pencil and paper. This used to work for me in school, still do it sometimes at work. YMMV, of course...

FrustratedWithFormsDesigner
  • 46,105
  • 7
  • 126
  • 176
1

I would think a good place to start (if you don't see anything obvious) would be by "debugging" it. Unless you see possible issues right off the bat, a good place to start is to make a small list of test values. Good values are a 'happy path' (normal) value, a 'zero' or 'empty' value, nulls, a very small value (a 1-character string, the int 1, etc.), a very large or very long value, and 'strange' values specific to the type (e.g., Unicode characters for strings, negative numbers for ints, etc.). It wouldn't hurt here to mention that normally you would write unit tests using these values to test the code, and would just run those to verify the function.

Start by walking through with your happy-path value(s). For an addition function, you might start with 3 or 4. Examine each line for typos and logic errors, tracking the values of local variables as you go. Hopefully, you find a few bugs. When you get done with the happy path, you will have a better feel for the code and hopefully will feel a bit less overwhelmed - so say something like, "Now that I have a better feel for what this code is doing, I'm going to step back and take a look at it," then do just that - looking for things that stand out to you as things you would have done differently (bad design decisions, poorly named variables, investigate possible bugs, etc.).

If that isn't getting you anywhere, or if you feel like you've run out of things to say, return to your list of test values, and walk through it again with a new one that you think is likely to cause problems.

This will at least get you going.

Ethel Evans
  • 5,329
  • 1
  • 23
  • 42
0

As Stephen Bailey have said, thinking out loud is an excellent technique in this situation as it allows your interviewers to see your thought process. Sort of explain what you are trying to figure out. The other thing you could do is to let the interviewers know that you are going to read through the code properly before providing a diagnosis on the badness in the code. I have been on both side of the table and I know it can be frustrating for both side in these situations.

tehnyit
  • 1,469
  • 2
  • 10
  • 16
0

If you feel less pressure doing it as a written test, then pull out your notebook and start taking notes. I've pulled out a notebook and started sketching out notes as part of my thinking process in an interview. Having a notebook and pen makes you look organized even. You might write down a few bullet points of things to look for, syntax, logic errors, data type mismatches, values of local variables (the list may vary depending on the type of code you got, my list for a complex piece of SQL would be different than someone who got a piece of code that wasn't data centric) as you go through the process, etc. Once you have written a few of these out, then start looking for them. That way even if you don't find all the problems before the interviewer wants to move on, he/she will be able see a list of the things you were going to check. If you create a checklist beforehand of things you might want to look for, then you will feel more confident starting the process knowing which things you have planned to look at. Usually these qiestions are more about how you would find the errors than actually finding all of them.

HLGEM
  • 28,709
  • 4
  • 67
  • 116
0

I'm a bit late to this party, but one technique you could use would be to write unit tests for the code in question. Then you can concentrate less on what is subtly wrong with the code and more on what expected results you are looking for. I'd rather hire someone who can write good tests than someone who can immediately spot what is wrong with a piece of code.

Chris Knight
  • 702
  • 5
  • 12
0

There might be two issues:

It might be a "stress interview" http://en.wikipedia.org/wiki/Job_interview#Stress. Interviewer is trying to see how you cope with stress since their working environment is such.

OR

You might be getting stressed yourself. In that case you will have to manage this stress, E.g. introspect and see how you can remain calm.

Shamit Verma
  • 759
  • 4
  • 9