@meshell 解决思路总归不完美，我会先问背景和前提条件再给出最简单和更完善的方案，最后来一句“实际情况远不止这些要依据具体的业务场景来考虑”，不让对方知道我的上限。

对付数据结构和算法可以用我们熟悉的语言来实践加深印象。
引导面试官往自己会的技术提问。有一次我被问到二叉树的问题我就大概答一下然后说“我在实际开发中用得不多主要是 mysql 索引优化和 redis”于是面试官开始问后面的内容，这些背几十遍了信手拈来完全在我的掌控之中。
背面经没有意义，面试时会根据你的简历提问而不是模板所以简历不要吹太猛。

互联网 CRUD 的领域不行了，新能源、AI 、电动汽车、尖端武器、芯片、高端制造业有很大的发展空间，然而换到新领域需要系统学习新知识。
现在不是没岗位而是体面的工作太少，高工资必然带来高强度和巨大的压力，轻松加班少的岗位不在市面上流通而且离职率低。
目前招聘最多的是销售和运营，中小型互联网公司研发水平不够产品没什么竞争力只能靠这俩勉强支撑了。

我觉得八股文问太多不利于筛选优秀人才。用八股文来评判能力强弱太片面了会导致到了入职才发现存在技能缺陷再辞退掉，对公司和候选人不负责任。以前自己面试别人会先分析简历结合当前项目需要和未来的规划来考查基本上可以保证胜任工作，八股文占比过大只会招到刷题高手。

公司在创业初期没啥名气只有关系好的亲朋好友才会来帮忙，做起来后最初的业务成为核心业务，老板信任他们因而赋予更大的权力形成嫡系文化，这个国内外都有只是原则和人情哪个优先考虑的问题。
OP 想表达的可能是“特权阶层”：无视规章制度享有其他人没有的特权和待遇，公司无论多困难他们的生活质量绝不能下降，而这些人通常是公司的嫡系，这是老板过度信任缺乏监督所致。嫡系不全是坏人相反可以在公司遇到困难时稳住局面，危害最大的是特权阶层，公司的财富被他们掏空还要架空老板。

以团队为单位来考核加强团队协作，取消强制比例。
BUG 数量改为“逃逸缺陷率”，对于 BUG 、生产事故的认定要有标准和分类。
完成的任务数改为“计划完成率”。
取消协作人评价，这个争议很大想做掉某个人太容易了。
取消无法量化的维度如“企业价值观”、“团队协作”、“工作积极性”、“沟通流畅度”等。
建立独立监督部门确保绩效考核结果公平公正，该部门所有人应与利益相关者构成回避关系。

我觉得绩效考核应以业务目标完成进度作为考核的重点，考核维度通过公式计算得到减少人为操作的空间，信息透明加上 leader 、组织和员工之间相互信任才行，还要给员工申辩的机会并严惩恶意操作的人，没有绝对客观公平公正只能做到基本客观，即使指标合理还有组织架构、职责、小团体等诸多因素，完美的制度也要有三观正的执行者才能落地。

模块化拆分任务提高内聚性让任务并行执行各司其职，代码更清晰。
统一编码规范便于维护和阅读。

不定期重构，清理技术债务。

非必要不更改框架内核。魔改会引入潜在的风险，我见过把一个框架内核改掉限制了只有新增、更改和删除记录才能使用否则无法提交和回滚导致无法正常写出优雅的代码。

减少人员流动，在职越久对项目越熟悉能写出高质量的代码，别整末位淘汰、人才九宫格这些没用的玩意儿害人害己。

优化需求，明确需求的边界。我见过最有印象的是 CRM 做成 CRM+财务系统+中台，边界不清晰的奇葩需求流入系统一定不符合业务需要理应被丢弃和转化。

保持可持续工作节奏，给予恰当合理的开发时间。

关注交付正确的内容而不是尽可能多的交付。

小网站 PHP 就行

PIP 打死也不能签，注意保留证据等仲裁，PIP 不通过坚决不写离职申请，这东西就是公司非法辞退又不给赔偿的套路，只要你不主动离职就能坐实非法辞退拿赔偿，不胜任工作经调岗培训仍不胜任才可以辞退，不签已经说明你不承认而且没有给公司造成损失，PIP 不通过也算是非法辞退。

我之前被套路签 PIP 后发现不对劲想要翻盘很难，领导天天拉着 HRBP 和我谈话，其实 PIP 那些东西都是鬼扯与事实不符，即使摆事实讲道理 HRBP 还是说“我只听领导的反馈，对于你的说法我们持保留意见”以至于被迫自己辞职，之后才发现那份文件有时效只要拖到截止时间后就可以赖着不走继续斗智斗勇。

OP 的做法不妥不能直接摆烂要多沟通寻求帮助让上级去协调，遇到蛮横无理的人得不到帮助才考虑离职，有时候让你加班是为了测试服从性，如果你有异常举动领导会认为你不服从管理肯定被开。需求不合理就更要沟通表明态度证明实现代价过大不值得做，只说不合理会被认为偷懒不想做。我接过一个不合理的需求本来没必要做，PM 被我反驳到没理由了就说“这是领导的考量属于商业机密”最后也只能做，在强权面前我们很脆弱的。

现在公司可以随便换人不怕你待不下去，以前试用期任务很少又简单到了转正后任务量增多变难，有个循序渐进的过程让你从磕磕绊绊逐渐到独当一面，如今一入职就要求产出达到老员工的 80%转正后为老员工的 100%甚至更多，刚开始做任务一卡一卡的多问几个问题就直接辞退说你业务理解能力太差，甚至你做得好好的被人用试用期的协作人评价联手做掉都有可能，你的同事都可能把你推入万丈深渊只要他们拉个小群搞秘密行动就行，所以不要太冲动。

大多数人习惯 try catch 捕获异常肯定会觉得 go 的异常处理不方便。go 的异常处理比较麻烦但很详细可以知道是哪个步骤错误，阅读更清晰。try catch 捕获异常要考虑 exception 的从属关系，而且抛出异常也不一定知道是哪里执行错了还得看报错的文件、所在行，需要借助错误日志定位问题。

我也遇到这个问题，找到飘红的文件根据代码补全提示重新键入一个方法即可

先熟悉基本业务流程，借鉴“用户故事”的三要素来理解需求，知道它们是给谁用的用来干什么的怎么运作，对于复杂的需求要给出流程图。
需求风险发现能力靠业务和项目的熟悉程度即可，越熟悉对风险的感知和预判能力越强。
谈判能力要结合具体的业务和应用领域，关注竞品动态，还要学习商业谈判技巧，产品和管理知识，要让对方知道需求实现的成本、代价和潜在风险，意识到这不是最优解决方案从而改变原方案或推翻重新设计需求。
有一次系统频繁发版却无人使用但 PM 仍说是“业务方反馈的”必须开发，我问 PM 为什么这么多功能没人用？没人用哪来的用户反馈？发布后是否有给员工讲解？ PM 说发布后就不管了，于是我提出发布后必须讲解所更新/添加的功能用法并更新系统使用手册后就有人用，从此再也不敢随便提需求，这个涉及到管理上的工作流程优化。
不过谈判的风险较大，有时候我们觉得需求很奇怪不只是业务上的考量还有 KPI 作祟，故意设计复杂一点让更多人获得绩效，水可能很深处理不好容易给自己带来危险。
至于楼里提到的“产品经理懂技术更好”我不太认同。懂技术的产品经理如果不能跳出技术思维会给程序员带来许多麻烦，业务上的任何问题都想用技术解决，不懂得优化业务流程，挖掘真实需求。

能领的尽量去领，只要 HR 做社保减员登记为非个人原因主动离职就可以领，不过有些公司很恶心不管是裁员还是解雇一律在减员登记时写成“主动离职”就领不了了。

考核指标不合理加上组织架构畸形造成的。
有一次我遇到发送通知需求：原本只需用 email 模板并替换模板变量即可发送却做成图片生成列表，还要缩放，字体大小适配、压缩等并上传文件最后再发送，再做一个定时任务定时清除已发送的文件。