Given the code fragment: `` Deque<String> queue = new ArrayDeque<>(); queue.add("Susan"); queue.add("Allen"); queue.add("David"); System.out.println(queue.pop()); System.out.println(queue.remove())…

Question

Deque<String> queue = new ArrayDeque<>();
queue.add("Susan");
queue.add("Allen");
queue.add("David");
System.out.println(queue.pop());
System.out.println(queue.remove());
System.out.println(queue);

Options

• ADavid David [Susan, Allen]
• BSusan Susan [Susan, Allen]
• CSusan Allen [David]
• DDavid Allen [Susan]
• ESusan Allen [Susan, David]

• A
  5% (1)
• C
  79% (15)
• D
  5% (1)
• E
  11% (2)

Explanation

ArrayDeque.add() appends to the tail, while both pop() and remove() pull from the head - making this behave like a standard FIFO queue. After three add() calls, the order is [Susan, Allen, David] (head → tail); pop() removes and prints "Susan", remove() then removes and prints "Allen", leaving [David] - which is exactly option C.

Why the distractors fail:

• A & D suggest pop() returns "David", implying it pulls from the tail - that's stack behavior (ArrayDeque supports stacks too via push/pop from the same end, but add goes to the tail, not the head, so pop still yields "Susan" first).
• B implies remove() returns "Susan" again, as if pop() didn't mutate the deque.
• E is the trickiest distractor - it gets the printed values right (Susan, Allen) but incorrectly leaves Susan in the remaining deque, forgetting that pop() removes the element.

Memory tip: When ArrayDeque uses add + pop/remove, remember "add to the back, take from the front" - pure FIFO. Only if you used push (adds to front) would you get stack/LIFO behavior.

No community discussion yet for this question.