双向选择问题。
IT 行业这些年从 C++往后，编程语言的入门门槛其实是降低了的，古早点的编程语言基本都是 C++和 C 做底层，然后屏蔽掉部分底层工作后，创造一个新的编程语言，这样可以方便开发人员关注应用本身而不再关心 C++和 C 这些技术细节。

这也就导致当你去讨论应用构建的时候，大概率不会接触到 C++和 C 这一类的开发人员。
当你去讨论语言本身的原理的时候，你大概就会遇到对 C 和 C++比较了解的人。

像游戏引擎、AI 框架这些对性能要求高，业务场景相对固定的时候，C++能达到其他编程语言无法比拟的速度，就会再次遇到 C 和 C++。

然后。。。回复里面说 C++冷门，是认真的吗？好好看看多少语言是基于 C++做的解释器或者编译器。。。

单纯用过 PG ，没做过深入的运维。
schema 和 db 相同和不同点倒是能说上几个，太深入的俺也不是很清楚。
1. pg 备份和恢复的时候是可以根据 schema 操作，也可以根据 db 操作，这个区别不大。
2. pg 的配置 pg_hba 里面可以限制 ip 和用户访问 db ，这个无法做到 schema 级别。
3. 跨 schema 查询很容易，跨 db 查询的时候需要 dblink ，需要额外的配置。
4. 不同 schema 数据文件是逻辑隔离，相同 db 的数据文件是放在一起的。 不同 db 的数据文件则可以分布在不同的硬盘上，属于物理隔离。

8700K CPU 没有大小核，加个水冷满负荷跑。可是我只有 64G 内存，看主板说明可以上到 128G ，内存频率是 2133 ，自带集成显卡，全套下来不到 2k 。

@rustnj 这个吧，刚毕业前三年的小伙子，找个大平台给简历镀个金是最好的。。找不到的情况下就学习老板是怎么做成老板的。。随时准备摆脱老板自己单干。。。反正年轻，赌得起。

看情况其实。
1. 假如工作的内容确实能增长自己技能，做的东西也觉得还不错，就先做着，然后时不时跟老板诉苦说工作强度很高，这里抽不开身，那里忙不过来，反正就是喊累，工作强度高啊之类的，让人知道你做的很辛苦，千万别蒙头干活不喊累。

2. 假如做的东西不靠谱，也没什么学习的地方，就直接骑驴找马了，有好坑位就果断走人。

税务提出来的，可能是跟税收减免相关的，税务这玩意没弄好，被认定是故意的，那是可以把税务部门的审核人员给送进去的。。。。这人家怎么可能随便操作。

老菜鸟路过一下，跟 OP 差不多年纪，完全没有这么厉害。

个人感觉 kubenetes 拼错没什么问题，kuctl 拼错才是问题。

这个情况见仁见智的感觉，期待 OP 最终给个结果，我也很好奇。
目前就是两个方案。
1. 接受当前公司赔偿
2. 仲裁

方案 2 里面，仲裁结果公司不认可的话是可以提起诉讼的，第一次诉讼是一审。一审结果对方公司不同意，好像可以二审，二审就是最终审理。

我没记错的话，这种民事的金额不大的，貌似排队要很久。。计量单位应该是月。

其他公司我清楚，之前我司在发招聘的时候就有一些规律可循。

薪资范围越小的，不如从 20k-25k, 20k-30k 这样标，一般是对这个岗位的技能组成和经验是有非常明确的要求，所以很容易推算出这个岗位的薪酬范围。而且这类岗位一定是由具体的项目组才能提出来，也就是项目组会给予明确的信息，信息也包括多长时间内要招到人，HR 在这种情况下，不会无意义的扩大薪资范围，去收集额外的简历增加自己的工作量，靠谱程度很高。

标出 20k-40k 这种的都是报着捡漏的心态招几个，这个经验和技能跨度太大了。

因为大一点的公司每个部门都是有年度预算的，招人用多少预算，每个部门都会自己算一下的。
用人预算这里。从 20k 到 40k ，有点规模的公司都不会让你的预算直接 double 的。大概 30%到 50%的区间浮动是比较常见的预算范围。当然我也不能排除有些公司就是这个风格。。所以可以做个参考。

@NightFlame 看看工程类的书，纯看技术类的解决不了焦虑的问题。像项目管理相关的，软技能 这种书，然后一些市场营销之类的经典书籍都可以看看。。看多了就会觉得，技术之外其实还有更多的内容要了解。。。

这个真实，我曾经也为此焦虑了很长一段时间，各种看书、学习、报各种课程。
最后收效其实一般。。
我现在只能把这个问题归结为广度和深度的问题，这两者是相辅相成的。

当单独追求深度达到一定程度时，会觉得自己会的技术栈过于单一，没有足够广袤的视野，明明有成熟的方案，结果发现自己在哼哧哼哧的从头写，结果还不一定有别人的好。

当单独追求广度的时候，又会觉得自己的技术不够深入，很多原理不清楚，遇到特殊问题的时候很抓瞎。

我给自己的最后安慰就是，深度是需要的，广度也是需要的，两者相辅相成，目的是要形成自己的技术知识体系。
这一体系是为了帮我理清各种技术栈的优劣，形成一套客观的评判标准和架构思路。

比如说按照项目管理的角度去思考技术带来的风险和价值，用时间、质量、成本去评估自己的架构设计是否合理。

对于技术优化方面，重构这本书里面有一句话 “过早的优化是万恶之源” ，追求性能的时候加上这句话看看。。

对于评价一个数据库的优劣的时候，先看看评价指标有哪些，再用 docker 快速模拟一个环境，横向对比不同的数据库，把模拟的场景的尽可能贴近项目中的实际场景，然后对比看看。。这样大概能自己一个心里预期。。

这俩因为是开源且免费的，使用时间也是最久的。。
实际上技术部门在大部分公司地位并不高。
都处于完成工作是应该的，完成的好不好不重要。重要的是不能出问题。
出问题就扣 KPI ，这种情况下，选择稳妥且保险的策略是最优选择。

先明确一点，要钱是目的，仲裁是手段。
我记得成都是有劳动仲裁相关的法律咨询。
建议先咨询下专业的法律意见，准备好要保留的证据，证据准备好之后。
假如奔着双倍工资去的。直接申请仲裁。
不然的话，就先跟老板开诚布公的谈一次，看能不能直接给钱走人，好处就是省事。

严格来算工作时长的话，996 的性价比其实很低。。。。

上家公司某国企外包，早上 8 点半打卡，5 点下班，但是不打下班卡，有事和甲方打个招呼就让你走。。。
国企领导有事找你，没事随便你干嘛。准时上下班，周末没人找。。。
没有免费停车。。。后来因为搬地方实在太远了。。换了个新工作，996 ，简直了。。。

@polariszc 做这个 7-8 年的人员的平均技术水平

能成功转过去固然是好的。
可以成为最懂业务的 LLM ，也可以成为最懂 LLM 的业务开发。

实际上可能要付出数倍的努力才能达到平均水平。

“沉没” 的大多数