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