In academia \u2013 as in many other contexts \u2013 Multiple Choice Questions (MCQs) are a fact of life. We have many situations in which we need to assess a large cohort of learners, and MCQs make this easier.<\/p>\n
Here, I don\u2019t want to debate the value of MCQs as an examination technique in general, but talk about how <\/em>they are written. If we accept that they are part of our work, let\u2019s at least make them not terrible.<\/p>\n There are three very common ways in which MCQs can be obviously bad. I see them all the time.<\/p>\n They are:<\/p>\n Let\u2019s look at each briefly.<\/p>\n The question only examines surface knowledge<\/strong><\/p>\n This is quite an easy and obvious shortcoming to recognise: Often, MCQs just ask questions about terminology. They do not touch on concepts or deeper understanding. This is a very common trap to fall into for people who are not used to writing MCQs. Writing MCQs that test understanding is harder, and it\u2019s easy to slip into the trap of just testing surface issues.<\/p>\n We have probably all seen it.<\/p>\n When you write your questions, examine each question critically in this light. Strive for meaningful questions.<\/p>\n The distractors are random<\/strong><\/p>\n Another very common gripe of mine is that the distractors<\/em> (the incorrect options in MCQs) are chosen at random. Let\u2019s consider an example. Assume we have this question:<\/p>\n Question 54:<\/strong><\/p>\n What is the output of the following segment of code?<\/em><\/p>\n If you speak Java, then you can work out that the answer is 6. So we use 6 as one of the possible options, and add a few random distractors:<\/p>\n Answer:<\/em><\/p>\n In this case, if students have a common misconception, they may arrive at an answer that is not on the list. For example, a student who does not understand that this definition makes the loop increment by 2 might assume that the answer is 15. But 15 is not on the list. So the student is implicitly told that they are wrong, and they can discard unlikely options (\u201cNegative? \u2013 No.\u201d \u201cMore then 800? \u2013 No.\u201d) and make a random guess between a few remaining options.<\/p>\n This question is even worse in a way: Another common mistake is not being able to correctly distinguish between <= and < in the loop condition, and getting the answer wrong because of this. The way the question is written, however, it is not even possible to expose this misconception, because both variants happen to result in the same output!<\/p>\n A badly written question.<\/p>\n The off-by-one way of writing\u00a0<\/strong>distractors<\/b><\/p>\n The other very common pattern I see all the time has an example in this question.<\/p>\n Question 31:<\/strong><\/p>\n \u00a0Which of the following code segment would execute the stored procedure “getPassword()” located in a database server?<\/em><\/p>\n The way questions like this are written is usually this: The question setter writes the correct response, and then creates three distractors by introducing one error in each.<\/p>\n It is trivial to reverse-engineer the correct answer from this. To do this, we spot the differences, and for each differences discard the odd one out. For example:<\/p>\n And voil\u00e0 \u2013 there is our answer: 3. We can do this without any knowledge or understanding of the subject matter. Keep your eyes open for this pattern in MCQ tests. It is astonishing how often you will see this question pattern.<\/p>\n A better example<\/strong><\/p>\n Here is an example of something you could do:<\/p>\n Question 8:<\/strong><\/p>\n When you try to compile and run this code, what will happen?<\/em><\/p>\n \u00a0In this case, the question tests an understanding of how maps work.<\/p>\n This is by far not all that there is to say about MCQ writing. But it\u2019s a start. It is the absolute minimum you should consider if ever you find yourself in the position to write and MCQ test.<\/p>\n","protected":false},"excerpt":{"rendered":" In academia \u2013 as in many other contexts \u2013 Multiple Choice Questions (MCQs) are a fact of life. We have many situations in which we need to assess a large cohort of learners, and MCQs make this easier. Here, I … Continue reading \n
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 int sum = 0;\u00a0\u00a0\u00a0\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 for (int i=0; i<=5; i+=2) {\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 sum = sum + i;\r\n \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 }\r\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 System.out.println(sum);<\/pre>\n(A) 1\r\n(B) 896\r\n(C) 6\r\n(D) -4\r\n(E) 5<\/pre>\n
\n
CallableStatement cs = con.prepareCall(\"{call.getPassword()}\");\r\ncs.executeQuery();<\/pre>\n<\/li>\nCallabledStatement callable = con.prepareCall(\"{call getPassword()}\");\r\ncallable.executeUpdate();<\/pre>\n<\/li>\nCallableStatement cab = con.prepareCall(\"{call getPassword()}\");\r\ncab.executeQuery();<\/pre>\n<\/li>\nCallablestatement cstate = con.prepareCall(\"{call getpassword()}\");\r\ncstate.executeQuery();<\/pre>\n<\/li>\n<\/ol>\n\n
HashMap<Integer, String> myMap = new HashMap<>();\r\n\r\nmyMap.put(2, \"Tiger\");\r\nmyMap.put(4, \"Lion\");\r\nmyMap.put(13, \"Lion\");\r\nmyMap.put(2, \"Elephant\");\r\nmyMap.put(3, \"Chicken\");\r\n\r\nSystem.out.println(myMap.get(2));<\/pre>\n
\n
\n
\n