|
|---|
|
|
|
|
|
|
o**********e
发帖数: 18403 | 1 【 以下文字转载自 ITRelief 俱乐部 】
发信人: onetiemyshoe (onetiemyshoe), 信区: ITRelief
标 题: Re: 分享一些经验及心得 (转载)
发信站: BBS 未名空间站 (Sun May 11 10:23:46 2014, 美东)
【 以下文字转载自 JobHunting 讨论区 】
发信人: halfsea (LTSPGFB), 信区: JobHunting
标 题: Re: 分享一些经验及心得
发信站: BBS 未名空间站 (Tue Jul 9 22:15:26 2013, 美东)
Sorry for the delay。本来想系统的写点东西，但动笔之后发现自己的水平还是差得
太远，没法handle，时间精力目前也不允许。所以估计就只能零零散散的写点感受了。
大家随便看看就好，不要期望过高，道歉先。这个板上牛人很多，真正的大牛可能根本
没时间来发帖子，我也就抱着回报社会的心态班门弄斧好了。
这几年几次换工作，job版上的信息都对我起到了很大的帮助。所以希望能把我的一点
心得回报这里。以下都是我个人的一点浅见，完全可能不正确或者不符合别人的实际情
况。仅供大家参考。
还是结合自己这次的经历来说吧。这次连续面试了7个公司，前四个都成功了，后三个
都失败了。G和F在另外的帖子说过。最后一个箱子公司其实面的还不错，不过team和我
的经验确实不卖吃，而且对方事先知道了我其它的奥佛，可能估计我会拿他们垫背，所
以第二天就很爽快的把我锯掉了。
前面4个成功的就是LT＋方块公司和别针公司。两个startup的奥佛我就不说了，因为面
的人比较少，不象LT那么有参考价值。
这次经历感觉最深刻的有以下几点可以作为经验向大家推荐。
1. 经验和技能卖吃会有事半功倍的效果。
这次我的4个奥佛，3个都可以说是非常卖吃，所以对方一直很有诚意的去bid，这事实
上造成我最后收到的奥佛都远远高于了他们第一次给我的奥佛。
现在CS的市场确实很火热，但正如前段时间也讨论过的，主要高薪工作集中在互联网相
关的领域，更细的说我感觉是和云相关的工作。现在几个主要的互联网巨头都进入了拼
规模的阶段，这对平台的要求是非常高的。有经验的同学可能都知道，设计一个能支持
1千万用户、5千万用户、或者3亿用户的平台的难度是完全不同，可能背后用到的tech
stack也会有很大的差别。现在分布式、云、NoSql、Hadoop这些比较比较流行的关键字
都是为了解决large scale的问题。这不但是一个还很open不断发展的领域，更是几乎
所有互联网巨头面对的难题。所以在这个领域里的经验和技术在目前就是比较“有效”
的，也能对找到不错的工作给予很大帮助的。
最近一段时间大家比较热衷于讨论A公司，我觉得A虽然对SDE不见得是最友好的公司，
但A的门槛相对较低，比较适合Fresh开始自己的career。A最有价值的地方我觉得就是
AWS，而且不仅仅是只有在AWS工作才有这样的好处，作为A的其它部门，你很可能会成
为一个AWS的用户，这样的经验也会是很有价值的。现在很多中小公司都在把服务向AWS
转移，连网飞公司和别针公司这样的小巨头都在这样做，可以想见熟悉AWS的平台在找
工作的时候很可能能带来很多优势。
至于怎么能做到有效的积累有价值的经验呢？底下是我以前的一个回帖写过的，偷懒，
就直接贴在下面了。
CS或者IT行业的一个特点就是技术更新快，热点转移快。虽然基本的算法、coding的东
西变化不大，但程序语言，体系结构，操作系统、工具常常是几年甚至几个月就有巨大
的变化。想靠一招吃一辈子基本上是做不到的，这对转行的还是科班的都一样。
前几天还有传统软件公司行业的网友抱怨现在工作形势不好，其实就是因为热点已经转
移到Web相关的领域了。有人在Web/Mobile/Cloud/BigData/里面吃香喝辣拿高收入，很
多传统软件方向里的人可能不但工作机会少，还面临裁员和收入下降。
但，我从不认为CS是吃青春饭，从不认为40岁以后事业就面临危机。相反，CS的经验积
累是极为重要的。举例来说，当你看到你的service的latency变高，或者website的反
应变慢，你的反应是什么？当你design a new service from scratch, with the
target being to handle thousands of requests per second，你觉得自己应该选择
什么framework, 什么storage，什么open source 的工具？解决这些问题都是要依靠经
验，而这种经验是最重要的。一个新手埋头努力搞出的东西最后完全可能南辕北辙，远
远meet不了expectation。有一个正确的实现方案的重要程度可能>50%，剩下的
implementation完全可以由新手来做，但价值已经下降很多。
所以，积累“有价值的经验”在你CS的career中是我认为最重要的。大家要关注行业的
热点，在热点转换的时期及时作出改变，尽量不要stuck在过时的技术和领域中。这才
是提升自己事业和收入的有效手段。
2. 集团作战，最好有多个竞争奥佛
面试一家公司，准备得再好，也完全可能失败。而且准备10个公司花费的时间精力和准
备1个公司的面试相比，花费的时间精力可能相差并不太多。所以同时面试多家公司，
可以大大的提高效率和成功率，还可以在最后和公司negotiate的时候拥有巨大的主动
权。
3. 认真包装自己过去的工作，不要流于表面。
在面试中一定要尽可能让对方对于过去的经验觉得impressive，这样即使不是很卖吃，
对方也会觉得你的经验valuable而对你另眼相看。反之，即使你的公司看着不错，或者
工作时间比较长，也未必会有什么加分的效果。
（下面大部分还是以前回帖中的内容，但确实是我真实的感受）
怎样能更好的包装自己的工作呢？首先要对行业和技术有足够的了解。只靠工作中积累
经验，常常是不够的。平时多充电，多去了解新鲜事物和新技术是必修课。当然，都是
说起来容易，呵呵。除了多关注大牛和各公司的技术blog/mit和其它一些网站的技术版
面之外，各个大公司一般都对现有系统有不错的documentation，多看看也会有帮助。
如果没有足够的doc那就只能靠自己努力读repo里面的code了。我也不是什么大牛，很
多东西也不知道，需要用什么新东西的时候常常也都是要临时抱佛脚靠wiki或者google。
面试中如何介绍自己的工作也需要认真准备。比如你在A公司做B系统的C子系统，你平
时的主要工作就是改点小bug，加点business logic。如果面试的时候这样平铺直叙的
描述你的工作，十有八九会被人认为你做的工作不够impressive。要学会包装自己的工
作。比如B系统很有名，但你加入的时候他已经release了，对方也知道。但你加入后出
了一个非常不错的feature，你可以说自己在里面做出了很大的贡献，尤其在design上
面。
当然，完全胡吹是不行的，你要做足功课，能描述设计和实现的具体细节，能说清中间
做过哪些tradeoff和原因，比如为什么最后选择了framework X而不是Y，为什么用了
Dynamo而不是MySql，过程中你们发现memcached有哪些不足，等等这样的问题。如果你
能说的清楚，对方没有能力也没有理由去调查你到底是不是做了你说的这些工作。而且
，你这样准备的过程其实对自己也是一个提高。就算最后不换工作，要在大公司长期发
展也是对各个系统了解的越深入越好。
做到以上几点的另一个附带好处就是能提高系统设计方面的能力。和提高算法和coding
相比，提高内功（系统和经验），很不容易，是长期工作。尤其是我们普通码工终究要
向高级码工和architect努力，内功高强是必不可少的。呵呵。
4. Open Source
过去的一年中，我的工作涉及到了很多开源的项目。不仅是需要使用开源的系统和工具
，我也成为了一些开源系统的贡献者。这次找工作的过程中，我深深体会到了这段的经
历给我带来了不少优势。我面试成功的几个公司，无一例外都是很多开源工具的使用者
和贡献者。在面试的过程中，这些开源的工作经历很容易让我和面试官们找到共同语言
。而且我做的开源系统还算小小有点名气，有很多次面试官都会主动说他知道我们这个
系统，我相信这也会对面试的结果产生了正面的作用。甚至有一个奥佛就是因为对方希
望我把这个同样的开源系统移植到他们公司的平台上，所以一直强烈的试图说服我加入
。我觉得自己在这一点上很幸运。
对于很多找工作的同学，可能你没有像我这样的机会在工作中接触开源的系统或者成为
贡献者。如何能象我一样从开源受益呢？我有以下几个建议
1）开源系统都是完全公开的，只要你有兴趣，那里没有秘密。如果时间允许，我觉得
如果你能去了解一下流行的开源系统，甚至下载下来玩一玩，都可能是对自己在技术上
有帮助的。
这次我面试一个公司，一个面试官问一个设计的问题“如果我们有一个MySql cluster,
一个master node和两个slave nodes，你怎么决定谁做master和处理node failure.”
我直接说，我们是用Zookeeper来解决leader election的和failover的问题。他就说
，good，我们也是用Zookeeper，然后这个问题就结束了，他也很满意。
我觉得这里很重要的一点是我们找到了“共同语言”，很多东西不需要解释就互相明白
。这在选择未来同事的时候一定是一个plus。第二，如果他继续问下去，我也有信心对
Zookeeper的工作机理给出一定的解释。其实Zookeeper的机制并不复杂，wiki上面都有
很详细的资料。但他没有问，因为对我和他这样大部分使用者来说，这些细节并不是最
重要的地方。
可以想像，如果我的回答中没有提到“Zookeeper”或者其它现成的开源色鹿身的关键
词，就算是我能现场设计出一个和Zookeeper一样的解决方案，我们之间的交流也很可
能不是这样顺畅的。
2）如果能成为一些开源系统的贡献者，会让对方有更直接的方式见识你的工作能力。
现在成为开源贡献者的门槛很低。如果你能加入一个开源系统，提交pull requests，
这些都可以写在简历上也很容易被对方检视和接受。如果你的开源工作比较high
quality和impressive，这会成为巨大的plus。
3）对于有经验的同学，能否在开源系统中选择自己需要的工具是几乎不可缺少的能力。
这是我认为从developer升级成为architect所需要的一个重要素质。开源社区现在几乎
可以说是无所不有，所有的需要都可以在开源系统中找到一个色鹿身。但这里有两个问
题，一是色鹿身几乎一定不是唯一，而且很多时候选择会比较多。有经验的dev/
architect能在众多的选择中找到比较好或者最好的，这是非常重要的能力。二是可能
所有的色鹿身都有自己不完美的地方，你需要做tradeoff或者customization来解决自
己的问题。这样的customization/improvement也可能作为contribution回馈到开源系
统中。能了解自己需要做的tradeoff，找到需要提高的地方，再把解决方案回馈开源社
区对自己的能力，甚至career上的reputation都可能会有不小的帮助。
5. 做题
终于讲到做题了，呵呵。在我看来，面试的技术能力主要包括三个方面，coding，算法
，系统设计。不太主要的还有知识性的问题，OO设计，和与具体职位相关的经验部分。
后三个部分在我自己的经验中遇到的不多，或者是范围太广没法cover，就不提了。主
要想说一下前面三个部分我准备的经验。
1）Coding
Coding在我的面试的经验中绝对是最需要准备的，当之无愧第一重要。所有公司在招一
个SDE的时候，都是需要他／她能真正的hands on，能deliver。大部分有经验的同学可
能都有类似感觉，真正的算法问题在实际工作中是不常见的。但给定一个业务逻辑，如
何把它简洁高效的用最易懂，最好维护的方式写成一段没有bug的程序，是几乎每一份
工作都要求的。简洁、易维护、无bug，这就是coding的能力。
结合我自己的经验，leetcode的online judge是最有效的训练方式（感谢1337大牛）。
132道题中，至少有80-100道题是具有很高的代表性的，我觉得这些基本的问题一定要
能非常熟练的掌握。我其实这次只把leetcode做了一遍，少数问题我写的不太好的后来
写了第二遍。但我觉得这些coding问题还是尽可能做到熟练为好，要“熟极而流”，做
到面试中如果被问到同一道题能做到在白板上立刻开始连说带写流畅完成无bug的程度。
举一个我自己的例子，在一个公司，我在不到1个小时的面试中被问到了三道不算简单
的coding题，这里有两道leetcode的原题，我觉得因为自己把leetcode做的比较熟，才
能在不到一个小时完成全部coding、语言交流和test cases。对方感觉上很impressed
。以我自己作为一个面试官的经验，能完成两道题的人已经不是很多了，多做一道题一
般来说是很大的加分.
2) 算法
这也是我自己的弱项。这次G和F都是折在了这个部分。我想基本上，我们见过的算法问
题一定要尽可能理解清楚，这样在面试中碰到没见过的问题才有可能做到触类旁通。是
不是要把经典算法书过一遍呢？反正我没能做到。TAOCP和CLRS在我书架上放了很久都
没有看过，呵呵。
其实我觉得算法和coding的界线并不十分明显。象leetcode上的最大palindrome子字符
串，jump game II，scramble string这样的问题虽然算法并不容易想，但在我看来还是
属于coding的问题。也许对我来说区分算法和coding问题的一个标准就是能不能在30-
40分钟内完成coding。
我这里想说的主要是那种不是很容易解决的纯算法问题，比如有个朋友被问到过的平面
N个点找最大两点距离的。这种问题知道的很容易，不知道的可能很难在几十分钟内解
决，从测试被面试者的角度来说，并不是非常适合做面试题的。
其实我感觉除了G和F，大部分公司对于这种纯算法的问题并不是过于强调，而是更强调
coding。如我前面所说，真正工作中复杂的算法是很少用到的。不过，在我过去几次面
试G的经历中，感觉这种比较纯粹的高级算法问题也是越来越少了。
3）系统设计
感觉上对大多数刚毕业的同学来说，这是一个瓶颈。确实，如果没有一定的相关的工作
经验，确实很难做到很好的系统设计。但除了我在前面曾经提到的通过关注业界动态和
开源系统来提高自己的内功之外，因为现在大部分的系统设计问题集中在distributed
system和large scale上面，也不是没有迅速提高的捷径。
比如下面两篇经典的paper, Dynamo和memcached at Facebook，就可以用来了解设计一
个大的系统的时候究竟有哪些的考虑，要做什么样的tradeoff。作为入门可以提供很多
的线索，剩下来就是靠自己通过Google和Wiki来做功课了。
http://www.read.seas.harvard.edu/~kohler/class/cs239-w08/decand
https://www.usenix.org/system/files/conference/nsdi13/nsdi13-final170_update
.pdf
其它就是在infoq上有一些presentation可以帮助了解一下各个公司的tech stack，有
些可能比较老。一般我临去面试之前突击一下，至少熟悉一下对方的系统。比如http://www.infoq.com/presentations/Real-Time-Delivery-Twitter
还有就是FLGT都有自己的engineering blogs, 去浏览一下可以熟悉一下他们最近在做
什么。现在很多他们的项目都open source了，如果有时间，可以去简单浏览浏览
github的wiki和code，尤其是和你要面试的组有关的，如果能提前做点准备，面试的时
候偶尔抛出来有的时候会有不错的效果。
4）真题
如果说还有什么对准备面试比leetcode更重要，那我要说，是真题。这里的大部分同学
我想都经历过高考或者GRE，那大家一定知道真题训练在这样的考试准备过程中有多么
的重要。尤其是有些公司同样的面试问题会不断重复出现，就更增加了真题的价值。这
两年的时间我养成了一个比较好的习惯，就是在BBS上看到什么有价值的帖子，就会随
手forward到自己的邮箱，所以在后来准备的过程中，就有很多以前别人分享的真题用
作练习。而事实证明，这些真题的效果是很明显的，我面试中碰到的全部问题，大概80
％－90％是leetcode和这些真题cover的。这也是让我对这个版面存有回报之心的一个
重要原因，呵呵。
除了BBS，收集真题还有的source就是careercup和glassdoor。这两者其实我看的并不
多。但有些小公司，在BBS上没太多人share过，在这两个网站上面会有更多的线索。
6. Behavioral Question
你对Behavioral Question的答案一般来说不会成为对方雇用你的原因，但却很有可能
称为对方拒绝你的原因。我有一个技术很牛的朋友，找工作的时候换工作有点频繁，大
概前面每个公司都只待了一年。结果对方在问他为什么这次又是要在一年之后换工作的
时候，他很实在的说了一些对现在工作不满意的地方，结果导致了悲剧。其实只要稍微
在给出答案的时候注意一点点，就完全可能拿到offer。
一般来说，我觉得在Behavioral Question方面主要应该注意以下几点：
1）不要说negative的comment，特别是对自己以前的工作
比如，几乎每一个公司的面试都会有人问“Why do you want to leave your current
company?” 这是一个很open的问题，绝对没什么标准答案。但我觉得，无论你离开的
原因是什么，无论你对你前一份工作是爱是恨，都不要make negative的comments. 比
较理想的是无论什么时候，当被问到你以前的某个工作，某个项目，你都能热情洋溢的
说出很多positive的东西。“热爱自己的工作”，这是很多公司非常在意的基本素质。
2）show出对对方的热情
当对方问你“why do you want to join us?”的时候，不要吝惜你的甜言蜜语。Love,
Passionate, Thrilled…这些词汇应该脱口而出。:-)
除了说一些好听的话之外，最好能在面试之前对公司和面试的team多做一些功课，了解
一下对方的产品、目前主要的发展战略、应用的技术和语言，等等，所有对方现有的都
应该是你热爱的。就像追女朋友，她长成什么样，你心目中的女神就是什么样，呵呵。
当然，对方不会仅仅因为你的passion而给你offer，但这会是一个巨大的plus。而lack
of passion常常成为技术不错的candidate最后fail的一个原因。
3）show flexibility
工作中可能会遇到很多不可预测的情况，一个好的员工应该能做到随机应变，而不是永
远一成不变的僵化对待每一种情况。所以，拥有flexibility是一个优点。
比如你知道对方的项目包括oncall的部分，可能经理会问“how do you feel about
doing some on call duty?” 这种情况下，如果你的回答会让对方觉得你非常不愿意
take oncall的话，很可能会成为一个负面的因素。所以我觉得比较正常的答案应该是
“I am very flexible to do operational work, even during off hours”，甚至更
肉麻一些可以说“Actually, I really love to do operational work. It can make
me very proud sometimes because I feel myself like a soldier fighting a war
”，哈哈。Believe me, I must have said something like that.
4) Behave with common sense
其实简单说，就是尽量象一个有正常情商的人。几乎所有的面试官都不是一定要找一个
最聪明的人，而是要为自己找一个能一起工作的同事。没有人会愿意和一个不合群，甚
至是jerk的人一起工作的。
比如，最好不要经常打断面试官的讲话。当对方对某样工具或程序语言有很强的
opinion的时候，即使你不同意，也没必要和他argue，一定程度的附和效果会好一些。
5）总结
说了这么多，可能有人会很不以为然，觉得这样做没有尊严，缺乏backbone。同学，我
们是在面试，我们是希望得到一个offer。你完全可以拒绝一家公司的offer，但它很可
能能让你最后在dream company那里拿到更好的package.
7. Networking
Last but not least, 是Networking. 找工作的时候，要尽量利用自己现有的
Networking。同学，朋友，网友，朋友的朋友，都是可以利用的资源。内部推荐在大部
分公司可以保证电话面试，而且更重要的是，如果一段时间没人联系，可以让推荐人
ping一下recruiter，至少可以知道一些信息。在网站上自己投简历最不理想的情况就
是石沉大海，完全不知进展。 | l*****t
发帖数: 2019 | 2 用一句MITBBSn年前的惯用语
peng!
【在 o**********e 的大作中提到】
: 【 以下文字转载自 ITRelief 俱乐部 】
: 发信人: onetiemyshoe (onetiemyshoe), 信区: ITRelief
: 标 题: Re: 分享一些经验及心得 (转载)
: 发信站: BBS 未名空间站 (Sun May 11 10:23:46 2014, 美东)
: 【 以下文字转载自 JobHunting 讨论区 】
: 发信人: halfsea (LTSPGFB), 信区: JobHunting
: 标 题: Re: 分享一些经验及心得
: 发信站: BBS 未名空间站 (Tue Jul 9 22:15:26 2013, 美东)
: Sorry for the delay。本来想系统的写点东西，但动笔之后发现自己的水平还是差得
: 太远，没法handle，时间精力目前也不允许。所以估计就只能零零散散的写点感受了。
| c********r
发帖数: 107 | | i********e
发帖数: 5996 | | g******g
发帖数: 52 | | c********r
发帖数: 107 | | g******g
发帖数: 52 | | s*****3
发帖数: 1673 | | T*******e
发帖数: 46 | | F********d
发帖数: 71 | 10 mark 牛人
【在 o**********e 的大作中提到】
: 【 以下文字转载自 ITRelief 俱乐部 】
: 发信人: onetiemyshoe (onetiemyshoe), 信区: ITRelief
: 标 题: Re: 分享一些经验及心得 (转载)
: 发信站: BBS 未名空间站 (Sun May 11 10:23:46 2014, 美东)
: 【 以下文字转载自 JobHunting 讨论区 】
: 发信人: halfsea (LTSPGFB), 信区: JobHunting
: 标 题: Re: 分享一些经验及心得
: 发信站: BBS 未名空间站 (Tue Jul 9 22:15:26 2013, 美东)
: Sorry for the delay。本来想系统的写点东西，但动笔之后发现自己的水平还是差得
: 太远，没法handle，时间精力目前也不允许。所以估计就只能零零散散的写点感受了。
| a***m
发帖数: 666 | | p**r
发帖数: 5853 | 12 认真拜读了全文，
个人感觉如何这些全做到，
完全可以去自己弄个公司玩了，
一年1m应该算小意思的。 | c***z
发帖数: 6348 | 13 个人的一点小经验，关于
“当然，完全胡吹是不行的，你要做足功课，能描述设计和实现的具体细节，能说清中间
做过哪些tradeoff和原因，比如为什么最后选择了framework X而不是Y，为什么用了
Dynamo而不是MySql，过程中你们发现memcached有哪些不足，等等这样的问题。”
那就是说项目的时候还是得注意点，不能说得太细，不能涉及公司的机密，或者是看起
来像是机密的东西。
对有的人来说这是常识，但是我还是吃了点亏才意识到这点。 |
|
|
|
|
|
|
|
