For some reason I found myself reading a review of How Would You Move Mount Fuji, William Poundstone's book about questions asked by interviewers at Microsoft Corporation.
The review is pretty standard stuff, the usual mix of summary, ghastly neologisms (``key takeaways''-- really!) and occasional name dropping, and since I haven't read the book I can't really comment on it. But I was drawn to two of Ole Eichhorn's example questions and answers:
First, we explore algebra:
Mike and Todd have $21 between them. Mike has $20 more than Todd. How much does each have (you can't use fractions in the answer).
Right, you think. A simple question. Then we are told,
This question has no answer!
and Eichhorn explains,
Apparently sometimes people ask questions which have no answer to see how candidates react. This might be helpful in some situations (if you're hiring for a company with a confrontational culture!), but I would never use it; I don't like what it says about me and my company, and I can't imagine what it would say about the candidate, either.
What does this illustrate? That Ole Eichhorn apparently doesn't know that dollars are divided up into cents:
m = t + 2000¢;
m + t = 2100¢
m = 2050¢;
t = 50¢
Next he asks (the question is not, apparently, from Poundstone's book):
Consider a pool table with the balls set up for a break. You must write a program which models the table, so you can predict where all the balls will end up. How do you approach this?
This is quite an interesting question, to which he gives a less interesting and rather misleading answer:
First, do they deal all the physical constants out of the deck? Hopefully they can immediately ignore all that stuff, treat them as constants, and move on. When people ask detailed questions about the masses of the balls, pool cue velocity, etc., I get worried.
If he means what he says, that's pretty worrying. Of course, the actual values of the physical constants don't matter in the final simulation, but they are very important in determining how to approach the problem, since like all physical systems this one is controlled by its dimensionless parameters. As a particular example, consider the question of timescales. Three relevant timescales in the problem are
- the time taken for a pool ball to roll a distance equal to its own circumference;
- the time constant of the elastic oscillations in the cushions of the pool table;
- the time constant for the elastic oscillations of a pool ball which has struck another pool ball.
Between the first (say half a second) and the third (say the diameter of a pool ball divided by the speed of sound in nitrocellulose or whatever they're made of now, say about ten microseconds) there is a huge difference, and the size of this ratio, about 50,000, is very important in designing the simulation. Ignoring this suggests a failure to understand the physics involved.
So, we move from physics to implementation, without, apparently, pausing to understand the physics:
Second, do they take an object-oriented approach? To model a problem with sixteen identical balls, six identical pockets, etc., one would hopefully do so... If they don't go there themselves I'll ask ``what objects would you need?'', and ``what are the properties and methods of each object?'' If they can't think about the problem in this way, that's a red flag.
Object-oriented programming is, of course, very fashionable nowadays and it's hardly for me to say that it's a poor choice here. But there is a subtlety that's worth pointing out. Such simulations normally wind up solving big systems of linear equations. This is a representation which, because it loses all type information -- it's just a big pile of numbers -- is quite inimicable to the typical software engineering notions of object-oriented design. Such a program will have a bunch of data representing the physical variables and some code which marshals this into big linear equations which then get solved. The physical variables are then updated from the solution to the equations.
The actual data structures used to do this don't really matter and may well not be an important part of the implementation. Object-orientation is one way to express the solution, but it's not the only one, isn't necessarily a very helpful one for implementation, debugging or understanding, and -- in the context of an interview -- just sitting there and waiting for the candidate to say `object-oriented' or ``I'd start by defining a class CPoolBall'' doesn't seem very helpful.
As an alternative, a FORTRANesque statement like ``I will have nine arrays of length sixteen which store the positions, linear velocities and angular velocities of each ball, and a DO/WHILE loop which computes an interaction matrix based on these'' is an equally valid solution. Should the interviewer reject it because it lacks the object-oriented pixie dust? If you accept the idea that software engineering is like real engineering and therefore that known tried-and-tested solutions are sensible choices for future implementations even if they do not comply with current programming fads, then the FORTRAN approach is an extremely sensible choice which corresponds to historical best practice. Reliable, well-understood FORTRAN simulation programs outnumber C++ ones by a substantial margin.
Anyway, having disposed of physics and implementation, we move to numerical analysis--
Third, how do they deal with time? [...] Ideally they'll come up with some sort of discrete time simulation, where they have an outer loop that cycles through units of time, and computes the new position of each object. If they don't deal with time correctly their solution is incomplete.
-- at which point we're very likely to come a cropper, since all the questions about timescales were apparently ignored in the first part of the answer. In particular, because there is a wide difference between the fastest and slowest timescales in the problem, you must either wastefully run your simulation with a fixed timestep (`unit of time') suitable for the elastic interaction of pool balls, or you must use different timesteps for different circumstances. This is very important and cannot be glossed over.
If Eichhorn's suggested answer is what he expects from a strong interview candidate, I'm at a bit of a loss as to why one would ask it.
Are these good interview questions? Well, who am I to say? I'm not in the commercial software development business now, though thinking back to people with whom I've worked, I don't think that their responses to these questions would divide them by competence particularly effectively. The answers given by Eichhorn aren't exactly shining examples, but that may not be the point either.
There are other things to wonder about here, some of which include, ``Why are Microsoft interview questions such a popular topic?'', all sorts of questions about authority and accuracy which you can read into the above; and, also, why such pontifications irk me so. I'd love to hear your comments.