出来混，迟早要还。也有了人生第一次电话面试。没有签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? 我耳背，听成了Java concurrencies? 心头一凉。心想，哪壶不开提哪壶嗫？做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的问题和多线程编程的问题。这也比较奇怪。据说他们是天天和这些东西打交道的。我猜大概是以为电话面试是用来过滤候选人的，所以不会复杂和面面俱到。现场面试的题目会更深广一些。
发表于 @ 2008年07月20日 00:23:00|评论(loading...)|收藏