注册一亩三分地论坛,查看更多干货!
您需要 登录 才可以下载或查看附件。没有帐号?注册账号 
x
今天刚面完VO 分享一下面经 希望自己能有好运!我尽量写的详细 Google是我的dream company 也希望其他的朋友看到能有所帮助
Timeline
05/14 收到recruiter的邮件 问我有没有兴趣 我说有 正好在找工作 聊了一下预约了电面。(中间因为时差和工作开会 recruiter vacation等原因 直接导致两周没有聊上 导致后面也有点慢了)
06/08 电面
06/10 收到电话电面过了
06/14 转到了下一个recruiter 约了VO 和一个组的Manager(好像是)聊了一下
06/21 两轮VO
06/22 三轮VO
这里提一下因为我有pending offer所以recruiter给我加急约了面试 同时开始team match 因为lz在Boston所以直接和Boston的Fitbit组聊来着 对方对我挺满意
电面
面试官是美国大叔 全程积极互动给提示 各种讨论
要不说Google面的非常灵活 上来就是一道根本没见过的题
给了我一个概念叫做 Lychrel number 描述了一下他的性质 让我写一个方法判断一个睡姿是否是Lychrel number
我从来没有听过这个概念 然后他和我说这是一个数学上的概念 没有数学的证明(?)我听到这里其实没反应过来,没有证明我咋能写出代码???
然后我就说我想举例子 试了一下发现没啥思路 他说你换个思路 你可以先写个方法判断一个数是non Lychrel number
我想这不是一样的吗....但是还是follow hint写出来了 然后我说我无法判断它是一个Lychrel number 我可以加一个k作为迭代次数的limit 达到k次迭代还没有结果就return false
他说可以 我写完了
他说k如果是十亿级别怎么办?我说那其实和没给k一样 大概率stack overflow
然后有趣的来了 我们开始讨论在recursion里面哪里可能会stack overflow,然后没完,他问怎么handle exception?我举了几个方法,他说随便选一个写出来。
然后我都写完了 他说looks good 然后就问问题 虽然超时了 但是我觉得既然大概率挂了 那我就什么好奇问什么吧 结果愣是问了15分钟 非常感谢大叔 非常nice
我当时感觉绝对挂了 后来一搜Lychrel number:
这还真的是无法证明 我有感觉可能我有机会???
anyway过了 而且feedback很好??
我写了这么多就是想分享一下这种从来没见过的题 可能是lz孤陋寡闻了 第一次写这种可能无法给出结果的程序....而且面试问题也比较出乎预料。lesson learnt如果面试官给了奇怪的问题 然后给了奇怪的提示 一定要按照hint往下走 因为正常来说是不会误导candidates的
VO
R1: BQ. 原来以为BQ是最后一轮根本没看,结果是第一轮??幸亏3天以前面了亚麻 那些例子烂熟于心.
- 面试官中国小姐姐 现在是team lead 在health什么组
- Tell me about a big challenge when you led a project
- Tell me a time you found a missing part in after you have made a decision
- Have you worked with ppl with different working style?
- Have you changed priiority in the middle?
- How to keep connected with ppl?
- 因为我没有看Google的BQ要求所以不清楚对应的是什么LP 不过小姐姐非常nice 全程互动 我说完了例子她要回应一下说很好 在Google这种事情很常见之类的 让我感到亲切
R2: coding
- 面试官美国大姐姐 在youtube做search
- 题目:word extension
Given a word "heeellooo", return a list of ranges where the letters can be compressed. The letters can be cms => succeed
request at 501ms => failed
FU1:
what if we change it to
class RateLimiter {
int maxRequests;
Function f;
void run() {
// implement here
f.apply();
}
}
this time we fiix the interval to be 1 second, but we allow maxRequest number of requests succeed in the iinterval?
比如maxRequests = 2 then
request at 0ms => succeed
request at 250ms => succeed
request at 500ms => fail
request at 1000ms => succeed
FU2:
How to handle retry?
这里没太明白一开始 后来各种讨论 才明白它是说如果retry也算到rate里面 怎么办?我回答用exponential retry减少hit并且总能达到一个retry interval使得request一定succeed from rate limiter
这里有很多可以讨论感觉
FU3:
say the RateLimiter can handle average TPS but we have peaks that it can not handle. How to optimize? 大叔直接说这是一个他们真正有的问题哈哈哈
我不会其实。。。就随便想了个分级RateLimiter 不知道大叔明没明白what I was talking about.....
有大神们给点建议吗?
总体感觉很好 一开始lz理解的不太对以为要区分request 通过id,然后写完了,大叔说他明白但是不是他要的,他怕FU会变复杂,我赶紧说那我改。。。这里确实没办法了 我以为我理解的是对的,结果并不是。。。大家还是要注意沟通啊!幸好这个补救成本很小一下子就改好了
总体就是这样 和地里的其他人比起来面的真是非常简单了!!而且面试官人也很nice!!!非常幸运!!
写的尽量详细 希望有帮助 不设置权限了 lz的大米也不多 希望大家加个米呀!
另外过两天把Amazon的VO也写上,大家可以看看
希望攒攒人品!
|