TL;DR;
The object you create is of type ArrayQueue, because that is what stands right after the new keyword. If ArrayQueue implements QueueInterface, then it declares that every ArrayQueue can be treated exactly as if it were a QueueInterface. This is why you can assign an object of type ArrayQueue to a variable of type QueueInterface. Then on, you use a variable of type QueueInterface to refer to an object that is, in fact, ArrayQueue. Since QueueInterface is an interface, all method calls (myQueue.enqueue("Jim"), etc) on the variable myQueue are actually calls to methods with the same signature in ArrayQueue.
Don't use interfaces for all your variables, this is wrong and evil. Since it is evil, it is done only when it will save your life. Unless you have purpose and a concrete problem to solve, don't use interfaces.
The Long Story
What @DiegoSLTS said is correct, technically.
However, "If you can use an interface or a base class to define a variable you should do it" is correct mostly for certain types of projects, and not in all places.
Scope is important. Methods perform short tasks, and in a short tasks you should be quite certain whether or not to use an ArrayList. Therefore, it doesn't make sense at all to use for a local variable List instead of ArrayList, unless you accept is as a parameter or it comes as a field. The more general a piece of code is, the more difficult it gets to understand.
Using an interface instead of a concrete implementation (class) is only done on purpose - you usually apply design patterns so that other programmers can more easily decipher your intent. A very common mistake is to program in some extensibility (e.g. use interfaces instead of a class) and provide no practical way for your class/module to be extended by clients.
People that teach teach OO in universities are usually scientists, and they publish papers. Code for papers is rarely available even a few years after publication, it is never maintained, and "big" projects for papers are 10,000 lines of code. Also, code is sometimes written by bachelor students or masters, and teams are rarely bigger than 5 people. What is more, researchers are rarely given the chance to analyze or apply their theories on code "in the wild", as companies are keen on keeping their IP.
What I am trying to say is that there is a very big divide between what in theory is good, e.g.
If you can use an interface or a base class to define a variable you should do it. That way, if you found ArrayQueue is not the best QueueInterface implementation, you only need to change one word in the code. It doesn't sound that great (change one word instead of two), but in bigger projects and complex situations it can make a difference, mainlly in the readability and mantainability of the code
and practice. Both researchers and programmers "in the wild" (the jargon they sometimes use for us) agree that complexity is your enemy in software engineering.
What is simple is to be given a task and do it in the simplest possible way. Using interfaces for everything is wrong, because it is needless complexity. We programmers love code that is "good", that we can brag about, and this is why smart hacks and complexity spread like an infectious disease in code. Doing really good code requires you to have the discipline to refrain from adding that fancy design pattern before you need it. This discipline takes a lot of practice.
