c*********i
发帖数: 46 | 1 上周FB onsite, 但是悲剧了，下面是HR的回复：
overall there were some very strong points throughout your interview day and
the engineers really enjoyed the conversations. Unfortunately, it was
primarily the architecture and design that did not go as well as we would
hope。
我全天就一个烙印，就是这个system design 这轮，题目是POI 5miles. 我用geohash
做的， 最后scale的时候，首先想到根据地域，然后他说有问题。自己struggle了一下
，然后提到另外一种方案，达到了他想要的scale的方法，他最后也表示满意，也算了
需要的memory， 和机器数，他也表示满意。我不敢说我答的很好，最起码也不是太差
吧。
但是还是被拒了因为这轮，而且是唯一的烙印，这些巧合不得不让我有些联想。HR 后
来又让我去面另外一个组，也算给了另一条路！ |
k****i
发帖数: 128 | |
c*********i
发帖数: 46 | 3 没给加面的机会。
【在 k****i 的大作中提到】
: 这是加面吧，加面design据说很难过
|
a****r
发帖数: 87 | |
k****i
发帖数: 128 | 5 不知道你这个面另外一个组什么意思。另外这东西要具体说说你怎么scale的，面试官
经常是表面点头同意实际上心里不同意的，但是没工夫和你争论。尤其F家没什么闲人
【在 c*********i 的大作中提到】
: 没给加面的机会。
|
c*********i
发帖数: 46 | 6 同病相连呀！
【在 a****r 的大作中提到】
: 我也挂在fb烙印设计题这一轮。。
|
c*********i
发帖数: 46 | 7 就是HR给我推荐了另外一个做系统performance的组，重新面试！
关于scale: 刚开始提出把地域相近的data shard 在一起，这样，因为是求5miles的
POI，相近的点可以group在一个DB里，不用跨DB。但是他提出这样设计有个问题，我想
了一会说，是的，这样可能有的db数据多，有的少，不balance.他问怎么解决，我想了
一会说(这个中间是有点不是很smooth我承认)，说可以hash之前生成的geohash值，映
射到不同的DB，这样，load 就balance了，但是要从不同的DB里取数据。还说这样也有
弊端，提了一下consistent hashing. 他说可以。 然后就问问题了。
大体上就是这了，我知道自己系统设计不是很强，但是也觉得答的没有那么差呀！
【在 k****i 的大作中提到】
: 不知道你这个面另外一个组什么意思。另外这东西要具体说说你怎么scale的，面试官
: 经常是表面点头同意实际上心里不同意的，但是没工夫和你争论。尤其F家没什么闲人
|
y*****e
发帖数: 712 | |
k****i
发帖数: 128 | 9 我以为F家是general hire，不分组的
对于rehash了，geohash本来的意义就没了，直接存成经纬度不就行了。另外rehash后
你怎么index到临近点呢？
这题我觉得应该按grid分片，一个grid里的POI存在一起，临近grid分散到不同机器上
。 |
n******n
发帖数: 12088 | 10 point of interest
【在 y*****e 的大作中提到】
: design小白问问，啥是POI?
|
|
|
n******n
发帖数: 12088 | 11 题目到底问的是什么？
and
geohash
【在 c*********i 的大作中提到】
: 上周FB onsite, 但是悲剧了，下面是HR的回复：
: overall there were some very strong points throughout your interview day and
: the engineers really enjoyed the conversations. Unfortunately, it was
: primarily the architecture and design that did not go as well as we would
: hope。
: 我全天就一个烙印，就是这个system design 这轮，题目是POI 5miles. 我用geohash
: 做的， 最后scale的时候，首先想到根据地域，然后他说有问题。自己struggle了一下
: ，然后提到另外一种方案，达到了他想要的scale的方法，他最后也表示满意，也算了
: 需要的memory， 和机器数，他也表示满意。我不敢说我答的很好，最起码也不是太差
: 吧。
|
c*********i
发帖数: 46 | 12 我给出的算法，在这里。本质就是按grid分片。
http://blog.csdn.net/v_july_v/article/details/11288807
【在 k****i 的大作中提到】
: 我以为F家是general hire，不分组的
: 对于rehash了，geohash本来的意义就没了，直接存成经纬度不就行了。另外rehash后
: 你怎么index到临近点呢？
: 这题我觉得应该按grid分片，一个grid里的POI存在一起，临近grid分散到不同机器上
: 。
|
k****i
发帖数: 128 | 13 另外我觉得是你load balance理解有问题。不是db数据量是否balance or not的问题，
是request load, 如果request集中到一个db上，比如ny市中心的几个gird，那db就是
bottleneck了。所以上面把grid分到不同机器上。 |
y*****e
发帖数: 712 | 14 这个链接很好耶。。lz能说说还有哪些章节应该看看吗？
不过我觉得不管是不是被黑了，心理还是应该及早move on,毕竟还有一个机会，要好好
把握，迅速进入面试状态。
【在 c*********i 的大作中提到】
: 我给出的算法，在这里。本质就是按grid分片。
: http://blog.csdn.net/v_july_v/article/details/11288807
|
k****i
发帖数: 128 | 15 你给的链接只谈了如何index，没有谈如何scale
【在 c*********i 的大作中提到】
: 我给出的算法，在这里。本质就是按grid分片。
: http://blog.csdn.net/v_july_v/article/details/11288807
|
c*********i
发帖数: 46 | 16 嗯，你说的对，是要重新整理，继续面试。我就是在july的主页上看到感兴趣的就看看
，个人觉得上面一些关于大数据的东西可以看看。
【在 y*****e 的大作中提到】
: 这个链接很好耶。。lz能说说还有哪些章节应该看看吗？
: 不过我觉得不管是不是被黑了，心理还是应该及早move on,毕竟还有一个机会，要好好
: 把握，迅速进入面试状态。
|
c*********i
发帖数: 46 | 17 当时面试官说假设request load理想。其实我的后面的讨论，都是他的一个问题的引申：
fixed grid有什么问题，怎么解决？
【在 k****i 的大作中提到】
: 另外我觉得是你load balance理解有问题。不是db数据量是否balance or not的问题，
: 是request load, 如果request集中到一个db上，比如ny市中心的几个gird，那db就是
: bottleneck了。所以上面把grid分到不同机器上。
|
