大厂面试官问你，在项目中遇到了什么问题？怎么解决的？
2021年11月08日 21:34 · 阅读 7273
「这是我参与11月更文挑战的第7天，活动详情查看：2021最后一次更文挑战」
经过了前面的一个项目的初步介绍之后，你的面试官对你整个从事的项目、你的技术战以及你钓鱼项目经历都有了对应的一个认识。
接下来就会进入面试官提问环节。一般来说，面试官在对你进行具体的一个提问的时候，总会有你这边先发起解决问题的思路以及方法。
于是乎面试官一般会问这样的一个问题，在你刚才进行过的一些项目的一个陈述过程当中，你在真正开发项目的时候遇到过什么样的一些难解决的问题，以及你是如何解决的。
一般来说，面试官问你对应的这个问题的时候，主要是想考察你的一些经验、阅历以及你解决问题的思路和方法。
对于这样的一个难解决的问题的定义，其实你并不要特别的去担心这一点。因为你如果在面试的过程当中一味的追求我要发挥出我解决了很多非常难的一些偏门的问题，并且告诉面试官说我是如何通过一些复杂的查询手段去解决这些问题、去查找答案的，其实并不一定能够凸显你对应真正的一个亮点和实力。
因此首先你在面试之前需要就你项目过程当中的一些问题去提炼一些难解决的一个点。首先我们来看一下什么是难解决的问题。
什么样的问题是难解决的
一般来说难解决的问题主要会分为四个维度，分别是常见问题、偏门问题、正常问题以及踩坑问题。
我们是需要去思考我到底是去讲一些常见的问题，还是一些偏门的一个问题？这个问题其实并没有一个非常明确的答案，一般来说常见的问题是互联网研发过程当中经常会遇到的一些问题，虽然问题常见，但是不代表它是比较难解决的。比如一些 GC 的配置问题，虽然说它是个常见问题，但是其实相对来说还是有一定的技术含量，以及多高性能优化的时候我们必须所要承担的这些问题。而对于一些偏门类的问题，大部分情况我们都是属于一些特定领域才会遇到的一些问题。
比如我们研发对应的一个数字计算器，对于一些数字计算能力的一个验证，我们是需要有一些专门的一个解决方案。这种样子的一个偏门的问题可能会与你对应面试的岗位无关。因此就我个人的经验来说，你需要准备的是一些常见的、但是有一定技术深度的一些互联网专用的一个问题。
我们是需要去思考的是我到底是去做一些正常的一个问题，还是做一些踩坑问题的一个回复。那对于一些正常的一般来说，我们都是和常见问题一样，都是一些固定式的一个套路模式去解决这些问题。
而对于踩坑问题，往往会是说我们发现了 Spring Boot 当中的一些源代码中的坑，我排查了许久，通过调试源代码，最后发现了这样的一些问题。
对于这种样子的情况，其实也没有一个标准的答案，一定是说哪个更好，而是更多的是说你对应的这个问题的技术深度，以及解决问题、思考问题的一个手段，是否达到了面试官对你这个岗位的要求。
因此这样的一个抛问题说答案，问你解决了什么样的难解决的问题，以及你是如何解决的。面试官其实主要是想看你做的内容以及深度实操的经验，还有就是你解决问题的一些思考和手段。
回答这种问题讲究一波三折。
一开始没搞懂
去网上看了个答案
一试发现这个广为流传的答案是有坑的
于是自己看 issue
发现还有一个小细节
然后解决了
谁知道还是在某种 edge case有问题
于是自己看规范看源码，搞定
100分
面试官想看你有没有讲故事的能力。（有些面试官以为这是在考察技术，呵呵，其实是在考察讲故事能力）
实际上呢，全是在 stackoverflow 上搜的。包括看源码哪一行都是 stackoverflow 上的网友说的。
你说你不上 stackoverflow？ emmmm，不会面向 stackoverflow 编程的程序员我们不敢要，再见，下一位。
来来来，我来教你。
首先，你应该明白：人家感兴趣的不是哪个问题，而是你解决问题的方法，和你描述解决问题方法的方式。
既然问了最有挑战的，那你一定要找一个，额，有挑战的实例。。。。
如果你说，哦，没遇到什么有挑战的，一般上Stackoverflow上搜一下就解决了。
我们管这种叫SOP, Stackoverflow-Oriented Programming，此乃必死答案。
如果你说，啊，在四年前。。。
什么？我不信一个优秀的一直在进步的程序员不会遇到任何挑战，那么说这四年来你都在固步自封了？哎，赶快打发走人。
如果你说，啊，就在上个月，我在编写$#%!#$%语言，实现#$%!#$框架时发现#$!!##$接口出现#$%!问题，!#$!@%#%^...
你看过电视吧？你见过电视没信号的时候的雪花屏吧？伴随雪花屏呲啦呲啦的声音，就是你的面试官听到的声音。
懒得写了，干脆送个礼包，万能“挑战问题”答案模版：
我（最近的一个时间）在做（怎样的一个产品／程序），这个产品／程序的目的是（帮助用户完成什么事），其中有一个（什么模块），为了实现（什么功能），用到了（什么技术），但是（遇到了什么挑战／难点／bug），我通过（怎样的手段）定位问题所在，问题出现的原因是（简要的点到技术点的描述），我在（至少两个资料来源）上找到了参考，最后基于（怎样的决策标准）决定采用（何种解决方法），运用了（哪种技术），最后成功解决了问题／实现了功能，结果是这个产品／程序（对用户，系统，性能，可用性，资源等产生了何种正面的影响）。下一步，我认为我应该研究（何种更先进的方式），进一步（怎样让产品／程序做得更好）。
问题：范围的控制 前期咨询及销售承诺客户过多，客户强势，交付范围增加导致人力工时增加，无法在预算成本内完成交付。 解决方式：内部与客户经理就交付范围变化导致的成本多次沟通，外部与客户就范围变化多次沟通并明确。内部审议，新增范围导致成本与变化带来的二次商机利润。
最难的是客户不断提出新的无规划的需求，特别是 ZF 部门，还有就是公司采购部门的不专业造成交付问题。 解决方式，针对客户方我们要从专业角度尽量引导客户走向项目设计的方案及成效，而不是提出自己的意见斥驳，在尽可能达到其部分要求的前提下做出合理变更并请求签证。项目变更费用控制在总标价 10%以内。如果变更较大则需公司商务部门出面协商并提前做好方案及报价，及时给出应对。 公司采购部门与项目拖节，采购的不专业盲目节约采购成本，造成供需不符的情况，影响项目交付工续，同时会增加施工成本，在这种情况下要及时做好应对工作，细部调整施工结点，而不是马上追责采购，及时与采购部门沟通调整以防事态扩大。
我做的项目一般不出现范围变动，需要变动时要优先考虑时间结点，其次是成本，项目是否成功是看你在时间节点到达时能否完成任务。如果必须变动范围，一般会联系 3 方，业主，设计，公司负责人，邮件发送变更内容，造成的影响，公司负责人会根据具体情况签订补充协议。我觉得项目最难的是干系人管理，每个人能力，做事方式，脾气，性格都不一样，管不好人项目基本会出问题。解决方法也就只有，团建，聊天，内部通报，踢人。
你永远都不知道销售还给客户吹了什么牛批，你永远都不知道售前还给客户承诺了什么样的功能开发，你永远都不知道客户会不会把电影情节拿出来让你实现
最难的就是不断的需求变化导致延期，本身管理需求包含已确定的需求，未明确的需求以及不断变化的需求。 解决方式：三方会谈！与产品经理与客户进行沟通，告知不断需求变化会增加成本且会延期，如果客户能接受则通过会议文件发布进行确认敲定，反之则弃车保帅！
范围频繁变更，团队经验不足，不能预先识别风险却频频验证，最后计划形同虚设，即使进度勉强赶上了，品质却根本无法保证。 最后只能向客户坦诚，好好沟通，争取信赖与时间。
项目计划管理比较考验公司实力，在需求明确、风险管理机制有效的前提下充分研讨形成实施计划和验收确认项目，做好项目细节变更的通报，统筹内部项目组目标一致、信息互通、任务明确，项目经理依据计划借点及交付进行控制，如有外部供应商时提前签署考核及处罚条款，备份优秀供应商名库。
本身机构组建一个团队就是在不停地创造挑战的机遇，而作为团队中的一份子我们不仅有责任需要处理掉项目中遇到的各种挑战和困难，所以你说最大的挑战和困难我更理解为是对身处机构的责任与对自己的责任，在我的世界观里没有困难是无法逾越的，除非提前选择弃权。 "归属感，团队力量",这个群体里的每一个人都把这些挑战困难视为自己的事情时，问题的处理办法会是很多种语言组成一种可行的方案。 希望每个机构能够做好准备迎接挑战。
中间接手别人做了一半的项目挑战最大，面临状态不明确，上一任的做事情方式方法与你的不一致，团队成员不熟悉，配合度不够，上一任为什么不做了的各种原因等等。
楼上诸位, 不要抱怨, 谩骂拿不到offer 的;
1.. recyclerView 卡顿(bindHolder 有耗时, 子view测量-绘制事件长, 有大图);
2.. 某看图页面, 类似于PDF, 解决大图, 解决占内存, 用缓存队列, 使用预加载, 某种播放列表也有类似问题;
3.. 页面等待时间较长, 肉眼可见, 网络preLoader, 并解决页面重启的preLoader问题, 根视图分步渲染, 减少用户等待;
4.. 排查页面卡顿, 列表滑动卡顿, 渲染卡顿. 首先采集用户设备性能, 在界定卡顿临界值, 最后定位问题,上报, 安排解决(使用原生api + 字节码插装);