Shaw第二轮面试：
今天是由一个Sr. Manager和两个team member进行面试，大多是行为方面的问题，基本没有涉及技术。因为这些问题具有普遍性，也许能供求职的朋友借鉴一二，所以乘着现在记忆还比较新鲜，把印象较深的问题记录如下：
问：你如何处理并行的几项工作（multi-task)
答：我会把工作按“重要性”和“紧急性”两个维度进行评估，优先处理既紧急又重要的，其次紧急的，再次重要的，最后处理既不紧急又不重要的。
问：如果同时具有多项又紧急又重要的工作，你如何处理
答：我会和我的team leader商量，看是否能安排其他的team member配合我一起完成这些工作，以保证用户的满意度。
问：你如何处理changing priority（我的理解是变更的优先级）
答：用户满意度是首位的，当出现changing priority时我只能尽我的最大能力跟随。但为了避免出现这种情况，我会在确定priority顺序之前进行充分的沟通，包括了解对方的需求以及阐述我及我的team将为此付出的工作量。这样即使当对方要变更优先级时，我也可以争取到更多的完成时间。
问：你所认可的开发模式是什么？
分析：这是一个典型的trick问题。传统意义上IT界普遍认可的的开发模式是waterfall模式，即 需求调研>设计>开发>测试>交付使用 这样环环相扣的步骤。但正如前面提到的，我在他们director的博客上看到了agile developement的字样，直译过来就是敏捷开发。说白了就是用户也不清楚他们的需求，所以就边做边看效果边改进咯，直到最后大家都满意。据此，我认定对方问这个问题其实是想看我是不是还在用传统方式思考问题。所以我的答案是：
答：当今市场竞争非常激烈，形势瞬息千变。如果以以往的方式按部就班来的话时效性太差。所以我认为敏捷开发是应对目前情况的最好模式。我不能坐等客户提出需求，而是应该站起来敲开对方的办公室门对他们说：“hey guys，do you want to talk about the problems you are facing?”。然后在不断讨论的过程中完成任务。
问：你是否愿意接手别人未完成的工作，比如读别人的源代码。
答：对于开发者来说，最大的痛苦莫过于此，更大的痛苦在于你不可避免。所以，这就是工作。我虽然不愿意这样做，但从中我也收益颇多。比如说你可以从对方留下的文档中看出他思考问题，解决问题的方法和思路。这让我觉得很有趣。
分析：实话实说。但要向积极的方向靠。
问：你如何处理争端（conflict）
答：（举例说明）有一次我的team leader让我完成一项非常困难的工作，而且只给了我很短的时间。我认为这是不可能完成的，但老大说这是非常重要的任务，必须无条件的接受。我当时认为他是在和我过不去，于是就和他发生了争执。但冷静下来之后，我主动找他了解了这项任务的来龙去脉，随后又和需求提出者进行了仔细的沟通，发现这个需求可以用另外一个替代方案来解决，但是工作量比原方案要少得多。于是在征得对方同意后，我向老大汇报了这个情况。从而问题得以解决。
分析：回答此问题的重点在于解决争端的方式，而不是描述问题本身。本来就没有一种通用的方法，所以最好用案例来说明。但需要注意案例的真实性和细节问题。比如我按照上面的内容回答完之后，对方就问了：那你说的替代方案是什么？你是怎么想到这个方法的？这时就要看平时的积累了。
还有很多类似的问题就不一一细说了。其实准备面试问题我个人有两个办法：关于个人行为类的可以到网上去搜，不一定要背答案，关键是了解对方问这个问题的动机，然后根据自己的实际情况来准备；关于经验和技术类的，把job description里面的requirement一条一条的翻出来，然后试着用“讲故事”的方式来回答。比如对方要求应聘者要有3年的java开发经验，那就用一个案例来描述自己是怎么使用java来开发软件的。这样的准备也是对自己职业生涯的一次梳理。
面试结果应该还算不错，至少跟我要reference list了。但是然后，该死的然后，manager笑着说可能还会有第三轮面试，和他的上司。。。。。。
难道介就素传说中的加拿大速度？疯了，彻底疯了。
