Monday, November 30, 2015

How to Prepare Interview - mitbbs



https://www.themuse.com/advice/your-5minute-guide-to-writing-an-amazing-linkedin-recommendation

http://jobsearch.about.com/od/linkedin/a/linkedin-recommendations.htm

How to Request a Recommendation

  • Click on:
  • Profile
  • Recommendations
  • Request Recommendations
If someone has already written a recommendation for you outside of LinkedIn, you can forward a copy of their document and ask if they might be kind enough to upload one online as part of LinkedIn.
https://blog.linkedin.com/2014/09/12/why-linkedin-recommendations-and-endorsements-should-matter-to-you
The answer is, both. LinkedIn is more than just a place where you find opportunities; it’s a place where opportunities find you. For that to happen you have to put yourself out there (completing your LinkedIn Profile, sharing content, engaging with your network, etc.), and make sure you’re putting your best foot forward. Including endorsements and recommendations in your Profile is a great way to complement and confirm the skills and experiences you’ve listed while also catching the eye of potentially interested professional parties.
http://www.mitbbs.com/article_t/JobHunting/32477683.html
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
这次我面试一个公司,一个面试官问一个设计的问题“如果我们有一个MySql cluster,
一个master node和两个slave nodes,你怎么决定谁做master和处理node failure.”
我直接说,我们是用Zookeeper来解决leader election的和failover的问题。他就说
,good,我们也是用Zookeeper,然后这个问题就结束了,他也很满意。
2)如果能成为一些开源系统的贡献者,会让对方有更直接的方式见识你的工作能力。
现在成为开源贡献者的门槛很低。如果你能加入一个开源系统,提交pull requests,
这些都可以写在简历上也很容易被对方检视和接受。如果你的开源工作比较high 
quality和impressive,这会成为巨大的plus。
3)对于有经验的同学,能否在开源系统中选择自己需要的工具是几乎不可缺少的能力。
你需要做tradeoff或者customization来解决自
己的问题。这样的customization/improvement也可能作为contribution回馈到开源系
统中。能了解自己需要做的tradeoff,找到需要提高的地方,再把解决方案回馈开源社
区对自己的能力,甚至career上的reputation都可能会有不小的帮助。
面试的技术能力主要包括三个方面,coding,算法
,系统设计。不太主要的还有知识性的问题,OO设计,和与具体职位相关的经验部分。

1)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,至少可以知道一些信息。在网站上自己投简历最不理想的情况就
是石沉大海,完全不知进展。

https://www.duanzhihu.com/answer/8803645
先说个结论:算法是其次,主要是写码能力与熟练度


Airbnb一般的coding面试的流程是45分钟,10~15分钟白板分析下问题,25~30分钟上机实现算法,5分钟留给面试者问问题

时间的限制决定了题不可能太难,基本不会超过leetcode难度。而且Airbnb作为还算是创业公司,更看重的是快速落实一个想法的能力。 一些常用的算法(什么拓扑排序啊,回溯,最小生成树这些,都是很基本的)你忘了也没关系,我们可以一起在白板上推。稍微有点实力的面试者白板出一个solution是没有问题的,所以这个时候就主要看写码能力与熟练度了。

上机写码考察的方面很多,比如面试者
  • 语言的熟练程度 语言不重要,但你总得对你拿来面试的语言很熟吧。我们会先问你prefer什么语言,然后选这个语言熟的面试官来。
  • 落实设计的能力 最怕吹半天,写一行代码都困难的那种人。
  • 对电脑的熟悉程度 这个不是必须,但熟练使用快捷键、shell之类的总是加分项
湾区据我所知有越来越多的公司是采用上机写码或者pair programming的这种形式。(Square是纯pair programming。Uber是只白板,所以uber印度人多)


Labels

Review (572) System Design (334) System Design - Review (198) Java (189) Coding (75) Interview-System Design (65) Interview (63) Book Notes (59) Coding - Review (59) to-do (45) Linux (43) Knowledge (39) Interview-Java (35) Knowledge - Review (32) Database (31) Design Patterns (31) Big Data (29) Product Architecture (28) MultiThread (27) Soft Skills (27) Concurrency (26) Cracking Code Interview (26) Miscs (25) Distributed (24) OOD Design (24) Google (23) Career (22) Interview - Review (21) Java - Code (21) Operating System (21) Interview Q&A (20) System Design - Practice (20) Tips (19) Algorithm (17) Company - Facebook (17) Security (17) How to Ace Interview (16) Brain Teaser (14) Linux - Shell (14) Redis (14) Testing (14) Tools (14) Code Quality (13) Search (13) Spark (13) Spring (13) Company - LinkedIn (12) How to (12) Interview-Database (12) Interview-Operating System (12) Solr (12) Architecture Principles (11) Resource (10) Amazon (9) Cache (9) Git (9) Interview - MultiThread (9) Scalability (9) Trouble Shooting (9) Web Dev (9) Architecture Model (8) Better Programmer (8) Cassandra (8) Company - Uber (8) Java67 (8) Math (8) OO Design principles (8) SOLID (8) Design (7) Interview Corner (7) JVM (7) Java Basics (7) Kafka (7) Mac (7) Machine Learning (7) NoSQL (7) C++ (6) Chrome (6) File System (6) Highscalability (6) How to Better (6) Network (6) Restful (6) CareerCup (5) Code Review (5) Hash (5) How to Interview (5) JDK Source Code (5) JavaScript (5) Leetcode (5) Must Known (5) Python (5)

Popular Posts