● 问已经发生的事情
比如面试移动开发者，面试官应该认真看下其做过的 App，具体的工作是什么，
准备一些相关的问题，这里就可以看出来之前工作中的积累是什么，有多深。
● 问题解决思路
针对项目经验和一些学习的经验上面，应该问拿到问题以后解决思路是什么，在
什么场景下为什么这么做，这里根据面试者的方案，分析的方法论，就可以大致了解
面试者是否聪明，知识面是不是够广，遇到问题时会不会举一反三。
具体可以举个简单的例子，很多同学说自己做过架构，然后都会讲自己做了一个
解耦和分层的框架，其实这类框架 iOS 很多，外部 github 上就有各种方案。在阿里
内部手淘早先做的 bundle 拆分时沉淀的容器规则，天猫开源出去的 beeHive，闲鱼
内部的 Xframework，抑或是服务端的 spring mvc，其实都实现了 IoC，但实现和
思路上都有一些差异，到底为什么这么做，其实是有区别的，这里面就可以看出知识
广度，总结和思辩能力，在关键路径上的技术判断。
又比如说，我们总在强调性能稳定性怎么做，业界也有很多方案，到底哪个方案
更好呢？答案没有绝对的对错，取决于某个时间点和场景下哪个问题是最核心的突破
点，而你的选择标准和落地的技术方案是不是合理（考虑成本，收益，以及后续的风
险是什么）。一般来讲，我们更倾向于用系统化的思维看待一个问题，也就是说，相
比根据人的经验去识别性能瓶颈，我们更希望能通过自动化，智能化，数据化的方式
去解决问题。
● 少问多听
一般刚开始做面试官的同学很喜欢以问为主，但因为大家的知识体系不太一样，
成长环境也不同，直接这么问起来很难就找到面试者的优点，所以尽量让应试者自己
陈述，然后以学习和交流的心态针对陈述中存疑的地方再进行发问，会更容易让应试
者放松，也更容易让应试者更全面的表达自己。另外，问的差不多的时候，结尾的
时候可以补充一句：您觉得刚才的面试中还有哪些我没问到的，您想再补充一下的内
容？末了，再问下：我的问题问完了，您有什么想要问我的吗？
---
===
STAR 原则
● 处境 (situation)
在什么样的环境下
● 任务 (task)
接到了什么样的任务
● 行动 (action)
然后具体怎么落地的
● 结果 (result)
拿到了什么结果
我们尽量问清楚对方在什么样的环境下接到这个任务，接到以后是做了什么事
情，最后的结果是什么样子的。乍一听，感觉，这不是套路嘛，是不是知道这个原则
的人，只要按照这四点编故事，就能通过面试了？当然不是，在叙述过程中，我们应
该分辨出 STAR 中的真假，那下面就举一些例子。