Caliban Darklock wrote this mid-morning:
I start my new job at Infospace on August 4th. I have no clue what my title will be; I’m going to be working in the test department, but also doing some development.
The interview process was grueling. My first contact was my future manager, followed by an aggressive and very bright developer who grilled me on C# concepts and was clearly pleased that he got to move into the more advanced territory.
We had one extensive argument over abstract classes which turned out to be a misunderstanding. I said an abstract class lacks implementation. He said an abstract class might have implementation. I responded that it must lack some implementation, and he insisted that an abstract class could be completely implemented. We argued intensely about this for some time before the equivocation fallacy came up: when I say “abstract class”, I mean a class which has one or more abstract methods. He means a class which is actually declared as abstract, an ultimately arbitrary distinction. Once we figured out the misunderstanding, the argument rapidly turned into vigorous head-nodding and retrospective agreement with one another’s points.
And that was awesome.
Looking back over the two decades of my career, I calculated that I’ve spent approximately 600 hours in interviews. Half of those hours were at Microsoft within the past two years. The end result of this is that I’m perfectly comfortable in interviews - they’re such a familiar experience by this time (occupying roughly half a day out of every week during the past two years), I don’t have any of the nervousness or anxiety I used to experience earlier in my career. I can walk into an interview, sit down, and just talk. I know pretty much what they’re going to ask, what they want to hear, and whether I can provide it. I can even call out my limitations beforehand without worrying about it - “I’m not great at the theoretical parts of OOP,” I said at one point. “Explain what OOP is,” my interviewer responded. “Abstraction, polymorphism, encapsulation, and inheritance,” I replied. He asked about abstraction; I described abstraction. He asked about inheritance; I described inheritance. He asked about multiple inheritance in C#; I said there was multiple inheritance of interfaces, but not classes. He slyly asked whether you inherit an interface, or implement an interface; I replied that this was just syntactic sugar, and under the hood you’re still inheriting. And that’s when he sat up and started asking the hard questions.
Ultimately, we came down to a coding test where I had to rotate a 4×4 matrix with the optimum number of comparisons. I got that question at Microsoft once, and I couldn’t answer it, but armed with the recollection of what didn’t work before - I managed to solve it. (I think the resulting code might actually be useful in a quaternion transform, but I’m not sure; I’ll have to test it.) Since I’ve had this question twice in interviews, I’m not going to give away the answer here, because it’s a tough question that’s both fun to solve and a great representation of abstract thinking.
After this, I was confronted by a member of the test team who looked way too much like Shaggy from Scooby-Doo. He was even wearing that ugly pea-green T-shirt. I had to restrain myself from asking him to say “Zoiks!” just once. His questions revolved around not only creation of test cases, but - in a radical departure from other test interviews I’ve had - how to manage test cases. What if something isn’t in the specification? What if the specification is simply wrong? What if there’s a contradictory requirement? What if management refuses to fix a bug that I’m sure is important? How do your test suites change when switching from black-box to white-box testing? There was the inevitable “how would you test this” question - a calculator, which was somewhat more interesting than Microsoft’s usual “soda can” or “Slinky” examples - where I focused primarily on things that almost certainly wouldn’t be in the specification.
He seemed surprised by this, so I explained at one point that there are many obvious test cases I’d skipped, like “does each number key produce the right number” and “does 5 - 3 equal 2″. Most people can see that a calculator should operate properly as a calculator, but I wanted to concentrate on the test cases that most people wouldn’t consider: impact resistance, battery life, tactile feedback of the keys, stability on slanted surfaces, vibration tolerance, environmental factors. So I did a quick rundown of the generic things any calculator should do, and he appeared satisfied with that.
The lead developer came up next, and focused more on the “soft” aspects of the position. How would I deal with other people, where did I want to go with my career, that sort of thing. He seemed surprised that I’m pointing myself in the direction of project management, and asked why I thought testing was the right route to pursue that. I pointed out that writing a test plan is a project, and managing a test team is a project, and coordinating a test effort is a project, and no matter what specific discipline you happen to choose it is fundamentally composed of encapsulated projects. The abilities and skills used to manage a project in its entirety simply don’t differ significantly from the abilities and skills used to manage the individual subprojects of which it is composed.
Finally, I spoke with my future manager again, who informed me that everyone was impressed but he couldn’t say anything official just yet. I was escorted to the elevators, went down to my car, and called the recruiter handling the position so I could tell him things went well. In the time it took me to reach the car (less than five minutes), they had already called him to make an offer and establish a start date.
I guess they like me. The feeling’s mutual; it seems like a really great company, and I’m sure it’ll be a blast working there.
Filed under: Business, Software
1 Comment