Slashdot Mirror

Otter writes "We've all heard the story of Microsoft's battle cry of "DOS ain't done till Lotus won't run". Adam Barr investigates the myth, interviewing various Microsoft and Lotus old-timers (including Mitch Kapor), and finds no basis for its legitimacy or any case of 1-2-3 actually not running. Whom to blame for Lotus Notes is not discussed."

AdamBa (Adam Barr) writes "Juiced is not a great book. The writing is workmanlike but not particularly entertaining, none of the stories are more than slightly amusing, and its protagonist projects an unappealing mixture of vanity and whining. There is a bit of dirt on players, and a couple of nuggets about Madonna and the sex lives of baseball players (and the intersection of those two), but as a baseball autobiography, it pales besides better competition. And yet, Juiced may be one of the most important baseball books ever written." Specifically, the book provides an insider's account of one aspect of biotech that has achieved widespread use, if not acceptance. Read on for the rest of Barr's review. Juiced: Wild Times, Rampant 'Roids, Smash Hits, and How Baseball Got Big. author Jose Canseco pages 290 publisher Regan Books rating 6 reviewer Adam Barr ISBN 0060746408 summary Canseco used steroids and maybe we should too.

Canseco, for those who spent the last 15 years hidden under a rock, played major league baseball for 17 seasons, from 1985 to 2001. He was most famous for belting massive home runs, but he was also pretty fast: in 1988 he became the first player in history to hit at least 40 home runs and steal at least 40 bases in a single season. For his career he hit .266, with 462 home runs and a .515 slugging percentage. He was a 6-time All-Star, won a Rookie-of-the-Year and MVP award, and picked up two World Series rings.

(How good was Canseco as a player? In his book Whatever Happened to the Hall of Fame?, Bill James presents several methods of estimating how likely someone is to be voted into the Baseball Hall of Fame. On the "Hall of Fame Standards" test, where 60 percent of players with a score of 40-49 have gotten into the Hall of Fame, Canseco scores a 38. On the "Hall of Fame Monitor" test, where a score of 100 indicates someone is likely to get in, Canseco scores an 103. So Canseco may not get elected to the Hall of Fame (and likely won't, after the publication of his book), but a reasonable case could be made that he belongs there. The answer to the question of how good Canseco was is "very, very good.")

What's important about Juiced, especially to the average Slashdot reader who may not know a baseball diamond from the Hope diamond? The answer is buried in the subtitle's heap of verbiage: "Wild Times, Rampant 'Roids, Smash Hits, and How Baseball Got Big." Canseco's book is about the growing user of steroids in baseball, something you hear a lot about today. But Canseco has an unusual opinion: steroids in baseball are not bad; in fact they are very, very good.

Spurred in large part by Canseco's book, the U.S. House Government Reforms Committee subpoenaed some of the biggest names in baseball -- including Mark McGwire, Jason Giambi, and Sammy Sosa -- to testify at a hearing on March 17. Allegations are flying that Barry Bonds was on steroids when he set the single-season mark of 73 home runs in 2001. The typical press reaction to this is one of disgust: words such as "tainted," "artificial," and "cheating" are common.

Not so fast, says Canseco. Steroids in baseball are good. Steroids help players get stronger, and enjoy longer careers. And it's not just baseball players who can benefit: steroids can help almost anyone live a longer, healthier life. His book is a wakeup call not just for baseball, or sports in general, but for all mankind. That's his view, anyway, but he makes a decent case for it, using himself as an example.

Canseco explains how he used steroids (which in this context really means a combination of steroids and human growth hormone) to transform himself from a skinny kid to the beefed up example of manhood that gazes soulfully at you from above a bulging bicep on the back cover of his book. He gained confidence as well, and there's no doubt his ego was pumped up: the book is full of references to how good-looking he is, with some attempts to balance those with descriptions of how ugly he was as a kid.

The book also has a B storyline, which is that the media discriminated against Canseco because he is Cuban, in comparison to the All-American image of Mark McGwire. The current media dismissal of Canseco's claims that McGwire took steroids only adds fuel to his conspiracy theory. If you read the book, you would be hard-pressed to doubt that McGwire took steroids on a regular basis. Canseco is not describing rumor or innuendo; he is talking about obtaining steroids and then personally sticking a needle containing them into McGwire's gluteus maximus, repeatedly, over a period of years when they were both with the Oakland A's, and then later injecting his Texas Ranger teammates Rafael Palmeiro, Juan Gonzalez, and Ivan Rodriguez.

A glance at the rookie cards of players like McGwire and Barry Bonds shows that those guys have put on a lot of muscle since they reached the majors (rookie cards are a good source of pictures since a hitter with no action photos from major-league games usually gets the basic pose of bent elbow, bat over shoulder). A Giambi minor-league card shows a lot of loose sleeve around the bicep. If Canseco is making all this up, he is doing an excellent job, and the fact that nobody is threatening to sue him over the book lends credence to the accuracy of his claims.

Remember, Canseco is not "accusing" anyone of using steroids, in the usual negative sense of an accusation. He is merely stating that people used them, and in fact applauds them, considering it a wise decision both medically and financially. Unlike almost every other media report, Canseco's book discusses steroid use in a factual way, absent the finger-pointing and hand-wringing. He presents steroid users not as cheaters, but as vanguards of a new era of athletic performance.

So how should a libertarian, "I'll believe it when I see it" cynic view the accomplishments of juiced-up baseball players? People are talking about asterisks on records, Hall of Fame bans, revoking MVP awards. Is this reasonable?

It's a fact that in sports where achievement is measured in objective terms, athletes today are much better than they used to be. Yet in sports where opinions are subjective, the older athletes are usually recalled as being better than their modern counterparts. In 1920, the year that Babe Ruth began hitting home runs at a previously unprecedented pace, the world record for the mile was 4 minutes, 12.6 seconds; today it is 3 minutes, 43.13 seconds. That doesn't sound like a huge difference, but if you picture the race as four laps of a quarter-mile oval, as it is usually run, the modern miler would finish almost half a lap ahead of his 1920 counterpart, an obviously dominating victory. Today a good college runner can run the mile faster than the 1920 world-record-holder. It would seem logical to assume that a good college hitter (a good college power hitter, anyway), if magically transported back to 1920, could hit more home runs than Babe Ruth.

Almost any baseball analyst today would laugh at that notion. I think they are wrong; I think a modern hitter, or pitcher, would in fact completely dominate their counterparts from early in the last century (even if you let the pitchers throw spitballs, which have now been banned from baseball, yet their erstwhile practitioners are considered crafty, not cheaters, and their statistics remain unblemished by any asterisks). It's documented that pitchers of yore could mostly take it easy out on the mound. In books like Christy Mathewson's Pitching in a Pinch, it was explained that pitchers could save their energy for the dozen or so times in a game that they really had to bear down.

I'm not saying that Babe Ruth or Christy Mathewson, if born today, could not become great major-league players. They obviously had natural talents that separated them from their peers. What they were lacking was all the knowledge that has been built up over the years. It's not just diet and conditioning -- it's all the miracles of modern life that keep us going. Even up to the 1970s, pitchers could never see video of themselves pitching (a huge advantage in correcting flaws in their pitching motion) unless they happened to pitch in the World Series. Jose Canseco had surgery three times for back injuries, any one of which presumably would have ended, or severely curtailed, his career 85 years ago, yet nobody accuses him of cheating for undergoing surgery.

One of the miracles of modern baseball medicine is "Tommy John surgery", named after the pitcher on whom it was first performed. It involves repairing the ulnar collateral ligament in the elbow using a ligament from another part of the body. A pitcher who undergoes this surgery is not only avoiding a career-ending injury (the linked article above says that Sandy Koufax, who retired due to a self-described "dead arm," is thought to have had damaged UCL). The surgery usually leaves the elbow stronger than it was before. And more than 10% of major-league pitchers today have had this surgery. Are they cheating? Do they need an asterisk next to their records? There is no doubt that in the near future, athletes will undergo surgery not to repair injuries, but to prevent injuries that have not yet occurred. One day athletes with artificial limbs will be relegated to their own Olympics not because they perform worse than their non-bionic counterparts, but because they perform better.

The Olympics, of course, have taken a hard line on pharmaceuticals: popping a Sudafed before the big event will disqualify you. Nobody is suggesting that baseball go that far, but what is the dividing line between steroids and a lot of other substances that athletes put in their bodies? As Jim Bouton points out in his classic book Ball Four, baseball players have long been searching for that extra chemical edge. His diary of the 1969 Seattle Pilots describes rampant use of "greenies," or amphetamines. Bouton expounds further on this topic:

"I've tried a lot of other things through the years -- like butazolidin, which is what they give to horses. And D.M.S.O. -- dimethyl suloxide. Whitey Ford used that for a while. You rub it on with a plastic glove and as soon as it gets in your arm you can taste it in your mouth. It's not available anymore, though. Word is it can blind you. I've also taken shots -- novocain, cortisone, and xylocaine. Baseball players will take anything. If you had a pill that would guarantee a pitcher 20 wins but might take five years off his life, he'd take it."

The issue with steroids, of course, is that they really work. They're not magic: you still have to work out, hard. But you do get stronger, and according to Canseco, even more important is the increased stamina, the ability to hit as well at the end of a 6-month season as you do at the beginning. Canseco also points out that baseball players used to be known for drinking and recreational drug use. But a steroid-user can't afford to tax their liver with alcohol and drugs, and they don't need to mess around with greenies, so Canseco feels that the arrival of steroids also ushered in a time of "clean living" among baseball players.

Canseco presents himself as "The Chemist," the one who did the experiments with steroids, learned how to use them properly, and then passed his knowledge on to others. He maintains that he taught McGwire in Oakland, then Palmeiro, Gonzalez and Rodriguez in Texas (and that McGwire taught Giambi), and when Canseco returned to Oakland, he taught Miguel Tejada. Canseco views the $72-million, 6-year contract that Tejada signed with Baltimore in December 2003 as proof that Tejada made a wise decision to increase his physical ability (although Canseco adds a disclaimer in this case: although he claims to have taught Tejada about steroids and saw him grow bigger and stronger, he did not actually witness Tejada using steroids).

Fans, of course, do love home runs. I saw a baseball game in St. Louis in 1999, and I have never seen an audience so clearly devoted to a single player. The only jersey you saw in the stands was Mark McGwire's number 25. The fans loved him, and the place came alive when he was batting. And when, mirabile dictu, he cranked a four-bagger over the left-field fence, the place went nuts, and I bet every fan felt they got their money's worth. What about those kids, the ones in the stands, when McGwire is revealed to have feet of clay?

Canseco has an answer: we shouldn't worry about those kids having fallen heroes, because in his eyes, they aren't fallen. Furthermore, he accuses baseball's owners and management of being complicit in trying to hush up steroid use, in order to give the fans what they wanted.

Juiced, as mentioned earlier, has problems. Canseco states that young athletes should not use steroids, but beyond a blanket disclaimer at the beginning of the book, does little to discourage teenagers from attempting to emulate the professionals. He gives an unsurprisingly sympathetic and glossy account of his various run-ins with the law: gun possession charge, a couple of domestic violence cases, a bar fight, three months in jail in 2003. He tosses around the names of various steroids, but for someone who claims to know so much about the subject, he gives little background on them: how they were discovered, the legal uses for which they are manufactured, how suppliers obtain them.

But as background reading for today's steroids controversy, and as a potential harbinger of the future of our species, it's worth a look.

You can purchase Juiced from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

AdamBa writes "There has been a lot of discussion of open source bills, but I think open data format bills have a much greater chance of actually becoming law. Over at the Open Data Format Initiative site, I have written an article explaining "Why Open Data Format Laws Are Better Than Open Source Laws". I also have a sample Open Data Format bill; I invite comments from slashdot readers, in particular on how the sample bill could be improved."

adamba writes: "Why are manhole covers round?" "How many gas stations are there in the United States?" "How would you design a remote control for venetian blinds?" "What company is famous for interview questions like those?" You might not know the answer to the first three questions, but you probably know the last one. The notion of asking "Microsoft interview questions," quick logic puzzles and brainteasers, has become accepted wisdom for many technology companies. In comparison, the questions asked during traditional interviews, such as "Describe your typical day" and "What is your greatest weakness?" seem too simplistic, too easy to handle with a prepared answer, too prone to allowing weak candidates to slip through: they simply don't reveal enough about the person. While the Microsoft questions appear to be a better way to evaluate people, the issue has never really been seriously examined. Microsoft's success would seem to make the argument pointless: Can $250 billion in market capitalization be wrong?" Read on for an interesting look at the details and justifications for this kind of interview. How Would You Move Mount Fuji? Microsoft's Cult of the Puzzle author William Poundstone pages 288 publisher Little Brown & Company rating 9 reviewer Adam Barr ISBN 0316919160 summary The scoop on Microsoft interviews--with answers!

Now comes a new book, How Would You Move Mount Fuji? Microsoft's Cult of the Puzzle - How the World's Smartest Company Selects the Most Creative Thinkers by science writer William Poundstone. Poundstone talked to various people who have been involved in Microsoft hiring, including those who were interviewed, and those who gave interviews (full disclosure: I worked at Microsoft for ten years and was one of the people he talked to). He includes a lengthy list of questions, and most interestingly for many people, he also includes answers.

In the book, Poundstone traces the origins of this type of question, providing some fascinating information on the history of intelligence testing. He then chronicles how a certain type of puzzle interview caught on in the high-tech industry. Microsoft was not the first company to ask such questions, but it certainly popularized it.

Poundstone explains that responding to a problem you can't solve could be thought of as the fundamental problem in Artificial Intelligence (AI), and then continues,

"The problems used in AI research have often been puzzles or games. These are simpler and more clearly defined than the complex problems of the real world. They too involve the elements of logic, insight, and intuition that pertain to real problems. Many of the people at Microsoft follow AI work closely, of course, and this may help to explain what must strike some readers as peculiar--their supreme confidence that silly little puzzles have a bearing on the real world."

It could be--or maybe Microsoft employees assume that since they were hired that way, it's a great way to hire (and complaints from those who were not hired are just sour grapes). Most developers I knew thought of AI as a pretty academic discipline, and were more concerned with putting a dialog box up at the right location on the screen than trying to pass the Turing Test.

Nevertheless, as companies seek to emulate Microsoft, the questions have caught on elsewhere. And as Poundstone put it, such questions have now "metastasized" to other industries, such as finance.

This makes the effectiveness of these questions an important issue. Poundstone first presents evidence that "Where do you see yourself in five years" and "What are you most proud of" are fairly pointless questions. In one experiment he describes, two trained interviewers conducted interviews with a group of volunteers. Their evaluations were compared to those of another group who saw a fifteen second video of the interview: the candidate entering the room, shaking hands, and sitting down. The opinions correlated strongly; in other words, when you are sitting in an interview telling the interviewer what you do on your day off and what the last book you read was, the interviewer has already made up his or her mind, based on who knows what subjective criteria. As Poundstone laments, "This would be funny if it weren't tragic."

Puzzle interviews could hardly be worse than that, but it turns out the evidence that they are better is doubtful. Poundstone shows how intelligence tests are on very dubious scientific standing, and points out that Microsoft's interviews are a form of IQ test, even though Microsoft does not admit that publicly. In his 1972 book of puzzles Games for the Superintelligent, Mensa member James Fixx wrote, "If you don't particularly enjoy the kinds of puzzles and problems we're talking about here, that fact alone says nothing about your intelligence in general". Yet virtually every Microsoft employee accepts the "obvious" rationale, that only people who do well in logic puzzles will do well at Microsoft.

There is another important point about puzzle-based interviews: although you would think that they were naturally more objective than traditional interviews--more black or white, right or wrong, and therefore less subject to interpretation by the interviewer--in fact, interviewers' evaluation of answers can be extremely subjective. Once you have formed your impression of a candidate from the enter/handshake/sit-down routine at the start of the interview, it is easy to rationalize a candidate's performance in an interview, either positively or negatively. They needed a bunch of hints to get the answer? Sure, but they were just small hints and it's a tough problem. They got the correct answer right away? No fair, they must have seen it before.

Given the ease with which the answers to logic puzzles can be spun, it is highly probable that Microsoft interviewers are also making fifteen-second judgements of candidates, without even realizing it.

Three years ago Malcolm Gladwell wrote a New Yorker article about job interviews called The New-Boy Network. Gladwell quotes much of the same research as Poundstone, and relates the story of Nolan Myers, a Harvard senior who is being recruited by Tellme and Microsoft. He has done a one-hour interview with Hadi Partovi of Tellme, and spoken to Gladwell, the author, in a coffee shop for about ninety minutes. His initial interaction with Microsoft was much briefer: he asked Steve Ballmer a question during an on-campus event, which led to an exchange of emails.

As Gladwell writes, "What convinced Ballmer he wanted Myers? A glimpse! He caught a little slice of Nolan Myers in action and--just like that--the C.E.O. of a four-hundred-billion-dollar company was calling a college senior in his dorm room. Ballmer somehow knew he liked Myers, the same way Hadi Partovi knew, and the same way I knew after our little chat at Au Bon Pain."

So Steve Ballmer, who obviously does not feel that he is choosing people based on traditional interviewing techniques, and in fact was one of the originators of the "Microsoft questions," is more prone to making fifteen-second judgements than he would probably admit.

The flaw, if any, may simply be in ascribing too much value to the puzzles themselves. The actual questions may be secondary: the company might do as well asking geek-centric trivia questions, like "What was the name of Lord Byron's niece?" That does not mean Microsoft is hiring the same people that an investment bank is going to hire. The cues they look for may be different: instead of a firm handshake and the right tie, they may be looking for intelligent eyes and fast speech, or whatever non-verbal cues ubergeeks throw off.

A Microsoft interview candidate will typically talk to four or five employees, and in general must get a "hire" recommendation from all of them. Even if the employees are actually basing their recommendations not on puzzle-solving ability but on a subconscious evaluation, it is unlikely that all of them will be subconsciously using the same criteria. Emitting the proper signals to satisfy four different Microsoft employees may be as good a judge of a candidate as any, and Microsoft may be good at interviewing simply because it tends to hire people that are similar in some unknown way to the current group of employees. If another company adopts puzzle interviews, they may discover that they are not hiring the smartest people, just the people most like themselves.

In the end, the best thing that can be said about puzzle interviews is that as a screening technique, they are no worse than traditional interviews. And there are some side effects: some candidates may be more prone to accept a job with Microsoft because of the interview style, and imparted wisdom about the technique may function as a useful pre-screening of prospective applicants. And of course, employees may get a kick out of showing a candidate how smart they are, although this can have a downside: How Would You Move Mount Fuji? has several examples of interviewers who seemed more concerned with proving their intelligence than in gauging that of the candidate. One former Microsoftie admits they asked candidates a question they did not know the answer to, just to see what they would do.

Two chapters of the book, entitled "Embracing Cluelessness" and "How to Outsmart the Puzzle Interview," attempt to help interview candidates who are confronted with such puzzle questions. The official advice is scarce: Microsoft's Interview Tips page advises candidates "Be prepared to think," which isn't much help, since presumably nobody is advising the opposite. Some of the recruiters who go to college campuses have their own little tips; for example, one recruiter named Colleen offers a quote from Yoda: "Do or do not, there is no try." Other recruiter tips include "Stay awake" and "Always leave room for dessert." Luckily, Poundstone gives advice that is a bit more concrete than that.

Microsoft puzzles can be divided into two types: those where the methodology is more important than the answer, and those where only the answer matters.

The "methodology" puzzles break into two classes, "design" puzzles ("How would you design a particular product or service?") and "estimation" puzzles ("How much of a certain object occupies a certain space?"--for example, "How much does the ice in a hockey rink weigh?")

Design questions exist because at Microsoft, responsibility for product development is split between two groups, the developers and the program managers. Developers write code: program managers design the user interface, trying to balance the needs of users with the technical constraints from developers. As Poundstone points out, while estimation questions and general logic puzzles are universal, the design questions are reserved for program managers.

The reason is that program management does not require the specific skills of development. Designing software is something any reasonably intelligent person can attempt, so the design questions are aimed at finding people who are really good at design. In fact one program manager I worked with told me that the best way to distinguish a potential program manager from a potential developer was to ask them to design a house: a developer would jump right in, while a program manager would step back and ask questions about the constraints on the house.

(Developers, meanwhile, are usually asked to write code on the whiteboard, an experience that program management candidates are spared. Books exist that discuss coding problems in more detail, such as Programming Interviews Exposed: Secrets to Landing Your Next Job by John Mongan and Noah Suojanen, which covers many standard programming questions and even includes answers to a few of the logic puzzles that Poundstone addresses).

Poundstone does include some of these design questions and provides sample answers. But the "answer" to these questions is really the process involved: ask questions, state assumptions, propose design. That's all you need to know about them. If you are wondering why Microsoft did not use this logical procedure when confronted with the question "Design a response to the open source movement," but instead seems to have spouted off the first five things that popped into its collective head--that's just more proof that performance in interviews is not necessarily a great indicator of future job performance.

Another recruiter, Stacey, gives the following interview tip: "The best interview tips I can give you are to relax and think for yourself. For a Microsoft interview, be prepared to answer both technical and problem solving questions. Ask clarifying questions and remember to think out loud. We are more interested in the way your are thinking through a problem then we are in your final answer!"

That approach works for the "methodology" questions: design and estimation. What about the other kinds--the more traditional brainteasers? For those questions, forget your methodology. What Microsoft interviewers want is the right answer.

James Fixx, writing three years before Microsoft was founded, offers some advice that may hearten potential Microsoft recruits: "One way to improve one's ability to use one's mind is simply to see how very bright people use theirs." With that in mind, we can follow along with Poundstone as he explains the solutions to the puzzles that the very bright people at Microsoft ask during interviews. He certainly delivers the goods: 100 pages of answers. Unfortunately, it's not clear whether seeing those answers help you tune up your brain to answer problems that do not appear in the book.

In his book, Fixx spends some time trying to explain what, as he so delicately puts it, "the superintelligent do that's different from what ordinary people do." For example, trying to describe how a superintelligent person figures out the next letter in the sequence "O T T F F S S", he advises people to think hard: "Persistence alone will now bring its reward, and eventually a thought occurs to him." Talking about how to arrange four pennies so there are two straight lines with three pennies in each line, he writes "The true puzzler...gropes for some loophole, and, with luck, quickly finds it in the third dimension." Further hints abound: "The intelligent person tries... not to impose unnecessary restrictions on his mind. The bright person has succeeded because he does not assume the problem cannot be solved simply because it cannot be solved in one way or even two ways he has tried." This advice sounds great in theory, but how do you apply it in practice? How do you make your mind think that way? As Poundstone quotes Louis Armstrong, "Man, if you have to ask 'What is it?' you ain't never goin' to know."

Poundstone recognizes that the flashes of insight that Fixx describes, and that Microsoft interviewers expect, are more of a hit-or-miss thing than the inevitable result of hard thinking by an intelligent person: "What is particularly troubling is how little 'logic' seems to be involved in some phases of problem solving. Difficult problems are often solved via a sudden, intuitive insight. One moment you're stuck; the next moment this insight has popped into your head, though not by any step-by-step logic that can be recounted."

During interview training I participated in when I worked there, Microsoft would emphasize four attributes that it was looking for when hiring: intelligence, hard work, ability to get things done, and vision. Intelligence was always #1, yet despite this, Poundstone says that the official Microsoft people he talked to would shy away from the word "intelligence", preferring to use terms like "bandwidth" and "inventiveness". Indeed Microsoft's Interview Tips web page says "We look for original, creative thinkers, and our interview process is designed to find those people." No mention of the word intelligence or any notion that interviews are some sort of intelligence test.

In fact, although I think that most Microsoft people would consider the puzzle tests to be mainly a test of intelligence, they may do better at testing some of the other desired attributes. Psychologist and personnel researcher Harry Hepner once said, "Creative thinkers make many false starts, and continually waver between unmanageable fantasies and systematic attack." Poundstone explains that you have to figure out when your fantasies have become too unmanageable: "To deal effectively with puzzles (and with the bigger problems for which they may be a model), you must operate on two or more levels simultaneously. One thread of consciousness tackles the problem while another, higher-level thread monitors the progress. You need to keep asking yourself 'Is this approach working? How much time have I spent on this approach, and how likely is it to produce an answer soon? Is there something else I should be trying?'"

This is great advice, not just for a puzzle, but for a job, and life in general. So watching someone think through a puzzle might be a great way to see how they would tackle a tough problem at work--the "hard work" and "get things done" abilities that Microsoft is also looking for. As James Fixx writes in the sequel More Games for the Superintelligent, "While the less intelligent person, unsure of ever being able to solve a problem at all, is easily discouraged, the intelligent person is fairly sure of succeeding and therefore presses on, discouragements be damned."

Unfortunately, the typical Microsoft interviewer is not looking at the approach to puzzle questions as a test of perseverence. Someone who tries five different attempts might demonstrate more resourcefulness than someone who just "gets it"--but they would get turned down. Interviewers who ask puzzle questions are probing the "intelligence" category, and they want the right answer.

The last chapter of the book is titled "How Innovative Companies Ought to Interview" and deals with a soon-to-be-problem: How will the industry be affected by the publication of this book? Will interviews still work if everyone knows the secrets?

Knowledge of Microsoft-style questions is already out there on the Internet. Since the candidates who participate in the interviews do not sign a Non-Disclosure Agreement, they are free to tell others the questions they were asked, and from these reports databases of questions have been built up. Poundstone includes the URLs of several sites, including Kiran Bondalapati's "Interview Question Bank", Michael Pryor's "Techinterview", Chris Sells' "Interviewing at Microsoft", and William Wu's "Riddles". These sites generally don't include answers, but certainly knowing the types of questions to expect can be an advantage.

Microsoft employees are aware of such sites. Once, when I sent email describing the questions I had asked a Microsoft candidate, I got a nasty reply from someone else at the company: Didn't I know that the question I had asked was posted on a website of known Microsoft interview questions? On the other hand, with no official internal Microsoft list of questions, some employees are undoubtedly using these sites to come up with material. Even within Microsoft there is debate about which questions are reasonable. In an unscientific survey I took of former Microsoft program managers, opinion was divided on the validity of some of the questions. A question described by one person as a good test of a candidate's ability was dismissed by another as foolish.

Poundstone does point out that some questions are silly and should not be asked ("Define the color green"), but he gives serious answers to others which I don't think are worthwhile either, including "If you could remove any of the fifty U.S. states, which would it be?" and "How do they make M&Ms?" Furthermore, I would argue that if an entire class of questions can be "tainted" by How Would You Move Mount Fuji?, they don't deserve to be asked in the first place. Estimation questions might be invalidated by the revelation that the way to solve them was to multiply together a bunch of wild guesses. The strategy of using a design question to to differentiate program management candidates from developer candidates might also go the way of the dodo. Is that necessarily a bad thing?

How Would You Move Mount Fuji? is worth reading even if you don't plan on interviewing at Microsoft. It has some interesting history, a few good Microsoft tidbits, and puzzles that are entertaining on their own. For those considering a job at Microsoft, the book may ratchet up the "arms race" of questions. Microsoft employees may assume that people interviewing have read the book--so if you are going to interview there, or anywhere else that imitates their style, you should probably read it too.

You can purchase How Would You Move Mount Fuji? Microsoft's Cult of the Puzzle from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

AdamBa writes "Speaking to financial analysts and reporters, Bill Gates admitted that .NET hadn't caught on as quickly as he had hoped. The headline ('Gates admits .NET a "misstep"') is a bit misleading; he doesn't think all of .NET was a misstep, just the My Services part (aka Hailstorm). He also said that labelling the current generation of enterprise products as .NET might have been 'premature.' Summary: Microsoft got too excited about locking in users via Hailstorm and botched the overall .NET message." There's also a Reuters report and a NYTimes story on the same subject, which includes the interesting line: "Microsoft also warned today that the era of "open computing," the free exchange of digital information that has defined the personal computer industry, is ending." It isn't clear if Microsoft is talking about something happening beyond their control, or if they're boasting about ending it.

AdamBa writes: "The New Yorker is running an interesting review of the book 'The Myth of the Paperless Office', also discussing 'Scrolling Forward'. Read it and the ever-informative Malcolm Gladwell will explain why paper enables collaborative work much better than computers do, why a messy desk is a sign of productivity, and give a little background on the inventor of the Dewey Decimal System to boot."

With Open Source software projects, understanding why certain features are developed while others aren't, or even why entire projects split apart into contending factions, is often as simple as reading mailing list archives and web sites where the involved parties hash out (or at least air) their differences. Within a large corporation, it's a lot harder. Slashdot reader (and "former Microsoftie") Adam Barr contributes this review of Breaking Windows, which he describes as an imperfect but revealing look into the internal politics of Microsoft, and how clashing groups within the company have struggled to get their vision of Windows on the desktop -- sometimes a messy process.

Breaking Windows author David Bank pages 288 publisher Free Press rating 8 reviewer Adam Barr ISBN 0743203151 summary Tells the story of the battle that raged within Microsoft from 1997 to 2000, between those advocating sticking with the Windows strategy and those wanting a full-fledged shift to the Internet. The Scoop This is one of the best-written books about Microsoft that I have read, and as a former employee I have read most of them. Focusing on the internal battles gives a new perspective on the company. It hopefully shatters, once and for all, the myth that Microsoft is a hive community marching in line behind Bill Gates. Executives and regular employees are shown battling over issues large and small, with a consistent public story emerging only at the end, if at all. Bank also shows how Microsoft's legal strategy in the Justice Department case was affected by the political and technical battles that were simultaneously going on within the company. What's To Like The book does a great job of telling its story efficiently and clearly. Bank quotes from internal emails, but doesn't overuse them, preserving the value of these rare glimpses into the Microsoft decision-making process. He gives just the right amount of history, and avoids ill-fitting analogies to describe the various pieces of software (in most cases he simply gives a minimal explanation, which might confuse a computing novice but is perfect for a typical Slashdot reader). He also describes the right reasons for Microsoft's success: not marketing as many people say, but its strategy of defining a small number of software platforms and evangelizing them to other developers.

The battle being fought here is between the "Windows hawks," led by Microsoft Vice President Jim Allchin, and the "Internet doves," led by another Vice President, Brad Silverberg. Allchin was in charge of Windows NT; Silverberg shipped Windows 95 and early versions of Internet Explorer. The book has some great insight into how this battle proceeded and why the participants acted as they did.

For example, the book discusses Jim Allchin's famous email in early 1997, in which he discussed competing with Netscape and wrote, "I do not feel we are going to win on our current path -- I am convinced we have to use Windows, this is the one thing they don't have -- We need something with more Windows integration." This email was brought up in the Justice trial to show that Microsoft used browser integration to unfairly attack Netscape, but the book shows that Allchin at the time was trying to counteract feelings within Microsoft that the browser was all that mattered, and was therefore concerned not so much that non-integration would hurt the browser as he was concerned that non-integration would hurt Windows.

Or consider the following sentence from the book: "In the same way that Gates began to view Microsoft's Internet team as the internal representation of Netscape, he came to see Microsoft's Java team as the internal agents of Sun Microsystems." This is an extraordinarily perceptive statement, and the fact that a reader can appreciate its meaning 74 pages into the book is a tribute to the explanatory powers of Bank's writing.

What's To Consider If the terms "Internet doves" and "Windows hawks" didn't tip you off, Bank is trying to show that the "fumble" of the subtitle occurred in 1997, when Bill Gates decided against supporting a Microsoft project known as Megaserver. This would have been a platform for Internet development: a set of back-end services, tied in to the browser.

Bank also discusses another, more well-known "fumble," the mismanagement of the Justice Department lawsuit. His writing here is still excellent, but this topic has been covered elsewhere so the information is not as surprising.

In the Justice lawsuit, he does a good job of showing how Gates was the main force behind two of Microsoft's poorest showings in the case: Gates'evasive videotaped deposition, and the response to the judge's order to allow computer manufacturer to ship Windows 95 without Internet Explorer (which involved allowing them to either ship a two-year-old version of Windows 95, or one that did not work at all).

In fact Bank spends much more time talking about the legal foibles than talking about his first argument, that Gates blew his role as technical leader of Microsoft by not endorsing Megaserver in 1997. But this really needs to be the core of his argument: saying that Gates' main mistake was made in the legal arena, in which he was a novice, is not nearly as compelling as claiming that Gates, the ultimate geek, botched the kind of technical decision that should have been his strength.

Megaserver was a Brad Silverberg project, and Jim Allchin was the main opposition. In Bank's mythology, Silverberg is the hero, pushing for the Internet. Allchin is the villain, sticking with Windows. But what really went on here?

Consider a story Bank relates from a Microsoft developer named Ben Slivka, one of the most strident of the Internet doves:

Slivka recounted the experience of one Windows developer who presented Allchin with his ideas for a simply, reliable operating system suitable for home users. Instead of saying "Great idea, go do it," Allchin had insisted that the new operating system be based on Windows NT. The developer objected that the huge NT operating system wasn't suitable for the drop-dead simple appliance he had envisioned. Allchin challenged him to list the parts of Windows NT he would strip out.

To me this looks like Allchin is doing his job. What would happen if he authorized everyone who so desired to go off and write their own operating system? I/ll tell you what would happen: Windows CE. Enough said.

Allchin also had little patience for Microsoft employees who were advocating a move towards Java and free software:

I don't want to be remembered as the guy who destroyed one of the most amazing business in history. We could have done it [meaning we could have destroyed the business] with engineers who didn't understand and didn't have any responsibility for the financial aspects of the company at all. Who live in this paradise where the stock goes up, revenues keep going up, earnings keep doing up. And all they have to do is crank software. Somehow it gets into packages and makes money. Well, it doesn't work that way.

Sounds reasonable to me. The notions of first-mover advantage and trading profits for users have been discredited in the dot-com meltdown. But the quote doesn't fit into Bank's view of Allchin as the bad guy, so he simply throws it out there, with no discussion.

History is often written by the winners, but in some ways the middle of this book is history written by the losers. The path not taken is discussed, but since it exists only as a perfect creation in the minds of its inventors (who obviously had Bank's ear when he was doing his research), it is depicted as flawless. Statements claiming that the new goal "was not to get thousands of developers to adopt your arcane PC programming interfaces but rather to get tens of millions of users to use your services every day=94 are accepted as holy truth.

Bank is convinced that Megaserver would have somehow "expanded the commons" of software development, that any Internet platform would have been an open platform. But consider what the Megaserver would have been as proposed back in 1997: A set of Microsoft servers with Microsoft data, talking to a browser that was customized to talk to those servers.

In short, it would have been a clone of AOL. Furthermore, this would have been architected by the team that brought you Windows 95. Would this have been a good thing? Does integrating your browser with your Web servers produce a more open environment than integrating it with your operating system?

Thus, it is hard to fault Gates for not supporting Megaserver in 1997. In fact, Microsoft is now pushing heavily towards .Net, which is the 2001 version of Megaserver. Why support it now? As Bank himself writes, about Microsoft executive Paul Maritz, "He had long known the problem was bigger than Win32, Maritz said. But now he could articulate the message. The difference, he later said, was XML." It was not so much that Microsoft did not recognize the need to move beyond the Win32 API; it was that in 1997 it didn't have the technology to do so.

Bank makes the claim that Gates was forced out as CEO because of his "fumbles." This is arguably the big revelation in the book, but it is hard to prove this conclusively: The trial missteps certainly did happen, Microsoft was drifting from a technology perspective, and Gates stepped down. Did he fall or was he pushed? The timing of events supports either conclusion. In any event, I found the behind-the-scenes descriptions much more interesting than this particular allegation.

Furthermore, Bank points out that Gates allowed an employee to set up a hands-off incubator within Microsoft that eventually led to the company-wide adoption of XML and .NET, and was the only top executive who really understood the .NET protocols. Thus it is hard to fault him for not supporting an Internet platform in 1997, when he planted the seeds for an Internet platform in 2001.

If the middle of the book is imperfect but still fascinating, the last chapter gets really strange. After playing Brad Silverberg up as the hero, Bank suddenly cuts him down. Earlier in the book, the decision to adopt Active Desktop in Windows 98 is mentioned, but with mysterious silence on who made the final call; it merely states that after seeing Netscape demonstrate a similar product called Constellation, "the browser team was given the additional job of creating a shell for all of Windows." That shell was Active Desktop, and this particular decision got Microsoft in antitrust trouble both because it increased the amount of browser integration that Microsoft had to defend in court, and because Microsoft started leaning on computer manufacturers in an effort to freeze out Netscape's product. Furthermore, the battle was basically for naught since Channels, the big Active Desktop feature, went nowhere. Gates himself said later, "That's a case where the browser guys, they had the Internet religion, but they pushed it too far in terms of what was a practical user experience."

So who decided to go with Active Desktop? You figure it had to be Silverberg, but Bank doesn't say that. In the final chapter, however, he slips a bit, pointing out that Silverberg's team was responsible for the tying of the browser, the semi-exclusive contracts with content and access providers, and the war against Java -- the main issues that the Justice department sued over. Furthermore, if the Megaserver strategy had been pursued, Microsoft might have been in even more legal trouble.

Gates, meanwhile, gets rehabilitated in the last chapter. His tactics in 1998 and 1999 are now described as a strategic stall, waiting for the right technology to appear for Microsoft's Internet platform: "The power to control the pace of innovation is a competitive advantage at least as crucial as the ability to innovate itself." Gates is portrayed as a leader once again, planning strategy ten years out, and the book ends with a prediction (for no reason other than the author's gut feeling) that Gates will do the right thing and usher in a new age of innovation, whatever that consists of.

I'm not sure what to make of this flip-flop. I assume this book was originally proposed to a publisher in 1999, written in 2000, and polished up in early 2001. In 1999 a book about the demise of Microsoft seemed a plausible undertaking, but two years later it turned out that the story wasn't over, and Microsoft appeared to be bouncing back. So Bank had time to equivocate, modifying his original thesis and explaining how perhaps Microsoft had a future after all.

Describing this latest turn of events, however, Bank doesn't have reams of email released during a trial, or sympathetic former Microsofties to interpret it for him. As a result, he can fire off sentences like, "The infrastructure for the digital age will be based on competition on the merits and a common code of open interfaces," with apparent complete sincerity. He believes that Microsoft asking AOL to open its Instant Messaging protocol is a harbinger of this golden future, and that Microsoft's Shared Source program shows it is moving towards open source. In short, he is buying the current Microsoft PR story, hook line and sinker.

Well, let this former Microsoftie (and former Windows hawk who worked in Allchin's group) explain a few things. Statements like "Interoperability, not lock-in, has become the winning strategy" are patently false. Right now there are two Internets: The AOL one, with its own client, servers, content, email, messaging, authentication, billing, security, and all the rest; and the plain old Internet. Microsoft wants to create a third Internet, the .NET Internet, with all the stuff that the AOL Internet has. Then it will pursue a lock-in like the world has never seen before.

Summary and Table of Contents But hey, enough quibbling. Bank may be wrong about the future of Microsoft, but he does a fantastic job covering the past. I spent some time discussing what I disagreed with, but there is so much more that I agree with. I knew about a lot of the events that are described in the book, but I still learned an incredible amount. If you want to know what things are like inside Microsoft, buy this book. Table of Contents

• Prologue: The E-mail Trail

1. Track the Inevitable
2. Hawks and Doves.
3. The Path Not Taken
4. Citizen Gates
5. Vicious Cycle
6. Monopolist's Dilemma
7. Loosely Coupled

• Key Dates
• Notes
• Acknowledgements
• Index

You can purchase this book at Fatbrain.

Danny Yee popped up this review from down under of the provacatively titled Proudly Serving My Corporate Masters: What I Learned in Ten Years as a Microsoft Programmer . This sounds like a fun read, but not without flaws.

Proudly Serving My Corporate Masters author Adam Barr pages 342 publisher Writers Club Press rating 8 reviewer Danny Yee ISBN 0-595-16128-6 summary What Adam Barr Learned in Ten Years as a Microsoft Programmer

Barr worked as a low-level developer at Microsoft and his account in Proudly Serving My Corporate Masters, built around his firsthand experience, offers a perspective on the company "from the ranks". This is combined with more general commentary on recent computing issues, with reflections on evangelism, community, and open source. The result has something for a range of people: those curious about Microsoft, involved in debates about the merits of open source, responsible for recruitment and management of programmers, or just interested in computing history.

Barr begins by describing how he came to work for Microsoft. This is the start of four chapters on Microsoft's recruitment system, covering both the initial selection on campus, the interview system, and the overall effectiveness. There is also an introduction to how work is structured at Microsoft, in particular the division between developers, program managers, and testers. Three chapters then describe Barr's time at SoftImage, a Microsoft acquisition producing digital editing software. Here we are introduced to the different types of "demos" (from carefully scripted sessions presented by special "demo artists" to genuine "hands-on" demos) and the complexities of dealing with third-party hardware suppliers.

Three chapters then present a potted history of computing over the last twenty years or so, beginning with an account Barr wrote as a teenager back in 1982, after visiting ComDex. Barr focuses on evangelism - on the factors that contribute to one platform or operating system winning out over others - and in particular why IBM PC hardware became ubiquitous, why MSDOS beat CP/M-86, and why Windows beat OS/2. None of this is particularly novel, but it's a nice lively account.

This leads naturally to more recent conflicts and debates which pit (as flagship icons) Microsoft against Linux. Again, there is nothing spectacular here, but Barr offers an intelligent, informed, and balanced perspective, coming up with some points that were new to me. Of the claim that it will be difficult to find programmers to do the "unsexy" work with Linux, for example, he writes

"Microsoft, being a company with salaries and a supervisory hierarchy, has the ability to order someone to work on something he or she doesn't want to work on, but I never recall this happening. People worked on things that interested them and projects still got complete coverage. There is no reason that the same should not be true of Linux, especially given the size of the Linux community."

Two chapters evaluate attacks against Microsoft, the first addressing popular criticisms and the second the various legal attacks. Here Barr is level-headed, calmly rebutting some of the sillier attacks while accepting valid criticisms.

A major weakness of this material is that Barr only ever talks about "open source" (a development methodology) and never about "free software" (a much broader movement). One major reason for techs ranting at Microsoft is their unhappiness with loss of choice, freedom, and control - and this has been articulated as an ethical and political position by the Free Software Foundation and others. But Barr never considers this argument against Microsoft at all.

A chapter on online community is really a digression. The final two chapters then consider the future of Microsoft. Barr argues that Microsoft should stick to its core PC business and not get distracted by ventures such as the XBox. He ends where he started, arguing that the key to Microsoft's future lies in its handling of employees, in its ability to attract, recruit, and retain good people.

Proudly Serving is nicely laid out and has obviously been carefully edited. Barr avoids most technical details (an exception is some discussion of buses and video hardware in the chapters on SoftImage) and offers separate digressions on Code, APIs, and Middleware. A minor complaint is that the workings of Microsoft stock options are only explained in the last chapter, by which point the reader will either have worked it out for themselves or decided they don't care.

Purchase this book from FatBrain. Visit the author's web site or check out Danny Yee's five hundred other book reviews.