来自我的微博( @Fenng )的整理.
现在看工程师的简历，容易加分的亮点是：
1. Github 上的项目地址.
2. Stack Overflow 有积分.
3. Twitter ID.
看产品经理的简历，容易加分的亮点是：
1.知乎ID
2.长期更新的Blog
注意是说*容易加分*，有些硬性要求当然不能跳过。
李开复的评论：
1）看邮件用什么邮箱（有些加分，有些减分）
2）看他发的微博、关注什么人、什么人关注他
3）搜索（网络搜索+微博搜索）他
再补充发送求职信的建议：
求职者发送简历的时候，邮件标题很重要。最好以{名字}的简历+ {目标职位} 的形式. 比如，「梁朝伟的简历 求职网络编辑」。这样招聘方收到邮件，一目了然。
--E0F-
最新内容 » 心得
1，当时公司招了大批应届本科和研究生毕业的新新人类。平均年龄25岁。那个新的助理，是经过多次面试后，我亲自招回来的一个女孩。名牌大学本科毕业，聪明，性格活泼。私下里我得承认，我招她的一个很重要的原因，除了她在大学里优秀的表现之外，还因为她写了一手漂亮的字。女孩能写一手好字的不多，尤其像她，看起来长发飘飘，多么女性化的一个姑娘，一手字却写的铿锵倜傥，让我对她不由多了很多好感。
手把手的教。从工作流程到待人接物。她也学的快。很多工作一教就上手。一上手就熟练。跟各位同事也相处的颇融洽。我开始慢慢的给她一些协调的工作，各部门之间以及各分公司之间的业务联系和沟通让她尝试着去处理。
开始经常出错。她很紧张，来找我谈。我告诉她：错了没关系，你且放心按照你的想法去做。遇到问题了，来问我，我会告诉你该怎么办。仍然错。又来找我，这次谈的比较深入，她的困惑是，为什么总是让她做这些琐碎的事情？我当时问她：什么叫做不琐碎的工作呢？
她答不上来，想了半天，跟我说：我总觉得，我的能力不仅仅能做这些，我还能做一些更加重要的事情。那次谈话，进行了1小时。我知道，我说的话，她没听进去多少。后来我说，先把手头的工作做好，先避免常识性错误的发生。然后循序渐进罢。
2，半年以后，她来找我，第一次提出辞职。我推掉了约会，跟她谈辞职的问题。问起辞职的原因，她跟我直言：本科四年，功课优秀，没想到毕业后找到了工作，却每天处理的都是些琐碎的事情。没有成就感。我又问她：你觉得，在你现在所有的工作中，最没有意义的最浪费你的时间精力的工作，是什么？她马上答我：帮您贴发票，然后报销，然后到财务去走流程，然后把现金拿回来给您。
我笑着问她：你帮我贴发票报销有半年了吧？通过这件事儿，你总结出了一些什么信息？
她呆了半天，答我：贴发票就是贴发票，只要财务上不出错，不就行了呗，能有什么信息？
我说，我来跟你讲讲，当年我的做法吧：９８年的时候，我从财务被调到了总经理办公室，担任总经理助理的工作。其中有一项工作，就是跟你现在做的一样，帮总经理报销他所有的票据。本来这个工作就像你你刚才说的，把票据贴好，然后完成财务上的流程，就可以了。
其实票据是一种数据记录，它记录了和总经理乃至整个公司营运有关的费用情况。看起来没有意义的一堆数据，其实它们涉及到了公司各方面的经营和运作。于是我建立了一个表格，将所有总经理在我这里报销的数据按照时间，数额，消费场所，联系人，电话等等记录下来。
我起初建立这个表格的目的很简单，我是想在财务上有据可循，同时万一我的上司有情况来询问我的时候，我会有准确的数据告诉他。通过这样的一份数据统计，渐渐的我发现了一些上级在商务活动中的规律，比如，哪一类的商务活动，经常在什么样的场合，费用预算大概是多少；总经理的公共关系常规和非常规的处理方式。等等等等。
当我的上级发现，他布置工作给我的时候，我会处理的很妥贴。有一些信息是他根本没有告诉我的，我也能及时准确的处理。他问我为什么，我告诉了他我的工作方法和信息来源。
渐渐的，他基于这种良性积累，越来越多的交待更加重要的工作。再渐渐的，一种信任和默契就此产生，我升职的时候，他说我是他用过的最好用的助理。
说完这些长篇大论，我看着这个姑娘，她愣愣的看着我。我跟她直言：我觉得你最大的问题，是你没有用心。在看似简单不动脑子就能完成的工作里，你没有把你的心沉下去，所以，半年了，你觉得自己没有进步。她不出声。但是收回了辞职报告。
又坚持了３个月，她还是辞职了。这次我没有留她。让她走了。
后来她经常在ＭＳＮ上跟我聊天。告诉我她的新工作的情况。一年内，她换了三份工作。每一次都坚持不了多久。每一次她都说新的工作不是她想要的工作。０５年的时候，她又一次辞职了。很苦恼，跑来找我，要跟我吃饭。我请她去写字楼后面的商场吃日本料理。吃到中途，忽然跟我说：我有些明白你以前说的话是什么意思了。
3，所谓的职业生涯，其实你很难预测到你将来真正要从事什么工作，将来所要从事的工作，是否跟你在大学里学的专业有关。大多数人，很有可能将来所作的工作，跟他当初所学的专业一点关系都没有。从22岁大学毕业在26岁之间这四年，重要的不是你做了什么，重要的是你在工作中养成了怎么样的良好的工作习惯。这个良好的工作习惯，指的是：认真，踏实的工作作风，以及是否学会了如何用最快的时间接受新的事物，发现新事物的内在规律，比别人更短时间内掌握这些规律并且处理好它们。具备了以上的要素，你就成长为一个被人信任的工作的人。
人都有惰性，也都愿意用那些用起来顺手的人。当你具备了被人信任的基础，并且在日常的工作中逐渐表现出你的踏实，聪明，和细致的时候，越来越多的工作机会就会提供到你面前。原因很简单，用一句话就能交代清楚并且能被你顺利完成的工作，谁愿意说三句话甚至半小时交待一个怎么都不明白的人呢？沟通也是一种成本，沟通的时间越少，内耗越少，这是作为管理者最清楚的一件事。
当你有比别人更多的工作机会去接触那些你没有接触过的工作的时候，你就有了比别人多的学习机会，人人都喜欢聪明勤奋的学生，作为管理者，大概更是如此。
一个新手，大多数新手，在这四年里，是看不出太大的差距的。但是这四年的经历，为以后的职业生涯的发展奠定的基础，是至关重要的。很多人不在乎年轻时走弯路，很多人觉得日常的工作人人都能做好没什么了不起。然而就是这些简单的工作，循序渐进的、隐约的，成为今后发展的分水岭。
漫不经心的对待基层工作的最大的损失，就是将看似简单的事物性处理方式，分界成为长远发展的能力问题。
聪明的人，总是不认为自己的能力有问题。时间长了，他会抱怨自己运气不好，抱怨那些看起来资质普通的人，总能比自己更能走狗屎运。抱怨她容貌比自己好，或者他更会讨领导欢心。等等等等。慢慢的，影响心态。所谓的怀才不遇，有时是这种情况。
工作需要一个聪明人，工作其实更需要一个踏实的人。在聪明和踏实之间，我更愿意选择后者。
而踏实，是人人都能做到的。和先天条件没有太大关系。
手把手的教。从工作流程到待人接物。她也学的快。很多工作一教就上手。一上手就熟练。跟各位同事也相处的颇融洽。我开始慢慢的给她一些协调的工作，各部门之间以及各分公司之间的业务联系和沟通让她尝试着去处理。
开始经常出错。她很紧张，来找我谈。我告诉她：错了没关系，你且放心按照你的想法去做。遇到问题了，来问我，我会告诉你该怎么办。仍然错。又来找我，这次谈的比较深入，她的困惑是，为什么总是让她做这些琐碎的事情？我当时问她：什么叫做不琐碎的工作呢？
她答不上来，想了半天，跟我说：我总觉得，我的能力不仅仅能做这些，我还能做一些更加重要的事情。那次谈话，进行了1小时。我知道，我说的话，她没听进去多少。后来我说，先把手头的工作做好，先避免常识性错误的发生。然后循序渐进罢。
2，半年以后，她来找我，第一次提出辞职。我推掉了约会，跟她谈辞职的问题。问起辞职的原因，她跟我直言：本科四年，功课优秀，没想到毕业后找到了工作，却每天处理的都是些琐碎的事情。没有成就感。我又问她：你觉得，在你现在所有的工作中，最没有意义的最浪费你的时间精力的工作，是什么？她马上答我：帮您贴发票，然后报销，然后到财务去走流程，然后把现金拿回来给您。
我笑着问她：你帮我贴发票报销有半年了吧？通过这件事儿，你总结出了一些什么信息？
她呆了半天，答我：贴发票就是贴发票，只要财务上不出错，不就行了呗，能有什么信息？
我说，我来跟你讲讲，当年我的做法吧：９８年的时候，我从财务被调到了总经理办公室，担任总经理助理的工作。其中有一项工作，就是跟你现在做的一样，帮总经理报销他所有的票据。本来这个工作就像你你刚才说的，把票据贴好，然后完成财务上的流程，就可以了。
其实票据是一种数据记录，它记录了和总经理乃至整个公司营运有关的费用情况。看起来没有意义的一堆数据，其实它们涉及到了公司各方面的经营和运作。于是我建立了一个表格，将所有总经理在我这里报销的数据按照时间，数额，消费场所，联系人，电话等等记录下来。
我起初建立这个表格的目的很简单，我是想在财务上有据可循，同时万一我的上司有情况来询问我的时候，我会有准确的数据告诉他。通过这样的一份数据统计，渐渐的我发现了一些上级在商务活动中的规律，比如，哪一类的商务活动，经常在什么样的场合，费用预算大概是多少；总经理的公共关系常规和非常规的处理方式。等等等等。
当我的上级发现，他布置工作给我的时候，我会处理的很妥贴。有一些信息是他根本没有告诉我的，我也能及时准确的处理。他问我为什么，我告诉了他我的工作方法和信息来源。
渐渐的，他基于这种良性积累，越来越多的交待更加重要的工作。再渐渐的，一种信任和默契就此产生，我升职的时候，他说我是他用过的最好用的助理。
说完这些长篇大论，我看着这个姑娘，她愣愣的看着我。我跟她直言：我觉得你最大的问题，是你没有用心。在看似简单不动脑子就能完成的工作里，你没有把你的心沉下去，所以，半年了，你觉得自己没有进步。她不出声。但是收回了辞职报告。
又坚持了３个月，她还是辞职了。这次我没有留她。让她走了。
后来她经常在ＭＳＮ上跟我聊天。告诉我她的新工作的情况。一年内，她换了三份工作。每一次都坚持不了多久。每一次她都说新的工作不是她想要的工作。０５年的时候，她又一次辞职了。很苦恼，跑来找我，要跟我吃饭。我请她去写字楼后面的商场吃日本料理。吃到中途，忽然跟我说：我有些明白你以前说的话是什么意思了。
3，所谓的职业生涯，其实你很难预测到你将来真正要从事什么工作，将来所要从事的工作，是否跟你在大学里学的专业有关。大多数人，很有可能将来所作的工作，跟他当初所学的专业一点关系都没有。从22岁大学毕业在26岁之间这四年，重要的不是你做了什么，重要的是你在工作中养成了怎么样的良好的工作习惯。这个良好的工作习惯，指的是：认真，踏实的工作作风，以及是否学会了如何用最快的时间接受新的事物，发现新事物的内在规律，比别人更短时间内掌握这些规律并且处理好它们。具备了以上的要素，你就成长为一个被人信任的工作的人。
人都有惰性，也都愿意用那些用起来顺手的人。当你具备了被人信任的基础，并且在日常的工作中逐渐表现出你的踏实，聪明，和细致的时候，越来越多的工作机会就会提供到你面前。原因很简单，用一句话就能交代清楚并且能被你顺利完成的工作，谁愿意说三句话甚至半小时交待一个怎么都不明白的人呢？沟通也是一种成本，沟通的时间越少，内耗越少，这是作为管理者最清楚的一件事。
当你有比别人更多的工作机会去接触那些你没有接触过的工作的时候，你就有了比别人多的学习机会，人人都喜欢聪明勤奋的学生，作为管理者，大概更是如此。
一个新手，大多数新手，在这四年里，是看不出太大的差距的。但是这四年的经历，为以后的职业生涯的发展奠定的基础，是至关重要的。很多人不在乎年轻时走弯路，很多人觉得日常的工作人人都能做好没什么了不起。然而就是这些简单的工作，循序渐进的、隐约的，成为今后发展的分水岭。
漫不经心的对待基层工作的最大的损失，就是将看似简单的事物性处理方式，分界成为长远发展的能力问题。
聪明的人，总是不认为自己的能力有问题。时间长了，他会抱怨自己运气不好，抱怨那些看起来资质普通的人，总能比自己更能走狗屎运。抱怨她容貌比自己好，或者他更会讨领导欢心。等等等等。慢慢的，影响心态。所谓的怀才不遇，有时是这种情况。
工作需要一个聪明人，工作其实更需要一个踏实的人。在聪明和踏实之间，我更愿意选择后者。
而踏实，是人人都能做到的。和先天条件没有太大关系。
为什么我们招聘的时候绝不要传智播客的学生？ - by @Tinyfool
作者 Fenng 137 天 前 (http://tiny4.org)
Tinyfool 的博文：http://tiny4.org/blog/2011/06/hr-itcast
今年三月到四月间，传智播客的老师张孝祥发了三篇Blog《联想利泰的一道做出来就给月薪7K的面试题–交通灯管理系统》、《又一道软通动力7K月薪面试题——银行业务调度系统》和《累病倒了我两次的面试题–移动用户资费统计系统》。这三篇无一例外的除了分析面试题以外，都讲述了张孝祥老师怎么辛辛苦苦给学生做好面试题，让他们去交差的故事。不以为耻，反以为荣。
......
我在盛大创新院的时候，自己招聘了一个美工，帮别的项目组面试了很多iOS工程师。招聘现在是非常困难的工作，各大招聘网站推荐来的面试者很多都是滥竽充数的，本来已经够麻烦的招聘再加上培训机构的作弊，招聘越来越难。与此同时，一个年轻人们去找工作也会变得越来越难。几年前，培训学校出来的学生可能还是某些公司争抢的目标，但是现在随着培训学校越来越多，竞争越来越激烈，跟企业斗志斗勇的越来越多，很多企业早就开始直接刷掉有培训学校经历的学生。我本来是不建议这么绝对去做的，但是经过张老师这个事件，我相信大多数看过张老师的blog的技术面试官，企业HR，心目中“传智播客”已经进入了黑名单。我们的目的是找到真正的人才，不是找一个老师牛屄的人，这个简单的道理，张老师，蒋老师，不需要研究面试题你们就应该知道。你们现在送一个学生混进了企业，就是未来堵住了其他学生进这个企业的可能性，哪怕未来那个学生是有真材实学的人。企业的技术面试官和HR，不是撂爪就忘的老鼠。
现在我出来创业做一个小企业。其实我很知道一些小企业的疾苦，当年我和火炬创业做技术咨询的时候，见过很多没有技术背景的创业者，找技术人才非常困难，因为自己没有辨别能力。所以经常招了一个人说起来不错，看起来挺好，结果做了三个月什么也做不出来。在当年瞬息万变的竞争态势下，三个月什么都没做出来，对创业者打击非常大。他们只能再找一个技术人员，期待三个月后有点结果。这个层面来看，小企业你更伤不起啊。
所以，在我的Blog，我今天严正声明在“张老师道歉并承诺再也不进行这类作弊行为”之前，我的企业，并号召其他的看到我的文章和张老师文章的企业主，技术面试官，HR，坚决不招聘任何传智播客培训过的学生。
有人今天在新浪说，也许我40岁以后就不会这么看问题了。我说，“反之，我年轻的时候，学生时想法也许不同，但是年纪越大觉得诚信越可贵越不可缺失”。现在传志播客的学生们，你们可以把我当仇人了，不过期待你们老了以后懂的我今天在讲些什么。
今年三月到四月间，传智播客的老师张孝祥发了三篇Blog《联想利泰的一道做出来就给月薪7K的面试题–交通灯管理系统》、《又一道软通动力7K月薪面试题——银行业务调度系统》和《累病倒了我两次的面试题–移动用户资费统计系统》。这三篇无一例外的除了分析面试题以外，都讲述了张孝祥老师怎么辛辛苦苦给学生做好面试题，让他们去交差的故事。不以为耻，反以为荣。
......
我在盛大创新院的时候，自己招聘了一个美工，帮别的项目组面试了很多iOS工程师。招聘现在是非常困难的工作，各大招聘网站推荐来的面试者很多都是滥竽充数的，本来已经够麻烦的招聘再加上培训机构的作弊，招聘越来越难。与此同时，一个年轻人们去找工作也会变得越来越难。几年前，培训学校出来的学生可能还是某些公司争抢的目标，但是现在随着培训学校越来越多，竞争越来越激烈，跟企业斗志斗勇的越来越多，很多企业早就开始直接刷掉有培训学校经历的学生。我本来是不建议这么绝对去做的，但是经过张老师这个事件，我相信大多数看过张老师的blog的技术面试官，企业HR，心目中“传智播客”已经进入了黑名单。我们的目的是找到真正的人才，不是找一个老师牛屄的人，这个简单的道理，张老师，蒋老师，不需要研究面试题你们就应该知道。你们现在送一个学生混进了企业，就是未来堵住了其他学生进这个企业的可能性，哪怕未来那个学生是有真材实学的人。企业的技术面试官和HR，不是撂爪就忘的老鼠。
现在我出来创业做一个小企业。其实我很知道一些小企业的疾苦，当年我和火炬创业做技术咨询的时候，见过很多没有技术背景的创业者，找技术人才非常困难，因为自己没有辨别能力。所以经常招了一个人说起来不错，看起来挺好，结果做了三个月什么也做不出来。在当年瞬息万变的竞争态势下，三个月什么都没做出来，对创业者打击非常大。他们只能再找一个技术人员，期待三个月后有点结果。这个层面来看，小企业你更伤不起啊。
所以，在我的Blog，我今天严正声明在“张老师道歉并承诺再也不进行这类作弊行为”之前，我的企业，并号召其他的看到我的文章和张老师文章的企业主，技术面试官，HR，坚决不招聘任何传智播客培训过的学生。
有人今天在新浪说，也许我40岁以后就不会这么看问题了。我说，“反之，我年轻的时候，学生时想法也许不同，但是年纪越大觉得诚信越可贵越不可缺失”。现在传志播客的学生们，你们可以把我当仇人了，不过期待你们老了以后懂的我今天在讲些什么。
JobsDigg 观察：从猎头发来的Spam看各大互联网公司的项目策略和动向
作者 Fenng 281 天 前 (Editorial)
现在猎头都开始群发Spam邮件招人了？翻看了一下发来的一堆JD，可了解到的各家公司动向如下：
1) 开心网在全力进军手机客户端，iPhone/Windows Phone/Android ，其中居然还有Meego的需求。手机客户端产品线全面开花。
2）千橡互动在找无线3G技术总监，Web Game 相关人才，也在做视频相关的项目；另外，千橡的Java工程师需求也不小。
3）Hulu预计将进入中国，最起码招人已经开始了。目前集中在PM相关的人才。
4）淘宝在大肆招人（可能是这些公司里面规模最大的）。范围涉及：数据分析、广告、搜索、算法等等方面。层级定位在p6-p8之间... (现在阿里技术层级贬值快赶上人民币的速度了)。
5) Yahoo!(Yahoo!美国在国内的研发中心)在国内正悄悄的招人，规模也很大，是属于组建完整团队的那种招聘方式。
6）360 在招 PHP 的人才；从各方面的信息来看，360在进军购物搜索和导购。其实还有另外低调潜伏的基础电子商务服务。
几乎每家公司的招聘都会有前端工程师的职位，需求旺盛。前端工程师的春天早就来了。
补充一个结论：以上这些公司基本都是比较"财大气粗钱多人傻“的公司：委托这样的猎头靠人海战术招人，可见一斑。
--EOF--
1) 开心网在全力进军手机客户端，iPhone/Windows Phone/Android ，其中居然还有Meego的需求。手机客户端产品线全面开花。
2）千橡互动在找无线3G技术总监，Web Game 相关人才，也在做视频相关的项目；另外，千橡的Java工程师需求也不小。
3）Hulu预计将进入中国，最起码招人已经开始了。目前集中在PM相关的人才。
4）淘宝在大肆招人（可能是这些公司里面规模最大的）。范围涉及：数据分析、广告、搜索、算法等等方面。层级定位在p6-p8之间... (现在阿里技术层级贬值快赶上人民币的速度了)。
5) Yahoo!(Yahoo!美国在国内的研发中心)在国内正悄悄的招人，规模也很大，是属于组建完整团队的那种招聘方式。
6）360 在招 PHP 的人才；从各方面的信息来看，360在进军购物搜索和导购。其实还有另外低调潜伏的基础电子商务服务。
几乎每家公司的招聘都会有前端工程师的职位，需求旺盛。前端工程师的春天早就来了。
补充一个结论：以上这些公司基本都是比较"财大气粗钱多人傻“的公司：委托这样的猎头靠人海战术招人，可见一斑。
--EOF--
工程师的妙文：工作这些年
作者 Fenng 410 天 前 (Editorial)
Fenng按:不用说，你也知道这是哪家公司。
--------------------------------
刚开始去的部门是负责在网页上贴牛皮癣，这个比较惹人讨论的。不过自然会有人发明出一些理论证明牛皮癣的意义，比如长尾理论。还会发展出相应的学科，比如计算广告学。
说远了，其实这些都跟我没关系。偶是个码农，就负责没日没夜的写代码。公司说要向硅谷学习，实行弹性工作制，可这是中国特色的弹性工作制，只可延长，不可缩短。九点下班那算早的，十点下班才算正常。事实上就没有下班的时候，经常会凌晨的时候一个电话打过来，然后回公司去处理线上事故。为什么老在凌晨的时候出事故呢？这跟线上服务有关系，晚上上网的人少，所以很多复杂的操作都留在晚上做，比如更新数据。这些操作往往会导致事故。凌晨不睡觉起来处理事故，有啥好处呢？加班费肯定是没有的。就没有加班的概念，因为是弹性工作制。第二天首先要追究事故责任。如果是我们自己的代码导致线上事故，然后扣钱，通报批评，自我检讨。如果是别人的代码导致线上事故呢？然后老大们会说你们响应太慢了，从事故发生到解决，居然花了一个小时，导致公司损失了多少多少钱，好好检讨一下应急机制，然后还是扣奖金。
没日没夜的加班，周末、加节也加班，加上出了点小事故就没完没了，导致的是，面黄肌瘦，早生华发，同时伴有强迫症，写代码的时候小心翼翼，反复测试，线上操作的时候，反复校对操作单、配置项。
每次做项目的时候就说，大家好好干，辛苦几天，做完这个项目就休息。事实上一个项目没做完，另一个项目已经在排期了。为什么会这么忙呢？主要是因为码农的需求来源有几个，一是PM，主要是提一些产品层面的需求，一是策略，主要是提些按什么规则贴牛皮癣的需求，一是公司上层，涉及到商业模式的变更，比如按什么规则收费。用IT的行话说，码农就是这些人的共享资源，都在争夺的，根本就不会有闲下来的时候。哪天运气好，真的闲下来了，直接经理也会没事找事，让码农干点事情，以体现他的管理水平，比如整 理下文档，整理一下统计报表。
在这种情况下写代码，会造成代码能力下降。记得小时候，字写得本来不丑，后来语文老师老逼着抄课文，结果字写得很丑。有时候看前人写的代码，有些写得很恶心，就不像学过编程，基本就是这种情况下写出来的。当然了，经理会忽悠码农，做啥事情都是能提高能力的，扫天下者先要扫厕所。
顺便说一下分工吧，主要有几个工种，PM,RD,QA,OP。这几种工种都会强调自己很重要，说自己是产品开发的中心。具体来说，PM主要是面向用户，偏好是人工干预，自以为了解用户，主要问题是逻辑能力一般，头疼医头，脚疼医脚，都按他们说的做，会把系统弄得一团糟。PM的职责就是催促RD去完成他的产品设计，所以天然跟RD关系是不好的。RD也就是研发了。QA是测试，不过QA喜欢说自己是安全保证，测试只是他们一小部分工作。QA的喜好是把些根本没有意义的BUG，而对产品质量的提升意义不大。什么会这样呢？这样是有段时间QA的考核是按BUG数。而那些重要的功能，RD往往会自测，所以BUG不多。那些根本没意义的功能，RD考虑不到，容易出问题，比如各种根本不可能的配置。其实QA也不容易，刚开始工作那会，QA都是美女，过了一年，都变成男生了。这就是传说中的，女生当男生用，男生当牲口用。OP又叫运维，在RD看来就是负责操作线上机器的，但是OP说他们是运维的，线上操作只是他们工作的一小部分。OP也是命苦的人，各个项目组的RD的操作都要他们作，出点差错，会被批评，所以容易得强迫症。
一般来说，如果一个新产品的收入不符合预期，谁也不知道哪里出了问题。但是PM会说，是RD的代码写的有BUG,RD会说是OP操作错了。
这么辛苦，回报是啥呢？等到评职称，涨工资的时候，老大们说，你的工作有技术含量吗，是个人就可以做。然后那些拿着鞭子催码农加班的人则一路往上升。所以组内的同事，大都会变成祥林嫂，逢人就说：我真傻，真的，光知道埋头干活；不知道是在为人做嫁衣。
然后同事都要走。然后经理开始挽留。挽留会分四个阶段，
第一阶段是许诺有多少多少好处，但是大都不会兑现，上过一次当不会再上第二次，可以参考一下http://hi.baidu.com/rodimus/blog/item/3a91a500505b631d738b6531.html
然后进入第二阶段，这阶段的主要是打击信心，先说要跳槽去的地方怎么怎么不好，再说个人怎么怎么不好，去哪都混不好，一直以来都是他在照顾我们。这阶段就会把人弄得很烦，干脆写个签名档"天要下雨，娘要嫁人"。然后经理也写了个签名档“那么多要嫁人的，是庙太小，还是心太高”。
然后是第三阶段，这阶段主要是人身攻击，比如说，你性格有缺欠，怎么说你都不明白，太偏执了。如果是内部换岗位的话，这些话的影响范围不确定。比如某部门的经理，跟我谈得本来挺好的，结果跟当时的经理谈完之后，态度就变了，他们谈的内容不得而知。
脱了一层皮之后，终于进入第四阶段，这阶段主要是拖。各种流程拖着不让走，能拖一天算一天。
看见挽留无望之后，经理会跟其他同事说，这个人做得很烂，我压根就不留他。这些话可能会在公开场合说，甚至当事人也在场。
据同事说，出去面试的时候，常会问的一个问题是，为什么要跳槽，然后同事苦大仇深的样子，对方说，这个部门我知道，前面有人说了。
具体到我来说，之所以要走，直接原因是职称问题。经理原先的说法是，你某些方面能力存在缺陷，不足以升职称，我说如果是因为我个人能力不够，而职称低，那我认为这个部门不适合我的发展，我选择更适合我发展的地方。过几天经理又改口说，其他大家对你能力都很认可，你在这边成长很快，我说如果个人能力已经到了，职称却偏低，我认为这个部门不公正，我选择更公正的地方。反正就是没完没了的扯皮。
几终折腾，终于跳出火坑。进入一个为日本淫民服务的部门。相关的工作之前主要在上海的分部做，现在要迁回北京总部。所以换部门后第一件事就是去上海交接工作。适逢世博会，住宿吃饭都很麻烦。很多人专程跑到上海看世博的，我既然到上海了，也应该顺便去看看的，只是人实在太多了，所以没去。
交接工作，主要流程是看代码、文档，然后跟别人讲，然后台下有人提问，如果都答上了，就认为接手得不错，可以接手下一个模块。接手比较不爽，一方面是以前都是模块负责人跟我说他的模块是怎么怎么做的，然后我问一下细节，就可以开工了，另一方面是提问的人老问些类似用长连接还是短连接，某常量是多少的问题，弄得很烦。
回到北京后开始具体工作，一开始是负责策略，然后负责抓取、存储、建库之类。
日本的工作，相当不好开展。这里不负责任地猜测一下，市场份额最大的是以人工推荐出名的YAHOO。很多人认为搜索引擎能成功，是因为信息爆炸及需求多样性（也就是也尾理论），但是在日本，这两者都不太符合。日本拍的电影虽然多，但也不至于海量，用户的需求虽然有区别，但是也不会太多，人的基本需求差别不大。
这里顺便说一下工程跟策略的区别吧。虽然都叫研发，但是工作内容差别很大。在系统里有些问题是不能用数学解决的，就算能用数学解决的，也不一定能用计算机解决，能用计算机解决的，也不一定能用现在的机型解决，所以就需要一部分做策略的同学，尝试各种方法，碰运气看哪种方法能更好的解决问题。其实跟中医一样，只是靠积累经验，药方有用，但是背后的理论都是伪科学。既然是碰运气，所以变数大，所以他们自以为这样很有水平，其实就跟买彩票一样，认为变数大，所以回报应该高。
之前贴牛癣的策略同事，大都擅于表扬与自我表扬。刚开始的时候，是A发邮件说B很牛，B说C很牛，C说A很牛。后来觉得这样还不过瘾，A直接就发邮件说自己很牛，B也回邮件说，我也很牛，C说我更牛，这时候A不干了，说活都是我干的……这时候做工程的同事就郁闷了，这代码都是我写的，怎么就没我啥事。遍身绮罗者，不是养蚕人。
不久又到了职称评定的时候。因为上一个经理给我的上半年考核很低分，所以没机会参加职称评定。虽然换部门之前，就知道换部门可能会导致无法参加职称评定的，但是真的到了这时候，还是很不爽的。有点像PIE版上剩女，年轻的时候遇人不淑，上了年纪，也不管自身啥条件，都要房要车。然后考虑别的机会。到外面公司转了一圈，不太顺。
一方面原因是，社招的时候，更看重的是在原来公司的职称。这方法也合理，想通过一两个小时的面试，确定一个人的技术水平也不容易。唐骏之流就是利用了这个漏洞。
另一方面是，工作这两年，确实没学到什么东西。时间都花在处理各种琐碎的小事，比如为什么某个连接出错了，某个客户钱被扣多了，某台机器为什么慢一点。仅剩的一点时间 ，想做点像样子的事情，经理觉得风险大，不让做，或者资源上不支持，大公司里做开发，不是一个人就行的，还需要OP,QA的协助。最后只能做些小打小闹，闭门造车的事。
还有一个原因是，跳的人太多了，把行情拖低了，可以参考一下http://hi.baidu.com/rodimus/blog/item/0ab1b7cee6ff860f92457e38.html
这感觉像在监狱里待久了，虽然越狱了，但是想找个好地方待也不容易
主要还是之前职业规划得不好。记得之前的经理，居然把我写的代码说成他自己写的，然后去参加部门的CODE评比，然后还好意思在我面前自夸技术牛。跟了这种不厚道的经理，早该走的。之前还是过于安土重迁了。
那个经理是把别人的功劳据为己有的老手了，比如09年的时候，他已经是项目经理了，一行代码没写，每天就拿着鞭子催大家干活，居然还评上了年度最佳工程师，这得抢多少人的功劳。
顺便说一下，他怎么催大家干活吧。每天不停地在办公区走来走去，看大家都在干嘛，看到谁不在干活，就直接批评，“你怎么在看论文，活干完了再看”，“你居然在看BBS，还是PIE版”……
怎么催大家加班呢？在项目开始的时候，先假惺惺地跟大家讨论项目排期，然后说，“这个项目正常是要7天，但是作为一名试用期的新人，要好好表现自己，努力一下，3天吧”或者“这个项目很重要，周末努力一下，下周一前提测吧”。然后开始没日没夜地编码，但是万一还是延期了，他又开始说了，“这个排期是你自己定的，现在QA,OP都按这个排期去准备了，对大家的工作造成很大影响，不能延期”，然后只能熬夜写代码了。项目完成了，又假惺惺地说，项目安排要合理，要先紧后松，老这样熬夜写代码，伤身体，代码质量又不好
简单来说，就是对外软弱，把脏活累活接回来，然后对内独裁，整天逼RD干活。为什么会这么BT呢。这跟公司的制度有关，PM经理，QA经理，其他部门的经理的意见都可能会影响经理的晋升，但是RD的意见是影响不了经理的晋升的。所以RD只能用脚投票了。当然大部分经理还是不错的
前面是杂文，后面的部分就当随笔看吧
公司里做事的一个信条是“简单可依赖”，即简单，又可依赖，这当然是好的，但是很难同时满足这两点，有些事情的复杂度就是很高。而且关键的问题的是，“简单”的标准没定下来，有的人觉得四则运算已经很复杂了，只会加减，有的人觉得微积分也很容易。这个原则当然也有它合理的地方，在老员工离职率居高不下，新员工没有体系的培训的情况下，事情必须做得足够简单，简单的标准就是，毕业生可以直接接手。
但是这些人也不是完全地排斥复杂的技术。对复杂的推崇是人的本性，人都喜欢忽悠说自己的东西很复杂，各种祖传秘方。这些人也喜欢说某某部门的技术很牛，很复杂。但是，就是不让自己身边的同事做复杂的事。长得高不是你的错，跟了武大郎就是你不对了。所以这个做事原则，充分保证了将熊熊一窝。
公司里会议特别多，所以有白天开会，晚上写代码的说法。这里分析一下原因吧
首先是因为，有人热衷于开会。开会的作用很大，首先一点，解决问题固然重要，但让老大们觉得事情正开展得轰轰烈烈更重要。开会+群发邮件就是很好的方式。有点像中共的官员，每天的工作就是开会，公司里很多同事，每天的工作也是开会。悄无声息地把问题给解决了，还不如不解决。另外，开会也是抢功劳的重要方式，多点露脸，把事情都说成自己做的，那些没去开会的RD,人们根本就不知道他在干活
没有合适的仲裁方式，一群人没完没了地扯皮。解决问题大都不是选择技术上最好的方案，而是依靠行政力量，把好处留给自己，脏活累活推给别人，所以讨论容易变成办公室政治。但是行政力量也不能完全解决问题，由于历史原因，牛皮癣部门分成两块，有两个老大，他们是平级的，谁也管不了谁。这里不负责地猜测一下原因，这个部门老早就成立了，那时只有一个老大，后来公司裁了一个部门，也裁了些人，引发了些风波，不过那个部门的老大没裁，而是调到牛皮癣部门，又不能让他降级，于是就有了两个老大，一直到现在。
顺便说一下工作很难推动的原因。一方面是每个人都很忙，而又不是所有的负出都有回报的，所以人们只会做两种事情，一是被行政力量逼迫的，必须得做，一是自己发起的，自己有收益的事情。所以想推动别人协助自己的工作很难的，必须得自己的职称比较高，但是自己职称低的话，推动不了别人干活，肯定也是升不上去的。这是个恶性循环。
这个公司有个据说特别帅的CEO，这位CEO偶尔也会以座谈会的方式回答员工的提问。这时候形势就会两边倒，一边是花痴小女生，不停地表达爱慕之情，一边是饱受剥削的男民工在抱怨工资低，CPI涨得快。然后某位高层冲出来表忠心，说那些整天抱怨的民工都是LOSER。CEO觉得光是小女生崇拜他是不够的，于是开始了轰轰烈烈的造神运动。比如像CCAV一样的内网，每天播领导活动；还有一本语录，人手一份，还要考试
项目起名是很重要的，一定要让人听了不知道这个项目是做什么的，出自中国的古典神话，或希腊、罗马神话都可以，越玄越好，正好能唬住没文化的民工。曾经做过一个项目，这个项目大意是要把一个本来只是流式处理数据，没有状态数据的模块，改成记录所有数据，所以内部叫法是“****状态化”，后来某人起名叫“运河计划”，化腐朽为神奇。取意是说，这个模块连接了公司很重要的两部分服务，所以称为运河。后来想了想，这种说法不对，这两部分服务本来就是连接，只是流式的，也就是类似消息队列的功能，现在要做的是把消息队列的内容存下来，叫水库比运河更合适，叫“三峡工程”多好，不过貌似现在中共也不拿这个当政绩了，不吉利。
--------------------------------
刚开始去的部门是负责在网页上贴牛皮癣，这个比较惹人讨论的。不过自然会有人发明出一些理论证明牛皮癣的意义，比如长尾理论。还会发展出相应的学科，比如计算广告学。
说远了，其实这些都跟我没关系。偶是个码农，就负责没日没夜的写代码。公司说要向硅谷学习，实行弹性工作制，可这是中国特色的弹性工作制，只可延长，不可缩短。九点下班那算早的，十点下班才算正常。事实上就没有下班的时候，经常会凌晨的时候一个电话打过来，然后回公司去处理线上事故。为什么老在凌晨的时候出事故呢？这跟线上服务有关系，晚上上网的人少，所以很多复杂的操作都留在晚上做，比如更新数据。这些操作往往会导致事故。凌晨不睡觉起来处理事故，有啥好处呢？加班费肯定是没有的。就没有加班的概念，因为是弹性工作制。第二天首先要追究事故责任。如果是我们自己的代码导致线上事故，然后扣钱，通报批评，自我检讨。如果是别人的代码导致线上事故呢？然后老大们会说你们响应太慢了，从事故发生到解决，居然花了一个小时，导致公司损失了多少多少钱，好好检讨一下应急机制，然后还是扣奖金。
没日没夜的加班，周末、加节也加班，加上出了点小事故就没完没了，导致的是，面黄肌瘦，早生华发，同时伴有强迫症，写代码的时候小心翼翼，反复测试，线上操作的时候，反复校对操作单、配置项。
每次做项目的时候就说，大家好好干，辛苦几天，做完这个项目就休息。事实上一个项目没做完，另一个项目已经在排期了。为什么会这么忙呢？主要是因为码农的需求来源有几个，一是PM，主要是提一些产品层面的需求，一是策略，主要是提些按什么规则贴牛皮癣的需求，一是公司上层，涉及到商业模式的变更，比如按什么规则收费。用IT的行话说，码农就是这些人的共享资源，都在争夺的，根本就不会有闲下来的时候。哪天运气好，真的闲下来了，直接经理也会没事找事，让码农干点事情，以体现他的管理水平，比如整 理下文档，整理一下统计报表。
在这种情况下写代码，会造成代码能力下降。记得小时候，字写得本来不丑，后来语文老师老逼着抄课文，结果字写得很丑。有时候看前人写的代码，有些写得很恶心，就不像学过编程，基本就是这种情况下写出来的。当然了，经理会忽悠码农，做啥事情都是能提高能力的，扫天下者先要扫厕所。
顺便说一下分工吧，主要有几个工种，PM,RD,QA,OP。这几种工种都会强调自己很重要，说自己是产品开发的中心。具体来说，PM主要是面向用户，偏好是人工干预，自以为了解用户，主要问题是逻辑能力一般，头疼医头，脚疼医脚，都按他们说的做，会把系统弄得一团糟。PM的职责就是催促RD去完成他的产品设计，所以天然跟RD关系是不好的。RD也就是研发了。QA是测试，不过QA喜欢说自己是安全保证，测试只是他们一小部分工作。QA的喜好是把些根本没有意义的BUG，而对产品质量的提升意义不大。什么会这样呢？这样是有段时间QA的考核是按BUG数。而那些重要的功能，RD往往会自测，所以BUG不多。那些根本没意义的功能，RD考虑不到，容易出问题，比如各种根本不可能的配置。其实QA也不容易，刚开始工作那会，QA都是美女，过了一年，都变成男生了。这就是传说中的，女生当男生用，男生当牲口用。OP又叫运维，在RD看来就是负责操作线上机器的，但是OP说他们是运维的，线上操作只是他们工作的一小部分。OP也是命苦的人，各个项目组的RD的操作都要他们作，出点差错，会被批评，所以容易得强迫症。
一般来说，如果一个新产品的收入不符合预期，谁也不知道哪里出了问题。但是PM会说，是RD的代码写的有BUG,RD会说是OP操作错了。
这么辛苦，回报是啥呢？等到评职称，涨工资的时候，老大们说，你的工作有技术含量吗，是个人就可以做。然后那些拿着鞭子催码农加班的人则一路往上升。所以组内的同事，大都会变成祥林嫂，逢人就说：我真傻，真的，光知道埋头干活；不知道是在为人做嫁衣。
然后同事都要走。然后经理开始挽留。挽留会分四个阶段，
第一阶段是许诺有多少多少好处，但是大都不会兑现，上过一次当不会再上第二次，可以参考一下http://hi.baidu.com/rodimus/blog/item/3a91a500505b631d738b6531.html
然后进入第二阶段，这阶段的主要是打击信心，先说要跳槽去的地方怎么怎么不好，再说个人怎么怎么不好，去哪都混不好，一直以来都是他在照顾我们。这阶段就会把人弄得很烦，干脆写个签名档"天要下雨，娘要嫁人"。然后经理也写了个签名档“那么多要嫁人的，是庙太小，还是心太高”。
然后是第三阶段，这阶段主要是人身攻击，比如说，你性格有缺欠，怎么说你都不明白，太偏执了。如果是内部换岗位的话，这些话的影响范围不确定。比如某部门的经理，跟我谈得本来挺好的，结果跟当时的经理谈完之后，态度就变了，他们谈的内容不得而知。
脱了一层皮之后，终于进入第四阶段，这阶段主要是拖。各种流程拖着不让走，能拖一天算一天。
看见挽留无望之后，经理会跟其他同事说，这个人做得很烂，我压根就不留他。这些话可能会在公开场合说，甚至当事人也在场。
据同事说，出去面试的时候，常会问的一个问题是，为什么要跳槽，然后同事苦大仇深的样子，对方说，这个部门我知道，前面有人说了。
具体到我来说，之所以要走，直接原因是职称问题。经理原先的说法是，你某些方面能力存在缺陷，不足以升职称，我说如果是因为我个人能力不够，而职称低，那我认为这个部门不适合我的发展，我选择更适合我发展的地方。过几天经理又改口说，其他大家对你能力都很认可，你在这边成长很快，我说如果个人能力已经到了，职称却偏低，我认为这个部门不公正，我选择更公正的地方。反正就是没完没了的扯皮。
几终折腾，终于跳出火坑。进入一个为日本淫民服务的部门。相关的工作之前主要在上海的分部做，现在要迁回北京总部。所以换部门后第一件事就是去上海交接工作。适逢世博会，住宿吃饭都很麻烦。很多人专程跑到上海看世博的，我既然到上海了，也应该顺便去看看的，只是人实在太多了，所以没去。
交接工作，主要流程是看代码、文档，然后跟别人讲，然后台下有人提问，如果都答上了，就认为接手得不错，可以接手下一个模块。接手比较不爽，一方面是以前都是模块负责人跟我说他的模块是怎么怎么做的，然后我问一下细节，就可以开工了，另一方面是提问的人老问些类似用长连接还是短连接，某常量是多少的问题，弄得很烦。
回到北京后开始具体工作，一开始是负责策略，然后负责抓取、存储、建库之类。
日本的工作，相当不好开展。这里不负责任地猜测一下，市场份额最大的是以人工推荐出名的YAHOO。很多人认为搜索引擎能成功，是因为信息爆炸及需求多样性（也就是也尾理论），但是在日本，这两者都不太符合。日本拍的电影虽然多，但也不至于海量，用户的需求虽然有区别，但是也不会太多，人的基本需求差别不大。
这里顺便说一下工程跟策略的区别吧。虽然都叫研发，但是工作内容差别很大。在系统里有些问题是不能用数学解决的，就算能用数学解决的，也不一定能用计算机解决，能用计算机解决的，也不一定能用现在的机型解决，所以就需要一部分做策略的同学，尝试各种方法，碰运气看哪种方法能更好的解决问题。其实跟中医一样，只是靠积累经验，药方有用，但是背后的理论都是伪科学。既然是碰运气，所以变数大，所以他们自以为这样很有水平，其实就跟买彩票一样，认为变数大，所以回报应该高。
之前贴牛癣的策略同事，大都擅于表扬与自我表扬。刚开始的时候，是A发邮件说B很牛，B说C很牛，C说A很牛。后来觉得这样还不过瘾，A直接就发邮件说自己很牛，B也回邮件说，我也很牛，C说我更牛，这时候A不干了，说活都是我干的……这时候做工程的同事就郁闷了，这代码都是我写的，怎么就没我啥事。遍身绮罗者，不是养蚕人。
不久又到了职称评定的时候。因为上一个经理给我的上半年考核很低分，所以没机会参加职称评定。虽然换部门之前，就知道换部门可能会导致无法参加职称评定的，但是真的到了这时候，还是很不爽的。有点像PIE版上剩女，年轻的时候遇人不淑，上了年纪，也不管自身啥条件，都要房要车。然后考虑别的机会。到外面公司转了一圈，不太顺。
一方面原因是，社招的时候，更看重的是在原来公司的职称。这方法也合理，想通过一两个小时的面试，确定一个人的技术水平也不容易。唐骏之流就是利用了这个漏洞。
另一方面是，工作这两年，确实没学到什么东西。时间都花在处理各种琐碎的小事，比如为什么某个连接出错了，某个客户钱被扣多了，某台机器为什么慢一点。仅剩的一点时间 ，想做点像样子的事情，经理觉得风险大，不让做，或者资源上不支持，大公司里做开发，不是一个人就行的，还需要OP,QA的协助。最后只能做些小打小闹，闭门造车的事。
还有一个原因是，跳的人太多了，把行情拖低了，可以参考一下http://hi.baidu.com/rodimus/blog/item/0ab1b7cee6ff860f92457e38.html
这感觉像在监狱里待久了，虽然越狱了，但是想找个好地方待也不容易
主要还是之前职业规划得不好。记得之前的经理，居然把我写的代码说成他自己写的，然后去参加部门的CODE评比，然后还好意思在我面前自夸技术牛。跟了这种不厚道的经理，早该走的。之前还是过于安土重迁了。
那个经理是把别人的功劳据为己有的老手了，比如09年的时候，他已经是项目经理了，一行代码没写，每天就拿着鞭子催大家干活，居然还评上了年度最佳工程师，这得抢多少人的功劳。
顺便说一下，他怎么催大家干活吧。每天不停地在办公区走来走去，看大家都在干嘛，看到谁不在干活，就直接批评，“你怎么在看论文，活干完了再看”，“你居然在看BBS，还是PIE版”……
怎么催大家加班呢？在项目开始的时候，先假惺惺地跟大家讨论项目排期，然后说，“这个项目正常是要7天，但是作为一名试用期的新人，要好好表现自己，努力一下，3天吧”或者“这个项目很重要，周末努力一下，下周一前提测吧”。然后开始没日没夜地编码，但是万一还是延期了，他又开始说了，“这个排期是你自己定的，现在QA,OP都按这个排期去准备了，对大家的工作造成很大影响，不能延期”，然后只能熬夜写代码了。项目完成了，又假惺惺地说，项目安排要合理，要先紧后松，老这样熬夜写代码，伤身体，代码质量又不好
简单来说，就是对外软弱，把脏活累活接回来，然后对内独裁，整天逼RD干活。为什么会这么BT呢。这跟公司的制度有关，PM经理，QA经理，其他部门的经理的意见都可能会影响经理的晋升，但是RD的意见是影响不了经理的晋升的。所以RD只能用脚投票了。当然大部分经理还是不错的
前面是杂文，后面的部分就当随笔看吧
公司里做事的一个信条是“简单可依赖”，即简单，又可依赖，这当然是好的，但是很难同时满足这两点，有些事情的复杂度就是很高。而且关键的问题的是，“简单”的标准没定下来，有的人觉得四则运算已经很复杂了，只会加减，有的人觉得微积分也很容易。这个原则当然也有它合理的地方，在老员工离职率居高不下，新员工没有体系的培训的情况下，事情必须做得足够简单，简单的标准就是，毕业生可以直接接手。
但是这些人也不是完全地排斥复杂的技术。对复杂的推崇是人的本性，人都喜欢忽悠说自己的东西很复杂，各种祖传秘方。这些人也喜欢说某某部门的技术很牛，很复杂。但是，就是不让自己身边的同事做复杂的事。长得高不是你的错，跟了武大郎就是你不对了。所以这个做事原则，充分保证了将熊熊一窝。
公司里会议特别多，所以有白天开会，晚上写代码的说法。这里分析一下原因吧
首先是因为，有人热衷于开会。开会的作用很大，首先一点，解决问题固然重要，但让老大们觉得事情正开展得轰轰烈烈更重要。开会+群发邮件就是很好的方式。有点像中共的官员，每天的工作就是开会，公司里很多同事，每天的工作也是开会。悄无声息地把问题给解决了，还不如不解决。另外，开会也是抢功劳的重要方式，多点露脸，把事情都说成自己做的，那些没去开会的RD,人们根本就不知道他在干活
没有合适的仲裁方式，一群人没完没了地扯皮。解决问题大都不是选择技术上最好的方案，而是依靠行政力量，把好处留给自己，脏活累活推给别人，所以讨论容易变成办公室政治。但是行政力量也不能完全解决问题，由于历史原因，牛皮癣部门分成两块，有两个老大，他们是平级的，谁也管不了谁。这里不负责地猜测一下原因，这个部门老早就成立了，那时只有一个老大，后来公司裁了一个部门，也裁了些人，引发了些风波，不过那个部门的老大没裁，而是调到牛皮癣部门，又不能让他降级，于是就有了两个老大，一直到现在。
顺便说一下工作很难推动的原因。一方面是每个人都很忙，而又不是所有的负出都有回报的，所以人们只会做两种事情，一是被行政力量逼迫的，必须得做，一是自己发起的，自己有收益的事情。所以想推动别人协助自己的工作很难的，必须得自己的职称比较高，但是自己职称低的话，推动不了别人干活，肯定也是升不上去的。这是个恶性循环。
这个公司有个据说特别帅的CEO，这位CEO偶尔也会以座谈会的方式回答员工的提问。这时候形势就会两边倒，一边是花痴小女生，不停地表达爱慕之情，一边是饱受剥削的男民工在抱怨工资低，CPI涨得快。然后某位高层冲出来表忠心，说那些整天抱怨的民工都是LOSER。CEO觉得光是小女生崇拜他是不够的，于是开始了轰轰烈烈的造神运动。比如像CCAV一样的内网，每天播领导活动；还有一本语录，人手一份，还要考试
项目起名是很重要的，一定要让人听了不知道这个项目是做什么的，出自中国的古典神话，或希腊、罗马神话都可以，越玄越好，正好能唬住没文化的民工。曾经做过一个项目，这个项目大意是要把一个本来只是流式处理数据，没有状态数据的模块，改成记录所有数据，所以内部叫法是“****状态化”，后来某人起名叫“运河计划”，化腐朽为神奇。取意是说，这个模块连接了公司很重要的两部分服务，所以称为运河。后来想了想，这种说法不对，这两部分服务本来就是连接，只是流式的，也就是类似消息队列的功能，现在要做的是把消息队列的内容存下来，叫水库比运河更合适，叫“三峡工程”多好，不过貌似现在中共也不拿这个当政绩了，不吉利。
校招杂谈 from 老白说真话|LaoBai’s Blog
作者 Fenng 426 天 前 (http://blog.donews.com)
过去的一个月里，花了一些时间为我供职的公司完成了我人生第一次的校园招聘任务。三个城市、七所大学，除了宣讲、判卷以外，每个城市每天完成面试的人数大于20。
每个面试20分钟，每天30人，就是600分钟，相当于10个小时不吃不喝和智力博弈。但和老板们相比，还是小巫，老板的记录都是每天30-50人。
也许有人会认为这个时间密度是草菅人命，但其实，和庞大的毕业生队伍相比，我们面试的越多，实际上是给了更多人机会！（当然，能快速进入状态的人选会占些便宜）
毕业快20年了，又走入校园，感触很多，分享如下：
1、校园的硬件都可以刮目相看了
在成都，我去了电子科技大，丁磊的母校。道听途说丁磊对自己的母校并不感冒，宁可给老家的宁波大学捐钱。去了成电，发现确实也没这个必要，成电校园之开阔超出想象。
稍后，又去了广州大学城。这个在珠江划出来的一个小岛，聚集了10余所大学。大开大合的规划和南方宜人的气候，又让我再一次震惊了。中山大学和华南理工（以建筑专业著名）其密度之低令人叹为观止。我知道同学们的交通工具基本上是自行车，但以我现在的高龄，我觉得没有四个轮子我很难在这些校园里游走。
2、教学质量和硬件相比，差的很远
尽管学生们都知道就业难，但从学校教学到学生自己，都没有把商业经验和社会经验当作一门重要的课程去学。
很多学校、很多专业的学生，还是近亲繁殖，用着本校老师攒的教材照本宣科。我面试的学生主要是供应链和物流专业，但很多读到了硕士的学生，都不知道仓库应该有几个门，都没见过货架和托盘。
华南理工不错，我在他们宣传栏里看到，管理学专业的学生学经济学，用得是曼昆的教材。软件工程专业的学生，用得也多是翻译的教材。这就是一个好的方向，我当年的教科书，前言里都是马克思和列宁怎么说。
西南交大就有些问题，这个曾隶属铁道部的工科院校，居然也有了美术和设计专业。有人和我讲，这是n次扩招的恶果，以前的选修课老师，也正式开门收徒了。但以我面试的感觉，我不好评价那些老师，就同学而言，连美术和设计的皮毛都没有学到。实在是误人子弟。
3、尽管有那么多不如意，人才永远是最重要的
我现在所在的公司只有600人，但今年校园招聘，我们兵分多路，至少走了北京、天津、大连、西安、成都、上海、重庆、广州、合肥等9个城市，宣讲了近20所高校，覆盖了超过50所高校的毕业生。
我们还要和华为、腾讯、阿里、盛大等知名互联网企业以及著名外资企业PK，如此大的投入为了什么？为了给同学们一个机会，多一个选择，也为了–我们的未来。
每个面试20分钟，每天30人，就是600分钟，相当于10个小时不吃不喝和智力博弈。但和老板们相比，还是小巫，老板的记录都是每天30-50人。
也许有人会认为这个时间密度是草菅人命，但其实，和庞大的毕业生队伍相比，我们面试的越多，实际上是给了更多人机会！（当然，能快速进入状态的人选会占些便宜）
毕业快20年了，又走入校园，感触很多，分享如下：
1、校园的硬件都可以刮目相看了
在成都，我去了电子科技大，丁磊的母校。道听途说丁磊对自己的母校并不感冒，宁可给老家的宁波大学捐钱。去了成电，发现确实也没这个必要，成电校园之开阔超出想象。
稍后，又去了广州大学城。这个在珠江划出来的一个小岛，聚集了10余所大学。大开大合的规划和南方宜人的气候，又让我再一次震惊了。中山大学和华南理工（以建筑专业著名）其密度之低令人叹为观止。我知道同学们的交通工具基本上是自行车，但以我现在的高龄，我觉得没有四个轮子我很难在这些校园里游走。
2、教学质量和硬件相比，差的很远
尽管学生们都知道就业难，但从学校教学到学生自己，都没有把商业经验和社会经验当作一门重要的课程去学。
很多学校、很多专业的学生，还是近亲繁殖，用着本校老师攒的教材照本宣科。我面试的学生主要是供应链和物流专业，但很多读到了硕士的学生，都不知道仓库应该有几个门，都没见过货架和托盘。
华南理工不错，我在他们宣传栏里看到，管理学专业的学生学经济学，用得是曼昆的教材。软件工程专业的学生，用得也多是翻译的教材。这就是一个好的方向，我当年的教科书，前言里都是马克思和列宁怎么说。
西南交大就有些问题，这个曾隶属铁道部的工科院校，居然也有了美术和设计专业。有人和我讲，这是n次扩招的恶果，以前的选修课老师，也正式开门收徒了。但以我面试的感觉，我不好评价那些老师，就同学而言，连美术和设计的皮毛都没有学到。实在是误人子弟。
3、尽管有那么多不如意，人才永远是最重要的
我现在所在的公司只有600人，但今年校园招聘，我们兵分多路，至少走了北京、天津、大连、西安、成都、上海、重庆、广州、合肥等9个城市，宣讲了近20所高校，覆盖了超过50所高校的毕业生。
我们还要和华为、腾讯、阿里、盛大等知名互联网企业以及著名外资企业PK，如此大的投入为了什么？为了给同学们一个机会，多一个选择，也为了–我们的未来。
我希望看到什么样的简历 by awflasher
作者 Fenng 451 天 前 (http://www.awflasher.com)
前几天看了一下，公司一大半人都是我亲自邀请或者招到的。现在也一直在继续招人。
最近又正好是07级本科毕业生和一部分应届研究生找工作的时机。虽然不是专业的HR，但作为公司负责人，我也想把最近招人的一些感受分享一下：
一、希望看到职位针对性强的简历
收到一份没有职位意向的简历是非常令人反感的。比如你想应聘PHP开发这个职位，但你的简历中根本没有“PHP开发”这样的关键词，那么被录用的机会就会大打折扣。当然，你也可以用一些灵活的描述据代替某一个具体的“职位”。总之，得有一个目的。整片简历扫一眼如果都不知道你想做什么事情，那我觉得被直接pass的可能性是非常非常大的了。
二、希望看到有较强入职意向的简历
创业公司的发展优势是什么？快！天下武功，唯快不破！
那么在组建团队和吸纳人才方面，创业公司一般都是非常希望能找到有强烈入职意向的人的（所谓“志同道合”）。所以，在简历中体现一个“最快入职时间”，我觉得会比较有吸引力。
三、希望看到有Blog、作品具体项目的简历
如果是应聘美术类、设计类的工作，一定要附上作品。对我来说，其实一个个人主页或Blog链接（如果担心隐私外泄，可以建立一个专门放作品的blog）比放到附件里的作品更有吸引力。作品是死的而Blog是活的，通过Blog可以看到一个人不同时期的水平和历练。另外，如果一定要发附件，请尽量直接发图，或者zip，发rar的我基本上就懒得看了。
四、希望看到言简意赅的简历
特别害怕看到放了大量诸如“校园XX节表演冠军”、“选修了XX、XX、XXX、XXX……课”、“参加了XXX社团”、“在X、X、X公司实习”的简历。这些东西其实简单介绍一下就OK，我看到一些简历把非常鸡毛蒜皮的事情都放上去，让人哭笑不得。
当然，我非常理解应届毕业生的处境，毕竟中国高等教育本身就存在缺陷，从大一入学军训，到大三的所谓“实习”，大多数情况下，如果你自己不努力跳出来，是学不到什么实际经验的。写简历的时候可能什么事情都想不出来，这时就想把那些很细微的精力都搬出来。我建议如果写不出经验就简短描述自己的性格和兴趣，都好过那些可怕的堆积内容。
五、希望看到有期望薪酬的简历
期望薪酬放到简历中是非常有意义的！加入期望薪酬非常有助于提高双方沟通的效率。几年来，看到很多小漫画，以薪酬为主体去激化公司和员工之间的“矛盾”，我现在觉得真的是非常扯淡。其实对于一个真正有理想的公司来说，薪酬体系的设计是会非常重视的。同样地，越是足够优秀的人才也越是明白人，应该越了解自己的价值。作为公司来说，亏待一个人，实际上是给自己的发展找麻烦。（某些极权“公司”除外）
–
总结
这些建议可能不适用于其他单位，比如一些大公司或者国企，毕竟我不是专业的HR。但对于创业公司来说，我相信很多同道中人会认同我的观点。
另啰嗦一句，很多大公司会做“人才囤积”（不算“人才储备”），就是把许多毕业生招进来“慢慢培养”，而其主要目的是不想让竞争对手给招过去。这样对大公司来说虽然多花一些成本，但避免了战略上的潜在压力。而创业公司里，同样职位所做的项目和产品则肯定是非常给力的（套用最新的一个单词叫very geliable）。这是创业公司的一个优势。因此，选择一个优秀、与自己长期发展匹配的创业公司，可能会比去一个大公司有更大的价值。
本文来自：http://www.awflasher.com/blog/archives/1836
最近又正好是07级本科毕业生和一部分应届研究生找工作的时机。虽然不是专业的HR，但作为公司负责人，我也想把最近招人的一些感受分享一下：
一、希望看到职位针对性强的简历
收到一份没有职位意向的简历是非常令人反感的。比如你想应聘PHP开发这个职位，但你的简历中根本没有“PHP开发”这样的关键词，那么被录用的机会就会大打折扣。当然，你也可以用一些灵活的描述据代替某一个具体的“职位”。总之，得有一个目的。整片简历扫一眼如果都不知道你想做什么事情，那我觉得被直接pass的可能性是非常非常大的了。
二、希望看到有较强入职意向的简历
创业公司的发展优势是什么？快！天下武功，唯快不破！
那么在组建团队和吸纳人才方面，创业公司一般都是非常希望能找到有强烈入职意向的人的（所谓“志同道合”）。所以，在简历中体现一个“最快入职时间”，我觉得会比较有吸引力。
三、希望看到有Blog、作品具体项目的简历
如果是应聘美术类、设计类的工作，一定要附上作品。对我来说，其实一个个人主页或Blog链接（如果担心隐私外泄，可以建立一个专门放作品的blog）比放到附件里的作品更有吸引力。作品是死的而Blog是活的，通过Blog可以看到一个人不同时期的水平和历练。另外，如果一定要发附件，请尽量直接发图，或者zip，发rar的我基本上就懒得看了。
四、希望看到言简意赅的简历
特别害怕看到放了大量诸如“校园XX节表演冠军”、“选修了XX、XX、XXX、XXX……课”、“参加了XXX社团”、“在X、X、X公司实习”的简历。这些东西其实简单介绍一下就OK，我看到一些简历把非常鸡毛蒜皮的事情都放上去，让人哭笑不得。
当然，我非常理解应届毕业生的处境，毕竟中国高等教育本身就存在缺陷，从大一入学军训，到大三的所谓“实习”，大多数情况下，如果你自己不努力跳出来，是学不到什么实际经验的。写简历的时候可能什么事情都想不出来，这时就想把那些很细微的精力都搬出来。我建议如果写不出经验就简短描述自己的性格和兴趣，都好过那些可怕的堆积内容。
五、希望看到有期望薪酬的简历
期望薪酬放到简历中是非常有意义的！加入期望薪酬非常有助于提高双方沟通的效率。几年来，看到很多小漫画，以薪酬为主体去激化公司和员工之间的“矛盾”，我现在觉得真的是非常扯淡。其实对于一个真正有理想的公司来说，薪酬体系的设计是会非常重视的。同样地，越是足够优秀的人才也越是明白人，应该越了解自己的价值。作为公司来说，亏待一个人，实际上是给自己的发展找麻烦。（某些极权“公司”除外）
–
总结
这些建议可能不适用于其他单位，比如一些大公司或者国企，毕竟我不是专业的HR。但对于创业公司来说，我相信很多同道中人会认同我的观点。
另啰嗦一句，很多大公司会做“人才囤积”（不算“人才储备”），就是把许多毕业生招进来“慢慢培养”，而其主要目的是不想让竞争对手给招过去。这样对大公司来说虽然多花一些成本，但避免了战略上的潜在压力。而创业公司里，同样职位所做的项目和产品则肯定是非常给力的（套用最新的一个单词叫very geliable）。这是创业公司的一个优势。因此，选择一个优秀、与自己长期发展匹配的创业公司，可能会比去一个大公司有更大的价值。
本文来自：http://www.awflasher.com/blog/archives/1836
A few months ago I blogged about the fact that IBM was looking for two interns to fill a longterm (paid) internship. The good news is that after an extensive selection process and a hearty dose of governmental bureaucracy (which is not unusual when relocating countries), two students have finally been able to join our DB2 team at the lab.
In case you are curious about who the students are, they’re Marius Butuc from Romania, and Henrique Zambon from Brazil. They’re good guys, feel free to follow them on Twitter (even though Henrique’s stream may be more interesting to you if you speak Portuguese).
The selection process
I received about 100 resumes from students around the globe who wanted to apply for the internship. Of those, I invited the 50 most promising applicants to have an initial phone interview, as I wanted to give a fair chance to everyone (yet at the same time, I didn’t want get the hopes up of those who clearly didn’t have a shot, and thus the remaining applicants were informed that they hadn’t made the initial cut).
Before their first interviews took place, I assigned the 50 preselected candidates a coding project. They could either develop a CSV to HTML converter, a search client using Twitter’s API, or an S3 uploader.
While none of these exercises were rocket science, they were intended to provide us with an general idea of the students’ ability to code. Most candidates went for the CSV to HTML converter. Some chose the Twitter client, and a tiny handful opted for the S3 uploader (one ambitious candidate delivered all three).
After carefully reviewing their code, I held the technical interviews with all of the candidates who had sent in their assignments. During the first interview I asked each person a series of very technical questions, and in some instances we also discussed their assignments. In most cases each interview lasted for an hour.
After the initial round of interviews had wrapped up, I selected the 10 most promising candidates for a second phone call and informed the others that they wouldn’t be continuing on with the interview process.
For the second round of interviews I was joined by my manager, and together we conducted phone calls with each candidate that were based less on the each person’s technical skills. This second interview was meant to test their soft skills, to get a feel for their interests, and to assess their overall attitude.
There were important interviews because they helped us get to know the candidates a bit better. Our aim was to learn about what excited these eager applicants, to see their level of passion for programming, and to observe other skills that were not strictly related to coding. We also discussed the project they’d be working on if they were selected, our team approach (we are more of an Agile startup than the stereotypical image you may have of IBM), and discussed details of the next steps with each of these ten candidates.
At this point Leon (my manager) and I discussed at length which two applicants we wanted to select. All ten students were top notch candidates, so the choice wasn’t an easy one for us. We ended up considering every single bit of information at our disposal about the students, from their their resumes and past experiences to their performance with the technical assignment, what (human and programming) languages they knew, and how they’d faired with both of the interviews.
After a lot of consideration, we ended up selecting Marius and Henrique. (In case you’re wondering, the student who did all three assignment was also from Romania and he was ultimately our third choice, had either Marius or Henrique been unable to accept the internship position.)
What I learned from reviewing so many candidates
When you receive 100 resumes from very good students from around the world, you quickly come to realize that it’s surprisingly hard to determine someone’s real ability. Just about everyone looked pretty darn good on paper! That’s why I had to extrapolate what made each person unique via specific elements that weren’t based on coursework or grades (more on this later).
The coding assignment was a huge asset in determining people’s real abilities. Some of the nicest assignments came from those with academically weaker performances. You could clearly see who the hackers and potential future computer science professors were. Without the assignment, the selection process would have been much harder, so I’m glad that it was something we required the applicants to do.
With just a few exceptions, even good students seemed to struggle with relatively straightforward algorithmic questions, more than any other type of question. Sample questions included: What’s a Red-Black Tree and what would you use it for? Can you explain the P versus NP problem to me? (Note that these were rather open-ended questions, which I would generally follow up with more specific questions to assess the applicants’ theoretical backgrounds — as well as their way of thinking about these kinds of problems.)
Most students didn’t know much about programming in the real world. In particular, they didn’t seem to be very up-to-date, most having never heard of things like SVN, GIT, MVC, ORM, Agile programming, or NoSQL.
In general, the qualifications listed on the resumes we saw were greatly exaggerated by mediocre candidates, and somewhat downplayed by the great ones. (It looked like some form of Dunning–Kruger effect was at work.)
Some candidates, taking advantage of the long distance telephone interview, tried to Google their answers and I could literally hear them typing as I presented them with questions that they weren’t familiar with. Replies such as, “Hmmm…well…”, followed by a 20 second pause and then the all but cut and paste Wikipedia definition. This was very easy to spot and didn’t end up boding well for those candidates who opted for this less than honest route.
Recruiting is hard. It takes a lot of time and energy; rational decisions are challenging to make because in most cases you really are comparing apple to oranges.
What made a resume stick out to me
Open Source contributions (a GitHub link would immediately arouse my interest in that candidate).
A concise but detailed description of practical projects that had been implemented by the student for companies outside of their coursework (whether on the side or through internships).
Social media involvement in the programming community. Did they have a StackOverflow profile? A Twitter account related to programming? Perhaps a a blog dedicated to the subject? While these points alone certainly don’t mean someone is a good programmer, they are a decent indicator that a person is at least passionate about the subject. Attendance of industry conferences (which some had) was also a strong indicator of interest in the field.
Knowledge of unusual programming languages. Virtually everyone had Java on their resume, however that alone wasn’t good enough to catch my eye as an interviewer. (Heck, even Python is starting to be pretty common.) When candidates claimed knowledge of Haskell, Scala, Clojure, OCaml, Scheme, Factor, Io, J, etc… that definitely grabbed my attention. Again, this is no guarantee that someone is a good programmer, but chances are that they have an above average interest in our profession or have attended a university where these languages were taught (both positive signs).
While I’m not sure what you’ll get out of this article, I thought it was worth sharing as I found the whole process described above to be a fascinating one. Perhaps if you’re a student in a similar position you’ll find tips on what to do when applying for an internship with a company such as IBM. If you’ve ever found yourself in a similar interviewer’s position, you’ll likely find numerous relatable points in this post.
中文版本参见：http://www.aqee.net/2010/10/12/things-i%E2%80%99ve-learned-from-hiring-interns-for-ibm/
In case you are curious about who the students are, they’re Marius Butuc from Romania, and Henrique Zambon from Brazil. They’re good guys, feel free to follow them on Twitter (even though Henrique’s stream may be more interesting to you if you speak Portuguese).
The selection process
I received about 100 resumes from students around the globe who wanted to apply for the internship. Of those, I invited the 50 most promising applicants to have an initial phone interview, as I wanted to give a fair chance to everyone (yet at the same time, I didn’t want get the hopes up of those who clearly didn’t have a shot, and thus the remaining applicants were informed that they hadn’t made the initial cut).
Before their first interviews took place, I assigned the 50 preselected candidates a coding project. They could either develop a CSV to HTML converter, a search client using Twitter’s API, or an S3 uploader.
While none of these exercises were rocket science, they were intended to provide us with an general idea of the students’ ability to code. Most candidates went for the CSV to HTML converter. Some chose the Twitter client, and a tiny handful opted for the S3 uploader (one ambitious candidate delivered all three).
After carefully reviewing their code, I held the technical interviews with all of the candidates who had sent in their assignments. During the first interview I asked each person a series of very technical questions, and in some instances we also discussed their assignments. In most cases each interview lasted for an hour.
After the initial round of interviews had wrapped up, I selected the 10 most promising candidates for a second phone call and informed the others that they wouldn’t be continuing on with the interview process.
For the second round of interviews I was joined by my manager, and together we conducted phone calls with each candidate that were based less on the each person’s technical skills. This second interview was meant to test their soft skills, to get a feel for their interests, and to assess their overall attitude.
There were important interviews because they helped us get to know the candidates a bit better. Our aim was to learn about what excited these eager applicants, to see their level of passion for programming, and to observe other skills that were not strictly related to coding. We also discussed the project they’d be working on if they were selected, our team approach (we are more of an Agile startup than the stereotypical image you may have of IBM), and discussed details of the next steps with each of these ten candidates.
At this point Leon (my manager) and I discussed at length which two applicants we wanted to select. All ten students were top notch candidates, so the choice wasn’t an easy one for us. We ended up considering every single bit of information at our disposal about the students, from their their resumes and past experiences to their performance with the technical assignment, what (human and programming) languages they knew, and how they’d faired with both of the interviews.
After a lot of consideration, we ended up selecting Marius and Henrique. (In case you’re wondering, the student who did all three assignment was also from Romania and he was ultimately our third choice, had either Marius or Henrique been unable to accept the internship position.)
What I learned from reviewing so many candidates
When you receive 100 resumes from very good students from around the world, you quickly come to realize that it’s surprisingly hard to determine someone’s real ability. Just about everyone looked pretty darn good on paper! That’s why I had to extrapolate what made each person unique via specific elements that weren’t based on coursework or grades (more on this later).
The coding assignment was a huge asset in determining people’s real abilities. Some of the nicest assignments came from those with academically weaker performances. You could clearly see who the hackers and potential future computer science professors were. Without the assignment, the selection process would have been much harder, so I’m glad that it was something we required the applicants to do.
With just a few exceptions, even good students seemed to struggle with relatively straightforward algorithmic questions, more than any other type of question. Sample questions included: What’s a Red-Black Tree and what would you use it for? Can you explain the P versus NP problem to me? (Note that these were rather open-ended questions, which I would generally follow up with more specific questions to assess the applicants’ theoretical backgrounds — as well as their way of thinking about these kinds of problems.)
Most students didn’t know much about programming in the real world. In particular, they didn’t seem to be very up-to-date, most having never heard of things like SVN, GIT, MVC, ORM, Agile programming, or NoSQL.
In general, the qualifications listed on the resumes we saw were greatly exaggerated by mediocre candidates, and somewhat downplayed by the great ones. (It looked like some form of Dunning–Kruger effect was at work.)
Some candidates, taking advantage of the long distance telephone interview, tried to Google their answers and I could literally hear them typing as I presented them with questions that they weren’t familiar with. Replies such as, “Hmmm…well…”, followed by a 20 second pause and then the all but cut and paste Wikipedia definition. This was very easy to spot and didn’t end up boding well for those candidates who opted for this less than honest route.
Recruiting is hard. It takes a lot of time and energy; rational decisions are challenging to make because in most cases you really are comparing apple to oranges.
What made a resume stick out to me
Open Source contributions (a GitHub link would immediately arouse my interest in that candidate).
A concise but detailed description of practical projects that had been implemented by the student for companies outside of their coursework (whether on the side or through internships).
Social media involvement in the programming community. Did they have a StackOverflow profile? A Twitter account related to programming? Perhaps a a blog dedicated to the subject? While these points alone certainly don’t mean someone is a good programmer, they are a decent indicator that a person is at least passionate about the subject. Attendance of industry conferences (which some had) was also a strong indicator of interest in the field.
Knowledge of unusual programming languages. Virtually everyone had Java on their resume, however that alone wasn’t good enough to catch my eye as an interviewer. (Heck, even Python is starting to be pretty common.) When candidates claimed knowledge of Haskell, Scala, Clojure, OCaml, Scheme, Factor, Io, J, etc… that definitely grabbed my attention. Again, this is no guarantee that someone is a good programmer, but chances are that they have an above average interest in our profession or have attended a university where these languages were taught (both positive signs).
While I’m not sure what you’ll get out of this article, I thought it was worth sharing as I found the whole process described above to be a fascinating one. Perhaps if you’re a student in a similar position you’ll find tips on what to do when applying for an internship with a company such as IBM. If you’ve ever found yourself in a similar interviewer’s position, you’ll likely find numerous relatable points in this post.
中文版本参见：http://www.aqee.net/2010/10/12/things-i%E2%80%99ve-learned-from-hiring-interns-for-ibm/
排序 内容
Jobs Digg 是一个实验性的招聘求职互助协作平台. 覆盖工作相关信息: 招聘、求职、就业、面试、裁员、感悟......
Tips: 发布信息请点击上面的提交内容.
Tips: 发布信息请点击上面的提交内容.