@maxmin
其实是蜻蜓点水，都接触过一点，但掌握得都很浅。
这次调整也是想找个方向深入下去

@woffee
简历里个人信息太多，抱歉不能分享了

@doctortao
不好意思回复漏了😅，回复在 #53

@byteli
待遇相关不能透露，见谅哈

@fuermosi777
感谢提醒！我这边似乎没有见过类似的东西，昨晚也有朋友提醒我之前 zhihu 上有回答面经的答主被回收 offer 了，所以赶紧把文章发给了 HR，他们确认没什么问题。

@yizhimamong
@Wisho
@lynskylate
心里已经有决定了，不过明面上只拒了头条，等确定之后我更新在下面吧

@xx19941215
每场面试完都先把面试过程简短记下来了

@yylucifer
是的, Prometheus +Alertmanager 这套警报偏向给运维用, 用户的学习成本挺高的, 基本难以自助式
Grafana 本身的警报模块足够傻瓜, 可惜功能太弱了, 一条规则无法追踪多条警报状态是个硬伤

一键视图不知道指什么, 能说明下吗?

@Jven
警报规则没有比较好的开源项目可以解决, 就用 prometheus 自己的解决方案了

@yanbc
Bear 缺了个 Vim binding, 有点蛋疼

从开发的角度来说, 我认为主要是应用交付层面的 Separate of Concern:
无论什么应用, 都会至少依赖 kernel 与 library, 楼上已经说了 kernel 和依赖库的多样性问题. 而再往上还可能依赖环境变量, 外部脚本或 Binary (比如 imagemagick). 在容器化的交付方式之前, dev 只交付代码, 后面的一切 ops 来做. 但是 ops 发现自己 hold 不住了, 毕竟只有 dev 才最理解自己的应用需要怎样的环境与依赖.
因此我们需要一个 docker (容器)这样的交付抽象, 一切外部依赖与环境都由 dev 定义好, 再交给 ops 一方 (ops 团队或者 PaaS 厂商) 来统一编排.

@Moming
感觉自己太菜了, 看到 rust 项目的 Help Wanted issue 都不太好意思下手

@trait
不能更赞同, 跟链表斗争能很好地检验对 borrow checker 的理解...

@gimp
感谢鼓励

@Sparetire
一开始我也是这种感觉, 后来发现 Rust 写链表确实是个坎, 可以看看 [Learning Rust With Entirely Too Many Linked Lists]( https://cglab.ca/~abeinges/blah/too-many-lists/book/)

go 的语言哲学已经够强了, 写出来的代码千人一面

apollo + go client