看看自己是否适合做it

《看看自己是否适合做it》由会员上传分享，免费在线阅读，更多相关内容在工程资料-天天文库。

1、看看自己是否适合做IT程序员面试一直是社区乐于讨论的热门话题。我自己从06年实习以来，先后经历了4家软件公司，全部是外企，其中有世界500强的通信企业，有从事期权期货交易的欧洲中等规模的金融公司，也有为大型汽车制造商开发Android智能汽车的新兴公司。跨入IT行业以来，我在求职过程中经历过多次面试，最近两年也有过多次面试别人的经验。我感觉现在到了对这个问题发表自己看法的时候，这篇文章是我站在面试官角度对于程序员面试问题的一个阶段性反思和经验总结。目标相信和不少朋友一样，有了几年工作经验成为Senior后就开始了面试别人的经历。我在最初这个阶段

2、只是按照自己的想象把“找到基础好的程序员”、“找到算法能力优秀的程序员”、“找到有Android开发经验的程序员”等作为面试的目标。但是，实际的经历告诉我，尤其是按“基础好”，“算法好”这些目标招到的人最终效果并不好。比如，有的面试者基础知识和算法掌握情况不错，进程、线程、内存等概念清晰，基本的Hash、二叉树、快速排序等数据结构和算法也比较熟悉，但是进公司后在实际工作中表现得很糟糕。后来，我才发现原来是我的面试目标出了问题，我原先的面试方法更像是大学的算法或操作系统期末考试，按照这种方法让许多并不合适的人通过了面试，同时也可能错过了许多合适的

3、人。后来，我的反思是，从公司的角度讲，面试的根本目的是找到“能够干好工作”的人，而“高学历”，“算法好”，“基础好”，“有经验”这些都是表象而不是根本，它们并不能直接和“工作好”划等号。方法目标明确了，但接下来的问题是假设面试者是一个黑盒系统，“工作好”不是直接可观测变量，你所能直接观测的变量是基础、算法、经验、学历、性格、谈吐、年龄等等。所以，实际上，你只能从“基础好”，“算法好”等可以直接观测的量去推测“工作好”的概率，这就是一个在“X好”条件下“工作好”的条件概率问题：P(工作好

4、X好)。根据这个模型，面试所应该考察哪些方面就很明显了，那

5、就是选择那种最具有区分性的方面来考察。比如，考察面试者的体型特征没有太大意义，因为P(工作好

6、高)，P(工作好

7、矮)，P(工作好

8、胖)，P(工作好

9、瘦)的概率都差不多；所以，体型特征不具有区分性，这不是面试所应该关注的内容。面试官应当结合职位的要求明确哪些因素具有比较好的区分性。比如，如果要招一名技术门槛比较高的3D游戏引擎开发工程师，面试者A具有3D游戏引擎开发的经验，但是在基础知识和算法面试方面表现一般；面试者B相反，基础知识和算法面试表现很好，但没有游戏开发经验，而你只能选择其一。你选谁呢？其实，这就是两个条件概率问题P(工作好

10、经验好，

11、基础一般，算法一般）和P(工作好

12、没经验，基础好，算法好）。这个问题就留给面试官来判断了，就我个人而言，对于技术门槛较高需要技术积累的职位，经验更加说明问题，因此，我更倾向于面试者A。20currencydeposit,weprescribeapassonaregularbasis,qilucardaccountonaregularbasis),certificatebondsandsavingsbonds(electronic);3.notdrawnonabanksavingscertificate,certificatebondsapply

13、formortgageloans,acceptingonlythelender算法算法是Google和MS等大公司面试所重点考察的内容。我个人很喜欢算法，曾经参加ACM/ICPC拿过北京赛区的13名。但是，就个人经验来看，我所接触过的绝大多数开发职位而言，算法都不适合作为考察面试者优劣的主要因素。对于普通的非算法性开发职位，考察面试者的算法就相当于考察他打乒乓球好不好一样，与目标“工作好”的相关性太低。就我个人的经验来看，差不多P(工作好

14、算法好)=50%，也就是算法面试没有太大的区分性。甚至，还有一种很不好的情况特别多地出现在算法好的面试者身

15、上，我称之为“只磨刀，不砍柴”。什么意思呢？有类人只对什么A*算法，异步编程，JVM类加载机制这种纯技术问题感兴趣，对实现用户需求毫无兴趣。这类人看起来有一定的技术能力，但是对公司来讲贡献十分有限，甚至不如技术一般但认真负责的人。所以，一旦遇到面试者算法好，我就特别留意考察会不会是这种“只磨刀，不砍柴”的人。另外，虽然我个人不了解Google和MS，但我对于其特别重视考察算法能力的面试策略是持怀疑态度的。即使在这样的世界级大公司，算法虽然重要，但可以想象在项目实施过程所遇到的各种各样问题中，算法问题绝大多数时候不会是主要瓶颈，没有到那种需要每个

16、人都是算法高手的情况。实际上，绝大多数项目真正难点并不是一两个算法瓶颈，甚至也不是单点的技术瓶颈，而是系统性的组织、协调、设计、开发问题，有大量的看起