面试困惑问与答

疑问一：为什么跳槽

问：每次跳槽的时候，面试官都会问“为什么想跳槽”。请问这个问题该怎么回答？

答：每个人都有自己的跳槽动机和原因，因此面试官也不会期待一个标准答案。面试官只是想通过这个问题来了解应聘者的性格。因此应聘者可以大胆地根据自己的真实想法来回答这个问题。但是，应聘者也不是可以想说什么就说什么，以免给面试官留下负面的印象。

           建议在回答这个问题时，应尽量避免这四个原因：（1）老板太变态；（2）同事太难相处；（3）老是加班；（4）工资太低。这四个理由都有可能给面试官留下不好的印象。要是面试官就是当前面试的职位的老板，他听到应聘者抱怨现在的老板变态时，他肯定会想要是把这个人招进来，接下来他就会抱怨我也变态了。如果应聘者说他周围有很多很难相处的同事，面试官很有可能在想，这个人他自己本身就很难相处。对于大部分IT企业来说，加班是家常便饭。要是当前面试的公司也需要经常加班，那等于应聘者说他不想进这家公司。现在的工资太低的确是大部分人跳槽的真实原因，但不建议在面试的时候对面试官抱怨。面试的目的是拿到offer，我们要尽量给面试官留下好印象。现在假设你是面试官，有两个人来面试：一个人上来就说现在工资太低了，希望新工作能加多少多少工资；另一个说我只管努力干活，工资公司看着给，相信公司不会亏待给力的员工。你说你更喜欢哪个？这里不是说工资不重要，关键面试不是谈工资的时候。等搞定面试谈offer的时候，再和HR谈工资也不迟。现在公司招一个技术合格的人也不容易，因此搞定面试之后你就掌握主动了，想怎么谈就怎么谈，如果真的开高了HR会和你很客气地商量。

      笔者自己在面试的时候，通常给出的答案是：现在的工作做了一段时间，已经没有太多的激情了，因此希望寻找一份更有挑战的工作。然后具体的论述为什么现在有些厌倦现在的职位，以及面试的职位你为什么会有兴趣。笔者自己跳过两次槽，第一次从Autodesk跳槽到微软，第二次从微软跳槽到现在的思科。从面试的结果来看，我这样的回答都让面试官很满意，最终也都拿到了offer。

当时在微软面试被问到为什么要跳槽时，我的回答是：我现在开发的软件Civil是一款面向土木行业的设计软件。如果我想在现在的职位上得到提升，就必须加强土木行业的学习，可我对诸如计算土方量、道路设计等没有太多兴趣，因此出来寻找机会。

      在微软工作两年半之后去思科面试的时候，“为什么要离开微软”这个问题几乎每个面试官都会问。我的答复是：我在微软的主要工作是开发和维护.NET的UI平台Winforms。由于Winforms已经非常成熟，不需要添加多少新功能，因此我的大部分工作都是维护和修BUG。两年下来，调试的能力得到了很大地提高，但再这样下去自己的软件开发和设计的能力将不能得到提高，因此想出来寻找可以设计和开发系统的职位。同时，我在过去几年里的工作都是开发桌面软件，对网络了解甚少。因此希望下一个工作能与网络相关。众所周知，思科是个网络公司，这里的软件和系统或多或少都离不开网络。因此我对思科的职位很感兴趣。

疑问二：感觉挺好，为啥被拒了？

问：技术面试的时候，题目挺简单的，我觉得自己都做出来了。可最后怎么还是被拒了啊？

答：面试被拒有很多种可能，比如面试官认为你性格不适合、态度不够诚恳等等。但在技术面试过程中，这些都不是最重要的。技术面试的面试官一般都是程序员，程序员通常没有那么多花花肠子，他们只认一个理：题目做对、做完整了，就让你通过面试；否则就没戏。所以碰到简单题目却被拒的情况，应聘者还是要检讨题目是不是真的做对、做完整了。

                举一个微软面试开发工程师时最常用的一个问题为例：把一个字符串转换成整数。这个题目很简单吧？很多人都能在三分钟之类写出如下不到十行的代码：

 1 int StrToInt(char* string)
 2 {
 3         int number = 0;
 4         while(*string != 0)
 5         {
 6                 number = number * 10 + *string - '0';
 7                 ++string;
 8         }
 9  
10         return number;
11 }

                看了上面的代码，你是不是觉得微软很容易搞定？如果你真的这么想，不好意思，你可能又要被拒了。

通常越是简单的问题，面试官的期望值就会越高。当题目简单的时候，面试官就会期待应聘者能够很完整解决问题，除了完成基本功能之外，能够考虑各种边界条件、错误处理等各个方面。像这道题，面试官不仅仅只是期待你能完成把字符串转换成整数这个最最起码的要求，而是希望你能考虑到各种特殊的输入。如果我是面试官，我至少会期待应聘者能够在不需要提示的情况下，考虑到输入的字符串中有非数字字符和正负号，要考虑到最大的正整数和最小的负整数，以及溢出，同时还要考虑当输入的字符串不能转换成整数时，应该如何做错误处理。当把这个问题的方方面面都考虑到的时候，你也就不会再认为这道题简单了。

除了问题考虑不全面之外，还有一个面试官不能容忍的错误就是程序不够鲁棒。以前面的那段代码为例，只要输入一个空指针，程序立即崩溃。这样的代码如果加入到软件当中，将是灾难。因此当面试官看到代码中对空指针没有判断并加以特殊处理的时候，通常他连往下看的兴趣都没有。

当然，不是所有与鲁棒性相关的问题都和前面的代码那样明显。再举一个很多人都被面试过的问题：求链表中的倒数第k个结点。有不少人先在网上看过这个题目，因此知道思路是用两个指针，第一个指针先走k-1 步，然后两个指针一起走。当第一个指针走到尾结点的时候，第二个指针指向的就是倒数第k个结点。于是他大笔一挥，写下了下面的代码：

 1 ListNode* FindKthToTail(ListNode* pListHead, unsigned int k)
 2 {
 3         if(pListHead == NULL || k == 0)
 4                 return NULL;
 5  
 6         ListNode *pAhead = pListHead;
 7         ListNode *pBehind = NULL;
 8  
 9         for(unsigned int i = 0; i < k - 1; ++ i)
10         {
11                 pAhead = pAhead->m_pNext;
12         }
13  
14         pBehind = pListHead;
15  
16         while(pAhead->m_pNext != NULL)
17         {
18                 pAhead = pAhead->m_pNext;
19                 pBehind = pBehind->m_pNext;
20         }
21  
22         return pBehind;
23 }

写完之后，应聘者看到自己已经判断了输入的指针是不是空指针并做了特殊处理，于是心里洋洋得意以为这次面试必定顺利通过了。可是，他没有想到的是这段代码中仍然有很严重的问题：当链表中的结点总数小于k的时候，程序还是会崩溃。因此，几天之后他收到的仍然不会是Offer，而是拒信。

要想很好地解决前面的问题，最好的办法是在动手写代码之后想好测试用例。只有把各种可能的输入事先都想好了，才能在写代码的时候把各种情况都做相应的处理。写完代码之后，也不要立刻给面试官检查，而是先在心里默默地运行。当程序运行之前想好的所有测试用例都能得到合理的输出时，再把代码交给面试官。做到了这一步，通过面试拿到Offer就是水到渠成的事情了。

疑问三：题目没弄懂，可以问面试官么？

问：面试的时候，面试官突然冒出一个之前没有听过的概念，请问我可以问面试官让他把题目说清楚吗？如果问的话他会不会觉得我很傻？

答：面试和笔试最大的区别是：面试是一个注重沟通交流的过程，而且沟通是双向的。因此面试官可以问应聘者问题，同样应聘者也可以问面试官问题。

                通常在面试环节面试官的一个很重要的任务就是考察应聘者的学习愿望以及学习能力。学习能力怎么体现呢？面试官提出一个新概念，应聘者没有听说他，于是他在已有的理解的基础上问进一步的问题，然后掌握了这个概念。这就是学习能力。通常学习能力强的人具有主动积极的态度。因此建议在应聘过程中碰到不明白的地方多提问，这样面试官觉得你态度积极，求知欲望强烈，这样会给面试结果加分。

                举个例子，google曾经有一道面试题：找出第1500个丑数。很多人都不知道丑数是什么。不知道怎么办？面试官就坐在对面，可以问他啊。面试官会告诉你只含有2 、3、5三个因子的数就是丑数。你听了后，觉得听明白了，但不太确定，于是可以举几个例子并让面试确认你的理解是不是对的： 6、8、 10、12都是丑数，但14就不是，对吗？当面试官给出肯定的答复，你就知道自己的理解是对的了。问题问的是第1500个丑数，与顺序有关。可是哪个数字时第一个丑数呢，1是不是第一个？这个你可能也不能确定，怎么办？还是问面试官，他会告诉你1是或者不是丑数。题目是他出的，他有责任把题目给你解释清楚。

                有些面试官甚至故意一开始不把题目描述的清楚，让题目存在一定的二义性。他期待应聘者能够一步步通过提问来弄明白题目的要求。这就是在考察应聘者的沟通能力。为什么要这样考察？因为实际工作也是这样，不是一开始项目需求就定义得很清楚了。程序员需要多次与项目经理甚至客户反复沟通才能把需求弄清楚。如果没有一定的沟通能力，当程序员面对一个模糊的客户需求时，他就会觉得无处下手。

比如最近很流行的一个面试题，面试官最开始问：如何求树中两个结点的最近公共父结点。此时面试官对题目中的树的特点完全没有给出描述。他希望应聘者在听到问题后会提出几个问题，比如这棵树是二叉树还是普通的树。

如果面试官说是二叉树，应聘者可以继续问该树是不是排序的二叉树。面试官回答是排序的。听到这里，应聘者才能确定思路：从书的根结点出发遍历树，如果当前结点都大于输入的两个结点，则下一步遍历当前结点的左子树；如果当前结点小于输入的两个结点，则下一步遍历当前结点右子树。一直遍历到当前结点比一个输入结点大而比另一个小的时候，此时当前结点就是符合要求的最近公共父结点。

如果应聘者问树是不是二叉树的时候，面试官回答是任意的树。此时应聘者可以接着提问在树结点中有没有指向父结点的指针，面试官将会给出肯定的回答。由于树的结点中有指向父结点的指针，因此从输入的结点出发，沿着指向父结点的指针一直到树的根结点，可以看做是一个链表，因此这个题目的解法就和求两个链表的第一个公共结点的解法是一样的了。

我们可以看出面试官给出不同的条件，将是两个两个完全不一样的题目。如果一开始应聘者没有弄清楚面试官的意图就贸然动手解题，那结果很有可能是离题千里。从中我们也可以看出在面试过程中沟通的重要性，当觉得题目的条件、要求不够明确的时候，一定要多提问来消除自己的疑惑。

疑问四：最后应该问什么？

问：每次面试的时候，面试官都会问我有没有什么问题要问他。我可以问什么问题呢？

答：面试官让应聘者问问题，主要是想了解应聘者最关心的问题有哪些。因此，首先至少要问一两个问题。不然面试官就会觉得你对我们公司、职位等都不感兴趣，那你来面试做什么？但是也不是什么问题都可以在这个时候问。如果问题问得比较合适，对应聘者来说是个加分的好机会；但如果问的问题不太合适，面试官对你的印象就会大打折扣，相当于跳入面试官的陷阱了。

                先谈谈不适合问的问题。首先是问和自己的职位没有关系的问题，比如问“公司未来五年的发展战略是什么”。如果你面试的职位是CTO，而你的面试官是CEO，这倒是个合适的问题。如果面试的职位只是个程序员，那这个问题离你就太远了，与你的切身利益没有多少关系。再说，坐在你对面的面试官很有可能也只是个程序员，你让他怎么回答这个关系公司发展战略的问题呢？

                其次是问薪水。技术面试不是谈薪水的时候。要谈工资，等通过面试之后和HR谈。这个问题在前面的第一个困惑中已经讲过，不在赘述。

                第三是立即打听面试结果，比如问“您觉得我能拿到Offer吗”之类的问题。现在大部分公司的面试都有好几轮，最终决定应聘者能不能通过面试，是要把所有面试官的评价综合起来的。问这个问题相当于白问，因为问了面试官也不可能告诉你结果。

                笔者推荐问的问题是与招聘的职位或者项目相关的问题。如果这种类型的问题问得很到位，那么面试官就会觉得你对应聘的职位很有兴趣。不过要问好这种类型的问题也不容易，因为首先对应聘的职位或者项目的背景要有一定的了解。我们可以从两方面去了解相关的信息。一是面试前做足功课，到网上去搜集一些相关的信息，做到对公司成立时间、主要业务、职位要求等都了然于胸。二是面试过程中注意面试官说过的话。有不少的面试官在面试之前会对招聘的职位相关的项目会做简单介绍，其中会包含其他渠道无法得到的信息，比如项目进展情况等等。应聘者可以从中找出一两个点，然后向面试官问。

                举几个我当时来思科面试的时候问的几个问题。一个面试官介绍项目时说这次招聘是项目组第一次在中国招人，目前这个项目所有人员都在美国总部。那一轮我最后问的问题是：这个项目所有的老员工都在美国，那怎么对中国这一批新员工进行培训？中国的新员工有没有机会去美国总部学习？最后一轮面试是老板面试，她介绍我要加入的项目组是负责开发思科测试供应商生产出来的网络设备的测试系统。当时我最后问的几个问题是：这个组是做测试系统的，那这个组的人员是不是也要参与网络设备的测试，是不是需要学习硬件测试相关的知识？因为我们测试的对象是网络设备，那么这个职位对网络硬件的掌握程度有没有要求？

郑重声明：本文摘自何海涛的博文——http://blog.csdn.net/cadcisdhht，涛哥的面试经历我感觉值得分享。原文是分四篇来说明，这里我将它们合并了。面试是门艺术啊~

转载于:https://www.cnblogs.com/CSNotBack/archive/2011/08/17/2142943.html