从面试别人想到的

      最近一个月面试了10几个人，有应届毕业生，有在校寻找实习的学生，有工作了两三年的，也有工作了5到10年的，有在外包公司工作的，有目前在世界级外企的。结果是，一无所获。
      想起两年前，研究生二年级上学期开始找工作，面试了几个公司的经历，和一些师弟师妹问我的一些问题，不禁让我想到了很多。主要有两个方面：
      1 我们应该如何面试，才能挖掘出应聘者的真实能力
      2 从面试中，我渐渐的画清楚，一个公司需要什么样的人才，我自己应该如何规划我的未来。
     
      我面试别人掌握两个原则：
      1 此人掌握的主要技能是我们所需要的
      2 此人虽然尚未掌握我们所需要的所有技能，但是从他已经掌握的技能可以看出他的潜力和当前的Level。
      第二点很重要，就像Kent Beck不是Flex高手，但是我相信如果他愿意学习，他很快就会成为Flex的高手。

      我觉得我们招人主要基于以下考虑：
      1 需要某方面专门人才，来和我们现有的人形成互补。
      2 需要一些具有我们项目所需要的技术的人，他的技能会跟我们类似，但即便这样，我们依然希望他会是某方面的专家，比如Spring Security这么一个框架的专长也是Plus。而且，我希望这个人比我强。

   

     我招人的时候希望此人具有以下的气质：
     1 热爱编程，相信软件工艺，也相信软件工程。最近在看Kent Beck的实现模式和Bob大叔的代码整洁之道，我希望他能跟我一样，认为代码是给人看的，好的代码像一篇文章一样。能够反复去雕琢一段代码。但是要理解软件工程，不能为了雕琢每一段代码，而缺乏全局认识。
     2 热爱编程，能够为解决一个问题，写一段漂亮的代码，甚至于为类起一个好的名字而失眠。
     3 热爱编程，把这当作是一项事业，而非仅仅是工作。那种只是想把工作对付完了就OK的人是不适合的。
     4 热爱编程，单纯的用程序交流，人也像好代码一样，干净利落，说话直来直去。大家都很忙，没时间听客套话和绕圈子。     

      就像当年别人面试我的时候那样，我会这样去面试别人：
      1 从简历里挑出我最关心的他所会的技能，比如最近我希望招一个JS高手，最好精通Dojo（我说的精通是真的精通）。
      2 我会问他最擅长的技术（如果此技术不是我们最需要的那个），如果他最擅长的技术都语焉不详，那就没什么意思了。
      3 我会问某项技术全貌上的问题，比如会让对方谈谈Dojo的整个架构，是怎么解决JS领域的一些核心问题的。
      4 我会问一些技术细节，比如Spring的声明式事务处理是怎么实现的，因为这一个问题就暗含了AOP的概念和如何实现，代理模式，线程，JDBC事务处理。如果应聘者看过Spring的源代码，那么说明此人能够花心思追究技术更深层次的东西，具有优秀程序员一个优秀品质：好奇心。如果应聘者没看过Spring的源代码，他能回答上来，说明此人各方面基础知识扎实并能融会贯通去解决问题。同样我会问Hibernate的延迟加载是怎么实现的。
      5 我会问一些工程性问题，比如Spring的依赖注入，Scope为Session的Bean如何注入到Scope为Singleton的Bean。比如如何调整Hibernate查询性能。比如数据库索引会在什么情况下失效，原理是什么。
      6 我会问一些解决方案，比如如何重启服务器后，依然能够保持Session。
      7 我会问一些企业开发中特别重要的问题对方是如何理解的，比如事务，并发，内存管理，异构系统整合，数据库性能优化。
      8 我会问一些特别基础的问题，比如HashSet是如何判断新添加的对象是否已经存在的，如果已经存在，它是不再放进去，还是放进去覆盖之前的。比如ClassLoader的工作原理。
     
      当我面对一些工作了四年以上的人时，多少是有点惴惴，因为会担心对方很牛，我却挖掘不出。后来请教了一位工作了六年的同事，他说一个简单的原则是：
      问他你目前在项目中遇到的问题，因为这些问题都是大家讨论的，深思熟虑的，然后问他的解决方案。

      我面试的这些人，有时让我很感慨，为什么工作了四五年的人，甚至是十年的人，号称自己精通Dojo，但是一些基础性问题都不清楚，因为我是初学者，但是我会买一本Dojo之父写的精通Dojo去学习，甚至于我带的一个大四的实习生都知道去遍历网上所有的Dojo基础资料，然后把源代码看看。我需要的是，当我问及一个问题时，告诉我Dojo正确的做法是什么，而不是仅跟我一样，遇到一个JS问题，只能去网上搜一段代码，改改放到项目中，甚至于那段代码他都不完全理解。比如我现在也在阅读Javascript高级编程指南，以了解细节。
      
       跟一个很牛的同事一起面试别人JS，我觉得那人技术还算熟练，但是我的同事摇摇头说，一个人工作了四年，连如何用JS模拟Java中的类，JS的事件框架是怎么回事都不清楚，怎么能行呢。

       我想，或许，这也是我的奋斗目标：
       1 成为丁字形人才，有一项自己特别精通的技术，比如我的那位同事精通Extjs，精通JBPM，精通Spring Security，那是真的精通，另一位同事精通Lucence，还有的精通JQuery，有的非常熟悉Oracle。
       2 其实我对于我想招的人的要求，就是对自己的基本要求。
         

评论

227 楼 jessie6620 2011-06-24  

学到了很多，不关是技术，还有就是一种态度！

226 楼 清秋一冷 2011-06-21  

社会很需要丁字型的人才，这一点解释和理解，非常到位。
我接触下来，开发类的很多2年3年就想只着都是往管理靠拢，不在乎技术了，往往忽视了“术业有专攻”。
方向的把握固然重要，原本的基础扎实才是前进的基石。

225 楼 busiying119 2011-06-20  

sslaowan 写道

pengzhoushuo 写道

楼主似乎对自己充满了信心，有自信是好的。
但是似乎你还不能服众呀，至少我看了贴子，有一半以上的人是反对你的观点的。
”我们就像爬到一座万丈高崖的半山腰的一群人，进退维谷。“
如果我的猜得没错的话，你做的应用是非常独特的，以致于市面上找不到适用的框架。而且你所在的领域绝对是高新的领域。
我以前所在的公司也是做这样的事情的，分布式文件系统、分布式缓存、我们自己搞了类html的语言，自己实现了语法解析器、自己实现了ORM，可以这么说，除了操作系统以外其他的我们都实现了。但是到后期，我们发现我们做的bug太多了，没有足够的人手来支持那么大的系统，再到最后，我们都把精力放在框架上，应用上的开发减少了，再后来，我们收入减少了，再后来，我们招人的水平降低了，招来的都是刚毕业的应届生，再后来，就是现在了......
放出一两个难题来让大家思考下吧，不要再争论了。

所以我们才需要招聘来所谓的牛人嘛。我们属于精英团队模式，就是Kent Beck说的那种模式。我们做一般应用的都是实习生。

此贴是谈如何去面试别人的，我问题的难度恰好适用于我们要招的人。
我也不是求&助贴，我们有什么问题解决不了跑这来问。
如果你非要问，那就给你一个，有两个矩阵，表示两个结果集，然后要找出第二个跟第一个差异。多了哪些格，少了哪些格，这些多的格子相当于放到了第一个矩阵的什么位置，少的那些格相当于去掉了第一个矩阵什么位置的格子。矩阵最大可以达到100*10000，最小可以变为0。要设计一种结构来标注每个方格，设计一个算法能实现上述要求。内存要尽可能占用的小，速度要尽可能的快，结构要尽可能的可扩展。

楼主可以用着算法给老婆写个qq看图找茬的外挂，我觉得行~，都是大师，我看帖看好久了

224 楼 jw2007 2011-05-07  

我只希望我遇到的面试官别像楼主这样要求这么高就行啦。

223 楼 slyn_2004 2011-03-19  

wdz567 写道

技术深 不一定就开发好
尤其是业务系统开发。

说的很有道理，
企业认同的是你怎样在短的时间里创造出最大的效益。
而不在乎你用的是什么新技术，
本人在世界500强企业有的系统还用asp呢
再者好的架构没有好的业务流程有什么用呢
呵呵，个人看法。。。

222 楼 Talentseeker 2011-03-09  

抛出异常的爱 写道

Talentseeker 写道

这也是我们团队的理想标准。可是现实和理想是有差距的，很难如愿。

难道真的是我们要求太高？还是从业人员整体素质有待提高? 招优秀的人难，是一个普遍现象，归根结底，是什么原因造成的呢？是个人原因、教育方式、社会环境、生存压力还是其他什么原因...原因是复杂的，人也是复杂的。

理想很美好，至少是一个方向。即使达不到，也会向着这个方向努力。

没人想培训只想吃现成的.....
这样的人多数都是团队花时间自己培养出来的.

是可以自己培养出来的，这样对团队的技术带头人的要求自然就非常高了。不光自己技术强，有领导力，有执行力，而且能够把团队的成员凝聚在一起。

找新人培养是可以的，可是要找到非常有潜质的新人，也不那么容易。尤其对于初创阶段的小团队，因为对于大多数新人们而言，可能有影响力的大公司会是他们的首选。

221 楼 wdz567 2011-03-08  

技术深 不一定就开发好
尤其是业务系统开发。

220 楼 BloodyCoder 2011-03-08  

sslaowan 写道

抛出异常的爱 写道

sslaowan 写道

抛出异常的爱 写道

sslaowan 写道

aws 写道

spyker 写道

Bowner 写道

按楼主这个标准，公司会永远缺人，而且说实话，换了是我，肯定也过不了楼主的要求，就算过了而且待遇也符合要求我也不会去上班，呵呵。我招人的时候只有一个目的，我希望招进来的人能开开心心地和团队其它的伙计一起完成一个目标，仅此而已，当然如果双方配合不错，可以成为朋友，那么以后很有可能会再成为同事。

ps：个人认为任何技术都是过眼云烟，只有解决问题的思路才是最重要的。我现在手下就有两个伙计，其中一个工作3年，技术功底一般，只是会在Spring,Hibernate框架下写代码而已，而另一个工作6，7年，技术功底很好，对Spring底层很熟，现在问题来了，相同的业务模块，前者两天搞定，后者一周都没完工，还一堆BUG，到底谁好谁坏呢？呵呵

这么神奇....

没啥神奇的吧
对spring底层了解熟悉并不等于就能做好业务功能开发
开发业务功能更重要的是对业务的理解和分析，对数据结构的理解，绝大多数情况下还包括SQL的能力和前端页面与js脚本的开发能力，再就是经验了，怎么才能更快更好的ctrl&c ctrl&v来实现功能或者通过修改继承现有功能来实现需求等等等

在系统框架已经有更高级的架构师搭好之后，能倒背如流spring的源码又如何，懂JVM怎么实现的，垃圾收集器怎么工作的又如何，懂创建了几个string对象，懂servlet的生命周期又如何，对开发业务模块根本毫无意义

其实这种情况也好理解，比如你的业务系统压根不需要考虑在高并发下的缓存策略（比如Hibernate缓存，比如为了减少创建开销而使用单例但是又面临同步问题的取舍），对内存占用释放也没啥要求，不涉及到并发锁，不涉及到JDBC和存储过程协同事务，不涉及到异构系统的服务调用，等等吧。
而且有时可能看到一个高手写了一堆代码，用以解决浏览器back按钮问题，解决并发问题（如果你们公司恰好没有QA测试这个方面，而这个错误恰好在并发数达到50时才会出现，哈，那个一般程序员还被认为更优秀，而高手反倒写了一堆让人看不懂的代码），解决可扩展性问题，等等，比那个一般程序员开发同样“业务”功能的模块由于考虑了更多问题，系统更高效稳定，结构更优雅，因此花费了更多时间。

而正是不少企业的技术领导不理解这一点，才会有开发业务系统不需要精通技术的错误，重业务而轻技术，学习也是这么教育的，可悲啊。

当然高手写的代码更烂!
QA不测试 的功能
加入纯ZB

最近同志们普遍反应想要降低标准招人。
我后来变换了几种不同的套路，比如跟他一起讨论一个设计方案，不过感觉好像我在给他上课。比如考些灵活的问题，但是往往最后我直接告诉对方我考察的知识点是什么。

你确定不是由于你官威比较大
对方放不开么?
我的朋友总是能给我新的启发
也许我私下不努力,对于想问的东西,想的比较少
只有与别人讨论时脑子才会转的快点 有关

那些人年龄都比我大，比我工作年头多，不应该吧~~~
呵呵，我也在反思自己。
我也很喜欢那个讨论过程。
可能我需要更多的观察他们的反应，而不该太着急。

有一次我还特别用事先没思考过的问题，一步步跟他从同一个起点一起思考，这样以避免我思考了很久的问题再问他，会觉得他想的不好

告诉你为啥人家不发表意见，那是因为人家也不知道你是个什么品行的人，来面试的就是想找个饭碗，怕遇到小人说多了得罪面试官，一般情况下都顺着说！你还真以为别人啥都不懂呢？面试的时候多看看人家的优点，别逮到人家的缺点就抓住不放，那是傻屄hr为了砍价用的伎俩！

219 楼 抛出异常的爱 2011-03-08  

Talentseeker 写道

这也是我们团队的理想标准。可是现实和理想是有差距的，很难如愿。

难道真的是我们要求太高？还是从业人员整体素质有待提高? 招优秀的人难，是一个普遍现象，归根结底，是什么原因造成的呢？是个人原因、教育方式、社会环境、生存压力还是其他什么原因...原因是复杂的，人也是复杂的。

理想很美好，至少是一个方向。即使达不到，也会向着这个方向努力。

没人想培训只想吃现成的.....
这样的人多数都是团队花时间自己培养出来的.

218 楼 Talentseeker 2011-03-08  

这也是我们团队的理想标准。可是现实和理想是有差距的，很难如愿。

难道真的是我们要求太高？还是从业人员整体素质有待提高? 招优秀的人难，是一个普遍现象，归根结底，是什么原因造成的呢？是个人原因、教育方式、社会环境、生存压力还是其他什么原因...原因是复杂的，人也是复杂的。

理想很美好，至少是一个方向。即使达不到，也会向着这个方向努力。

217 楼 fishernew 2011-03-08  

学到东西了，很好

216 楼 sslaowan 2011-03-07  

抛出异常的爱 写道

sslaowan 写道

抛出异常的爱 写道

sslaowan 写道

aws 写道

spyker 写道

Bowner 写道

按楼主这个标准，公司会永远缺人，而且说实话，换了是我，肯定也过不了楼主的要求，就算过了而且待遇也符合要求我也不会去上班，呵呵。我招人的时候只有一个目的，我希望招进来的人能开开心心地和团队其它的伙计一起完成一个目标，仅此而已，当然如果双方配合不错，可以成为朋友，那么以后很有可能会再成为同事。

ps：个人认为任何技术都是过眼云烟，只有解决问题的思路才是最重要的。我现在手下就有两个伙计，其中一个工作3年，技术功底一般，只是会在Spring,Hibernate框架下写代码而已，而另一个工作6，7年，技术功底很好，对Spring底层很熟，现在问题来了，相同的业务模块，前者两天搞定，后者一周都没完工，还一堆BUG，到底谁好谁坏呢？呵呵

这么神奇....

没啥神奇的吧
对spring底层了解熟悉并不等于就能做好业务功能开发
开发业务功能更重要的是对业务的理解和分析，对数据结构的理解，绝大多数情况下还包括SQL的能力和前端页面与js脚本的开发能力，再就是经验了，怎么才能更快更好的ctrl&c ctrl&v来实现功能或者通过修改继承现有功能来实现需求等等等

在系统框架已经有更高级的架构师搭好之后，能倒背如流spring的源码又如何，懂JVM怎么实现的，垃圾收集器怎么工作的又如何，懂创建了几个string对象，懂servlet的生命周期又如何，对开发业务模块根本毫无意义

其实这种情况也好理解，比如你的业务系统压根不需要考虑在高并发下的缓存策略（比如Hibernate缓存，比如为了减少创建开销而使用单例但是又面临同步问题的取舍），对内存占用释放也没啥要求，不涉及到并发锁，不涉及到JDBC和存储过程协同事务，不涉及到异构系统的服务调用，等等吧。
而且有时可能看到一个高手写了一堆代码，用以解决浏览器back按钮问题，解决并发问题（如果你们公司恰好没有QA测试这个方面，而这个错误恰好在并发数达到50时才会出现，哈，那个一般程序员还被认为更优秀，而高手反倒写了一堆让人看不懂的代码），解决可扩展性问题，等等，比那个一般程序员开发同样“业务”功能的模块由于考虑了更多问题，系统更高效稳定，结构更优雅，因此花费了更多时间。

而正是不少企业的技术领导不理解这一点，才会有开发业务系统不需要精通技术的错误，重业务而轻技术，学习也是这么教育的，可悲啊。

当然高手写的代码更烂!
QA不测试 的功能
加入纯ZB

最近同志们普遍反应想要降低标准招人。
我后来变换了几种不同的套路，比如跟他一起讨论一个设计方案，不过感觉好像我在给他上课。比如考些灵活的问题，但是往往最后我直接告诉对方我考察的知识点是什么。

你确定不是由于你官威比较大
对方放不开么?
我的朋友总是能给我新的启发
也许我私下不努力,对于想问的东西,想的比较少
只有与别人讨论时脑子才会转的快点 有关

那些人年龄都比我大，比我工作年头多，不应该吧~~~
呵呵，我也在反思自己。
我也很喜欢那个讨论过程。
可能我需要更多的观察他们的反应，而不该太着急。

有一次我还特别用事先没思考过的问题，一步步跟他从同一个起点一起思考，这样以避免我思考了很久的问题再问他，会觉得他想的不好

215 楼 抛出异常的爱 2011-03-04  

sslaowan 写道

抛出异常的爱 写道

sslaowan 写道

aws 写道

spyker 写道

Bowner 写道

按楼主这个标准，公司会永远缺人，而且说实话，换了是我，肯定也过不了楼主的要求，就算过了而且待遇也符合要求我也不会去上班，呵呵。我招人的时候只有一个目的，我希望招进来的人能开开心心地和团队其它的伙计一起完成一个目标，仅此而已，当然如果双方配合不错，可以成为朋友，那么以后很有可能会再成为同事。

ps：个人认为任何技术都是过眼云烟，只有解决问题的思路才是最重要的。我现在手下就有两个伙计，其中一个工作3年，技术功底一般，只是会在Spring,Hibernate框架下写代码而已，而另一个工作6，7年，技术功底很好，对Spring底层很熟，现在问题来了，相同的业务模块，前者两天搞定，后者一周都没完工，还一堆BUG，到底谁好谁坏呢？呵呵

这么神奇....

没啥神奇的吧
对spring底层了解熟悉并不等于就能做好业务功能开发
开发业务功能更重要的是对业务的理解和分析，对数据结构的理解，绝大多数情况下还包括SQL的能力和前端页面与js脚本的开发能力，再就是经验了，怎么才能更快更好的ctrl&c ctrl&v来实现功能或者通过修改继承现有功能来实现需求等等等

在系统框架已经有更高级的架构师搭好之后，能倒背如流spring的源码又如何，懂JVM怎么实现的，垃圾收集器怎么工作的又如何，懂创建了几个string对象，懂servlet的生命周期又如何，对开发业务模块根本毫无意义

其实这种情况也好理解，比如你的业务系统压根不需要考虑在高并发下的缓存策略（比如Hibernate缓存，比如为了减少创建开销而使用单例但是又面临同步问题的取舍），对内存占用释放也没啥要求，不涉及到并发锁，不涉及到JDBC和存储过程协同事务，不涉及到异构系统的服务调用，等等吧。
而且有时可能看到一个高手写了一堆代码，用以解决浏览器back按钮问题，解决并发问题（如果你们公司恰好没有QA测试这个方面，而这个错误恰好在并发数达到50时才会出现，哈，那个一般程序员还被认为更优秀，而高手反倒写了一堆让人看不懂的代码），解决可扩展性问题，等等，比那个一般程序员开发同样“业务”功能的模块由于考虑了更多问题，系统更高效稳定，结构更优雅，因此花费了更多时间。

而正是不少企业的技术领导不理解这一点，才会有开发业务系统不需要精通技术的错误，重业务而轻技术，学习也是这么教育的，可悲啊。

当然高手写的代码更烂!
QA不测试 的功能
加入纯ZB

最近同志们普遍反应想要降低标准招人。
我后来变换了几种不同的套路，比如跟他一起讨论一个设计方案，不过感觉好像我在给他上课。比如考些灵活的问题，但是往往最后我直接告诉对方我考察的知识点是什么。

你确定不是由于你官威比较大
对方放不开么?
我的朋友总是能给我新的启发
也许我私下不努力,对于想问的东西,想的比较少
只有与别人讨论时脑子才会转的快点 有关

214 楼 中国大人 2011-03-04  

给firesoul做个推理，开个玩笑，别见怪：
firesoul很反感楼主的言论-->firesoul认为楼主的言论不对-->firesoul没做过楼主说的做的事情-->firesoul没有楼主懂的多-->firesoul没有楼主能做的事情多-->firesoul没做过楼主这样级别的东西-->firesoul级别不高-->firesoul...很可怜--->firesoul很愤怒

213 楼 sslaowan 2011-03-04  

抛出异常的爱 写道

sslaowan 写道

aws 写道

spyker 写道

Bowner 写道

按楼主这个标准，公司会永远缺人，而且说实话，换了是我，肯定也过不了楼主的要求，就算过了而且待遇也符合要求我也不会去上班，呵呵。我招人的时候只有一个目的，我希望招进来的人能开开心心地和团队其它的伙计一起完成一个目标，仅此而已，当然如果双方配合不错，可以成为朋友，那么以后很有可能会再成为同事。

ps：个人认为任何技术都是过眼云烟，只有解决问题的思路才是最重要的。我现在手下就有两个伙计，其中一个工作3年，技术功底一般，只是会在Spring,Hibernate框架下写代码而已，而另一个工作6，7年，技术功底很好，对Spring底层很熟，现在问题来了，相同的业务模块，前者两天搞定，后者一周都没完工，还一堆BUG，到底谁好谁坏呢？呵呵

这么神奇....

没啥神奇的吧
对spring底层了解熟悉并不等于就能做好业务功能开发
开发业务功能更重要的是对业务的理解和分析，对数据结构的理解，绝大多数情况下还包括SQL的能力和前端页面与js脚本的开发能力，再就是经验了，怎么才能更快更好的ctrl&c ctrl&v来实现功能或者通过修改继承现有功能来实现需求等等等

在系统框架已经有更高级的架构师搭好之后，能倒背如流spring的源码又如何，懂JVM怎么实现的，垃圾收集器怎么工作的又如何，懂创建了几个string对象，懂servlet的生命周期又如何，对开发业务模块根本毫无意义

其实这种情况也好理解，比如你的业务系统压根不需要考虑在高并发下的缓存策略（比如Hibernate缓存，比如为了减少创建开销而使用单例但是又面临同步问题的取舍），对内存占用释放也没啥要求，不涉及到并发锁，不涉及到JDBC和存储过程协同事务，不涉及到异构系统的服务调用，等等吧。
而且有时可能看到一个高手写了一堆代码，用以解决浏览器back按钮问题，解决并发问题（如果你们公司恰好没有QA测试这个方面，而这个错误恰好在并发数达到50时才会出现，哈，那个一般程序员还被认为更优秀，而高手反倒写了一堆让人看不懂的代码），解决可扩展性问题，等等，比那个一般程序员开发同样“业务”功能的模块由于考虑了更多问题，系统更高效稳定，结构更优雅，因此花费了更多时间。

而正是不少企业的技术领导不理解这一点，才会有开发业务系统不需要精通技术的错误，重业务而轻技术，学习也是这么教育的，可悲啊。

当然高手写的代码更烂!
QA不测试 的功能
加入纯ZB

最近同志们普遍反应想要降低标准招人。
我后来变换了几种不同的套路，比如跟他一起讨论一个设计方案，不过感觉好像我在给他上课。比如考些灵活的问题，但是往往最后我直接告诉对方我考察的知识点是什么。

212 楼 中国大人 2011-03-04  

每个人的追求都不一样，像楼主这样的，愿意读研究生，本身就是有追求的人。很多人本科出来，混日子，混工资，拿到钱就行，做完项目就行，编程谈不上喜欢不喜欢，这种人怎么会有兴趣在业余研究技术细节呢？面人，当然是要找合适岗位的人，不同岗位不同标准，楼主要求的素质，当然是最能在各种技术岗胜任的，相当于理想化的目标，要往这个方向要人。低下很多持反对态度的，估计很多10年下来还是一个底层编码人员。

211 楼 liruimin 2011-03-02  

向LZ学习，看到这篇文章之后，感觉自己说好听点什么都会一点，换一句话说，那是什么都不会；对自己现在会的就要在进一步，不要求所有的都精通，只要有一个精通，不会自己在去好好学习。

210 楼 yuky1327 2011-02-27  

chris_in 写道

向楼主学习，让我茅塞顿开，谢谢了！

+1

209 楼 sunway0628 2011-02-26  

所谓的眼高手低

208 楼 laryun 2011-02-17  

漂亮  写的很好 受启发