在面试时，经常会被问到各种”蛋疼”的面试题,不知如何作答，举些例子:
1:你开发生涯中遇到的最大问题是什么？你是如何克服的？
2:假设场景内有500个人，如何对500个人进行寻路优化?
3:假设一个界面太单调，想图标上加一堆特效,如何保证界面打开时能流畅?
4:动画的帧率，多少最为合适？
5:做手机游戏时美术模型的面数有什么样的规范？
6:你认为怎么样的编码才算规范？
7:你如何看待代码注释?
8:你为什么从上一家公司离职?
…
这些”蛋疼”的问题，大家是不是经常会遇到,回答完，往往效果不好。明明自己技术能力可以，为什么面试完总被人看不上？
分析这些问题，找到"蛋疼"的原因
我们先来分析一下这些问题让人”蛋疼”的原因：
问题4, 5, 6等类似规范等问题, 不同时期，不同项目，都有不同的标准,没有标准答案。很容易回答错误。
问题6, 7的蛋疼本质: 属于讨论10年也没有结果的问题。
拿问题7来举例，代码写注释吧，可能会陷入过度注释的问题，代码不写注释,会陷入代码不好维护的问题。代码写少量注释，会陷入注释不规范的陷阱，代码大量注释吧，会陷入过度注释的陷阱，一旦你讨论，讨论10年都没有答案。
问题2, 3属于需求不明确，容易陷入”答非所问”的陷阱。
面试时,面试官经常感觉面试者答非所问，面试者不知面试官具体要问什么。双方在尬聊。其实这是典型的"需求不明确"的问题，比如”如何对500个人进行寻路优化”问题，是客户端还是服务端？500人寻路，是独立的寻路，还是可以分组(一组由中心带领,共用寻路)，是否可以使用多核优化等…...(这个问题，我在下文给一个参考的回答)需求没有明确，根本就不知道面试官想问什么，你该回答什么。
问题1，问题8属于”人性”问题，怎么回答都错。
“你开发中遇到的最难的问题是什么？如何克服的?”。你认真回答一个问题吧，别人觉得你这个问题没有难度，他心目中的”难点”才有难度，觉得你技术菜。你回答没有技术难点吧，他觉得你没有做过大项目or太狂妄。怎么回答都错。
“为什么从上一家公司离职?”这个问题，怎么回答都是作死。
以上这些问题，即是挑战,也是机遇。如果回答的好,能让你脱颖而出。同时很容易与面试官陷入”对立”的立场。
如何回答好这类“蛋疼”的问题
原则1: 万能开场白，立一个不败的立场,让面试官入套。
例1: “为什么从上一家公司离职?”,我们先抛一个”不败”的立场来开场:”现在社会,生活压力很大,节奏很快,个人,公司都可能面临复杂的竞争和抉择，导致我们不能像国企一样，可以一直干下去。每个在”民企”工作的人,怕被公司裁员,所以不断地学习，提升自己。又怕没好的前景，35岁后就没有发展, 压力都很大。导致我们会有多段工作经历,在现在的社会是非常普遍的。感恩带过我们的领导,优秀的同事,从他们身上学到了很多东西。同时也祝福自己能在新公司有一个好的发展，接受新的挑战来磨练提升自己。”
例2: “你如何看待代码注释?”,我们也来立一个不败立场，让面试官入套。
“每家公司的企业文化，项目复杂度，研发投入，团队规模等不一样,导致对代码维护，交接以及相关注释和文档的要求不一样。我见过小项目没有很多的注释和文档，因为它本来也简单，做好代码命名，基于一些基本的开发纪律就可以了。我也见过大项目要做好完整的注释，修改记录等，同时通过技术交流,code review来解决代码维护与交流的问题,同时关键的点也会配套比较详尽的文档做好交付。具体根据项目需求，项目大小等因素来综合决定，制定适合项目的开发纪律与相关注释与文档规则。
万能开场白的本质就是不先入为主,强力输出自己的观点,可以从以下方面入手:
1:具体问题具体分析,没有绝对,只有取舍;
2:从大形势,大环境等来分析整体行业行为;
3:谦虚，把自己放低,永远是最真诚的面试必杀技;
…
更多的一些技巧,可以自己总结与使用;
原则2: 站在”更高”的角度来回答问题
程序员回答面试问题时，往往马上就说技术点，解决方案，陷入问题的细节中，导致高度不够。个别遗漏的细节，容易让人扣字眼,导致双方都陷入细节中，忽略了你的高度和思想。这个时候，我们最好站在更高的角度来回答问题。
问题5: 做手机游戏时美术模型的面数有什么样的规范？
我们利用原则1,和原则2来很好的回答这个问题:
开场白:
“面试官，这个问题有点不好回答，不同的项目,情况可能不一样,不能一刀切，如果我是项目负责人来制定公司某个项目的相关技术规范，我会这样来综合考虑,来制定一些注意的规范,您看下我说的对不对?,有遗漏的还请指正。”
这里开场白,利用了”原则1”中的谦虚,放低自己,请面试官指点,具体问题具体分析的策略，来让自己的不败之地立场。利用了”原则2”,站在更高的角度，来回答以下问题，为后续充分展现自己做好准备。并避免了直接回答技术参数这种低级且可能的错误,不加分反而减分。
原则3: 拉高立场后，分情况进行充分讨论;
接上面的问题，我们站在项目负责人的角度来分析来如何制定规范。这个时候就要充分的分情况，分角色来进行讨论，就像写作文堆字数一样的,接着上面的回答如下:
“我们首先找到相关的竞品or画风相近的游戏，来分析它的一些相关技术难点,准备技术预研。这里就包括了它的美术风格，它里面模型的面数等来作为一些参考。确立核心极限玩法中可能会出现的最复杂,最多的面数情况，来做性能验证与技术预研，从而来确定渲染总面数在不同机型上的表现，来根据我们的游戏项目来确定模型与场景等的相关面数范围规范。对于美术而言，要求他们建模的时候,充分考虑用最小的面数来构建模型与细节，用细节增加等技术来减少模型面数。同时程序提供”减面工具”，让美术在出模型之前，使用减面工具，在效果不变的情况下让每个模型的面数最小。场景与模型出来后，程序最快的速度验证极限玩法的性能，让程序，美术，表现效果上整体达到最佳。以上就是我的一些想法，如果有遗漏的，还请指正。”
上面的回答,避免了直接回答参数可能导致的错误,又充分的表现出来你是如何来分析处理这个问题的。
作业: 阅读回答并思考用了哪些原则？
问: 假设场景内有500 人，如何做500人寻路优化?
答:
“在没有说明游戏的类型,地图的特点，可视范围内最多的玩家人数，是否有其它特殊点能优化寻路的等情况下要回答500人同时寻路如何优化,这个问题有点难，之前我没有做过同时500人寻路的优化，国战虽然有500人同屏，但是没有寻路,弹幕类游戏超过500人，但是基本是用避障+流场+多线程地图的障碍物并不复杂，如果我遇到了这样的问题要做技术预研or性能优化，我大概会做如下处理:
1:先根据游戏项目，选定最合适的寻路算法，目前主流的算法有:流场寻路,Mesh寻路,Astar寻路等。选定好寻路算法后,将单个的算法优化到极致;
2:充分考虑戏玩法的特点,看是否能采取其它的一些可行方案优化，比如,500人，分成50个组，寻路的时候只要寻路50次就可以了,减少问题规模;
充分考虑地图的特点，将地图分成关键的块，每个块有个关键点，提前把所有关键点A到关键点B的路径全部都预先寻路出来,保存到内存里。运行的时候，玩家A---》关键点A---》关键点B----》目的地。这样关键点A到关键点B的路径，不用寻路，查表即可。关于这些方向，可能有遗漏，具体问题再详细讨论。
3:如果上面的算法优化完了，还是有性能问题，就得要考虑使用的策略。
如服务端可以考虑多线程寻路，分布式寻路等,客户端我们可以考虑多线程寻路等。让多核并发来优化500人同时寻路的问题。
总结一下就是三大的方向: 算法选取与算法性能优化到极致，结合项目的特点等来优化寻路策略, 多线程并发,分布式等方式来进行多核优化。可能中间有考虑不周的地方，请指正。
”
这样回答完后，后续的问题都会是更明确的技术问题,就更好回答了。
End
最后面试时，分享一个小技巧，自己带笔+笔记本，面试时，记录面试官的问题，同时回答问题时，先在笔记本上思考一小会，确立一下回答问题的基本立场和思路框架。然后再不悲不亢地回答即可。