Most computer science examinations tend to start with the easiest questions and progress towards the more difficult material. Whether this is because of the highly scaffolded nature of the course, an attempt to 'ease students in', or simply by convention, is unclear. However, there is a great deal of data from the psychology literature to suggest that human perception of the difficulty or discomfort of a task is disproportionately affected by the last part of the task completed. Therefore, is it possible that by structuring our exams in an easy-to-hard fashion, we are causing students to perceive the test as more difficult than it actually is? Could changing the question order allow us to change students' perception of their own achievement? What effect could this have on actual performance? This paper attempts to answer these questions by randomly assigning students to write exams ordered either easy-to-hard (referred as 'Easy-Difficult') or hard-to-easy ('Difficult-Easy), then ask them to predict their marks on per-question basis. We find that the question ordering has a small but not statistically significant effect on the performance, and virtually no effect on predicted marks when treating the entire class as one unstratified sample. However, the effect was significant for certain subgroups created via stratification. In particular, swapping the order of the questions may have hurt the performance of international students, but significantly raised both the performance and confidence of female students.

Much work has been done on the achievement gap between code tracing and code writing in CS1 students. The generally accepted explanation for this gap is that tracing and writing form separate steps in a learning scaffolding; students must first learn to trace code before they can be expected to write code. The expectation is that once students have mastered these skills, future grades will be driven by their ability to understand the deeper learning concepts, and so the gap between tracing and writing should disappear. In this paper, we detail and evaluate a study on 384 CS2 students to evaluate whether a tracing-writing gap still exists, and assess whether anything can be deduced about students who continue to exhibit such a gap. We find that not only does the gap seem to have closed by CS2, students are equally likely to show a reverse gap in the writing-tracing direction. However, further analysis shows a strong correlation between students who do continue to have a gap (in either direction) and poor overall performance in the course.

Marking coding exam questions for introductory computer science courses is notoriously resource intensive and difficult to perform consistently. Students can be easily led astray by minor misunderstandings in the wording of questions, and graders often find it difficult to decide whether mistakes are attributable to simple misinterpretations, minor memory errors, or major lack of ability/understanding of the core concepts being evaluated. In this paper we detail and evaluate "Code Mangler" questions. The "Code Mangler" is a fictitious character who manipulates code; removing commenting, changing the order of lines, adding bugs, and otherwise breaking perfectly good code. The role of the student on the exam is then to use the mangled results to reverse engineer the original code. We discuss the benefits of this style of question, and perform an evaluation on a large (475 student) CS1 course, demonstrating that these questions are less resource intensive to mark than traditional coding questions, improve the confidence of the graders, and correlate strongly with student ability as assessed in traditional question styles.

To evaluate the performance of database applications and DBMSs, we usually execute workloads of queries on generated databases of different sizes and measure the response time. This paper introduces MyBenchmark, an offline data generation tool that takes a set of queries as input and generates database instances for which the users can control the characteristics of the resulting workload. Applications of MyBenchmark include database testing, database application testing, and application-driven benchmarking. We present the architecture and the implementation algorithms of MyBenchmark. We also present the evaluation results of MyBenchmark using TPC workloads.