I actually think it's possibly the most valuable skill you could practice at university. 99% of programming interviews involve hand-written code on whiteboard or legal pad. Don't be that schmuck who can only write compiling code with an IDE and Intellisense.

That's great advice, thanks! I used Sublime for this reason the first year, instead of something like Eclipse. When discussing algorithms and concepts, writing by hand is fine by me, but it gets worse when you have to memorise some API and build a GUI..

Refactoring just gets so hard with pen and paper.. :)

I've always figured this was the exact point of such tests, it forces you to think about how you are going to design things, and think ahead about what it means to do such things.

I had to write code using pen and paper when I did exams. At the time I argued with my lecturer but, his argument was that when he used to work as a developer all programers had to write their code by hand and then it was given to a secretary to enter into the mainframe and then they would have to wait 24 hours to see if their programs had actually run.

Nowadays I find it useful because nearly every programming interview will involve writing code by hand either on a whiteboard to pen and paper.

I'd echo the point about programming interviews. It's also worth noting that, even in these days of fancy debuggers, getting away from the computer screen with a program listing and doing some old fashioned desk checking is still a useful debugging technique. Programming with pen and paper is good practice for/demonstration of ability at this. Being expected to write 10-20 pages of code this way does seem excessive though.

Being expected to write 10-20 pages of code this way does seem excessive though.

That was the other reason to have written code on exams - it makes students think about whether they are solving the problem in a code-efficient manner.

The optimal solution would typically be around 5-15 lines in length, but a solid handful of students would still hand in multi-page solutions. You'd get full credit for a working solution regardless, but the chances of bugs in your hand-written code goes up exponentially with length.

All our exams and tests were paper and pen programming, though it was a mechanical engineering university, so that means 3 final exams (I don't know the proper term for the exam at the end of a semester) in total and some tests. I remember once having a 2-hour paper and pen test while being drunk. It was extremely hard to focus, but I got a B.

I did coding exams on paper for all four years of college. Granted I was never brought to the extremes of your experience, writing 10-20 pages for a question. I did have to write multiple pages one time and gave up and left a note explaining how stupid this was to the lecturer. Got an A1 so he cant have minded too much. But I do agree its important for interviews. You have to rely on your own knowledge there to write things out. It can also be useful to know certain algorithms or functions off the odd time.

Don't be that schmuck who can only write compiling code with an IDE and Intellisense.

Its not about being schmuck!

Its about focus!

When your mind is distracted by syntax, and secondary structuring then you have less focus (and thinking strength) for the core algorithms!!!(except if its trivial)

I see absolutely no advantage of coding on paper for exams and interviews. The fact that interviewers, very very stupidly (and arrogantly), choose to do interviews this way doesn't mean they are right. In the real practical world good IDEs help you to focus on what matters at that stage. Except if you are doing something really trivial your focusing strength and thinking power is at a premium and you need all of it for the core algorithm. Eventually everything matters, even secondary restructuring and design.

I've always figured this was the exact point of such tests, it forces you to think about how you are going to design things, and think ahead about what it means to do such things.

Nah! Design stage is a separate thing, There is a time for it and you need to fully focus on this stage too. But coding on paper directly in exams, interviews ??? Utterly senseless, useless and counter productive

I actually do algorithm analysis on paper a lot. But as an interview test and exam, it is the most stupid and dumbest act practiced by bosses today

A lot of times i am coding, i'm mentally fully immersed in the structure of the program so i generally have no problems with writting code directly if need be. But the times i've done tests on paper has been the times when i've been mis-judged the most, because it ends up being so messy, not because the core algorithm is wrong but because - whereas in an IDE i can insert variables, make room for a loop that i didn't forsee... on paper you have do that- you get very messy!!

Don't be that schmuck who can only write compiling code with an IDE and Intellisense.

Its not about being schmuck!

Its about focus!

When your mind is distracted by syntax, and secondary structuring then you have less focus (and thinking strength) for the core algorithms!!!(except if its trivial)

I see absolutely no advantage of coding on paper for exams and interviews. The fact that interviewers, very very stupidly, choose to do interviews this way doesn't mean they are right. In the real practical world good IDEs help you to focus on what matters at that stage. Except if you are doing something really trivial your focusing strength and thinking power is at a premium and you need all of it for the core algorithm. Eventually everything matters, even secondary restructuring and design.

I've always figured this was the exact point of such tests, it forces you to think about how you are going to design things, and think ahead about what it means to do such things.

Nah! Design stage is a separate thing, There is a time for it and you need to fully focus on this stage too. But coding on paper directly in exams, interviews ??? Utterly senseless, useless and counter productive

I actually do algorithm analysis on paper a lot. But as an interview test and exam, it is the most stupid and dumbest act practiced by bosses today

A lot of times i am coding, i'm mentally fully immersed in the structure of the program so i generally have no problems with writting code directly if need be. But the times i've done tests on paper has been the times when i've been mis-judged the most, because it ends up being so messy, not because the core algorithm is wrong but because - whereas in an IDE i can insert variables, make room for a loop that i didn't forsee... on paper you have do that- you get very messy!!

I had two paper coding interviews. In one, I did almost all the tests but made some mistakes even fundamental ones. But there was something to talk about on the interview, and I would have got the job, but I rejected (the interview was a result of a recruiting event, so I knew something about the company, but nothing about the job position).

The second interview had mostly C++ coding and very specific C++ questions, so I hardly written anything on the paper, so I failed.

On many interviews, they want to see how you think, they want to see that how you start working on something you don't have knowledge about yet (don't ever leave questions without any answers, try to think, and at least write about how you would approach the problem). They are looking for candidates who can do the work even under some stress. People who sit tomfool at a paper without trying to work on questions they don't know from the top of their heads because they are either lazy, or dumb, or panicked on an interview are certainly not good candidates.

I think the thing we all agree upon is that writing things out by hand is a useful skill, and if the test requires you to write a function or two, it's okay. Even useful, since a lot of interviewers ask for this. But being asked to set up a multi-class system, including GUI, with all lines included is a bit nonsense. We did class diagrams, we did other UML diagrams too. Shouldn't that be enough? And then showing some interesting algorithms fully coded to prove that you actually know the syntax and can manage to create a good implementation?