What tips can you offer for programming on paper?

Question

In exams and interview situations, it's common to need to either write or review code that's not on a screen.

Whether it's on paper or a whiteboard, what tips can you offer for both the writing and reviewing/debugging processes?

Answer 1

Leave space between your lines in case you have to insert more code.

Answer 2

After writing each line, go over it TWICE - to ensure there aren't any bugs. It's a lot harder to catch them on paper rather than on a computer.

Answer 3

If you are being asked to do it, for example, in a job interview, please know what you are doing, and have a clue how to actually program.

True story: I asked an interviewee to write a simple program (it was FizzBuzz), and he had forgotten how to do a for loop.... I didn't bother with the rest of the interview.

Answer 4

• use a pencil
• start with your first line indented in case you later need to wrap it in something
• do a quick pseudocode mockup of your control flow before you get started, to avoid obvious mistakes
• avoid goto :)

Answer 5

Think like a computer. This may seem obvious, but it truly helps more than anything for the reviewing/debugging process.

To do this, start reading from the top, all the way down. Have a separate sheet of scratch paper so you can do any necessary calculations that the computer would do, or write out any complex array formations.

Don't do any complicated calculations in your head, or else you will not as easily pick up on mistakes in your code — write it all out.

Answer 6

Generally, don't. In an interview situation, if somebody wants you to write non-trivial code without a compiler, they don't live in the same world you and I do (where compilers tend to be available in a professional development environment).

That said, manually compiling the code in your head is a good trick if you know the language spec well enough.

Answer 7

After you finish coding, run through several "expected" cases (examples).

Then, switch hats and think about the code you've written as a tester looking at a black box - looking and outputs only. What kind of crazy inputs can you provide? Write them all out, without looking at your code. Then, after you're done brainstorming, think about what your code would do in all of those cases.

Answer 8

Bring your own whiteboard pen, it will make you look like a pro.

Answer 9

Practice! Practice! Practice!

Write complete code for at least 3 simple algoritms on a whiteboard (or paper). Here's the challenge for you:

• implement quicksort
• implement a single-linked list, with insert/remove functions
• implement atoi function

No cheating! You have to do it on a whiteboard, not on your computer. The point of the exercise is to test yourself in an unusual environment, not just test your coding skills. Also, in the process you will find the best way to use whiteboard, paper, pencil/pen, etc.

After you're done, either have someone you trust check your code, or type it on a computer / try to compile and test. Fix the problems on white board first, and test the fixes. Once you're done with this exercise, you will be psychologically prepared for the exam and will most likely pass it. Good luck!

Answer 10

My suggestion is to remember to have a few sections to the paper or board that you using to hold the pseudo-code:

1) Data Structures - This may be useful if you want to look at how objects are connected such as in trees, linked lists, or arrays.

2) Complexities - What is the big-O of your program in terms of time and space?

3) Tracing room - If you work through a couple examples of the program you may want a space for where to put temporary variable values and output to the screen or errors.

4) Question details - What were you asked to implement with what qualifiers and is this clear enough to start writing out a solution? For example are there time or space qualifiers such as an in-place sort or sort in O(n log n) time. What is the important complexity in solving this: Time, space or are they equal? For example, some problems may use a lot of space as a way to quickly store the data, e.g. how many 1 bits are there in each of the different bytes combinations that needs to have a constant time solution.

If you work through a few sample problems like Igor Krivokon's answer has with this kind of structure you may find it easier to be able to present what you did, why you did it that way, and that it does work within the bounds stated.

Answer 11

Whenever you put an open brace, put blank space and then a closing brace. It's better to erase and move your closing brace than to forget it.

Answer 12

Good grief, what will they think of next ?
Why would you want to write actual code on paper?
Why not option for chiseling it in stone instead?!

Don't get me wrong, I even did something like that in the past, but that was 10-15 years ago, and I had printed code where only small adjustments were made. And that was only because I was more comfortable lying on the couch in the living room than sitting by the desk. Completely different.

What you've got here is this scenario - instead of writing computer code, which is an abstraction per definition, on computer, and writing for example mathematical symbols on paper (which is another abstraction; the symbols, not the paper), you're writing actual code on paper. What good is that for ? What usage will come out of that, except showing off and similar uselessness ? (No, being able to do it does not make you smarter - some autistic people can do amazing things, but that doesn't make them smart).

Debugging ?!! Think about it ... the economy of the world is in enough bad shape without these idiocracies. And we're not helping it with this kind of thinking.

I sometimes think people come up with this kind of ideas because they obviously don't have anything useful to do at the moment. Having too much free time can be very dangerous in the hands of intelligent people.

Answer 13

Especially in an exam situation, it's pretty important to choose the shortest function / variable names as possible, while still being descriptive enough to explain their reason for existence.

Longish variable names are fine when you are typing, but if you are trying to write out a heap of code with long variable names, there is sadly a significant time penalty.

Answer 14

Use a typewriter.

Answer 15

if you are in a situation where someone ask you to solve a problem writing code in an interview, sometimes they are not only looking at the code itself but also the logic you use to solve the problem. You can answer with an excellent code, that compiles with no error/warning but you use a wrong approach or inefficient one, and then comes a not so good coder but with a better elegant solution and gets the job. For exams the thing its different, you should try to do the best solution with the right code at once, as someone else said practice a lot with exercises, i used to do test cases, draw a table where I put the variables, assign initial values and change those values as i walk through the code looking if the desired value is the one i get from the code (as a debug)

Answer 16

This usually only applies in an academic setting, so I'll assume that's the constraint--

First, use really clear names. Treat this more like you're writing an essay, since the instructor is hoping to see the quality of your thinking. Try to avoid single letter variables.

Re-read your own code when you're done and try to correct small errors. Missing semi-colons, mis-use of core language features, etc. are an easy "-1" for a grader, so try not to give them that chance. Grammar is enormously important when programming.

Comment your code (use your language's comment syntax) to explain what you're thinking. Again, even if the answer is a little off, if the instructor can see what you intended then you're more likely to gain points.

Lastly, try spending a little time writing small, real programs to test out simple ideas. You'll do better if you can shake out small mistakes from your program while you have the assistance of a real compiler and execution environment. One of the reasons instructors have you write programs on paper is to test how well you've learned the lessons of working in a live environment.

Answer 17

When I interview someone I give bonus points if they talk through a couple different scenarios before they start to fling code (on paper or otherwise). I would suggest talking through a couple scenarios. Then maybe sketch out a flow chat (really simple) or something.

There are a number of other good tips here too. I wouldn't want to repeat them.

Answer 18

I keep a Pink Pearl in my wallet for emergencies.

Answer 19

For school situations, find out what the prof wants. From my experience (professors differ), I've never had a prof ding me on little syntax mistakes when writing out code. For the most part, they wanted to know how I solved the problem and paid much less attention annoying little errors.

Answer 20

If your code involves manipulating linked-lists, trees, and other reference/pointer based data structures, then always always always draw a picture. If you're like me, this will help you more than you might expect. I've seen people struggle quite a bit at a whiteboard trying to reason through things from first principles, but a picture can help keep track of things, and demonstrates to an interviewer (if that's the context) that you know what's going on.

Answer 21

If you're using a whiteboard, make sure the cap the marker between questions! Otherwise it dries up and you'll have to recap and wait awhile before it'll write again.