面试经验分享--业务真的比技术重要？

一、序言

       每一次面试都能看到自己的不足，能让自己的视野变得开阔，能让自己在前进的路上看得很清晰，同时我也希望这些能点亮我生活的经验，能给予大家一些光和热。

 

二、面试过程

       曾经：我参加过几家公司的面试，具体的名字我就不介绍，基本上的过程都是先大概介绍一些自己，介绍一下自己的项目信息，然后就对技术的狂轰乱砸，直到你头晕眼花！我相信很多人和我的经历差不多，然后我们可以从面试中看到自己技能方面的不足，深入不够，然后奋发图强...

 

       技术真的那么重要吗？

       对于这个问题，对于技术宅来说，是肯定重要的，对于销售、市场的人员来说，技术员都是搬砖的，仅仅由体力劳动变成了脑力劳动，觉得业务才是最重要的。

 

       这个问题争论了很久，由于都站在自己的角度中，因此经常谈不拢~。~来看看我这次面试的情况吧！

       由于前面的面试经验，深知自己的技术不足，也导致了自己一直研究技术（也感兴趣），然后对业务不是特别上心。这次的面试官，看了我博客之后，直接就对我以前的做的项目进行挖掘，我以为和以前一样，也就是大概了解一下，结果问得比较细，而我对项目的总结，一般也是技术上的总结以及管理上的，由于业务牵扯庞大（ERP 供应链），大部分时间仅仅关注了自己写的模块，对整个项目以及各个项目之间的业务关联不清楚，因此这次的面试是挺不好。

 

       不好的原因有几点：

       1.对自己项目的业务不是很熟悉，同时也反应出我对业务的敏感度不高。

       2.技术面试方面，比较基础，但是对于互联网的东西实战不够。

       3.面试准备不充分，没能很好的表达自己的东西，比如业务描述那块，上心程度不够。

       4.当然也有客观原因，整个业务涉及的系统，已经好多年了，代码还在JSP 都有，然后大部分业务都写到存储过程里面，很难去把握整个项目的概况，即使相关联的模块的一些详细信息，文档缺失，很难从代码上去弄，这里还得找更好的方式去深入了解才行。

 

       当然，可能很多人会说，一个技术人员，应该对技术深入嘛，对业务了解就行了，这也是我以前的认识的，因此所有的空闲时间我都用来学习技术，没有深入分析和扩展业务。

       对于一个团队来说，所有的技术都是为业务服务的，而互联网的业务变化很快，你要从业务上深入分析，才能知道变化，才能通过技术更加灵活的实现。我们常常听程序员抱怨，需求变化快，代码又要变，其中的关键就是对业务不熟悉，不能推断其后续可能的变化，导致代码的灵活度不够造成的。（PS：代码需要灵活度，但是不是一味的追求灵活或者扩展， 它更多的应该建立在对业务的理解，可以可变性上。）

       同时，团队希望组员能能挖掘业务，更好的扩展业务，毕竟互联网的业务价值，和传统的不一样，传统的很多需要销售去弄，而互联网的也需要销售，但是很多时候需要程序员对自身产品的一些价值进行挖掘，因此不深入分析业务，是做不到这点的，那么你能产生的价值仅仅是“搬砖”，你是这样希望的吗？

 

小结：

       1.上文我主要描述了业务的重要性，同时给那些和我一样，不重视业务的技术宅（非底层研究）提个醒，希望能做一个技术和业务兼顾的人。

       2.在对技术的执着的同时，希望大家也增加一些软技能，比如一些业务、团队沟通协调等等之类的，无论对自己还有对团队都会很有利。

       3.无论自己走技术路线还是管理路线，对业务的把握都是必须的，只是侧重点不同而已

       4.最后希望大家分享快乐，仅仅表示个人意见，不好请指出~。~

       

评论

10 楼 greemranqq 2014-05-26  

white_crucifix 写道

我来给博主泼点冷水吧，呵呵，算是集思广益
......
钻研技术还是精通业务么，没有对错，这就是生活。

首先，很感谢您观点，其实我是一个比较重技术的人，在项目空闲时间，一般都用于技术上的学习，对业务，或者说对自己的项目没能形成较全的理解，在经理将需求搞定之后，我仅仅是进行技术上的实现，当然会考虑代码的质量，久而久之就感觉经理提需求，我进行实现，成为一种理所当然了，没去很仔细的思考这个需求是否正确，是否有更好的方式去实现，没能站在一个真正的软件工程师的角度去看问题，仅仅是码农。

当然，重视业务的人也会导致类似却相反的情况。我们知道一个优秀的架构师，一般是对技术领域以及相关业务领域都是比较熟悉的，这样才能更好的做好架构工作。

你最后的观点，我是很藏同的，文中我也不是想表达业务或者技术 哪个更重要，仅仅是想对走技术路线的人说明一下：“业务其实也很重要，要相互结合。”也就是不要偏科，语文和数学都是相互相成的，也为我们以后像更高层次进发做好铺垫。

9 楼 white_crucifix 2014-05-26  

我来给博主泼点冷水吧，呵呵，算是集思广益

其实博主提出的是个伪命题，博主今天的感悟是源自于在面试中发现了自己在业务了解上的薄弱，若是一个业务熟悉而技术很浅的人参加一个技术面试，发现自己技术薄弱，就会得出相反的观点。

当然，我不喜欢说什么两者都重要这样没有营养的观点。若扩散开去会说的太多，就分析一下，博主那一行加粗的句子好了。

我在一个重技术，geek氛围强的环境待过，也在一个重业务，技术只要不出问题怎么搞都行的氛围待过。我不否认还是有很多两者兼并的人才存在，但是大多数重业务弱技术的情况下，都做不到博主说的 灵活的扩展要建立在熟悉业务的可变性上。因为长年不在技术上思考的人，是没有能力将复杂多变的业务需求配合软件工程的设计思想做出高可用高扩展的架构。很多人都会在需求变更时被自己写的代码给坑了，尽管他是对业务熟悉的。

但是这样说会有很多人不服气，因为技术是个实打实的东西，当你没有理解到一定层次，可能根本不会想到有更好的解决方案，但是自己本身不会感觉到，因此会觉得自己做的是最好的，理所当然的。但事实确实存在差异。

另一方面，对于技术的深入理解，对软件工程思想的熟悉，很多时候能对业务的多变进行反哺。"一味的追求灵活的扩展"，这是一个没有做过调查思考后的简单想法。没有多少人喜欢做大量暂时用不着的事情。但是对于技术的深入了解，却能够在需求变化后，做出软件层面最优雅的扩展和预留。

说的具体点，在一个业务导向氛围的公司里， 充斥着大量的着是流水账的，重复的，没有规范的代码和架构。从最早启动项目的人就没有做任何的把控，随着多年的人员进出，项目逐渐频临崩溃，最终上新项目替换，然而依然是周而复始。

当然，技术是个隐性的事物，你的代码写的好或者写的不好，领导不一定关心，只要跑出来没有问题。需求要是变了，贴膏药打补丁还是优雅的扩展，只要能跑通，领导也不一定知道。

钻研技术还是精通业务么，没有对错，这就是生活。

8 楼 greemranqq 2014-05-25  

need_faith 写道

优先级从低往高

• 技术能力
• 业务能力
• 为人
• 人脉

是的，从开始学习，前面1-2年 可能关注技术比较多，很多业务知识都没行形成系统，基本的任务模块都是上级分配任务，仅仅对模块熟悉，对整个项目的概念以及相关系统的联系 意识都比较差，随着能力的提升，开始考虑业务，设计项目，挖掘业务价值，逐步向上提升

7 楼 need_faith 2014-05-24  

优先级从低往高

• 技术能力
• 业务能力
• 为人
• 人脉

6 楼 zhengyutao 2014-05-24  

经济决定上层建筑
技术为业务服务

5 楼 greemranqq 2014-05-23  

caizi12 写道

大部分情况下了解业务要比了解技术更优先，一个团队有ld，有需求人员，有测试人员，有开发人员，和别人沟通最多的还是业务，特别是业务复杂了后，更要了解业务，对整个系统的模块都要有了解，不然就会容易改一个问题时漏了另一个导致出现bug。

嗯，我开始反省自己的了，因此从开始懵懵懂懂走到现在，从最开始 按经组长的要求完成，到自己去设计。是一个过程，这次给我了很大的 提醒。

4 楼 caizi12 2014-05-23  

大部分情况下了解业务要比了解技术更优先，一个团队有ld，有需求人员，有测试人员，有开发人员，和别人沟通最多的还是业务，特别是业务复杂了后，更要了解业务，对整个系统的模块都要有了解，不然就会容易改一个问题时漏了另一个导致出现bug。

3 楼 xiang37 2014-05-23  

ERP行业，是一种行业经验，当然和普通技术工，很不同的。相比来说，技术重要性仅占40%不到。

2 楼 malie0 2014-05-23  

我是觉得业务是很重要的，项目的成败往往不在技术层面上。技术只是工具，需要的时候再用也行，而一味研究技术特别是那些在工作中用不到的东西还不如多用心学习业务，让工作更加顺手。
另外中国文理分科的教育导致了做技术的不懂人文，知识结构的不完整使人由于无知而产生种种的偏见。而中国的企业或者说是中国文化病态的人才观导致每一个都要做全才，一个企业最好一个员工什么都能做，看招聘条件就知道。希望靠个人能力解决所有问题而不是用管理、制度、团队的力量使1+1>2来解决问题，没有现代化的管理思想。这个就和中餐馆一样，靠的全是大厨的手艺，而不像肯德基、麦当劳全都是流水线标准化作业，分店可以开满全世界。

1 楼 freezingsky 2014-05-23  

任何技术都是为了业务服务，理解这句话，自然也就没那么多纠结！