A Few Tales of Interviewing in America

Interviewing engineers in America is a curious experience. I’ve posted a few such experiences on Moments before, and these past two days I interviewed two very interesting engineers, one of whom stirred up a long-buried memory. Digging through the git repo of my public-account posts with ag, I finally found an old piece I’d never finished and so never published. Today let’s talk about these three people.

(One)

Mr. SH. The Mr. SH I interviewed yesterday. His background is ad systems — at his previous company he learned on the job, implementing an RTB system in erlang. He’s a fast learner, has rich systems knowledge, considers problems thoroughly, and in just over a year with erlang his mastery of it is already quite good. We chatted for nearly an hour, hitting it off more and more — usually by this point I’ll ask candidates some odd questions, like, what have you been reading lately? What interesting open-source projects have you come across recently? To him, I posed this question: if the erlang core team were willing to implement a few features for you at the language and VM level, what would you want?

This question is very open — it tests both the candidate’s understanding of existing systems and the breadth of the candidate’s knowledge.

Unexpectedly, he rattled off three wishes at once: 1) better refc management, improving memory efficiency without triggering “leaks”; 2) introducing a type system, ideally strictly distinguishing pure/impure functions like haskell does; 3) moving OTP’s core features — application/supervision trees, say — into the language itself rather than shipping them as a lib.

For 1) and 2) I wasn’t too surprised. 3) was very interesting, and showed real thought. I asked him to elaborate — he said that although he didn’t have much akka knowledge, akka had clearly surpassed the master in some respects. In akka, any actor that spawns gets a default supervisor; erlang OTP provides supervision trees, yet neither the language nor the VM makes this the default behavior — if we temporarily spawn a process to serve some contextual need, in the vast majority of cases we’ll additionally monitor it for proper error handling; so given that, why not supervise by default?

Whether the idea is right or wrong, that kind of thinking alone puts him above a great many programmers.

(Two)

Mr. B. Today I interviewed Mr. B. An android engineer. At a glance at his resume, Mr. B reminded me of Mr. S, whom I interviewed long ago (more on him below), for a simple reason: another Silicon Valley living fossil. When Mr. B started working in 1980, I wasn’t born yet. That was the era when DEC was at its zenith (no one foresaw that the minicomputer king who’d cornered IBM would, within a few years, be shattered by the PC wave), he worked at DEC, then moved through no fewer than ten companies, famous ones including amazon and twitter. If we calculate based on a normal kid entering college at seventeen, he’d now be well past seventy. While the domestic programmer circle is still debating what programmers should do after 35, he’s still hale and hearty, doing frontline android development. And he’s the author of three android books, the most recent published in ’16, called android concurrency. Although the old gentleman unfortunately missed nearly every opportunity in modern computing history to get rich, he’s still cheerful, without self-pity.

In the hour before interviewing him, I browsed amazon for reviews of the book and previewable chapters. Honestly, the book isn’t excellent — concepts aren’t explained clearly enough (which the interview confirmed: he had no clear definition of concurrency versus parallelism; perhaps I’m a stickler for concepts), and he doesn’t grasp the big picture of concurrency beyond android (e.g. actor model, CSP, STM, etc.). Of course, being able to write a book already exceeds the ordinary; his android mastery is considerable, and being active on the technical frontline and continuously writing at nearly sixty — truly a model for us. (While chatting, the old gentleman said he’d keep publishing books.)

(Three)

The interview with Mr. S was over a year ago; if not for having written an article at the time that preserved some vivid memories, my recollection of Mr. S would remain only at “living fossil.”

Here’s that article:

More than 10 years ago when I first joined Juniper, colleagues would gather for lunch together every day. For a while, many Chinese engineers from HQ came through, chatting about Silicon Valley anecdotes. A kernel guru colleague named Yi mentioned that once while fishing, he got to chatting with an old man beside him and ended up chatting out the inventor of Ethernet. Even then I marveled: Silicon Valley really is a magical place.

Later I heard from colleagues many more stories about running into Silicon Valley living fossils — such as interviewing programmers from the same era as Gates and Jobs — and I listened, enchanted.

Last week I finally met an interviewee from the same era as old Jobs, Mr. S, who graduated from Indiana University in ’78. An early MIPS employee, an early NeXT employee (he joined right after old Jobs was kicked out of his own biological son Apple and had just adopted this stepson NeXT), VP at several companies, including NEC (well, NEC can hardly be considered a good company now, but it once burned bright).

And then he came to interview at our little temple, Tubi TV!

This is unimaginable in China! Can you imagine revered super-programmer elders like Bao Yueqiao or Jian Jing coming to your startup to interview for a programmer position?

Mr. S lives in Atherton, Silicon Valley’s famous wealthy district; presumably he’s not short of money. Throughout the interview, a question nearly escaped my lips several times: you don’t seem to lack a salary, and by your credentials (or connections) you could go to some big company, so why come to a startup like Tubi TV that’s at the stage where everything needs worrying about? But out of deference to cultural differences, I forced myself to hold back.

As a warm-up, I asked him about his time at NeXT; he said he worked on the object-c compiler. I’m not versed in compilers, so after a few exchanges I moved the topic to old Jobs. Mr. S immediately opened up, telling various anecdotes, then his eyes dimmed, and he said that after the old man took over Pixar, his energy went entirely there, and he rarely appeared at NeXT.

Then we talked about MIPS. I gradually felt his love for technology — which also explains why he moved through many companies, held VP titles at companies big and small, yet was still willing to work on the frontline.

He said that two years before joining NeXT, in 1984 (well, at that time I was still toddling around in split pants), he joined the just-founded MIPS, personally experiencing the transformation of an instruction set from academia to industry, and so he holds deep affection for MIPS. Because at Juniper I’d worked on interrupt-handling-related code, I was fairly familiar with various RISC CPUs, especially MIPS and ARM, so I presumed to show off in front of an expert, testing his depth with branch delay. He said his main work was optimizing the TLB, trying to optimize away the SRAM between CAM (in those days there was probably no TCAM yet) and DRAM (SRAM was unbelievably expensive back then), but he understood instruction pipelines too. After he’d explained in textbook-like detail the evolution of branch delay across several early generations of MIPS CPUs, I suddenly recalled a question that had puzzled me for years: why does MIPS have branch delay, when ARM/PowerPC, also RISC CPUs, don’t do this at the instruction level. He explained that as far as RISC goes, MIPS is the purer RISC CPU, while ARM/PowerPC had already made some improvements (compromises) in industry for performance; moreover, exposing too much pipeline logic to software engineers (note: mainly engineers writing compilers and low-level kernel code) would make compilers overly complex (static compilation struggles to perfectly predict the dynamic state of instruction execution). So he felt ARM’s approach was correct, especially since the later emergence of hyperthreading confirmed this — the complexity of pipelines has rendered such simple optimizations meaningless; only the CPU’s own out-of-order execution is the true way.

I listened with relish — isn’t this line of thinking exactly the difference between imperative programming (the programmer tells the CPU the steps to do things) and functional programming (the programmer tells the CPU what they want done)?

Since ARM came up, I took the opportunity to ask whether he understood literal pools.

Unfortunately, the article cuts off right here; I can no longer recall the later interview process. The one thing I can be certain of is that he didn’t come to Tubi TV.

(Four)

I’d originally meant to just jot something down on the train, publish a long post with an image, and be done, but somehow I wrote all this. A programmer’s life path is long, and wave after wave will come in the future; most people are destined to miss every opportunity to make a name for themselves, spending their whole lives as ordinary, diligent programmers. Actually I have quite a lot of reflections on these interviews, but after much deliberation I’ve decided to lay down my pen here and let everyone think for themselves.