|
锁定老帖子 主题：从面试别人想到的
精华帖 (13) :: 良好帖 (6) :: 隐藏帖 (7)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：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 最近同志们普遍反应想要降低标准招人。 我后来变换了几种不同的套路，比如跟他一起讨论一个设计方案，不过感觉好像我在给他上课。比如考些灵活的问题，但是往往最后我直接告诉对方我考察的知识点是什么。 |
| 返回顶楼 | |
|
发表时间：2011-03-04
给firesoul做个推理，开个玩笑，别见怪：
firesoul很反感楼主的言论-->firesoul认为楼主的言论不对-->firesoul没做过楼主说的做的事情-->firesoul没有楼主懂的多-->firesoul没有楼主能做的事情多-->firesoul没做过楼主这样级别的东西-->firesoul级别不高-->firesoul...很可怜--->firesoul很愤怒 |
| 返回顶楼 | |
|
发表时间：2011-03-04
最后修改：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 最近同志们普遍反应想要降低标准招人。 我后来变换了几种不同的套路，比如跟他一起讨论一个设计方案，不过感觉好像我在给他上课。比如考些灵活的问题，但是往往最后我直接告诉对方我考察的知识点是什么。 你确定不是由于你官威比较大 对方放不开么? 我的朋友总是能给我新的启发 也许我私下不努力,对于想问的东西,想的比较少 只有与别人讨论时脑子才会转的快点 有关 |
| 返回顶楼 | |
|
发表时间：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 最近同志们普遍反应想要降低标准招人。 我后来变换了几种不同的套路，比如跟他一起讨论一个设计方案，不过感觉好像我在给他上课。比如考些灵活的问题，但是往往最后我直接告诉对方我考察的知识点是什么。 你确定不是由于你官威比较大 对方放不开么? 我的朋友总是能给我新的启发 也许我私下不努力,对于想问的东西,想的比较少 只有与别人讨论时脑子才会转的快点 有关 那些人年龄都比我大，比我工作年头多，不应该吧~~~ 呵呵，我也在反思自己。 我也很喜欢那个讨论过程。 可能我需要更多的观察他们的反应，而不该太着急。 有一次我还特别用事先没思考过的问题，一步步跟他从同一个起点一起思考，这样以避免我思考了很久的问题再问他，会觉得他想的不好 |
| 返回顶楼 | |
|
发表时间：2011-03-08
学到东西了，很好
|
| 返回顶楼 | |
|
发表时间：2011-03-08
这也是我们团队的理想标准。可是现实和理想是有差距的，很难如愿。
难道真的是我们要求太高？还是从业人员整体素质有待提高? 招优秀的人难，是一个普遍现象，归根结底，是什么原因造成的呢？是个人原因、教育方式、社会环境、生存压力还是其他什么原因...原因是复杂的，人也是复杂的。 理想很美好，至少是一个方向。即使达不到，也会向着这个方向努力。 |
| 返回顶楼 | |
|
发表时间：2011-03-08
最后修改：2011-03-08
Talentseeker 写道 这也是我们团队的理想标准。可是现实和理想是有差距的，很难如愿。
难道真的是我们要求太高？还是从业人员整体素质有待提高? 招优秀的人难，是一个普遍现象，归根结底，是什么原因造成的呢？是个人原因、教育方式、社会环境、生存压力还是其他什么原因...原因是复杂的，人也是复杂的。 理想很美好，至少是一个方向。即使达不到，也会向着这个方向努力。 没人想培训只想吃现成的..... 这样的人多数都是团队花时间自己培养出来的. |
| 返回顶楼 | |
|
发表时间：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为了砍价用的伎俩！ |
| 返回顶楼 | |
|
发表时间：2011-03-08
技术深 不一定就开发好
尤其是业务系统开发。 |
| 返回顶楼 | |
|
发表时间：2011-03-09
最后修改：2011-03-09
抛出异常的爱 写道 Talentseeker 写道 这也是我们团队的理想标准。可是现实和理想是有差距的，很难如愿。
难道真的是我们要求太高？还是从业人员整体素质有待提高? 招优秀的人难，是一个普遍现象，归根结底，是什么原因造成的呢？是个人原因、教育方式、社会环境、生存压力还是其他什么原因...原因是复杂的，人也是复杂的。 理想很美好，至少是一个方向。即使达不到，也会向着这个方向努力。 没人想培训只想吃现成的..... 这样的人多数都是团队花时间自己培养出来的. 是可以自己培养出来的，这样对团队的技术带头人的要求自然就非常高了。不光自己技术强，有领导力，有执行力，而且能够把团队的成员凝聚在一起。 找新人培养是可以的，可是要找到非常有潜质的新人，也不那么容易。尤其对于初创阶段的小团队，因为对于大多数新人们而言，可能有影响力的大公司会是他们的首选。 |
| 返回顶楼 | |
