Are Written Computer Science Exams a Fair Measure? 728
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?
Agreed (Score:2, Interesting)
Re:Agreed (Score:3, Funny)
package dataStructures;
public class FinalExam {
public boolean pass() {
return true;
}
public int grade() {
return 100;
}
}
AP Computer Science (Score:2, Interesting)
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 (Score:2, Insightful)
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?
..treat as real code? (Score:2, Informative)
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? (Score:2)
Error checking by compiler (Score:2, Insightful)
We did these at the Rochester Institute of Technol (Score:2, Informative)
I've also had profs that would take a point off for each syntax error...
Re:We did these at the Rochester Institute of Tech (Score:2, Interesting)
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:We did these at the Rochester Institute of Tech (Score:5, Informative)
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.
I feel the same way (Score:3, Insightful)
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 (Score:2, Insightful)
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 (Score:2, Interesting)
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
(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 (Score:3, Insightful)
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 (Score:2, Interesting)
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...
Psuedo-Code (Score:2)
Students can focus on the problem, and not writing the syntax, complete with all the () {} etc.
Hate it! (Score:5, Interesting)
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! (Score:2)
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! (Score:3, Insightful)
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! (Score:2, Insightful)
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! (Score:2)
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.
It depends what they ask and how they mark (Score:5, Insightful)
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:ABSOLUTE BULLSHIT!!! (Score:3, Interesting)
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.
Re:ABSOLUTE BULLSHIT!!! (Score:4, Insightful)
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.
I don't mean to sound mean.. (Score:2, Insightful)
Hopefully the prof will cut you some slack (Score:3, Interesting)
stravinsky (Score:2, Interesting)
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... (Score:3, Insightful)
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?
Written exams are fine... (Score:5, Interesting)
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... (Score:2)
No need for large portions (Score:2, Insightful)
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
depends on level of code (Score:2)
Now anything more complex then that. . .
Heh.
Of course depending on your working enviroment things become trickier.
If the class is taught in Visual Studio with MSDN installed. . . . That would have to be disabled on all of the workstations beforehand and the students instructed to use Notepad or such. Likewise for any other sort of IDE.
Writing code (not typing it) is *hard* (Score:5, Insightful)
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.
DESIGNING code (not typing it) is *hard* (Score:3, Insightful)
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:Writing code (not typing it) is *hard* (Score:3, Informative)
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.
One more thing I'd like to add... (Score:5, Interesting)
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:Writing code (not typing it) is *hard* (Score:4, Insightful)
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.
I also (Score:2)
Travis
Re:I also (Score:4, Insightful)
Just because you have a calculator is no excuse not to learn how to add.
Seems fair to me (Score:2)
Re:Seems fair to me (Score:2)
Re:Seems fair to me (Score:2)
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 (Score:2)
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.
An anlogy (Score:2)
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 (Score:2)
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 (Score:5, Insightful)
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 (Score:3)
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 (Score:5, Insightful)
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 (Score:3, Interesting)
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 (Score:5, Insightful)
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 (Score:2, Insightful)
Bad grammer on an English test? Gee, that sounds like arithmetic errors in a calculus test!
It's not the vibe... (Score:2)
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 (Score:3, Interesting)
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? (Score:2)
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 (Score:2)
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 (Score:2)
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 (Score:2)
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 (Score:2)
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
Good programmers use tools, not memorization (Score:5, Insightful)
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... (Score:2)
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.
500+ lines of code in a test? (Score:2)
Actually, poor and bad tests are my major gripe with the education system. I can't count the times I've looked at poorly worded question and known the subject completely, but because of the way the question was worded it wasn't obvious if the teacher wanted the straightforward answer, or thought they were being clever and asking a "trick question", since the straight forward answer wasn't right the way the question was asked. Not wanting to put up with bullshit like this caused me to pass us the chance to take a lot of free courses several years ago when I ran a computer center for a local university. Am I the only one who has a problem with tests like this?
Other disciplines, people just live with it (Score:3, Insightful)
In the field of computer science, specifically, you can make the claim that only the ability to express yourself in type - personally I can write by hand anything I could type, but that's me - matters professionally, so that's what you should test on. Certainly, those students who "choke up" when presented with a computer terminal shouldn't be in computer science courses, so you don't have the same problem you'd have giving exclusively oral tests in the humanities.
But I don't think it's true that you can totally neglect the ability to scribble code; there are situations where (for social reasons) I've had to do development work by hand-writing on printouts. If you're teaching someone else, it is often easier to scribble on a slip of paper than to talk and gesture at a computer screen.
In CS, it would be reasonable to have all the tests on computers. However, there is a certain justification for making sure people can write code by hand, and it isn't so difficult for most people to learn. I don't see it as a fairness question - the skill of writing code by hand is not terribly important, and your department may place disproportionate emphasis on it. That's unadvisable, but it's perfectly fair; it's the same skill for everyone, but some people can't do it. Too bad for them, but they've not suffered any injustice.
Now, personally, I think it's daft to have students write significant code during exams. If you're teaching programing, have the kids write programs and submit them. A little pseudocode on an exam ought to demonstrate the abstract understanding for which the written exam should be testing.
Pointless Exercise (Score:2)
I have never minded questions such as "prove that this block-of-code is Theta( n^3 )," or "provide a proof of correctness for the following...", or a "describe the structure of...", or even the occasional "analyze this code and provide the output," but actually forcing me to *write* the code is another matter entirely--one I'm particularly glad to have left behind in the earlier CS classes.
The worst was when I was asked to write a complete linked list class on a test... ugh, speaking of pain... particularly since I'm a dysgraphic.
Can anyone shed light on *why* professors seem to think that this is a good practice???
Re:Pointless Exercise (Score:2)
You might say, "it's computer _science_, we should learn concepts, not syntax", but concepts are useless without a means of implementation. Professors want to test your knowledge of the language used just as much as they want to test your knowledge of theory.
I had a CS professor give us a picture of a GUI, describe the behavior, and have us write the code to implement all of it. Being in java swing (and being only one of the six other questions on that test) it wasn't pretty, but how else are they to know that you know how to do what they've been preaching about? My implementation was a good two pages of code, but doable if you knew what you were doing. If you didn't know what you were doing, you failed miserably --- like you should.
If students were not required to have knowledge of code, I would not want to hire a graduate of that sort of program. Knowing how to do something is just important as knowing what it is.
Sounds like (Score:2)
I'm not talking about a full IEEE design document. I'm talking about something as simple as outlining the functions/objects/tasks you need to implement in order to solve the problem. You can not skimp on the design, even if its a trivial one.
Problem solving is problem solving, whether or not you type it into the computer or write it down on paper shouldn't matter.
Young whippersnappers - remember coding sheets? (Score:2)
But I understand where you're coming from. I never used coding sheets myself. I managed to avoid working anywhere that still did things that way (although I once worked as a data-entry keypunch operator in high school. Brrr...), for another I tend to prefer sitting down at a keyboard (keypunch, dumb terminal, workstation -- whatever) to actually bang out the code once I've got the basic outline done.
But writing it out by hand does force you to organize your thoughts a bit better. I can see it for short code segments (less than 50 lines). Requiring larger chunks of code to be handwritten is either an exercise in sadism for inflicting that or in masochism for wanting to read that much handwritten code. Or both.
Re:Young whippersnappers - remember coding sheets? (Score:2)
The latter is much better tested by assignments, and more easily graded with the computer's help.
Message to "me!": you're an idiot. (Score:2)
You're just making excuses, you know. When I was in high school, I made a big deal in one of my classes about how I couldn't write out an essay for a test unless I were in front of a typewriter, and I actually convinced the teacher to let me bring in a typewriter to type out my final exam (luckily the classroom had a small back room with a door, so I could clack away on my portable typewriter without annoying the rest of the class too much.) Fortunately, the experiment convinced me that if I couldn't write out my work in a blue book like the rest of the class, then I probably deserved to fail: if you're not able to write your ideas out on paper, indeed on the back of a napkin in ballpoint if that's all that's available, without the crutch of a computer (or a typewriter) to help you, then you're not much of a thinker.
Computer programming is mathematics, not painting. If you claim that you can't devise a good program unless just the right set of conditions is satisfied, then you're just as bad as the self-indulgent filmmaker who wastes a week of shooting time until the sunset is _just_ right and the the sand dunes have swirled into the right shape.
hyacinthus.
Re:Message to "me!": you're an idiot. (Score:2)
I would concur.
Also I cant spell at all unless i'm typing,
I don't think typing is the problem here...
A good marker knows how bad it is... (Score:2)
a grrl & her server [danamania.com]
Projects (Score:2)
Back in my day.... (Score:2, Interesting)
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 (Score:2)
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 (Score:2, Funny)
---
Never test for an error condition you don't know how to handle.
-- Steinbach
Some things can't be tested. (Score:2)
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... (Score:2)
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 (Score:2)
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 (Score:2)
Written Exams (Score:2, Interesting)
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 (Score:5, Insightful)
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! (Score:2, Interesting)
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.
Answer: Not fair. But we have to do it anyway. (Score:5, Insightful)
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.
The pen is mightier than the keyboard (Score:2, Informative)
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 (Score:5, Informative)
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
Why would you study at a place ... (Score:2)
Definitely not fair! (Score:3, Interesting)
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.
Are written plumbing exams a fair measure.... (Score:5, Insightful)
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.
Programming is a necessary tool (Score:4, Insightful)
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.
Whats up with these places... (Score:3, Insightful)
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.
These tests are wrong. (Score:3, Insightful)
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.
You need to be able to do this (Score:3, Insightful)
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.
May not be fair but helpful. (Score:3, Interesting)
The best professor I ever had (Score:3, Interesting)
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.
Re:simple (Score:4, Interesting)
Re:simple (Score:3, Insightful)
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.
overrated? (Score:2, Insightful)
Re: code on exams (Score:3, Insightful)
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?
Re: code on exams (Score:2)
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:Of course not (Score:2)
Re:Change your major. (Score:2)
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