- 短期（1年内）


     - 个人技术沉淀，查漏补缺，专研技术打好基础，尽快熟悉公司的业务需求，完成公司布置的任务，


- 长期（2-3年）


     - 通过工作，通过工作的积累与个人的学习，能够独当一面，并能够对系统进行不断的完善且为公司带来收益。专研技术，能够作为leader协调小组，学会强化管理能力


- 未来


     - 往项目经理方向发展

- 优点


     - 执行力比较强


- 缺点


     - 太好说话，容易被动


     - 我的工作执行力很高，领导给我安排的任务我也能较快的完成（速度快），但是可能在工作的时候会少一些深入的独立思考，所以经常会对一些细节进行反复校对（虽然可能会出现小问题，但是我有意识到并且加以注意），对于这方面能力需要我进一步的努力，我也将继续学习，通过阅读、向前辈请教等改善自己的不足（注意到问题之后也会进行改正）。

- 其实我在上家公司工作得游刃有余，能快速搞定需求，而且我比同水平的开发者更有责任心，再加上我在团队里表现出众，还能向领导给出专业性的技术方案，所以一直很受器重。 但如果我固步自封不思进取，我怕我会被行业淘汰。


- 因为目前的工作太安逸，没有挑战，公司整体上都很稳定，也没有什么发展空间，我希望有一份比较有挑战的工作，毕竟还年轻


- 我目前在公司已经到顶，短期不会有什么发展空间，我希望有更多挑战，接触更多新项目，到更大的平台发展.


- 认为自己已经具备一定的积累，希望可以迈向新的台阶，我重视平台的发展，我认为一个人只有再合适的平台才能够最大程度发回自己的才干


- 希望拓宽自己的知识面，进行更深入的学习和实践，人不应该满足现状应该积极进取，如果不能适时的挑战自己，比自己一把怎么能够最大程度挖掘自己的潜力


- 个人职业发展与公司发展规划不符，部门岗位调整，业务发展与个人职业规划有出入

- 面试前问


     - 就说：需要根据和面试官聊的情况来看，现在暂时不方便说


     - 如果必须给出范围：先反问对方各种福利、奖金在内的收入构成，以及目前岗位的定级再给出期望值


- 面试后问


     - 表现良好


          - 之前做过的项目与贵司做的业务范围很匹配，来贵司后可以减少很多沟通成本，往高处开


- 如果HR说给不了期望的薪资


     - 切记不要给肯定，也不要否定


          - 我认为候选者与公司应该是一种互利共赢的关系，而非买卖双方的对抗关系。我的期望薪资与贵司可能差了一些，但是可能就是因为这个差值，会导致候选人的积极性以及加入公司的意愿没有那么强烈了。还是很感谢公司对我能力的认可，公司可以先按照面试流程对我水平先进行评估定薪，后续我也会参考该薪资水平与我所期望薪资的差距，反思自己的不足


          - 说明我的表现可能没有达到你们的预期，我会复盘一下面试表现哪里有问题

- 回答思考方式


     - 1、为什么会觉得这里是难点  2、遇到之后自己是怎么想的  3、怎么去解决这个难点的  4、解决之后与目标相差多少  5、从这个难点中你学到了什么


          - 项目的预览


               - 1、难点的原因：没有接触过在线预览的功能


               - 2、第一个想法是，直接转为图片或者pdf，可以直接从浏览器打开直接查看，不需要下载；


               - 3、由于公司要求使用免费，找到openoffice这个API可以将word或者excel转为pdf，所以当用户上传之后，存储到服务器，点击预览直接调用api转为pdf，并再次以pdf形式存储到服务器内，下次再预览可以打开该pdf，不用再次转换


               - 4、存在3个问题，一个是excel文件内容太多会折行，所以重写里面的方法，将转的pdf的长度进行加大，当然这个还是可能会存在折行问题；还有一个则是移动端的问题，移动端IOS点击pdf无问题，但是安卓打开则会直接下载，所以如果是安卓，将文件再次转为图片，第三个是文件过多，定期清理


               - 5、利用gitee的第三方项目 kkFileView（公司不同意使用），实际项目没有做，自己有在个人的项目中用过


          - MySQL查询超时问题(线上有个定时任务，这个任务需要查询一个表几天范围内的一些数据做一些处理，每隔十分钟执行一次，直至成功。)

               - 1、难点原因：很诡异，每天凌晨5点多失败，但是凌晨6点执行成功；异常日志查看显示MySQl查询超时，原本以为能立马定位问题并处理，但是实际耗费了许多时间


               - 2、第一个想法是，SQL没有走索引，把日志里面的sql复制出来，sql里面有两个日期参数，是药品的库存交易时间区间，相隔三到五天，我取了5天的时间间隔的保守值，explain一下这条sql，却发现还是走了索引，走的也是时间这个字段建立的索引，执行发现也只是耗时100多毫秒


               - 3、根据explain结果，这个sql肯定是走了索引，如果没有走索引，六点钟的查询按理也会超时；所以让dba帮忙导出凌晨5点到7点关于这个表的慢sql，但是dba说那个时间段没有这个表的慢sql，索引也验证了原本测试的推断，这个sql走了索引，可能五点多因为一些原因导致了超时


               - 4、所以我的想法可能是这几点引起的


                    - MySQL资源竞争


                         - 我查看了那个时间段的mysql运行情况，连接数以及cpu负载都是正常，会不会是因为其他业务操作影响到这个表了？由于我们数据库事务隔离级别是RR(可重复读)，因为MVCC，简单的修改不至于影响到查询超时，有可能就是别的业务update这个表的时候，更新条件没有走索引导致行锁升级为表锁，并且刚好在5点左右执行；首先这个条件非常苛刻，检查了相关代码以及咨询对应负责人，并没有这个情况，所有更新都是根据ID主键更新，如果更新SQL的更新条件没有走索引，肯定会是一个慢SQL的，那么，我们在慢SQL日志文件里面就能找到它，实际上并没有


                    - 数据库备份


                         - 会不会是因为凌晨5点多数据库备份呢？首先备份锁表不会锁这么久，这个任务是前前后后半个小时都执行失败了；我们的备份任务都不是凌晨五点执行的，这个就可以排出了


                    - 网络


                         - 我找运维同学帮忙看了一下执行任务的那台机器那段时间的网络情况，非常平缓没有丝毫问题，机房也没有出现什么网络抖动的情况。再者，如果是网络问题，肯定会影响其他任务和业务的，事实上，从监控系统中查看其他业务并没有什么异常。


               - 5、先后排除了索引、网络、备份、业务竞争MySQL资源等因素


                    - 解决1：我把任务执行时间延后，加一些监控日志再观察观察。毕竟，又不是不能用。


                    - 解决2:   1）重新理清思路，问DBA要了一份线上5点到6点的慢sql文件，重新找了一遍发现没有这个表的慢sql记录，但是突然发现，sql日志记录的时间时区都是标准时区的，而我们任务执行时间是北京时间


                         - 标准时间与北京时区(东八区)是差了8个小时


                    - 解决2： 2）让DBA重新跑一份慢SQL，出现了我需要的那个表的慢SQL，从日志发现，查询的区间从2021年11月到2022年4月，时间跨度5个月，mysql成本计算认为区间太大走索引不如全表扫描，最终没有走索引，但是原本不是说3-5天，为什么变成5个月了呢？


                    - 解决2： 3）定位代码，发现底层取时间区间的时候，调用了一个接口，接口预期返回的时间只有几天，但是结果返回了几个月的时间区间，于是联系这个接口的相关人员，通过查找验证确定了是底层数据的问题


                    - 解决2： 4）修复了相关数据，增加了相应的校验与监控，重新发布系统，终于解决了这个问题


               - 6、不走索引，为什么六点多的时候执行没有超时呢？


                    - 原因就是六点基本上没有业务在调用MySQL，那个时候的MySQL的资源是非常充足的，加上MySQL的机器也配置非常的高，所以这条SQL硬生生跑成功了


               - 7、为什么这个BUG在线上这么久了，现在才发现？


                    - 这个时间区间底层数据用的不多，目前只发现只有这个超时SQL任务在调用。原来业务量没有这么大，加上机器配置高，扫描整个表也花不了多久时间。凌晨五六点执行，没有对线上的服务造成影响


               - 8、总结


                    - 复盘一下整个过程，对于这个查询超时SQL问题的排查，我从索引、网络、备份、业务竞争MySQL资源等方面一一分析，却忽略了最重要的因素——执行的到底是哪一条SQL，原本一个简单的问题被我复杂化了


                         - 你可以保证你写的逻辑没有问题，但是你不能保证服务上游提供的数据都符合预期。多想一下如果上游数据异常，自己写的服务会不会出问题，多加一些数据校验和报警会省去很多不必要的麻烦。


          - 难点考虑方向


               - 内存泄漏


               - CPU高


               - 磁盘碎片


               - 性能不足

- 项目需求把控


- 技术方案设计以及实施


- 落地过程的风险把控


- 在x项目过程中主要遇到跨团队的协同问题


     - 项目排期


          - 立项会，干系人全部到位


     - 目标对齐


          - 责任到人，落地过程积极响应pm进度以及技术风险识别


- 背景、解决方案、结果复盘总结等纬度来讲。方案这块最好有多个备选方案，个人所负责的那一块，不局限与端上的核心问题，还负责整体系统方案设计，资源协调

- HR


     - 1、公司的晋升方式以及渠道


     - 2、绩效考核方式


     - 3、公司的发展愿景与价值观


     - 对员工的培养机制


     - 公司的组织架构


- Leader


     - 1、简单介绍下目前团队的业务


     - 2、未来的发展计划与团队规划


     - 3、目前该岗位的长期目标


     - 看中候选人哪方面的素质能力


     - 公司的研发流程