给个开放架构题，候选人秒出方案——怎么判断是做过还是猜的？

# 第一层：约束变化追问
 
# 候选人给了实时归因方案：Kafka+Flink+Doris
 
# 追问1: 如果QPS只有100，预算很紧呢？
# 真做过的：那这个架构是过度设计，可以简化为日志直接入库
# 八股党的：还是这套架构，性能足够
 
# 追问2: 如果QPS峰值5万，但要求精确归因不能丢消息呢？
# 真做过的：要考虑Exactly-Once语义，
#         Kafka要配acks=all，Flink要开Checkpoint+幂等下游
# 八股党的：这套架构本身就支持高可靠
 
# 追问3: 如果数据要保留3年做长期分析呢？
# 真做过的：Doris存最近3个月，
#         冷数据放Hive/Iceberg做归档查询
# 八股党的: Doris可以一直存
 
# 真做过的人，方案会随着约束变化
# 背书的人，方案永远那一套

// 第二层：替代方案追问
 
// 候选人方案: Kafka+Flink+Doris
 
// 追问1: 为什么用Kafka不用Pulsar？
// 真做过的: 我们考虑过，但Pulsar运维成本高，团队对Kafka熟，
//          且Kafka的生态成熟度高
// 八股党的: Kafka是行业标准
 
// 追问2: 为什么用Flink不用Spark Streaming？
// 真做过的: 延迟要求秒级以下，
//          Spark Structured Streaming的微批模型不够
// 八股党的: Flink性能更好
 
// 追问3: 为什么用Doris不用ClickHouse或StarRocks？
// 真做过的: 这3个我们都做过POC，
//          ClickHouse Join性能不行，
//          StarRocks当时还不太成熟，
//          Doris支持了我们需要的UPDATE和高并发场景
// 八股党的: Doris就是好用
 
// 区分关键：候选人是否能讲出"权衡过程"
// 真做过的人讲过程，背书的人讲结论

第二层是最杀的。架构选型是个「权衡」过程，不是「选最好的」。能讲出权衡过程的人，是真做过；只会讲「这个最好」的，是背的。

第三层：挖落地细节

第三层问最具体的落地细节：「你这个Kafka分区数怎么定的？Flink的并行度多少？Doris的BE节点几个？」

落地细节是最装不出来的。一个真做过的人，对这些数字有「肌肉记忆」；背书的人只能给量级或者瞎编。

落地细节问题	真做过的回答	背书的回答
Kafka分区数怎么定的	按峰值QPS/单分区吞吐算的，我们定了32个	默认值或者瞎报
Flink并行度怎么定的	和Kafka分区数对齐，下游聚合算子按状态量调	知道有这个参数
Doris BE节点几个	起步3个，后来扩到6个	不知道
数据延迟P99多少	我们目标是2秒，实际跑下来1.5秒	应该很低吧
每天数据量多大	原始日志2T，落盘后500G	很大

一个完整的「秒出方案三层挖坑」实战

我面过一个候选人，问他「设计一个实时归因系统」。他秒出方案：Kafka→Flink→Doris+维表关联。我开始挖：

第一层（需求边界）：「如果QPS只有100呢？」他答「方案不变」。「如果延迟要求100毫秒以下呢？」他答「方案不变，调一下Flink并行度」。约束变化方案不变——红灯。

第二层（技术取舍）：「为什么没选Spark Streaming？」他答「Flink延迟更低」。「具体多低？你测过吗？」他答「业内都说Flink快」。讲不出权衡过程——红灯。

第三层（落地细节）：「Kafka分区数你们设了多少？」他答「默认值吧」。「你们Flink跑了多少时间？峰值QPS多少？」他说「数据不太记得」。讲不出落地细节——红灯。

三层全红灯，判定为「背过类似题但没真做过架构」。最终评估按「执行型开发」打分，不按「架构师」打分——岗位是Senior，他的水平只够Mid。这就是三层挖坑的价值。

挖坑时的「软规则」

规则一：每层之间稍等几秒。不要连续追问，给候选人时间。连续追问像审讯，节奏稍缓更像技术交流。

规则二：每个追问都给具体场景。不要泛泛地问「为什么」，要问「在XX场景下为什么」。具体场景能逼出真实细节。

规则三：候选人讲不出来时给暗示。毕竟开放题难度高，讲不出某个细节不一定是没做过。给一次暗示机会再判断。

规则四：用「假设」把对话拉回来。候选人卡住时，「咱们假设按你的方案，QPS翻10倍会怎样？」——把方向定了，候选人能继续讨论。

面试高频追问

追问一：候选人秒出方案但是确实做过类似项目，怎么办？

不会有这种情况。真做过架构的人有「条件反射」——会本能地问需求约束，不会秒出。如果候选人简历写做过类似项目但回答方式像背书，那大概率是项目里他不是架构决策者，只是执行者。这种情况按「核心开发」评估，不按「架构师」。

追问二：候选人三层都过了一些，但不是全过，怎么定级？

按过的层数对应级别：3层全过=架构师；2层过=资深开发或架构候选人；1层过=中级开发；0层过=初级或八股党。把级别和岗位需求对齐，给精准定级。

追问三：怎么应对那种「现学现卖」的候选人？面试前突击背了几个架构」

第三层（落地细节）必杀。背的内容讲不出落地数字、讲不出参数、讲不出运维经验。这一层不是知识题，是经验题。突击不出来。所以三层挖坑顺序很重要——前两层考思维，第三层考经验，经验是装不出来的。

实战踩坑：被秒出方案的候选人迷惑

我面过一个候选人，让他设计实时数仓架构。他秒出了一个完整方案，技术栈、分层、监控、容灾全都有。我当时被速度震慑，觉得他思路非常清晰，给了高分。

入职后他第一个任务是设计一个新的实时归因系统，结果他给的方案跟面试时讲的几乎一模一样——但完全没考虑业务的具体约束。一个一样的Kafka+Flink+Doris方案被他套到所有场景上。后来才知道，他面试讲的方案是从某篇技术文章背的，自己根本没真设计过。

教训：秒出方案 + 不问需求 = 大概率是背的。从那以后，开放架构题我都用三层挖坑法。能秒出方案的人，要么有第一层的「需求反射」，要么是背书。两种判断方式完全不同。

候选人侧反向使用指南

如果你是求职者：

① 听到开放架构题，第一反应是问3个问题：QPS、延迟、数据量。这是架构师条件反射，主动问就拉满了第一印象。

② 给方案时讲「为什么不选别的」。一句「我考虑过XX但没选，因为YY」，比讲100句方案多好都值钱。

③ 主动给落地数字。「这种规模我建议Kafka 32分区起步，Flink并行度对齐」——具体数字让你的方案立刻从纸上落到地上。

总结

开放架构题的精髓不是看方案，是看思考过程。秒出方案是警钟不是亮点。三层挖坑法：需求边界（变约束看方案能不能变）→ 技术取舍（讲为什么不选别的）→ 落地细节（具体参数和数字）。三层全过的是架构师，过两层是资深开发，过一层是中级。能秒出方案但不问需求的人，9成是背的。

下一篇聊一个新人面试官最爱争论的问题：候选人的方案不是我心里的标准答案——是错还是另一种思路？

你做面试官时，最常用的开放架构题是什么？评论区聊聊～

关注「Wood聊大数据」| 9年大数据老兵，聊技术、聊职场、聊成长