放眼长期，稳中求进；知行合一，日拱一卒

自身的专业性要提升。2、喜欢谈设计，这么能侃，就问了下 类似基础服务cs，短信邮件发送的设计，就只答了具体3点，没设计思路；4.候选人对offer的关心程度，让候选人问问题，确认其关心的范围，能否合理选择面试官的问题范围。3.工作业绩，取得了什么成绩，抠细节。9.考察沟通能力，候选人能否有条例，如第一、第二、第三，先总结，后细节。6.未来的规划，2-3年，具体的细节计划。7、多处给人感觉：这人表达出来的东西，和简历牛逼的印象，差距较大。自我心态：一轮面试，总体比较随意，只要不是太差的，都给了2轮机会。

如果你不能用一句话来描述你的产品基础价值，那么这个产品就过于复杂了。作为产品设计者，你需要关注一项任务，并让这一项任务做到尽善尽美，因为。对于互联网时代的公司来说，财力、精力、时间等资源永远是有限的，以有限的资源追逐更多的目标，很可能落得竹篮打水一场空。聚焦、聚焦、再聚焦，定义产品的核心价值后，然后检查每个特性是否与之相悖，并去处那些不符合的部分。理解了真正的核心价值后，再去寻找产品的附加值，打造更加“漂亮”的产品，让用户使用起来感觉更加愉悦、物超所值。本文内容，人工手敲，来自《互联网产品之美》。

敏捷设计强调的是团队成员的高度参与，目的就是要让大家统一认识，把团队的目标变成每个人的工作目标，并得到每个团队成员的认同，1、老外提出的很多概念、想法，可能是有一定的适用场景，也有可能是到了国内就“水土不服”，因为国内极度强调效率等特色化的东西。4、团队成员要有超强的适应能力，适应变化胜于按部就班，敏捷开发的特点就是快速，对于互联网行业来说，这点非常重要。总的观点：“新瓶装旧酒，换汤不换药”。通常来说，老板要的是：总的进度计划、里程碑节点、好的结果，提出需要协调解决的问题，任务细节没那个功夫关注。

专门面向一个产品领域；通过快速的产品迭代，保持产品团队的用户和市场敏感度；在迭代中充分关注线上版本用户的反馈，并且主动联系用户了解他们的困扰，在当前迭代或下次迭代时快速优化；我的感觉：好像说了很多漂亮话，啥好处都是敏捷的，能不能落地，是否适合团队，能否达成共识，值得探讨。每次迭代前重新调整需求的重要性，及时加入重要的业务需求和用户需求，将重要性不高的需求往后调整。对于功能的实现第一时间给出反馈，并能快速调整，而不会像瀑布式等到开发末期才发现实现上的问题。提升产品经理的产品感觉，提高技术团队的产品意识；

好好学习，天天向上

笔耕不辍

奋斗吧，少年

1、把90%的精力花在做好当前的工作，把10%的精力花在以后的跳槽上。2、集中精力做好业务、项目、技术本质工作，积极主动，不断进步。3、积极加强自己的相对优势，积攒自己的竞争力。

而且我们可以看到在追求一种表面性格的同时，对别人的赞美也是过度的追求，这样的一种表现，相信无论是谁都不会非常的欣赏，而且对于大多数人而言，很多时候自信是一种非常正面的表现，但是对自己没有一个正确的认知，盲目自信，会让很多人对这种人有一种不好的看法，让我们看到他们将自尊心扭曲，在追求那种表面荣誉的时候也没有一个正确的度。品牌实体店的业绩可能是真的，但是数据筛选有问题，业绩好的门店才看得上，社区店等所谓的模型，是有问题的，逻辑性不强，没得可复制性；2020年后的疫情是次要因素，对少数优秀门店才是重要因素。

如果用人单位，尤其是面试官，喜欢需要你这种风格的，且真正需要招人，招聘环节很简单的，就是个简单的交流，谈谈价钱，来不来。大学之后，自由了，经常思考，感觉学计算机软件，进度太慢了，啥时候才能写真正的商业软件，达到上班赚钱的地步。但是，长期形势肯定不妙，内部信息化的系统没钱途，然后找了个机会，异动到了京东商城这边的某个部门。调整自己的心态，摆正自己的位置，做好自己该做的，不做不该做的，在职场里，不断增强自己的核心竞争力。相对来说，总结使人进步，这句真章简单多了，非常好理解，也很容易执行，就看是否落到实处。

不想遇到问题，不想处理问题，只想轻轻松松的过日子。：当遇到问题时，如果不主动处理，不第一时间处理，问题的影响范围可能会扩大；用户反馈问题给我 远不如 我主动反馈问题给用户，态度、体验、感受、性质是很不一样的。该需要处理的问题，早晚得处理。1、前端，增加各种静态判断，减少不正常的请求到后端2、后端，必要的参数检查3、后端，捕捉预期的异常错误，给用户返回提示。

举例：有的数据，需要做关联，打标记；但是，可能一直无法关联；不限制时间，无法关联的数据，越积越多。分页查询，全量查询，无效数据太多了。额外条件：createTime创建时间1个月内的。isForce=1，不限制查询条件，不限制状态等。业务条件：比如 状态为running的数据。

有3句话，深深地刻在我的脑子里，这里说下我的理解。

具体到本文相关的，我个人 基本不用CURRENT_TIMESTAMP ，timestamp，只用DateTime，createTime、updateTime，都是Java代码手动设置。认真学习了点，比如知乎文章、大厂的做法等，简要总结个人理解：数据库，只是作为持久层，确保数据准确，存储过程、视图、复杂sql，甚至普通的联表查询等，N年以前，我比较好奇互联网公司（BAT）用的技术和普通公司有啥不同，数据库怎么抗住那么大访问量的？数据库，干好一件事就行了，其他的：ES、Redis、业务拆分等各种手段搞定。

工作繁忙，随口胡说；接近胡说，敷衍而已

残酷的现实压力下，归根结底，还是靠人的主观能动性、充沛的体力、稀缺的耐心、无所畏惧的付出。经常讲，要站在用户角度思考问题，要考虑功能的可扩展性，代码的健壮性、安全性、可读性。当疲于奔命时，用户体验的“感同身受”，就成了奢侈品。代价是时间、精力、精气神。

数据转换的事情，谁来做？

上述代码的逻辑：查询A表所有，包含了绑定关系的用户，然后根据此关系map去刷新B表冗余的id。那么，实际代码：只重新更新B表的 B 10 - A 12，漏掉了 B 11 → NULL。从查询的角度，B表维护A表的id，方便B表数据快速关联查询到A表的id。但是，没有当前跟进人，实际上需要把 当前值更新为 NULL，或者0。只要有一丁点未知的事情，被有意或无意忽略了，就埋下了灾难的种子。A表和B表，维护了关联关系，互相冗余了对方的id。从信息的简化角度，A表维护B表的id即可。逻辑推理，考虑所有的可能性。

有的bug确实不常见，全都修复，费事费力。真实用户，几乎不可能这样故意给自己找麻烦。