Nice write up, being an ex-Microsoftie, I typically hit them with some off the wall questions-
1) You’re a tester on a project, you’re partnered with a developer who doesnt want to work on the project you’re both on. He wants to work on other ‘cooler’ stuff.. What would you do?
I like this question, as you can guage whether they’ll take the “I’d escalate to their boss” type response indicating a preference for heirarchical environments versus collaborative, which typically would result in an answer like “I’d take them aside and talk to them, and explain I’m only trying to help, the sooner we get this done, the sooner we can move onto other things..” type answer.
2) A problem solving task, for example a common technical task like encyrption using public keys, abstract it into a problem that needs to be solved, just to figure out if they have the ability to immerse themselves into a problem. All too frequently testers take a spoon fed approach, which is if its not a requirement identified by a business user in the forms of reams of requirements documentation, then it doesnt exist- an extreme blackbox which seems to be made prolific by certain shops in Melbourne.
3) I draw a square on a piece of paper. I tell the prospect- this is a computer screen. Using as few lines as possible- show me some tests you’d make to test it can work. Each line is made up of 2 dots, in which a line is drawn between them.
I do this kind of test as a test case writing problem. I like to see how creative they get.. are they the kind that just tests that it works? or do they try and break it.. and how?