什么样的技术人才最受欢迎？说下我个人的感受

什么样的技术人才最受欢迎？说下我个人的感受

    也工作几年了，陆陆续续做过很多不同的项目，也面试过不少人，结合我个人的经验及面试的心得，稍微总结一下。
    对于没有工作经验的，一般都是看他的基本功和他的态度；
    对于有工作经验的，怎么看这个人的潜力和水平？
我个人觉得一般做题这东西不太靠谱，面试者他熟悉的东西和他的项目经验未必被你的题覆盖到，另外在写代码过程中，未必会记下所有细节，高人一般都是在用到的时候去资料中查细节问题。大脑中存着太多细节，可能就没有空间去存放一些更重要的东西了。

    我面试，一般一开始就问他有没有处理过什么疑难杂症，疑难杂症一般都是技术问题，要花费一周、一天或几个时间去攻关解决的，可能一个人还搞不定，还需要多人一起搞。
    要解决疑难杂症，一方面需要比较广的知识面，另一方面也需要良好的心理素质。
    就知识面而言，比如，一个新员工要一天解决的问题，某老员工可能只需要几分钟，因为某些问题老员工他可能之前已经花了很多精力去攻关过，这是知识面的一方面，一般我们称之为工作经验，另外知识面还包含业务知识、编程技术、学习能力等，无法用几句话概括（至少我还没有能力用几句话把它概括）。在不同项目中，可能要用到不同的编程语言，或者同种语言中的不同架构和不同组件，数据库、操作系统、编译器、平台等都涉及到不同的技术细节，你涉及过的东西越多，你的视野也就开阔。我个人感觉，如果你做过不同类型的项目，开发过不同的东西（可能会基于不同的编程语言），你的视野一般会比一直做同一个项目的人要开阔，毕竟接触的东西要多，而且需要学习的内容也会多一些。
    心理素质，我个人总结就是信心+耐心+决心。信心最重要，遇到难题，大家都会摸不着头脑，这个很正常，关键是你如何能战胜自己的心理恐慌，信心就很关键了，即使是没有处理过的问题，只要你有信心，你很快就能镇定下来，把心思花在具体的问题上；哈哈，信心是第一步，敢面对难题，我们还需要做好打持久战的准备，还需要有耐心；有时有些难题，会花上几个小时、一天、一周甚至几周才能搞定，这么长的时间内，你会不停地郁闷、痛苦，但你还要找方法去解决问题，哈哈，如果把解决问题的目的给忘了，那结果你知道的；至少决心嘛，一般我们的郁闷达到最高点时，可能就越接近问题的根因了，这时如果扛不住，就功亏一篑了。下定决心吧，不把问题搞定，就不吃饭、不睡觉、不回家、不去见女朋友，还有不干嘛，你自己想吧。只要你有这个决心，那问题就一定能搞定，如果还搞不定，就去找你的领导吧。
    我个人遇到过的难题，如果按解决问题的时间长度来算，应该有20个吧，哈哈。过程确实很痛苦，但问题解决过后豁然，也只有个人知道；你对某个问题的认识，或者对某个知识面的把握，可能一下子就进了一步。

    如果你经常面试人，可以试试我的方法；如果你打算被面试，也考虑一下自己工作几年内遇到过哪些难题；如果工作一两年一个都没有遇到过或者一个都想不起来，哈哈，考虑一下自己的工作态度是不是有问题？就算自己没有亲自解决，也得耳睹目染过别人解决问题的过程吧？如果这个都没有经历过，你是不是对技术一点追求都没有？如果你能想起来那么几个，恭喜你，把过程好好总结一下吧，能总结出的东西越多，那你的升值空间就越大，在解决问题、总结问题的过程中，相信你会有大的提升。

 

 

 

再补充一些我个人认为比较重要的知识点：

1、精通某一编程语言（所谓精通，比如Java，除了熟悉使用常用的工具类、语言特性外，还要对JVM的内部机制要有所以了解，比如JVM的内存管理，类加载机制等）；

2、某种脚本（Windows的Bat、Linux的Shell），有时熟练使用某些脚本会带来意想不到的便利；

3、对涉及到的协议的掌握，比如你搞页面开发，HTML协议的RFC一定好好看看（比如之前我处理的几个问题，都与Http 1.0与Http 1.1的特性差异有关）；

4、对网络知识要有所了解，及对抓包工具（Wireshark）的熟练使用，在处理一些疑难问题（如各种乱码问题）时，会在你定位问题给你很大的帮助；

5、对数据库要有一些基本的认识，比如常用的sql调优等；

 

我给大家的建议是，至少要在某一方面做到足够深入，让大家知道你在某一方面很强，处理这方面的问题时你就是专家；然后再扩展自己的知识面，尽可能多了解一点其它知识点，至少在遇到这方面的问题时，你知道去哪里找资料；不要让自己什么都学精通，你没有那么多精力的。

你要相信平时的积累会在某个时间点发挥出价值，所以真的不用担心自己的积累会无用武之地。

 

另外，我个人觉得最重要的一点是掌握方法，就像处理疑难问题，处理得次数多了，你会从中找到一些规律和窍门的，这个就是我说的方法。

在 平时的学习和工作的过程中，要注意总结，把自己认为重要的或对自己有帮助的及时输出到文档中；刚开始可能总结不出什么，但多总结几次，可能你就能总结出很 多东西，其实这就是你在进步。哪天你突然发现自己在解决问题时是按照某些特定的步骤去定位的，并且这样处理问题基本能得到解决，相信你的能力已经提高了很 多。

 

所谓功在平时，平时的积累最重要，遇到问题要淡定，积极而平静的心态会让你走得更远。

评论

10 楼 神之小丑 2011-06-21  

我那天去面试，面到最后领导了，
领导就问我 操作系统 问我算法，因为工作后，学校里的很多东西忘了

所以就没打上来，然后他就说我技术不行，

然后我就跟他理论（已经带情绪了，争论了很久），

不过还好，最后那领导改变观点了

9 楼 黑白两相望 2011-06-21  

jackra 写道

zhao3546 写道

Durian 写道

还要对JVM的内部机制要有所以了解，比如JVM的内存管理，类加载机制等

这些东西有啥用？

我不知道你有没有遇到过Java内存泄漏的问题，Java内存泄漏还分几种，感兴趣自己去找找。
如果你写的代码只有几个人用，可能有些问题你永远都不用考虑；
但假如你的代码每天有几万人、几十万人在用，很多小问题可能都会无限放大变成大问题。

如果你不能深入地去学习一些东西，而只停留在List、Map等几个常用类的使用上，我觉得你应该考虑一下你以后要怎么办。

内存泄漏？我见过，有文件句柄不够的，也有数据库连接超越最大允许数的，还有各种不关游标的，各种不关statment的。
程序员不一定必须要犯这样的错误，片面的强调这些，其实不见得是好事。很难想象在一组嵌套的N千行的function里，一个人能控制自己所有的逻辑代码。一些有好习惯和良好的素质教育的程序员，就算没有经验，也不见得就一定要犯你说的错误，他们在创造外部资源依赖的时候，或许已经就对外部资源进行了关闭。这些其实是基础知识，接受过良好的编程教育或者认真的对待这些经验问题的人，是可以通过学习学到的。
对于资源管理的知识，有些人当回事，有些人不当回事。很难说，把结构搞的很复杂，然后自己的资源控制不住，到底是水平问题，还是智商问题，或者是根本没用心思的问题。

程序员的基本素质，永远不会认为自己没有错误，而是计算机在犯错误。任何的错误都可能是由人导致的，而绝对不会是机器。你可以说JVM会有差异，也可以说操作系统有问题，但是机器永远代表的是现实存在的物理规律，而不是可以随便犯违反规律错误的带有情绪和不确定因素的活物。

聪明的程序员，要想办法防止自己陷入麻烦，进而防止团队陷入麻烦。所以聪明的程序员，应该学会挑选合适的团队、合适的领导、合适的团队，更聪明的程序员，就得做到“宁武子邦有道则知，邦无道则愚；其知可及也，其愚不可及也。”该钓鱼的时候钓鱼，该摸鱼的时候摸鱼吧。

事实上，聪明的程序员，会把麻烦的事情想到合适的解决办法。比如对于可能变化的设计，保存足够的生成代码的资料（详细设计），比如避免重复劳动而花费写时间为需要重复做的事情写脚本，还有必须发现项目的潜在危险（比如不确定的需求，无法确定的客户态度，以及无法确定的领导结构）。但是，其实聪明的程序员，不见得是成功的，毕竟现阶段的环境就是如此，天才也不一定能胜的过天朝。呵呵。

也许有时候，技术并不是真正的核心内容也说不定。永远不要在程序上谈论程序。单纯的程序，什么都不是。只是一些消耗电能的指令而已。

习惯的确很重要

8 楼 pangpang514 2011-06-21  

“永远不要在程序上谈论程序。单纯的程序，什么都不是。只是一些消耗电能的指令而已。”
必须ding你了。。。。。我ding你的肺！！！！！

7 楼 yizhilong28 2011-06-21  

jackra 写道

zhao3546 写道

Durian 写道

还要对JVM的内部机制要有所以了解，比如JVM的内存管理，类加载机制等

这些东西有啥用？

我不知道你有没有遇到过Java内存泄漏的问题，Java内存泄漏还分几种，感兴趣自己去找找。
如果你写的代码只有几个人用，可能有些问题你永远都不用考虑；
但假如你的代码每天有几万人、几十万人在用，很多小问题可能都会无限放大变成大问题。

如果你不能深入地去学习一些东西，而只停留在List、Map等几个常用类的使用上，我觉得你应该考虑一下你以后要怎么办。

内存泄漏？我见过，有文件句柄不够的，也有数据库连接超越最大允许数的，还有各种不关游标的，各种不关statment的。
程序员不一定必须要犯这样的错误，片面的强调这些，其实不见得是好事。很难想象在一组嵌套的N千行的function里，一个人能控制自己所有的逻辑代码。一些有好习惯和良好的素质教育的程序员，就算没有经验，也不见得就一定要犯你说的错误，他们在创造外部资源依赖的时候，或许已经就对外部资源进行了关闭。这些其实是基础知识，接受过良好的编程教育或者认真的对待这些经验问题的人，是可以通过学习学到的。
对于资源管理的知识，有些人当回事，有些人不当回事。很难说，把结构搞的很复杂，然后自己的资源控制不住，到底是水平问题，还是智商问题，或者是根本没用心思的问题。

程序员的基本素质，永远不会认为自己没有错误，而是计算机在犯错误。任何的错误都可能是由人导致的，而绝对不会是机器。你可以说JVM会有差异，也可以说操作系统有问题，但是机器永远代表的是现实存在的物理规律，而不是可以随便犯违反规律错误的带有情绪和不确定因素的活物。

聪明的程序员，要想办法防止自己陷入麻烦，进而防止团队陷入麻烦。所以聪明的程序员，应该学会挑选合适的团队、合适的领导、合适的团队，更聪明的程序员，就得做到“宁武子邦有道则知，邦无道则愚；其知可及也，其愚不可及也。”该钓鱼的时候钓鱼，该摸鱼的时候摸鱼吧。

事实上，聪明的程序员，会把麻烦的事情想到合适的解决办法。比如对于可能变化的设计，保存足够的生成代码的资料（详细设计），比如避免重复劳动而花费写时间为需要重复做的事情写脚本，还有必须发现项目的潜在危险（比如不确定的需求，无法确定的客户态度，以及无法确定的领导结构）。但是，其实聪明的程序员，不见得是成功的，毕竟现阶段的环境就是如此，天才也不一定能胜的过天朝。呵呵。

也许有时候，技术并不是真正的核心内容也说不定。永远不要在程序上谈论程序。单纯的程序，什么都不是。只是一些消耗电能的指令而已。

如果执泥于技术，会出现很搞笑的状况，学着学着就看起道德经起来，哈哈

6 楼 Durian 2011-06-21  

zhao3546 写道

Durian 写道

还要对JVM的内部机制要有所以了解，比如JVM的内存管理，类加载机制等

这些东西有啥用？

我不知道你有没有遇到过Java内存泄漏的问题，Java内存泄漏还分几种，感兴趣自己去找找。
如果你写的代码只有几个人用，可能有些问题你永远都不用考虑；
但假如你的代码每天有几万人、几十万人在用，很多小问题可能都会无限放大变成大问题。

如果你不能深入地去学习一些东西，而只停留在List、Map等几个常用类的使用上，我觉得你应该考虑一下你以后要怎么办。

遇到过几次内存溢出。
eclipse编译大工程时候溢出，只要设置eclipse的初始化参数 =256m就可以。
死循环也会溢出
递归次数过大肯定溢出
不确定数据连接不关闭，连接数占满是否溢出？
这些问题靠jvm能解决?

另外，看类加载有啥用?

5 楼 fireboy 2011-06-21  

忍不住跑上来透透气
‘单纯的程序，什么都不是。只是一些消耗电能的指令而已。’
太经典了。。顶楼上。

4 楼 jackra 2011-06-20  

zhao3546 写道

Durian 写道

还要对JVM的内部机制要有所以了解，比如JVM的内存管理，类加载机制等

这些东西有啥用？

我不知道你有没有遇到过Java内存泄漏的问题，Java内存泄漏还分几种，感兴趣自己去找找。
如果你写的代码只有几个人用，可能有些问题你永远都不用考虑；
但假如你的代码每天有几万人、几十万人在用，很多小问题可能都会无限放大变成大问题。

如果你不能深入地去学习一些东西，而只停留在List、Map等几个常用类的使用上，我觉得你应该考虑一下你以后要怎么办。

内存泄漏？我见过，有文件句柄不够的，也有数据库连接超越最大允许数的，还有各种不关游标的，各种不关statment的。
程序员不一定必须要犯这样的错误，片面的强调这些，其实不见得是好事。很难想象在一组嵌套的N千行的function里，一个人能控制自己所有的逻辑代码。一些有好习惯和良好的素质教育的程序员，就算没有经验，也不见得就一定要犯你说的错误，他们在创造外部资源依赖的时候，或许已经就对外部资源进行了关闭。这些其实是基础知识，接受过良好的编程教育或者认真的对待这些经验问题的人，是可以通过学习学到的。
对于资源管理的知识，有些人当回事，有些人不当回事。很难说，把结构搞的很复杂，然后自己的资源控制不住，到底是水平问题，还是智商问题，或者是根本没用心思的问题。

程序员的基本素质，永远不会认为自己没有错误，而是计算机在犯错误。任何的错误都可能是由人导致的，而绝对不会是机器。你可以说JVM会有差异，也可以说操作系统有问题，但是机器永远代表的是现实存在的物理规律，而不是可以随便犯违反规律错误的带有情绪和不确定因素的活物。

聪明的程序员，要想办法防止自己陷入麻烦，进而防止团队陷入麻烦。所以聪明的程序员，应该学会挑选合适的团队、合适的领导、合适的团队，更聪明的程序员，就得做到“宁武子邦有道则知，邦无道则愚；其知可及也，其愚不可及也。”该钓鱼的时候钓鱼，该摸鱼的时候摸鱼吧。

事实上，聪明的程序员，会把麻烦的事情想到合适的解决办法。比如对于可能变化的设计，保存足够的生成代码的资料（详细设计），比如避免重复劳动而花费写时间为需要重复做的事情写脚本，还有必须发现项目的潜在危险（比如不确定的需求，无法确定的客户态度，以及无法确定的领导结构）。但是，其实聪明的程序员，不见得是成功的，毕竟现阶段的环境就是如此，天才也不一定能胜的过天朝。呵呵。

也许有时候，技术并不是真正的核心内容也说不定。永远不要在程序上谈论程序。单纯的程序，什么都不是。只是一些消耗电能的指令而已。

3 楼 zhao3546 2011-06-20  

Durian 写道

还要对JVM的内部机制要有所以了解，比如JVM的内存管理，类加载机制等

这些东西有啥用？

我不知道你有没有遇到过Java内存泄漏的问题，Java内存泄漏还分几种，感兴趣自己去找找。
如果你写的代码只有几个人用，可能有些问题你永远都不用考虑；
但假如你的代码每天有几万人、几十万人在用，很多小问题可能都会无限放大变成大问题。

如果你不能深入地去学习一些东西，而只停留在List、Map等几个常用类的使用上，我觉得你应该考虑一下你以后要怎么办。

2 楼 Durian 2011-06-20  

还要对JVM的内部机制要有所以了解，比如JVM的内存管理，类加载机制等

这些东西有啥用？

1 楼 antonia 2011-06-16  

刚开始可能总结不出什么，但多总结几次，可能你就能总结出很多东西，其实这就是你在进步。  赞成！