Are Written Computer Science Exams a Fair Measure?

me! asks: "I seem to have this inability to write substantial chunks of code (500+) in exam conditions (for uni). I have been writing code for years for open source and commercial applications, so I know a thing or two. There is just something about exams and code that does not work for me. I find that I need to be sitting in front of a computer to get a problem out, to get in the 'vibe', have you will. I have done exams on computers (closed environment) that involve coding, and it work so much better for me. So what I am asking is...how do people tackle exams that involve solving problems on the fly, on paper, in exams?" I have this exact same problem, and I've never thought written tests were a fair way to measure someone's knowledge of coding. It's fine when you are asking questions about design and structure, but when you need to write code it falls way short. How do you feel about it?

Comments

Re:simple

[The Kow]

Yeah, that works really well in the current job market. I dare you to try to find a job right now with what you had on your resume when you first got into the industry.

Agreed

[the_mystic_on_slack]

I cannot say that I have this problem so much, though every time I have taken an exam which forced me to write code, we were allowed to cite a previously written function or whatever. In the cases where a completely new solution is needed though, I agree, the paper thing does not work. I feel much more comfortable on a computer than writing frantically. Giving exams on computers provide significant challenges for honesty though too. My two cents worth.

Re:Agreed

[iapetus]

I cannot say that I have this problem so much, though every time I have taken an exam which forced me to write code, we were allowed to cite a previously written function or whatever.

Answer 1
Refer to method public void passExam()

Re:Agreed

[PotPieMan]

I think you left out part of your answer:

package dataStructures;

public class FinalExam {
public boolean pass() {
return true;
}

public int grade() {
return 100;
}
}

AP Computer Science

[jeeryg_flashaccess]

When I took the AP computer science test in high school we had to code on paper! I'm just like you...I get my vibe when I am in front of the computer coding, not with a pencil and paper.

My highschool had 2 computer labs that would work perfect for such tests. I'm glad you brought this up, it always irritated me.

Re:AP Computer Science

[DMDx86]

When I took the AP computer science test in high school we had to code on paper! I'm just like you...I get my vibe when I am in front of the computer coding, not with a pencil and paper.


Well, I will be taking AP Computer Scince next year. I have seen copies of the test, it seemed pretty resonable, IMHO. How did they grade your exam? Did they give you oppritunity to contest the grade if you felt it was graded incorrectly?

Re:AP Computer Science

[jedidiah]

What? They don't have student loan programs where you live? Learn how to effectively exploit them. This may require moving to another state to establish residency there if your own state schools are too expensive.

Re:AP Computer Science

[Yunzil]

but the main one was that one teacher thinks that code on paper is just as good and efficiant and everything as acctually putting it into the computer

Well, it's like this. If you can't explain yourself clearly in plain text then you don't understand the problem. No one exists in a vacuum. If you get a job in the industry, some day you will have to write a report on why your company should buy certain piece of software over another, or stand up in a meeting and explain to your manager why the proposed timetable is ludicrous. And you will have to do it without writing code.

The true test of whether you fully grasp a concept is if you can explain it to someone who has no knowledge of the subject. Your teacher's test is an interesting idea.

Ob spelling flame:
Your post was filled with spelling errors. Are you sure you're ready for college?

..treat as real code?

[Archon-X]

..I too used to suffer this - we used have to write chunks of code, and it was frankly painful. I found the best thing to do was use copious amounts of scrap paper, and develop the code like you normally would on a workstation...

ie, get your structure down, then start to flesh it out, a page for each method etc. That way you can 'grow' your code a syou normally would, and don't feel pressured to write it all top-bottom-with-no-mistakes.

Re:..treat as real code?

[xtremex]

I get test anxiety. For example, I have WRITTEN tests for UNIX, and I've been workign with UNIX for more than a decade. However, I had to take a "test" for a job interview, with a pencil and a timer no less. Something as simple as the lpd port..I went blank. I start to sweat and I panic. That's why I had to take my finals over 4 times in college! I have a friend who is a lawyer..a damn good lawyer..he has to take his 27 times! Because of test anxiety. He can quote the NY State Law books from memory, the minute he's "tested", he turns to Jelly...

Error checking by compiler

[Anonymous Coward]

Is the reason you don't do well on the tests because your hand gets tired writing so much code or because you don't know if you are doing things right because you can't compile and see where your errors are. For me it is easier to think of my code as communicating with other programmers my ideas. Writing in this style is easier on paper.

Re:Error checking by compiler

[heybrakywacky]

first of all your teacher does not want a compiler to check your work.. you are supposed to do it yourself...

You're supposed to write perfect code the first time around? I agree that it's an interesting test of your knowledge of a concept, but it's completely unrealistic from the standpoint of what you would do in real life (as much of academia is, I'm afraid). I can write code that is pretty close, debug through compile and runtime errors, unit test for missed functionality, etc., and have something working in half the time it would take me to attempt to do all that on paper, analyzing each statement "by hand." Is this not the way that 99% of all developers work?

and second, you should not be looking up stuff with man if you ever get a job... just wait untill the boss finds out that your spending your payed hours learning how to code when school should have taght it to you...

I use man as a reference, as I would imagine most people do. I don't keep every last detail of every function or program I'm going to have to use in my brain.

I know that both of these arguments are somewhat counter to the purpose of academia. I have an HP calculator that will do integrals for me too, but can obviously see where that wouldn't be allowed on a calculus test where you're demonstrating your ability to integrate. But as for writing code on paper, it just never made much sense to me. It's completely outside the medium for which it was intended, and completely counter to the process which most developers use to write code.

If you want to test someone's knowledge of a computer concept/algorithm/etc., have them write detailed flow charts. Get 'em used to it. Make UML requirements. These are the kinds of things that not only make for good development practices, but also will have a practical application when students actually get out of school and start working.

My $0.02

Re:Error checking by compiler

[Iffy Bonzoolie]

just wait untill the boss finds out that your spending your payed hours learning how to code when school should have taght it to you...

Well, I don't think that's fair at all... You are paid to do a job, and it's easy to be effective without memorizing tedious information. Compilers are better at finding missing semicolons or parentheses that you are. Why not let them do it? You might know what a library function does, and how to use it, but maybe you forgot the order of the arguments. Sure, a guess probably won't compile, but it doesn't mean you are a bad programmer. I'd rather work with someone who has a strong grasp of OOAD and can learn the specifics on the fly than someone who can write code that compiles every time out of the gate, but doesn't "get" the whole "objects" thing. (At least in my case, where we work in an OO environment.)

Part of being a good programmer is using the right tools to maximize your effectiveness. The compiler is a great syntactic and semantic validator. Let it do that for you. The manual is much better at retaining information about specifics. Let it do that for you. As long as you can use these tools to craft quality code, then you are being effective. There's insignificant cost to running the compiler twice as often, or looking something up in a manual or on the web. You tend to memorize the things you use really often, but what you use can change from project to project, or release to release. It's hard for an employer to find someone who already knows everything exactly that they want... and when they get them, they may not be as effective/productive as someone who has to learn part of it on the job.

If it's a class in Specific Language X Syntax, then maybe that makes sense, but that's a useless class. At my school, we did a lot of hand-writing code on tests, but usually pseudocode was sufficient to get full marks, and you could get good partial credit if you had the basic idea. The focus was not on details like syntax, but on the concepts, ideas, paradigms of the subject (compilers, operating systems, computer graphics, or whatever).

You are hurting yourself if you stop learning once you are out of school. Technology is always moving and changing, and what's available and how to use it might change on you, you have to adapt. You should always be learning, 1 year after school, 10 years after school... why stop? No one I know at anyplace I've worked ever expected anyone to know everything about what they were supposed to do. They care about results... providing those requires being able to learn effectively on the job, because who knows what you might be doing next release, next project, next company... Being versatile will get you exceeding expectations all the time. Success is rarely about what you know, but how quickly and how well you learn, and whether you can make use of it.

-If

Re:Error checking by compiler

[dakoda]

"Part of being a good programmer is using the right tools to maximize your effectiveness. The compiler is a great syntactic and semantic validator. Let it do that for you. The manual is much better at retaining information about specifics. Let it do that for you. As long as you can use these tools to craft quality code, then you are being effective. "

Exactly =) Programming, as a career, is _not_ memorizing all the man pages, but knowing how to use them quickly, and learn on the fly. Every task you do is likly to be different, so why bother memorizing everything? i, for one, use them for function argument order, which i never remember because all the libraries i use have slightly different orders.

I suppose it'd be better to think you get it right, only to find a logical error somewhere down the line when you provide the source and dest structs in the wrong order..? right ;)

Re:Error checking by compiler

[susano_otter]

No, it's more like saying "grammar is important only where it supports communication". Normal people don't set out to create grammatically perfect sentences. That way lies madness. Instead, they try to communicate. They use exactly as much good grammar (or local idiom) as necessary, and don't sweat the rest of it.

Re:Error checking by compiler

[Alex Belits]

I cane sink of a Lott of cases very a spell checkers Voodoo worse Zen a hue man.

On the other hand, when a time is limited, compiler helps with misspellings and minor errors while not affecting things that exam is really for.

We did these at the Rochester Institute of Technol

[Anonymous Coward]

It really depends on how it's graded. I had some Prof's that would grade based more on the understanding of the problem. They would look at the code as more of a structured psuedo-code, rather than something they thought would compile.

I've also had profs that would take a point off for each syntax error...

I feel the same way

[scode]

I have no resect for any exam that involves writing actual code on paper. Asking about fundamental principles is fine; asking for pieces of code or specific API details is IMO rediculous.

Granted, you can never design a perfect test. But you can at least do away with the totally obvious imperfections like asking people to do things in ways they never do and never will do in the future (except on other tests).

The few times I was subjected to these tests, I sure felt primitive erasing entire chunks of code after having realized I needed to insert something in the beginning. And it's a hard thing to avoid; I don't think any reasonably experienced programmer writes code entirely from top to bottom. Just a simple thing as placing braces becomes a hurdle in writing unless you know the length of the code you need to put between them!

Re:I feel the same way

[MobiusKlein]

Jeeze, it's not so bad. In upper division and graduate math classes, they have you write proofs in exams.
You have to
1) Remember definitions.
2) String statements together in logical, consistent groups.
3) Reach the proper conclusion with the hypotheses given.
4) Justify interesting or tricky steps.

Sounds a lot like creating code in an exam situation. A reasonable professor (or TA more likely) will read the code/proof looking for the the correct ideas and flow more than perfect pedantic correctness. At least that's what I did when I graded for upper division classes.

rbb

ps - use scratch paper to avoid erasing.

Re:I feel the same way

[AJWM]

You miss the point.

Indenting is relevant to this for the same reason that Python uses only indenting, not braces or begin-end, to indicate block structure.

Yes, one school of coding in a text editor is to place the open/close braces first and then fill in the code. As you say, that's tough to do on paper. It's also a crutch.

Another school says indent your code properly and the braces are superfluous, just there for the compiler (for non-Python languages).

If you follow the latter train of thought, you just put in the closing brace when you're done filling in the intermediate, indented code.

Re:I feel the same way

[ginsu]

Really, it is very very rare that a professor or grader could care less if you have correct syntax or even correct function names. As anyone who's tried writing code in a editor which doesn't balance parentheses (after being used to one which does) knows, today's editors (vim/emacs/IDEs) make it easy to lose simple syntax skills. That's not what they are testing you for.

What you are being tested on is your ability to pull, from your own head Algorithms, Data Structures skills, etc. (Can you sort without cutting and pasting code from somewhere else? Can you create a good linked list in 10 minutes on paper?) You are also being tested on your ability to do a design (in this case, a VERY SIMPLE design most likely) and execute it. If you, as the poster mentioned, feel the need to erase "large blocks" of code, you probably didn't think the program out well enough ahead of time.

Can you create new ideas/code? Or are you a 'clay pusher' -- one who can make any 1 block of code do any other thing, but has a hard time creating it from scratch.

As previously mentioned, these skills are, more importantly than on exams, used during job interviews. I've yet to have an interview where I didn't at least write some code. And you think it's hard to do it in a lecture hall where you have 2 hours to finish the whole test? Try doing it in an interview with the interviewer sitting across the table from you watching you think, and you have a 5 minute time limit :)

There are a few tactics which make this a lot less painful.
(1) Whip out a design before you start writing code. This could be anything from a flowchart to a picture of the memory buffer you'll be modifying.

(2) Remember the old 'Basic' trick of line numbering? (Start by numbering things 10, 20, 30, 40 ... -- then if you have to edit code later, instead of re-entering the whole program just add a 'line 11, 12 and 13.') Apply that to paper. Space things reasonably widely, write small. You can also write blocks of code and 'insert it' into the correct place with arrows. As long as its readable, graders usually could care less.

(3) When you write your own code, try to practice coding it without refering to any other code. Pull what you can out of your own head without referring to that marvelous brain-extension, the internet (Hard discipline to keep if typing 'google.com' is as natural for you as it is for me!) or referring back to already-written code.

My biggest problem with handwritten tests is irrespective of having to write code or not . . . after all these years on a keyboard, my handwriting SUCKS. :)

Re:I feel the same way

[scode]

Of course they have - a pretty good idea. You don't write the entire program line-by-line mentally first (at least, I've never heard of anyone doing that).

Part of programming is creating abstractions and factoring code. You don't keep the source code and state of the entire program in your head at one time. You deal with the relevant parts. For example, suppose I were to write a method that answers the absolute age difference between two people.

First, I'd worry about the method at hand:

absoluteAgeDifference: aPerson
^self (ageDifference: aPerson) abs.

This implementation is completely independent of the implementation of Person>>ageDifference. After writing that method, I would implement #ageDifference - unless it already existed:

ageDifference: aPerson
^self age - aPerson age.

This is my normal way of doing things. If I had to do this on paper, I would have to think through dependency methods first in order to calculate what will fit where.

But to get back to the issue of braces. Suppose I needed to write code that answers the most wealthy relative of a person. First, I'd probably write:

mostWealhtyRealtive
"Answers the most wealthy relative of the receiver, or nil if the receiver has no relatives."

self hasRelatives ifTrue: [
] else: [
^nil.
].

After having written this, I would fill in the code block. The implementation may be extremely simple, or mit may be relatively complex, depending on the methods already available to me and to which extent I want to factor the implementation for usability (i.e. divide into more methods).

It may sound simple; but when doing this on paper, the whole process of writing code just becomes different. Suddently you need to concentrate on pety details of syntax instead of the problem. It wastes time, and is annoying.

All IMHO of course...

Re:I feel the same way

[Coward Anonymous]

"... Asking about fundamental principles is fine; asking for pieces of code or specific API details is IMO rediculous"

Unless this is a language course, or an introduction to computing...

"The few times I was subjected to these tests, I sure felt primitive erasing entire chunks of code after having realized I needed to insert something in the beginning ... I don't think any reasonably experienced programmer writes code entirely from top to bottom"

True, but any reasonably savvy college student (or, now that I think of it, anyone who has programmed BASIC with line numbers) would know to put nice large spaces between his lines of code to accomodate the occasional insert. That and the uncanny ability to write in ever smaller hand writing...

Quit whining about why you can't do tests and just slog through them like the millions who did it before you

Re:I feel the same way

[Coward Anonymous]

I have never heard of a computer course where additional paper was refused a student. If this has occured, then you have a much bigger problem with the course staff. They are out to get you to begin with so you might as well opt out of the course and wait for better people.

Your Hitler invocation is gratuitous and as such merits no response.

Psuedo-Code

[XBL]

Does doing things in a not-so-rigid manner help? I think so.

Students can focus on the problem, and not writing the syntax, complete with all the () {} etc.

Hate it!

[Tadrith]

I personally hate it when they require programmers to write code on an exam. Every programmer knows that part of programming is debugging, and it's very difficult for many people to get chunks of code correct the first time. I can see, perhaps, requiring a small snippet of code, but large chunks are difficult to deal with in writing.

Due to complexity, programs simply cannot be written 100% perfect the first time around. Not only that, programming is very individual and specific to the programmer. Just because one person writes something one way, and the other writes it another way, doesn't mean either of them are wrong or right.

Written exams should be limited to syntax and concepts, to see how well you know the language. If you want to test a programmer's skills as a programmer, you should at least allow them to excercise their debugging skills...

Re:Hate it!

[seanadams.com]

Due to complexity, programs simply cannot be written 100% perfect the first time around.

A slight modification of the infinite monkey theory states that given infinite time, a compiler, and complete test cases, anyone can write a correct program.

If I'm going to hire you, I want to know that you can code quickly and correctly. That doesn't mean your code has to work the first time through, just that I don't want you sitting there all day jumping from your text editor to gcc while you work through syntax errors, off by one errors, etc.

This is why pen & paper coding is a fantastic test.

Re:Hate it!

[Neon Spiral Injector]

So make it a timed test.

The only language I can write 100% on paper is COBOL, and I hate COBOL.

With C I need a compiler to catch the few typos or what ever I made. But I don't need all day, one or two compiles does it.

Luckly at my school the COBOL tests were on paper, and the C test was on a computer (and timed).

I liked my OS class. The UNIX tests were held in front of terminals. I couldn't remember the quite how to use the non-GNU `sort` command. So `man sort` saved me there. I told the teacher what I did after the test, he said, "excellent."

Re:Hate it!

[denial]

Exams that ask for written code aren't testing for syntax errors, generally they are marked with lenience in that area.

But written code tests something very important, which is whether you can design a solution and describe the solution in essentially correct code. That's something very different from just slowly crufting a solution together because you can build it up. I've seen so many programmers commercially who can't design, describe, or communicate their approach to solving a problem, and I think quality suffers directly.

Obviously there are other important things to test that require prac exams to test, but asking for written design, pseudo-code or even code in some exams is, imo, a good idea.

Re:Hate it!

[AJWM]

Yes.

I swear I've known alleged programmers who, for any given problem, with start with a "hello world" and follow the edit/compile/test cycle until it does what they want.

For hobby programming, fine. If I (or my employer) is paying them, I want something a bit more efficient.

Re:Hate it!

[seanadams.com]

So make it a timed test.

No, give them plenty of time. Any decent programmer picks up a pen maybe once or twice a week - it might take them a while to remember how to use it!

Seriously, knowing the syntax inside and out is important, but not half as important as knowing the algoritm and not needing a dozen passes to get it to work right.

Interview questions should NOT test obscure specifics. They should test problem solving and attention to detail. One of my favorite interview questions is:

Write a function to reverse the order of the letters in each word in a string of arbitrary length, using a finite amount of memory. eg "This is a test" becomes "sihT si a test"

If you can write that function out with pen and paper, given plenty of time, then you're a pretty good programmer.

Re:Hate it!

[AJWM]

usually done for maintainability, expandability and is pretty much a requirement if there are multiple people writing pieces of the program

All of which can be pretty much assumed to be the case if you're getting paid to code. Not always -- some jobs (eg sysadmin, and others) might require a fair bit of "quick bang out a script to do X" where the code will never be used again. But even there you want somebody who can think on their feet, not develop the script by stepwise refinement from "echo 'hello world'".

Re:Hate it!

[seanadams.com]

$tmp_ara = explode(" ",$instr);

I don't know PHP, but it looks to me like like your function allocates memory proportional to the size of the given string. Did you read the question?

Hint: you have to modify the string in-place. Try it in C.

Re:Hate it!

[leshert]

I don't know PHP, but it looks to me like like your function allocates memory proportional to the size of the given string. Did you read the question?

Actually, not to be pedantic or anything, but his answer does fit the letter of the question. You specified "using a finite amount of memory", not "using a constant amount of memory."

Given a finite input string, any algorithm that uses any finite amount of memory (whether it be O(n), O(n^2), or O(n!) ) passes.

:-)

Re:Hate it!

[0x0d0a]

large chunks are difficult to deal with in writing

90% of the time, anything over 100 lines of code is going to have at least one mistake in it, be it a syntax error or a bug.

Re:Hate it!

[Ayende Rahien]

Assuming you meant a constant ammount of memory, and not finite, that isn't very hard.

//Assumes, str is null terminated.
void revStr(char *str)
{
int start,end=strlen(str);
char tmp;
do
{
tmp = str[start];
str[start]= str[end];
str[end] = tmp;
}while (++start!=--end);
}

Re:Hate it!

[Ayende Rahien]

What did we say about never getting it right the first time?

Here is the version that works.

//Assumes, str is null terminated.
void revStr(char *str)
{
int start=0/*forgot to do this before*/,end=strlen(str);
char tmp;
do
{
tmp = str[start];
str[start]= str[end];
str[end] = tmp;
}while (++start /*using != will work, but will segfault on string with len of 1*/ --end);
}

Re:Hate it!

[Ayende Rahien]

forgot to set it to code style.
Damn!

Re:Hate it! (Score:2)
by Ayende Rahien on 17/06/02 13:08 (#3714251)
(User #309542 Info)
What did we say about never getting it right the first time?

Here is the version that works.

//Assumes, str is null terminated.
void revStr(char *str)
{
int start=0/*forgot to do this before*/,end=strlen(str);
char tmp;
do
{
tmp = str[start];
str[start]= str[end];
str[end] = tmp;
}while (++start < /*using != will work, but will segfault on string with len of 1*/ --end);
}

Re:Hate it!

[lucifuge31337]

All it takes is someone to grade the test that actually knows what they are doing.

But if they knew enough about coding to do that, they'd have a real job and wouldn't be grading written tests.

Oh well...it was a nice idea.

I don't mean to sound mean..

[Fixer]

.. but you should know the language you are using well enough to be able to simulate what's going to happen in your head. Yes, it takes a lot longer, and you have to double and triple-check things, but it's a good skill to have.

Hopefully the prof will cut you some slack

[CodeMonky]

Hopefully the instructor will realize that everyone drops a ; occasioanlly (however forgetting ; altogether is something else), or misspells a variable. I think that as far as written tests go they should be more based on making sure you understand how the concept works and not so much on not forgetting a ;. Questions like are better suited for questions like "What is wrong with these 4 lines of code" imo.

Re:Hopefully the prof will cut you some slack

[be-fan]

How true. I think they should just formally introduce the semicolon as the method of seperating statements in math problems. Makes life so simple. Besides, if Perl does it, it must be right!

stravinsky

[splorf]

Stravinsky wrote in his autobiography about his composing habits. As a student, he'd sit in front of his piano picking out melodies, playing them different ways and changing them til he got them the way he wanted, and then he'd write them down. He envied composers like Mozart, who'd compose entirely in their head and then write the composition directly on paper, and he thought maybe he wasn't doing something right. So he asked his composition professor about the problem.

The professor replied basically "there are two kinds of composers: those who use an instrument when composing and those that don't. You're one of the ones that does. Don't worry about it". Stravinsky stopped worrying and did fine.

Sounds like it's the same way with programming.

This is A Big Problem...

[Mad Browser]

This was my least favorite thing about CS at school...

I am much better at solving a programming problem in front of a computer.

Also, they are nothing like real world conditions... Do you know any programmers without reference books on their desks? That have the whole Java API memorized?

Re:This is A Big Problem...

[0x0d0a]

Yes

Re:This is A Big Problem...

[0x0d0a]

I have a sudden suspicion that Sun gives this school funding...

Written exams are fine...

[cperciva]

Written exams are fine for computer science; Coding exams are dumb.

Remember, computer science is about methods and algorithms, not about learning syntax. If you forget a semicolon when you're writing a program, you'll remember about it as soon as you try to compile it; if you code a bubblesort where a quicksort would be more appropriate, you're going to be stuck with a slow program until someone more clued fixes it.

Re:Written exams are fine...

[Dr. Zowie]

Likewise if you code a quicksort where a bubblesort would be more appropriate! (those constant terms can sure kill...)

Re:Written exams are fine...

[e40]

My course work goes way back (80-84). We never had to write anything other than small snipits of code at UC Berkeley.

No need for large portions

[jacobjyu]

I find that the CS tests that I have encountered don't require me to write a large portion of code, just snippets and tiny routines. Usually, a test problem leads us down a long list of sub-problems that, at the end, proves to the professors that you can indeed reason about programming, even though you haven't written a large portion of code.

Testing the ability to write large chunks of code is not reasonable on a written exam, and then, usually your grade is determined by your handwriting speed and neatness :)

Writing code (not typing it) is *hard*

[seanadams.com]

... because you don't have a compiler to tell you when you make mistakes.

This is why it's an outstanding way to test people's knowledge. Anyone can make a program work given a compiler and sufficient time. If you can do it with just pen and paper, and remember the syntax without having other code in front of you, then you know your shit.

This is why it's a great test for interviews. You'd be amazed how many "senior C developers" we interviewed at my last company who couldn't write push() and pop() for a linked list.

Re:Writing code (not typing it) is *hard*

[seanadams.com]

Please tell me you don't actually zing people on missing semicolons and undeclared variables, in your interviews.

I certainly do, but what's more important is whether (s)he got the basic algorithm correct. Writing a linked list is something they teach you in high school programming courses, and even if you've done all your programming in Perl since then, you ought to be intimately familiar with the *workings* of push and pop. Did you get the special cases right for empty lists and lists with only one item? Are there any places where you might derefence a NULL?

This is basic, basic stuff, and I swear at least 90% of our applicants for $70K+/yr programming jobs couldn't do it.

Re:Writing code (not typing it) is *hard*

[seanadams.com]

Are you kidding me? A linked list is something you'd forget since graduation? You might not remember the code verbatim, but if you've been programming for many years, you should have no trouble at all figuring it out in a few minutes.

Re:Writing code (not typing it) is *hard*

[iabervon]

Writing code on paper is easy. What's hard is creating it out loud. Of course, I have no idea why you'd want to do that (although it's kind of fun).

I know Java, C, and Scheme (and some others). I don't know Python. But I wrote most of the code of a useful utility in Python by looking at existing code. I can't think of anything wrong with doing that. If you're always writing new programs without basing them on anything previously existing, you're just wasting the work that's been done previously at your company.

A senior C developer shouldn't need to write push() and pop() for a linked list. A senior C developer should be able to find versions already in the code base or in a library, or copy the version they usually use. It's a far more relevant test to have someone implement something complicated with a computer (and an explanation of the algorithm, even) than to implement something simple in difficult conditions.

Re:Writing code (not typing it) is *hard*

[NullPointer]

This is why it's a great test for interviews. You'd be amazed how many "senior C developers" we interviewed at my last company who couldn't write push() and pop() for a linked list.

Sorry, but that is complete BS (bullshit for those that are acronym averse) and probably off-topic. Sure, writing push() & pop() is trivial, but for some of us it is impossible under certain circumstances. Some of the best programmers out there suffer from "stage fright" when interviewing for jobs, and sitting in an alien environment with a bunch of folks you've probably never met before doesn't help. I've got a BS (a degree) in CS and have been writing C (among other things) code for more than 15 years now and I still can't sit down and write it out on paper. I can write an algorithm description in pseudo code, but real code must come from my fingers banging on a keyboard. In other words, habits are hard to break and how many people write their code out on paper before typing it? Maybe I live in a bubble world, but I don't know anyone who does that.

If you really want to find the best candidate for a position in your company, don't ask them to write code on paper, ask them for some samples from previous work they've done and check their references. If you're suspicious of the source they've provided, put them in a room alone with an editor (no compiler or debugger) and ask them to reproduce something.

My worst experiences interviewing for jobs have occurred when some arrogant jerk has asked for an on-the-spot regurgitation in compile-able code on paper of an algorithm that is trivial for any first year CS student. Some of us simply can't do it.

Again, I'm sorry, maybe I've got an attitude problem and/or should see a therapist...

Re:Writing code (not typing it) is *hard*

[Sloppy]

in the last 6 years of programming (C++) I have never ONCE had to write a linked list.. [snip] ..Waaaaaay back when I was coding in C I STILL wouldn't have been able to do it without resorting to a reference book because I had a set of libraries which implemented this. [snip] ... It shows NOTHING about their ability to solve problems in real world conditions under their own recognisance.

Ugh. You've got everything backwards; I almost can't believe you're serious.

It's fine to have to resort to a reference book, but the thing you should be forgetting and having to look up, is how to use your library (e.g. the names of functions, the order of their parameters, etc), not how elementary data structures conceptually work.

If you can't implement a list or stack, it does show an inability to solve problems. Here's the problem: solve it! Can't? Then you're not a problem solver.

It's ok to forget libraries and syntax; seanadams is in the minority in thinking that matters. But stacks and linked list aren't things you should have to remember -- they're something you should be able to derive and re-invent on-the-spot. If you can't whip them up ex nihilo, then your problem solving skill is ..um.. frumious.

Re:Writing code (not typing it) is *hard*

[Equinox]

There is one thing my AP CS teacher in High School did that I like. After we all bitched and moaned about handwriting code, he would, from then on, disconnect all machines in the room from the network, image them, then let us go. Here's the caveat: the compiler would only run 5 times, print the code, then delete itself. It didn't matter how long it took us (one guy took three days to complete the test,) but you only got 5 compiles. Incidently, under that pressure, I usually only needed 2 or 3. :)

Re:Writing code (not typing it) is *hard*

[WhaDaYaKnow]

"What's the difference between a bridge and a switch?"--I'm usually merciful and stop them if they start talking layer 3

I agree. It's when the start talking cars and lights turning on and off that you want to pay attention.

(sorry,- I'm in my Friday mood...;-))

Re:Writing code (not typing it) is *hard*

[0x0d0a]

A senior C developer shouldn't need to write push() and pop() for a linked list.

I agree (though C is the the language where you'd most likely have to do this yourself) -- however, a senior C developer should be able to write push() and pop() for a linked list.

They want to filter out idiots quickly. I'm sure that they have more advanced questions as well.

Also, to the person who said that they'd tell them point blank that this is a bad idea -- if the first thing you do (this is at a *job interview*) is tell them that you're not going to do what they want you to do...well, you aren't making the greatest impression in the world.

Re:Writing code (not typing it) is *hard*

[0x0d0a]

I hope that's a doubly-linked list.

I also

[Kallahar]

I also had a similar problem. When I code, I keep reference materials and the web close at hand. Whenever I have a question about syntax, style, examples, whatever I quickly look it up. In a test environment you're expected to have everything memorized and at your instant recall for obscure things. I always hated that I was being judged outside of my normal working environment when I had to code on paper.

Travis

Re:I also

[Arandir]

If the test is asking you to use obsure Motif function calls or NT sockets, then you have a point. But if you're being asked to write a linked list or balance a binary tree, then it is perfectly fair. These are skills you are expected to know as a software engineer.

Just because you have a calculator is no excuse not to learn how to add.

Seems fair to me

[ROBOKATZ]

If you can't think through a solution before committing it to code then you clearly don't know your stuff as well as you should.

Re:Seems fair to me

[Mad Browser]

Don't forget you only have 50 minutes to do the whole exam... Not a lot of time to "think through a solution" and then code it (on paper). You have to RUSH.

Re:Seems fair to me

[Llywelyn]

Except if I skip over a line of code in a program I generally catch it before I attempt to compile the code.

On paper if I catch it later its bad (no space for it) and if I don't catch (because I am in a hurry) it then its worse.

Re:Seems fair to me

[ROBOKATZ]

If you're using an incremental design methodology on a test over material you should know cold, you probably don't deserve to do well on test anyways.

The point of a test is not to judge your "real world skills" but how well you learned the specific material that the test covers.

Re:Seems fair to me

[envelope]

What a bunch of crap. "Psychological connection" ?? Pure bullshit. You're dependent on your environment's syntax checking or statement completion, and obviously unable to think thru a problem. Writing code is nothing more than defining a problem solution in specific syntax. If you can't do it on paper, you have a serious problem.

An anlogy

[TrumpetPower!]

A written, computerless computer exam is like having somebody prove they're a chef by watching what they do in the bathroom. Even if you can meet some definition of success, it don't mean diddly.

b&

Re:An anlogy

[jd142]

A written, computerless computer exam is like having somebody prove they're a chef by watching what they do in the bathroom. Even if you can meet some definition of success, it don't mean diddly.

Two things. First, a good chef should know how to create a dish without a recipe -- this means knowing what materials are needed to produce a specific effect and in what proportions. I think it would be applicable to test a chef's knowledge by asking them to write down a recipe using a specific set of ingredients. The good ones and the ones with lots of experience know the way different foods combine in the mouth to create a specific taste, so they don't need a banana and an onion in front of them to know that you won't be able to create a decent desert with those two ingredients.

Secondly, I believe you meant to write "you'll be judging them on their piddly." Or maybe not. Seemed like there should be some joke there. Judging them in bed. . . if you can meet the definition of success, it's still just diddling? Or something like that.

Learn this skill

[Arandir]

This is a skill that you need to learn. When you go out on a job interview, you will most likely be given a marker and white board and told to code something. If you're going to freeze up without a monitor and keyboard in front of you, the employer will be very hesitant.

It seems that you've associated syntax and semantics with the visual cues of a computer. That's not the same part of the brain that answers exams. So you need to retrain yourself. Here are some things you can do to relearn programming:

A) Stop using IDEs. Use the plainest text editor that you can find to write your code. Turn off any syntax highlighting and code completion.

B) Design your code before you write it. Use UML, flowcharts or whatever, but design it first. Then when it comes time to code you will know where you are going.

C) Write code away from a computer. Use a pencil and paper. I didn't have a computer when I was in college (very few people did). So I coded by hand on paper, then went to the lab to type it in.

Re:Learn this skill

[Llywelyn]

"Stop using IDEs."

No reason to do this in particular--it doesn't help you find problems and it doesn't help you check for errors later in better highlighted code.

"Design your code before you write it."

Actually, this is the critical part. If someone hands you a marker and leads you to the white board, draw a UML diagram and write pseudocode. Do complexity analysis, proof of correctness, and draw generalizations and associations.

If they demand C++, you don't want to be working for them.

"Write code away from a computer."

1) I'm dysgraphic, I score in the 30th percentile on handwriting tests.

2) This is a pointless exercise and serves no useful purpose.

Re:Learn this skill

[Arandir]

This would be like if an English prof told you to write a term paper and you did extensive research but lost points for bad grammar. It matters, but is it enough to dismiss the research done?

Bad grammer on an English test? Gee, that sounds like arithmetic errors in a calculus test!

Re:Learn this skill

[e40]

I've hired a lot of people over the years and I'm completely against this type of on the spot exam.

I find that people's performance over the long haul has nothing to do with a 30 minute interview coding session. Some people don't work their best when under pressure, especially when they are interviewing. A lot is riding on that interview, and the stress does very odd things to people.

Re:Learn this skill

[prockcore]

"When you go out on a job interview, you will most likely be given a marker and white board and told to code something."

Most likely? I doubt it. Just because you may have done it doesn't mean everyone does. I've never had to write code on a whiteboard in a job interview. I *have* had them give me a program spec and say "go home, make this work, and email it to me" That was even better in my opinion.. there wasn't a time limit, so they can judge you on how fast you work when there's no motivating deadlines, and the project can be a lot more complex than "write a 5 line routine on a whiteboard"

Now I'm the one doing the hiring, and that's exactly what I do.

Re:Learn this skill

[Hard_Code]

"Write code away from a computer."

"2) This is a pointless exercise and serves no useful purpose."

Well I don't know what a "handwriting test" is, but writing code on paper sure does serve a purpose. It illustrates that you can think through a problem and put it on paper (hopefully with a minimum of mistakes) without being at a computer. It is useful. If anything, if you are bored, you can just code with a pencil and paper for "fun".

Re:Learn this skill

[HiThere]

Yeah... writing code on paper gets it ready to turn in to the keypunch operator.

And that's ALL the good it's ever done me.

Re:Learn this skill

[Llywelyn]

Odd, but I believe I specifically said to do this.

When I start to code the first thing I pull out is my sketchpad and out comes pseudocode, UML, and the math involved, among other things.

There is a huge difference, however, between writing /UML/ on a sketchpad or whiteboard and writing C-code on a sketchpad or whiteboard.

Re:Learn this skill

[tshak]

I agree. I also have dysgraphia. There also isn't a point to throwing away the IDE. It's there so that you can spend less time on the "nerdy" stuff and more time on the creative and more relevant things. Finally, UML is the way to go. Even Boeing is starting to adopt UML for less technical documentation - it's a very versitile standard.

Re:Learn this skill

[gillbates]

Write code away from a computer. Use a pencil and paper. I didn't have a computer when I was in college (very few people did). So I coded by hand on paper, then went to the lab to type it in.

This can't be emphasized enough. When I first started coding, I could complete the whole thing in front of the monitor screen. But now that I'm working in the professional world, I'm coming across problems so complex that they cannot be solved sitting in front of the monitor. More and more often, I find myself actually flowcharting the problem, and then writing my code out on paper. Yes, I could pound it out with the edit/test/debug cycle, but in the professional world, when you are under a deadline, the ability to code it write the first time is essential. I have found that it is always faster from a total development time standpoint to write and debug code on paper and then type it in than to just begin coding. The only mistakes a good programmer makes are syntax errors - because he's already verified the solution before he begins coding.

Re:Learn this skill

[0x0d0a]

A) Stop using IDEs.

This is one of the most aggressive things you can tell an emacs user to do. It's akin to going up to someone and saying "blood...blood...blood" over and over to them.

B) Design your code before you write it. Use UML, flowcharts or whatever

I recently used UML for the first time, and I have to say that UML is abstract to the point of being useless. I want to be able to change a UML diagram and regenerate code stubs. UML isn't capable of specifying stuff that's fairly important to C++ coders, like, say, typedef. The workarounds for this are really awful -- someone has you create a class called "Typedef" and toss some junk in it...yeech.

UML is a nice idea, but it needs to be a smidgen more powerful. Oh, and all the editors need to support XMI. I can understand MS not doing it with Visio, but dia not doing it is just embarrasing to the Open Source community (which constantly claims that everyone should use standard file formats).

C)Write code away from a computer

I really don't like doing this. I don't even like doing this for English text. I remember in grade school how we were taught in English to write rough drafts on paper and then use the standard markup symbols...ick. Much, *much* easier to do revision as you go through a text editor or word processor.

Re:Learn this skill

[e40]

I've worked for almost 20 years under tight deadlines. Stress is the enemy of getting a good job done, not the friend. The smart programmer will learn how to work in a fast paced environment while not being stressed.

If you have, in fact, experienced this type of environment and lived with the stress, I feel sorry for you. You've missed the entire point.

Re:Learn this skill

[Arandir]

You can turn off the syntax highlighting. But that misses the whole point. This new hire was panicking because he didn't have an IDE to use. He wanted something with tabbed windows, class browser (for C driver code nonetheless), debug window, and MSDN on the side...

Emacs gives him everything he needs but it's not in the visual style that he is used to. If he is going to get ahead in his career, he needs to learn how to program regardless of the tool set or media. He won't always have Visual Studio or a Visual Studio clone available. He might have to use a whiteboard in a code review. He might be stuck out at a customer site with only a ssh access to the code base.

It's not the vibe...

[grammar fascist]

...at least not for me. I can code on paper, but I really don't like to. At least, I can code if what I'm supposed to be coding is short.

The deal is that I just don't code from line one to line 5000 sequentially. I define the overall structure and then fill things in - and that's at every level (class, method, loop, conditional).

When I was making exams for an assembly language class I taught once upon a time, I opted out of having them write much code. (A few lines is fine, I think.) If there was any serious amount of code involved, I was asking them to trace through it and give me the result, or I was giving it to them and asking them to incorporate something short in it, or the other way around. That's a better use for the static medium (paper), IMNSHO.

Exams

[lrichardson]

The exam SHOULD be testing your grasp of concepts, not the ability to write large programs on papaer.

That said, I remember one of my worst exams ... Pascal. Got the paper back with a mark around 30% ... which, after talking to the Prof, jumped to a 90 ... since the damn markers didn't actually know what routines were on the system, and my code used them extensively.

Like an english paper, marks should be given primarily for content, with spelling (and grammar) subtracting from that slightly.

The best advice is to do a question in three steps:

1/Shetch out the flow of what you want to do.

2/ Write the code, and

3/ At the end of the exam (assuming you have the time), go back over each answer checking the spelling

How much to write?

[www.sorehands.com]

Usually in exams, it is
But, there are more than one way to test, sample code can be provided and you correct it or determine the potential problems. Or, give the results after execution.

It is important for the grader to keep in mind that it is on paper and that in the real world you are using a compiler that will warn you about some errors.

Ought to be a fundamental theorem of programming

[blair1q]

It ought to be a fundamental theorem of programming that the program isn't done until it's tested.

This includes all subsets of the program. File, class, function, line, expression, term, token, character, syntax, etc., etc.

Your version of this process, like mine, includes getting the tested code to assist our understanding.

--Blair

I used to hate these

[Subcarrier]

A written test like this requires a more systematic approach than just coding with an editor (which is essentially design by coding). A written test has a purpose in the sense that it measures your ability to systematically plan how to solve a problem, design the code and then write it.

I don't think it is entirely a fair test of innate talent, though. The most gifted programmers I know can keep it all in their heads and keep enhancing the code incrementally as they go along. This results in a *much* faster development time and often the code is as good or better as a solution developed using a stricter process.

As all tests, these are also designed for the average programmer, not the brilliant one.

DeVry

[stoolpigeon]

DeVry gets a bad wrap around here so I hesitate to mention this.

But to their credit- the program I was involved in their did not have us coding on paper. We had lap tops that we bought as part of our tuition. They provided us w/the full software for whatever we would be working on- or we would go get it (legally - JBuilder for instance).

Exams consisted of sitting at that laptop and cranking out code. Nothing that huge- you would save it on a floppy and hand it in when you finished.

Could someone cheat? Sure. We weren't allowed to hook up to the network and the teacher was there but that was about all that was 'enforced'.

But on the other hand I don't code w/out books, the internet and colleagues now that I do it professionally.

Anyways- I just thought I'd mention it as it seems that if a school is equipped to properly teach you to code then they are properly equip to test you on computers vice paper.

.

Tests in general aren't particularly good

[Ghoser777]

Here's why: name the last time some one came up to you and asked "Tell me the quadratic formula and use it to solve this quadratic equation. You've got 1 minute... GO!" Honestly, this example is absurd, but some tests come down to that. What you can write down in a mad dash is not the same as if you're working on a problem in a "real world" setting.

Tests in general are after regurgitation and quick thinking, not knowledge of a subject. CS tests, on the other hand, seem to always be about analyzing a problem and coming up with a successful algorithm. In my opinion, CS tests are by far the BEST of all tests given. Any computer can store data, but it takes a thoughtful human to come up with an efficient algorithm to use that data.

I honestly like CS tests that emphasize breaking down a problem into small steps and coming up with solutions in english (or portuguese, whatever). Then, another portion of the test would be implementing small portions of that solution algorithm.

Ah well, I'm almost done with school anyway, what do I care.

F-bacher

Re:Tests in general aren't particularly good

[elflord]

Here's why: name the last time some one came up to you and asked "Tell me the quadratic formula and use it to solve this quadratic equation. You've got 1 minute... GO!" Honestly, this example is absurd, but some tests come down to that.

Have you ever given a math or physics talk where someone asks you an annoying and difficult question you hadn't anticipated ? The kind of question you offer as an example here is exactly the kind of thing you're likely to get shoved in your face in front of a large audience in the real world. Of course, the quadratic formula will probably be one of 5 steps that you'd better be able to string together in your head in short order, but basically, it is the same thing. I've saved myself from some substantial embarrassments by thinking on my feet and "patching" unanticipated gaps in proofs. I'd imagine similar is true for more business oriented types, when they're handling tough questions at a shareholders meeting. THinking on your feet is actually quite useful, even in "the real world".

Re:We did these at the Rochester Institute of Tech

[jcoy42]

They would look at the code as more of a structured psuedo-code, rather than something they thought would compile.

I had a fortran instructor sort-of like that. But then his code wouldn't compile. The final was a 2 page listing and the question "Tell me what this code does". I told him it would error durring compile at line 30.

He gave me an A for that. It would have been much easier if I could have used a compiler to find the result though..

Re:simple

[Anonymous Coward]

The greatest thing about college for me was NOT the CS, Engineering, and math courses that eventually got me the job I now enjoy...

It was the total mind-opening academic scene that surrounded me 24/7 for 5 years, the chance to really go out and party my brains out to relieve the stress, the hour long conversations with professors who are true geinuses in every sence of the word.

You might get paid a lot of money, but if you see college as simply a means to that end, I strongly suggest you take a year off and attend full time. Because you certainly do not get the point.

And, through so many experiences, I learned that your final career and salary doesn't define you, your worth, or how much you can get out of life.

but congrats on your job, though. Pretty sweet deal.

Good programmers use tools, not memorization

[Jack William Bell]

I have run into this same problem in job interviews. Usually it comes down to the fact that, on the job, I have resources at my command; books, web sites, code examples, etc. So, rather than memorizing every API (or even every keyword), I become very facile in knowing where to look up what I want very quickly.

But when I am asked questions about the same thing away from a computer and my books I start drawing blanks even about things I know in detail. This is why, IMHO, computer programming exams and even job interviews should be 'Open Book'. Memorizing details doesn't make you a good programmer -- knowing how to use the tools does.

Jack William Bell

Own experience...

[Pollux]

For the most part, I agree with you. I've had professors who ask me to write out my code on a page, and the environment just doesn't feel right.

I've had no problems "debugging" code on paper, designing a program on paper, plus your typical bogus multiple choice questions ("What's the difference between 'cout' and 'printf'", etc.). But when it comes to coding, my brain operates differently writing code pencil / paper style. You could probably equate it to baseball hitters who commonly have higher batting averages at their home field than on the road. When a job is done in the same kind of environment for so long, we become accustomed to that environment.

I'd be perfectly happy if the profs let us only use notepad to write out code if they're afraid that a program such as Borland / Visual C++ would give us too much leverage.

Re: code on exams

[Arandir]

When you're on the job, you WILL have those kinds of time pressures. One of the things the interviewer wants to know is how well you can cope with it.

It's Friday at 5:00 and you're leaving on a weekend trip at 7:00. The software is handed off to SQA on monday. There's one more bug in the queue and it belongs to you. Question: A) Do you bail on your trip? B) Do you sneak out the back door? C) Do you go fix that bug in 57 minutes?

Back in my day....

[newerbob]

I've been writing code nearly every day professionally for the past 25 years, and have a graduate degree in Computer Science and an undergrad degree in math. I've also taught computer science, on and off, for a local community college evening program.

Back in my day, we programmed on punch cards. If you didn't get it right the first time, you had to re-submit your deck. They only ran the compiler twice a day--once in the morning and once in the afternoon, so you had two chances/day to get your program correct.

You don't debug with a compiler, not in the days of punchcards, and not now. You debug by looking at your code and finding the bugs.

I think a written test is fair--what's the alternative. But most rigorous "Computer Science" programs don't spoon-feed programming language courses to students. Classes are on more abstract subjects. You are (or should be) expected to learn the syntax of a particular language on your own.

I hand people a white board marker and expect them to write code on the white board during job interviews. This really separates the men from the boys. You'd be surprised how many complete frauds are out there with "C++ expert" on their resumes! I have to reject outright about 80% of the people whose resumes have passed muster by our HR dep't. If I didn't give that written test, I may have made a bad mistake and hired an incompotent programmer who can talk and wear a suit well.

Computer Science != Coding

[donutello]

There is a difference between the SCIENCE of software and computing and writing programs. Kinda like the difference between Mechanical Engineering and being able to fix a car. Please don't confuse the two.

As far as the subject at hand is concerned, asking someone to write code without a convenient editor (like emacs) and a debugging environment is just plain stupid. You wouldn't write code in real life without those tools - why would you want to even test someones ability to do something with artificial constraints that will never be met in any realistic scenario?

I have a Bachelors and a Masters degree in Computer Science and I cannot remember a time when I had to write code in a written exam that was not pseudo. Consider taking a different class if that is not ok with your professor.

State-Dependent Memory

[RAMMS EIN]

The explanation for this is a psychological principle called state-dependent memory. People are better at remembering (doing, etc.) things when their minds are in a state similar to the state they learned them in. Since you are used to writing code on a computer, coding on paper doesn't work because you can't get your mind in hack-mode. What I do is I drink huge amounts of beer while programming and do the same thing before I take a test. That adds enough similarity to the situations that the results are similar.

---
Never test for an error condition you don't know how to handle.
-- Steinbach

Some things can't be tested.

[surfcow]

Would you have a written test for cooking? Art? Programming is similar in many ways.

Perhaps the grade should be assigned solely on projects.

And yes, some people could cheat, so what? They could get other people to draw for them in art class too.

Most professors find the whole testing process to be a pain and a waste of time. The whole paradigm is about 3000 years old. Maybe it's time to change. Universities should be in the business of educating people.

CS exams are a fair measure but...

[Maul]

CS exams are a fair measure, but I never liked sections where I had to write more than 10 or so lines of code. Though it was rare to see, I did see it once in a while.

Some profs. are sadistic and like to do that sort of thing, but often they will still ignore small errors (such as syntax) as long as the "big picture" of what you do works as a feasable solution to the problem. Or at least that is the way it goes most of the time.

As far as everything else the written exam tests, such as theory and math, well, I really don't see a problem with it. Even if you are a great "coder" it doesn't mean you're a great "computer scientist," after all.

Writing code without a computer

[briansmith]

At the University of Iowa, IT/CS people here were invited to go to Nigeria to help with computing infrastructure (designing and building campus-wide networks, etc.). The interviewer told us that in some cases, the Computer Science students at the Nigerian university rarely, if ever, executed or compiled their programs on an actual computer. The reason is that computers are scarce, as is even electricity.

So, with that in mind, writing some code as an answer to a test question doesn't seem that bad. At least with my homework I can still use a computer to test my ideas and to experiment.

And, I'm fairly confident that when I "need" a computer, I will:
(1) have a computer available for me to use
(2) have working electricity to use it
(3) have an Internet connection that works
(a) works at all
(b) doesn't take three minutes to bring up
the slashdot homepage.
(4) have documentation and literature to read
that isn't older than me.

It's the paper

[SheldonYoung]

I find it's not that I rely on the compiler to catch mistakes, it's that I don't write programs from the top line to the bottom line. I'll write the structure then fill it in, maybe even move stuff around as the idea solidifies. It is just very difficult to work this way on paper.

Re: code on exams

[AJWM]

That makes all kinds of sense for a job interview situation. There, they want to know not just what you know, but how well you perform under pressure, and how fast you can perform.

The guy who knows the syntax and the APIs off the top of his head is, ultimately, going to produce faster than the guy who relies on multiple passes through the compiler to correct his syntax and using 'man' or equivalent to look up the API of every function -- just as the person who can add/subtract numbers in their head can check their change faster than someone who has to count on their fingers.

Somebody looking to actually pay money to somebody to write code for them (ie, to hire a programmer) is going to prefer the former rather than the latter, so why not give them such a test? (And it will instantly screen out the bozos who've lied on their resume and maybe just memorized enough to pass simple interview questions.)

Re:We did these at the Rochester Institute of Tech

[edrugtrader]

nearly all of my exams were pseudo code... that is the entire point of a 4 CS degree: theory!

if you understand the problem and solution, then you are an 'A' student.

now, if this was DeVRY or something, syntax is the important thing cause you are just going to be a code monkey your whole life.

Written Exams

[edthemonkey]

All the exams I've taken at the University level have been written. I found that beyond some of the initial pop quizzes where they're teaching you a language, it becomes more concept oriented. My final exam for a data structures course allowed us to use Java (or C++, etc), pseudo-code or witten english, as long as got your algorithm concept accross.

On the other hand, for my functional programming course (Haskell and Prolog, especially the Haskell) if you had things slightly off, it could totally change the way the program works.

I find the professors also tend to come up with creative weighting for the courses. Between exams, tests and assignments, I have a lot of leeway with my marks. I can fail (or skip) two midterms and make my final exam worth 90 instead of 50 and so on. If you do better on the exam, it can be weighted higher.

I think the main reason they use the written exams for the highest percentage of the mark is the ability to control cheating. It's much easier to cheat electonically. At some point, computer science departments will gain faith in their security systems and ability to prevent cheating.

benefits of paper programming

[Preposterous Coward]

Writing code on paper may not be a "fair" measure of your actual sitting-in-front-of-a-PC programming skills, but that doesn't mean it's entirely useless either. Some reasons it's arguably a good exercise:

One of the things that universities are supposed to do is give you a chance to express your knowledge in new contexts. It's relatively easy to apply things you've learned in familiar contexts, but how good are you at applying them in unfamiliar environments?

Making you work with pencil and paper forces you to plan ahead and architect your solution, not just jump in and start writing code.

When you write by hand, the logic and aesthetics of your code are especially important -- since you (and the reviewers) can't run the code to see whether it works or not, you need to make an extra effort to make it transparent and comprehensible.

I might take issue with an exam that was nothing but one big handwritten coding assignment, but I don't think this is at all out of place as a part of an exam or course. It's a little like essay questions in a soft-science class; they're unrealistic because in the "real" world you have access to reference materials and time to spell-check and so on... but at the same time they are a useful gauge of your ability to articulate a subset of your knowledge, to think on your feet, etc.

Also, in courses I've graded where such exercises where required, we usually didn't worry about things like minor syntax errors that didn't obscure the intent of the author. The goal was to look for an understanding of and ability to solve the problem, not to be human compilers.

Get over it!

[SoupaFly]

What did real programmers do before interactivity? They sat down, figured out their program step by step, checked and rechecked for possible errors and then used the punch card machine to write it out and ran it. If it failed, they had to wait a day before they could get their program through the batch again.

Having to hand write code is probably a better way to test one's knowledge than having them use a computer for it. The reason being that you're in a different frame of mind. It's all part of being able to visualize things in different ways.

The way I did it was to think through the logical functions the programs had to perform (sometimes writing out a psuedo code version) and then converted it into actual code a section at a time.

College isn't always fun, but I found that I learned the most from the things I least wanted to do.

It depends what they ask and how they mark

[oliverthered]

Questions like, here is a recursive function, write the code to turn it into a loop.

Write some code to rotate/scale an image.

Fine an element in this sorted list (of say 10000)

Give this xxx write a class model for it.

Now as long as they don't expect perfect code, eg. forgeting to +1 because of a rounding error, or a binary search can result in a high or low result(for a non-perfect match), these seem fair enough questions to me because:-

They all test your abilty to write good code, not just code that works.

I know loads or 'programmers' who don't know how to turn a recursive function into a loop.

Would use sin/cos to rotate each point on the image, instead of using an interger line drawing algo to scan accross the image to rotate it (or even floating point)

Would write a n order search instead of a binary search.

And would use a poor or unflexable design pattern.

So long as they mark your programming skills and not how perfect your code is, i don't see a problem.

Debugging is also a key skill, but is very hard to test in an exam, a good debugger uses a hell of a lot of past experiance and insperation to locate, fix and check that there are no simila bugs.

Re:It depends what they ask and how they mark

[HiThere]

I know loads of recursive functions that it's quite difficult to turn into a loop. With tail recursion, it's trivial, but that's the exception, not the rule.

For a start (just to give you the idea) turn the fibbonacci series into a loop.

Now that you've practiced, try the Ackerman function. ;-)

And it really MATTERS what the programming language is. I remember spending a huge amount of time trying to get everything right on a binary search in C. But several in other languages, it's nearly trivial (though hashes tend to get used instead).

Re:It depends what they ask and how they mark

[HiThere]

Ackermann requries an explicit stack (it's not primitive recursive), but it's also pretty easy.

How big a stack?

Re:It depends what they ask and how they mark

[sconeu]

For a start (just to give you the idea) turn the fibbonacci series into a loop.


long n1 = 1;
long n2 = 1;
printf("%d\n",1);
while (1)
{
long tmp = n2;
n2 += n1;
n1 = tmp;
printf("%ld\n",n1);
}

Re:It depends what they ask and how they mark

[TGK]

I think it's important to remember why we're taking these tests. A CS degree is a professional degree.

The point is that the testing you experiance earnign that degree should be testing the skills you'll need in the real world.

How many programmers out there are regularly called upon to write perfect working code on a napkin? I've never been asked to do that except for these damn tests (well... not a napkin). The idea that people are testing us for a skill that we not only do not need but never will need is insane.

Answer: Not fair. But we have to do it anyway.

[IvyMike]

I used to teach a class to engineering freshman, and part of the course was writing code in Matlab. There are in fact a bunch of matlab questions that you can ask that aren't just writing code, but you really don't get complete coverage unless you have the student put some code on the page.

Additionally, there probably was some cheating going on with the homeworks (this was a large class taught to all freshman, with relatively small programming assignments. It would be difficult to prove someone was cheating.) We needed a controlled environment where this couldn't happen.

However, we all realized how crappy this was for the student, and we graded the assignment more like it was psuedocode. If the code had obvious typos, we ignored those. If they were close on syntax, but a little unclear on the API, we usually let it slide, too. (We understand when online you can look that stuff up with the online help.) The thing we stressed was the overall algorithm itself, as well as a demonstration that the student knew how to use matlab. (After all, as a TA, I'm taking programming courses myself; I have some idea of what's reasonable to expect and what's not)

If you do have a written CS test, and the prof does mark you off for syntax errors, I would probably go in and (politely) complain. Say, "I made a typo which would have been caught by the compiler, but I got the gist correct." If you demonstrate that you know what you're talking about, and you're not a jerk about it, and the professor's not a total jerk, I bet you'll get most of the points back. (We would do this all the time, especially if the student could clearly explain what they were trying to do.)

If the professor or TA is a jerk, all bets are off, though. But if they're a jerk, they aren't interested in being fair anyway, so you were screwed from the start. We've all been there. Sorry.

DESIGNING code (not typing it) is *hard*

[kwerle]

I half agree with this. Syntax doesn't matter. If they can't get the syntax right, who cares. That's like saying that people who can't spell can't think - those are unimportant details. The important thing is that the know HOW TO WRITE push and pop. Not that they be able to type it once and have it compile.

I can't write a java main() statement. Just can't remember how - don't do it very often. But my emacs expands when I type 'main', so it's not a problem :-).

I couldn't write push and pop and get it to compile, either. But I know how. And I can communicate the design.

If you're talking about "can't design push and pop", then my sympathies. If you're talking about "can't get the {}'s right", then I don't want to work with you anyway.

Re:DESIGNING code (not typing it) is *hard*

[kwerle]

And I suppose, that, to people like you, taking baths/showers and using deodorant are also unimportant details?

That's a perfect analogy! I don't care if people take a bath, or if it's a shower. Nor do I care if they use deodorant; if soap is enough for the job, that's great. What's important is that they clean themselves.

OK, maybe it's a bit of a stretch. Try to think of something better.

Re:Of course not

[ceejayoz]

So everybody gets to go to Harvard, and they all graduate with honors, eh? Doesn't work. Face it - the TA and prof usually have more knowledge than the students, and thus are good evaluators of said students.

The pen is mightier than the keyboard

[ctj]

Writing code in exams is hard to if you are used to typing all you assignments with the use of an IDE. As a current EE student who does a lot of CS subjects I have found that the best way is to write code with pen a paper first. This way of coding makes you think very carefully about what you are writing, you don't want to have to rewrite a page of code in pen (rather than just deleting it and retyping it). This way of coding also means you spend your time working on the algorithms and data structures that you believe will solve the problem with out being distracted by your complier not liking your code as you develop it. I am not against IDEs once you have written your code worked through the problem make sure it works in you head (The only complier that can find your logical errors) typing it with an IDE can speed up the time it take to find your typos.

If your are working in assembler pen and paper are just as good as a computer.

Most exams are after finding out how you would approach a problem. Writing the code demonstrates that you know how to use the language.

Prepare for insertions

[MattC413]

When I took a required test for C when I was an engineer, a very large chunk of the test consisted of writing code. One part required making the shell of an API, while another asked for a program that (if memory serves) did some sort of computation or sorting. I ended up getting a 99/100 on the test.. Why? Well, on the last problem of the last page on the last test of the year (the final), I neglected the final closing left brace " } ".. doh!

Anyhow, the code wasn't nearly perfect.. to the contrary. I had to erase several times, draw arrows (see below) to places, and other things.. but in end, what works, works. Here are some suggestions to help people write code during tests.

1) Think how you want to structure your solution. On the back of a piece of paper, write down each [method/function/procedure] and the variables involved.

2) Write down the [methods/functions/procedures]. Leave 2 'spaces' between the declaration and the start of your code in case you need to insert variables or code here.

3) Leave a little space between lines. If you find it necessary to 'insert' code somewhere, write it near the bottom of your page and draw an arrow to where you want to insert this code. Most TA's/Professors are very forgiving and understand that you won't erase 15 lines to insert 2 in the middle.

4) Do required editing.. that is, check your 'code', and if you need to insert lines, see #3. Those arrows work wonders.. really.

-Matt

Re:Change your major.

[ceejayoz]

1. yes, but what if you forget a semicolon, or accidentially misspell a variable name, or something like that? if you're losing x points for each minor syntax error that you'd have instantly found if in a real-life situation, is that fair?

2. most professors won't take english papers in pen - everyone requires typed papers now... and typing's far easier on the hands

3. it's useful, but most people should be able to code w/o it, so I'll agree with you there

Why would you study at a place ...

[wytcld]

Why would you study at a place that's so stupid about using computers that they don't realize that having to grade code written on paper costs so much more in terms of faculty time that they should have sat you at computers. I mean, they could go to Wal-mart and buy those Lindows machines for 10 cents each, right? And they use paper??

overrated?

[Anonymous Coward]

college? overrated? yeah...only if you're a geek who codes in a vi screen in his pitch-black dorm room all day...

What are you testing?

[SeanAhern]

Anyone can make a program work given a compiler and sufficient time. If you can do it with just pen and paper, and remember the syntax without having other code in front of you, then you know your shit.

Then give them a compiler and sufficient time. That's what you'd do if you hired them and set them to work. You don't hire someone to code without providing them the tools of the trade. Why would you test a skill that is not asked for in the job?

I would suggest that the job "interview" gather information that's pertinent to the job being posted. Gathering performance data (like being able to code without reference material, a compiler, and an editor) that has nothing to do with the job is going to give you information of questionable usefulness.

Definitely not fair!

[BlindSpot]

Yes! I'm glad somebody finally brought this up.

Paper is just plainly the wrong medium for CS exams that involve programming. That became plainly obvious in my first CS exam and only got worse.

CS students should be tested on computers in at least a simulated development environment. (Controls would of course be needed to prevent cheating). Reference manuals should also be allowed as using them is a vital part of being a programmer. Forcing students to remember the parameters to fopen() or whatever is just pathetic.

If athletes were tested like computer programmers, the teams would be made up of those who could write the best description of how to play the sport, not of those who could actually play it the best. The worst part is that the intersection of those two groups is probably not very large, especially in CS, so I think some truly good programmers are being punished.

In first year CS our prof once asked us how to make the course better and I suggested the exams be held on computer. She was actually quite receptive to the idea, but as we both knew it was impractical. Computers cost $$$ and take up extra space, and testing 400 or more students on computers is just too ugly.

However, we are getting to the point where it's starting to become a lot more feasible, so I dearly hope educational institutions will start to upgrade their evaluation methods.

In the meantime, I hope instructors treat handwritten code more like a sketch than a masterpiece. We were lucky that the profs here didn't worry too much about syntax in handwritten code and instead looked for understanding of what we were doing. If we were a bit off on the syntax that was okay as long as we had the concepts down well. But we still did have to memorize a lot of stuff that was quite unnecessary and that's just Wrong.

Re:Definitely not fair!

[elflord]

Paper is just plainly the wrong medium for CS exams that involve programming. That became plainly obvious in my first CS exam and only got worse.

Depends on what you're testing.

CS students should be tested on computers in at least a simulated development environment.

Simulating a "development environment" is nontrivial. A real world development environment often involves large and complex programs. The paper exam is a "simulated environment" of sorts. I agree that open book tests tend to be a good idea with courses that involve programming.

If athletes were tested like computer programmers,

You've lost me. You're discussing "testing computer programmers", but the topic is "CS exams". The two are not equivalent.

The worst part is that the intersection of those two groups is probably not very large, especially in CS, so I think some truly good programmers are being punished.

An exam on compiler design will punish a "good programmer" who doesn't understand the fundamentals of compiler design.
An exam on artificial intelligence will punish a "good programmer" who doesn't understand the fundamentals of artificial intelligence
An exam on discrete math will punish a "good programmer" who doesn't understand the fundamentals of discrete math.

Get the point ? Not all CS exams attempt to measure whether or not you are "a good programmer". The exams are there to test mastery of the syllabus, which, with the exception of some entry level courses, doesn't have a whole lot to do with writing code.

In the meantime, I hope instructors treat handwritten code more like a sketch than a masterpiece. We were lucky that the profs here didn't worry too much about syntax in handwritten code and instead looked for understanding of what we were doing.

You weren't "lucky", this is the way it's usually done. The instructors, as you say, are looking for some sign that you understand the material. They don't care a whole lot if you miss a semicolon or something.

If we were a bit off on the syntax that was okay as long as we had the concepts down well. But we still did have to memorize a lot of stuff that was quite unnecessary and that's just Wrong.

Just like it was "wrong' for them to make you memorize those timestables, right ? After all, one could always use a calculator.

Re:Definitely not fair!

[elflord]

If you reread my post, I said "CS exams that involve programming". You even quoted that part, but obviously didn't pay attention to it.

I see. My response would be that most CS exams don't involve programming, and the ones that appear to involve programming are actually testing something else (eg whether you can express an algorithm clearly and correctly) So I think most of your argument is based on a false premise.

I'd been programming for over a decade before I took my first CS exam, so I think I'm qualified to say that writing code on paper is unnatural.

"Unnatural" is a loaded, subjective, and emotive term. IMO, "unfamiliar" would be a better word.

XP has it right Design a little, test a little, code a little.

XP is about project management. It has little or no relevance to measuring basic skills. What coding exercises on exams measure is whether or not the student can express simple algorithms in a clear and correct way.

Again, this boils down to the fact that entry level programming courses are not intended to evaluate your skill as a programmer (that would require an interview at the very least), the purpose is to test mastery of the syllabus, which is often related to programming, but certainly is not exactly the same thing.

Are written plumbing exams a fair measure....

[Lictor]

... of someone's knowledge of fluid mechanics?

Once again, Slashdot continues to perpetuate the (Computer Science == Programming) myth.

Programming IS NOT "computer science" any more than telescope design is Astronomy (with apologies to Dykstra).

Programming is a trade skill. Certainly, a challenging and rewarding one.. but it is not a science.

Being the first guy to figure out quicksort... thats science... thats research. Coding a quicksort in LISP is not.

I've ranted about this before, but it upsets me to see such a misleading headline.

I think *computer science* exams are quite fair... if you understand the data structures and algorithms associated with B-trees.... you shouldn't have any problem describing them on an exam. Likewise, if you understand the halting problem, reducing a simple contrived example should be doable on an exam.

On the other hand, I very much disagree with the "code this up in PL/I, using proper syntax" type of exam question. What an enormous waste of time...

The bottom line is that if you've been through a computer science program and understand the underlying principles, I should be able to give you a manual for 'trendy language x', a few examples, and 48 hours. After that, you should have no trouble coding in Jav^H^H^H 'trendy language x'. Will you screw up the syntax occasionally? You bet. Is it fair to dock points on a formal exam for being human and forgetting a semicolon? I sure don't think so; and I've *never* done that to my students.

But I stray from my point. Once more, for the record, since no matter how often I rant about it, no one seems to listen:

COMPUTER SCIENCE != PROGRAMMING.

Re:Are written plumbing exams a fair measure....

[denshi]

Coding a quicksort in LISP is not.

Considering that that's right there in the core, I should think not.

But more importantly, CS != Programming.

But a big problem w/a CS "exam" is that the timescales are totally absurd. CS draws on several disciplines: HCI, EE, set maths, complexity theory, etc; and establishes many of its own: code translation (compiling), algorithmic efficiency (math has algorithms but not O(f(x)) concerns), data representation. A computer science advancement tends to draw on all of the above, and sounds something like: "using these techniques, we can devise a new method/language for programming that cleanly solves these algorithmic difficulties, produce extremely fast code, and present the user with a simple abstraction to the whole design." That's not something you do on a two hour exam. That's something you prototype in a semester, cover your ass in a year, and make production-capable in 3 years.

Could some of us generate a new programming language with a very restrictive set of operators in 2 hours? Sure. Will it compile? Hell no.

The exams discussed on this story are not CS. They don't even resemble CS. And for real CS, the idea of an undergraduate final exam is just ridiculous.

Re:Are written plumbing exams a fair measure....

[HiThere]

Sorry, this is a response to the parent, not to the article.

Sorry. Java's a lot worse than that. It may be "trendy language x", but there's no way I'll ever just remember what function throws what exception (e.g.), without looking it up. Usually I just re-use old code that got it right and don't worry about it (I rarely use Java), but there's no way I'd remember it cold.

There are other traps. I really dispise the way that Java handles files. C got this much better. So did Python and Ruby. (The most common reason for my avoiding a language is that it doesn't deal nicely with files. That is in-and-of itself sufficient for me to consider a language unuseable.)

Now with a good reference, and some sample code, Java's RandomIO class is acceptable. Not great, but acceptable. (Nobody handles RandomIO very nicely.) But the entire concept of mangling files with streams is at best dubious, and Java built it into the core classes of the language. (Well, so did some other languages, and it sounds like a good idea. Only when you start using it does the true horror strike.)

A class should start out simple, and then add complexity. That's correct. But Java's approach to simple for handling files makes a simple little routine for reading a text file take up twice the space that it should (or more). This is probably because of single inheritance. (Look into the details of how Java twists itself around to implement RandomIO sometime. It works alright, but UGH! What a design!)

If Python or Ruby had the same push behind them that Java had, Java would have been laughed off the face of the planet. Unfortunately, Java has a relatively decent crossplatform GUI interface, where Python used tcl/tk (Tkinter), and Ruby is still groping (tk? gtk? FOX? ...).

Applied Computer Science IS Programming. Unfortunately, Abstract Computer Science is the study of algorithms, where this should only be one part of the field. Usability criteria should also be a part of the field, but that has been shoved over into ???. There are people who worry about it, but they don't really seem to have a home. Like PARC ... which was an industrial research lab run by a company that didn't really pay much attention to computers. Or Bell Labs, which was really about making the telephone system work better, but had a bunch of other miscellaneous labs just in case one of them paid off. (Bell paid more attention than Xerox did, and Bell has split into several companies that are each doing pretty well. [There may be an exception, but I don't know about it.])

Re:Are written plumbing exams a fair measure....

[John Harrison]

The written exams I took in CS weren't about hunting through documentation. If they happened to be a need for some documentation then the documentation was provided. Often exams were open book, open notes and designed such that it didn't matter if you had the book anyhow. Instead the exams that I took generally required no knowledge of any libraries at all. They would be problems that to write some small yet potentially useful function like a sort. Or designed to demonstrate your knowledge of recursion.

If a real coder can use these resources, why can't we?

Sorry, but universities don't consider students taking tests to be "real coders". They are people who are still learning some of the basics.

Another type of problem that I saw often in intro CS was here is a function. Tell us what it does. I have actually been asked this in a job interview. My answer was, well, it won't compile since there is a bug right here, but if it did, then this is what it would do... The person would had made the problem had no idea that there was a bug in the code. He made a note to fix it. I was glad that I had experience doing this sort of thing.

There seems to be an attitude of complaining about how school is run here on /. Maybe /. is populated by people attending crap schools. I don't know. What I do know is that any CS major worth his/her salt should be able to sit done and write out how to implement sorting routines and such pretty quickly. Also, remember that the test is not 100% of your grade. In programming classes there just might be some actual programming assignments that will give you the opportunity to show your coding skills in a sitting at a computer situation. Having to spend three hours with pencil in hand won't kill anyone and is acutally something that you should be able to do without whining.

Re:Are written plumbing exams a fair measure....

[Lictor]

>Considering that that's right there in the core, I should think not.

The "core" of LISP is the eval function.. no more, no less...

>the timescales are totally absurd

I guess this depends. I think its reasonable and possible to write an exam that directly tests the material at hand without demanding too much. Certainly an exam question that reads "Design and implement a major software system..." is ludicrous. But a question along the lines of "Given the tree data structure listed above, write a depth-first search for it in pseudo code" is perfectly reasonable. And it tells me if the student has even the foggiest idea what a depth first search is and what these "tree" things are...

In any case your premise appears to be that "real CS" == large scale software engineering. I respectfully disagree... this is certainly *one* of the major areas of CS... but its not even close to the whole field.

Re:Are written plumbing exams a fair measure....

[Lictor]

Nice anti-Java rant =) I'm not a big Java fan myself... but for better or worse, its going to be sticking around for a while. It may be a beast, but on an aesthetic level, its a little better than C++... how many times do people have to re-invent "memory management" by reference counting before they realize it sucks??

Python is my favourite language for prototyping and scripting, so I'm 100% with you on that one. I haven't had more than a cursory look at Ruby, but it seems to have a pretty solid design.

Now, as for "applied computer science == programming"... yes, thats part of it, but it sure isn't the whole bag. Do you think the AI/computer vision guys working on cruise missile guidance systems are just simple coders? But at the same time, they aren't doing new research in computer vision... they are *applying* (probably quite a bit) of abstract academic research in the area. But their contribution is undoubtedly more than just writing code.

Re:Are written plumbing exams a fair measure....

[Lictor]

I totally agree that most CS people end up as programmers or software engineers. But if they're *really* doing software engineering, then there is a LOT more to that than just coding. And just because thats what most people end up doing... doesn't mean that its all there is to CS. How many people with a BSc in physics end up doing something that could be comfortably labelled "pure physics"?

The ends do not the means make.

>most of the people who do what you consider CS are actually math majors

If you are from North America, I promise you that you are wrong on this one. Go to your local university.. walk into the mathematics department and ask the faculty there if they think: automata theory, complexity theory, formal language theory, information theory.. heck even semigroup and semiring theory are "pure mathematics". They'll laugh in your face and make some condescending remarks. (If you're in Europe, then all bets are off. Your comment is quite accurate... why this dichotomy exists is a mystery to me... but I have certainly observed it).

Re:Are written plumbing exams a fair measure....

[geekoid]

boy, I wish you where my english professor. Sure I understood punctuation, but the bastard had the gall to dock me points if I would miss a semi-colon.

Re:Are written plumbing exams a fair measure....

[denshi]

The "core" of LISP is the eval function.. no more, no less...

No, it really isn't, considering that 'eval' doesn't operate within a surrounding lexical context. The core of LISP is s-exprs, atom?, car, cdr, cons, lambda, progn, cond, quote, and function application.

But what I meant was "a generic Common LISP image without loading any modules", but the terminology is a bit unwieldy.

In any case your premise appears to be that "real CS" == large scale software engineering. I respectfully disagree... this is certainly *one* of the major areas of CS... but its not even close to the whole field.

You completely missed what I was trying to say, which is fine.

Re: code on exams

[e40]

Absurd. Where's why: if you do your job correctly and work for a responsible company, you will build confidence doing your job. When something goes wrong, you will be working with people you know doing a job you know.

In an interview situation, there very well might be a few people standing around watching you that you've never met.

The situations are very, very different.

I know a guy that was put on the spot to write code with 10 potential co-workers standing over his shoulder.

The times that I've had 10 co-workers standing over my shoulder were never tense situations, but always relaxed, fun times.

well, of course...

[gyratedotorg]

I find that I need to be sitting in front of a computer...

of course it's easier to write code on a computer. you have the compiler/interpreter to immediately alert you to your mistakes.

still, i dont see the point in these exams where you have to write a program on paper. its infinately more important to understand the concepts rather than to memorize the syntax of a particular language. thus, i believe that pseudocode should be the official language for written exams that involve programming in (at least higher-level) computer science classes.

Are Written Computer Science Exams a Fair Measure?

[GMontag]

Are Written Computer Science Exams a Fair Measure?

Yes.

i find that

[Gavitron_zero]

the big problem that I have with coding in exams is the whole enviroment. When I code, I have 2 displays going, mp3's playing and a couple of ICQ chat windows open. For me, coding without these things makes me concentrate too much, and get hung up on little details that don't really affect my code...

One more thing I'd like to add...

[Kashif Shaikh]

I've already finished my CS degree and one thing I like is writing code on an exam makes me happy. I mean of all the other exams I have to write with various degrees of memorization, writing code is *thinking*. So it means for me, less memorization bullshit.

Also another thing I would like to say: many would like online exams almost exclusively. But they are missing one crucial point: TAs and Profs mark such tests in "black & white", meaning if it compiles and passes the test cases you get most of your marks.

But if your program doesn't even compile, your mark starts at 0. And depending on the mercy of the marker, they *may* go back and look at your code and give you a mark here and there.

In such tense situations, I've seen people literally cry 'cause a) the program was too hard and b) they can't get it to compile. Where you literally get in a hack-peck/compile frenzy to get your program to spit out some correct output before the test is over.

In such tests we usually have 9 questions and gotta do about 6 of them. And the worst thing: they issue such online tests during the first year, where many are having their first crack at programming. Thank god, I was able to do the questions, but alas some individuals who struggled couldn't.

At least if the test was written you could get the core logic of the program done and you'll get most of the marks anyway.

But, I did enjoy online tests they were fun. The positive of such tests: if it compiles and spits out the correct output you've got 90% of your mark if not 100%.

Oh boy....talked too much...

Re:Change your major.

[jelwell]

My guess is you write your essays in a linear manner as well. Try an outline.
Joseph Elwell.

S____y antivirus software and CBDTPA

[yerricde]

There's insignificant cost to running the compiler twice as often

Unless, as several people commented in this story, management demands that you run antivirus software with the following policy: every time you run the compiler, you also run the virus scanner on the compiler binary, and the virus scanner takes twice as long as the compiler itself.

or looking something up in a manual or on the web.

Not if the CBDTPA passes, free software is declared illegal, and the operating system vendor makes its NDA'd developer manuals pay-per-read.

Re:Change your major.

[jelwell]

At UCSD Cognitive Science and Computer Science overlaps quite a bit, except that Cognitive Science requires little to no programming. Alot of my friends that couldn't hack the CS major switched to Cognitive Science. My apologies to Cognitive Science majors. I myself was very intrigued with CogSci and took many of the lower division classes and some of the upper division. I missed a minor by one quarter, but I chose graduation over the minor.
Joseph Elwell.

In my day

[rant-mode-on]

• I have no resect for any exam that involves writing actual code on paper

My first programs were written (yes, written) on paper and sent off to be put onto punched cards. You kids these days, you just don't know you're born.

Re:Change your major.

[jelwell]

1. Is it fair if you accidently write down 3-3=6 when you really meant 3+3=6? Typos in math are just as critical in Computer Science. But that's why you double/triple check your work.

2. Write it in pen, then type it up when you're done. And I think your doctor would disagree about typing being easier on your hands. I had never heard of carpal tunnel syndrome before I got a keyboard.

Maybe the whole "Change your major" is a little too strong. But the gist is, these tests are fair, and if you score poorly ask some of your peers how they did - I'm sure you'll find someone with a good score who earned it.

Joseph Elwell.

Whats up with these places...

[Pinball Wizard]

First we have math programs that won't let you use calculators, now CS tests that make you write code on paper. There's always that argument..."if you get stuck on a desert island and need to rebuild society you won't have the benefit of these modern tools." I've actually heard a variation of this, repeatedly.

The coolest professor(this was a EE class) I ever had did it this way - he made the tests extremely hard, but allowed open book, open notes, and calculators. His philosophy was that on the job you would use these tools, so you might as well use them on the tests. You were competent in the subject if you made it out with a C, and perhaps 2 people in a class of 20 would get an A.

Actually, I think CS tests are pointless, period. They have very little to do with your skill as a programmer or knowledge of the subject. Its much better to give hard assignments that require lots of work before they are due(i.e. a two week assignment that is virtually impossible to finish the weekend before it is due). I can see concepts on tests, and perhaps a few functions to demonstrate knowledge of certain algorithms, but a 500 line program is ridiculous.

Re:Whats up with these places...

[elflord]

First we have math programs that won't let you use calculators, now CS tests that make you write code on paper.

I think the point is that the tests are supposed to be designed in such a way that you don't need a calculator or computer. The students whine about this because they reach for their calculators if you ask them 2+2.

Another issue is with graphing calculators: there are some tests where the questions are conceptual questions about the behaviour of functions, and the students are supposed to be able to compute (for example) the vertex of a parabola, so giving them a calculator that they could graph it on would defeat the purpose of the test. You didn't bring calculators to elementary school when you learned your times tables, did you ? (or don't they learn those any more ?)

Similar arguments are applicable with writing code on paper. Maybe you are testing the students capacity to check code for themselves, without having a computer tell them whether their program is correct. In the real world, of course, you have a computer, but your program is also very large, and an error will not necessarily produce an immediate bug that surfaces within 20 lines of the offending line of code.

There's always that argument..."if you get stuck on a desert island and need to rebuild society you won't have the benefit of these modern tools."

That's a straw man. The real problem is that you're not going to be able to simulate the real world under exam conditions.

Actually, I think CS tests are pointless, period. They have very little to do with your skill as a programmer or knowledge of the subject.

Sure they do. An algorithms test can ask questions about algorithms. They can be conceptual, they can involve proofs or pseudocode implementation. Either way, they test your knowledge and understanding of algorithms. Replace "algorithms" with any subject and repeat (-; Off-the-cuff remarks like yours strike me as cheap rationalisations employed by weak (or lazy) students.

Exams don't necessarily test "your skill as a programmer", because they're not necessarily supposed to. Mastery of the syllabus usually does not mean the same thing as "skill as a programmer".

can see concepts on tests, and perhaps a few functions to demonstrate knowledge of certain algorithms, but a 500 line program is ridiculous.

I agree that a 500 line program is ridiculous, and I suspect that it's also an exaggeration. I've never seen any school do anything remotely like this.

PROLETARIAN

[foonf]

is the word you are looking for

Notepad, or ed?

[yerricde]

It seems that you've associated syntax and semantics with the visual cues of a computer.

Quick, in what order do the arguments come in the C standard library's fread()? What about qsort()? If you were in a real coding situation, you could pull it up in man or something within two seconds.

Stop using IDEs. Use the plainest text editor that you can find to write your code.

Is using Microsoft Notepad OK (that's what I use half the time anyway), or do I have to go back to ed (or edlin, its MS equivalent)?

Write code away from a computer. Use a pencil and paper.

I did this in high school when I had already finished all pending short-term course assignments. It worked. Paper and pencil really helps a fellow visualize the analytic geometry necessary to develop a 2.5-dimensional real-time graphics engine. (Yes, 2.5-D engines are still in use on handheld gaming platforms.)

Code on paper == good

[lkaos]

If a professor just takes code from paper and then puts it into a compiler and just checks the output, then that surely is unfair.

But if a professor takes the handwritten code and merely reads it, he then gains a valuable insight into the skill level of the student.

If a student struggles with all sorts of compile errors but finally gets a piece of code to work, while another student generates the code very quickly, who has learned more? Who deserves the better grade? Who will be more productive in the real world?

Having a compiler is like having training wheels on a bicycle. After a certain point, one shouldn't need either.

These tests are wrong.

[acidblood]

I feel the same way -- every written test I had to take, I was proficient on the underlying theory, and would be able to code it in front of a computer. Most of the time I miss the 100% grade due to an off-by-one error, or an `if' clause testing the exact opposite of what I intended to. These sort of errors are easily spotted if you have a computer to aid in debugging, and that's why I believe coding tests should be done on a computer, period. Especially with students unfamiliar with the mechanics of coding -- after a few years of daily coding, a person seldom commits these silly errors.

As a side note, having learned touch typing, it's really hard to write on paper. Thoughts flow much faster than handwriting, and you end up losing yourself sometimes. I'm positive that also affects other coders when doing written tests.

Re:These tests are wrong.

[elflord]

I feel the same way -- every written test I had to take, I was proficient on the underlying theory, and would be able to code it in front of a computer. Most of the time I miss the 100% grade due to an off-by-one error, or an `if' clause testing the exact opposite of what I intended to. These sort of errors are easily spotted if you have a computer to aid in debugging, and that's why I believe coding tests should be done on a computer, period.

I think the point is that you're supposed to "understand" it well enough that you can write simple programs that do not contain fencepost errors, and that you can write condition tests correctly. Of course a tool as powerful as a computer can help you diagnose your mistakes-- on a trivial 20 line program. On a program that is thousands of lines long, however, logic errors are not immediately detectable. That is why you want to be able to get it right without waiting for a core dump.

This may sound harsh, but it sounds to me like you're just whining. I mean, everyone thinks they're "proficient on the underlying theory", but when it comes down to it, some people are more proficient than others, some are "proficient" enough to get simple questions right all of the time. My advice is to quit whining and just do the exam -- when I say just do it, I also mean prepare for it, practice with similar questions, and make sure you "understand the underlying theory" in a way that leads to giving correct answers on exams.

They aren't testing your code, usually

[Nelson]

They are testing your ability to communicate. The best programmer in the world is useless if he can't communicate with the rest of his team. The idea behind those tests often is to see how well you can code/pseudo code up something. Often the problem is big enough that you can't just code up the answer right there and have to use some pseudocode and they get to see how you model a solution and start to build it. Now if they are going to get all syntaxy on you and doc you for swapping the args on memcpy or something then they aren't terribly good tests or really fair.

It's also worth noting that this kind of thing starts to be the cross over from hacking in to software engineering. You know there is a whole school of thought and practice (usually only for very important things) where the developers don't get to compile their code. You get a document that tells you to produce something, you code it up, you hand it over to an SCM person who compiles it and tells you if it compiles or not (they don't tell you why if it fails) if it fails you and your team start combing through everything looking for problems. Once it compiles it goes on to test and they react in a similar way. The idea is that you find and fix other problems when you don't know what the problem is. It works, there are aerospace applications and defense applications that have been produced that way and the correctness of the output is staggering, so is the cost of production but it costs a lot to make really really robust software.

As someone who has also done a fair share of BIOS and boot coding, there is something to be said for writing some code, reading it, seeing that it should be correct and then trying it. When it takes 15minutes to compile something, burn it in to an EEPROM or flash and then try it out you put a little more importance on proof reading the code regardless of what a compiler tells you. It's far more efficient to write something, debug it in your mind, rewrite it, then try it in those kinds of environments.

While I'm writing this, I'm reminded of Linus' dislike of kernel gdb code. You know what his thinking is? If you need to walk through it in the debugger to make it work, then you probably didn't understand everything that was going on in the first place. I really can't disagree with that, the problem with his product is that there are a lot of rules and conventions that aren't well documented so you can read them, step in and write a driver and understand all that is happening..

Personally, I start getting a little suspicious when someone can't code C++ or C without VC++ and intellisense or they need some wizbang Smalltalk IDE with drag and drop. Tools are great but they don't make the programmer. In the right hands they can make things more efficient and we all have our preferences but being unable to use other tools to do the same work isn't a limitation of the tool, the language, the platform or anything but the programmer. In the end, tools are just tools and all the tools in the world won't produce great products without great programmers using them.

If you can't produce programs away from a computer then I'd start working on it. It really says more about the kind of a programmer you are than the test. There will always be anxieties and things like that, those are often related to test taking skills, but if you simply cannot think through a program and start to produce something that looks like code without a computer then I think you should start practicing it a lot more. You may be a hell of a perl or C coder but you might not be much of a software engineer yet. (not to be personal, no ill feelings intended)

Re:ABSOLUTE BULLSHIT!!!

[CaseyB]

The problem and the object model created to define it will provide the solution. That's the ONLY way to code it.

You think that programming is a completely deterministic process? That there is only one way to model a given problem? You're the moron.

Write code so the machine will NEVER do ANYTHING it doesn't need to.

That means NEVER EVER use ANYTHING but hand written assembly language, that uses every shortcut in the book. It is assumed that maintainability has ZERO priority.

Cache every execution result that you will need again. RAM is cheap.

It is assumed that you have an infinite amount of RAM. Google should optimize by storing both the page cache and the HTML output of every single query ever executed in RAM, in case the exact query is repeated twice.

But RAM is not so cheap that you need to waste money and time filling it unnecessarily. Only cache what you absolutely need again.

Wait, what I just said, do the exact opposite.

I loathe moron who keep saying that software development is an individual's preference.

It's not all individual preference. But your attitude that there is only one way to solve any given problem, and that optimization is always the only priority, is equal bullshit. And your posturing and ranting bespeaks a religious zeal that kills development teams in their tracks. You'd be off any team of mine in a matter of days.

You need to be able to do this

[mmmmbeer]

I, too, find it easier to write code on a computer, but there are times when you need to be able to write something out longhand. If you have a lot of difficulty doing so, I suggest you practice it. It can be a very useful skill to have.

First, it's something that will come up during an interview, and you can look really bad if you can't do it. I have given more than one interview when an otherwise impressive candidate was turned down because they couldn't write a relatively simple algorithm. I've also been on the other side of the table, where it really gave me an opportunity to distinguish myself. (Btw, from an interviewer's perspective, what's more important there is the approach, not the end results. I wouldn't be surprised if many of your teachers feel the same way.)

Also, it's often necessary to be able to write out code when you're working in a team. It's not always enough to just describe your approach, especially if another programmer wants to go a different way. It's like any visual aid, it helps you get your point across.

Finally, it can be useful when working on your own. I sometimes find that it's helpful for writing complex programs if I sketch it out longhand first. It helps me guarantee I haven't left anything out, so I don't have to go back over my code as much.

So, is having students write code on an exam a good way to test their coding skills? I don't know. But maybe coding skills aren't all they're testing.

Re:Funny you mention Microsoft

[Anonymous Brave Guy]

The recruiter wanted me to code some function in C, on paper, right there in front of him. It wasn't a very complicated function, but the environment made it very difficult. After I put together something that seemed reasonably correct, he proceeded to pick apart every little mistake, things that I easily would have corrected after the first compiler warning/error.

I think people often miss the point of tests like these: they aren't just about your programming ability.

A pressure test such as this also shows your approach to solving a problem, because the interviewer(s) can follow you as you work through it. It also demonstrates your level of communication skills; can you explain what you are doing clearly and correctly to your peers?

It does also indicate a certain level of competence. It's all very well saying "oh, the compiler would have warned me, so I didn't need to get it right", but the compiler won't warn you about poor style, an obvious inefficiency in your code, or the fact that you used the wrong variable name although it made perfect sense according to the grammar of the language.

A good guy doesn't make these mistakes in the first place. A less good guy makes them, but is sufficiently careful with heeding warnings and using diagnostic tools that he finds them and fixes them. A guy you don't want to hire makes them and then argues that it's OK because the compiler would have warned him if it had been real.

This is Bullshit

[The Living Fractal]

An exam is an exam, everyone takes the same fucking one, or something which is basically the same, which teachers do to deter cheating -- you, however, are whining. Just like I whined about Trig in High School, yet everyone had to do the same exact thing, so I was an idiot.

But at least I learned, and moved on. I mean come on man, you're just grabbing for sentiment. Go take the fucking test, you either know how to write code, on a napkin, on paper, in a computer, on your girlfriends back as you rail her from behind, or your boyfriends, from the looks of it, but it doesn't fucking matter any way you look at it: it's you who writes it.

This test is a measurement of nothing more than your ability to take this test. Why do people think it was ever anything more?

Want some cheese or what?

No they are not fair BUT....

[Brian_Ellenberger]

No they are not fair, but they are probably the only way of assessing whether or not a student in a lower level course (sophomore or below) has really learned the material.

This goes back to a previously Slashdot article on getting help on your Computer Science programs. Someone in a beginning CS course can probably "get by" on their programs by getting help (honestly or cheating) and/or by using the internet/books for examples and hacking away at the code. The only way to really assess whether the student has learned anything themselves is to sit them down in a closed atmosphere and see if the student really knows something by giving them a test.

Now my experience has been that in upper level classes the amount of code writing done on tests is greatly reduced. This is because being able to "get by" on the more difficult assignments is harder and there is enough material of greater complexity to test the student on higher level concepts without requiring getting into detailed code. The student is still expected to write pseudocode however, but this is more to show that you can solve a particular problem (say creating an algorithm) than testing your ability to write C code.

The ability to write code/pseudocode outside the computer is not a useless skill. In my experience I have done alot of whiteboard coding in groups on different projects when brainstorming solutions to problems. I have also had to do it on interviews to show I knew my stuff.

Brian Ellenberger

I'm curious...

[Anomolous Cow Herd]

How could he work things out on the paino if he was deaf?

500+ lines?! On an EXAM!?!?!

[dutky]

In the entire 4 years that I spent in the CS department at a well respected state university I never saw an exam that required more than 100 lines of actual code to answer a question. All of the heavy lifting was done in the projects, and only snippets or toy programs were used for exam questions.

If your school is making you write hundreds of lines of code, on an exam, and requiring that the code be ready to both compile and run flawlessly, I'd advise you to look for another school: first, the fact that the department seems to fixated on generating code in a particular language is a very bad sign. Computer science is not about coding, but about the theory and structure of programs and computation, none of which needs to be expressed in the kind of strict syntax required of real-world programming languages. Second, the fact that the department even thinks that anyone could write hundreds of lines of code in a couple hours and have any hope the code compiling correctly, much less working, is ridiculous and suggests that the department itself is less than top quality.

All of that said, when I was required to write real code on an exam, there was always some leeway for 'typos' (or whatever the equivalent is when you are writing with a pen, rather than typing at a keyboard). Most of the time, however, only psuedo-code was required. Even my computer architecture course, where we discussed scheduling of machine instructions, allowed the use of entirely hypothetical assembly languages on the exams.

Programming is a necessary tool

[VP]

Unlike fluid mechanics, where you can learn, and do research without knowing plumbing, you cannot be a good computer scientist without being very good at programming. Exams, which require you to write correct code, are usually done in introductory classes where the goal is to teach you programming in a specific language.

Learning the exact syntax and idioms of a particular language in an introductory class is necessary, as it teaches you how to learn a new language as much as it teaches you the basics of programming.

Re:Programming is a necessary tool

[Lictor]

Excellent point.

I do, though, think it possible to be a good theoretical computer scientist without being a "very good programmer". The level one works on here is so abstract, that being able to write blindingly efficient C code is far less important than being intimately familiar with axiomatic set theory. And these folks still make a very important contribution to computer science as whole.

In most other areas of CS though, you're bang on.

Re:Programming is a necessary tool

[gregbaker]

...introductory classes where the goal is to teach you programming in a specific language.

Teaching a specific programming language is the goal of no introductory computing science course. If you took one and still think so, you missed the point.

In an average introductory CS course, you should learn things like ADTs, recursion, control structures and basic algorithms. Depending on the slant, also some introductory OO.

Learning things like "put a semicolon after each statement" or "'else if' is really two words" are just side points that let you do an assignment that exercises the real concepts. I know of some CS courses that give students a choice of the language for their assignments. I think this is a fine idea; it forces them to realize that the language doesn't matter (concept-wise).

It's fair.

[Anonymous Coward]

Maybe you're missing the fact that there are those of us who can handle such tests. I'm sorry if this is out of your grasp but keep on trying and maybe one day you will be able to do the same thing. I've tutored plenty of students in many programming languages and there really is just a few who understand things well enough to do exams on paper. They also turn out to be awesome programmers in the end. If you can't handle writing code on paper then stop filling up an industry that used to be populated by intellectuals. Stop causing the standards to be lowered in the universities. Anybody who has been within the academia environment for the past 20 years knows what I'm talking about. The students have gotten dumber, probably because the job pay has gone up.

May not be fair but helpful.

[jellomizer]

Is there any type of CS Testing that is fair. Me personally will do better on the coding questions then on True False statements because I personally over read the answer and I miss enterprit the queston and put the wrong answer. But the trick for coding questions is to read the question. Make Psuto Code then convert it to the language that the class is teaching with. The problem I find with a lot of CS Students they enter the degree with the mind set that sience they can program and make advanced programs they assume that they are good at it. While they may be able to make it work it may not be the best algorithem. I get this from the parent post because 500+ lines for a test is way to much. I would think it may be 60 lines or so. And you havent studied the algorithm that they wanted to teach you.

The best formula for the class

[gers0667]

I'm a CS student at Kettering, and I've never had something more than a 5 page exam. We have labs where we are graded on technique, and then tests based on theory. Example... I had to write parser code in Java, but for the exam, I had to draw the Parse Tree, no code at all.

The best professor I ever had

[eples]

The best professor I ever had could do everything in his head, hundreds of lines of code. He knew exactly how the compiler would react to anything.

He didn't just teach us the syntax and the languages, he taught us how to do *that*, and *that*, to me, is a f-ing awesome skill.
Dr. Caviness. We used to joke about him being the "human compiler". He ruled.

My thoughts

[da3dAlus]

I'm going to skip reading most of the comments and post my $0.02, even though I'm sure it may be similiar to a lot of other people's thoughts.
It all boils down to the professor most of the time. For the most part, I agree that if exact (ie, correctly formatted and working) code is required, you HAVE to be sitting at a computer and have a chance to compile, find errors, and fix your code. However, I had a lot of professors that were more concerned about the form and function as described by pseudo-code.
Honestly, I have found that paper code makes you more prepared for the real business world. ie, If you are working as a programmer, and you are discussing specs with a client, there may be times where you need to think quickly about a problem from the programming perspective. This usually (for me at least) gives me a minute to jot down some code that pops into my head--without regard to whether or not it will actually work the first time. If you depend too heavily on using a computer to make sure that code works, you may not be able to trust in yourself. I kinda equate it to the argument that reliance on calculators makes you forget basic math when you're in a pinch. If you do a little on paper now and then, you keep it fresh in your mind--check it on your computer/calculator later.

Coding for projects--Exams for concepts

[geisler]

I'm shocked to see how many people are complaining about this issue. To me, the real test of your coding skills should be done with homework assignments and projects. They show that you understand the problem and how to solve it using the paradigm given.

As others have said, the role of exams is to test the CS concepts being taught: algorithms, methodologies and problem solving skills. It's important to be able to demonstrate you know what a linked list is and when it should be used instead of an array, but that doesn't require a significant amount of coding in the test.

Re:Change your major.

[ceejayoz]

1. Generally, 3-3 or 3+3 is something you'll be allowed to check on your calculator. The final answer in a math equation is like the compiler - if you get a negative area, for example, you know you probably did something wrong along the way.

2. I get cramps in my hands within 30-45 minutes of writing. I can type away for 8 hours straight without major problems. That's not even the main issue - handwriting is. I've graded CS exams before and it's obnoxious - half the time you can't read it.

Re:It is silly - the question that is

[elflord]

Why would anyone want a programmer to know how to code a linked list? Its a waste of time. No one is gonna code it from scratch, its a trivial and demeaning question.

I'd want to know, because a hell of a lot of people graduate from CS degrees without knowing how to do this properly. You're not really looking for whether the interviewee can write the code with immaculate syntax, the main concern is whether or not they understand the basic concepts, and all of the subtle implementation issues

I know if I went into an interview and someone asked me for code like that, I'd tell them straight up that I'd look that up in a book or online, and that it'd be a waste of my time to write it.

That's like an elementary school student telling the teacher that they'd just use a calculator if someone asked them to add two numbers. Of course, one could do it like that, but the point is that the interviewer is interested in knowing whether or not you understand how to implement a linked list. There's a good reason for asking questions about a data structure that has been implemented millions of times-- it's something that everyone is expected to know how to do.

Maybe if you're hiring greenhorns straight out of school you might ask a dumb question like this just to make sure they aren't completely clueless, but for experienced programmers its frankly a poor test to find a good problem solver.

Even people who write programming books frequently make a complete mess out of linked list data structures. So I'd consider the question fair game, even for "experienced developers". By the way, I think you're greatly underrating the subtlety of this question. It's not trivial, there are a lot of interesting issues and tradeoffs that come up in designing such a class, and most books screw it up.

Moot point

[acoustix]

Why would a four year school (like uni) let you do a lab test when they don't even give you lab hours in the classes?

I was there (uni) and out of all of my classes I only received 2 hours a WEEK of lab time in class. Everything else was lecturing.

So if 95% of the class time is lecture then I would assume that 95% of the test will be theory. The other 5% would be lab time.

What's the point of telling a person how to code something (or how to perform any function for that matter) if you're not going to let them do it until next week?

Professor: "OK class, this part is very important! You have to do X and Y to get the result of Z. You will do this next week in lab with my TA's. That is all. Class dismissed."

If you can't write it...

[geekoid]

... you don't know it.
In the "olden" days, you wrote your program out, then put it in the computer, it failes, loose a letter, try again.
Now programmers are more try this, doesn;t work? try this? doesn't work, change this. I swear, if I hear "I don't know why this change worked, but it did" one more time, I'll scream.
I can't think of any other engineering where creating by "vibe" would be acceptable.
We sure as hell didn't create software to get someone on the moon by "vibe".
What else you want for your exam. use of a help system? you mommy to hold your hand? sheesh.

Re:Answer: Not fair. But we have to do it anyway.

[geekoid]

so you feel its OK to pass students who would waste there employers time having to run a compiler over and over again because they where not trained to pay attention to what they are doing?
Why don't you just show them how to use the help system, then pass them? after all, they can look it up online.

assignments bulk of grade / drop coding altogether

[kidlinux]

A lot of people seem to say that "As long as they mark your problem solving skills and not how perfect your code is, it's ok."

I agree, however, that's not the way it works. In my first year CS courses, we lost marks if we so much as forgot a bracket. That's rediculous. Small things like that happen when you ask someone to write code on paper under exam conditions.

What I think should be done, if writing midterms and finals on a computer is out of the question, is that assignments should be given the most weight on the final grade. Our CS assignments were handed out weekly, and due the following week. That allows you to take it home, code as many solutions as you can in a week, debug it, etc. I think this approach is a far more accurate description of one's skills as a programmer.
Another way about it would be to have a "final assingment", which combines all of the skills taught during the semester into one larger than average assignment. You'd have a week to complete this assignment, like the others, but it'd be weighted more.

Of course, an obvious problem with my suggestions would be cheating. And at the moment, all solutions to this problem I can think of don't seem like they'd be any good.
I'm open to suggestions.

Another approach is to change the way CS tests (midterms and finals) are designed. Drop as much of the coding as possible, and simply ask the student to apply the principles they've learned to a variety of problems. This would be a mostly written exam, which leaves it open to subjective grading. Maybe that's the way it should be. Computer Science is about problem solving, not coding. Anyone in CS should know that programming is a drop in the bucket of Computer Science. If you're designing a solution to a problem, you should know how to express your solution in words just as well as you can think of it.

Re:Answer: Not fair. But we have to do it anyway.

[IvyMike]

so you feel its OK to pass students who would waste there employers time having to run a compiler over and over again because they where not trained to pay attention to what they are doing? Why don't you just show them how to use the help system, then pass them? after all, they can look it up online.

Don't be so obtuse; of course that's not what we did. Quick, without looking: what are the arguments passed into "strtok()"? Personally, I don't know for sure, and that doesn't matter, because "man strtok" gets me the answer on the rare occasion that I need to use it. But it doesn't tell me when I want to use the function, or how to use it in a tokenizer, and as it turns out, I do know that part. And that's the kind of thing that's more interesting to test for. Memorization monkies aren't good employees; good problem solvers are.

But perhaps you have a point; clearly, your grammar and spelling teachers weren't strict enough.

Re:assignments bulk of grade / drop coding altoget

[elflord]

I agree, however, that's not the way it works. In my first year CS courses, we lost marks if we so much as forgot a bracket. That's rediculous.

Might be "how it works" in your experience, but there's no reason why this is always "the way it works". In any case, your complaint is about the fact that in your experience exams were poorly graded. An obvious solution to this problem is to use a better grading scheme for exam papers (-;

That allows you to take it home, code as many solutions as you can in a week, debug it, etc. I think this approach is a far more accurate description of one's skills as a programmer.

Nope. A good programmer should be able to write simple programs correctly without having the computer to test it for them. If they can take it home, everyone should (and in practice, usually does) get it, but in an exam room, you're measuring how good the students are at catching mistakes (or not making them in the first place) without the computers help.

Of course, an obvious problem with my suggestions would be cheating.

Yep. That's why this solution isn't used in practice. It unfairly penalises honest students.

Another approach is to change the way CS tests (midterms and finals) are designed. Drop as much of the coding as possible, and simply ask the student to apply the principles they've learned to a variety of problems. This would be a mostly written exam, which leaves it open to subjective grading. Maybe that's the way it should be. Computer Science is about problem solving, not coding.

I mostly agree with this. First year courses do need a lot of coding, so that students acquire the basic skills to coherently express their ideas. I wouldn't put a lot of coding on an exam uness it was an open-notes test.

Re:ABSOLUTE BULLSHIT!!!

[Tadrith]

So, what you're telling me is that there is only one way to store data, and that personal preference has absolutely nothing to do with it?

Wow, I'd really like to know what kind of programming you've done lately. Perhaps in procedural programming there is a set place to put things, but as far as OOP goes, I'd say there's quite a few ways you could arrange things. People have different reasons for coding things differently, both syntactically and in organization. One person may find it more convenient to store something in a simply ASCII text file, someone may find a small but efficient database system better.

I agree, you shouldn't use more resources than you have to, but there are multiple ways of accomplishing things, each with their own benefits and drawbacks. If you can't see that, I'd really hate to see what happens when you have to work together with someone on something.

OK, this is actually true

[Simon Brooke]

When I first went to University, I signed up for a Computing Science course. It was very, very bad. So, having averaged 80% on coursework through the year, when it came to the end of first year exam instead of answering any of the questions on the paper I wrote a detailed critique of what was wrong with the course.

Naturally, I got zero marks for that exam, and went on to take a degree in something completely different, including a Philosophy minor. Immediately on graduating I got head-hunted by the systems engineering department, and within two year was on the academic staff of the Computing Department.

That's fifteen years ago, and I've been getting paid for writing (and teaching people to write) interesting software ever since. I still don't have any computing qualification. The moral of the story: you don't take a course in quill-cutting to learn how to write great literature. In the Computing Department, when I was a student, they were teaching us to write bar-graph generators in PASCAL on punch-cards to be fed into mainframes; in the Philosophy department they were teaching us to write theorem provers and inference engines in LISP and PROLOG (with a side order on the meta-mathematical basis for the designs of the language interpreters themselves) on micro-computers. Guess which turned out to be more relevent in the real world?

Here comes the clue, try to catch it.

[slashdot_commentator]

1) Most universities determine the grade in the class by how well you do in relation to your classmates, not by a fixed percentage of correct answers. If you only get 30% right in a test, and you answered the most questions correctly, you get an A. (Unless the professor has a different policy and the tenure to enforce it.) If your classmates are pumping out functionally correct programs on paper, and you aren't, you should not get an A because you "tried" hard to learn the class material, or can regurgitate theory but cannot code for your life.

The tragic reality is that in many competitive majors, you end up being responsible for a ridiculous amount of knowlege in a class, some of which would be more appropriate in an advanced class. This is deliberate; to ensure the people who can regurgitate the most get A's, and the also-rans arbitrarily get B's, C's, etc. "Separate the pre-meds from the med-techs." You should always strive to absorb the most amount of knowlege, but if you can't outperform enough of your other classmates, it means you should be looking for another field of study (and thus career) where you can perform better in relation to your peers. Everyone was not meant to be a programmer or a computer specialist.

2) On a final exam, the professor should not be using as a program question something that would require 500 lines of code. But asking to implement a data structure in code, or a basic algorithm, like a heap sort, should be perfectly reasonable task to be completed in a set time. The professor takes off points in syntax, and your other classmates can code on paper with less errors than you, whallah, they have a greater mastery of the course material than you. They should get the higher grade. An aside: if you can't code in your head under pressure, you have no business picking a career in the computer industry.

3) If you were truly a bright and mature student worthy of a higher grade than your classmates, and you were aware that you have a deficiency with programming on paper, you would PREPARE for the challenge you know you will confront at exam time, not whine that it is unfair. This can easily be done by writing every programming assignment on paper before implementing it in an IDE. Yeah it takes inordinate amounts of time, and yeah, you won't have a reference book in the exam room, but practice makes perfect.

When I went to college, IDE's did not exist. The line editor we used to input code on the mainframe made edlin a pleasurable experience by comparison. It was faster to write programs on paper, and that's what many people did, including your professor. Did this generation wallow in self-pity and not participate in the computer revolution because we had to write our program exams on paper? (And before you get bent out of shape by the presentation of my context, please re-read (3).)

I could blather on forever about exceptional cases, post-primary education, etc. but it can be boiled down to the final clue:

4) Life is unfair, college is a subset of life, and a bachelors degree does not mean the possessor mastered an academic subject. Grow up, make the difficult decisions, do better, and please not let this diatribe be a waste of our time.

Re:hexa

[lrichardson]

Wow! Checked out your web site ... you desperately need to get a grip! I think you've been swayed way too much by the dominant paradigm (binary) in computers. There's the blindingly obvious advantage of decimal ... ten fingers. And there's a damn practical reason why lots of things (i.e. time) are in base 12 ... it divides into more (common) factors {2,3,4,6} than both 16 {2,4,8} or 10 {2,5}.

The finger counting example (base 6) is pitiful. Why? Because millions of people are taught an alternative method which allows you to reach 99, rather than the maximum of 35 your method allows. (FYI, right fingers:1, right thumb:5, left fingers:10, left thumb:50).

I can't decide whether your website is satirical, or seriously deluded. If the first, it isn't obvious. If the second, then I've got a revelation for you: whatever base we choose is arbitrary.

10 and 12 both offer real advantages over 16. And the rest of the world operates on 10 and 12, not 16. Get over it.

Same thing about physics

[KjetilK]

Well, CS exams has been much more friendly to me. I've got just a couple, though. My first was really easy, and the second, well, the course sucked so much I had really given up the whole class one month in advance, but showed up at the exam anyway. They gave us a problem on non-natural splines that was really interesting, so I did well on that exam too. But it is the only exam problem that I can say has had that quality in my 8 years.

I've been arguing that physics exams, on the other hand, is a major problem for critical thinking. I even had an article in the journal "Physics World" about it.

Re:We did these at the Rochester Institute of Tech

[0x0d0a]

I just completed Java and COBOL courses

Those are some odd bedfellows.

Re:hexa

[jellomizer]

So you are saying that we should use 0x3C or 3Ch except for 60 and 0x1F4+ and 1F4h+ except for 500+ A real geek will find a way to display there value with the least amount of typing. I also find it funny that you couldnt even give us the Hex Value wich makes me suspect that you cannot convert 2 simple numbers to hex. So I 3 lines of advice and an example for you.

1. Get a life.
2. Use what is effecient for the task
3. and if you want to be really geeky use binary.
60 = 0000000000111100b
500 = 0000000111110100b
and I am leaving the leading 0s in a 16bit array to show that is is a positive number in 2s complement.

Using HEX is for the week at heart who is to stupid or lazy to convert a decimal number to binary they want someting that lines up easly.

Re:hexa

[devnullkac]

I doubt "Hexa Person" actually advocates the use of hexadecimal. Judging from the posting pattern, s/he simply wandered around the site linked by the "Physics in the Movies" post, discovered the Hexadecimal pages, and constructed a new Slashdot account devoted to insulting other posters. Fortunately, it looks like s/he got tired and went to bed after an hour and a half of this nonsense. Hopefully s/he'll forget about it in the morning.

The irony is that Hexa Person doesn't really understand hexadecimal, since there are comments of the form "$16.99 should be written 10h.99." 0x10.99 is only 16.59765625 decimal.

All recusive functions are loops!!!

[oliverthered]

Ok this is why it's a good question
given the following code

rteval f(x,.....){

f(x,......);
}

all calling f(x) inside f(x) does is allocate some space on the stack, this stack space can be preallocated as an array, so that a loop can be used instead of a recursive function call..

Re:DisAgree

[WowTIP]

Well, that problem is not only related to coding, but writing in general, for me. Somehow it feels so much easier and faster to write with a keyboard than with the ordinary pencil and paper. I guess it has to do with computer text being easier to modify and rearrange than the handwritten stuff. Not to talk about the looks of the finished result. My handwriting isn't that easy to read, not that it's ugly, just hard to interpret. I just have to wonder how many points that has cost me at different exams?

Re:We did these at the Rochester Institute of Tech

[jedidiah]

a) What are you doing coding a single chunk of code that's 10K lines long anyways?

b) Any good compiler should be able to take you straight to the line where you forgot the semi-colon.

Re: code on exams

[jedidiah]

Their 40 GigaBucks have little to do with how they treat their programmers.

Me too

[macdaddy]

I had the same problem. They teach us to use the debuggers and trial and error to our advantage. Then they don't actually let us use it in the end. They teach us the process that we'll actually use in the industry, then they want to to resort to pen and paper for testing purposes. It just doesn't compute.

Re: code on exams

[Alex Belits]

I programmed various things since 1986, and in all that time I have never seen a project being completed on time.

i could have ment linked/doubly-linked

[oliverthered]

Here's my like
1[x 2] = 'aa....a'
2[1 3] = 'aa...b'
3[2 4] = 'aa...c'
4[3 5] = 'aa.....ba'
etc...
say eack node has a 10k string in it,
you may need to search all 10000 nodes,

you'r not looking for the data pointer that matches, you looking for the data,so a log2(n) search is not only possible, but probably faster.

Very Simple

[JohnHegarty]

Its very simple... what they should do.....

in the real world i have a computer and reference books , and caffine (ok last one not too revelent).... i don't have to write programs without those.... why should people be judged on a system that they will never see when they do get a job...

i have never seen anyone at my company writing software in a room with no computer...

What's in a name? Everyting!

[fm6]

Programming IS NOT "computer science" any more than telescope design is Astronomy (with apologies to Dykstra).

One of my profs used to object to the very term "computer science". Computers, according to him, are just instruments, and relating the discipline to them is misleading. "It's like calling Astronomers 'Telescopists'." (Hmm, was he plagiarizing Dykstra?) I think he preferred "Information Science". At least, that was the name of the department he chaired. But when I told people that was my major, they tended to infer that I was studying to be a librarian!

Being the first guy to figure out quicksort... thats science... thats research. Coding a quicksort in LISP is not.

I've ranted about this before, but it upsets me to see such a misleading headline.

There's no need to apologize. There are too many people who know some small aspect of computing, and think that qualifies them as experts. Quick, is chess a forced win for White? Ought to be easy to write a program to figure it out!

However, I don't care for your analogy. Discovering quicksort is original science. But not all science is original. Better to say that understanding all the theory relating to quicksort -- why it's faster than a pyramid sort, what kind of data impacts its performance in different ways -- is science. Implementing a quicksort routine is engineering. Writing a program that takes the routine and sorts data -- well, I want to call it coding, but that's not quite right.

There used to be people called mechanics. Nowadays that word basically means "repair person". But I think it used to be an honorable part of an important hierarchy. Scientists investigated basic principles. Engineers found practical implementation for those principles. And mechanics made these implementations work in day-to-day life. Nothing wrong with being a mechanic -- I consider myself one. But you shouldn't confuse it with more fundamental work.