Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Programming IT Technology

Are Written Computer Science Exams a Fair Measure? 728

Posted by Cliff
from the unfair-testing-procedures dept.
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?
This discussion has been archived. No new comments can be posted.

Are Written Computer Science Exams a Fair Measure?

Comments Filter:
  • Agreed (Score:2, Interesting)

    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.
  • 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.
    • by DMDx86 (17373)

      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?
  • by Archon-X (264195)
    ..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.
    • 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...
  • by 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.
  • by 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...

    • 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..
    • by edrugtrader (442064) on Friday June 14, 2002 @07:10PM (#3705065) Homepage
      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.
  • by scode (22551) on Friday June 14, 2002 @06:36PM (#3704781) Homepage
    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!
    • 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.
    • by ginsu (37651)
      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. :)
  • 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! (Score:5, Interesting)

    by Tadrith (557354) on Friday June 14, 2002 @06:37PM (#3704789) Homepage
    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...
    • 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! (Score:3, Insightful)

        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! (Score:2, Insightful)

      by denial (92135)
      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.

      • 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.

    • 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.
  • .. 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.
  • by CodeMonky (10675) on Friday June 14, 2002 @06:39PM (#3704807) Homepage
    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.

  • stravinsky (Score:2, Interesting)

    by splorf (569185)
    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.

  • by Mad Browser (11442) on Friday June 14, 2002 @06:40PM (#3704809) Homepage
    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?
  • by cperciva (102828) on Friday June 14, 2002 @06:40PM (#3704811) Homepage
    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.
  • 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 :)
  • If it is just "write a for-next loop to print out your name 10 times" then I see no problem with it, nor do I see an issue with "Make an array of {whatever} size and fill every other position in it starting with the first one with X's and every other position in it starting with the second one with O's".

    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.
  • by seanadams.com (463190) on Friday June 14, 2002 @06:41PM (#3704823) Homepage
    ... 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.
    • 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.
    • 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.

    • by Kashif Shaikh (575991) on Friday June 14, 2002 @07:56PM (#3705289)
      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...

  • 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 (Score:4, Insightful)

      by Arandir (19206) on Friday June 14, 2002 @06:47PM (#3704889) Homepage Journal
      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.
  • 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.
    • 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.
    • 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.
  • 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&

    • 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)

    by Arandir (19206) on Friday June 14, 2002 @06:42PM (#3704834) Homepage Journal
    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.
    • "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.
    • by e40 (448424) on Friday June 14, 2002 @07:45PM (#3705240) Journal
      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.
    • by prockcore (543967) on Friday June 14, 2002 @07:49PM (#3705257)
      "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.
  • ...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 (Score:3, Interesting)

    by lrichardson (220639) on Friday June 14, 2002 @06:42PM (#3704836) Homepage
    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

  • 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.

  • 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
  • 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 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.

    .
  • 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
  • by Jack William Bell (84469) on Friday June 14, 2002 @06:44PM (#3704862) Homepage Journal
    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
  • 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.
  • I certainly would have a problem with this much code without sitting in front of a computer and having the basic tools handy. I expect if I found that exams were of this nature I would drop the course, change schools, or just get a job.

    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?

  • There are people who have the same problem, in other fields, when expressing themselves in writing instead of orally. It just causes them to choke up. Those people don't do as well on tests and there isn't really anything you can do about it. If university exams were all given orally (expense aside) another group of people would choke up because they can't talk good.

    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.
  • Just remember: Academics is 20% intelligence and 80% jumping through hoops.

    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???
    • They do it because it's the next logical step to determine whether or not you truly understand a topic. Sure, you may be able to describe a linked list out the wazoo, but do you understand enough to implement it?

      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.
  • You are too used to being able to change your mind on the fly. Too me, this is an indication that you haven't thought the problem out from start to finish or done the proper design work up front.

    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.

  • Back in the days of punch cards, most programmers were expected to hand-write their programs on coding sheets -- essentially lined pages with the individual columns (80, to match the card) marked off. You could get them with different columns highlighted for the languages where that was critical (FORTRAN, COBOL, etc). Then you turned those pages over to a keypunch operator and she (usually a she) punched up the card deck for you.

    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.
    • BTW, all that said, I don't recall my CS exams requiring a whole lot of code on them. Some, sure -- and they'd usually accept any reasonable pseudocode that got the algorithm across -- but most of the exam questions related to concepts, not "bang out a program to do X, Y and Z".

      The latter is much better tested by assignments, and more easily graded with the computer's help.
  • Sheesh. So you need to be sitting in front of a computer to be able to write out a good algorithm? What are you, some kind of goddamn artist? Next, you're gonna tell me that you need the smell of rotten apples in order to code (q.v. the philosopher Schiller, who claimed that he needed the smell of moldy apples in order to write.)

    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.
  • A decent marker should know just how difficult it is to get first-try coding working. I've marked some smaller exams with code snippets, and never required someone to be 100% perfect - any question with code on paper shouldn't NEED perfection like a compiler, but should be asked so you can demonstrate a theme or ability of yours. That being said, some markers/exam writers want more than you can give in that situation - it's a way of working out your skills that's too easy to misuse.

    a grrl & her server [danamania.com]
  • 20% of my grade in my CS class came from 4 programming assignments. I think the best approach would be to have 4 assignments that count 20% of the grade each and small labs that count another 20%. Let's face it, if you can do well on the assignments, you should be doing well.
  • Back in my day.... (Score:2, Interesting)

    by newerbob (577746)
    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.

  • 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.
  • 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
  • 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 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.
  • 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.
  • 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.
  • Written Exams (Score:2, Interesting)

    by edthemonkey (136946)
    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.
  • by Preposterous Coward (211739) on Friday June 14, 2002 @07:11PM (#3705070)
    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! (Score:2, Interesting)

    by SoupaFly (558227)
    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.
  • by IvyMike (178408) on Friday June 14, 2002 @07:12PM (#3705073)

    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.

  • 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.
  • by MattC413 (248620) <MattC413@hoLIONtmail.com minus cat> on Friday June 14, 2002 @07:28PM (#3705166)
    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
  • 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??
  • Definitely not fair! (Score:3, Interesting)

    by BlindSpot (512363) on Friday June 14, 2002 @07:33PM (#3705197)
    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.
  • by Lictor (535015) on Friday June 14, 2002 @07:42PM (#3705231)
    ... 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.
    • by VP (32928) on Friday June 14, 2002 @10:05PM (#3705847)
      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.
  • by Pinball Wizard (161942) on Friday June 14, 2002 @08:22PM (#3705443) Homepage Journal
    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.

  • by acidblood (247709) <decioNO@SPAMdecpp.net> on Friday June 14, 2002 @08:54PM (#3705575) Homepage
    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.
  • by mmmmbeer (107215) on Friday June 14, 2002 @09:34PM (#3705734)
    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.
  • by jellomizer (103300) on Friday June 14, 2002 @10:13PM (#3705888)
    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.
  • by eples (239989) on Friday June 14, 2002 @10:30PM (#3705999)

    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.

I've never been canoeing before, but I imagine there must be just a few simple heuristics you have to remember... Yes, don't fall out, and don't hit rocks.

Working...