Startup 4.5YOE 8面4中2顶包senior 总结+经验分享

匿名者 发表于 2022-5-2 06:03
1. 我这次的目标就是大厂, 因为startup待过了想去大厂看下. 另外手上已经有一批纸钱了, 也不想再去pre-IP ...

之前我就和你聊过，我现在还是想多嘴劝你一句。

你面的那位HM本身就是个平庸且一心政治斗争的EM，他的老板Director手下基本都是同床异梦的EM，全是自己的小99。他不论和你如何画饼，他想找的只是一个定位特殊且服务于他的斗争的EM。更糟的是，他本身的眼界和能力，导致他对EM的理解放到地里来绝对就是被人会评判的那种。

千万不要因为他给你的印象，或者Roblox这个特殊的语境，导致你认为manager不是你未来希望做的事。在合适的公司，EM绝对比Roblox语境下的EM，要有趣，有挑战，而且有成就感得多得多。相反，Roblox的EM这个职位，很多业界经验丰富的EM和TL来这边都是大喊上当的。

匿名者 发表于 2022-5-1 15:12
之前我就和你聊过，我现在还是想多嘴劝你一句。

你面的那位HM本身就是个平庸且一心政治斗争的EM，他的 ...

太感谢了! 你说的很对, 这次面试也只是一个经验, 包括我在现在公司所谓的“managing experience“, 可能也都不是真正EM做的事情和scope, 所以以后我去了别的公司好好学习和了解一下吧.

匿名用户 发表于 2022-05-01 14:37:57
(就知道会有人关注这个...)
首先, 你这个“虽然但是”.. 好像没什么逻辑关系...

一般A6G5水平的应该都至少有两三个大型项目的lead、design、implement的经验可以侃侃而谈，还需要抢credit？面试还需要夸大其词？

Relational DB的replication,  master-slave模式下, synchronized会有network latency, async的话会有master挂了但一部分数据没有被replicated的风险... 怎么可以解决这两个问题? 既不丢数据又能及时返回?

这个 master 应该有write ahead log， 写请求persist 在disk上之后才返回结果。  master挂了，需要等master上线了之后， 根据wal 来 resolve conflict？

微风簇浪 发表于 2022-5-1 16:24
Relational DB的replication,  master-slave模式下, synchronized会有network latency, async的 ...

嗯我有一场面试就是这么回答的, 但是这样意味着我们认为disk是在我们的控制下, 或者是可以restore的 - 可能有些场景或面试官会认为这样不可以.
Depending on use case, 这个resolve conflict也不好解决. 比如银行交易, 从某个账户里扣100块, 已经被写到WAL然后返回给client了, 这时候master挂了, slave还没接收到这个消息, 然后slave被promote到master那后续的转钱就有可能violate一些constraint... 最终原来的master恢复的时候可能就要人工介入去一笔笔检查有没有问题?

学习了，感谢楼主

匿名用户 发表于 2022-05-01 16:33:21
嗯我有一场面试就是这么回答的, 但是这样意味着我们认为disk是在我们的控制下, 或者是可以restore的 - 可能有些场景或面试官会认为这样不可以.
Depending on use case,

涉及到交易、转账这样的，consistency是优先考虑的。我们公司是sync的，每个node都可以接受写请求，慢点就慢点。

很有用，谢谢楼主。

Relational DB的replication,  master-slave模式下, synchronized会有network latency, async的话会有master挂了但一部分数据没有被replicated的风险... 怎么可以解决这两个问题? 既不丢数据又能及时返回? (一直没想到一个solution...感觉这个无解啊?)

//////////////////////// 楼主，我们公司有一个解决方案。仅供参考。===============
只有master可以read-write。就是用async 到两slave。slave只是backup。master挂了 （除非网络出问题，即使master机器挂了，slave依然可以sync bin data。如果网络挂了，外面的数据也进不让来了。），slave promote成master。因为master和slave的机器是随时可能变化的，所以DNS随机返回三台机器ip。client只要retry几次就肯定能连到master上面去了。
当然天下没有免费的午餐的，这个也是个read/write的一个trade off。比较适合read/write都比较均衡，但是需要速度和强consistent的。（master和slave会有lag，但是只有在非常极端的情况下才会发生）
如果数据量比较大，那么需要sharding。
我们组一个专心搞oracle数据库，搞了10年的牛人搞出来的。

还是不懂为何楼主选择去当ic而不是manager啊，尤其是个人已经在当manager软实力强于硬实力的情况下？你去了狗家l5基本就是大头兵，何况狗家最不缺的就是资深l5，七八年的那种，个个技术实力强对组内业务了解，楼主想更进一步从狗家l5 ic升到l6 ic这条路会比继续manager track然后去面试fg的manager艰难得多吧。不知道楼主是不是有其他的考虑呢？