应届毕业生同时拿到华为，thoughtworks，斗鱼tv的软件开发offer，请问我应该选择哪个？跪求前辈帮忙分析指导下
华为 OR thoughtworks，应届生去这两家学习将会是非常好的选择&br&斗鱼TV跟以上完全不是一个水平和量级的
华为 OR thoughtworks，应届生去这两家学习将会是非常好的选择斗鱼TV跟以上完全不是一个水平和量级的
已有帐号？
无法登录？
社交帐号登录
无事不扫地&&&&华为今年总体的发展要比去年好，所以才出了涨薪的事。去年华为心声（内部论坛）上各种人高呼让终端公司（包括手机）出去自立门户，不要再打公司的旗号坑人。企业业务bg据说去年也是亏钱的，大家纷纷担心2012年的股票有没有分红，结果是分红20%，125亿“年中”奖（虽然大部分人只看到了零头）。今年的形势比去年要好很多，p6据说卖的不错，移动4g要上，公司在很多未来的新兴领域也有布局，看样子华为平稳发展几年没有问题。&
&&&&2014年应届生的薪酬是（北京）：&
&&&&本科&&&&9k&无户口&&13级&
&&&&研究生&&10~13k&无户口（根据能力议价）&13级&
&&&&博士&&&&议价&有户口（一贯的风格）&15级以上&
&&&&各地区研究所的根据各地的系数有浮动，北京应该是属于最高的（系数是1）。&
&&&&总体上薪酬标准是浮动的了，不像以前一样一刀切（本6研8）。&
&&&&另外说一下虽然本科和研究生没有户口（不解决北京户口，可以给深圳，杭州，成都等地的户口），但是三年左右应该可以拿到工作居住证。&
对配股影响：&
&&&&之前员工配股都是用内部账户借款购买，用分红还公司的本息。现在内部账户被***处理了，购买股票只能通过现金，假如给你配2w股，按现在的股价要付出近11万，每年的分红在20%左右。之前应届两年就应该可以配股，但是现在应届员工的现金流很成问题。所以我觉得高工资低配股在现在不能内部借款的情况下还是不错的。15级以下不是不配股，而可能是从原来的b绩效以上，提升到a绩效才可以配股。&
&&&“年中”奖：&
&&&&加薪对奖金包是有影响的，公司有发文件，这里就不说了。&
&&&&公司的福利：&
&&&&基本没有。每个月到账只有工资，过年过节过生日都不会有补助，晚上8点40之后下班有7块钱的夜宵补助。每个月最后一个周六上班是双倍工资，可以年底统一取出，也可以转调休。其他时候周六日指令性加班，基本都是转调休。&
&&&&餐饮不免费，早中晚全部食堂的话，在北研所一个男生的开销大概在30-40。班车不免费，最便宜的到西二旗的班车是3元，其他是6，8，10三个档，以后还会涨（各地研究所基本都不免费）。晚上8点30之后的班车是免费的。公司在环保园的位置比较荒凉，方圆四公里没有小馆子，步行一站地有个公交车站。&
&&&&实习期（4-6个月）也是全额发放工资，住房公积金是工资的12%（如果是9k的话，等于公司每个月还帮你交1k的住房公积金），转正后离职有n+1个月工资的补助，n为在公司工作年限，不足6个月记0.5。&
&&&&今年薪酬上涨，华为估计会变得比较热门。每年都有一些同学，待了一年，甚至不到一年就离职了，所以华为在网上被骂的那么厉害还是有原因的。总结一下不适合华为的几种类型的人：&
&&&&1）想找安逸工作的。如果你想找轻松点的工作，真没必要来华为，可以去国企或者运营商。&
&&&&2）对现金回报比较强烈的。华为的现金回报是比较迟缓的，公司比较强调先付出才有回报。有这种需求的可以选择互联网。&
&&&&3）强调企业关怀。这个我觉得外企普遍会好些。华为。。不想说了，如果做的好，也不至于被妖魔化。&
&&&&什么样的人选择华为比较好呢？&
&&&&那些大学时候没好好学，但是又有点基础。不想上研不想出国，想好好工作两年锻炼自己的，华为绝对是最佳的选择。&
&&&&华为在技术领域做的在国内算是很不错的了，赞助了很多开源社区，也投入人力参与社区的开发，有这样的人一周在家工作四天，做开源社区的项目。这一点上比国内一些互联网公司的拿来主义要好的多。所以如果你想从事技术上的工作，为社区贡献patch，成为技术先驱，华为绝对可以为你提供这个平台。但是不能保证所有人都有这个机会。&
相关待遇帖
热门公司待遇
最新薪水待遇
最新Love机会ThoughtWorks - 梦想风暴 - 博客大巴
在ThoughtWorks里面，我经常有机会在不同的项目组间轮换，所以，经常会面对陌生的一切，出去做咨询项目时也是如此。但人们常常会对有经验的人加入项目有所预期，也就需要我能够尽快进入到工作状态中。所以，我也就慢慢摸索出一套适合自己的了解项目的方式。
首先，肯定要从业务入手，了解这个系统是做什么的。既然是初始的接触，我并不预期弄清楚所有的细节，只要知道这个系统是做什么的基本上就够了。
按理说，这通常不应该是什么问题，但这也是常常容易出问题的地方，比如说，有为数不少的人在讲业务的时候，会把技术的内容混在一起讲，这一点对于技术人员尤为明显。个人就曾经经历过让我开始怀疑自己智商的几次介绍。如果5分钟说不清楚，你就别指望半个小时能说清楚。
了解了系统的业务，接着就是对技术方面的了解。还是先从宏观方面入手，我期望了解到这个系统是由哪个技术栈实现的，Java、C/C++还是.NET系等等。这样，我就可以系统采用相应的工具与框架有个大概的预期。
接下来，我期望从架构层面上了解系统。有没有一张或几张图能够把整个系统描绘出来，比如，这个系统需要与几个外部系统集成，自身包括哪些部分等等。一般我不指望有现成的图，多半的情况是，其他人一边说，一边在白板上画出一副这样的图。我接下来会根据自己的理解，把需要的这种图画出来。
对大面的东西有了了解，我就希望稍微了解一下细节。从集成开始，因为输入输出对一个系统来说是非常重要的，而集成点往往都是系统信息来源。如果有集成，集成方式是什么，比如，Web Service、RMI、MQ，有为数不少的系统用的是FTP，这些集成方式相当于信息的承载，那之上的信息是什么样子，我们还需要搞清楚，比如有的系统用的是MQ，在MQ上传的是XML等等。接下来，就是更具体的协议层面的东西了，我想知道是否有对应的文档，这样，我在需要的时候，就可以查看每个字段具体的含义，不过，这往往不是初期要了解的东西。
了解了集成，接下来就是系统内部了。这个系统有哪些子系统或模块组成。好的系统往往是由多个进程构成的，这样才不会彼此影响。对于这样的系统，我只要了解每个子系统的作用就可以了。而对于那些只有一个进程的系统，我就需要了解一下这个系统包含哪些模块，各个模块承担着怎样的职责。通常，这会一个很重要的出问题的点，因为很多系统虽然号称有模块的概念，但模块之间的职责往往是不清楚的，经常会出现很严重的依赖问题。对于现代软件系统而言，分层结构往往是不可或缺的，我还希望了解一下这个系统有多少个层，每个层做的事情是什么。这里提及了模块和层次，模块通常是从业务上来分，而层次往往是从技术上看，一个水平一个垂直。
从设计层面了解完，就是动手的层面了，不过，还不是写代码的事。我会先了解构建脚本。了解一下项目中常用的命令，比如，是否可以一键式跑脚本提交之类的。我期望看到的是一个从版本管理工具里拿出来直接可以构建成功的脚本。但通常情况都不是这样的，要改很多东西、配不少的东西。这也许就是未来要改进的东西。
熟悉了周边的东西，我们就可以深入到源码层面了。这就是我们程序员最熟悉的东西，比如，源码目录结构、配置文件的位置、模块在源码上的体现之类的等等。但作为最初的接触，我们只要了解基本的东西就够了，因为这是我们后来投入精力最多的地方，以后深入理解的机会多得是。
除了了解技术层面的东西，我还希望了解团队运作方面的东西，一个方面就是常见活动的时间安排，比如，站会、迭代计划会议、回顾会议等的时间。再有一个方面就是，团队内部是否一些活动安排，比如是否有每天的Code Diff，是否有常规的Session墙。如果团队有外部客户，我们有客户日常的沟通是怎样进行的。
通过这些问题，我们便不难发现项目运作上的一些问题，比如，很多团队与客户之间根本没有常规的沟通，只是会临时起意去做沟通。有的团队没有Session墙，团队内部分享也就没有常规化。
通常以上这些东西都不需要很长的时间来了解，快的话，一天就可够了。而通过这些了解，我就可以对团队的基本情况有了一个相对完整的大体认识，接下来的事，就是卷起袖子开始干活了！
在ThoughtWorks内部，我们定期会把各个项目的负责人召集在一起，介绍项目进展，汇报风险，交流经验。下面的问题就是出现在我们的讨论中。
问题：新加入项目的人一直不能独立做事怎么办？
简短回答：让新人多干活，老人向后站。
完整回答：在ThoughtWorks，我们通常会采用结对开发的方式。大多数程序员直觉上总是会把完成任务排到更高的优先级，所以，即便在结对开发的情况下，有经验的老人为了快速完成任务，总是倾向于霸占键盘。作为刚刚加入项目的新人，通常又不好意思打断，而且，老人眼花缭乱的屏幕切换更让新人不知所措，为了不露怯，就更不好意思问了。
但软件开发这个行业，第一手经验往往就是动手得到的。不动手，怎么看别人解决问题，也不会得到真正的成长。
一般来说，在日常工作中，工作并没有那么紧，大多数时候，我们不必冲得那么猛。完全可以把键盘教给新人，让他们来主导。作为有经验的老人，在这个过程中，主要保证思路不出现偏差即可。可能在一开始，新人的各方面确实不令人满意，但就是在这种磕磕绊绊的过程中，新人慢慢就会成长，一点点抗起压在其肩头的重量。
这是有经验的人经常犯的错误，我们经常会见到一个无所不能的负责人，向我们抱怨其团队的不作为。我想说的是，真正该骂的是这样的负责人，是你挡住了别人成长的路。
问题：项目中有人要离开怎么办？
简短回答：让要离开的人变成酱油。
完整回答：稍微长一点的项目，人来人往几乎是必然的，所以，离开一个人是很正常的。其实，出现这种担心，主要是有经验的人离开项目，尤其是在项目中扮演重要角色的人离开。
为什么他们的离开会那么惊心动魄？因为他们太重要了。一个不起眼的角色离开必然不会有很大影响。所以，解决这个问题的方案，必然是让这些曾经重要的角色不重要。
怎么才能做到这一点呢？那就是把重要的事交给其他人来做。比如：
以前在客户面前发表高论的都是这些人，那就换成下一个要负责的人。
曾经的设计决策都是这些人，那就换成下一个要负责的人。
曾经给新人讲东西都是这些人，那就换成下一个要负责的人。
曾经与上层领导交流的都是这些人，那就换要负责的人。
总而言之，趁着这些人还在团队，逐步弱化这些人的作用。这样，一方面，可以降低这些人离开的风险，另一方面，又可以利用他们的经验，对新的负责人提供帮助。我们去年的那个团队，至今一年半的时间，来来往往的人无数，其中曾经的项目负责人就下了四个，项目未受太大影响，反而有新人不断带来惊喜。
以上两个问题，其实在回答一个问题，如何培养团队。不把团队培养摆在优先级很高的位置上，很多问题是难以解决的。
最近有几篇关于科技公司面试的新闻，这篇格外受瞩目，因为竟然有公司力压Google，成了面试最难的公司，而这个公司居然是ThoughtWorks。
这个结果真的让我有些惊讶，作为一个面试过许多人的ThoughtWorker，我之前还真没想过我们的面试到底有多难。既然有人关心ThoughtWorks面试，我就不妨在此分享一下我的&面经&。
先来说说，我们的招聘流程。ThoughtWorks的招聘流程大抵分成如下几个部分，以社招开发人员为例：
电话面试，称为Phone Screen，由负责招聘的同事了解候选人基本情况
技术电话面试，称为Techinial Phone Interview，TPI，这个环节通常是针对远在外地的候选人
代码作业，称为Homework，动手写代码对程序员的考核而言是不可或缺的。
通过上面流程，候选人就可以进入到我们的办公室。一般说来，候选人要来办公室两次，第一次会做一些测试题：
逻辑和英语测试
通过之后，才是真正的重头戏，也是称为&面试&的部分。一般说来，这些环节会在一个下午的时间完成：
结对编程面试，称为Pair Programming
面谈，称为Office Interview，在我们招聘同事的口中，它有一个更复杂的名字：Overall Technical Interview and Culture Interview
这是主要的流程，有些情况会因人而异稍做调整。一般情况下，整个流程需要3周左右时间。我个人参与较多的主要是后两个环节，我的&面经&也主要在这里。
结对编程面试，是候选人和面试官一起写代码。所用的代码就是候选人之前在代码作业环节所写的代码。这是个真刀实枪的环节，想作弊是不可能的。之前曾经发生过这样的事情，候选人找人代写代码，结果，一到这个环节就完全暴露。
在这个近距离一起工作的面试中，候选者对代码的理解、开发习惯和与人交流的方式等等就全部展现在面试官面前。有些人之前习惯于窝在一个角落里写代码，像这样，写程序时身边还有人交流，对他们来说是一个巨大的挑战。我曾经看到很多面试者在这个环节紧张得不能正常思考，导致实力打了折扣。
之所以采用这样的方式进行面试，因为这就是我们日常的工作方式。我们希望了解候选人的情况，同样，也希望他们能够最真实地体验我们的工作方式、交流方式和思考方式。我们不仅仅要写程序，还要彼此交流，降低项目中出现&关键人物&的风险。以我之前的一个项目为例，这是一个总规模在十人左右的项目，一年半的时间里，这个项目先后下了四个团队lead，离开项目的开发主力也有五六个，但项目一直顺利进行，未受太大影响，就是因为通过交流，知识得到了充分地分享，避免了&关键人物&带来的风险，也让更多的同事得到了充分地锻炼。
不可否认的是，不是所有人都喜欢这种工作方式。有了这样的环节，候选人在体验之后也会有个新的评估：ThoughtWorks是不是他在找的工作，这样的工作是不是他喜欢的。
透露一个秘密，如果在结对过程中，候选人能够展现出他对快捷键和命令行的熟练，会在面试官心目中有加分的。
接下来是面谈环节，面试官和候选人坐下来，聊聊候选人的一些经历。以我个人的面试风格而言，了解了候选人过往的经历之后，我会让他挑一个自己最想讲的项目，做一个介绍。听起来很容易，但接下来，根据他介绍的内容，我会做进一步挖掘。比如，候选人说自己做过某个设计，我会问他为什么这么做，而不是那么做，对比不同方案之间的差异。这是一个说难不难的环节，如果在做设计决策的过程中，候选人经过了深入思考，回答出这些问题简直易如反掌，但对于那种直奔结果而去的候选人而言，这个问题却并不容易，当初决定的草率会在这个环节暴露无疑。这是整个面试的重头戏，候选人完全可以在这个环节将自己对技术的深入理解体现出来。
所有的问题都是开放的，没有正确答案可言，通过这样的交流过程，我们可以看到候选人更多方面的能力：思考方式、分析能力、表达方式等等。当然，也有一些人让人遗憾，他们应该是做了很多出色的工作，但完全没有办法清晰地表述出来。我喜欢听到的介绍方式是，层次清晰的讲述，当然，如果有激情就更好了。如果你看到过对技术真的有热情的人讲技术，你会知道，与那样的人交流简直是就是一种享受。
之后，我们还会了解候选人的本职工作之外的努力，因为我们相信，所谓的工作，并不能阻止一个真正热爱写程序的人求知的心：即便他只是Java程序员，并不妨碍他了解Ruby；即便工作再忙，他也会抽空学点东西。如果候选人曾经利用时间做过一些东西，那是我们乐于见到的，如果再能涉猎更多的东西，那简直太好了，当然，我们会问一些问题，了解他是&听说、了解、用过，还是深入研究过&。
单就面试过程而言，ThoughtWorks的面试并没有特别的。但为什么还有很多人会觉得这个过程很难。或许，这就是他们习惯的工作方式与我们工作方式的差异所在。
众所周知，ThoughtWorks在&如何做软件&方面是走得很靠前的。当我们的客户还在考虑ClearCase是否要切换成SVN时，我们已经抛弃了SVN，拥抱了git；当很多公司开始做持续集成时，我们已经开始了持续交付；当许多人开始拥抱敏捷时，我们正逐步地&去敏捷&。
在ThoughtWorks工作，我们要找的是真正热爱技术的人，喜欢刨根问底的人，那种为了完成而完成的人不是我们想要的。在公司里，我们经常会听到这样的话：我们不只要实现功能，更要以正确的方式来做。追求是无止境的，所以，我们要找的就是具备深入思考的能力/潜力的人，这样，我们才能不断向前。
在很多的人印象中，ThoughtWorks有一群特别能说的人，没错，在我们的工作里，沟通占了很大的比例，无论是我们在交付项目中，还是咨询项目里；无论是与自己人，还是与客户。所以，在面试中，我们也特别重视一个人的表达能力，肚子有货的人是否能够清晰地表达出来，而表达能力往往是一面反映多方面能力的镜子：分析能力、组织话题的能力、对技术的理解等等。
以个人观察而言，在程序员这个闷骚遍地的行业里，所谓不擅与人沟通的程序员只是没有找到合适的环境。其实，表达能力完全是可以锻炼出来的。还记得我第一次在东软给别人讲东西的时候，紧张得手心里全是汗。在公司内部主动讲讲东西，在社区活动做一些分享，多讲几次，什么问题就都没有了。
其实，所谓ThoughtWorks面试难，在我看来，只不过与其他公司只重视技术能力而言，我们更注重全方位的工作能力而已。因为在ThoughtWorks，我们是程序员，但我们不只是程序员。
自从迈出了，西电的校园活动就一次次进行下来，我们讲了如何写代码，讲了完整的开发过程，后续的一系列校园技术讲座也已经排上了日程。
其实，单以效果而言，技术讲座所带来的影响是有限的，对于参加讲座的学生来说，除了知道很多新名词、新做法，多半也就是看个热闹。直接动手实践，才是一个更好的做法。
感谢我们优秀的市场MM，她为我们打开了一片新天地。感谢西安交通大学软件学院的领导具备的卓越眼光，为他们的学生提供了一个接触外面世界的机会。
于是，我们有了一个新的机会，在西安交通大学开设一门软件开发的课程。
这门课，我们称之为&现代软件开发&，其目的就是为了告诉同学们，不同于传统方式的开发方法。其实，我们本可以叫敏捷软件开发方法，但我着实不喜欢这个名字，因为这已不是我追求的东西，我只想把一些好的东西告诉同学们，所以，选了一个不容易过时的名字。
我们是这样设计的这门课，采用上下半场的方式运作。上半场，我们会介绍一些基本的开发方法，比如整洁代码，比如重构，比如自动化等等。而下半场，则完全是实践。我们选取了一个项目，按照我们的方式运作了一个项目，我们的同事会与同学们结对，让他们直接体会最原汁原味的ThoughtWorks开发方式。
就在这个周末，这个系列课程终于迈出了第一步。
第一次课基本上算是一个课程介绍，让为有兴趣选修这门课的同学了解这门课，以及我们的上课方式。我们讲了公司里如何做软件，还演示了结对开发和TDD。
第二步就这样迈了出来，在接下来的一段时间里，虽然要牺牲一些业余时间，但这也是一个很好的尝试，让我们的课程更加系统化，也给了我们的同事一个很好的锻炼机会。
我们的同事在课程的结尾送给同学们一句话，与其周末逛街打DOTA，还不如来写写代码。嗯，就是这样。
五年了，真快。
工作十年，我只工作过两家公司：为我打好基础的东软和为我打开视野的ThoughtWorks，每家五年。这个换工作的速度，在IT行业里，应该算是蜗速了。
当年进到ThoughtWorks，我最想解惑的是如何做好软件，因为之前的开发经历里，我有太多想不明白为什么的地方，比如，为什么要写文档。选择加入ThoughtWorks，我知道这里有敏捷，貌似是解惑的途径。
随着自己在ThoughtWorks做过项目的增多，我了解了敏捷，这些曾经的困惑逐渐得以挥去。当有机会尝试咨询，我开始得到从更多角度看待软件开发，我开始相信改变。渐渐地，我知道了我追求的其实不是敏捷，是持续改进。
去年带了一个项目，在那个项目里，我做了一个尝试。我把项目的目标订在了人才培养，而非传统意义的交付。于是，在这个过程中，我花了大量的精力去教新员工写代码，帮他们设定个人成长目标，教他们做事，带着他们吃好玩好&&就是这样一个几乎都是由新ThoughtWorker&&甚至大多是毕业生&&组成的项目组，后来，这个项目成了Michael Chen口中最接近他心目中的项目。
早在做咨询的最初，我就认识到，敏捷实施，管理实践很快上手，但新鲜劲一过，就会发现，收效甚微，而技术实践实施起来，却难上加难。我一度很悲观地认为，这事没法搞，我再厉害，也不可能让他们把我十年的东西在几个月内学会。去年的这个项目实验让我这个问题有了新的思考。
真正要敏捷起来，我们要做的并不是敏捷实践，而在于提升团队中每个人的能力，而其中的关键在于，营造团队学习氛围。这正是我们在ThoughtWorks西安办公室努力营造的，事实证明，在这样的环境下，整体的成长是很快的，而学习氛围更好的团队其实也是各方面做得更好的团队。
对这个问题也有属于他的思考，结合了我们在ThoughtWorks西安办公室所做的各种努力，他提出了LOT（Learning Organiation Transformation，学习型组织转型）。
从了解如何好软件，到告诉别人如何做好软件，到思考真正提升团队能力，还好，五年的思想工作者，光阴不算虚度。
：：：：：：：：：：
访问统计：