Slashdot Mirror
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?
..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.
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...
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.
MARIJUANA, SHROOMS, X: ONLINE?! - E
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.
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
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.