开始挖坑
回想当年跳槽面试，经常会遇到面试官给我一个假设场景，让我给出应对方案。
那时候傻乎乎地不懂，以为正好是我展示经验和水平的时候，恨不能把心窝子里的话都掏出来。但是通常结局只有两种——
一种是技术向的面试官详细记录，或者干脆扔给我一张纸，“你把你的方案写下来吧。”等我写完后出门，留下的记录就被交给相应的团队作为参考。
还有一种更惨，我在描述的过程中，HR或运营部门的面试官不断修改客观限制条件，甚至说：“用户就是不同意你的建议方案，认为不能满足业务要求/超出预算/导致交付延期……”。我则疲于应对，最终不得不举手投降——“您是面试官，自然怎么说都对。”
看到了吧，我面试经历过最大的坑，非假设场景类问题莫属。
千万别跳
既然知道是个坑，那当然不能再往里跳了。但是面试官的问题又不能不回答，该如何是好呢？
其实，回答这类问题，只要掌握以下三个要点，往往就能取得奇效。
一、永远不要用“我会／我应该／我觉得……”这样的来开头。面试官一听就知道候选人没有这方面的经历，只是拿一些大家知道的正确的废话来应付。这就好比老师上课只告诉学生几何定理，却不教大家怎么在证明题里去运用是一样一样的。
二、针对面试官给出的假设场景，尽量拿自己的既往经历往上套。因为这是我实实在在经历过的事，限制条件已被锁定。要想随便修改，面试官在道德高地上怎么站得住？
三、用SBI三步法情景再现。
如何是好
上次提过STAR原则，这回是SBI，其实二者殊途同归。唉～这回是没法偷懒了。简单说一下SBI吧。
其实SBI分别是三个英文单词的首字母，
Situation（场景）：一句话交代清楚当时的场景。
Behavior（行动）：两句话说明自己所采取的行动。
Impact（结果）：两句话说结果，结果好坏并不是最重要的，关键是从中学习到了什么，对自己有哪些促进。
现在无论是我参加面试，还是我面试别人，都按照或要求候选人按照SBI方式来描述，同时尽量给出一些的数据。一方面减少大家说正确的废话浪费时间，另外一方面，也可以通过基于数据的探究，判断出候选人在其中到底扮演了怎样的角色，有没有把别人甚至团队的业绩拿来给自己镀金。
再举一个例子来说明吧：我在一次面试中，遇到面试官问我，有用户跟你反馈，他们在日常工作中访问文件服务器上某些文件的时，遇到某些上传文件无法打开的问题，请问你会采取什么方法处理？
我的回答：
您描述的场景跟我之前经历过的一个情况一致或类似。
Situation——我公司某某部门在定期访问存储在文件服务器上的扫描件时，时常出现文件上传不完整而无法打开，或者内容重复遗漏等情况。
Behavior——我跟该部门同事进行深入沟通，详细了解他们日常工作流程和痛点问题后，决定开发新的文件上传工具辅以搭建新文件服务器，通过某某技术手段，确保文件上传的完整性，一致性和可追溯性等等。并在开发/服务搭建完成后，邀请该部门同事参与测试，验证方案可行且有效。
Impact——方案获得该部门同事的认可，以前需要XX人小时完成的工作，现在缩短到X人小时即可完成。我不仅技术水平获得提升，也也熟悉了相关业务流程，锻炼了自己发现问题和沟通解决问题的能力，同时获得该部门同事的认可，让我在开展后续工作过程中获得不少便利。
这样一通描述下来，不仅能让面试官知道我曾经做了什么，而且由于客观现实的限制，面试官很难再随心所欲地调整假设场景，最多就是针对其中的一些细节发问。不过，既然是自己经历过的事情，随便面试官怎么刨根问底，候选人也不会再担心被逼得疲于应付了。
留个尾巴……
还有一种情形，面试官给出的假设场景，确实是我没有经历过的。怎么办？——管出题老师要思路！
首先，诚恳地跟面试官解释，您提到的这种事情，我确实没有经历过。不过，我有一些想法，正好借这个机会跟您分享一下，请您给我一些指导。
然后…… 面试中化被动为主动，引导面试官思路的小点子即将于下周登场——敬请期待下篇“面试黑科技——如何与面试官求同不存异” 。
