
继 面试造核弹,入职拧螺丝 之后,很不幸的再次被抽到,45 分钟 10 题,这次没公布有多少人顺利通过,估计大家都学聪明了。
1 Geekgogo 1 天前 好难啊,一题都不会做 |
3 JYii 1 天前 这有点难了,如果不用 AI 很难回答好。对于大头兵开发只能挑几道题,架构设计居多。 |
5 BelovedOne 1 天前 这多正常啊,来的时候要打死东家,来了发现都是酒囊饭袋。虽然没有向着梦想前进,但性价比拔群。 |
8 111111111111 1 天前 好题,每一题都值得写几篇博客 感觉能答出这些题的人,应该是团队里攻坚(技术研究、方案设计、优化保障)的少数人,在这些场景深度参与,并且留下了深刻影响,甚至可能还颇有心得 大多数人应该答不好 |
11 adimn 1 天前 8.9 招的是运维吧 |
12 Aust1ng 1 天前 能在 45 分钟把这些题全答出来的人,还会来面试吗 |
13 alpha4zeta 1 天前 什么神仙公司, 这么闲, 把公司名发出来 |
14 midsolo OP @adimn 是的,这 2 个题有点偏运维,因为公司中 dev 、test 的 k8s 环境是开发自己维护的,运维只管 sit 、uat 、prod 环境,所以开发也需要懂点运维方面的知识 |
16 midsolo OP @alpha4zeta 某跨境公司,做的业务是把民用无人机跟运动相机卖到欧美或澳大利亚这些地方,真的不闲,只不过周五我想摸鱼,搞这种内部测试估计是领导的 KPI 吧 |
17 alpha4zeta 1 天前 @midsolo #16 DJI ![]() |
18 FlashEcho 1 天前 |
19 midsolo OP @askfilm 这些问题已经很贴近实际工作了,系统是公司交易业务线中的,问题也是正真出现并解决过的,薪资对标的是 p6 ,题目偏难纯粹是因为来面试的人多,部门老大为了提高面试效率而整出来的 |
20 falsemask 1 天前 太难了 |
22 x86 1 天前 当年去地产公司做事的时候,一说做有需求啥的,总监来句给外包做就行了别浪费时间 我:啊这么爽... |
23 k9982874 1 天前 via Android 这题目对标 3-5 年经验 p6 ,你确定能招到人? 这些题目做的好的来你这拿 3w/月? |
24 falsemask 1 天前 @falsemask 第一个以前看过一本 mysql 小册,当时仔细研究过,现在忘了。第二个以前看过 DDIA 作者和 redis 作者的争论,研究过,忘了。转账业务没接触过,但是最终一致性有很多方案。4 5 没接触过。第六个,我们数据归档 dba 做的。后面的 k8s 开发基本不接触 |
25 tonytonychopper 1 天前 via iPhone @k9982874 喵了一眼,这都是架构类型的题,起码也要给 P7 吧哈哈 |
26 Rat3 1 天前 这个在上海是 40K 起的 |
27 midsolo OP @tonytonychopper p6 跟 p7 的技术差距并不大,只不过 p7 多了管理能力跟自驱力,而且跟其他同事关系搞的比较好,目标性强,关键时候能扛事 |
30 JoeDH 1 天前 |
31 asdhak 1 天前 给多少工资? |
32 wu00 1 天前 说实话这面试题出的挺不错的,大部分题回答出解决思路应该就算过关,挺难的 |
33 BraveRBT 1 天前 针对题目 2 对于这么高的强一致性要求,而且还是双活(上下文题目中已经提到了同城双活架构) Redis redlock 方案真的有待商榷. 换句话说 redis 加锁真的能满足强一致性要求吗(同城网络抖动导致脑裂, 内部 NTP 时钟漂移), 从一开始就是陷阱提问方式 很符合面试八股文的基本定义, 即从公司里的历史故障出发, 而不是从技术本质出发 正常做法都是数据库事务做悲观锁,或者 etcd(Raft)做强一致性处理,而不是缓存做分布式锁 而且同城双活的可靠性, 实际上也有待商榷, 不引入外部跨地域可用区进行 OB 仲裁很难避免脑裂问题 通常做法都是"两地三中心"或异地多活, 仅靠同城双活基本都是吹的比较好听,实际业务炸了就紧张的修理中了 感觉整套题目能回答上的人, 基本都感觉公司的实际技术栈是老旧和有问题的.... 我第一想法是这公司的业务系统设计水平不高, 可能还停留在 10 年前的水平, 如果配上薪酬水平估计投都不投了 |
36 BraveRBT 1 天前 另外题目中,已经反复提到了网络抖动相关的问题, 这就更说明公司在这方面吃过亏 如果从架构上可以避免,就不应该使用有缺陷的架构去解决问题, 这也是面试八股文的典型特征 而且题目中也提到了 Drools, 这东西本身就老..... 主流做法早就用 Flink/Spark Streaming 做流式处理实时计算 就和有些公司会问 clickhouse 现在是否是数仓第一选择一样, 反映的都是公司技术栈老旧的问题 答案都是否定的 |
37 midsolo OP @BraveRBT #33 没错,该系统是 2017 年用 Java 开发的,一直在稳定迭代中,现在逐渐在用 Go 进行重构,异地多活这一块用的还是多年以前的 SET 单元化架构,早期团队成员大多来自阿里。 |
38 midsolo OP @BraveRBT #36 网络抖动这个问题一直没法解决,因为做的跨境业务,服务器部署在全球多个地方,数据很难保证一致性,并且尝试多多种最终一致性方案,都没能很好的解决现有的问题。技术栈老旧是历史原因,我入职的时候就用的这一套,已经规划重构升级了。 |
39 kingofzihua 1 天前 一个题也不会。有答案吗? 需要根据答案补下知识 |
40 BraveRBT 1 天前 @midsolo #37 对的, 根据题目大概能猜测到贵司团队创始时间在 2015 年前后 有机会用 go 重构的话, 现在有蛮多先进中间件和框架可以选用 兵来将挡水来土掩, 只要架构设计合理, 性能问题和可靠性问题都能迎刃而解 另外最近几年半导体发展迅猛, 我们十年前担心的很多性能问题(尤其是算力和吞吐),现在已经不再是问题 有时候我们都感慨现在中间件/HATP 数据库的性能和起飞一样,在 15 年我们绝对不敢想会达到这个夸张的程度.... |
41 BraveRBT 1 天前 @midsolo #38 我们内部经常讨论的经验法则: 万事万物都要幂等, 什么业务场景都要考虑重放带来的影响和风险. 问题核心在业务重放和抖动后不幂等, 优先从业务逻辑上解决这个问题, 如果实在无法解决, 再从技术手段上来降低风险. 不清楚贵司实际业务场景是什么, 但我们的想法是: 异地多可用区监察(尤其要单数节点,并且最好大于不等于 3) + 可靠重放机制 数据库如果能上云并能接受阿里系的话, PolarDB 或者 OceanBase 跨地域部署都还可以(把复杂基础设施可靠性问题抛给公有云解决,换句话将来得有个人接锅) AWS 就是 Aurora Global Database, 实际验证过跨区域容灾能力和 RPO/RTO 都还不错 |
43 dfourc 1 天前 |
44 soulflysimple123 1 天前 这是面试架构师吧 |
45 Geon97 16 小时 16 分钟前 这个岗位多少薪资啊 |
46 wuhanchu 15 小时 2 分钟前 我作为部门的技术总监 我羞愧 。也就懂寥寥几题 |
47 chenshun00 10 小时 22 分钟前 我很惭愧 :) |
48 ytmsdy 5 小时 6 分钟前 卧槽,我作为一个十多年的后端开发,感觉都答不太上来! 所以这个岗位的年包是多少? |