by rtpg 4 hours ago
I had to do "write code on paper" stuff as part of french engineering school entrance exams.
It's fine (tho annoying when you lose points to "typos"), but it limits what kinds of problems you can reasonably put on the exam. You'll definitely lean a bit more into theoretical stuff than practicals. Which is fine for some courses, I think a bit less interesting in other courses.
Remember, the hand written code is also harder for reviewers to grade! You have to manually run the code in your head, for example
Having said all that... "we've booked the computer room, you don't have internet, go type up all your stuff in this VM we have set up" feels fine if you don't like this constraint IMO
> we've booked the computer room, you don't have internet
How practical is this?
1. Is your institution able to provide this support?
2. Do you believe you are able to supervise the room well enough that students will be caught if they cheat? (Eg, bring a phone and look up answers.)
2 is “fine”, or that’s just the status quo. The friction from copying over stuff from a tiny phone screen discretely is the cost to cheat as well
I don’t know about 1s practicality. In my schooling it would always be doable but I have the impression US schools are a different scale
Jfc, this is a solved problem at the community college near me. All of the computers in the testing room are thin clients that effectively remote into a vm, and you get checked with a metal detector before going into the room with the computers.
If you can escape the vm on the fly and manage to use an llm to cheat, you deserve that A.
> have to manually run the code in your head
If you're doing a good job, you have to do that anyway, or at least have enough of a spidey sense for broken code to know when to investigate and add an extra test case.
Something like 30% of the time at $WORK, interviewers report the candidate as having solved the problem when a closer inspection reveals UB, memory corruption, and other bullshit. The test cases pass, and I think that's part of the problem. You can't tune out and avoid deeply understanding the submission.
> If you're doing a good job
I think the problem is that the grader has to run your code in their head. That's a whole different problem.
I would imagine every professor (or assistant) who graded any programming exam I wrote was doing just that and further expect them to let some things slide as long as the general direction was correct.
[flagged]