Microsoft’s corporate interview process involves the use of logic puzzles to figure out how you think. It’s intended to be like the Kobayashi Maru test, but with cheap index cards instead of billion-credit battle simulators.

The Microsoft method, unlike the Starfleet version, is very easy to hack.

In my first round of interviews for a full-time position at Microsoft, I was given the old chestnut “You have unlimited time and resources. I want you to move Mount Rainier 6 feet to the north”.

My first proposal was that, given that we had infinite time, we should wait for plate tectonics to do the job for us. That was rejected, but it did lead to a discussion of usable project constraints.

I then harried the interviewer to provide best-estimate constraints.

He responded with one year and $60 billion dollars. As an incentive, I could keep whatever funds were left over.

I asked how he would measure my success. He said he’d stand on the summit with an accurate GPS tracker, and would accept any value within a radius of 2 inches of the desired location.

I proceeded with an analysis of the costs of the project, but I was stalling for time, because I’d had an flash of an idea and I needed to set the stage.

The interviewer kept suggesting dumptrucks, but I knocked that one down, based on the difficulty of slicing Mount Rainier into dump truck-sized cubes, indexing the cubes, and storing them until we reassembled them. Why, the setup alone would take a minimum of 6 months to create the required tools, let alone deploy them!

I then announced my fool-proof plan: a $30 billion campaign of bribery, extortion and assassination at the USGS and Pentagon mapping offices, designed to insure that all GPS devices would, at the end of the project, report that the summit of Mt. Rainier was in the desired position.

It wouldn’t be an abrupt transition, just an accumulating error as one got closer to the summit. All we really needed to do was upload a fiddled software update to the entire GPS satellite fleet, and backed by a Bond-villain budget, we could get ‘er done on time and under budget.

I spent the next ten minutes on the general minion-hiring process and an outline of how to identify and handle the Bribable, the Extortionable, and the (most unfortunately) Expendable target groups, using the USGS bureaucratic structure as an example. I did this one standing up, turning the plan into an actionable flowchart.

The interviewer was somewhat flabbergasted, and took a few minutes to respond. I used the time to ponder my next curveball.

There were the usual objections about legality; I countered with the far thornier legal and practical issues involved in getting permission to move Mount Rainier.

He objected that the GPS and survey maps wouldn’t match. I allowed his objection, and added $1 billion to the project cost for deploying additional assassins and assorted minions to adjust the master cartographical databases at the USGS and Pentagon. All we needed were tiny tweaks in the survey marker data, really. Probably wouldn’t have to get into wet work at all.

He brought up the European and Russian GPS-clone mapping systems. At the time, the Euro-GPS system was years away, so I ruled out that objection immediately. I politely suggested that he, as chief Mount Rainier project manager, needed to broaden his technology reading.

I then went into an analysis of the Russian system. I acknowledged the difficulty of hiring reliable minions in the former Soviet Union and the problem of identifying persuadable targets under a secretive regime; I balanced these problems against the likelihood that anyone on the project could obtain Russian mapping data.

I concluded that, if need be, we could cover the Russian contingency by using at most $2 billion to provoke a serious international incident with Russia, guaranteeing that no Russian data would be available.

I then proposed an alternative.

Would the interviewer like to be $20 billion richer at the end of the project?

P.S. Thanks to my good friend Skry for triggering this post by sending me an excellent article on how to get a job in user-experience design.

From my inbox:

Job Description

The this program is a transformational, strategic supply digitization initiative at , binding software to hardware in an effort to reduce friction in ‘s product key supply chain and reduce piracy on an upcoming release of one of ‘s major revenue drivers.

Problem Uno

Some — in fact, MOST — job inquiries I’ve been getting recently have been from people who obviously have no knowledge of the skills required to fulfill the jobs they’re flogging.

One tell-tale sign of a clueless recruiter is the hurried copy/paste/mangle process they follow when creating their come-on emails.

Problem Dué

Do I want to work for someone who can turn “We’re building an App Store clone” into a boggy swamp of buzzwords?

No, I think not.

One of the worst mistakes any company can make is fracturing their product line in the vain hope of attracting and capturing new audience segments. Doing so almost inevitably causes both the company and the company’s customers to lose sight of the company’s strengths.

One of the ways you can fracture a product line is to treat every SKU in your corporate database as an individual product, give each one a unique name, and use those unique names in the design of your advertising.

Example #1: Apple, Before the Jobsian Restoration

Between 1992 and 1996, Apple fielded no less than seventy-five different computers across fourteen product lines. Some of these allegedly different computers differed only in the bundled software. Others, in different product lines, differed only in the nameplate on the front.

Confusion reigned supreme. It nearly killed the company.

Upon his return, Steve Jobs started pruning product SKUs as fast as possible, and by 1998, he’d famously pared Apple down to a 2×2 product matrix. Laptop versus desktop on one axis, consumer vs pro on the other. Four products. (Three actually, because they weren’t ready to unveil the iBook yet.)

Now, the real magic behind this maneuver wasn’t that Apple settled on four products. It was that Apple stopped attaching dozens of meaningless product names to different configurations of the same computer.

Customers could still order different configurations, which in turn would be recorded under different SKUs, but nobody bothered to apply a grandiose name to each configuration.

Example 2: An American Mobile Carrier, Après le Déluge

One and only one of our ‘Big 4′ mobile phone carriers presents its phone plans as monolithic and utterly confusing conglomerations of features. In order to get something close to your desired plan features, you have to compare 19 named plans (including a new one that beats the other 18 like a drum…until you read the fine print on its limited ‘Unlimited’ data cap).

Some plans offering NO high-speed data cost the same as those with a low amount of data. Some two-line family plans with shared minutes cost more than two individual unlimited-minute plans with the same ‘unlimited’ limited data allowance. (I’m tempted to think that this kind of insanity is intended to drive shoppers to choose costlier plans that don’t have these fairly obvious inequities.)

Meanwhile, all the other mobile carriers sell three to five plans differentiated only by minutes of talk time, treating text messaging and data plans as a la carte add-ons. No bundling, no unwanted features, and only mild confusion.

And soon, the US line of national mobile carriers will be reduced from 4 to 3, thereby solving the problem.

 The Lesson

Sell the razor. The blades will take care of themselves.

A basic design for unobtrusive mobile way finding

Back in 2008, I was following Rachel Hinman’s grand mobile design experiment, 90 Mobiles in 90 Days [images also available on Rachel's Flickr page].

One of her designs involving waving a mobile phone back and forth like a radio tracking device, with the phone signaling when it was pointing along the azimuth to the desired location.

I thought the idea might be improved by a less overt scanning behavior. After all, standing in the street and waving a shiny phone back and forth is Not Recommended Behavior in a number of situations.

This sketch was my first iteration: moving one’s thumb back and forth over the device screen, with a quiet vibration signaling the relative direction of the desired location.

On further reflection, in any built environment (roads, streets, cities), turn-by-turn walking directions would be preferable to mere compass directions.

This breaks down into to two sub-problems: outdoor and indoor navigation. Indoor navigation is by far the harder problem.

Outdoor

This part is fairly simple in a world of detailed city maps. All we need is a five-position arc of pointers in front of the user, plus haptic signals for New Turn, Behind You, At Destination and Not Found.

After that, we just orient the user to a map service’s walking path, and alert them when they have to discover a new direction at a waypoint.

This will get them to the building they want. But how do we help them find their way to an office in a 40-story building?

Indoor

We’re already seeing mobile apps that provide detailed, multi-floor maps of malls across the US. These provide obvious benefits for all tenants of the malls and their current and potential customers. Mall businesses are almost entirely intended as walk-in businesses, so the more traffic the better.

Can the same business mappings be applied to large public and private buildings?

Would the same balance of discoverability benefits apply to non-retail business tenants of office buildings?

Are there countervailing disadvantages in publicizing certain business locations?

[ Haptic Wayfinding on Flickr ]

[ Flickr tags 'wayfinding', 'haptic' ]