本篇文章较短，是一个同学的真实面试问题，这些问题看起来很简单，但是并不好回答。我们作为面试者回答这些问题，你的回答会直接影响你的面试评价。我们从这几个简单的问题来看下面试官在问什么？
1. 线上实时作业的qps是多少？
你以为的答案
这个问题看起来非常简单，直接回答1万，10万等等。
面试官真正想要的
面试官想通过这个问题了解你的业务规模，数据规模，数据接入方式等等。
在业务上，面试官想了解你的简历中的项目里提到的业务核心业务过程，数据接入方式，核心设计方案等。例如你是通过CDC的方式接的业务库，那么这里还要考虑DELETE消息的过滤，如果你的业务过程比较复杂，中间涉及到非常多的状态机变化，那么的你的输入qps要在业务规模的基础上扩展数倍甚至数十倍。另外还要考虑，如果你用到了流关联，那么叠加回撤消息，这个量会是你的真实业务数据增量的很多倍。当然这和你的技术方案紧密相关，一个有经验的面试官很容易通过一两个很小的点判断这个项目你做到了什么程度，是浅尝辄止还是深度参与设计和实现。
除此之外，假如你的数据规模非常巨大，那么高qps下，实时计算的任务会有一系列的问题，例如维度表的hit rate、数据hot key问题。这些问题，如果你能在回答的时候顺便和面试官讨论一番，那么是绝对超过面试官的期望的。
2. taskmanager full gc的原因是什么，如何做的优化？
你以为的答案
内存给的不够，增大内存。
面试官真正想要的
面试官想通过这个问题，了解你在生产环境是否真的遇到过这类问题？是否对框架的内存模型足够了解？是在什么业务场景中遇到的？如何定位到的Full gc频繁？如何定位热点代码？如何解决？
例如如果你的框架是Flink，那么在监控系统上可以看到任务的内存分配和真实使用情况，另外还可以看到full gc 的频率。
此外，Flink给我们提供了强大的火焰图能力，火焰图可以很容易定位到热点代码，最终你定位到的问题可能是UDF中大对象调用问题，也可能是单纯的堆内存分配不合理，当然也可能是你的业务场景数据规模太大（高达几十万/百万）缓存了过多的数据造成的。
总之，任何一个线上的问题都是和具体的业务场景相关联，从发现问题，定位问题，解决问题，是一个紧密相连的过程，不可能脱离场景单独存在。
3. hbase的使用场景
这个问题我们可以扩展到任何一个框架的使用场景。
你以为的答案
公司平台选了这个/大数据量下的高并发读写。
面试官真正想要的
如果面试官提到这个问题，那么一定是你的简历或者项目中提到了这个框架。那么他真正期望你表达的是，你的技术方案中选择了某一个框架，那么一定是因为各种原因，它有一些独特的优点在你当前的业务场景下，是其他的框架所不具备的。假如这个技术调研的过程交给你去做，你需要准备哪些信息？我们知道一个组件的选型需要做详细的benchmark测试。比如基本的使用场景是点查询还是排序、聚合？主要的场景下的性能表现？qps、rt、支持的数据规模？稳定性？SLA？灾备情况？未来如果进行技术迭代升级，有可能的替代方案是什么？这些因素综合到一起，才是你选择它的理由。
上面几个问题是面试的几个常见问题，这几个问题让不同背景、经历的同学回答结果完全不同。回答这些问题，不仅仅是掌握知识点本身那么简单，同时是过去经验的总结，开发思维方式的体现。这也是很多同学非常困惑的，为什么我的问题都答上来了，但是面试失败/面评不好的根本原因。
