1. Either a tab or a 9 gets displayed. Alternatively, maybe a 6 (or a an ASCII 6, whatever that is) followed by an ASCII 3? This seems unlikely. Or get a syntax error, I suppose, but something tells me that's not right either. I'm going to guess a tab gets displayed.
2. Probably many reasons, but catching typos is good.
3. Grr. I always have to look these things up. Guessing something in the s/\s+$// or s/\s*$// area would do it.
4. Not sure. Guessing one has the scope of both the package and the main script whereas the other is scoped just to the package?
5. Umm...sets $var to the value in the ...uhmm...last element (?) from the @array? Or does it give us the element count? I think it's the value of the last item. Have to look it up.
6. Dunno. Read from STDIN?
7. $a[2][0] (?)

 
So...given how poorly I did on this test, we move on to your request for suggestions.

Frankly, that depends on your goals. Sure, you're trying to assess peoples' skills. But interviews are also partially about assessing them as people. Do you want to make them feel disqualified and test their defensiveness? Or does this part of the interview come at the point where you want them to feel welcome and loosen up a bit? Or do you not play those kinds of games during an interview process?

From a technical test perspective, I don't know that you need to worry about changing it. Just based on how close they come, or if they're willing to indicate where they think they'd go looking first is probably enough to determine if you've got a problem-child or a problem-solver sitting in the hot seat. In my opinion, that's worth more than education when it comes to software development and maintenance. Especially at entry level positions.

Now to go look up the answers to see how badly I did.

:-)