SDE/Test interview at Microsoft
Chris Sells has a link to a post by
Jason Olson on interviewing for the SDE/Test postion. A few things struck me about the
questions posed for this interview as well as Jasons actual experinces.
- It was for a product code name 'Sparkle', last I heard that was the code name for the Avalon editor (and called by some in the past a 'Flash Killer' - don't got for such branding my self). As such I would be asking questions on testing Avalon its self, how are they proposing to do it, does it dogfood with Burton (mapping up the Avalon APIs to Butrons Unit Testing APIs is the approach I would consider) etc and if not what APIs are they using and why.
- SDE/Test are asked to code and then write tests for the code. I can see why this is done, to test code you must be able to understand how that code works. However, every peice of code is written differently. Even with code standards and a complete design model (e.g. RUP or MDA etc) the actual approach taken by the developer may differ each and every time. So to write tests you will need the ability to write code combined with the ability to know what a developer was thinking when they wrote that code and the spec and standards they were using. Of course with Agile the model changes again, but thats TDD and in that world the tester is the coder, maybe thats Microsofts model?
- One point was changes to the source 1 week before ship and a defect no one is willing to fix.
- One the first point I assume that such changes are allowed. If such a critical defect was found that it was a show stopper (I would be asking why this defect was being resolved so late in the process and what caused the defect) or if a sighed off change request then fair enough but anything else would have be pushed back until after shipping. If your test lead then you would have the authority to push this back to QA who in turn could push back to the business owners, if not then bounched back to your test lead. Either way a process should be in place that could manage this.
- On the second point. Depending on the nature of the defect would state what happens. If the SDE/Test identfies the issue has critical then hopefully a process would be in place that would mean the issue is raised with the program manager and the dev manager can state his reasons as to why the defect is not being resolved. If the issue is not critical then I would expect that the defect remains managed (that is identified and raised as open) and that its sighed off by the dev lead (and I mean written agreement and sighed off). Either way its about process so that test and dev can follow set procedures and project resources and times are not risked.
This is my view point on the role, not saying by a country mile I would actually do any good in the SDE/Test interview but I found other peoples experiences interesting.