站点公告:
微信公众号liuprogramme

易牛网 主页 干货开发频道

我在美帝面试程序员二三事

简介
在美帝面试工程师,是一种有趣的体验。以前曾经在朋友圈里发过一些体验,这两天,面试了两个很有意思的工程师,其中一个勾起了我一份尘封的回忆。今天我们讲讲这三个人。 (一) SH 君。我昨天面试的 SH 君。他的 ...


在美帝面试工程师,是一种有趣的体验。以前曾经在朋友圈里发过一些体验,这两天,面试了两个很有意思的工程师,其中一个勾起了我一份尘封的回忆。今天我们讲讲这三个人。

我在美帝面试程序员二三事

(一)

SH 君。我昨天面试的 SH 君。他的背景是广告系统 —— 他在之前的公司现学现用,用 erlang 实现了 RTB system。他学习能力很强,系统知识丰富,考虑问题周全,仅仅使用了一年多 erlang,在其之上的造诣就相当不错。我和他聊了进一个小时,越聊越投机 —— 一般到这个时候我会问 candidate 一些奇奇怪怪的问题,比如,你最近在读什么书?最近发现了什么有意思的开源项目等等。对他,我抛出了这么个问题:如果 erlang core team 愿意在语言和 VM 层面为你实现几个 feature,你希望是什么?

这个问题非常 open,既考察 candidate 对已有系统的理解,又考验 candidate 知识的丰富程度。

出人意料地,他一口气提了三个愿望:1) 更好的 refc 管理,提高内存效率同时又不引发 “leak” 2) 引入 type system,最好像 haskell 那样严格区分 pure / impure function 3) 把 OTP 的核心功能,比如 application / supervision tree 做到语言级别,而非以 lib 形式提供。

对于 1) 和 2) 我不太意外。3) 很有意思,也很有想法。我让他进一步澄清 —— 他说,他虽然没有太多 akka 的 knowledge,但 akka 显然在某些方面青出于蓝而胜于蓝。akka 下,任意一个 actor spawn 出来,都有默认的 supervisor,erlang OTP 提供了 supervision tree,可语言或者 VM 本身却没有把这个作为缺省行为 —— 如果我们因为上下文的需要临时 spawn 一个 process,绝大多数情况,会额外去 monitor 它以便妥善进行 error handling,既然如此,为何不默认就 supervise 呢?

甭管这个想法对与不对,单是这份思考,就超过很多很多的程序员了。

(二)

B 君。今天面试的是 B 君。android 工程师。粗一看简历,B 君就让我回想起了很久前面试的 S 君(下文会说),原因很简单:又一枚硅谷活化石。B 君 80 年开始工作时,我还没出生。那是是 DEC 如日中天的年代(谁都不曾料到把 IBM 逼到墙角的小型机之王,几年后就就被 PC 的浪潮冲击得七零八落),他在 DEC 工作,随后换了不下十家公司,著名的有 amazon 和 twitter。如果按照正常孩子十七岁的花季上大学推算的话,他现在已经年逾古稀。在国内程序员圈子还在热火朝天地讨论程序员 35 岁后该干嘛时,他却精神矍铄地参与一线 android 开发。并且,他是三本 android 书籍的作者,最近一本于 16 年出版,叫 android concurrency。虽然老爷子不幸错过了计算机近代史上几乎所有能发家致富的机会,他依然乐乐呵呵,没有自艾自怜。

和他面试的前一个小时,我上 amazon 翻看这本书的评论和可供预览的章节。平心而论,书写得并不算是优秀,概念解释得不够清晰(面试时也印证了他对 concurrency 和 parallelism 没有清楚的定义,可能我是一个对 concept 过于较真的人吧),对 android 之外 concurrency 的 big picture 也不了解(比如 actor model,CSP,STM 等)。当然,能写书,已经非一般人所及,他的 android 的造诣不浅,而且在近六十岁高龄活跃在技术一线还不断写书,实在是我辈之楷模。(和老爷子闲聊时,他说他还会继续出书)

(三)

S 君。和 S 君的面试已经过去一年多,如若不是当初写了篇未完成的文章,保留了些许鲜活的记忆,我对 S 君的记忆仅仅停留在「他是个活化石」的阶段。

这是当时的文章:

10多年前我刚加入 Juniper 时,同事们每天中午都要一起聚餐。有一阵子,来了很多总部的华人工程师,聊起硅谷的各种轶事,一位做 Kernel 的大神同事 Yi 说起他有次在钓鱼,和旁边的老头闲扯,一扯扯出来个以太网的发明者。那时我就感慨,硅谷 TM 真是个神奇的地方。

后来又陆陆续续听到同事们不少关于偶遇硅谷活化石的故事,比如面试遇到和盖茨乔布斯同时代的程序员等等,听得我如痴如醉。

上周终于遇到一个和乔老爷子同时代的面试者 S君,78年印第安纳大学毕业。MIPS 的早期员工,NeXT 早期员工(他是在乔老爷子被自己亲儿子苹果扫地出门,刚领养了 NeXT 这个义子后加入的),数个公司的 VP,包括 NEC(好吧,NEC现在已近算不得什么好公司了,不过曾经火过)。

然后他来我们 Tubi TV 这座小庙面试!

这在国内是无法想象的!你能想象鲍岳桥简晶这些让人敬仰的超级程序员前辈们跑到你的 startup 来面一个程序员的职位么?

S君住在 Atherton,硅谷著名的富人区,想来是不缺钱的。整个面试过程中,有个问题好几次我几乎脱口而出:您看上去并不缺一份薪水,凭资历(或者人脉)也可以去一些大公司领个闲置安度晚年好了,为何要来 Tubi TV 这样一个处在需要事事操心的阶段的创业公司?但顾忌到文化的差异,我强忍住了。

作为热身,我问了他在 NeXT 的履历,他说自己做 object-c compiler。我对 compiler 并非谙熟,不敢造次,扯了几句后就把话题移到乔老爷子身上。S君立刻打开了话匣子,讲起了各种轶事(程序君按:妈蛋我当时为啥没把这些轶事记录下来),随后他目光一暗,说老爷子自从接手 Pixar 后,精力就都投在那边了,在 NeXT 就很少出现他的身影。

随后我们聊起了 MIPS。我渐渐感受到他对技术的那份热爱 —— 这也可以解释他辗转多家公司,有大大小小公司的 VP title,却还愿意在一线做事。

他说他在加入 NeXT 之前两年,1984年(好吧,那时候我还穿着开裆裤满地连滚带爬地蹒跚学步呢),加入刚刚创立的 MIPS,亲历了一套指令集从学术界到工业界的转型,因此对 MIPS 饱含感情。因为在 Juniper 做过中断处理相关的代码,我对各种 RISC CPU,尤其是 MIPS 和 ARM 比较熟悉,于是便班门弄斧,用 branch delay 试了试他的底。他说他主要的工作是优化 TLB,设法优化掉 CAM(那时估计还没有TCAM)和 DRAM 之间的 SRAM(那个年代 SRAM 无比贵),但指令流水线也是懂的。在他如同教科书般详细介绍完 branch delay 在早期几代 MIPS CPU 的演进后,我突然想起一个困扰我多年的问题:为何 MIPS 有 branch delay,而同为 RISC CPU 的 ARM / PowerPC 却没有在指令级别做这种事情。他解释说就 RISC 而言,MIPS 是更纯粹的 RISC CPU,而 ARM / PowerPC 在工业界已经为了性能做了些改进(妥协),另外,暴露过多的流水线的逻辑给软件工程师(注:主要是写编译器和 Kernel 底层代码的工程师)会使得编译器过于复杂(静态的编译难以完美预测指令动态执行时的状态)。所以他觉得 ARM 的做法是正确的,尤其是后来 hyperthread(超线程)的出现印证了这一点,pipeline 的复杂已经使这种简单的优化失去了意义,唯有 CPU 自己的乱序执行才是王道。

我听得津津有味,这个思路不就是 imperial programming(程序员告诉 CPU 做事的步骤)和 functional programming(程序员告诉 CPU 想干什么)的差别么?

既然提到了 ARM,我便顺势问他是否了解 literal pool。

可惜,文章在这里就戛然而止,后来的面试过程我已经记不清楚,唯一能确定的一点是,他没有来 Tubi TV。

(四)

本来有感而发,火车上随便写写,发篇长文字图片了事,不经意间写了这么些。程序员的人生道路很长,未来还有一波又一波的浪潮,大部分人注定会错过所有扬名立万的机会,一辈子做一个普通的勤勤恳恳的程序员。对于这几个面试,我其实有蛮多感悟的,但思虑再三,还是决定就此搁笔,让大伙儿自己思考吧。

收藏 邀请

鲜花

握手

雷人

路过

鸡蛋

精彩阅读

精选资讯

推荐资讯

广告位

扫描二维码下载客户端

扫描,关注官方微信

联系我们

1399-7632910

24小时服务热线
客服QQ:834713287
市场部电话:13997632910

Archiver|手机版|小黑屋|Eaniu. ( 鄂ICP备17026225号 )

Powered by 易牛网 X3.4© 2016-2017 易牛门户 鄂ICP备17026225号 增值电信业务经营许可证:苏B2-20120251 公安机关备案号:苏32058202010001号 | 互联网新闻信息服务许可证编号:1312006002