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?
Re:simple (Score:4, Interesting)
Agreed (Score:2, Interesting)
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.
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...
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.
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.
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
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:simple (Score:1, Interesting)
Re:AP Computer Science (Score:0, Interesting)
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.
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.
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.
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: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...
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.
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:simple (Score:1, Interesting)
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.
This is Bullshit (Score:2, Interesting)
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?
It's fair. (Score:2, Interesting)
May not be fair but helpful. (Score:3, Interesting)
The best formula for the class (Score:2, Interesting)
Re:Writing code (not typing it) is *hard* (Score:2, 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.
Coding for projects--Exams for concepts (Score:2, Interesting)
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: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.