I teach comp sci at a community college. I used to get all bent out of shape about plagiarism but it seemed to be a losing battle.
Now all the students in my classes have to demonstrate their lab solutions to me. I ask them to explain the flow of program, point of the tricky bits, etc. I ask them questions like "if you were to change this subroutine/method to add this extra parameter, show me the places in your code where you'd have to incorporate the changes".
I am concerned that the students have learned and understood the material, not how they arrive at the solution. The students are even allowed to demonstrate other people's code if they wish; we discover very quickly how much they know. The demonstration tends to result in much better feedback and interaction between the student and the instructor.
I'm fortunate enough to be in an environment where we can give this sort of personal attention.
I am a community college instructor who teaches a second Java programming class. I used to use the traditional technique of marking individual assignments but found that students used a lot of each other's material, particularly when they became very busy.
I mark a majority of my student labs now by asking the students to demonstrate them. Beforehand, I tell the students that
1) The can use any learning style they want, including copying the work of others.
2) I am most interested in their understanding of the material.
3) I caution them that people who go through the pain of learning through practice are usually more successful than those who look at other's solutions.
4) I encourage the students to work cooperatively, but not just pass on solutions.
5) I tell the students that if they don't know/understand the material they are demonstrating, it will be a very uncomfortable time for them.
During the demonstration I ask the student to
1) Give me an overview of the code.
2) Show me some of the important bits.
3) Describe the flow of the program.
4) Tell me how they would perform a simple modification (I usually have a number of them up my sleeve). This is often the best indicator of their knowledge since making a simple change often means changing code in several places.
In general, I find that asking the students to demonstrate their programs works very well. It allows for immediate feedback and often some extra education, tailored to them. On the drawback side, it can be intimidating for the student, particularly the first few labs, and it is a bit harder to ensure that the marking objective.
Slashdot Mirror
I teach comp sci at a community college. I used to get all bent out of shape about plagiarism but it seemed to be a losing battle. Now all the students in my classes have to demonstrate their lab solutions to me. I ask them to explain the flow of program, point of the tricky bits, etc. I ask them questions like "if you were to change this subroutine/method to add this extra parameter, show me the places in your code where you'd have to incorporate the changes". I am concerned that the students have learned and understood the material, not how they arrive at the solution. The students are even allowed to demonstrate other people's code if they wish; we discover very quickly how much they know. The demonstration tends to result in much better feedback and interaction between the student and the instructor. I'm fortunate enough to be in an environment where we can give this sort of personal attention.
I am a community college instructor who teaches a second Java programming class. I used to use the traditional technique of marking individual assignments but found that students used a lot of each other's material, particularly when they became very busy.
I mark a majority of my student labs now by asking the students to demonstrate them. Beforehand, I tell the students that
1) The can use any learning style they want, including copying the work of others.
2) I am most interested in their understanding of the material.
3) I caution them that people who go through the pain of learning through practice are usually more successful than those who look at other's solutions.
4) I encourage the students to work cooperatively, but not just pass on solutions.
5) I tell the students that if they don't know/understand the material they are demonstrating, it will be a very uncomfortable time for them.
During the demonstration I ask the student to
1) Give me an overview of the code.
2) Show me some of the important bits.
3) Describe the flow of the program.
4) Tell me how they would perform a simple modification (I usually have a number of them up my sleeve). This is often the best indicator of their knowledge since making a simple change often means changing code in several places.
In general, I find that asking the students to demonstrate their programs works very well. It allows for immediate feedback and often some extra education, tailored to them. On the drawback side, it can be intimidating for the student, particularly the first few labs, and it is a bit harder to ensure that the marking objective.