一样的 CRUD 项目，你作为一个技术人员做了什么来提升这个项目的效率和 /或价值？

如果有，那就介绍一下，如果没有，那不如从现在开始尝试起来？ 微小的重构也好，换轮子也罢做轮子也罢，甚至是整理一些文档，都是几周就能见成效的事情

另外，过 HR 反而不需要这些，过 HR 你要的就是关键词，包括知名公司学校的名字和技术 /框架的关键词，堆起来一般命中两三个对方的需求就够了

忘记是 underscore 还是 backbone 了还列举了 2 ／ 3 ／ 4 ／ 5 个参数的 case 呢 23333

说没有关键字我第一反应就是 brainfuck

告诉老板他看到的是前端服务器

裹上鸡蛋液和面包糠炸至金黄

@fov6363 已经那么干了的话先让他认识到问题，然后 feature 分支直接 reset 回到 origin/feature 即可，如果 D' 之后又开发了东西，rebase 回去

@fov6363 我觉得你没看我的回答

顺便，这个过程的实际操作是 git fetch && git rebase （取代 git pull ），现在 git pull 增加了 `--rebase` 开关可以直接用

Bob 在已知 github 的状态的情况下，不应该做这个把 feature 从 D rebase 成 D'的操作（已经 push 到 remote 的 commit 不应该 rebase ），更不需要解决 Anna 的什么东西（因为 Anna 的 E 压根没有 push，Bob 也不可能得知 E 的信息）

rebase 更多解决的是 Anna 线 push E 到 github，Bob 同时（未拉取最新修改）在 D 上 commit 了变更 F 后，发现 push 失败

此时用 rebase 把 ABDF 变成 ABDEF 再 push,使 feature branch 的结果为一直线，避免增加 merge commit

湿布擦吧，等更好的

考察能力，而非知识
考察经验，而非经历
试探对方能做什么，能力边界在哪里，是否能够突破，而不是遍历对方不能做什么，在能力边界八丈远的地方刁难对方

我觉得面试官不好当的一个很大的因素在于，作为面试官太难得到对面试质量本身的反馈了，面试和招人本身频率就低，入职与否，入职后表现和面试本身的质量相关性不高（除非入职后发现是个雷，那很明显是面试需要改进），更别说反向来说，筛掉的人是不是有面试不合理导致的误筛几乎不可能得知，要改进提高面试能力，更多只能靠自己 YY

个人更倾向反过来，代码生成文档，毕竟让程序员写代码和让程序员写文档的难度差了不止一个数量级

另外，想换节点可以趁早换，或者 at livid 处理，换节点重发一样的帖子不好

你要和 redux vuex 抢饭碗，或者是想整合一起用，凭啥，建议在 readme 第一屏内显著写明白

另外点进去看了看，出 promise 不 return 造成 uncaught reject 的 sample code 不敢恭维

暂时先不 star 了

我现在基本形成了本能反应：看到这种开头一张图，内容里面大量副标题和加粗的公众号文笔 就自动判定成垃圾水文，速读垂直扫几眼直接拉到底，看到一排链接，嗯，枪毙，再见

SAP?

想去互联网公司趁早，等你简历上有了两家三家非互联网的公司，再跳阻力就大了，可以再找找

不想去互联网公司的话，autodesk 风险小，另一家你得自己去调研确认是有核心竞争力而不是风口上的裸泳公司

对于高端 /稀缺的职位来说，一家公司在招聘换句话说有职位空缺这件事本身就是某种意义上的商业秘密，猎头的一个作用就是保护客户公司的商业秘密，尽量避免无谓的信息泄露

当然也有的是虚张声势，类比中国有 5 所 top3 大学，10 所 top5

嗯嗯，算力分布好做，数据分布难做，事务分布 (还要自动地，业务无关地) 那是地狱难度了

window tidy / mosaic