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?
do what i did.. drop out of college.. become a "go getter" get a good job like me ($300000+ w/ a ton of benefits) and be happy :-)
college is overrated.. you'll realize sooner or later
yes
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.
Life is like pants... fit in or you don't fit in.
..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.
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.
It really depends on how it's graded. I had some Prof's that would grade based more on the understanding of the problem. They would look at the code as more of a structured psuedo-code, rather than something they thought would compile.
I've also had profs that would take a point off for each syntax error...
I 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!
/ Peter Schuller
--
peter.schuller@infidyne.com
http://www.scode.org
I once had a job interview where they asked me to write a C program on paper. They gave us an hour, and it took me 57 minutes. Writing code makes sense as a homework assignment. I feel that multiple choice questions are best for computer science examinations. There is no point in trying to write a program under that kind of time pressure.
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.
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...
.. 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.
"Avast! Prepare for the rodgering!" THWACK! "Arrr.. me nards.."
Half the time I forget a semicolon or somrthing, but on the computer...it doesn't matter because it tells you. Every single decent compiler will tell you when you mess up...paper doesn't.
There is no fair way to test someone's knowledge. Some are better at written tests, so are better at "projects", etc.
Written tests do test certain kinds of knowledge while projects test another type of knowledge.
Your professor should be using both to judge your abilities (and hence your grade - which is another false metric, but better than nothing).
And... in life, you *do* have to do thing you don't like / aren't good at, so I'm afraid, you are going to have to get used to it.
That said, don't drop out - the formal education is invaluable. It will be the only time you get to cover a significant part of a subject. The learn-as-you-go model, while getting you a salary sooner, doesn't round you out enough. Don't forget the humanities and economics courses as well (I can't believe I just typed that!) - I did and have paid the price.
Writing code on paper is definitely not the same as using the old keyboard. Its kind of rediculous that they would make you code on paper, actually.
I try not to worry about it too much personally and just get the basic structure and as much of the syntax as I possibly can right.
It's a stupid way to test if you ask me. I find the same strategy even more annoying in the job interview format. You're asked a bunch of nitpicky technical questions while sitting around a table with a bunch of people staring at you, and no computer in sight. With a system at your fingertips you'd be able to find the answer or solve the problem in minutes, while at the same time demonstrating your methods.
I've noticed this interviewing technique has become more prevalent since the downturn. The idea seems to be to make you feel stupid so they can offer you less money.
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.
--"Karma is justice without the satisfaction"
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 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?
RateVegas.com - Vegas Reviews
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.
Tarsnap: Online backups for the truly paranoid
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
Get used to it. When you get in the real world, you oftentimes have to take a written test during an interview.
If you can't think on the fly, you'd better start practicing.
+1 Insightful, -1 Troll. What can I say, I'm an Insightful Troll.
... 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 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
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.
...but I agree it's moronic. I took an accounting class many moons ago, and the exams went something like this:
"OK. You have to balance this company's books in the next 3 hours, but you aren't permitted to use any reference material whatsoever. And you're limited to a non-graphing calculator, a pencil, and an eraser. Go!"
For the computer graphics course I took, I got an A in the practicum portion and a C+ in the classroom portion (separate classes with separate grades). So, I demonstrated that I could apply all of the techniques I learned, as well as come up with a few of my own, but since I couldn't remember some formulae I did less than spectacularly on a written exam.
Whatever happened to preparing people for the REAL world???
-----------------------
To understand recursion, one must first understand recursion.
You know whats worst with written exams? There's no cut n paste, auto indent, backspace, undo button, color changes for variables and stuff. All you have is a loosy pen and an eraser... and I bet anyone that knows how to code actualy types faster on a keyboard than they can write with a pen.
:}
Maybe once electronic paper is out and used in schools, the situation will be a bit better.
I also disagree with large sections of 'write the code' on exams too. The profs. should incorporate more creative questions that you have to think about and possibly write pseudo-code to solve. After all they always say, "don't worry so much about syntax."
And often when I'm gonna write an app at home, I'll just use the ol' pen and pad to get the concept and write some pseudo-code with a few method headers but don't usually write out much code. But maybe I rely on the compiler too much for syntax?
having students write out code on paper is assinine. I used to lose all kinds of points for forgetting semi colons. Granted, its a stupid mistake and its my fault, but one trip through the compiler and all is well. Is that mistake really worth losing 2 points? I still forget semicolons all the time. Why wrack my brain over it when the compiler will babysit me? Its kind of like spell check. Who really cares what the correct spelling of necessity is? Close enough will do.
I think all CS tests involving algorithms should be in pseudo-code. If you want to test a students knowledge of syntax, make them write a program. If you really have to do it on paper, teach them BNF first and then test them on it.
Before you all start calling me a sloppy programmer, remember i'm just talking about semi colons, here.
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&
All but God can prove this sentence true.
... is my whiteboard. I needed a whiteboard at my exams; bastards wouldn't let me bring it
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.
A Government Is a Body of People, Usually Notably Ungoverned
...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.
I got my Linux laptop at System76.
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
writing software on paper is like doing sex by hand. What's the point?
Seriously, how is the teacher supposed to evaluate it if it's not run? I think software students shouldn't be tested by traditional exams, but by doing software projects, in the course of a few weeks. That's how they will work in their professional life, anyhow.
yeah, it sux to right on paper compared to actual coding, but i think that it is good to be able to work completely one paper becuase that way you don't use the compiler as a crutch...after all, if you get a little sloppy with your code, the complier will show ya the syntax error, but you shouldn't RELY on it... avoid code entropy!
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.
Fight Spammers!
It ought to be a fundamental theorem of programming that the program isn't done until it's tested.
This includes all subsets of the program. File, class, function, line, expression, term, token, character, syntax, etc., etc.
Your version of this process, like mine, includes getting the tested code to assist our understanding.
--Blair
I agree IDEALLY we would assess our abilities in the manner most fitting for each individual but we are currently struggling just to pump out people with degrees regardless of whether they can read write or dance. How many times have you heard on /. you need to have more than just a degree to be a programming god, you don't learn what you need in school just how to learn. Well that is because they don't have the resources to teach you the most effective way. Good luck getting a school to dump resources into tailoring education for you.
***I GOT NUTHIN***
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.
"I have opinions of my own, strong opinions, but I don't always agree with them." -- George H. W. Bush
Why should some TA be able to decide my value as a student? "We hold these truths to be self evident, that all men are created equal"
Grades divide us.
As a nation, as a planet, as a people, we need to embrace each other. Perhaps even nuzzle each other playfully.
Writers imply. Readers infer.
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.
.
It's hard to believe that's how Micronians are made. Why don't we see it right now by having you both kiss one another?
Personally it seems to me that psuedo code on exams is easier than writing code in on a computer. They aren't looking at syntax, they are looking at your logic, and any decent programmer should be able to express the ideas on paper. Now would my exams have compiled probably not, cause I would have missed semicolons or mismatched parens, but that isn't the point of a paper test. They don't want you to waste your time getting it to compile and debugging it, they are concerned with your logic and your high level design abilities. They will find out if you can make your code work on the labs and the homework.
That said, when I interview people I give them a problem. The point is to see how the person reacts under pressure, and to see the thought they put into the design while I am sitting there watching them. Does the code have to compile and work, no I am more concerned with orginization and problem solving. So that is my thought, they are testing something other than what you think. Then again some people just aren't good test taker's either, but that is too bad for them, cause most cs classes I took were weighted towards the exams and not much on the lab/homework.
Christmas in some time also? Mr. mmmmmm you know the slashdot name stuff(?) :):) I can be the slasldot person?
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
James Tiberius Kirk: "Spock, the women on your planet are logical. No other planet in the galaxy can make that claim."
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..
Never trust an atom. They make up everything.
Where I demonstrate system I/O on the professor using his cock and my mouth
This'll *really* be an accurate measurement of your ability. Education. Geesh.
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
- -
Are you an SF Fan? Are you a Tru-Fan?
It seems to me that the real benefit of sitting at a computer is to use the compiler. Otherwise, I use to write all my code by hand before getting on the computer. I probably think better writing by hand than on the computer. To each his own I guess, but I don't find questions wrt coding on exams unfair or difficult. (Except for inserting lines when you make mistakes) :-)
Guess what? I got a fever! And the only prescription.. is more cowbell!
That said, if the other students have the same conditions as you, you'll have to suck it up and deal with it. That's life.
SIG:Slashdot: indymedia for nerds.
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.
Having TAed several courses now in Computer Science, (I'm a PhD student) I have truly come to believe that having students write large amounts of code is just a bad idea.
Not only is it a pain to grade, it puts too much stress on the student.
Code snippets are fine. Make the student show that they understand one isolated concept at a time. Also, having students analyze a given piece of code, I feel, is also very useful.
Anyway, just my thoughts...
The idea of not being able to colaborate and share data is outdated today.
In todays world you actually are able to sit down with a reference manual and the internet and work out a program.
I have yet to see ANY computer science program do openbook opennet exams where people can work in groups go on irc and ask questions etc.
Like theres something wrong with asking questions while working. Like they need to know every part of the spec off the top of their head.
Computer science in schools is flawed because schools try their best to discourage sharing of knowledge and ideas.
Teacher -> student. *good* student->student *bad*...
least thats what i got from school till i dropped out and got a ecomm job in nyc making a ton of money learning on my own and asking friends for help when needed.
school is for saps. go get some experience.
I thought everyone had compile and run function built into their #2 pencils. Oh well. Make sure not to miss any more semicolons on the next test or its curtains for you.
I hate to say it, but you're not cut out for Computer Science if you require a compiler to tell you what is wrong with your code so you can tinker with it until it works. I never had any problems coding on paper in college.
Here's a list of substantive differences between writing a program on paper versus a computer. If I left out anything, let me know.
1. compiler
- see above comment
2. keyboard
- maybe you simply can't write as fast as you type. Are you running out of time on these tests? If so, start writing your english papers in pen.
3. syntax highlighting?
- I've never bothered with it. If this is your crutch maybe you should write a compiler. That will burn in your mind the syntax of a given language.
Try switching to Cognitive Science.
Joseph Elwell.
I have ideas for the slashdot. I can post withthe name also?
I have this problem too. Basically, I write down in steps what sections of the program I'm going to need, functions etc. Then I just make the functions or what not based on my notes. It helps a lot when you don't have to switch from planning to coding mode on and off.
we do the essay/multiple choice part on paper, then we have lab tests that solve this problem. But seriously, there shouldn't be that much difference between writing something on paper and writing it on a computer. You shouldn't be surprised when something doesn't compile, because you should check your syntax. Also, if your algorithm has a major flaw, you should have thought of it or seen it BEFORE you started writing code - that's just good practice.
$45 per U Colocation Special
Hi, you are damn right. Asking someone to write, even if it as small as 200 lines of code, is unfair on the part of the professor. Thats no way to test someones coding skills in a comp sci class. Professors should rely on giving projects to test coding skills. It should form a major part of the grade, say 50 to 75 %. The test questions that check the design and structure should be framed by giving out the code and asking to check the correctness, th way it works, is it a good way, is there a better way, point out the mistakes and rewrite to make it work, these kind of questions do a better job.
Here at UMR, the professor did just what I said when I took the course in summer 2001. We simulated a game called Dungeons and Dragons.
Thanks !
Regards,
Ronin
This question has been raised many, many times before, and is still under debate, in almost all areas of education. there is even debates about this applying to silicon chips (device testing -- if the test really reflect the abilities of the device) -- any test engineers reading this should get nostalgic, i reckon. ;)
the short answer is: well, it might not be perfect, but it's the best we've got considering the amount of resources, etc etc...
(pretty much the "this is why we have standarized tests" argument).
On the other hand -- there is a longer answer. Most of my "code tests" really only have to do with puedo-coding / algorithmical stuff. i.e. there is a few points that the instructor / TA checks for: does this guy know how a stack works, did his/her implementation leave serious memory leaks, etc. these, i think, can be figured out on paper if you are careful and draws flowcharts, etc. my teachers generally do not take off chuncks for grammar (unlike english -- which is ironic because compilers are so much less forgiving about grammar errors in code than people are regarding errors in speech). So, i do believe the paper coding testes show certain merits.
At the mean time, there are definitely times when the method fail: in front of a computer you can re-compile / debug until it (mostly) works; paper test you don't have that luxury; my personal feeling is that if you depend on the [compile] button to catch all the errors, then you are not all that great a programmer anyway. but if you have gotten clear enough logic, paper coding should not be a problem (just my opinion, again)
and besides: that's why you have both a final and a project; of course, so you can maybe even grab some extra credit with extra-features on your project.
i would, actually, like to see finals as:
here is a problem, you have 4 hours in a room with whatever you like to bring into it (i.e. coffee, jolt, cheese-nips, etc. except friends), and it better be working at the end; that would really bring out the best from the worst: actually, most programming competitions used to be put this way...
My life in the land of the rising sun.
When I was in high-school, I had an AP Computer Science teacher who would actually make us go in front of the class and write our code on the blackboard. He would point out every error in gruelling detail, and would constantly belittle us for even the simplest mistake. He was especially hard on me, though. Every time I was called to go in front of the class I was treated to a never ending barrage of insults or patronizing remarks. I felt more like I was in some special education course than an AP class. Eventually it came to a head when I was asked to write a balanced tree class in C++ on the board. I was so nervous I just couldn't think. I stood there for a minute, thinking out the problem, and before I could write anything on the board, I heard him sigh and say "thank you, mister typedef, that will be all." That is when I put the dead hooker in the trunk of his car. I had her laying under my bed wrapped in plastic for about a week, and had been saving her for a special occasion. I jimmied his trunk and dumped the corpse in, and then cut his break-lines so that the slightest bump would cause them to break. That afternoon, as he was leaving school, he crashed into another car at the intersection outside our school, and the dead hooker went flying out his trunk. The last I heard, he was doing 40-life in the local pound-me-in the ass prison. So that, my friend, is how I came over my coding funk. Hope this helps!
i never claimed to be "First Post", only "frist proust".
... and that is something you can never take away from me, you goathumper.
Yes! Im love the jesus to. Im like the gay jesus. Im happy also.
Do I can be the slashdot peole(PS)? please tell me.?:):)
When you're on the job, you WILL have those kinds of time pressures. One of the things the interviewer wants to know is how well you can cope with it.
It's Friday at 5:00 and you're leaving on a weekend trip at 7:00. The software is handed off to SQA on monday. There's one more bug in the queue and it belongs to you. Question: A) Do you bail on your trip? B) Do you sneak out the back door? C) Do you go fix that bug in 57 minutes?
A Government Is a Body of People, Usually Notably Ungoverned
jesus built his hotrod
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.
--
Ask the Ya-Hoot Oracle Anything!
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.
Mmmm.. Donuts
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
Please correct me if I got my facts wrong.
I have never had any problems with this. I think if you really know your stuff, you should be able to think about the problem and then write down a valid program just as you would on a computer. If you have problems visualisng a program before you sit down to write it, then you probably could be more efficient in your programming by doing so. I know it's easy to sit at a terminal, hack out a few lines, and compile it to see if it works... but such trial and error tactics are a lazy practice that will result in sloppy code and/or design that you have to touch up later. I am all for these kinds of tests, frankly, because they make you think before you code. Not just *while* you are doing it, and then again after the fact.
I know more than you drink.
As a product of a CS 0 (as defined by IEEE & ACM) curricula, I have seen that a coding emphasis is misleading. In software development, more emphasis should be placed on design and documentation. It would be better for CS tests to be written to have the takers write out the pseudo-code and documenation (relying heavily on UML). That is unless it is for a class focusing on a specific aspect of a language ie, write a code snippet that simulates a queue, linked list, etc. But where you are given a black-box type problem, I feel it is more important that you are able to communicate the method and your thought process than trying not to forget your semi-colons. You can always refer back to a How-To or an Orielly book, but you can't rely on them for the thought process.
A forgotten curly bracket or semicolon won't affect your grade if you're going to any decent college... Where I am in CS anyways we're asked to write specific language code only on few introductory courses, some not even credited.
The real courses talk about algorithms and general ideas hence you can write down your algorithms in pseudocode, english, or any way you feel that the TA is gonna get your idea.
For myself, and I'm sure I'm not the only one, I'm happy when we get a question about programming syntax or such in an exam because usually those are the easiest questions so I don't really understand why you're complaining...
For example, let say you are asked to write a Dynamic Programming algorithm to multiply matrices in O(n^2) and your algorithm is correct but won't compile, and you loose some marks, then the college you're going to does not deserve you're money anymore!
Now my CS major is almost finished and I never saw an exam where I had to write more than say 100 lines of code. The 500 lines your talking about are for a single exam question or the whole exam?? Would be more reasonable to make programming assignments or projects because thats why they're there for.
delete free(system.gc);
I was hammered writting coding exams while at school. I don't think I ever recieved lower then 80% on a coding assignment. I probably averaged 90-95% on assignments and on group projects I was always near the top of the class. However I'd write the two midterms, and then the final and I'd barely pass the course. I found the only way to get through the courses was to do amazing on the assignments and then get what I could on the tests. In 4th year most of the courses had projects and not exams. I did great there, my best year GPA wise was the last year that should have been the hardest. I never did figure out a way to do better on the tests.
I completely agree. It is idiotic to ask someone to write code completely right the first time on paper. I took the AB CompSci exam, and though I pulled a 4, I was annoyed that they had asked me to write out this complicated piece of code on paper. When you code, you dont sit down to some paper and start writing code. No, you sit down to a computer (after skeching out some ideas)and start writing code. Then you compile, see if it works, and if it doesnt, you go back and try and fix the problem and compile again. On paper, you cant do that.
Ten years from now nobody will care what your exam grade was.
i walked into an interview where i was going to be doing server side scripting (perl/asp/PHP/etc) for this company's intranet in their home town.
they sat me down and asked me to code in fucking javascript. on paper. with a pencil. i don't fucking do javascript to begin with (outside of retarded things like mouseovers, etc.) i know what its like to not be able to code on paper, i've never been able to. i can't really explain it. i just froze up.
i didn't get that job
i'm such a tard
-c
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.
One of the first things I learned with C++ was code a little, debug. Rinse, repeat. That's good practice...and requiring someone to write more than one or two lines of code on paper in an exam seems stupid. It teaches exactly the wrong skillset: it's not how many lines of buggy code you can write on paper in 3 hours that's important - it's your ability to write good code and have good debugging skills.
I can understand the need to write a few lines to illustrate an algorythm, but anything more is just silly.
-EvilMagnus
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.
"You spoony bard!" -Tellah
Why shouldn't a programmer be able to write short programs down on paper? If you absolutely need a compiler/debugger just to get an algorithm/program to work then maybe you are approaching programming the wrong way. I thought the whole point of written coding tests was to take the computer away to see if you understand the concepts on your own; to remove your ability for mindless trial and error and test your actual knowledge and thinking ability. I never had a problem with written coding assignments, but maybe thats why I see things this way.
Yes, but those that can hand write code are those that truelly know it well.
The rest are just hacks.
I can really relate - I'm a senior now in computer science and math, and I've had plenty of nasty problems thrown at me on exams (writing an implementation of malloc, multi-threaded priority-based message passing system, crap like that). Here's just some things I've found that work for me.
1) Make sure you do all projects to their fullest extent, and after doing them, make sure you think about all the things you could do to your solutions to improve them past what the prof asked for. Then study your solutions before the exam. I've found that profs are likely to ask programming questions that are extensions of what was asked on the projects and homework... so this has saved my butt a couple of times.
2) If your school has coding contests, get involved. Even if you lose every time. It's important to learn how to write complex code in a short amount of time for these exams - and coding contests have helped me out a *lot*. Probably 'cause in a coding contest you often have to get the code right the first time (which is what is needed for paper exams) in a short amount of time.
3) Don't be afraid to ask questions during the exam (if this is possible). Last semester I was in the top-ten for exam scores in my CS class. I was also the one asking the most questions. =) Not that I was able to get the solutions out of the prof, but I was able to narrow my parameters. I was able to find out how much error checking he wanted. And I was able to get a lot of ambiguity eliminated.
4) Just be a smart test-taker. =) I know, I know, that's way too general, but what I mean is: don't get pissed at the hard problems until you've done the easy ones, write *some* code down even if you have no f***ing clue, and get plenty of sleep, food, whatever beforehand, enter the test relaxed, and just hope for the best.
Just my $.02
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.
We had these damned fill-in-the-blank questions regarding Master-File updates at my old university (of which I am no longer a part of). Now, they would give you about 20 lines of code, with holes here and there. I cannot think like these crusty old bastards, so the code I did write was totally wrong. In fact, my teacher took 63% of my first lab score away because I didn't comment the print lines. So I wrote, "where's the comments?" There went my 'D'... I do these things totally differently and paid the price for it. I guess they want to train GI (general issue) programmers...
The only sensible approach is to use $LANGUAGEOFCLASS as a design language and write, as the parent said, pseudocode.
Unless your professor is a compiler, it's not feasible to grade for syntax and correctness, not in most languages.
On the other hand, maybe it's a useful challenge to be asked to write code that is clean from the get-go. There's a development methodology called "cleanroom" (*) in which the first compile is done by QA. The theory is that if you paid enough attention to get the syntax perfect then you probably paid enough attention to avoid a lot of bugs.
(*) not related to the technique of reverse-engineering using two isolated teams.
Frame of mind is very important in order to code effectively. He isn't discounting the first two issues in establishing a frame of mind conducive to coding; he's giving an example on how to establish such a frame of mind when such tools aren't available.
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.
"Despite decades of social change, the general perception remains that technical workers, scientists, and engineers are unusually intelligent white men who are socially inept, absent-minded nerds."
That makes all kinds of sense for a job interview situation. There, they want to know not just what you know, but how well you perform under pressure, and how fast you can perform.
The guy who knows the syntax and the APIs off the top of his head is, ultimately, going to produce faster than the guy who relies on multiple passes through the compiler to correct his syntax and using 'man' or equivalent to look up the API of every function -- just as the person who can add/subtract numbers in their head can check their change faster than someone who has to count on their fingers.
Somebody looking to actually pay money to somebody to write code for them (ie, to hire a programmer) is going to prefer the former rather than the latter, so why not give them such a test? (And it will instantly screen out the bozos who've lied on their resume and maybe just memorized enough to pass simple interview questions.)
-- Alastair
These tests are geared towards wannabee programmers who regurjatate code from a book or manual. In some cases the tests are amazing to write but there's a marked difference in the environment where you code and the environment where you write an exam.
No matter what anybody says, you can modify or adjust to a business environment over time. No such preparation can be done for the exams.
internet like monkeys'
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
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.
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.
"Biped! Good cranial development. Evidently considerable human ancestry."
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.
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.
thank God the internet isn't a human right.
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.
Asking someone to code on paper is just as ignorant as spending hours looking for typos rather than letting a compiler catch them. The problem is that a cutting edge skill is being taught in an age old fashion.
When you're on the job, you WILL have those kinds of time pressures. One of the things the interviewer wants to know is how well you can cope with it.
And this kind of "pressure" is exactly why Microsoft puts out such sh!tty products. Its quanity over quality.
Bring a PDA, a Typewriter, and a pack of mountain dew (or beer, if thats your style). Problem solved!
That or drop out, whatever's clever.
I've learned to program a computer without a computer, so I'm used to writing code on paper. However, I run into the problem of misspellings or sloppy on tests, for which I lose points. This is where it isn't very realistic, because in the Real World, a compiler or ocular debugging will often spot this problems.
It's also silly in a general sense, in that in the Real World, you usually do have reference manuals and F1 to help you out. Of course, this ends up leading to the monotonous cheating debates.
Mi klopodas varbi por Esperanto.
many of you sound like you've never had to sit an exam in a foreign language (with several pages of written composition) or do a maths exam where you had to show all your working.
the point is to show that you understand structure, sequencing, and that you TRULY understand how things work without debuggers.
FWIW, when i was in school, we had to do everything on paper before we could even go near the computer.
Over the last 2 years my University's CS department has been rapidly dumbing itself down. Letting in unqualified students, making it easy to pass intro courses that used to be difficult, teaching to the lowest common denominator. Part of this process has been a switch from the written tests and quizzes to testing on computers with compilers. Go figure.
I do think that this is only appropriate for intro courses where students need to rapidly develop a grasp of a programming language and concepts so they can move on to the good stuff. Beyond the intro level they should really be teaching higher level concepts, stuff that is programming-language independent and impractical to code on an exam. If you are asked a question about an algorithm, you should be able to use pseudocode (I have never run into problems using very-pseudocode in upper-division CS courses, as long as I knew what I was doing). A good exam should ask you to think and apply the material and a decent instructor will recognize if you've done this. Seriously, if you are a CS student you should be able to write an algorithm on paper, but it is kind of a skill in itself... Writing C++ on my intro final was not so bad because we had written weekly quizzes and were used to doing it, but if a professor asked for a large hand-written program out of nowhere, I imagine losing the safety net of a compiler would freak some people out. It made plenty of my classmates fail :)
Well not quite,
The interview went somthing like this,
Do you now what function of larlar does ralral.,
[quick scratch of the head, brain in top gear]
Sorry I can't remember at the moment, I'm sure I'd find the answer in the help file under sys.io though.
thank God the internet isn't a human right.
call me old fashioned but, what about pseudocode?
damn it, the word is spelled "RIDICULOUS."
RIDICULOUS.
No wonder you can't code on paper. You're a complete moron.
I went to UCSB, and I don't remember ever having to write code for exams. I wrote a damn lot of pseudo code, mind you, but that's how you get ideas across, eh ? I mean, how else to show that you understand an algorithm than by using it ?
don't be such a sissy.
-- Spankmeister General
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.
In nearly every programming class I've had, I've been required to handwrite code.. and it never is as good of code as I could write if I was in front of a computer. I don't believe that it's a fair way to judge someones skill in a language.
Code on paper is a great way to test that you can design before you code. You can no longer just hammer in code bit by bit and hope it stick. It's really not about the coding they are testing, even if you got the api wrong (spelling, or something minor) they not going to penalize you for it. One of my subject even allow us to bring an api reference into the exam.
What they really testing is the ability for you to:
1. Know what the problem is
2. Design a solution to the problem
3. Break down the design and put it into code
Through design it allow us to make better codes that actually solves the problem and period. Its ridiculous how many assignment (where people hammer in code before design) got so many bells and whistles (ascii animation for an atm program? anyone) that the main focus of the assignment is lost.
avoid scheduling yourself into such tome constrants. There's no reason to schedule a departure that close to quitting time... besides can't you just remote in that bugfix?
My high school doesn't have AP Computer Science (or any computer science at all).
You just don't know how good you have it, you little whippersnappers! Back in my day, we had to write all of our code by hand. There was no such thing as "open source" or "compilers." There weren't even any computers! But we wrote our code all day long without a single complaint. No wimpy caffienated drinks or bathroom breaks for us! No sir! You don't know just how good you have it.
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.
well, i am fine without debugger or ability to
run code in intermediate stages. But what i am
not fine with, is unabilito to *edit* on paper.
when i write 'if' calause, i do first write `if {}' and then insert code inside, which is obviously impossible on paper.
other point is that programmer largely depends on editor, i doubt i'll be able to write any fucntional code in emacs, while vi is my best friend.
You can't write good code if you can't think it through.
How do you expect to write a clean (bug free) algorithm if you can't think beyond the loop you are currently writing.
Go get a job at M$ they need your big picture expertise and ability to think things through.
Most profs I had didn't care if you forgot a few semicolons and if you pay attention in class you largely regurgitate the structure.
Hint write in the left side of the page and if you forget something crucial, put it on the right half and tell em where to stick it!
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??
"with their freedom lost all virtue lose" - Milton
Because of crap like that.
:P)
Oh, I don't mind the odd problem here or there, but when they ask you to write, as in with a pencil, on paper, in a room without any computers, a fully functional working program, erm.. No.
(And no, damnit, it wasn't a 'Hello World' program.
I find it is not that hard, I mean, when I write a program I first make a design (or at least take some notes) on paper. Once you have divided the problem, writing down some implementation (pseudo) code is much easyer.
Those notes will also tell the examinator that you understood the problem, making it easyer for him/her to forgive eg. a pointer error, and to understand the code.
"It's too bad that stupidity isn't painful." - Anton LaVey
I took the Advanced Placement Computer Science AB test last year and received a 5. Yes, hand-written code can be tedious and strenuous, but usually most exams note this and score according to the attempt. It was a painful task, but it also helped me in my psuedo coding quite a bit. Still, I wouldn't be suprised if I saw the exam move to an actual computer in the next few years.
mund freud.
The only course where I've had to write any code on paper is in the introductory programming course at uni. This course used the book SICP, so the course obviously tought scheme. In the exam we had to write loads of extensions on paper to the "amb"-evaluator and the logic evaluator (those who have read SICP know what I'm talking about). We also had to implement a few really absurd streams and that was really a pain when you couldn't test the on a computer.
I've been coding myself since I was 11 (well I couldn't say I was coding back then, more like "coding"...) and I'm 20, so I've got some experience in coding. I've noticed that the problem with writing code on paper is that if you've never implemented anything similar to what you need to do in the exam on paper, it's going to be pretty quite hard.
For me the only solution to check my code I've written is really to write a large stack on paper for the stack and write all the variable names on paper. Then start evaluating the stuff in your head and just begin to write down all the values on paper and fill up the stack. It's pretty damn annoying to do this, but it's even more annoying for the people with little experience. Thus no matter how you look at it, if you're an experienced coder, it's you should do better than the rest.
There's one thing where coding experience doesn't help though. Many courses in algorithmics and programming methods generally test for the ability to design algorithms which is more math than programming. In these situations it helps more to be talented in maths than to have experience in programming and some people with practically no programming experience are going to do very well in these types of questions. If you want to succeed in these types of problems I suggest you look at the IOI or ACM Programming Contest archives. There you'll find lots of nice little problems to solve at your spare time.
college? overrated? yeah...only if you're a geek who codes in a vi screen in his pitch-black dorm room all day...
I would suggest that the job "interview" gather information that's pertinent to the job being posted. Gathering performance data (like being able to code without reference material, a compiler, and an editor) that has nothing to do with the job is going to give you information of questionable usefulness.
What, you can't write code without a syntax-checking editor, or frequent breaks to see what the compiler makes of your half-thought-out muddle? Well, then you don't deserve a good grade, sonny. Come back when you've learned how to code, not just to hack up a storm.
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.
I've never thought written tests were a fair way to measure someone's knowledge of coding
And what other standard of performance judgment would you advocate? I've seen the Slash source code; you're better off with the test.
I disagree with that statement. (And I suffered through RIT too ;))
:)
:P)
Syntax is perhaps the first thing a person should be taught. It doesn't matter that it doesn't transfer from language to language (for the most part). People need to be slapped upside the head until they comprehend the fact that syntax is incredibly important. Ever track down a missing semicolon in a ten thousand line program at 4 am?
Granted, it shouldn't take very long for people to grasp this idea that syntax == important. That's when you move onto theory, algos, the meat that transfers and is applicable damned near anywhere.
(Ahh. How I miss getting massive amounts of points taken off of labs because I incremented a variable by i++; instead of i += 1;
I had an engineering professor that would 1 point off for every mistake on a dynamics problem. I thought this was ridiculous, since if you make 1 mistake like this 'in real life' the whole thing blows up.
How is this different?
I agree. Coding on paper really sux. I tend to write a 'header file' type structure (interface for the java people) so I know what I'm doing. After that it's just filling in the blanks. The bad part is I still mess-up.
Before I learned to do that I used to go to the profs office; I'd beg and plead with him for a bit, (I suck on tests, my home work is the best, you've seen me tutoring others in the library, etc.) then discuss programming technicalities with him for a little while. That worked also.
I don't know about everyone else, but the way I code is I write a chunk, compile, and run to see how it looks, then write another chunk..etc..
Comp Science AP exams really blow. They make you sit there for 3 hours, writing by hand, and trying to sift through these useless functions they come up with. PLUS they make you use their proprietary classes instead of standard ones. I think College Board is spread a bit too thin, perhaps standardized testing shouldn't be administered by a company out for a profit.
-------
"In times of universal deceit, telling the truth becomes a revolutionary act."
-- George Orwell
Computer Science sucks. I hear Philosophy is pretty good...
my CS teacher gives exams/tests with 20-60 line blocks of code with missing lines, tells you the input and output, then you gotta figure out the missing line... it sucks
There's a reason the tests are on paper.
Somewhere in Michael Abrash's awesome Black Book of Graphics Programming, he mentions that his grandfather (IIRC) used to do the cross-word puzzle in every sunday's newspaper... in INK. And he never messed up or had so much as a smudge on the paper. The reason is that before he wrote anything down, he thought about it from every angle, and only wrote when he was sure his answer was right.
I try to do the same when I code. Overall, things are drawn out in flow charts, state machine diagrams and whatnot, but when I write an individual routine, I sit back and think it through quite a bit before I write anything down. The point is that although I do move things around or write code to see it, I try to think as much as possible and type as little as possible. The results tend to be a lot shorter and work quite well, if I may say so myself.
And I'm one of those "visual learners" who needs to see stuff with my eyes. But my rule of thumb is that if I can't work a routine out in my head, it's too complicated and I need to take another approach.
As a side note, I am very strict on formatting. I format the code perfectly to my specifications as I write it. (1TBS, spacing between operators.) There's no such program as a pretty-formatter on my systems. Since I take such care, I hardly ever miss a semicolon or other punctuation mark.
Oh, and one other thing... When it comes to debuggers, definitely use them! Make sure you specify some really harsh test cases, and after you write a routine or a small system of routines, bust out the debugger and watch every line execute, and as you do, ask yourself, "What could possibly go wrong on this line?" You'll be shocked and amazed at how many flaws you'll find in what looks like innocent code. And use Lint. But when it comes to tests, if you can do it on paper, you know your shit.
I've been coding for years, but I run into the same type of problems. But it doesn't necessarily apply to just exams. Say you're away from a compiler (or in the case of PHP, etc, a web server that suits you)... You have some quick ideas for structure, jot them down in notepad, pico, vi, whatever may be handy. You finish up maybe 100-200 lines, and when you get to the compilation/execution stage, you realize that you made some silly layout or design decisions. You don't get the critical 5 minutes of fix time on an exam. Most colleges have enough rooms w/the goodies for whatever language you may be working in to give a timed 'practical' exam. This would offer the chance to do a quick compile, catch any goofs or uglies, and submit something reflective of your skill; yet I have seen a strong tendency toward paper for entire exams. It seems like the students need to make a push to showcase themselves and break these sticks outta the mud.
I'm approaching the final year of a CS course and I've had my fair share of handwritten programming exams. There's nothing that annoys me more than a question that asks for code on paper. Programming is simply not done on a line-by-line basis.
u essing-the-number-of-lines-for-your-code question.
Who here thinks "OK, here's the algorithm I have to write" and writes say 200 lines one by one? Nobody! You start with chunks and progressively fill out the code by inserting lines above and below, editing things as you go along. Functions are not essays!
The questions I've faced so far have been reasonable and haven't required too many lines of code. (You know, the usual tree walking stuff). We're so familiar with the algorithms, we've already got a good idea of how many lines we'll need. But in some cases, the majority of my time is spent trying to figure out the code before I write it. Otherwise I'll end up having to insert lines here and there, make corrections and eventually need to rewrite the whole thing so the examiner can actually read it. All of which is costing me time.
These conditions detract from a test of actual programming and are a stumbling block for many. I have friends who have run out of time rewriting their draft code scribbles into a neat, examiner-readable form.
Secondly, in "real life" programming situations, you have a debugger! Type some code and test as you go along, progressively reaching your goal. So why these exams (the coding part) aren't systematically conducted on computers is beyond me. Unless I'm presented with a screen and a keyboard, it's not a programming question. If it's on paper, it's a how-good-are-you-at-writing-quickly,-neatly-and-g
The subject matter is ever evolving and universities have been good in keeping up, but in my opinion, the standard examination techniques are just not effective for coding questions. But for some reason, my lecturers, who are supposedly skilled in this field, just don't see the problem. "... in my day... " Bah!
My life is one big siesta in which I'm dreaming I wished my life was one big siesta.
Exactly. That's what the introductory courses are for. However, I don't believe you should be overly penalized for syntax errors on exams laden with theory (unless of course it appears to be a consistant problem).
--
silence is poetry.
Is this a serious question?
... 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.
There is only one slight problem which i can see with this. It (as Always) spawns from money. There would need to be a substabntial inverstement by unis/colleges/etc. to prevent cheating in such an exam. for every secrity profesional you get who knows there stuff about locking a system down, you get a good few students who know just as much, if not more about busting them open. you have to look at the fact that computer based exams will be coded by someone, a real person, and therefore could be fallable. especially in a situation where coding is involved, as all the tools to properly use/abuse a system are inplace to allow programs to be compiled and executed. to have a limited system in this situation would be worse than having no system atall.
I just finished my first year of college, and I took my CS final two days ago. The test was pretty fair, I thought, and broke down about as follows:
/whatever/")
30% multiple choice ("What is a valid form of a call to this function?")
30% analysis ("Study this recursive implementation. Will it work as described? Why or why not?")
40% coding ("Write some code that
I feel that tests along these lines are the most fair. You aren't going to be shot down immediately if coding with pencil/paper isn't your strength, but it certainly helps. And I definitely agree with the posters that think coding by hand on paper is an excellent precursor to coding in the lab; the times I bothered to figure things out before I headed to the lab, I spent far less time on problems than when I sat down and started coding, fixing errors along the way.
I am always taken aback at how many people on slashdot think that computer science is nothing but coding. It isn't.
In fact, the vast majority of computer science courses I've taken (4 years undergrad, 3 graduate) have a lot of material that CAN be tested via written tests. In fact, just about anything you can take after the first 2 years is more theoretical than coding-heavy.
Just think about what is out there: Algorithms is mostly proofs of correctness, or high level pseudocode. Theory of Computation (FSMs/Turing Machines) doesn't need any programming. Artificial Intelligence can do a lot without code (problem of representation strategies, Q-learning, bayes nets, decision trees, neural nets...). Even stuff like computer graphics could use a paper exam: examining the filters used, theoretical ray-tracing speedups, lighting models. Computer Architecture, anyone? How about network design - Queuing strategies, security, robust multicast solutions? Inverse Kinematics for Robotics (ie, how to efficiently control a robotic arm)? This is just off the top of my head. If you've been through 4 years of college, you've probably seen what's out there, and know all this.
Coding is a tool. Sometimes you need it, sometimes you don't. But unless you know how to build a house using just a hammer, you shouldn't think that it is the ONLY component of computer science.
Absurd. Where's why: if you do your job correctly and work for a responsible company, you will build confidence doing your job. When something goes wrong, you will be working with people you know doing a job you know.
In an interview situation, there very well might be a few people standing around watching you that you've never met.
The situations are very, very different.
I know a guy that was put on the spot to write code with 10 potential co-workers standing over his shoulder.
The times that I've had 10 co-workers standing over my shoulder were never tense situations, but always relaxed, fun times.
I find that I need to be sitting in front of a computer...
of course it's easier to write code on a computer. you have the compiler/interpreter to immediately alert you to your mistakes.
still, i dont see the point in these exams where you have to write a program on paper. its infinately more important to understand the concepts rather than to memorize the syntax of a particular language. thus, i believe that pseudocode should be the official language for written exams that involve programming in (at least higher-level) computer science classes.
Gyrate Dot Org - "Where high-tech meets low-life"
...But that was in back in the days of Pascal. Pascal and Fortran were what your professors used in college, and were written down on a sheet of paper.
In the golden days, people used punch cards. People had to think about how they were going to write their code, writing it out as statements longhand, and then punching it into the cards. So it's not like it hasn't been done before.
I took the AP Programming test back in '91. It was pencil and paper, and I scored a 5 on it, but even I'll be the first to admit that pascal was much easier to code than C. There are some obvious reasons for this, procedures and functions were easy to write and to read. The way to use pointers were clear as day. Debugging a pascal program on paper is *so* much easier as well.
And that's part of the problem. Professors have thought that computer programs has always been pencil and paper testable. And it hasn't really been until the proliferation of C & C++ where writing code without a compiler gets hard. Pascal and fortran were easy compared to things like pointer arithmetic and function pointers in C.
But without some sort of test, most professors have no accurate way to gauge how well you have mastered the material that has been presented. Most profs know collaboration is going on, (sanctioned or not by the school), so homework is clearly not a good measure. If you're teaching a high-level computer science course, neither an essay test, nor a multiple choice test seems apropriate, especially when your students need to understand how some B(X)-tree node insertion/deletion/optimization works.
Sadly, booking a lab of computers for a class test creates resentment among those who need computing resources during the day, unless your school happens to have more than enough computers to go around. (This was an issue at our school)
So pencil and paper tests are waaaaay easier to create than a computer test.
Are Written Computer Science Exams a Fair Measure?
Yes.
Eve Fairbanks says I drive a hybrid!LOL
That is nothing new, but like many things that are often well known, it is not practiced much. Programming, depending on the class and/or specific section currently being taught, includes syntax, grammer, style, consistency, algorithm usage, adaption, cleanliness, efficiency and probably specific elements (where you MUST use them regardless of whether you know a better way). So I would find it difficult to say I evaluated someone's skill at programming, when I used written tests. (I would shoot myself if I ever used multiple choice only... or even more than 33%)
Some people suck at tests... period. Some are great test takers but have little adaptation and implementation ability. These are usually the BS artists and empty shells that have letters next to their name. (I have seen more idiots with degrees than intelligent and usefull degreed people... thus my recognition of degrees is very low, but NEVER counts against anyone)
the big problem that I have with coding in exams is the whole enviroment. When I code, I have 2 displays going, mp3's playing and a couple of ICQ chat windows open. For me, coding without these things makes me concentrate too much, and get hung up on little details that don't really affect my code...
For simple linear problems, no sweat, for object oriented systems a bit tougher. No matter how much I map out the problem in my head, or outline it in prose/pseudo-code, I get coders block occasionally when trying to write complex problems down in a linear manner on paper. I think across the problem boundaries and prefer an editing environment where I can bounce between modules / routines. I _really_ love the folding editing features where you can collapse statement blocks that you have complete (and you have to develop a comment style that comments the collapsed block).
:-). And currently I have a pet question I got from someone I interviewed and hired that is a practical problem in a hypothetical language that I ask people I am interviewing. The main thing is to see what approach to problem solving they have.
...
But those exams are just the start. Even with 25 years experience when you go into some corporations (MS for example) there are occasional times where they'll hit you up with a hypothetical, then ask you to sketch out the code on the white board. I did three coding examples over a 6 hour interview for a contract with the MSVSEE group. Part of that of course is to see how you handle stress. And maybe writers cramp
So, get yourself in a relaxed zone, leave space around what you write, and if you have time or the problem is complex, sketch out the proposed solution in outline form with one statement per chunk you can easily code without worry. And if it is OO, do a normal design cycle, slightly compressed. Patterns if applicable, with a breakdown of roles, then specific interfaces, then do the individual modules as above.
Step by step, inch by inch, slowly I coded
- Tjp
I am in wallow with my inner money grubbing capitalistic pig. ... Oink!
ECE 291 (Assembly programming) @UIUC - Final consisted of one hour long multiple choice test (if you could call it a test, it was pathetically easy). Two hours consisted of a supervised lab period, about 20-30 students at a time, with a few small problems and all the tools a programmer would have (old notes, design specs, google, assembler to test for bugs, everything except your old code and talking to each other was allowed)
I've found that people who didn't go to a decent college for computer science typically wind up as "Nick, your company's computer guy."
Always defensive, always hacking away at a terminal, never seeing the big picture on a project.
Anyone who wants to take a test with a compiler sitting in front of them is a hack. They should look for an MCSE examination instead of Advanced Placement in CS.
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...
this is a very good subject. one of the first iv actually read most of the comments on a topic
iv written code for many years now. mostly on and off, but not till my recent job at a bank have it written it on a consistent basis and have actually been proud of what iv created
i allways use paper to map out what i want to do first, example: database structure, work flow, iv even drawn out screen layouts and put pages of code behind it to give a better idea of what im trying to do
but i allways find myself going back into other code iv written and just coping and pasting if it works the same or is close to working the same as it did somewhere else
am i the only one? or is everyone, professional and amature memorizing code and writing from scratch everytime? to me thats a waste of time.
maybe this would fit better under a topic like "to source safe or not to source safe?"
as for the degree thing, i dont have one, and my code has proven my skills time and again, but to no avail, no new job interviews. i think alot of major corporations are looking for that piece of paper. teaching yourself just doesnt do it anymore now adays.
-Mario
If you can't write code on paper, then what you probably do on your machine would be considered hacking, not programming. Most people write utter crap, and then use the debugger and the compiler to refine their code into working form. In my opinion, people who can write code well, can also manipulate design ideas in their head without having to "test" everything. Such people could work the overall structure on paper, and express the algorithms in pseudo-code, and then do the trivial task of translating those algorithms into a particular language. I don't think code monkeys deserve the title of "software designer" most of the time.
There's insignificant cost to running the compiler twice as often
Unless, as several people commented in this story, management demands that you run antivirus software with the following policy: every time you run the compiler, you also run the virus scanner on the compiler binary, and the virus scanner takes twice as long as the compiler itself.
or looking something up in a manual or on the web.
Not if the CBDTPA passes, free software is declared illegal, and the operating system vendor makes its NDA'd developer manuals pay-per-read.
Will I retire or break 10K?
Utter crap. Saying "programming is very individual and specific to the programmer" is spewing TOTAL stupidity!
The problem and the object model created to define it will provide the solution. That's the ONLY way to code it.
The data structure falls out of the object model. The algorighm likewise falls out of the model after performing appropriate optimizations.
Write code so the machine will NEVER do ANYTHING it doesn't need to. Not a extra disk hit, not an extra byte fetched, not a uselessly continued loop, not an instruction executed twice. Code the algorithm to deal with sub-optimal structure for the process that needs to be executed.
Cache every execution result that you will need again. RAM is cheap. Time is not. Not even Bill Gates can buy the user another second.
But RAM is not so cheap that you need to waste money and time filling it unnecessarily. Only cache what you absolutely need again.
If you don't know what the fuck you're dealing with. Don't start writing the fucking code. It'll just be garbage. Worse, it'll be "almost" working and become a sump for development time.
I loathe moron who keep saying that software development is an individual's preference. That a total crock spewed by ignorant ass-holes.
Learn your job and write properly optimized algorithms or sell shoes for a living. I loathe debugging code written by dilletantes and "artistes."
MSBPodcast.com The opinions expressed here are my own. If you don't like 'em... Think up your own stuff.
I've never had an issue with coding on paper like that. Some people complain about debugging.. yeah, nobody writes code perfect on the first try. Writing it on paper forces the programmer to follow their code by hand to see what is REALLY happening to it. This is a great practice to get into, because when you are coding at the keyboard, you better understand what is going on. Is it fair to dock for spelling mistakes? I don't think so.. but is it fair to see if you have the logic there on paper? Certainly!
My first programs were written (yes, written) on paper and sent off to be put onto punched cards. You kids these days, you just don't know you're born.
Have you ever tried CRC Cards?
Do you skip UML Class Diagrams, Sequence Diagrams, State charts and Flowcharts (for procedural stuff), and dig straight into the code?
Do you have Java Interface classes with 40 functions?
Will your whiteboard at work never be more than a todo list or doodle pad?
Do you fix a bug only to create 5 more within the same monolithic function that should be refactored?
Syntax checking is the least of your worries if you can't think up a solid structure/design.
---- Smokin' another sig.
Enjoy.
I love written exams, they are very easy to grade.
Here is my grading scale:
20% Program compiles
20% Attempt to solve the problem
20% Program sort of works
20% Program Works Correctly
20% Style and other concerns
Each of the categories relies on the other, so if you program doesn't compile, you can't break 20%. This makes grading a snap, because I just look for missing semi-colongs, and give out all F's to teach the kids an important lesson.
If I weren't so tired of reading the bad answers and trying to be fair to students who really can't program, I would stick with coding on tests.
The basic gist of the question here is, "Is writing code on paper a fair way to test in a CS class?" To be frank, this question assumes so much that there's no good answer. Fair, test, CS, and class are so ambiguous that it will leave your head spinning if you try and pin down an objective answer. Let me run through some of the problems to illustrate:
/.ers' judgement. Effectively, you're asking, "If a measurement of coding skill obtained by writing-code-on-paper produces results that disagree with your own, does that imply a bias in the writing-code-on-paper process?" Well then, what is MY process for measuring coding skill, and is IT fair? Your presuming that there is some method that we can use to cross check the coding skill measurement. Sure, those of us in the field probably have a decent gut feeling, but have any of us measured our coworkes writing code on paper recently? Not likely...
1) You asked about a fair measurement. Measurement of what? You're taking the concept of a "test" as used for "measurement" in the context of a "class," where the nature, purpose, and significance of the measurement is effectively arbitrary--being arbitrated by those who administer the "tests." You said measurement of coding skill; however, this is not necessarily the attribute the testers intend to measure. Hypothesize for a moment, though, that all CS tests that ask you to write code on paper intend to measure your coding skill.
2) You said "fair." You then applied that word to a measurement. Generally, I would more likely use the term "accurate" when referring to a measurement. However, I think that you were referring more to the process of testing when you said "fair." What, then, is a fair process? We want to run a test, measure the results, and draw conclusions. (oversimplifying) As an emperical scientist here, we want the process not to introduce bias, or at most to introduce systemic and well understood bias. So I believe your questions translates to, "Does the writing-code-on-paper process bias the result (code) in a way that we cannot correct for before drawing conclusions regarding coding skill?" An "unfair" process would then yield incorrect conclusions even given accurate measurements and strong statistical correlation between measurements and conclusions.
3) There's the kicker, though. Given accurate measurements and strong statistical correlation between measurements and conclusions. How can you tell the difference between poor process and inaccurate measurement? Presumably, you have a way to independantly verify that the measuring device works, so let's presume that you have a computer program that performs OCR and assigns a point score (measurement) to the code (results), so that we may be certain that the same handwritten test paper always gets the same score. Now how do you tell if your process was good? Make sure that you can repeat your own tests. Then get independant verification. Now, you have to go back to your theory and explain how the results fit into your theory. Hopefully, your theory will suggest other tests that you can run that will confirm your earlier results.
4) Finally, we hit the fatal flaw in this question: we have to measure coding skill in some other way to see if the results agree with the writing-code-on-paper method. But the other method that you're appealing to here is
Anyway, you're presuming that all of the other aspects of testing are fair, and I made a huge assumption with the OCR grading program. What you get depends on the grader's mood, and other things. Also, the formulation of the questions biases the results more than anything. But that's testing for you.
Mostly the purpose of making student's code for and exam is too see how much they know, not how much they've stolen off their study partner. If you did the work through out the qaurter, you'll do OK, if you didn't, you'll fall on your face.
Now that I'm out in the work force, coding on the fly is the norm, not an exception (we need this, NOW - shows up out of the blue quite often), so I don't really see a problem with asking student's to do the same for a certain percentage of their grade.
"We shall party like the Greeks of old! You know the ones I mean." - HedonismBot
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.
No, Thursday's out. How about never - is never good for you?
This isn't about what you can do in the comfort of your bedroom; it's about how you can perform under exam conditions. Whilst not being real world conditions, this is good discipline. If this is the standard that everyone else (that you are in competition with) is measured by, and you do not measure up, then tough. It's not fair, but it is the way of the world.
If your "open source and commercial" experience is up to scratch, then you have no need to sit exams in the first place. You can either program or you can't.
is the word you are looking for
"(Man) tries to live his own life as if he were telling a story. But you have to choose: live or tell." --Sartre
It seems that you've associated syntax and semantics with the visual cues of a computer.
Quick, in what order do the arguments come in the C standard library's fread()? What about qsort()? If you were in a real coding situation, you could pull it up in man or something within two seconds.
Stop using IDEs. Use the plainest text editor that you can find to write your code.
Is using Microsoft Notepad OK (that's what I use half the time anyway), or do I have to go back to ed (or edlin, its MS equivalent)?
Write code away from a computer. Use a pencil and paper.
I did this in high school when I had already finished all pending short-term course assignments. It worked. Paper and pencil really helps a fellow visualize the analytic geometry necessary to develop a 2.5-dimensional real-time graphics engine. (Yes, 2.5-D engines are still in use on handheld gaming platforms.)
Will I retire or break 10K?
I was preparing a student of mine to take the AP CS exam (A) a couple of months ago. The coding section is graded very reasonably.
Let's say that in a function you've got a vector of objects and you need to call a member function on a certain set of them that meet a given condition.
If you loop through the elements of the vector, you'll get X points. If you test the objects for the condition properly, you'll get Y points. If you correctly call the member function using the element in the vector, you'll get Z points.
If your intentions are clear, but you make some logic error (OBOE in the loop, missing an upper/lower bound in the condition, etc.) you'll get half credit for that little section. (Generally the "sections" are from one-half to 2 points each, and the full function is around 4 points total, give or take 2 points.)
In addition, if you make a syntax error you *could* lose more points, but *only* if you got points for that section. A lot of errors that people seem worried about (missing semicolons, braces, parens, etc.) don't make you lose points. (If you indent to show where braces are needed, you're okay.)
The things that will cause you to lose more (one-half or 1) points are, in my student's opinion, insanely stupid things that you shouldn't screw up anyway, such as reading in new values for parameters, using types names instead of variable names, not declaring variables, or returning something from a void function. (There are others, but pretty simple like these.)
Problem solving with the computer is the most important thing, so we have lots of coding homeworks to exercise that material. That's fine, but it still leaves a place for code-writing questions.
A code-writing question is a very concentrated way for a student to show that they really understand a topic such as recursion or pointer manipulation. Ideally, the answer should be short, and obviously you don't want to grade on syntax or other superficial stuff. Forcing the student to visualize the data-structure and come up with solution code on their own shows off their understanding in a way that multiple-choice questions just don't get.
Here's a paraphrase of one of my favorite old exam problems from a languages course were we talked about low-level memory manipulation in C....
For the following function, 'a' points to a malloc allocation heap of the given length in bytes. The elements of a linked list (1, 2) may be allocated in the heap somewhere. Search the heap for the list, and if found return a pointer to the '1' element, or return NULL if not found. Assume that pointers and int are the same size, 'length' is a multiple of sizeof(int), NULL is represented by 0, and the list struct is not padded.
sounds like you're just pissed off 'cos it's results day today...
There have been several documented computer accidents relating to something as simple as a misplaced semicolon....sometimes the code has the correct syntax, but the error is semantic.
My 2 Cents
I asked my first college CS professor this same question. His reply was that while the homework was a much better indication of coding skills, the written tests were a much better indication of who knew what they were doing and who was cheating, (or getting a LOT of help.)
Why the hell would you want to retrain yourself to be better at coding for purpoises other than writing programs?
One purpose for learning to code is so that you can end up with a finished program. The other is so that you can end up with food on the table. Learning to code on paper gives you skills that get your foot in the employer's door so you can put food on the table.
Will I retire or break 10K?
We all feel terribly for you, give us a call when you graduate high school. After all, in university they just give you a degree because you are l33t and can install GNU/LINUX.
Well I'm not quite a computer science student yet, but I just had a GAT and that required two writing tasks which I found quite painful! I'm not brilliant at english, but even when given more time, flexibility and the ability to research the topic a little, I can write something much better.
Jeremy
Melbourne, Australia
Jabber Australia
A hand-written test seems to assume that coding is a linear process--that in coding one starts at the beginning of a task and proceeds in an orderly progression to the end. But I personally rarely do this. Instead, I break a problem down into parts, solve each of the parts separately (which may be further broken into sub-parts, etc), and then assemble them into the finished product. Computers make this process a pleasure since they make in really easy to insert and rearrange huge chunks of text. The same process, though, is nearly impossible on paper, where the only operations you really have are "put text in empty space on paper" and "delete text from paper".
Snarkiness is inversely proportional to wisdom because it emphasizes feeling right rather than being right.
As a student I would say that it was very unfair.
It seemed so difficult, so subtle. As a TA I would say it is very fair. To learn the
subtles of a language is quite difficult, to know that == is not = and to understand classes, objects, and pointer references is an art form.
If you are a true coder then understanding written code and generating written code is trivial. Writing code on an exam also requires one to structure the answer first, rather than perform trial and error coding. Trial and error coding is useful in learning, but a bad practice from a software engineering viewpoint. If you look at coding as a mathematical piece of text then one should appreciate and understand the intrinsic relationship to the logic in which you create. Software is like math and can be very error prone. Psuedo code is like English and can be very abstract.
That doesn't mean all languages are equal.
And believe me, a TA or prof should be able to tell if you can pick up on the concept regardless of the syntax you create -- unless of course you learnt nothing in the class...
...All i got for my Computer Science Final was a stack of IBM cards and a hole puncher. And then it broke half way through the exam. So I had to use my teeth. Of course, our teeth back then were a lot stronger back then....
I think the use of syntax testing in high school/first year uni/all of tech school is very important as it comes down to learning the fundamentals of the language. If you were to take a humanities language course such as Spanish or French you are tested on the syntax and grammer of the language reguardless of how eloquintly you can speak it. If you expect to be called an expert or guru in something you should at least know everything about it including syntax.
And the fact is in day to day programming, not just a code junkie, the more useful programmer is one who can communicate, especially the fundamentals, to another person. Reguardless of how well the programmer can use cut and paste and look up the online help if they can't even write down their own idea on a piece of paper they are useless.
Don't be a wimp. The amount of skill it takes to be able to generate an answer while not at a computer and still be right is indeed greater than it takes to sit at a computer and "hack it out". That's intentional. And it's worth testing. If you're a programmer who can solve exam questions on the spot off the top of your head, then you've got a good grasp of your language, its syntax, and how to deal with your problem. This is immensely useful in the real world.
Given 2 programmers, both of whom can design equally well, but one of which can do correct implementations quickly without needing to test them and the other of which needs to work on a computer, the skilled implementer is preferable. Of course in a real world environment you're actually going to have a computer, and you actually are going to test your code, but the clean implementer is going to go through this process quicker, because he or she will have less to correct.
If you can teach yourself to know how to do "academic" problems cleany enough to pass a test, you're much more valuable and productive a programmer when it comes to writing clean and correct code.
Not only that, but this kind of person is invaluable as a resource to other programmers, because if they have a question like "I want to do X using Y, how do I do that?", he or she can explain without having to resort to saying "I dunno, I could go back to my station and try a few things..."
And lastly, I find that typically on exams the professors are looking for algorithmic correctness more than syntactic correctness. Since this is essentially testing "applied design" skills, it's again something very valid to test people on.
At the end of the day, if you're doing a course which requires you to do a exams where you have to write some code, then you will end up doing exams where you have to write code.
So side stepping all the arguments like "is this an effective way to test peoples abilities" etc.
Here are some practical tips which I use when taking such exams:
1. Write all your code AT LEAST double spaced, this leaves plenty of room to make corrections, insert new lines etc.
2. Leave whitespace everywhere, particularly at the end of a question. This will make it easy to come back to a question latter and pad it out if you have more time. This is pretty general exam technique, although its particularly relevant if we're talking about having to writing code for algorithms where you may suddenly remember you've forgoten something.
3. If like me your natural style of coding is an itaritive approach (i.e. first you write the function outline, then the outer loop, then the inner loop, slowly fleshing out your codde etc), make heavy use of functions!. Write all the complex parts of your code into seperate simple little subroutines. This will not only make your code more readable for the examiner (if you name your functions clearly), it is also easier for you as crossing out a little subroutine and re-writting it is easier than having to rewrite one big function because you forgot something.
4. Finally as has been said before, unless you are taking a course which purpose was to specifically teach you the syntax of your target language, little mistakes are unlikly to make a difference to your grade. One would hope that someone marking an exam with snippets of code in the answers has been a programmer (or at least had to write a program) at some point themselves. Despite evidence to the contrary examiners are human, and will realise that the odd minor syntatical mistake should not reflect badly on your knowledge of the subject being tested.
- Cj
If a professor just takes code from paper and then puts it into a compiler and just checks the output, then that surely is unfair.
But if a professor takes the handwritten code and merely reads it, he then gains a valuable insight into the skill level of the student.
If a student struggles with all sorts of compile errors but finally gets a piece of code to work, while another student generates the code very quickly, who has learned more? Who deserves the better grade? Who will be more productive in the real world?
Having a compiler is like having training wheels on a bicycle. After a certain point, one shouldn't need either.
int func(int a);
func((b += 3, b));
So this is how to create programs on paper.
First, divide the problem up into constituent parts. For structure programming, these are functions. For OO programming, these are objects. The functions and objects should be named with words that have high content. Humans can only hold 7-10 pieces of information, so there should only be 7-10 objects or function at any level. Once these functions or objects have been defined, establish a method of communications between them. Data that is shared must be very obvious, even to the casual observer. Hidden global variables are not acceptable.
One these top-level entities are established, they can be fleshed out with code. Normally this will involve writing a bit of glue code for the functions, with other functions called, or creating data and member functions for the objects. Focus only on the problem at hand. Remember the 7-10 rules. If something get complicated, rename it as a function and write it later. The more correct code you can write, the better.
If you find the need to call one top level function from another top level function, or declare public data in objects, you probably made a mistake and the architecture needs to be rethought.
If you can get this far, I believe that you have shown a grasp of code architecture and grammar. You have also shown an ability to understand the problem and convert it into scaffolding that appropriate functions can hang off of. If you did a really good job, you have created code that can easily be expanded. All that is needed now is to flesh out the lower level functions, which can be done as time permits.
So in conclusion, one needs to come up with some top-level functions and object. Create well-defined data and methods to communicate between these tope level function that will minimize the cross talk among them. Flesh out the entities with correct code, always keeping you focus as targeted and high as possible. This is a skill that takes significant amount of time and effort to learn. Read coding books, as reviewed on this site, to get good at it. There is not time on a test to think about such basics are make big mistakes. Do you homework beforehand.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
I write and grade these horrible tests (a good reason to be anonymous;-] ) as a CS prof at a reasonably respectable place. 500+ lines is too much for a in-class exam. In a language class, code snippets and short programs are appropriate because you are supposed to learn the grammar (sorry but that's what a C++/Java/C/... class is about). In other classes pseudo code is better. If you are having a mechanical problem with the tests, ask the prof about it at the very beginning of the class (i.e. before you fail any exams). Most universities and prof's are quite reasonable about alternative test conditions. (It does help if you can document a problem first). It is not fun to fail students. It is critical to bring this up before any tests because otherwise it looks like an excuse and I assure you we've heard them all (is that your third grandmother who just died?).
cheers
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.
Join the NFSNET. Our prime goal is making little numbers out of big ones. http://www.nfsnet.org/
It's also worth noting that this kind of thing starts to be the cross over from hacking in to software engineering. You know there is a whole school of thought and practice (usually only for very important things) where the developers don't get to compile their code. You get a document that tells you to produce something, you code it up, you hand it over to an SCM person who compiles it and tells you if it compiles or not (they don't tell you why if it fails) if it fails you and your team start combing through everything looking for problems. Once it compiles it goes on to test and they react in a similar way. The idea is that you find and fix other problems when you don't know what the problem is. It works, there are aerospace applications and defense applications that have been produced that way and the correctness of the output is staggering, so is the cost of production but it costs a lot to make really really robust software.
As someone who has also done a fair share of BIOS and boot coding, there is something to be said for writing some code, reading it, seeing that it should be correct and then trying it. When it takes 15minutes to compile something, burn it in to an EEPROM or flash and then try it out you put a little more importance on proof reading the code regardless of what a compiler tells you. It's far more efficient to write something, debug it in your mind, rewrite it, then try it in those kinds of environments.
While I'm writing this, I'm reminded of Linus' dislike of kernel gdb code. You know what his thinking is? If you need to walk through it in the debugger to make it work, then you probably didn't understand everything that was going on in the first place. I really can't disagree with that, the problem with his product is that there are a lot of rules and conventions that aren't well documented so you can read them, step in and write a driver and understand all that is happening..
Personally, I start getting a little suspicious when someone can't code C++ or C without VC++ and intellisense or they need some wizbang Smalltalk IDE with drag and drop. Tools are great but they don't make the programmer. In the right hands they can make things more efficient and we all have our preferences but being unable to use other tools to do the same work isn't a limitation of the tool, the language, the platform or anything but the programmer. In the end, tools are just tools and all the tools in the world won't produce great products without great programmers using them.
If you can't produce programs away from a computer then I'd start working on it. It really says more about the kind of a programmer you are than the test. There will always be anxieties and things like that, those are often related to test taking skills, but if you simply cannot think through a program and start to produce something that looks like code without a computer then I think you should start practicing it a lot more. You may be a hell of a perl or C coder but you might not be much of a software engineer yet. (not to be personal, no ill feelings intended)
Written exams for CompSci were easy before peoplegot used to using the IDE with contextual helpers. Face it, you're crippled in your thinking and need the crutch.
To start off, let's define "fair"; actually, let's first define test:
...hole and nit picks about every syntax err and typos -- (are they still considered typos on paper since i am not typing?) -- then you are screwed anyway so suck it up and do your best. we've been there too.
test is a mechanism by which a group will be divided into a passing population and a failing population. (In college, you can also further divide into A,B,C,D,etc)
a fair test, or, at least, 100% fair test, does this division perfectly (in the rest of this i will deal with pass/fail only, it works the same between A/B/C/D whatever) -- i.e. 100% of the students (whoever/whatever under test) who deserves to pass passes, and 100% of those who does not deserve to pass fails.
ex.: a test that passes 95% of the deserving population while also passes 95% of the un-deserving population is completely useless.
now -- no test is 100% fair, let's first get that straight -- but, a good enough test will get pretty good at these ratios, so assuming that the test is good at what it does: separating the deserving and undeserving population: the question gets pushed back to a more fundamental level: which students deserve to pass?
those with a firm grasp of computer science, of course. but this is enough of a debate-ridden debate (ha) without mixing in our debate. what exactly constitute such an understanding?
In the end, the fairness you are asking (i am jumping ahead a couple steps of logical dedcution; complain if you can't make the leap) is that "is writing code on paper" a valuable skill which would determine my "deservability" to pass this test?
*my* answer is yes. again, this falls into another whole bunch of debate that i won't get into -- but you now know where to look for more info -- however, some key points i will use to support myself:
writing code on paper makes sure that you "design" well -- anybody can figure out a problem with a debugger (well, not everyone, but a fairly large population of programmers) -- but being able to critically find these errors while they are on paper / whiteboard / in your head makes a valuable skill as a programmer. you are no longer a slave of the compiler -- but rather using the compiler as intended: a TOOL. in software engineering, the main focus is design; everyone who thinks that programming (especially large projects) involves sitting down with some coffee and start typing are delusional and really should try taking some software engineering courses. being able to produce a flow-chart and convert that into psuedo-code is exceptionally valuable -- (excepiton is visual basic?) -- and that's really what most professors check for anyway -- logical thinking, algorithmic understanding, not producing dead-locks and memory leaks. relying on the compiler to do the error checking and "debug" when the bug should have not been there the first place because of bad design is bad programming -- and without that skill, i would say it's rightly so that you would fail / not do so well on your tests.
a side note: if a professor is a
My life in the land of the rising sun.
It's people like you that make me glad I'm no longer near a university and the clever half-wits that infest them.
It's pretty simple really. Ask yourself just what your prof is trying to test. As you didn't say what sort of exam it was I'll have to try and guess.
If it was an exam on a programming subject they are trying to find out how well YOU KNOW the language - not how well your editor knows it, not how well your compiler knows it.
Thus getting you to write it down allows the examiner to see both your thought processes and the results.
If it was a more conceptual subject then the code probably would have been treated like pseudocode for marking purposes, so exact syntax would not have been important anyway.
The thinking pattern is just as important in this case.
Assuming that you really are addicted to outlining then there is nothing to stop you doing it in an exam - use the WHOLE book, do a text outline then the code. Put one function on each page and cross them out as your thinking evolves.
As a bonus, almost all tests will give you high marks if they can see that WAY you are THINKING ABOUT the problem is correct - even if the solution is wrong.
If you can do this then maybe, just maybe you won't be yet another useless university graduate who thinks typing speed is more important than problem solving skills.
Learn to adapt. After all, it's probably the only useful skill you can get out of a University.
E2.
My solution is this: Just get >= 'D' and you're all good. Grades mean funk-all in the real world and all those try-hard 'A' students will be no further ahead come graduation.
Employer: "How were your grades?"
You: "Good."
Employer: "Can I see a transcript?"
You: "No."
Employer: "Okay... You're hired."
Universities are about learning an academic discipline, not about learning a trade.
Computer science should be about the theoreticals of programming -- thinking and communicating in a shared language with other academics without having tools. Sure you need to know the trade to know the theoreticals, and you should be able to sit down in front of a computer and write code, but you should also know how to communicate the principles of the work without the tools.
Computer science and computer programming are not and should not be the same thing.
You can fake having some measure of skill, if you have a machine in front of you.
As a lot of people have already noted, there are people who use a compiler as a crutch, to catch errors. Just as people use a calculator as a crutch, or a spelling checker as a crutch.
I would not hire a reported for a newspaper who could not turn in good work without a spell-checker (or worse, a grammer-checker).
I would not hire a mathematician who needed a claculator in order to take a square root.
And I would not hire a programmer who needed a compiler in order to write good code.
I think that it's very important that the skills reside in the people, not in the tools.
I also think that people who approach problem solving through successive approximation, using an editor and a compiler to judge their work product, are much less likely to solve a problem correctly the first time.
Yes, it's amazing the number of problems you can solve with brute force. But a brute force solution will inevitably be suboptimal, and require rewriting by someone else... someone with better work habits.
There's a lot of merit in knowing how to arrive at a solution, but there's also merit in knowing the answer before you start.
Knowing how to use a tool is good; knowing how to build a tool, because you know how a tool arrives at its result, is better.
As a final note, I will say that I have known a lot of programmers from the "sit down and code" school of computer programming. Without exception, these are people who I would not hire for a design position on a bet; I would prefer not to hire them at all, but if it came down to it, they could do OK in the production of prototypes. They are people who don't understand the value of planning, or provability, or process, and they are the people who will become upset when they are forced to use source code control, or to work in teams. They are people who can not solve complex problems, except by way of kludge. I guess the worst part of this is that these people often believe that they are "code gods", simply because they can produce code that, with a restricted set of inputs, gets the expected set of outputs, and they can produce it quickly.
-- Terry
Now I do a large portion of my work on paper. I've never gone to college (aside from a brief stint at one of those crappy "learn to code in 12 months" courses, which I quit right away), but I had been coding recreationally for years, and my high school had a 3 year comp sci course where the teacher forced us to do 75% of our work on the chalk board and on paper. I f***ing hated it! Tests were almost all done on paper too, especially the exams.
Then I moved cities and had to get a job, so I got up to speed with Perl, and I've been coding professionally for 3 or 4 years now. The problem was that when I moved, I didn't have a computer for the first year and a half I was here, aside from at work. So I took out a dozen books at a time from the library, got a big notebook, and coded all on paper. It was painful at first, but now I can't do without it. I find it helps to separate myself from the problem at hand, and since I use scripting languages (usually PHP now, with some Perl/Python/Ruby once in a while) I don't have to worry about compiling, and the code is much more like prototyping or pseudocode.
I went back to my high school a few years ago and thanked my teacher for forcing us to code on paper, because now I use it constantly. It forces me to thoroughly understand the problems I'm working with, and to consider my approach more carefully. It also helps because with pseudocode you can make your own functions you don't have to worry about implementing until later.
This also helps me when I do API designs, since I can put short UML diagrams interspersed with my pseudocode all over the page.
putfwd.com - 1GB Free file storage with a twist
Shudder to think, I learned COBOL in college as a requirement, and while I *HATED* it at the time, I was required to plan my program, flowchart it, write up the output specifications, and write the program ALL on paper before I was even allowed anywhere near the computer. These assignments had to be done, and handed in, and if there was an error, even one tiny error, like missing the head of the arrow on the flowchart, 50% off of the documentation part of the project. No questions asked and no appeals allowed.
It seemed totally unfair, but it was the best thing I had to go through. I got to be really thorough before I started working.
I know it seems like such an impediment now, but people have done it since before punch cards, and it's just a skill you learn.
I think that there is an important personality dimension in coders that is relevant to their level of performance on written tests. A good name for this dimension would be the "explicit thinking vs. implicit thinking" dimension.
Basically explicit thinkers understand a problem and conceptualize its solution before they start to code. Implicit thinkers went presented with a problem either do not want to understand or cannot understand a problem fully and thus they start coding in an exploratory way.
Implicit thinkers use their initial coding attempts to understand the contours or possible solutions to the problem at hand. It is very neat to watch how the act of coding (usually without compiling or executing the results) can explore a problem. Given enough time the solutions that implicit coders find are usually comparable to those found by explicit coders. Unfortunately, because "implicit" coders require an interactive exploration of a problem they usually perform quite badly in comparison to "explicit" coders on written tests were its not that easy to write and rewrite the answer.
Most "implicit" coders behave as they do from habit. Usually they learnt their interactive problem solving style while they were teaching themselves how to program. These coders just need to learn to take a step back from a problem before they jump into coding - it can be a little hard at first but overall the "explicit thinking" style is more effective.
The minority of "implicit" coders that behave as they do because of a difficulty in understanding problems may be identified as having a minor learning disability.
DISCLAIMER: I made up this dimension while selecting teammates for and then competing in two of the ACM international programming competitions.
Sitting in front of a computer coding allows for a significant advantage that is nullified by the paper format, namely the ability to run your code and correct mistakes. Seems to me that to successfully write code on paper requires a higher level of skill and depth of knowledge than to run successive programs until one of them fires correctly. This applies to written test in other subjects as well. A essay is better b/c it is able to be fact checked, but this advantage is not present in the exam format, thus testing your recall of the information and the firmness of your grasp on it.
If you have problems with the exam format and are not subject to some learning disability, i would suggest that perhaps you re-think how prepared you are for the test and how firmly you know the material. It could be that your knowledge of code has always relied on the crutch of being able to run it till it worked. It also could be some sort of problem with testing in general, but I'm suggesting that you not rule out the other possibility.
I was going to add that that I had this same problem at my Microsoft interview.
The recruiter wanted me to code some function in C, on paper, right there in front of him. It wasn't a very complicated function, but the environment made it very difficult. After I put together something that seemed reasonably correct, he proceeded to pick apart every little mistake, things that I easily would have corrected after the first compiler warning/error.
There are no exams that are fair for everyone. One could even argue that there are no exams that are fair for anyone.
Are you being tested on your knowledge of coding, or your understanding of principles?
Study principles. Code is completely secondary.
when you "compile" perl code and you are missing a curley bracket on line 14 it says "Syntax error on line 14 you may be missing a curely bracket"
--mikeeusa--
Any exam that expects someone to write large chunks of code *that work* is utter arse!!!
However expecting a CS student to be able to construct a psuedo-code algorithm is both;
a) to be expected
b) totally reasonable
Provided: The marker lets the syntactical error slide and awards grades according to how well the student has grasped the logical task required. One of the fairest "code questions" I ever had to answer in a university exam involved changing the generation order for various combinations. We were provided with the full algorithims for lexographic and gray and an example of the desired generation order.
Using the computer as a crutch, i.e. iterative coding, CAN coax good code from adequate people, but if you knew what you were doing, you could write it down.
Yes, I've been coding 28 yrs, doing bleeding-edge work. I use tests like this to help pick out the wheat from the chaff when it's time to hire. There's nothing wrong with the exam. It did everything it needed to.
It's not enough to know it with the computer's help. You need to Know It(tm).
Heh. Not long ago, I was the only programmer at my company, but we needed to expand. My boss put me in control of the interview, and I had a LOT of fun... with guys I didn't think I'd be able to work well with (very odd company atmosphere... not just anybody fits in), I sat them in a half-width folding chair, asked them three questions, and made them code. Sat behind them in my boss's really nice leather chair, and watched them code. My boss puts the pressure on a LOT, and the guy I hired is handling it perfectly.
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.
I personally think that you should be about to bring your mom into the exam. I often get tired, or need a drink during an exam. If I could have my mom there to encourage me, that would be cool. She says i'm a really good at programming.
Grow up!!!
Exams are meant to be hard. If you have problems... practise more.
I actually find it easier and better to do it on paper first. My solution is likely to be more thorough and with less logical errors, doing it on paper.
When you get to a certain maturity level at programming you should be able to do it in a methodical manner - paper and pen first, before coding and the keyboard.
Start coding with discipline. 'on-the-fly' coding might seem far quicker, but wait till you face large complex problems.
if(you're fucking the professor) {
You'llGetAnAAsLongAsYourDickIsBig();
else
You'reFucked();
};
An exam is an exam, everyone takes the same fucking one, or something which is basically the same, which teachers do to deter cheating -- you, however, are whining. Just like I whined about Trig in High School, yet everyone had to do the same exact thing, so I was an idiot.
But at least I learned, and moved on. I mean come on man, you're just grabbing for sentiment. Go take the fucking test, you either know how to write code, on a napkin, on paper, in a computer, on your girlfriends back as you rail her from behind, or your boyfriends, from the looks of it, but it doesn't fucking matter any way you look at it: it's you who writes it.
This test is a measurement of nothing more than your ability to take this test. Why do people think it was ever anything more?
Want some cheese or what?
I do not respond to cowards. Especially anonymous ones.
No they are not fair, but they are probably the only way of assessing whether or not a student in a lower level course (sophomore or below) has really learned the material.
This goes back to a previously Slashdot article on getting help on your Computer Science programs. Someone in a beginning CS course can probably "get by" on their programs by getting help (honestly or cheating) and/or by using the internet/books for examples and hacking away at the code. The only way to really assess whether the student has learned anything themselves is to sit them down in a closed atmosphere and see if the student really knows something by giving them a test.
Now my experience has been that in upper level classes the amount of code writing done on tests is greatly reduced. This is because being able to "get by" on the more difficult assignments is harder and there is enough material of greater complexity to test the student on higher level concepts without requiring getting into detailed code. The student is still expected to write pseudocode however, but this is more to show that you can solve a particular problem (say creating an algorithm) than testing your ability to write C code.
The ability to write code/pseudocode outside the computer is not a useless skill. In my experience I have done alot of whiteboard coding in groups on different projects when brainstorming solutions to problems. I have also had to do it on interviews to show I knew my stuff.
Brian Ellenberger
I have never taken a CS course, but let me throw an idea at my fellow /.ers. From my reading of the posts, it seems that people are assuming that if an exam is to be taken on a computer, a debugging compiler is automatically present. The limitation of plain paper exams is that the coder must in effect write everything in a linear fashion or face space restrictions. Perhaps the simple solution would be to allow the use of a plain text editor (vi, emacs) but lock down all other software on the machines. I know this is either impossible or too time consuming, but at least the coder could insert lines/blocks in the code easily.
No CS course should require you to know any syntax. Coding? Leave that to programmers. A computer scientist needs only know what a linked list is, not how to get it to compile, be it in LISP, C++. SmallTalk, Java, or Logo.
--- this space intentionally left blank.
How could he work things out on the paino if he was deaf?
"I don't know that atheists should be considered citizens, nor should they be considered patriots." - George Bush
If your school is making you write hundreds of lines of code, on an exam, and requiring that the code be ready to both compile and run flawlessly, I'd advise you to look for another school: first, the fact that the department seems to fixated on generating code in a particular language is a very bad sign. Computer science is not about coding, but about the theory and structure of programs and computation, none of which needs to be expressed in the kind of strict syntax required of real-world programming languages. Second, the fact that the department even thinks that anyone could write hundreds of lines of code in a couple hours and have any hope the code compiling correctly, much less working, is ridiculous and suggests that the department itself is less than top quality.
All of that said, when I was required to write real code on an exam, there was always some leeway for 'typos' (or whatever the equivalent is when you are writing with a pen, rather than typing at a keyboard). Most of the time, however, only psuedo-code was required. Even my computer architecture course, where we discussed scheduling of machine instructions, allowed the use of entirely hypothetical assembly languages on the exams.
My only experiance is AP computer which is a joke. We have written tests which are write a function to do this and this and write a bigger function that uses the first two. Usually 2 of these per test. They don't check stuff the debuggger catches (semicolons, etc.). All that matters is does it work and is it efficiant. If so, full points. IMO, this is a good check. If you can't do this a debugger won't help. You'll just be starting at garbage wondering what the fuck happened.
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.
Why? Well I went to University more than 20 years ago and one would have expected that CS exams would have required one to write more code then than now (we were typing onto punchcards at the time for our programming assignments).
I can't remember having to write more than 10 lines of code at a time on an exam (Structured English yes, code no!).
What is the theory now? That writing code without a compiler shows some extra talent I have not heard of before?
Someone please explain!
Maybe you're missing the fact that there are those of us who can handle such tests. I'm sorry if this is out of your grasp but keep on trying and maybe one day you will be able to do the same thing. I've tutored plenty of students in many programming languages and there really is just a few who understand things well enough to do exams on paper. They also turn out to be awesome programmers in the end. If you can't handle writing code on paper then stop filling up an industry that used to be populated by intellectuals. Stop causing the standards to be lowered in the universities. Anybody who has been within the academia environment for the past 20 years knows what I'm talking about. The students have gotten dumber, probably because the job pay has gone up.
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.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
I'm a CS student at Kettering, and I've never had something more than a 5 page exam. We have labs where we are graded on technique, and then tests based on theory. Example... I had to write parser code in Java, but for the exam, I had to draw the Parse Tree, no code at all.
Both in exams and outside of them, I tend to do most of my work in pseudo-code first as it helps me to get my head round tricky sections of code. I find it's much easier to sit down and say "This needs to happen (scribble) but only when this is true (scribble)", and from there you can begin to construct basic code around the pseudo-structure - far easier than delving straight into the code :)
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'm a 2000 man.
I know many "experienced" professional coders who can't write more than 30 lines of C++ without an IDE to check for syntax. This really shows a lack of basic knowledge of the language with which one is working.
Were I an employer, I'd much rather hire the interviewee who quickly gets to work on a whiteboard over the prospective hire that chokes when asked to write code without a terminal and IDE. It's a matter of productivity. Does anyone want programmers who are spending their time fixing one syntax or structure error per every 4 or 5 lines? Probably not. In this labor market especially it is essential to know your craft inside and out. For programmers, that means knowing your chosen language and it's quirks without a syntax checker.
It's not that you can't do the coding without a computer. It's that you're lost without the IDE to "remind" you of the language's syntax. Stop whining about exam setup, which is unlikely to change anytime soon, and learn your stuff thoroughly. You'll also be that much further ahead of your peers.
I found that I could write code three times faster. Psuedo-code is the devil ;)
I go to UMD and we where required to code on all or lower level exams. We where not only graded on correct structure but we lost points for such little mistakes as not indenting properly. It's a real pain to have to rewrite a whole function just to insert a new variable at the top. WE definitely had no time to rewrite or code 3 or 4 times and where expected to just bang it out. It seemed to be the general agreement among my classmates that coding this way nowhere near showed or talent. Many of us found our selves writing sloppier code this way just so we didn't have to redo what was already on paper.
The ability not to forget a semicolon at the end of a line, or match parenthesis in a resonablely complex expression correctly is a much less important than fundamentally understanding the algorithms the class is teaching. At least in my exams, simple syntax mistakes didn't matter, and we didn't have to code anything that long. If you were an employer, would you prefer someone who write compilable code all the time? Or one who had a sound fundamental understanding of various algorithms?
I hate to drag out the obvious once again, but have any of you ever interview for a job? For many, many jobs you'll have to write lots of code. In some interviews I was asked to write code that took several hours. This coding was done on paper (or a whiteboard) not on a computer. Being able to code when you're not infornt of a screen is an important skill to have. You might not like it, but who likes taking tests anyways.
I'm going to skip reading most of the comments and post my $0.02, even though I'm sure it may be similiar to a lot of other people's thoughts.
It all boils down to the professor most of the time. For the most part, I agree that if exact (ie, correctly formatted and working) code is required, you HAVE to be sitting at a computer and have a chance to compile, find errors, and fix your code. However, I had a lot of professors that were more concerned about the form and function as described by pseudo-code.
Honestly, I have found that paper code makes you more prepared for the real business world. ie, If you are working as a programmer, and you are discussing specs with a client, there may be times where you need to think quickly about a problem from the programming perspective. This usually (for me at least) gives me a minute to jot down some code that pops into my head--without regard to whether or not it will actually work the first time. If you depend too heavily on using a computer to make sure that code works, you may not be able to trust in yourself. I kinda equate it to the argument that reliance on calculators makes you forget basic math when you're in a pinch. If you do a little on paper now and then, you keep it fresh in your mind--check it on your computer/calculator later.
Sometimes I doubt your commitment to Sparkle Motion.
Ok, a few ideas here... first get ACDZip as well, it supports sef files which are 256 bit encrypted archives, put a good long password on them, give then random names. ACDSee can browse inside sef fils just as if they were folders. Almost as fast too, if the sef files stay under about half a gig or so. Turn off the thumbnail database in ACDSee, as well there is an option to clear the part box on exit. Also, batch rename all your pron so no file names can give you away. Do that and you should be good to go.
I teach (yey) at two vastly different schools. One school is the traditional' theory based school, and the other is the 'devry' type learn syntax and don't care about understanding type. In one school, I give language independent projects, ask people to come up with algorithms, etc., in another the students are so far behind in actual understanding of computer science that I have no choice but to resort to testing their syntax (since there isn't much you can do when students have problems with for loops - and are 2 months away from graduation!).
Now, if your class is something like "algorithms" they shouldn't really care if you miss a comma or a brace, etc., as long as the idea is correct, but if it's something like "Java 101" and you write something that resembles QBASIC, then there is obviously a problem.
So the original idea of writing code on paper should only be used either in beginner classes or in 'devry' like schools, all else should be a bit above 'code' and more into algorithms and concepts.
"If anything can go wrong, it will." - Murphy
I'd argue that you are not only eliminating the worst candidates with that type of test, but also the best. The best programmers do not remember code in a specific language. The best programmers do not waste valuable "brain space" remembering trivial crap like linked lists that none of us would ever write in practice (since its been written a bazillion times anyway).
Writing code is not done in a sterile, non-networked environment without books. We do not code on the top of Mount Everest. Good programmers certainly will not waste a companies time and money by writing a linked list from scratch. Knowing how to write code in a specific language is one thing, knowing how to write some trite piece of code that you haven't written for 5, maybe 10 years is another.
I say, if you're going to ask for code, ask the interviewee beforehand what types of things they've been coding recently and ask a code question along those lines. Do a little work yourself instead of asking some lame ass question that no one would have any good reason to remember the answer to. Hope you like those greenhorns or anal rote memorizers you've been hiring. They must be either close enough to having been in school or a one language pony to remember useless junk like exactly how to write a linked list.
Frankly, I'd be more apt to hire a candidate who told me writing a linked list was a stupid question and that he'd just look up sample code than one who wrote it perfectly. I don't want droids working with me, I want problem solvers. That is what programming is all about, after all.
In short, unless you're hiring for the position of linked list expert extrodinare, asking for on the spot compilable code for a linked list is most likely a waste of time for the interviewer and the interviewee.
// harborpirate
// Slashbots off the starboard bow!
WOW, Im completely the opposite, I actually code better on paper then on the computer. For me the computer interface distracts me, so I isolate myself from it, code on paper, then come back to the computer to type it in, It seems to work better that way for me.
unforseen circumstances
In psuedo code, I might agree with you. In a specific language, requiring it compile, no. Yes, a good programmer should know basic concepts, but more importantly, a good programmer should be able to use basic concepts in a language independant manner. Why would anyone want a programmer to know how to code a linked list? Its a waste of time. No one is gonna code it from scratch, its a trivial and demeaning question. I know if I went into an interview and someone asked me for code like that, I'd tell them straight up that I'd look that up in a book or online, and that it'd be a waste of my time to write it. Maybe if you're hiring greenhorns straight out of school you might ask a dumb question like this just to make sure they aren't completely clueless, but for experienced programmers its frankly a poor test to find a good problem solver. Really, in my opinion, it shows a lazy interviewer who hasn't bothered to come up with good questions.
// harborpirate
// Slashbots off the starboard bow!
I'm shocked to see how many people are complaining about this issue. To me, the real test of your coding skills should be done with homework assignments and projects. They show that you understand the problem and how to solve it using the paradigm given.
As others have said, the role of exams is to test the CS concepts being taught: algorithms, methodologies and problem solving skills. It's important to be able to demonstrate you know what a linked list is and when it should be used instead of an array, but that doesn't require a significant amount of coding in the test.
It is the same with all academic subjects. Like solving physics problems, without text books to give you base equations to start from.
I agree with the writer's feeling about writing code on paper, but I think you have to be pragmatic about it and realize that testing is never perfect. There are probably people out there who would object to writing the same test on a computer (although this wouldn't make much sense if you were a CS student). Ultimately I think most professors/TA's will realize that paper is a disadvantage and mark accordingly. I think resources are also an issue. I don't know how it works at other schools, but I go to the University of Waterloo, which has a pretty well established CS program, and we don't have the resources to have exams on computers... not when you have classes of 80+ people. To construct a closed environment for exams would be a nightmare for the school. Also, marks are never really the point of a University education. The valuable part of a CS degree (IMHO) is that you are forced to actually code.. to figure out complex problems and work your way through them. Unless you are shooting for graduate degree, or want to work at MS, I think life is too short to stress about the format of tests.
five fingers make a fist amalgamate and resist
Hand written code is really a bitch. All of my CS tests in coding classes have had rather large coding poritions to them. While I understand there's very few ways to show that you indeed know how to code, University CS programs shouldn't focus on a language.
If the professor grades the hand written code solely on the logic rather than symantics then I agree that hand written coding tests are acceptable. However often this isn't the case. If you're testing on the language its only fair to offer these tests in a real world situation, one where you can run the code through a compiler a few times and find your errors which are bound to happen.
scott
I am very comfortable with writing code with a
text editor. The thing about writing code on paper during exams is, well, very, very silly. My uni asks us to write code all semester with editors ( or IDEs ) and then abruptly exams us on paper.
I cannot see why the uni just provide even a text editor without access to the compiler or anything else so that we can complete our exams.
I very used to coding with a text editor on Linux and I pay the price, I think, when I am forced to write on paper during exams. I know that it is not a measure of my abilities or understanding.
Mod-bombing. Fascist mods look through yr posting history and mod down previous posts.
The teacher I had for computer science my senior year in high school... not only could she not teach incredibly well (at the end of the 2nd semester, we had gotten to 2 dimensional arrays in BASIC! UGH! Not like I had to listen or anything... she told me I could do whatever the hell I wanted for the entire year), but she had a tendency to give written exams for computer science... you shouldn't have written exams in computer science! It doesn't reflect your coding ability. In a related story, LSU didn't let us use calculators on our math credit exams... how the hell are you supposed to do COMPLICATED logrithims without a calculator, slide rule, or log table?!
This is why I became a Philosophy Major. I couldn't pass the damn in class COMPSCI exams. At home programming projects I did well on, but in the exam setting, forget about it. And I normally test well. But COMSCI is way different.
Props to RIT. Ever have Ken Reek for any CS courses? That dude's like a human computer and can't understand it when tests reveal that his students are not the same. He's a prime example of slashing points for stupid reasons.
Oh. And don't forget the most important rule you learn from RIT: "Never EVER use a break; statement." Riiiiight.
Personally hated it all but I think that syntax is relevant in a written when its part of the curriculum, otherwise an algorithm should be all that's required. Otherwise you're prone to cultivate irrational biases towards a particular language, or even coding style. Sometimes different approaches are useful in different contexts (how obvious is that !?).
Don't sweat it so much man... Assignments are a good way to prove your true skill. Also, get to know the professors and they are more likely to cut you a little slack come grade time.
:-)
Remember, good programmers will always find work in the end... Good ones that managed to graduate are even better off
Many people have commented how dumb this kind of exams are and how people never need this skill in real life. I sort of disagree. ;)
First, writing code on paper or whiteboard teaches you to be more careful and creates good habits (not the common write-something-fix-compiler-errors style). If you're working on bigger projects where compiling the code and reproing mistakes takes a long time then it often pays off.
Second, this approach also teaches you to read code carefully and spots mistakes quickly. This is an invaluable skill when working on projects that involve many people and where you often need read and debug other people's code. I have done my fair share of written exams plus whiteboard interviews and years of experience have given me a fairly good eye for seeing mistakes in unfamiliar code. And you wouldn't imagine how impressive this skill can sometimes seem to one's managers
When men used to be men
I don't believe anyone would ask to write 500 lines of code on CS exam. I remember the exams which had anything to do with coding. Mostly it was like outlining the data structure and algorithms, may be provide some logic, but that's about it. Now I'm taking a course on algorithm performance analysis. Once again, we are asked to outline the algorithm, to provide the logic. Actual code? Why bother?
Heres one people need to read.
/* */)Entertain them, comment your programs, etc. I've received an A on a late story about a floor-covering because the English prof. loved it.
Students always want to know how professors will grade things. It's like that's what matters. In reality, if it's a pile of SHIT, you will get a bad grade. if it's GREAT, you will get a good grade. When a professor asks you to code in writing (or write a short story) on the SPOT, he will see if there's thought put into it, if the events are logical, if there's good function/character development, great design/setting, planning, correct/interesting output/conclusion (for program/story). Do that, and demonstrate understanding of what you're doing (putting braces/commas where they should be), that's what professors are looking for. You're only asked to do well nothing more than what's expected to earn a great grade. Nobody expects you to write ground-breaking code in a short time, just sensible code.
RULE OF THUMB: If your creation takes A LOT of fixing/editing to be good (if it's code, replace 'good' with 'perfect'), your grade will suffer. (And If Nick, Your Company's Computer Guy(tm), needs to say MOVE!, and redo everything you've done to get the problem solved/requirements met, you will get a REALLY REALLY bad grade.)
Have your work make the professor feel really warm-and-fuzzy inside when they grade it, is what I guess I'm trying to say. Make it sensible and entertaining (think
Cover your eyes and click this link!
Not only do I agree with you, but I also happened to use Nick, your company's computer guy in my reply, too! And I've never seen him referenced anywhere except in my post and now yours!
7 06 376 is mine
Except that two-year schools are decent, too--I've been programming since early high school (learning through books and writing LOTS LOTS of programs--barely seeing any other source code until internet access years later, thus TRUE learning from experience and practice), so I have to say a lot has to do with the person him/herself, not just his or her college.
http://slashdot.org/comments.pl?sid=34241&cid=3
Cover your eyes and click this link!
The problems all mention aren't tests. It's most obviously attitude.
Cover your eyes and click this link!
Does anybody remember the old-style coding sheets? Often provided for COBOL and FORTRAN programmers in the days when we had dedicated keypunch ops, but useful for assembly and other languages too; I found the header boxes helped to organise modules quite handily. Of course, to be considered a real programmer, it was way cooler to punch cards directly with an 029 keypunch... Them were the days... :-)
The problem's quite common, having been a TA for a few lower level university programming classes, and graded the things. I think it comes down to force of habit. Although we're told a million times to code on paper first, and on a machine later, hardly anyone does, because an editor is as good a tool as any to layout structure and flow of control through function definitions and user defined types. The habit backfires when it comes to using paper. The way I'd recommend to tackle such exam questions, is to start off with a bunch of scratch paper and draw the bigger picture. Then refine bits and pieces, filling in functions, formalizing parameters, and so on. Finally bring it all together. Then when you write the code, you're working off a solid draft. I realize that this is time consuming and seems contrary to the time restricted nature of exams, but it's likely that once you do put down the code, there will be far less to change and it will take less time overall than trying to wing it off the bat.
Why would a four year school (like uni) let you do a lab test when they don't even give you lab hours in the classes?
I was there (uni) and out of all of my classes I only received 2 hours a WEEK of lab time in class. Everything else was lecturing.
So if 95% of the class time is lecture then I would assume that 95% of the test will be theory. The other 5% would be lab time.
What's the point of telling a person how to code something (or how to perform any function for that matter) if you're not going to let them do it until next week?
Professor: "OK class, this part is very important! You have to do X and Y to get the result of Z. You will do this next week in lab with my TA's. That is all. Class dismissed."
"A plan fiendishly clever in its intricacies"- Homer Simpson
if marked/judeged in the an appropriate way. It would be unfair to mark someone down for a minor syntax error (e.g. missing the semicolon off the end of the line), but if such errors are over looked I feel that judging someones first attempt at a piece of code, without the ability to compile and run it would be a interesting viewport on their abilites. It would highlight fundemental flaws with their use of sturctures and pointers (which for some reason sems to be a area many new progrmmers cannot vision without the ability to compile code and run it).
Basically I think if judge fairly an uncompiled/tested version of code should give a very good indication of a subjects abilities.
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 must disagree with that last comment.
I finished up my final exams just this past week, at DeVry in Toronto, Ontario, completing the requirements for my three-year Computer Information Systems diploma. I'm not sure how familiar you are with the school, but we do learn a great deal of theory along with our 'hands on' education.
In my exams this week, for example, I wrote one for my Client/Server Application Development class that dealt mainly with concepts and design approaches, rather than straight code. Some of my other exams have been practical, using tools and applications on the computer.
It is true that many of our courses were very language specific, (i.e. I just completed Java and COBOL courses), and syntax is important, but we are also exposed to courses such as Systems Analysis, Database Design and Network Architecture. These courses gave us the knowledge and insight needed to identify and understand problems, and create solutions for them. So saying that DeVry graduates are mere 'code monkeys' is a rather short-sighted comment.
People who despise paper are people WHO ARE NOT COMFORTABLE WITH CODING. Whether it's because they rely on manuals and compilers, fear of others seeing them make mistakes, lack of confidence in their abilities to put-out faster than a monica lewinsky, need to work on code individually before displaying it, etc etc etc, these people share bad qualities. Some are programming, some emotional, but if a company needs people to say, code as a team, other things besides IDE-experience come into notice. If companies are looking for someone to tell the recruiter, "Sure, I'll write code for you. Here we go. I'm doing this for this... This is why I'm doing this", then they are looking for confidence.
But there's a solution!
You can go to topcoder.com and register to compete (tell-em "left-handed" sent ya), you'll improve every time and gain confidence. But even as membership approaches 17,000, each match still averages about 500-600 people, because (we think) although people want to fill out 5 pages of registration, they never compete even once because of fear of sucking compared to the 'big guys' (who are very experienced). DO IT ANYWAY GUYS. Then you can also go up to a prospective employer and tell them one of your interests is programming competitions (this shows him/her you're confident in your abilities and can well land you a job just for willing to do it!) Plus, you'll remember more syntax, learn A LOT from looking at how the 'big guys' coded their solutions, and improve yourself. And those 600 people share-in the $10,000 pot every match (2x a week).
moderators please don't drive me into the ground with this, I know it's sortof off topic
but here is an area where a young profession can learn from an old one;
In every music school I know, the emphasis is on applied development (being able to perform on your instrument). There are lots of important things about music, but what matters is that you can demonstrate that understanding through performance. Several times per year we have to take a "jury" where we perform alone for the applied faculty, and this is what really counts so far as you staying in the school and doing well.
Instruments are expensive so you're expected to not only have your own, but have extensive experience with it before even applying to school.
Maybe computer degrees can learn a thing or two...
Spoon not. Fork, or fork not. There is no spoon.
... you don't know it.
In the "olden" days, you wrote your program out, then put it in the computer, it failes, loose a letter, try again.
Now programmers are more try this, doesn;t work? try this? doesn't work, change this. I swear, if I hear "I don't know why this change worked, but it did" one more time, I'll scream.
I can't think of any other engineering where creating by "vibe" would be acceptable.
We sure as hell didn't create software to get someone on the moon by "vibe".
What else you want for your exam. use of a help system? you mommy to hold your hand? sheesh.
The Kruger Dunning explains most post on
IDEs exist for a reason, and it that reason isn't (only) automatic generation of makefiles. For example, the possibility of hitting CTRL-F1 (or similar) to bring up documentation about the class/function/keyword/whatever under the cursor is priceless.
And even if you don't have an IDE, you almost always have manpages or something similar you can use.
so you feel its OK to pass students who would waste there employers time having to run a compiler over and over again because they where not trained to pay attention to what they are doing?
Why don't you just show them how to use the help system, then pass them? after all, they can look it up online.
The Kruger Dunning explains most post on
It's not so bad - as long as they don't take off for minor syntax mistakes, and consider the method more important then the syntax. I'm not sure why they would do this in college - I suppose to test your mastery of specific language (which is much less important then coding skills; anyone can pick up a language if you have the patience). Cheating is probably a major concern, too. ;)
The question of the APs was raised by someone; this is an entirely different question. The APs are something of a special circumstance. I think what they are trying to prevent here is any accusation of "favoratism" to "advantaged" schools with more computer labs who could better afford to give the CS AP exams on computer. Personally, I think they're just making kids do it by hand so they can sit around and laugh at how many young idiots they conned out of $80
"They do not sin at all, who sin for love" -Oscar Wilde
I only read a few replies and being a former CS student I agree. Writing code that is to be graded at a syntax level for a test is counter productive. I have my own problems with the CS department I was in that being that it was far to theoretical and very unpractical. Yet I am reminded of my beginnings as a computer scientist. Copying code out of BYTE magazine and initially ignoring the line numbers seperated by 10's I learned pretty quick the value of editing ones code after you wrote it.
As for those of you that think a compiler used for error checking is an indication of sub standard computer science, I challenge you defend the myriad errors that gcc will give that inidicate something wrong that is not even close to accurate. How many times I chased down errors according to the compiler that were completely wrong. Only experience and lines of code can help you become a better trouble shooter/coder.
Several of my freshman year professors had the same comment for this problem. I'm sure you must have been given a hint by a professor at some point to space and pace your work. By this I mean you have to leave space between your lines of code so you can go back and add code, and pace yourself. Don't try to rush through the answer. Think about the entire problem before you start writing. This will save you a lot of frustration.
You may want to start with a small flow diagram before you dive into code. This will help you visualize the problem and save some eraser marks.
Maybe your problem is partially a fault of growing up so privileged. When I started learning to code a short 15 years ago, I spent more time writing on paper than coding at a terminal. (Now I'm feeling old.) Every so often, I'll still grab a notebook (that's the paper kind) and sit on the couch writing out what I want to do before I code.
A lot of people seem to say that "As long as they mark your problem solving skills and not how perfect your code is, it's ok."
I agree, however, that's not the way it works. In my first year CS courses, we lost marks if we so much as forgot a bracket. That's rediculous. Small things like that happen when you ask someone to write code on paper under exam conditions.
What I think should be done, if writing midterms and finals on a computer is out of the question, is that assignments should be given the most weight on the final grade. Our CS assignments were handed out weekly, and due the following week. That allows you to take it home, code as many solutions as you can in a week, debug it, etc. I think this approach is a far more accurate description of one's skills as a programmer.
Another way about it would be to have a "final assingment", which combines all of the skills taught during the semester into one larger than average assignment. You'd have a week to complete this assignment, like the others, but it'd be weighted more.
Of course, an obvious problem with my suggestions would be cheating. And at the moment, all solutions to this problem I can think of don't seem like they'd be any good.
I'm open to suggestions.
Another approach is to change the way CS tests (midterms and finals) are designed. Drop as much of the coding as possible, and simply ask the student to apply the principles they've learned to a variety of problems. This would be a mostly written exam, which leaves it open to subjective grading. Maybe that's the way it should be. Computer Science is about problem solving, not coding. Anyone in CS should know that programming is a drop in the bucket of Computer Science. If you're designing a solution to a problem, you should know how to express your solution in words just as well as you can think of it.
-kidlinux.
so you feel its OK to pass students who would waste there employers time having to run a compiler over and over again because they where not trained to pay attention to what they are doing? Why don't you just show them how to use the help system, then pass them? after all, they can look it up online.
Don't be so obtuse; of course that's not what we did. Quick, without looking: what are the arguments passed into "strtok()"? Personally, I don't know for sure, and that doesn't matter, because "man strtok" gets me the answer on the rare occasion that I need to use it. But it doesn't tell me when I want to use the function, or how to use it in a tokenizer, and as it turns out, I do know that part. And that's the kind of thing that's more interesting to test for. Memorization monkies aren't good employees; good problem solvers are.
But perhaps you have a point; clearly, your grammar and spelling teachers weren't strict enough.
i haven't actually done any programming related exams yet (we dont have any programming subjects in my senior school) but i know how you feel... i can't code unless im on a computer
about the honesty and computers, there are lots of shell programs out there which restrict what a user can do (we have one on our computers at school which stops things like ctrl+alt+del etc..), so surely some1 could just configure this to just allow say notepad?
Might be "how it works" in your experience, but there's no reason why this is always "the way it works". In any case, your complaint is about the fact that in your experience exams were poorly graded. An obvious solution to this problem is to use a better grading scheme for exam papers (-;
That allows you to take it home, code as many solutions as you can in a week, debug it, etc. I think this approach is a far more accurate description of one's skills as a programmer.
Nope. A good programmer should be able to write simple programs correctly without having the computer to test it for them. If they can take it home, everyone should (and in practice, usually does) get it, but in an exam room, you're measuring how good the students are at catching mistakes (or not making them in the first place) without the computers help.
Of course, an obvious problem with my suggestions would be cheating.
Yep. That's why this solution isn't used in practice. It unfairly penalises honest students.
Another approach is to change the way CS tests (midterms and finals) are designed. Drop as much of the coding as possible, and simply ask the student to apply the principles they've learned to a variety of problems. This would be a mostly written exam, which leaves it open to subjective grading. Maybe that's the way it should be. Computer Science is about problem solving, not coding.
I mostly agree with this. First year courses do need a lot of coding, so that students acquire the basic skills to coherently express their ideas. I wouldn't put a lot of coding on an exam uness it was an open-notes test.
what he means is that DeVry graduates are less likely to have rich parents who paid their way through school for them and that enable them to climb the social ladder and attain job positions above "code monkey" easier.
Perhaps a 1-day programming challenge in a controlled environment (company office, no network connection, no telephone) would be preferable - of course, that won't always be feasible. :-)
Go ahead, call me paranoid. :-)
Female Prison Rape in NY
Interesting that there are so few comments from people who have marked these exams. (Possibly because academics realise that the "500+ lines" must be an error or a wild exaggeration.)
...
My students know that there is a hierarchy of tests for code-writing skills -- with computer available, with no computer but with reference material available, pen and paper only -- and that the syntax for pen-and-paper-only just has to be there or thereabouts, any reasonable approximation to the right words will do. And that only short answers will require actual code, which will involve only commonly-used syntax for the key concepts of the course. If you have to sit one of these exams, you should ask about this sort of thing (if your poor long-suffering lecturer hasn't already told you 3 times).
I am not condoning errors. My students know that I am keen on error-reduction techniques of coding (though most of them seem to fail to adopt such ideas -- sadly that includes those with previous paid programming experience). But what are you really testing for in a coding question? Not what a compiler looks for.
I would agree with those other replies that question how well a marker could possibly read the code for minor syntax errors. It is difficult enough when *writing* the code for a "find 5 errors" question to ensure that there are not 6 errors!
Unfortunately, exams have to be part of programming courses -- because staff have plenty of evidence that some students are not writing their own code for assignments that can be worked on in their own time. There are some great stories
Not only written tests, but almost ALL THE examinations that I've taken, regarding computers, are not only irrelevant to the subject of the exam, but also OUTDATED.
Take the "Linux Certification" exams, for example, under the "syllabus" of "Linux distributions", the "Stampede Linux" which has closed up shop, is STILL listed as one of the "Major Linux Distributions", and the test modules STILL carry that item !
The best way to REALLY TEST the ability of a person regarding the specific computer subject is to get the person to JUST DO THE THING.
If it's about C, then list a problem, and then give the guy a computer with a C compiler and then get that guy to code up a program that solve that problem.
What counts in the computer field is WHAT WORKS, not what one can put down on the paper, or what's in the syllabus.
That's all I will say, for now.
Muchas Gracias, Señor Edward Snowden !
I'm informing you in this message that your use of decimal is disturbing to geeks. Why did you choose to use decimal? I'd really like to know. We may have ten fingers, but we don't even use decimal for time. Decimal is clearly for stupid people. I think it likely that you do not know what radices mean, or else you would be using hexadecimal. Read about hexadecimal at intuitor and repost your comment using hexadecimal. You may use "0x" as a prefix or "h" as a suffix for the numbers. Intelligent people despise decimal--so try to show some intelligence. So do you know what hexadecimal is? Reply to this and prove it, otherwise we will assume that you are stupid.
Personalized message:
How many in the list? Stupid decimal-using idiot.
I'm informing you in this message that your use of decimal is disturbing to geeks. Why did you choose to use decimal? I'd really like to know. We may have ten fingers, but we don't even use decimal for time. Decimal is clearly for stupid people. I think it likely that you do not know what radices mean, or else you would be using hexadecimal. Read about hexadecimal at intuitor and repost your comment using hexadecimal. You may use "0x" as a prefix or "h" as a suffix for the numbers. Intelligent people despise decimal--so try to show some intelligence. So do you know what hexadecimal is? Reply to this and prove it, otherwise we will assume that you are stupid.
Personalized message:
What percentile? Use hexadecimal percentages (out of 256).
I'm informing you in this message that your use of decimal is disturbing to geeks. Why did you choose to use decimal? I'd really like to know. We may have ten fingers, but we don't even use decimal for time. Decimal is clearly for stupid people. I think it likely that you do not know what radices mean, or else you would be using hexadecimal. Read about hexadecimal at intuitor and repost your comment using hexadecimal. You may use "0x" as a prefix or "h" as a suffix for the numbers. Intelligent people despise decimal--so try to show some intelligence. So do you know what hexadecimal is? Reply to this and prove it, otherwise we will assume that you are stupid.
Personalized message:
If you have to use out of a hundred, just say 1Eh/64h. Unless you're stupid and can't figure it out. Then just don't reply.
We don't have any written coding exams. At advanced level computing (what I'm doing) we do theory, logic, problem solving and that sort of thing, but we never write any code in the exam.
I'm informing you in this message that your use of decimal is disturbing to geeks. Why did you choose to use decimal? I'd really like to know. We may have ten fingers, but we don't even use decimal for time. Decimal is clearly for stupid people. I think it likely that you do not know what radices mean, or else you would be using hexadecimal. Read about hexadecimal at intuitor and repost your comment using hexadecimal. You may use "0x" as a prefix or "h" as a suffix for the numbers. Intelligent people despise decimal--so try to show some intelligence. So do you know what hexadecimal is? Reply to this and prove it, otherwise we will assume that you are stupid.
Personalized message:
I see two grave errors. Reply as a repost or admit your stupidity.
I'm informing you in this message that your use of decimal is disturbing to geeks. Why did you choose to use decimal? I'd really like to know. We may have ten fingers, but we don't even use decimal for time. Decimal is clearly for stupid people. I think it likely that you do not know what radices mean, or else you would be using hexadecimal. Read about hexadecimal at intuitor and repost your comment using hexadecimal. You may use "0x" as a prefix or "h" as a suffix for the numbers. Intelligent people despise decimal--so try to show some intelligence. So do you know what hexadecimal is? Reply to this and prove it, otherwise we will assume that you are stupid.
Personalized message:
How many lines? Two errors. Stupid idiot.
Quick, without looking: what are the arguments passed into "strtok()"
A good programmer never uses strtok(). Its use is very dangerous for the health of your program.
Thus you don't need to know the arguments too it.
Or even better please forget you ever heard of strtok(), sprintf(), gets() and all other dangerous functions that never should be used by a good programmer.
Just saying it like it are.
I'm informing you in this message that your use of decimal is disturbing to geeks. Why did you choose to use decimal? I'd really like to know. We may have ten fingers, but we don't even use decimal for time. Decimal is clearly for stupid people. I think it likely that you do not know what radices mean, or else you would be using hexadecimal. Read about hexadecimal at intuitor and repost your comment using hexadecimal. You may use "0x" as a prefix or "h" as a suffix for the numbers. Intelligent people despise decimal--so try to show some intelligence. So do you know what hexadecimal is? Reply to this and prove it, otherwise we will assume that you are stupid.
Personalized message:
How many minutes? Hmm?
There are positions above code monkey? Oh my God it's a conspiracy!
A caveman dreams of being us, the incalculable power and riches. We dream of being Q, then what?
We find there's plenty of people who can talk the talk, but not that many who can walk the walk. After all, if you can't cut code fluently under pressure, then what real use are you where the rubber meets the road </cliche>.
Naturally, I got zero marks for that exam, and went on to take a degree in something completely different, including a Philosophy minor. Immediately on graduating I got head-hunted by the systems engineering department, and within two year was on the academic staff of the Computing Department.
That's fifteen years ago, and I've been getting paid for writing (and teaching people to write) interesting software ever since. I still don't have any computing qualification. The moral of the story: you don't take a course in quill-cutting to learn how to write great literature. In the Computing Department, when I was a student, they were teaching us to write bar-graph generators in PASCAL on punch-cards to be fed into mainframes; in the Philosophy department they were teaching us to write theorem provers and inference engines in LISP and PROLOG (with a side order on the meta-mathematical basis for the designs of the language interpreters themselves) on micro-computers. Guess which turned out to be more relevent in the real world?
I'm old enough to remember when discussions on Slashdot were well informed.
1) Most universities determine the grade in the class by how well you do in relation to your classmates, not by a fixed percentage of correct answers. If you only get 30% right in a test, and you answered the most questions correctly, you get an A. (Unless the professor has a different policy and the tenure to enforce it.) If your classmates are pumping out functionally correct programs on paper, and you aren't, you should not get an A because you "tried" hard to learn the class material, or can regurgitate theory but cannot code for your life.
The tragic reality is that in many competitive majors, you end up being responsible for a ridiculous amount of knowlege in a class, some of which would be more appropriate in an advanced class. This is deliberate; to ensure the people who can regurgitate the most get A's, and the also-rans arbitrarily get B's, C's, etc. "Separate the pre-meds from the med-techs." You should always strive to absorb the most amount of knowlege, but if you can't outperform enough of your other classmates, it means you should be looking for another field of study (and thus career) where you can perform better in relation to your peers. Everyone was not meant to be a programmer or a computer specialist.
2) On a final exam, the professor should not be using as a program question something that would require 500 lines of code. But asking to implement a data structure in code, or a basic algorithm, like a heap sort, should be perfectly reasonable task to be completed in a set time. The professor takes off points in syntax, and your other classmates can code on paper with less errors than you, whallah, they have a greater mastery of the course material than you. They should get the higher grade. An aside: if you can't code in your head under pressure, you have no business picking a career in the computer industry.
3) If you were truly a bright and mature student worthy of a higher grade than your classmates, and you were aware that you have a deficiency with programming on paper, you would PREPARE for the challenge you know you will confront at exam time, not whine that it is unfair. This can easily be done by writing every programming assignment on paper before implementing it in an IDE. Yeah it takes inordinate amounts of time, and yeah, you won't have a reference book in the exam room, but practice makes perfect.
When I went to college, IDE's did not exist. The line editor we used to input code on the mainframe made edlin a pleasurable experience by comparison. It was faster to write programs on paper, and that's what many people did, including your professor. Did this generation wallow in self-pity and not participate in the computer revolution because we had to write our program exams on paper? (And before you get bent out of shape by the presentation of my context, please re-read (3).)
I could blather on forever about exceptional cases, post-primary education, etc. but it can be boiled down to the final clue:
4) Life is unfair, college is a subset of life, and a bachelors degree does not mean the possessor mastered an academic subject. Grow up, make the difficult decisions, do better, and please not let this diatribe be a waste of our time.
There is no America. There is no democracy. There is only IBM and AT&T and DuPont, Dow, General Electric, and Exxon
I got one of these. My second interview at this company was really a test.
I got the description of the program in the morning, they provided a desk,
a pen, some paper and a working machine with visual C++.
The program I had to write was a parser of a file format given in the
description. This included defining the data structures/classes
to store the data.
I turned in the program in the afternoon and the manager giving the test
would review my code at his leisure.
Actually, I thought I had blown it-- the program wasn't actually working.
It didn't help that this was my first time exposure to visual C++.
So it was a bit of surprise to me that they were going to make the offer.
I suspect me putting in good comments in the code was helpful in convincing
the manager that I knew what I was doing...
Later on, after I started on the job, my manager gave me a "warm-up"
project: fix that semi-working program.
One of those days I'm going to find out if any other candidates got
this test and how well did they do.
-cmh
I agree with you 100%. I love interviews, never get worried or anxious, but as soon as I get an 'exam' or written test. I always point out that if they put me in front of a pc I could write the code but some interviewers look at me as if i'm from mars.
seany
I'm also a cs student, I don't love the exams but
solve the problem on paper then on computer. I do get better solutions if I solve a problem on the paper first and then just use the computer as a type writer!
yours
eske
What rimes on recursion What rimes on recursion What rimes on recursion What rimes on recursion
Having been in school a very long time (BSc, MMath, PhD), and having taught for many, many years, I can honestly say that I have yet to see a professor ask a student for "compilable" code on an exam. The instructor wants to see if you can issue a sequence of instuctions that solve a problem ... why? Because if you can't do that you don't have the basic CS skills that you should have in order to graduate with a degree.
The argument about getting a 'vibe' by sitting in front of a computer to program has nothing to do with problem solving. It either implies that you don't really understand what you are doing when you code (i.e., you are writing a solution to a problem - be it on paper or with photons), or that you put zero thought into your code up front.
As for coding tests during interviews, if you can't do one, don't expect to be hired. Simple as that - these guys are trying to find out if you can think - not if you can iterate between editor and debugger to get a linked-list working. If this worries you, practice. It helps. Bone up on your mental ability to reason out solutions before ever comitting a line of code to paper/editor.
When I was a professor, I never took points off for errors the compiler would catch for you. I took points off for theoretical mistakes.
I've been arguing that physics exams, on the other hand, is a major problem for critical thinking. I even had an article in the journal "Physics World" about it.
Employee of Inrupt, Project Release Manager and Community Manager for Solid
I have been writing code for years for open source and commercial applications, so I know a thing or two.
Let me assure you, that doesn't mean shit
Pseudo code is the devil!!!!
How on earth are you suposed to learn to program good code if you don't know how to actually write it? (ie at a computer where you can see: this is readable this is well comented etc.)?
I can at least understand a code test asking you something simple like why was C written or something...
Try having a C++ course assessed *exclusively* on the basis of a multiple-choice test - in the second year, not some introductory thing. It didn't help that at the first tutorial the instructor was unable to get the compiler to function on my workstation. I worked it out after a while (paths not properly set up, if you really want to know) but he would not accept that I could have done that.
I got disciplined for complaining and never went to any more tutorials. I still don't know any C++.
" There is a rational explanation for everything. There is also an irrational one. "
I just completed Java and COBOL courses
Those are some odd bedfellows.
May we never see th
Writing tests on paper is not my strong suit. I've always used a computer since I was 4, and learned how to type before I could write my name properly (teb is still writen on all my papers up till 1'st grade). But when you have a teacher that doesnt know how to program, it doesnt matter whether its on paper or on computers. I had one quickbasic teacher when I was young who had no clue what I meant by a Case statement. she also insisted on using windows 95 machines loaded with every piece of scummware and crippleware you can find, and crashed every 5 seconds. Then, when my friends machine crashed as he was printing, she yelled at him for "ruining" the printer because of a garbled sheet that came out. That aside, there are times when writen tests can be apropriate. My one teacher stressed being able to work the code out on paper. His tests were writen and included code parts where you had to evaluate variable contents or output. For this I can never thank him enough. I am now able to work out what is wrong without a debugger.
When life gives you crap, Make Crapade.
Sluggy Freelance.
I expect a fair number of professors are close to my age (51). When I started, terminals were either unavailable, or too expensive for classwork. I wrote code, on paper, and then went and keyed it on punched cards. Then you turned it in and received the card deck and a listing back in: a few hours, a day, or even a week. A misplaced semi-colon cost you one turn around cycle. You had better be able to proof your work before the compiler gets your program or you will not get your work done in time.
There are still people who think this is the only proper way to program (see Cleanroom process).
What the original poster is telling me is that he is brittle, he can only code when Ares is rising, his favorite MP3 is playing, the sun isn't too bright, etc.
Now preferred conditions are fine, but "I can't code on paper". Fragile, brittle. I like white boards for design, paper for writing, terminals for editting, etc. I've designed on terminals, paper, backs of envelopes, cocktail napkins, etc. I've coded at the key punch, terminal, Starbucks, etc. I've debugged on cards w/ a listing, memory dumps, front panels, hex debbuggers, symbolic debuggers, IDEs, etc. That's what being a professional means. Otherwise you are a recreational coder.
"The only tool a programmer needs is a pencil with a five pound eraser." - circa mid 70's
As second-year CS, first-year AI student i have had quite a few programming exams on paper, aceing them all. If you know a language, be it Java, C++ or Prolog (yummie!), it doesn't matter where you code on, be it paper, an old 386 or a piece of toilet paper, coding remains coding. If you can't get your ideas on papier, in models or source, you can't code, imho.
Now i do agree that coding on a nice workstation is a whole lot faster than on plain paper, but when coding during an exam it isn't about being as fast as possible, but being as neat & secure as possible to get your code right in one go. It's about knowledge, not about speed...
This sig is intentionally left blank
You, sir, Have apparently not seen enough episodes of Iron Chef. Anything... I say, ANYTHING can be made into a sorbet. (probably have to sautee the onions though)
There is also the fact that a large amount of a chef's work is recreating tested (and popular) recipies from memory, in addition to understanding the 'ingredient synergy' that is useful in experimentation. It's hardly the picture of a chef being left to toy with ingredients in the kitchen until something edible comes out, is it?
Honestly, a good chef should be able to stand back and tell other people how to prepare a dish... how many assistant chefs do you think an average resturant-operating chef has?
Actually, I'm beginning to like the chef analogy. Shouldn't the goal of a good programmer to be to set out with his basic tools (keyboard and compiler), recipies (design patterns and algorithms), and ingredients (libraries and other reuseable code) and come up with a correct solution the first time out... basically try to make sure that nothing leaves the kitchen that would displease a patron?
Of course it's not horribly realistic, since current time demands place the software (and hardware) industries more on the time-scale of the drive-through at McDonalds. Still, a good goal for any who would stake claim on the title 'professional'...
Ok this is why it's a good question
given the following code
rteval f(x,.....){
f(x,......);
}
all calling f(x) inside f(x) does is allocate some space on the stack, this stack space can be preallocated as an array, so that a loop can be used instead of a recursive function call..
thank God the internet isn't a human right.
The purpose of an exam is to draw distinctions between those that learned the material and those that didn't. I speak as a (non-CS) professor when I say that difficult exam conditions or "unrealistic" tests are hard, but not unfair. Why? Because even though you (the student) find it more difficult to write code than type code, every other student in the class labors under the same conditions. If you still score worse than your classmates, we can't blame it on the pen and paper (though it may be the case that you're not a good test taker -- but then again, that's always a hazard when trying to measure academic performance).
Make cheese not war 8:)
This topic is less about coding than it is about teaching, learning and evaluating. Every subject matter has its own unique style. Every teacher has his own unique method of evaluating. If we are strictly keeping with writing computer code, did the class teach how to use an ide, were particular data strucures or patterns presented, how tolerent is the teacher of unique programming styles? One class that I attended had a set style guide (deviate and lose ten points; I print in all caps and spent more time correcting to lowercase). Another class asked for pseudo code first so that it became the comments, and bonus points for correct code. Yes, there is always the typical jackoff who can not understand that you used ten lines of code to accomplish his hundred, but is that good programming for a large project where no one else can use your module(job security only goes so far)? My two cents, if you are training people to use a language in a production environment, give them the tools they would have. Multiple projects have always been the best source of improving one's code. Also, don't trust a computer scientist who is afraid to use a computer.
a) What are you doing coding a single chunk of code that's 10K lines long anyways?
b) Any good compiler should be able to take you straight to the line where you forgot the semi-colon.
A Pirate and a Puritan look the same on a balance sheet.
Their 40 GigaBucks have little to do with how they treat their programmers.
A Pirate and a Puritan look the same on a balance sheet.
I'm not talking about coding here, but copyediting and writing copy.
I find it really hard to write well on paper because I'm used to editing as I write.
Of course, all the candidates have the same problem, but surely you want to make your test reflect the conditions of the job? The best candidate when working on paper might not be the best at editing or writing on screen.
With exams, I can see the argument that as long as you don't demand perfect syntax, paper could be OK.
Written exams can be very fair and the results an excellent indication of what you know.
... the list goes on & on. However, he never got the recognition he deserved as an acedemic since his goals of teaching well & being a good engineer kept him from getting his PhD!
The problem is that it is extremely difficult to write such an exam and to grade it ptoperly. At the university level the profs & TAs that are attempting this have NO knowledge of making or grading exams. Their capability, if any, is in the application (e.g. coding). If the university is exceptionally good the profs got a quick intro to teaching, but they still couldn't give a decent exam to save their lives.
I was very fortunate as an undergrad to have had a prof that took teaching seriously. He passed up a PhD in engineering in order to get Masters degrees in teaching and psychology. In Prof Kult's classes you worked harder & learned more, you knew the theory & application, and top grades went to those who knew, not to those who regurgitated material.
He was also one of the most capable engineers I've ever met -- holding basic patents in radar systems, the ECG & other medical devices, digital switching systems, computers
A few years after graduation I had his boss at the University working for me for the summer. I fired the incompetent after less than a month -- he had conned two recent grads that also worked for me into doing his work and passed it off as his own!
"Glory is fleeting, but obscurity is forever." --Napoleon Bonaparte
I'm not going to argue the merits of such testing, everyone here has lots to say. But the reality is that you have to deal with it now and probably again in the future. So here is what I've done for written tests for my programming classes.
Usually the test exams are printed on one side. So what I do is flip to the back and start scribbling/writing code. If the solution is not apparent, I write pseudocode (write something. anything, to get the brain going). If nothing still comes out, then I skip to the next question. Don't waste too much time.
Working on a separate problem will sometimes jog my memory, or may use a similar type solution that gives me some insight to the old problem. Then I will go back and flesh out the rest of the solution on the back. Once everything looks good, I will then flip back to the front and fill in my final answer neatly. This second pass allows me to catch any syntax errors.
I usually avoid writing the answer flat out in final form because often I find that I can optimize the code by leaving out a number of lines, or change the format of my loop, use a different function, or whatever. Or I may realize I have just taken up all the answer space with code that doesn't really solve the problem. So I try to finalize my answer on the back to make sure. And in the event I run out of time, I will just write a note directing the professor to search the backside of the paper for a partial/complete solution to the problem.
Although it may seem difficult/needless, this is a skill that you can learn with practice and can only help you in the long run.
My technique is not perfect and won't make up for lack of studying, but I will often get the highest grade. YMMV. good luck.
I had the same problem. They teach us to use the debuggers and trial and error to our advantage. Then they don't actually let us use it in the end. They teach us the process that we'll actually use in the industry, then they want to to resort to pen and paper for testing purposes. It just doesn't compute.
"what he means is that DeVry graduates are less likely to have rich parents who paid their way through school for them and that enable them to climb the social ladder and attain job positions above "code monkey" easier. "
thats the dumbest comment I've ever read. I go to Florida State University and the state of Florida offers scholarships to almost every high school student who attends a public university in Florida. My tuition is about $300 a semester. My books usually cost more than my tuition. Tuition is no longer an excuse for not going to school....
I programmed various things since 1986, and in all that time I have never seen a project being completed on time.
Contrary to the popular belief, there indeed is no God.
Years ago when I took the AP Computer Science Exam, I failed it. Eventhough I had created numerous programs at home and in the classroom, I just didn't feel comfortable writing the code on paper. Perhaps some revision in testing methods for CS Exams are in order?
Turing is almost a father of CS, and did he actually use a computer?
Yeh the twat even spent a couple of weeks sorting it
Here's my like
1[x 2] = 'aa....a'
2[1 3] = 'aa...b'
3[2 4] = 'aa...c'
4[3 5] = 'aa.....ba'
etc...
say eack node has a 10k string in it,
you may need to search all 10000 nodes,
you'r not looking for the data pointer that matches, you looking for the data,so a log2(n) search is not only possible, but probably faster.
thank God the internet isn't a human right.
If n is the 10,000 elements (that seems like the obvious thing), then this certainly won't be lg(n). I suppose you could be counting something like the number of character comparisons, but if the strings are 10k each, then a sorted list REALLY isn't the right dictionary data structure.
been fast on aritmetic made you a better mathematician?
Sure, life isn't always fair, but in the year 2002, any professor or school that gives a coding exam on paper is not thinking "read world." There is something about the keyboard and the computer screen that helps a computer programmer create code.
A definite "Me, too!" in geisler's direction. They're not out for perfect coding in the exam - it's that you understand how to translate the theory into pseudo-code. My course exams did actually require the odd bit of perfect code in there, but only when they were wanting you to show that you understood certain language features - such as functors or curried functions in ML. Pseudocode was asked for when they wanted understanding of the algorithms or problem solving.
I don't do a lot of programming these days - mainly due to my debugging ineptitude, but when I do I tend to have an A4 pad as an additional tool. There's something about the feel of putting ideas on paper that makes it a lot easier to work through the logic - I rarely stick actual code on the page. Visio just can't handle quickly doodled and scribbled out flowcharts which you then have to unscribble out because "it was right, no it wasn't (scribble), but if I stick this on here..."
In the grand Slashdot grammar flame tradition: you meant "for C driver code, no less". Nonetheless, or nevertheless, means "however". "No less" is the strengthener you were looking for.
I say fire the new hire. If he doesn't love a text approach, he probably won't grow to love it. And if he never loves it he'll never get his productivity up to a very high level. There are plenty of workplaces where he can be comfortable in his IDE orientation.
I can now truly tell that most everyone here is about 15 years old and has almost zero knowledge of computer programming. Being able to work through code in your head or with only a pencil and a sheet of paper is *crucial*. Suppose, for example, you are working on a major piece of software with millions of linesof code that takes an hour to compile. You sure a heck are *not* giong to write some code, compile, test it, change the code, compile, ad nauseum. You would end upgetting fired for being so damn slow. In some shops the practice of "desk checking" code before writing it is still practiced!! This question merely shows an extreme lack of technical maturity on the part of the question asker and the majority of people replying. What a shame.......
Its very simple... what they should do.....
in the real world i have a computer and reference books , and caffine (ok last one not too revelent).... i don't have to write programs without those.... why should people be judged on a system that they will never see when they do get a job...
i have never seen anyone at my company writing software in a room with no computer...
Cruise TT
This past semester, I had the "luxury" of teaching freshman in an intro to C course.
We gave written exams. These exams were designed to be hard because we allowed open books, open notes, print outs, whatever - just nothing electronic. There were typically 8-10 questions where we gave code snippets and required the students to write the output or explain why it would not compile or why it would segfault. The other 3 or 4 questions were writing code snippets. Most of the problems were very similar to ones they had seen in class or on their programming assignments.
While grading, we were forgiving about missing ; and {} as long as the indentation made it obvious where they should have been. We were, however, very unforgiving about function calls because they had reference materials in front of them.
This was an intro programming class where they had (supposedly) learned java the previous semester, and we were merely teaching them the syntax and "style" of C.
The goals of the course were to teach them C syntax and dynamic memory allocation. And the majority of written problems were taken from office sessions. Someone would come in and not know why their code was segfaulting, so we'd put that snippet of code on the exam so that everyone got that experience.
The following semester, they will/would have to write their own versions of malloc, and understanding how to debug code with dynamic memory allocation was one of our top priorities.
With that in mind, we were hard on them on the written exams.
I will agree, that on some CS exams, they can get absurd. You can't do this, you can't do that. But at the same time, it works out problem solving, and there IS a way to solve it correctly.
I personally thought that it's always like Music Theory. In a MT exam, you don't really write any real music, you (for Bourque music in theory 1 and 2) can't write Parralell 5ths, octaves, make large skips, use certain inversions, etc. In real life you do all of these. We study Bach in there, but even Bach breaks these rules constantly.
CS exams are the same way, they are an absurdity of real life, but they teach you a set of rules and logic that apply on any langauge (just as MT can apply to any music but Squarepusher... lol).
I personally have always done fine on CS exams, often correcting the teacher, or even proofreading the exams for lower classes. Still, sometimes, they just aren't fair, and I agree that there should be a little more flexabilty. But again, just like MT, I know people who have played instruments for 30 years who can't pass a Theory exam.
The CS exam isn't about programming, it's theory. It doesn't care if you can program much, just as long as you know the theory and some syntax.
Tibbon
tibbon.com
I'm fairly new to programming, but it is a pain to write a coding EXAM. Being a high school student, I completed an APCS course this year. However, in one day I had both AP english and APCS exams: that's a lot of writing and pain. And eraser dust. Don't get me wrong, I enjoy programming, and often write my code by hand first, simply because it helps me think better. Someone suggested not using an IDE as well as some other solutions... But, in a class, especially for beginners, it often seems that what the instructor uses, you use. And honestly, I have a hard time designing algorithms for my programs. I'm lucky. I sit, type, and voila, a functioning program with maybe 10 errors. I guess if you're inspired, or have had ample time to consider to consider the problem, then writing is doable. But when it comes to exams with extensive coding sections, writing will underestimate skill.
However, I don't care for your analogy. Discovering quicksort is original science. But not all science is original. Better to say that understanding all the theory relating to quicksort -- why it's faster than a pyramid sort, what kind of data impacts its performance in different ways -- is science. Implementing a quicksort routine is engineering. Writing a program that takes the routine and sorts data -- well, I want to call it coding, but that's not quite right.
There used to be people called mechanics. Nowadays that word basically means "repair person". But I think it used to be an honorable part of an important hierarchy. Scientists investigated basic principles. Engineers found practical implementation for those principles. And mechanics made these implementations work in day-to-day life. Nothing wrong with being a mechanic -- I consider myself one. But you shouldn't confuse it with more fundamental work.