出来混,迟早要还。也有了人生第一次电话面试。没有签NDA,所以在这里分享一下。但愿对各位大佬有帮助。职位是架构。要求是对Java和J2EE熟,能编程,熟悉OO设计。有架构经验,等等等等,都是大路货,没什么出奇的。再说出奇的我也不行啊。

总的感受:
用自己的话总结对方的话挺有用。表明了你在积极思考,理解了对方的意思,并且避免了双方的误解。关键是要加上自己的理解、延伸,和追加问题。面试官介绍他们的技术时我用了这坨方法,明显感到对方话多起来,也更为随意。大概正确的理解让对方打开了话匣子。 准备一个电话用耳机。不然一小时的面试下来,手挺累的。而且做编程题时需要在本子上演算,拿着话筒也不方便。用免提效果不如耳机好。尤其现在家 家都用IP电话,用免提有非常明显的杂音。 准备一杯水。除非老大您久经沙场,面试如老友闲谈。多少会紧张,导致口干。一杯水能让人舒服,很好地缓解情绪。 问题挺简单,但我居然卡壳。可见事前充分准备多重要。下面详说。
大致的面试过程

寒暄过后,面试官介绍他们的技术。介绍完后,问我有没有问题。我陈述自己对他们技术的理解,列举了几坨可能的应用,问他自己的理解对不对。他同意。于是继续他们的技术同他们的竞争对手有什么区别。然后又问了点搜索中常见的问题,比如怎么处理扩展性,怎么抓取数据,怎么整合数据,如何数据挖据什么的。目的不在了解他们的具体技术。反正也问不出来。主要是表明自己对他们的相关技术有兴趣,有一定了解。另外也是找机会称赞他们技术新颖的时候(前提是真觉得他们的东西不错。诚恳很重要哈)。感觉大家言谈甚欢。直到对方说如果你有问题,等会儿还可以继续问我。于是知趣打住,等待对方提问。

问题从我的经历开始。你现在做什么。负责什么。用什么技术。多少跟Java有关,多少跟JSP/Servlet有关,多少跟前台有关。多少跟后台有关等等。你都很久没有用Java了(俺现在做很多AJAX应用),技术不会落后么?于是俺强调其实没有全职做Java也就一年,但技术并没有撂下。比如俩月前还写了一坨stream-processing proxy server。至于JSP,一坨简单模板技术而已,用不用关系不大嘛。再说相关书没少看。然后列举几坨最近看的常见书籍,对方也就没再追问。本来想说语言不重要,关键是背后的技术。但想想人不是来听我上课的,遂作罢。

然后面试官说,So you still know Java, huh? Do you know Java Collections? 我耳背,听成了Javaconcurrencies? 心头一凉。心想,哪壶不开提哪壶嗫?做JEE的哥们儿里,有多少人成天和concurrency打叫道啊?都是托Container的福。只有书本知识和玩具程序的体验哈。不过嘴上不能示弱。答:然,concurrency的知道。结果对方说,不不不,是Collections。说说Collections里的常见数据结构。随口说了几个。对方继续问:如果有一百万key-value pairs供查询用,怎么办?答:可以用HashMap,如果你没有synchronization的要求。对方继续追问,可能有有什么潜在问题?我聊了点常见的问题,诸如数据多了需要不断重新组织bucket,会时不时影响性能。对方接着问:那你还用HashMap?心想:Call!设套让俺钻呐?于是答:因为够简单。再说如果担心性能,我们可以测试嘛。找出瓶颈再优化不迟。面试官没有纠缠,换了个话题追问:如果这些key-value是用于cache的,用hashmap有什么问题?答曰:可能导致大量垃圾。然后讨论了一下Weak Reference,Soft Reference,和Phantom Reference的区别。对方问,如果用String作为key,还可以怎么处理?答:用Trie。面试官接着问:那如果要做子串查询呢?顺口答:Suffix tree。奇怪的是对方没有深入问下去,而是换了个话题问:如果我只关心key,你怎么处理value?这个时候我开始犯傻,答:那你用boolean或者整数,还可以知道每坨key出现多少次。结果我大概听力有问题,人不是这个意思。所以面试官提示:我不关心value。于是俺醒悟:答; 那就用Set。奇怪的是他也没有追问关于Set的选取和实现,就跳到下一个问题了。事后想来,这是教训:应该先问清楚对方的需求再答题。平时我肯定是这么做的。但不知道为什么面试时这些常识通通忘掉了,先入为主。当时好像也不紧张阿。

之后进入编程时间:写一坨函数交换两个String。我一听想,难道是传说中的陷阱?于是特意确定,你是想我写一坨函数:void swap(String s1, String s2),运行后s1的值同s2的值交换?对方说是。于是我说不可能。解释了pass by value和pass by reference。然后对方问怎么可能。我说你用StringBuffer或者一坨Array/某坨Collection都行。他好像满意了。于是跳到下一个问题。

问:说说一坨request进来后,JSP的life cycle。我背书。然后他追问:怎么保证线程安全。答不要用instance variable。你要用partial/full synchronization也行,但这多半表示你的设计出问题了。然后他又反过来问:那你在JSP里怎么保证不用instance variable。我说不用<%!就行了。其实我们有严格的编程规范。像<%!这种东东只在书上见过。俺一辈子都没用过。两人笑。后来面试官又问了几个常见的Java/JEE问题,不过我忘了。

真正的算法题没几道。都比较简单。第一道是两坨排好序的数组。求它们的overlap。比如[a, c, e, f]和[d, a, g, h, k, f, s]的overlap是af。其实就是求他们的LCS。那么简单的题,我居然一下卡壳。当时不知道为什么脑子完全被LCS的常用算法占据。问题是,这样就没用上排序这项条件。我也想到了用类似Merge Sort的方法做,但不知为啥又把它否定了。这个时候对方提示了一下,说brute force怎么做,我赶快答。然后就想出了答案。接着对方问复杂度,我说O(m+n),对方就跳到下一道题了。这次失败的教训是
镇定,镇定,再镇定。我居然忘了多演算几个例子,问他对复杂度的要求,以及从brute force开始推演。 练习,练习,再练习。在时间压力下解决问题同悠闲地做题自娱自乐有本质区别。至少压力会干扰我的直觉,让一些平时看来简单的东西变得捉摸不透。平时就注意夯实基础和拓宽思路才不会在关键时掉链子。 临场经验也挺重要。其实Polya的解题方法我也常用。平时开会和给学生讲题也是站在白板边就开始大声思考。但到了面试,还是觉得思路非常拘束。
第二道算法题是一坨任意整数数组。写一个函数,把数组里的奇数放前面。偶数放后面。比如[1, 2, 3, 4, 5],处理后得到[1, 3, 5, 2, 4]。这次我学乖了,先演算了几个例子,然后问了他顺序重要不。他说不重要。我说,俺决定从最简单的开始,试一试顺序做,放一坨下标,指向数组起始元素。说到这里,算法出来了。然后分析复杂度,时间O(n),空间O(1)。好像他也就满意了。虽然这次稍微顺利了点,但感觉还是非常束缚。完全没有平时编程时思路清澈自由的感觉。貌似解释思路只是为了拖延时间,脑子里好像被塞了一块抹布。非常郁闷。

最后一题刚好关于Suffix Tree,就不多说了。

然后是我的提问时间。我问了公司的文化。然后问除了Job Description上的条条,他们到底找什么样的人。然后又问了他们的开发流程。顺便聊了下流程,表明自己对软工的套路也熟悉。

最后大家道再见。面试官说会同HR的人讨论。再看有没有必要安排下一轮面试。比较诡异的地方是,我申请的是架构的职位,但电话面试没有问关于设计和架构的问题,也没有问和人打交道的问题。还有他也没有问关于scalability的问题和多线程编程的问题。这也比较奇怪。据说他们是天天和这些东西打交道的。我猜大概是以为电话面试是用来过滤候选人的,所以不会复杂和面面俱到。现场面试的题目会更深广一些。


http://www.mianwww.com/html/2009/11/5643.html/comment-page-1