@PinkRabbit 如果面试通过的话，一周内应该就会发 offer 了。如果刚投递简历，可能会等几天先筛选一下。

考虑来豆瓣吗？ https://v2ex.com/t/782236

@ZhaoHuiLiu 哈？没太明白是什么意思，就我的周边的同事来看的话，30 ~ 40 岁有挺多，但是更年轻的同事做的也都挺好啊（精力充沛、视野开阔，让我这种老油条倍感压力，哈哈哈）

可能你说的问题一些其他厂有，但反过来看，其他厂也不乏三十几岁就因为拿了股票而财务自由的啊。而且实话实说的看，加班多的大厂，工资确实也高啊，这个看个人选择吧。

如果要扯劳资关系、资本主义对工人的剥削的话，我确实不太了解，而且感觉也不太适合在这个招聘帖子里讨论 : (

反正就我个人来说的话，打工嘛，开心挣钱最重要 : )

@PinkRabbit 可以，欢迎投递简历！

@ZhaoHuiLiu 不好意思，没太明白你的意思？我想你大概是想问，“为啥公司留不住人？”

如果是这样的话，我来回答一下哈；

大家出来打工的，离职换工作是很正常的现象，换工作理由也并不一定是“公司不留有能力的人”。

我个人感觉离职的话，可能更多时候是公司能够提供的东西和个人追求之间出现了不匹配的情况：比如想留更多时间给自己和家人，但是公司狂加班；或者想拿更多的薪水，但是工资上涨的有限；还或者是厌倦了北京的生活，但是公司又不会搬到你期待的城市；对于工程师来说的话，还有很多是个人技术追求难以在目前的业务中实现落地等等。

这些都会造成离职，个人感觉单纯用「公司不留住有能力的人」这个理由把锅扣在公司头上，有点偏颇。

再说回来「有部分十年以上的代码，对于考古爱好者来说，在从代码仓库里，你能看到近十年来前端领域发展的路径」这句话；这句话首先是想说明「我们的工作中，还在运行和维护一些上古时代的代码」这个事实；其次是对于一些工作时间没那么长的同学来说，有时候其实挺难体会为什么会出现 Angular/Vue/React，又为什么会有 AMD/UMD/CommonJS 这些东西，以及没有 Webpack/Rollup/Vite 时，前端的工程化是怎么做的；这个时候可以看看以前的工程师在这上面的探索，或许能对理解这些东西更有帮助。

写了一大堆，不知道是不是你想了解的，如果不是的话，请原谅我这么多的废话 :(

@ycr6708536 具体薪资，其实我也不太清楚...不过根据我个人的感受而已，总包相比大厂肯定是略低一些，但是如果算时薪的话，反而可能会更高：）

@xxxxtoto 确实也是很少招人，前端这边最近两年差不多每年能有一个职位吧（最近两年招人频率算是比较高了）；工作氛围的话，可以提供几个关键词「很少加班」、「工作范围不设限」、「自主驱动」；

@james504 哈哈哈 这个估计比较困难…不过如果能装回 6.x 版本的话，应该还是可以继续使用的

弱智需求，面对这种需求，建议 TA 想想为什么浏览器、各家操作系统的滚动条没这么设计。
如果 TA 实在觉得自己确实牛逼到秒杀所有人的程度，建议直接说 “不给做”。

三亚吧
找个临近海滩的酒店呆几天挺不错

可能是技术面试官不知道怎么开口让你离开...

@BoringTu 我认为这不是个人原因，更不是有没有「权力」管后端的问题；
恰好是因为人员流动大，所以更应该把文档和类型补充清晰，毕竟「今天流的汗，是前人脑子里进的水」；
还有所谓要求的问题，有些事情对的就是对，错就是错，如果觉得有用，当然可以提出要求，如果别人不改，你可以自己上手改；老项目可以慢慢改，但我觉得不需要因为所谓的「以前就是这样」，所以要一错再错下去；
再换个思路，其实现在很多工具已经支持直接从 api 导出文档了（比如 swagger ），试试新工具，说不定可以更好的提高效率；

@BoringTu 对，就我个人而言，如果明明是 int，但是文档里写成是 string，这个几乎是无法容忍的错误；
如果是合作的同事觉得这个甚至不算什么问题，那我肯定是非常难受，甚至难受到回去帮他修正文档 or 离职；

还有一点，如果前后端都用 ts，可以省掉很多对接口的工作，大家直接甩 interface 就好了；对于后端非 node 环境，其实也有解决方法，如果后端工程师会使用类 marshal 的工具来序列化输出的话（比如用 Python ），直接看 schema 写 interface 也不是什么难事，如果你喜欢，也可以把 schema 走一遍 ast 直接生成 interface ；

总之，我个人感觉如果前后端的合作者都对输入 /输出有明确定义，很多时候其实不用文档，这样也能减少很多沟通成本。

就我个人而言，现在基本上所有的项目都转向 ts 了，主要是以下几点考虑：
- 比较偏向业务层面的，用 interface or type 很方便跟 api response 同步
- 比较偏向 lib 层面的，因为大家都用 vscode，参数 /返回 都严格定义了描述，即使文档比较简陋，其他人也可以很快上手

很多年前做过类似的功能，个人感觉最好的方法是自己写一个针对算式的解析；
这样更安全也更可控，还能兼容更多交互。

比较复杂的类型建议写上 hints，如果还在 2.7，我觉得注释或通过 schema 验证可能算是个解决方法。
否则，一个嵌套多层的 dict / list，真的太崩溃了。

发了 30 个
还发了消毒湿巾、酒精等其他物资

前端回答你：做后端好

--------- 正经的回答 ---------

选择今后的方向上，可以先考虑考虑自己几年后是想在技术上深入，还是想在业务上深入，这可能比单纯的「前 /后」端更重要一点。

就个人经验来看，如果不进大厂的核心部门的话，前端的瓶颈期要比后端来的早一些，这时如果想在技术上更进一步，因为问题的开放性太大，并且每个分支之间的差距还挺大的，所以可能会难选择一些。

当然，不论是前端还是后端，做了几年，你会发现自己总会变成全干工程师。

日常上个线 /修个 bug，不忙且在电脑前，就顺手给弄了
基本上碰到这种事儿也花不了半个小时，也算帮了同事一个忙（毕竟如果真不是特着急的事儿，敝司同事真的很少在休息时打电话...)