银行 APP 里都有一些基金，理财产品，挑两个买一下，买个总钱数的 60%左右放那别管了

按照以往经验，这个问题虽然面试官问的是 1 到 100 的和，但是想要你设计的应该是个工具类，算法没啥好说的，主要是代码规范方面吧
抽取合适的方法(方法命名，参数命名)
比如提供合适的出入参
使用合适的数据类型
做好边界控制
错误时给出友好的提示

当然以上也是在楼主的经历之后推测出来的

下班十点后 基本洗洗睡了

你现在对于当前创业公司的期望和念念不舍，其实是对于以往投入的沉没成本的一种反应，正常人都会有。
但是要知道，沉没成本不应该对未来未发生的事情产生影响的。
所以，忽略掉那些“可能得到”的，再仔细考虑一下当前的这些选项吧

莫神乐宁

依赖一些框架，自己搞
要做比较严格的权限控制

公积金仁者见仁智者见智，只看自己短期利益，交的还是很好的，买房，供月供都挺好。
前面说公积金公司交的也是自己工资的部分，你可以先试试按照公司缴纳的数字加到工资上你能不能找到工作，能的话这个公司是不是也会交公积金？等你找到一个到自己上限薪水的工资，这时候公司交好还是不好？
至于说医疗保险，没病时候很多人觉得浪费，生病时候是真香。个人评价：该交。

774
看了下记录 主要是使用共享充电宝的几个记录

我们公司也试图这么干过
后来虽然听了课了，但是也就几个人实际操作过
更最后，没办法还是让前端做了一个平台出来，服务端的同学可以通过点点点实现

就个人经历和接触到的人而言，帝都确实抽烟的女性比较多
同时，在这些样本中，帝都本地的女性占更大一部分

已购
多谢

似乎希望语义化的都是前端，希望使用数字枚举的多数是后端
其实无非一个把枚举到语义转换的操作放在哪儿的问题，设计上肯定要分开，我可不想将来某个枚举改个名字要去改一堆的代码
前端想要后端做好，我直接展示；后端觉得枚举有了，返给你 key 值你映射一下有什么难的嘛
其实，对于一个量级比较大的服务，夸张点以谷歌为例，每天处理的空格的体积都非常大，如果返回去一堆汉字，那占用带宽更是大的多，前端 cache 一份枚举的缓存，针对枚举的字段客户端使用本地 cache 直接转换不挺好么
另外，如果这个枚举在客户端有需要处理的业务逻辑，到处 switch 或者 if 淘宝、京东，不觉得很 low 么？反正如果后端用这样的枚举如果看到绝壁要骂人的
这样涉及到不同环境，多个语言等情况，比较原始的类型比较安全，基本能始终保证统一，英文字符串也比汉字要强一些
最后，我是后端 🐶

问下中软国际那边有没有机会直接过去电网，如果有的话，这个还是有点香的。
如果不能，那就教育。