How Not to Give Magazine Interviews
Intel faces a perennial problem: How much access should magazines, TV, radio, and Web site gurus be granted to techies and geeks? A supplementary problem is how to train the technical talent to understand that blurting out the entire truth to a question is not the only option.
Old jokes often contain old truths. A hoary engineering favorite is the one in which three convicts are in line to be executed, the third of which is an engineer. The first puts his head in the guillotine and the executioner pulls the lever, but the blade gets stuck halfway down. Because of some ostensible double jeopardy principle, the convict walks away a free man. The second convict puts his head in the guillotine, the same thing happens, and he also walks away. Then the engineer walks up, but before he puts his head on the block, he points to the track of the blade and says “Hey, I think I see how to fix where that blade is getting stuck.”
Randy Steck and I spent a few days entertaining various magazine editors from all around the world, giving interviews on the design, the team organization, and other topics of interest. Many of these interviews ended up being published in languages neither of us could understand, so I never did get to read what they quoted me as having said. I hope it was intelligent. But I have had many occasions to read the raw transcript of a speech I had given or legal depositions I have made, and they always make me cringe. I often wonder how anybody gets any coherent information out of what looks to me like quasirandom walks through various idea spaces, separated by nonsequiturs and expostulations. Maybe they just like the panache with which I attempt them.
At one magazine interview, I decided to take a break while interviewers kept talking to my Intel compatriots. As I headed for the door, I heard the questioner ask about our PowerPC competitors (which were very new at the time): “How do you think P6 will fare against the forthcoming PowerPC chips?” As I walked past, I thought, “Who cares how fast any chip is if it cannot execute the right kind of code?” The next day, I saw that quote in the newspaper and realized I hadn’t just thought it; I had said it aloud, and they had heard it. I wonder how my PR handlers at Intel would have felt if they had known that that quote was as big a surprise to me as it was to them.
Someone from the Wall Street Journal was interviewing us later that day, and asked what we had done as a result of corporate’s learning about the FDIV flaw. Without thinking (enough, anyway) I said, “We learned many things about the public and its relationship to technology, and we realized that as bad as FDIV turned out to be, it would be far worse if Intel made the same mistake twice. So we pounded the crap out of the floatingpoint units in the P6.” Naturally, that’s the quote they ended up using, and it was sent over the wire services to a huge number of local newspapers, including ours. Some friends bought a new hammer, wrote “craphammer” on its handle, and left it on our front doorstep. My mother saw the papers and threatened to wash my mouth out with soap. I guess it just does not pay to get too technical with the noncognoscenti.
Speech Training
As the P6 project was winding down, our general managers had the great idea that we should prepare the project leaders to give coherent public presentations. They hired Jerry Weissman [11] to tutor four of us for a week on how to structure our foils and deliver them for optimal effect.
Jerry was a great coach. He had all of us do a quick presentation that was videotaped for later reference. Then he began working on us. He correctly noted that most technical presenters are deadly dull, believing their job is to inundate the listener with data and to pack as much as possible onto each Powerpoint foil. If the foil will not accommodate all the data, they use a smaller font size. Yet, as Jerry pointed out, none of us actually like to sit through such presentations.
We had all been to technical conferences and the universality of Jerry’s truths was selfevident. Jerry suggested that even technical folks like a good story and that no one was going to remember all the data anyway. He advised us to pick the one or two major ideas we hoped we could get across and then structure the talk around them. He had numerous suggestions for structuring the Powerpoint foils. No more than four bullets per foil. No more than four words per bullet. Place words so that they enhance the graphic, not obliterate it. Build the foils so that the sequence makes sense.
He also had dozens of great ideas on how to present the story. Do not grip the podium; it makes you look like you are scared. And do not hide behind it. Let the audience see you. When they sense your mastery of the material, they will relax and accept the message better.
Jerry also stressed practice. He suggested that we practice our talks in the shower, while driving, while eating lunch, in front of friends, in front of coworkers, in front of strangers, in front of pet iguanas in front of any entity that will sit still long enough.
It was decided that we would introduce the P6 at the IEEE’s 1995 International SolidState Circuits Conference (ISSCC ‘95), a kind of Superbowl for microprocessors, and that I would be the presenter. I had attended many conferences, but never that one, so I did not know quite what to expect. But I definitely said a silent thanks to Jerry and my own general managers for having put me through this training, because I soon found myself alone on an enormous raised platform in front of 2,000 conference attendees, wearing a wireless microphone headset. I felt like Madonna but with a lot more clothes.
My talk followed those of a few others, who had described competitors to Intel’s products, and who had obviously not taken Jerry’s class because they did that techie datadump thing. The session chair introduced me and I walked behind the podium. Then I walked around it and stood next to it, per Jerry’s instructions. Out of the corner of my eye, I could see that this action had startled the session chair, who got halfway out of his chair, presumably to address the problem he thought I had or to give this idiot speaker some additional instruction, since the dummy obviously did not know he was supposed to stand behind the podium. I launched into my talk, and he resignedly sat back down, the emergency averted.
At several points during my presentation, audible gasps circulated through the room; they were among the most gratifying sounds I have yet heard in my career. One of these occurred when I pointed out that we had made the P6 an intrinsically multiprocessorcapable engine; all you had to do was connect a second (or third or fourth) socket to the pins of the first one and install another P6 chip in it. Another occurred at the end, when I pointed out that I had prepared the talk on a P6 system. This told the technically astute in the audience that P6 was already healthy enough to run Microsoft’s Powerpoint application, and the only way to run Powerpoint was to run Windows first. With that single remark I had given them a lot of information that led to one conclusion: The project was very far along. This out-of-order stuff was working.
I have been grateful for Jerry Weissman’s training on other occasions as well, in particular, at the Microprocessor Forum. I have presented at that conference a few times and it was always a surreal experience. Instead of sitting in the audience and listening to previous speakers before taking my turn, I was kept backstage, like a rock star before a gig (or a convict as the engineer in the joke above was repairing the guillotine). If that were not bad enough, I had to speak immediately after AMD’s Jerry Sanders on one occasion, which meant that we briefly occupied the same cramped space, much to my amusement.
After being introduced, I discovered that the monitor I was supposed to use to see what slide the audience was seeing was almost invisible from where I stood because of the in tense glare of multiple spotlights trained squarely in my eyes. I could not see even one person in the audience, much less discern the real-time feedback the audience normally provided. If that were not bad enough, I next found that if I turned my head even slightly, out of the corner of my eye I could see a 20-foot image of my own face, tracking my movements in real time. It was incredibly disconcerting, and if I had not practiced my talk so many times that I had memorized it, it would been very difficult to stay on t
ask. I do not know how Mick Jagger does it.
Trash-Talking Helps the Opposition
My antipathy to AMD’s Jerry Sanders stemmed from interviews he had given in 1995, in which he had opined that “The reality is the (P6) is inferior to the Pentium…. The Pentium is a better part” [36]. I didn’t much care what his technical opinion was of the P6, but what he said next, I did care about. “The guys who conceived of the Pentium were better than the guys who conceived of the P6.” It doesn’t matter which guys were truly “better,” and Sanders’ opinion on it mattered even less. What got my attention was that the CEO of a rival company had decided to not just trash the P6, but to personally attack its designers as well. Why he thought that was appropriate or useful to AMD, I could not guess, but I took it personally and decided to do with that quote what sports teams do with trash-talking by their rivals: they post the quotes in the locker room for additional inspiration. So maybe I should thank Mr. Sanders, because in the wee hours, when I was tired and wanted to quit for the night, I would see that quote on the wall and feel reinvigorated.
6
THE PEOPLE FACTOR
Good people aren’t good because they never cause harm to others. They’re good because they treat others the best way they know how, with the understanding that they have. Too often in our public life we condemn people for well-meant errors, and then insist that everyone should forgive people whose errors were intentional and who attempted, not to make amends, but to avoid consequences. Good and bad have been stood on their head by people who should have known better. How do we live in such a world?
-Orson Scott Card, Rebeka
To say that the P6 project had its share of people issues would be an understatement. Any effort that combines extreme creativity, mindbending stress, and colorful personalities has to account for the “people factor,” the simple idea that people will say and do just about anything given enough time. The people factor is probably the least understood aspect of hardware design, and nothing you learn in graduate school compares with what a day-today, long-term, high-visibility, pressure-cooker project can teach you about your coworkers, or yourself.
I considered filling this chapter with sage advice about managing and coping, but I ended up mostly relating stories of stuff that worked and did not work. I am confident the reader will draw the appropriate conclusions.
HIRING AND FIRING
The 1990s were a period of very strong growth in Intel’s workforce. Early in the decade, the company had around 22,000 full-time employees; by 2000, the number had quadrupled.
Our design teams were growing, too. The inexorable march of Moore’s Law made ever more transistors available to chip designers, but schedules were not lengthened commensurately, and though design tools were improving, they did not make us twice as productive every 18 months. In other words, we were falling behind, and we compensated by hiring more help. Design teams as large as Intel’s-hundreds of engineers, tools designers, and layout experts-require a highly organized, disciplined process for hiring, forming, and managing the team.
Rational Recruitment
Approximately half the P6 and Pentium 4 design teams were recent college graduates (RCGs) when they joined us. Hundreds of RCGs were walking around who not only had never designed anything, but also had never held a full-time professional job. On the surface, this probably seems a little crazy.
I would like to think our recruitment scheme was solely responsible for our stellar selection of RCGs, but I know better. Still in all, it worked well enough for us to staff both the P6 and Pentium 4 projects with hundreds of engineers, and we were justifiably proud when many of those RCGs went on to have very successful careers.
Part of our recruiting scheme’s success is that it was impressively rational. We began by fishing in the steady stream of resumes made available by the company’s usual campus representatives, and farmed out the most likely fits to the project leaders. Design engineers would phone screen the candidates for 30 to 60 minutes, essentially checking for a match between the candidate’s knowledge and the resume’s strong points. About half the phone screen candidates who passed were invited to Oregon for a site visit.
Those interviewing the visiting candidate had two goals: Sell the candidate on Intel, the team, and the merits of living here (not at Intel, but somewhere nearby; we did not want to scare them), and assess their ability to do the work and the candidate’s fit with the team. We had cleverly isolated six major technical areas-architecture, microarchitecture, software, logic, circuits, and layout and determined that successful candidates should be expert in at least one. A design team expert from one of the six areas then spent an hour with the candidate, gently probing his or her knowledge and training. The interviewer scored the candidate’s knowledge of that area from 1 to 10, with 1 being clueless and 10 being world-class expert. When the expert in that area was finished, the candidate would move to the expert in the next area, and so on. By the end of the interviewing, we had six scores for each candidate.
Few candidates scored at either extreme; middle scores between 3 and 7 were by far the most common. For calibration, we routinely reminded interviewers that 5 was supposed to be the mean score expected of a candidate. Most candidates would score very well on one or two areas, relatively poorly on one or two, and middling on the rest. If the personality fit was good, such candidates could expect a job offer.
The interviewers would meet to discuss the candidate, and occasionally, one would say, “This candidate didn’t know much about X, but seemed to be an expert at Y.” The Y interviewer would then raise her eyebrows and say, “That’s funny. I found that this candidate doesn’t know anything about Y, but they sure talked a good game about X.” To get to the root of this contradiction, we would ask the X and Y interviewers to explain the questions they had asked. Listening to these interview questions, the other four interviewers would look around guiltily, as they realized that they themselves might not have fared all that well on this interview.
The strcpy Programming Test
As part of our interview to determine skill in the software technical area, we asked the candidate to write the C code for the strcpy (string copy) utility. This is a presupplied function in the C/Unix runtime library, so most candidates would never have previously considered how it must be implemented, but it is a very simple task for any reasonably experienced programmer to sketch out a workable version of strcpy within a few minutes.
Most candidates who said they “knew C” passed this sanity check easily. But we were surprised at how many candidates who had claimed extensive C programming experience on their resume were unable to conjure up a plausible strcpy. Some would stumble around for a few minutes and then admit that they had heard of C, but never actually seen it. Others would write out code that looked suspiciously like Fortran, using array syntax instead of C’s pointers. We did not necessarily fail candidates who performed poorly on this test, but if their resume did not match their interview, we looked much harder at their references.
Hiring and the Promotion List
In 1999, Jim Aylor of the University of Virginia invited me to give a talk at the Microelectronic Systems Education Conference in Arlington, Virginia [25]. The invitation was in response to requests from professors who wanted to know how effective their students were when they entered industry and how well prepared we thought they were during recruitment. I viewed this talk as an opportunity to show off our well-crafted recruitment process, and solicited some help from Intel’s human resources department so that we could show how actual data on promotions and career advancements correlated to our hiring process.
Initially, I didn’t even think to question whether the data would support my belief that our hiring process was effective. But as I looked over several years of promotions data from the corporate database, I began to realize that my intuitions were way off. I had thought that the higher the interview score (the candidate’s average expertise level across the six technical areas), the mo
re likely they would be to “catch on” at Intel and move on to great things. But there really was no statistical correlation between our interview scores and the odds that a particular person would get a promotion within a few years after having been hired. (All “fast-track” performers get such promotions.)
This was somewhat distressing, at least initially. It just seemed so logical that people with higher evident technical ability would be better positioned than others with respect to promotions, but the data did not show it.
This made me suspicious. If my intuitions were wrong about this, where else might they be wrong? Well, surely a higher college grade point average ought to be correlated with career success. After all, the GPA is a result of native ability, hard work, and demonstrated mastery of difficult technical material, all of which seem essential to success in industry. But, again, the data did not bear this out. It was clear that Intel did not hire engi neers with GPAs below approximately 3.2, but once someone was hired, a higher GPA did not in any way predispose its owner to faster promotions.
I was feeling a bit desperate at this point. If interview scores and GPAs did not predict future success, how about advanced degrees`? Wouldn’t MSEEs and PhDs be able to exhibit higher levels of mastery as well as the perseverance to tackle something and finish it no matter what? Again, the data stubbornly refused to support even this soundly logical assumption. If anything, PhDs appeared to be underrepresented in the ranks of the newly promoted.’
By this point, the pattern was clear, and I was pretty sure how the next attempted correlation would turn out, but I pressed on, comparing the alma maters of the fast-trackers to Intel’s list of preferred “focus” schools. I found nothing. There were unmistakable differences in the educational background of students who came from, say, MIT, and those who came from second-tier universities, but focus schools were only slightly better represented in the promotions lists. And even that correlation was questionable, because Intel hires disproportionately more students from its focus schools so, naturally, there would be more of them in the fast-track category.
The Pentium Chronicles: The People, Passion, and Politics Behind Intel's Landmark Chips (Practitioners) Page 25