今天我才仔细看这篇文章,我敢说,这个面试者没有水平,不是伯乐,相马要根据具体目标来看,而不是通用标准。

主要依据这句话:
>用jsp,struts,hibernate,spring做业务逻辑.
>十几年都是做这些吗?

15年做业务逻辑,如果他没掌握什么建模专业知识,那么这个人至少是一个业务专家,当前DSL趋势下,业务专家可以不了解技术架构,而面试者竟然面试别人的技术架构细节,更有甚者面试JVM原理,可惜我做了近20年软件,我也不知道JVM原理,但是如果我想知道,我会知道的。

为什么不面试别人Linu内核呢?

20年做业务逻辑,这个目标值得提倡,现实中实现缺乏业务专家,满眼都是技术人员充当业务专家,技术人员基本都是简历驱动型,也就是让自己建立看上去很玄,紧跟技术潮流,新技术都掌握,而做业务逻辑,则是相当战争中的粮草,表面不风光,重要性相当高,甚至高于前线将士,任何一场持久战最后是由经济决定的。

业务逻辑就是软件开发中的经济地位,枯燥,总是那么模型,翻来覆去,不断重构,不断对事物有新的认识。DDD一书中对这种业务逻辑重视几乎是满篇都是。

15年你积累什么?积累了业务经验,兄弟好样的,我挺你,让那些不开眼的毛小伙子见鬼去吧。碰到这种面试官是你耻辱。

2010年04月30日 06:52 "banq"的内容

评论事物时,我们有太多成者为王 败者为寇 观点,PHP做起来快,然后开源,会填补某个领域的空白,马上普及应用,确实能够获得成功,但是我们没看到有多少真正大型系统是依赖对开源PHP进行维护拓展出来的,关键是PHP做得快,后面就没戏了。
...


不抬杠,我收回我的话。

我也觉得这片文章是忽悠人的,如果能把他的问题都正确回答了就是人形WIKI.

我原来的室友,现在做项目经理。他当年找工作遇到很多变态的面试题。现在他也开始面试别人,就喜欢把自己晚上睡觉前在书上了解的一点细枝末节的东西拿出来难为别人。我问他这样有意思没,他说他就喜欢看别人傻眼的样子。但,他们公司的产品似乎并不令人满意。
现在很多面试,一不考量面试者是否是一个认真负责的人(把这个工作完全推给HR),二不看面试者的思维(要么尽是些光怪陆离的逻辑题),三是笔试面试题本身就模棱两可、粗制滥造。
提倡在反思中面试别人,反思自己的态度,反思自己的价值,反思自己的思维,反思自己的技术。个人认为这样能招到对公司有较大价值的人。既然自己公司所做的东西并不好,那为什么一定要在面试别人的时候先假定自己或者所处企业是个中好手呢。

现在IT行业的所谓高级人士,貌似脾气向乔布斯靠拢,产品向山寨化靠拢。
[该贴被macwrit于2010-05-04 11:36修改过]

呵呵我觉得bang说的有道理,楼主在面试时,简直故意刁难别人?gc原理?分代?明白和不明白这些道理有什么意义吗?比如根据现代java虚拟机实现,如果你一个对象生成后很快不再被使用(方法里的局部变量),那么它将很快在新生代被垃圾收集。可是明白这个道理有何实实在在的好处?我们不是一直在使用很多局部变量吗(这是java提倡的)?所以楼主有点抠门了,你倒不妨面试他一些以前的项目经验,或者更基础些的算法之类,或者干脆跟他讨论面向对象和设计模式,这有时候很容易看出来一个人的面向对象思路是怎么样的。

2010年05月05日 08:31 "newthinker"的内容
楼主在面试时,简直故意刁难别人? ...
囧。。那个啥。。跟lz没关系的。。我只是转而已。只不过象那样的面试者真的是挺多的,浸淫在一些不为人知的小技巧上又鸣鸣得意的真的是不少。

确实。。。我见过的几个牛人,都不是很全面型的,反倒是在某方面很专,专得让我望尘莫及啊。。。

这哥们上班时间归上班时间,下班时间完全回归到个人的生活,是没有错的。
错误的是,他想要的职位和他对自己的付出相差太远。

我只是觉得这么武断的否定一个人是不对的,但是这个面试官所问的问题,是他所需要对方熟悉的。比如说JVM的GC原理之类的,你可以不懂,但是这个职位需要你懂,而且这些东西不是只看看就能懂的,需要大量的经验去实际应用。所以我觉得,面试题没有错,错的在于武断的评价一个人。

谈谈一般工作流中流程引擎处理的对象模型.
答:我做的都是特定于某个需求的流程,不了解通用的工作流处理的原理.(十五年的经验不知道一点模型抽象,一直在造轮子).
---------------------------
从这句问答可以看出这个人没做过工作流。如果做过工作流,必然知道流程包、流程、活动、迁移、流程和活动参数这些起码的对象模型。不管是通用或者特定某个需求的工作流,总离不开这些吧?

同意“jentrees”的观点,一个砌砖匠,就是干了一辈子,然后让他去做一个摩天大楼的设计师,然后,你就问他:地基怎么打能防止8级地震,一共要用多少钢材和水泥,需要多少人力,工期如何估算。。。

他只能瞠目结舌了。

我接触过一个公司的架构师,他老人家就是把IBM的一个废弃的SF项目的一些代码搞到了,然后自己琢磨,再把微软当时正在规划的MBF的点点滴滴都搜集来,就可以提出一个“中国的世界级”产品的架构,在项目的最开始,考虑支持的数据库时,拍着胸脯说,我们只支持SQL server,但是几年后,当该项目又要改变初衷,需要支持Oracle了。。。我佩服他的学习能力。哈哈!

2010年05月03日 09:36 "banq"的内容
相马要根据具体目标来看,而不是通用标准 ...

非常赞同这句话。

实际工作过程中的很多事不是会调调优、了解点底层技术就能解决了或者说是就能解决的恰当,关键还是看人的头脑。像我们以前的一个项目,需要采集一个地区的数据,刚开始时按传统思路提出架设一个网上申报系统来解决,客户对这种系统上线很打怵,得调动各种资源不说,时间也得用上好几个月,最后采用了固定格式的excel+vba的方式解决了,通过excel的表格样式来模拟录入界面,通过超链接来回跳转,通过少量的vba代码实现录入控制以及信息统计,很简单,一是免安装,也不用架设服务器,二是兼容性很好,不用担心在客户端上出现的各种问题,三是平滑用户的学习曲线,用户都会使用excel,无需培训。现在的科技日新月异,分类也趋于精细化,过于纠缠于技术细节是不智的,在自身知识体系的范畴内以及社会关系的大背景下快速的找出合理的解决方案或者是方案组合才是我们所需要的,并不是一根筋到底,非得一条路走下去。
站的再高点,看的再远点,思考角度再多点。

再说面试,那天我的几个同事跟我说起当年我面试他们的情形以及他们的笔试分数,说实话,那份试题即使我来答,也未必能得个比较高的分数,不过我根本不在乎他们是否能把一份试题考出高分,那些题目答对或答错都是无关紧要的事,重要的是我要通过考试了解他们的知识结构、对待问题的态度以及解决问题的方法,把谁难倒或是比较分数高低根本不是我的目的所在。

当然,我并不是要完全否定帖子中的那位面试官,我的意思只是说术业有专攻,不要因为几个技术细节就全盘否定一个人,有人擅长软件技术,有人擅长领域分析,有人擅长资源整合,在这个知识爆炸的时代,随着我年龄的增长、脑筋的退化,我个人更倾向于成为最后者。

2010年04月28日 09:09 "jentrees"的内容
其实我也被震撼了,如果我们不追求软件的本质,编程思想的进阶,在中国的软件行业里面很容易就这样被“杯具”.

我们应以此为戒啊。

在jdon宣扬的先进的编程理念和思想,就很能让我们去深入本质,跟踪前沿。希望以后能多多和道友们交流,共同提高。 ...

JDON上都是这种打着官腔说话不着地的人么??真TMD和我们公司那帮人一个德行!!嗯,我有必要好好适应,早点向你们看齐

有点恐怖了。引以为戒

所以要有自知之明,激励自己“学的金刚钻揽得瓷器活”!