因为有些要求感觉实是太过奇葩，收集下来娱乐下大家。 代码规范要求 要求代码必须要放在一行上面，导致代码上面有不少行甚至超过了 1000 个字符。 规范解读 就是有时候代码过长，我们会折行增加可读性，最简单的一个例子就是 object builder 设置值。奇葩的要求是这个代码必须要放在一行上上面。 奇葩解释：因这就是 Java 的编码规范和便于 IDEA 语法分析。 如果你的代码有折行，PR 都全部拒绝通过。强制使用 IDEA 2 次格式化把代码尽量放一行的功能。 拒绝使用临时变量增加代码可读性。一些复杂代码就会在一行上超过上千字符，屏幕都需要往右侧翻 5 ，6 次 还没看全这行到底要干什么。 挑一个方法来看看：     这个方法被要求这样写以后，这行的长度是 682 个字符。 不允许折叠行。 看不明白这行要干什么？看不明白就对了，这个根本就不是人读的东西。   https://www.ossez.com/t/topic/14475

正如我们常说的公司在大规模裁员之前是有很多征兆的，不是就拍怕脑袋决定的。 这次公司的裁员真的属于教科书级别的裁员，因此觉得记录下公司整个过程的时间轴是有意义的，希望能够给所有朋友有个参考。   也很想知道的是，如果是你，你会选择在几月份开始积极找工作呢？ 欢迎在下面回复喔！ 2022年1月 被猎头以高软件开发工程师的职位挖到这个公司的。 不到一个月被提拔为 Team Leader，负责组建自己的新团队。最开始的计划是团队有 8 到 10 个人左右，虽然不大，但是也算可以干点事了。 2022年2月 团队组建完成时只有 5 个人外加一个不属于任何团队的软件架构师。 同时这 5 人中间还有一个人是东欧开发团队的，我们负责培训这个东欧开发团队的成员成为团队的 Leader，负责在东欧团队中创建另外的开发团队。 同时，我们被告知将会负责公司最重要的项目，因为这个项目已经被拖延了 3 月，无法继续进行。 随后的几个月项目开发都比较顺利，完全是按照开发计划进行。 向领导提出要为团队加人，领导也非常支持，并且面试都按照计划在进行中。 在这个过程中，只选择了一个中级程序员加入我的团队，其他人员面试的较多，但是很多时候并不符合录取条件，或者好的程序员要求过高，不愿意过来。 在 8 月份的时候，公司给我们提供了一个高级程序员，这个程序员水平还是不错，比较能适合开发，同时项目推进非常顺利。 2022年9月 上级通知我们，招聘在减缓，公司暂时冻结招聘。 如果我们还需要人的话，只能从其他团队进行调整，在这个时候其他团队也缺人，所以没有给我。 另外负责培养东欧的团队 Leader 计划已经完成，东欧团队成员从我们团队离开。 我们团队在这个时候还是出于十分缺人，任务比较重的情况。 2022年10月 项目正式上线，并且上线也非常顺利没有什么太多困难。 在项目上线完成后，公司还开了庆功会对我们团队进行了奖励。 虽然不是我们团队一个团队的事情，但是整个计划还是非常顺利的。 在项目上线完成后，我们和另外 3 个团队合并在一起来进行另外一个快速重要的功能开发。这个功能的开发要求在 3 个月内完成。 2 个 Sprint 以后，这个项目被在毫无预兆的情况下撤销，理由是法务问题。 2022年11月 创始人加 CTO 和 创始人加 CFO，2 个人在毫无预兆的情况下离职，公司一共 5 个创始人。 整个公司技术层面一脸懵，不知道理由是什么。 最后，在公司 All Hands 会议上给出的理由是，CTO 要选择继续进修，所以选择离职。 我们团队因为项目撤销，所以负责一些技术债务的清理和合并工作。 2023年2月 新 CTO 就职。 在项目上面我们继续进行技术债务的清理工作，在这个期间，我们团队中的唯一高级程序员被另用而离开我们团队。 在这个阶段，公司管理层给我们团队的评级为全美团队里面表现最优秀的团队。 就在本月，奇葩的架构师在完成一些基础类的设置后，开始全面在公司强推奇葩的代码规范，受到的阻力可想而知。 我会在另外一篇技术类的文章中列举一些奇葩的要求。 就在本月，我已经通知团队成员注意公司变化可以开始其他求职计划。 2022年3月 这里需要说明下 2 个人物。 2 个人都是 VP（副总），一个为加拿大人，一个为印度人。 负责开发的副总被在毫不知情和预先通知的情况下被解职并辞退（印度副总）。 个人认为这个印度的同事的专业素养还是不错的，要比和他同级别的另外副总（加拿大副总）水平要高。 加拿大副总，在印度负责被解职后，全面负责公司所有的开发，运营，方面的工作，除了测试。 需要注意下的是，奇葩架构师是加拿大副总招聘进来的，用来在公司对 Maven 项目进行重构。 举例一个奇葩的要求：所有 IntelliJ 有警告必须被修改。 如果有任何的 IntelliJ 有警告， PR 合并全部被拒绝，不管有些警告是不是有点奇葩，不知道有用 Eclipse 的公司是不是所有人都得跳楼。 如果你是程序员，从 Apache 克隆一些代码，你会看到上面有成千上万条警告，我们在公司上面提出过这个问题。得到的回复是：因为 Apache Commons 的包的警告被很多人证明这不是问题，所以不需要去处理。 2023年4月 因为和架构师的冲突和很多的不理解的奇葩代码规范，我们团队从领导那里得到是所有团队最差的团队的信息。 并且技术债务的修改，因为 PR 合并的阻挠，进展缓慢。 2023年6月 公司宣布大规模裁员。 所有东欧和印度团队全部解散，北美技术团队裁员 40%。 如果全部按照人数的比率来看的话，裁员比例高达 70%。 总结 从上面的时间轴我们来看，是不是每一步都是一个需要离职的信号？ 可惜我的拖延症把这些信号都给忽略掉了，事实上早在今年年初和架构师有冲突的时候就应该开始下定决心换工作了。 无奈自己的拖延症有点耽误了。 当公司出现有一些并不确定的信号的时候，从公司层面来看看，应该是经营和管理出现了困难，作为职员来说，需要提前做好准备。 如果你是我，那么你会选择在什么时候下定决心开始找工作呢？   https://www.ossez.com/t/topic/14472

从通知被裁员到今天已经有 3 天了。 这 3 天有过那么一点点焦虑。 是时候应该收拾收拾自己的心情再出发了。 找到原来 Git 中的代码库，上面有每次面试的记录，也有过一些吐槽。     今天把公司的文件都删掉了，保留了一些在公司日常工作时候记录的文档，也当做是一个历史的记录把。 虽然，在这个公司工作的时间并不长，也才 1 年 8 个月左右。 是时候收拾收拾自己的心情再出发了。   https://www.ossez.com/t/topic/14471

可能最近写离职的东西比较多，在网站上刷新闻的时候说是有一人因为才离职 1 个小时就被拉黑退群了。 为了保证来源的准确，原文的截图如下：     觉得上面的情况还挺有意思的，现就来说说离职拉黑在美国这回事。 公司层面 上规模的公司对用户的管理都会有一个标准流程的，这个用户的管理不针对个人是针对所有人。 公司对所有人的处理都会采用这种模式，技术层面上使用的是 LDAP 或者 AD，AD 是微软的产品，但是实际目的都是一个东西。 LDAP 是轻量目录访问协议，英文全称是LIGHTWEIGHT DIRECTORY ACCESS PROTOCOL，一般都简称为 LDAP。 对读操作进行优化的一种数据库，在读写比例大于7比1的情况下，LDAP会体现出极高的性能。这个特性正适合了身份认证的需要。 可以理解为 LDAP 是一个小型快速数据库，技术上我们会使用这个数据库对用户身份进行管理，数据库中的数据使用的树型结构便于日常鉴权的查找。 公司技术层面，离职的当天，完成和人事的最后沟通后，你的用户信息会在 LDAP 内被禁用，一旦用户设置为非激活，被禁用的话，所有相关服务，内外部网站，电子邮件等任何需要你用户名和密码信息的地方都会被禁用。 你的感觉就是离职会议开完了，账户马上禁用了。 来看看和人事会议结束后 3 分钟后电脑的屏幕：     实际上就是公司已经把你和 HR 的会议时间交给了负责管理 LDAP 的人，这些人根据你的会议时间设置了禁用时间，并且完成禁用。 有可能在禁用之前会和 HR 沟通下，你和这个员工的会议完成了吗？ 个人层面 平时保持一些同事的个人手机号码，很多事情是不方便在公司群里面说的，如果你想和同事保持联系的话，留有这些同事的手机号码或者单独加个微信就好了。 北美这边就是好的同事之间会留个号码，裁员当天如果来不及的话，就上 LinkedIn 找同事互相加一下，或者本来你们在 LinkedIn 已经互相关注了，知道谁被裁员得当天可能没有什么时间，当过程走完了后就上 LinkedIn 要个对方的手机号码并且通过手机或者其他渠道联系。 因为微信在这边用得不多，华人同事之间可能会加一个，其他同事多是邮箱和 LinkedIn。 说实话，公司的群里面并没有任何值得你留恋的东西，再留在里面也不合适。 对于规模以上裁员，美国同事之间也会建立一个曾经同事的群，并且在这个群里面分享下生活和招聘信息，主要是互相帮助沟通下，以便于大家都能更快找到工作。 微信群 因为微信群多是各个利益团队建立的，微信在北美这边本来就不是非常流行，所以对这种个人或者领导建立的群，这边没有太多需要修改的地方。 因为这种群从技术上没有 LDAP 的管理，所以退群或者不退群就是自己的选择了。 如果你加入的群还比较多的话，可能退出来还比较花时间，在这个时候就会出现上面说的那种，你还没有来得及退，群主已经把你踢出去了。 其实想想这个群主不就起到了一个手动 LDAP 的功能不？所以真心感觉把心态放开就好，反正也是要退的，时间问题。 怎么做才更专业 其实这里面有个心态的问题，本来很多平常看起来还不错的同事，怎么在这个时候这么不近人情呀。 事实可能还真不是这样，只是这事情做起来可能不那么好看，但还是有人要去实施不是，实际上还真没有什么。你不退他们也会让你退，当然发个消息表达感谢本意是好的，只是群都不在了还感谢谁呢？ 另外，一口气拉黑所有人，也感觉没有必要嘛。抬头不见，低头见，曾经的同事也有可能是自己以后发展路上的好友。 都说，多个朋友多条路，虽然职场上的关系在工作时候感觉都是小心翼翼的，但离职后，在公司内发生的哪些事情是不是已经变得不重要了呢？ 因为环境变了呀。因此，笔者认为保留一些朋友的个人联系方式，在需要的时候联系下，这种事情是可以私下说的嘛。 一口气拉黑所有人还是有点赌气了，其实自己也不需要赌气对不对？   https://www.ossez.com/t/topic/14469

警告等级【2 星】 这个项目的警告等级完全是属于可大可小。有时候招聘冻结可以算是 3 颗星，有时候也仅仅可认为是 2 颗星警告。 有关招聘冻结的定义和可能发生的情况如下： 在招聘冻结期间，公司通常停止增加新员工。然而，如果冻结被解除，企业可能会恢复其原有的增长计划，包括雇佣额外的人员。 各种情况可能导致招聘冻结，包括不确定的经济时期或企业内部发生的个别事件。当管理层冻结招聘时，公司员工通常会意识到；通常情况下，在经济放缓期间，现有人员有望保持或提高生产率。 上面的定义是书面上的定义。我认为中西文化在这个定义上面是有误解的。原因是中国的公司规模相对比较小，更多是老板一个人说了算。 美国公司这方面的行为比较规范，尤其是一定规模的公司，在公司经营比较正常的情况下，通常不会轻易冻结招聘。 原因是，公司本身需要保持一定的流动性，因为公司的员工可能有自然辞职，意外等各种情况，公司需要保留一定的人才储备，这个人才储备就是通过招聘过来的。 因此招聘冻结，就意味着公司在短时间内不再需要一定的人才储备，甚至对已有员工的离职和意外也认为有足够的能力去解决。 因此，冻结招聘在西方文化的语境里面就是公司的经营状况由增长转变为持平或者下降了。 结合这次我们的公司的实际情况，所有的问题就都是从冻结招聘开始的。公司冻结招聘的时间是在2022年的9月份。 在 2022年8月份的时候，公司还是处于积极招聘的状况，从经济学的角度来看就是从增量经济转变为存量经济了。 冻结招聘的时间 这里冻结招聘的时间长度也非常重要，如果只是短时间的冻结几周到个把月的时间的话，通常是不需要过度担心，通常可以结合其他信号进行观察。 这是因为，公司可能需要几周时间对公司内部进行调整，或者公司的经营方向有些变化，相关岗位不再需要太多的人，公司需要对这些岗位进行调整。 另外，需要注意的冻结招聘不是说整个公司的招聘都冻结了，而是只针对你的部门或者岗位。 比如说，我们的技术岗冻结招聘。 再结合我们公司的实际情况，从 2022年9月冻结招聘以来，公司有关技术岗的招聘就再也没有开启过，直到现在这次大规模裁员。 因此，如果对冻结招聘对我们这次的影响来看的话，这次应该的星级更高，应该到了 3 颗星 的水平。 对于中资公司来说，冻结招聘所占的权重并不是太高，因为中资公司的整个招聘流程还是相对比较随意。这里还是有一个比较大的中西方文化差异的理解。 可能还是因为文化差异，这次大意了。 https://www.ossez.com/t/topic/14465

如果想自己在裁员的时候是第一个知道的，并且打一些有准备的之战的话，下面的雷区一定要认识到。 这些雷区通常能够给你提供一些警告，因为本次公司裁员真的属于教科书级别的，以前都没有太当回事情，反正也抱着无所谓的心态去的，很遗憾上面的内容都一一验证了。 裁员对被裁的员工当然是有影响的，就算还算幸运留下来的话，也会有很大的打击，士气上肯定是没有以前那么好了。 下面的内容也参考了网上的一些文章，同时结合自己的实际总结出来的。 管理层变化 警告等级【4 星】 在未知情的情况习啊，管理层出现了非常大的变化。 我们公司的情况是在 2022年 11 月，创始人+CTO，创始人+CFO 离职。 一个公司只有 5 个创始人，其中 2 个创始人在同一天离职，这个意味着什么，你品品，细细品品。 因为 CTO 离职了，职位空缺了 3 个月，在今年 2 月份左右的时候新招了一个 CTO，这个新 CTO 我个人不认为能力有非常强的感觉，但是马上肯定就意味着要重组。 果不其然，1 个月以后，负责开发副总被解雇，对公司 VP 级别全部大换班和调整，保留了其中开发人员和测试人员都认为比较奇葩的 VP。 3 个月后，公司技术岗裁员 70%。 具体的时间轴，会在另外的一篇文章上写些总结。 另外，当被裁后，发现公司负责市场的总裁在 3 个月之前离职，目前已经就职在另外一家公司。 现金流 警告等级【4 星】 不管公司怎么说，资金是不会说假话的。尤其是对上市公司或者财务要求公开的公司来说就更是这样。 如果公司在 2 到 3 个季度内都没有办法达到财务预期，那么裁员就是要快发生的事情了。 投资人是不会让公司在不赚钱的情况下不停的烧钱的。 这个对应的是人事变动，如果负责财务的团队或者主要负责人有非常大的变动的话，那么说明公司的资金状况可能并不是非常理想，这个时候要小心了。 同事离职缺勤增加 警告等级【3 星】 如果你发现近期，你身边的同事离职增加了，并且很多和你关系还不错的同事都在偷偷开始找工作的时候。 这个你要小心了，可能大家的感觉都差不多。 因为现在多是远程工作，最大的体现就是各种会议的时候同事通常开始请假，并且总有各种理由不参加一些本来安排好的会议。 如果你找你的同事要求处理一些问题的时候，通常要等更长的时间才能收到回复。 这种情况更多的是你的同事在参加各种面试，没有时间同时照顾 2 个会议。 如果有时间冲突的话，他们肯定是选择更加重要的会议，换你不也这样吗？ 和上司沟通的时候提供信息更少 警告等级【3 星】 很多人和上司都有一个固定时间的 1对1 沟通。 在和上司进行 1 On 1 进行沟通的时候，你会发现上司提供给你的有关公司的信息越来越少，每次都好像有什么要说的，又没有什么要说的。 这次，我没有把这个放在裁员的考察之内。 原因是：我们公司这次的裁员规模和比率，连我上司自己都被降职减薪了，他自己也不知道要发生这些事情。至少他自己是这么说的，我也姑且相信他一下吧。 他说，没有任何人找他对他的手下做任何评估，我相信这是真的。因为按照这个裁员规模，是不需要对要裁的人进行任何评估的。 裁员手法就是砍项目，降低到最低可维护水平。 项目并不重要或者价值不高 警告等级【3 星】 公司安排的项目对公司来说并不非常重要，或者说并不是影响运营的，更多属于优化这种。 另外，你的项目完成后，公司并没有后续项目让你继续进行。 我们这次组被裁，因为我们做的是财务和支付处理流程。这个流程现在已经有一套 PHP 的版本在用，虽然用得很难受，但是也是可以用的。 在处理财务和支付流程的时候，他们还是手动的方式导入 CSV 文件来进行处理，我们需要把这个流程做成自动化。 如果公司业务在高速发展的时候，这个需求是非常紧迫的，因为我们可以替代 3 到 4 个财务人员的工作，并且可以降低错误。 但是，公司业务出现问题的时候，这个功能改进其实就没有什么太大价值，或者意义不大到没有任何价值。 因此整个团队在这部分被处理掉，这个很正常也可以理解。 被提示需要改进工作 警告等级【3 星】 北美这边有一个 PIP。PIP，全称为 Performance Improvement Plan，中文为绩效提升计划。 据闻 PIP 起源于亚马逊，意为针对业绩排名靠后的员工进行绩效辅导。进入到PIP中，上级会给员工制定一个绩效目标，员工需要在特定的时间里去完成这个目标，这个时间通常从30到90天不等。 当员工在 PIP 中出色的完成了目标，将会留下来继续工作，否则将面临被辞退的命运。 据悉，亚马逊一年会有两次比较大规模的员工绩效评估，绩效排名在后10%的员工都有可能被放进PIP名单当中。 PIP名单由上级主管决定，一旦进入到PIP名单，若想要从名单中剔除，则需要部门总监甚至VP的批准才可以从名单中移除，而不是由主管来决定。 PIP中的绩效目标要比正常工作的业绩目标稍难，甚至难得多。 由此可见，进入PIP的业绩提升计划本来就难，从PIP出来还需要层层领导审批，无形中又增加了走出PIP的难度。 如果你被 PIP 了，建议就是稳住工作的同时，马上寻找下家。 我们组因为新的奇葩架构师的问题，被 VP 提示过 1 次。因为这个新来的架构师的要求实在太奇葩了，实在是无法接受，甚至你觉得你接受这些要求，等于是在公司工作没有任何提升还会影响你后续的求职，因为没有公司是这样玩的。 这次提示的时间大致是在 2 到 3 月之前。 因为 VP 自己没有判断能力，或者他过于依赖这个架构师提供的信息，就等于是听床师这种，难免就会对组内成员产生看法。 这个看法是由我的上司传达给我的，我也开始要求他们接受所谓的新的代码规范，但是无奈实在是阻力太大。 总结 上面是我从这次公司裁员中获得的一些经验和教训。 虽然不是非常全面，但是也希望能够起到一些抛砖引玉的作用，如果我还想到了什么就再补充补充，供大家参考下。 如果有 3 星以上的警告出现一个的话，真的要认真考虑下是否要选择下一家或者开始准备了。 如果有 2 个 3 星以上的警告同时出现的话，没有什么好犹豫的，积极准备，因为裁员或者被裁就会发生在不远的将来。   https://www.ossez.com/t/topic/14465/1

任何一个公司都有自己独特的管理方式，但是在裁员和人员管理上，只要人数超过一定规模的公司基本上都是有一个 SOP 了。 如果你没有被裁员，主动离职的，那么恭喜你不需要经历这个 SOP 流程，如果你是被动的，那么这个 SOP 流程肯定你会遇到，请参考文章：北美 2023 被裁员的感悟 内的裁员过程部分。 这篇短文就是为了不被吓着自己，在公司里面可以玩的小手段能帮助你获得更多的信息来决定自己在公司中的去留。 管理层的鸡汤要过滤 管理层的鸡汤有些看起来很不错，有时候又可能就是毒鸡汤了。 在一个星期之前的 All Hands，公司管理层还说今年形势大好，完成了多少多少的计划，反正就是给你一个公司运营非常不错，各个地区的市场占有率都在节节攀升这种情况。 谁知道，在一个星期以后的 All Hands，就进行了大规模的裁员，这次裁员比例据说是高达 50% 以上，这哪里叫裁员呀，这个就是削减掉所有的开支，保持公司最低正常运营，所有的开发和功能全部暂停。 技术岗更是重灾区，所有外包和驻外的开发团队全部裁撤，北美地区裁员 40%，如果按照人数比例来说的话，技术岗裁员高达 70%，而且是一步到位。 简单来说就是保障系统的最低运营就行，所有的开发全部暂定和不再继续。 所以，我们公司的这个 All Hands 简直就是毒鸡汤，好在大部分人是信而不信，在这么高的裁员比例下，就算留下来的也是降薪降职。 小道消息多打听 我们组里面有个同事，非常喜欢打听各种消息。 他能够在管理层里面活得相当滋润，属于非常擅长社交之类。我们组的小道消息都是从他那里获得的，这次他也才被裁员之列。 在裁员当天，他说路过管理层的窗户的时候，他们都不敢直视他。我们就说你这过了喔，裁员是管理层的决定，他们只是具体执行的人，只是他们有选择谁的权力罢了。 在这个时候，他们肯定会选择自己用得顺手的听话的，或者工作不咋地但是和他们套近乎不错的。 比如说那个奇葩的架构师，显然是留下来了，因为整个公司的 PHP 转 Java 是他们推动的，不管整个过程有多奇葩，但是现在把他弄走了不是啪啪打留下来这个副总的脸嘛。 公司这次裁员的保密工作做得非常好，可能是因为裁员规模非常大，已经削减掉了 50%，甚至有些人还在度假 PTO，公司为了稳住他们，在他们 PTO 的时候就没有说，直到他们返回公司。 这种更好玩，度假回来打开电脑，工作没了。 我们组这个包打听也不好使了。 对上司保持冷静 在本次裁员中，我们的直接上司是留下来了，他手下本来有 4 个组的，从留下来的人数上看，肯定要重新合并，最后公司可能就会留下 2 个组搞开发，一个 DevOps 搞搞部署。 留下一个奇葩的架构师搞 Java ，另外一个维护 PHP 的已有产品线。 在裁员的当天，我们的直接上司也是懵的，他完全不知道，至少他自己是这么说的。 事后，他也单独找我们说，他是真的不知道，他知道所有的选择就是副新来的 CTO + 原来 PHP 提拔上来的副总 + 测试副总 3 个人决定的。 没有任何人问过我们直接上司名单的意见，工作能力等任何问题。姑且我们也想想他把，按照这个规模比例的裁员来说，手下人的表现和工作能力其实不是他们考虑的目的，他们需要考虑的目的就是一次性削减成本到位。 原来公司架构师有 5 个人，从最后的裁员列表上看就是裁掉 1 个，降职 1 个，保留了 3 个，可能另外那个因为我们不熟悉，沟通少，也可能被降职了。 学到的就是，自己上司有时候也没有办法帮你，不是很多信息他也知道的。 我们公司这次裁员可以说是完全不按套路出牌了，说得好听叫重组，说得不好听点就是经营出现了严重的困难，必须要削减掉大部分的开支。 如果经营持续恶化的话，那么进一步的开支削减就在路上的不久发生。 对自己有定位 每个人在公司中的位置是不同的。 有些公司的文化比较开明，个人和公司的关系也是合作的关系。有些公司与员工的合作关系比较融洽，这种公司容易让人有代入感，让你觉得你还真是公司的主人了。 首先想说的是，对我现在这个公司真没有什么代入感。因为产品线的相关负责人实在是让人很困惑，只喜欢听他自己喜欢人的建议。 举例，所有人都反对的把代码放在一行超过 1000 个字符的这种事情，他们都在公司一直强推。可想而知这个阻力有多大了。 你这是反人类呀，但是还是推下去了，不是因为这个东西是正确的，你把握了 PR 的权力和 PayCheck，别人自然会选择退让，不选择退让的人就开始离职了。 对于自己，这次需要深刻检讨的地方在于拖延症，其实一直在准备离开的事情，只是没有那么急迫的下定决心。 所以说，自己在公司中应该有比较明确的定位，一旦发现公司和自己的合作关系并不融洽，或者你对一些事情的看法无法接受。 那么换地方的想法就要马上进行实施了，不要拖延，不要把所有鸡蛋放在一个篮子里面，而且这个篮子还不非常舒服的情况。 心态 心态的转变是需要一个过程的，不得不说人的适应能力还是很强的。 被裁的当天，大家还是有点郁闷的。但是第二天大家都好了，被裁掉的同事建了个群，用来分享下生活小事和面试招聘信息。 连 3 个月之前被裁掉的副总也拉进来了。 也不得不说，美国人这心态也是绝了，此处不留爷，自有留爷处。同时说，就让这奇葩的架构师和奇葩的副总自己玩吧。 一同事是前端转 Java，学 Java 是学得挺费劲的。这回，他说：终于又可以回到他最爱的前端了。3 个月学 Java ，学了个寂寞。 如你也被裁员了，想分享分享，欢迎加入我们。     可扫描加群，讨论下内推，刷题和面经，以及避下雷。   https://www.ossez.com/t/topic/14464

不贩卖焦虑，就事论事，希望能帮助到有需要的朋友。 很多人觉得在裁员之前是没有任何迹象的，其实真的不是这样。 公司在裁员的过程中有很多要裁员的迹象，我会在另外一篇文章中对我遇到的一些裁员信号设置一些雷区和警告，当你遇到上面的这些信号的时候，直觉告诉你需要马上考虑寻找下一个替代方案了。 因为当这些信号的任何一个或者多个同时出现的时候就意味着裁员在进行中了，通常会在 3 到 6 个月左右发生。     在公司的职位 在被裁公司的职位是 Tech Lead。 虽然这个职位并不意味着你对其他同事而言能够获得更多的有效信息，但是通常可能会让自己与上级有更好的沟通管道。 但是，非常不幸的是这家公司的沟通渠道非常有问题。 因为负责相关开发部分的副总是从 PHP 转 Java 的，对 Java 的很多情况都不非常明确，所以他非常依赖一个架构师。 但，公司大部分人都认为这个架构师的要求是错误的，并且是非常愚蠢的。 比如说要求代码必须要放在一行上面，导致代码上面有不少行甚至超过了 1000 个字符。 所有开发都对这个要求非常不理解，并且多次提出这种要求是无理并且愚蠢的，我们组是对这个要求反应最激烈，并且抵触最大的（也有可能是因为我的原因，我不希望在明显错误的地方让步；我可以让步，但是需要给一个能说服的理由）。 然而，这个所谓的架构师就利用 PR 合并的权力，不停的让我们的组员进行修改。 裁员之前 正是因为在公司的职位和上面说到的和架构师直接的冲突。 在 6 个月之前，我就已经和组里的同事说要准备进行下一步了，你们该面试的就面试了，不要拖延。 在这个中间过程中，我的领导还找我谈过一次。领导的意思就是他非常同意我们的有关代码 PR 的要求，也觉得这些要求都是狗屁。 但，负责开发的副总，认为我们组现在是所有组里面最差的。 可能当时没有认真理解这句话的意思，我们组从所有组里面最好的，变成最差的只用了 2 周（一个 Sprint）的时间。 在这次谈话后，我更加坚信让我的组员找下一家的信息了，对他们中途要面试其他公司我都放开一面。 非常不幸的，我自己那该死的拖延症，我是把我自己的简历准备好了，但是还没有来得及投就等来了真正裁员的这一天。 深刻的教训和学到的经验： 如果公司的运营或者管理让感觉到不舒服，并且已经有开始寻找下家的想法的时候，一定要尽快准备，马上实施，不要拖延。 这就是我在上面标黑马上的原因。 裁员过程 裁员过程非常简单和迅速，并且在毫不知情的情况下进行。 在周四的时候，公司的高层提示所有的会议今天全部取消，并且把应该 11 点开的全公司会议提前到了 9 点。 因为很多人都没有准备，所以很多人也没有参加。 后来才知道，9 点就是宣布裁员的开始，事后知道裁员比率为 40%。 然后就是各个部门找自己的被裁的员工开会，这个会议通常首先是一个 Zoom 的 Group 会议，说了一堆屁话，就是什么这是不得已的决定呀，什么乱七八糟的东西。 当然，在这个时候你还需要或者期待公司给你什么合理的理由呢？ 然后就是 P&C 人员说话，基本上就是每个人 15 分钟的时间单独 Zoom。 这个 15 分钟，主要就是读下文件了，至于 2 个会议上是不是开摄像头，随意。 你愿意开也行，不愿意开也行，反正上面的所有人都心不在焉。我是懒得开，因为和你谈话的人，你都根本不认识。 第二个会议就是 P&C，这个会议主要就是和你说说被裁员后可以有的一些福利和什么的，对我个人来说我更关注的是补偿。 至于 401K 和里面的资金都是可以自行转的，也没啥需要他们说的，了解到补偿就是 6 周工资，不算多也凑合能接受。 负责裁员的人说，还有什么需要问的，我简单的回答了下 All Set 然后 have a nice day 就好了。毕竟他们只是具体做事的人，问他们也问不出个所以然，这有啥的。 裁员之后 裁员之后，感觉所有认识的被裁的同事都是懵的。 开完 15 分钟的 P&C 会议后，基本上电脑和邮箱马上就不能用了。公司貌似说电脑可以自己留着，但是上面的数据会被远程清理掉。 留在公司里面的东西会有人收拾后寄到家里。 我在公司里的办公桌就属于离职型办公桌，简单的来说，上面只有一台不属于我的显示器，另外就是从其他地方拿过来的一盒消毒湿巾，公司里面压根没有我需要的东西。 很多人认为公司禁用账户有点太不讲人情，其实从技术层面来说根本没有什么，因为所有的管理都是 LDAP，直接在 LDAP 上禁用你账户就好了，没啥稀奇的。 中午的时候，被裁的同事都互相留下了手机号码，感觉大家因为我在裁员列表里面感觉有点扯。另外更扯的同事在这个公司工作了 7 年了，也在列表里面（所有 PHP 的基础架构都是他写的和建立的）。 虽然最开始和这个同事有过一些摩擦，但是这个印度的同事真的挺好的，我们都觉得他挺不错，也愿意和他一起共事。 很多人，包括我。都对这个同事感觉不值，也觉得这很扯。 奈何公司的选择就是一些阿谀奉承，天天扯淡的人，比如说那个奇葩的架构师。 没多久，被裁的同事建了一个群，然后把我给拉进去了，主要还是我们组里面的同事，大家希望能够分享一些面试经验和机会，偶尔吐槽下。 在晚上的时候，突然收到另外一个同事的 LinkedIn 好友邀请，他不在这次裁员内。 但是他也被降职了，他本来是 Sr 开发人员和小组长，后来被提拔成架构师了，现在连小组长都不是了。 他和我说，如果需要帮助的话，他会尽量帮忙，并且还给他的一些曾经的招聘专员账号推送给了我。 我也非常感谢他们，虽然经历过，但是也收获了一些朋友，虽然说在美国职场比较难收获朋友，但是也并不是完全这样的。 没有了利益的纠葛，更容易说点实话。   https://www.ossez.com/t/topic/14461

感觉搞 IT 的日子最近都有点不太好过。 早上接到公司电话说今天是一个大日子。   为什么是大日子，相信所有人都是懂的。这次公司将会经历一次非常大的裁员，很不幸也在列表中。不过感觉这个好像也没有什么关系。   因为早就在意料之中的事情，经历过去年 CTO 的主动自行离职，今年初的开发部技术总监被迫离职，这一切貌似都不会太远。 裁员比例 根据公开的文档和准备裁员的职位列表，公司的裁员比例高达 40%。 换句话说就是把技术岗位的 40% 都裁掉了。 感触 说心里话，真没有什么什么感触。 因为觉得这天早晚都会来到而已了，只是有点没有期待会以这种方式结束罢了。 公司有公司的选择，主要的裁员原因是公司是一个初创型的公司，在今年第二季度的时候公司的增长没有达到投资方的预期。 那么投资方肯定能会要求公司削减开支，这个削减的过程自然是很多人都会受到影响。 公司会采取某种方式的运营来进行。 早上的时候收到这个消息还是有那么一点点吃惊的。 没有任何征兆，没有任何沟通，裁员的模式就是整个产品线都不要了，如果你现在做的东西不是非常重要和紧急的话，整个产品线就全部裁掉。 写在后面 早就准备好这一天了，只是早晚而已。 写写文章也不错，难得有那么几天清静的可以在这里补充不同的内容和面试找工作的经历。 祝福身边人，开心就好。

示例 桌面 移动终端     特性 toc = table of contents（内容列表） 通过菜单上面的设置按钮，根据当前内容的状况一键生成 toc 列表 Toc 将会一直在页面中尽显显示 —— 滚动内容与 topic 的链接是同步的 当你滚动过当前页面中中的主题的时候，对应这个主题的内容列表将会使用高亮来进行显示（显示为绿色） 针对标题添加属性（你可以从其他的 topic / post 中来链接到特定的内容） 通过单击 toc 的主题链接，浏览器将会导航到正文内容的对应位置上（同步滚动） 针对每一个标题添加一个可以拷贝的链接（当然是在你期望的情况下） RTL 支持 配色方案基于你当前使用的配色方案 是如何进行工作的 在默认情况下，当前的内容的标题将会被标记为 toc（通过 composer 按钮来完成上面的操作的），同时如果你的当前主题是被标记的话，这个也将会被转换为 toc（这个与当前标题的层次有关），所有的内容标题都会被转换为 TOC —— 这就意味着，你的 MD 文件的标题设置是必须正确的，如果你的标题设置层级有错误，那么转换的结果也会出错.。 # heading 1 ## heading 2 ### heading 3 #### heading 4 ##### heading 5 ###### heading 6 针对层级，你可以随意进行调整，但是你必须要保证层级的正确。 # heading 2 ## heading 3 ## heading 3 ### heading 4 ## heading 3 # heading 2 etc... 为了保证链接能够正常工作，所有的标题必须要有 Id 属性。 这个组件将会自动对标题的 Id 进行校验，如果标题是存在的话，那么这个组件将能够更加有效的执行。同时 Id 在你手动创建主题的时候也更加有用。 如果你的标题没有 Id 的话，这个组件将会根据标题的内容来自动创建 Id（对不需要的字符将会自动的被忽略）。 当上面的所有内容完成后，TOC 将会根据标题创建一个链接到正文的链接，如下图： 设置 这个组件只有一个设置，就是 Toc 的图标（这个图片将会在后面的设置中使用，官方不建议对这个图标进行修改。） 翻译和本地化 这个组件需要翻译的内容也非常少，只有下面 3 个字段需要翻译。 table_of_contents: "table of contents（内容列表）" 这个将会在移动终端上打开 TOC 的时候显示 insert_table_of_contents: "Insert table of contents（插入内容列表）" 这个是在内容列表被插入到主题页面的时候来进行显示的。 topic_will_contain_a_table_of_contents: "This topic will contain a table of contents（本内容将会提供主题列表）" 这个内容将会在你对主题内容进行编辑的时候，在右侧进行预览的时候显示在预览页面上。This is the text that shows up in the composer preview to indicate that the a toc will be generated for the topic 如何创建一个标题 有关内容的标题在创建的时候需要创建有正确的语法。 单击页面中的菜单选项（这个只针对常规主题和帖子进行显示，如果你试回复和私信的话，这个选项将不会被显示）。 插入到主题页面中 当我们使用 Toc 的时候，阅读进度小组件会发生什么 你可能知道，在页面中我们没有办法同时显示阅读进程和 TOC 。 官方的解决方案是，如果你再阅读第一个帖子的时候，TOC 存在的话，那么页面上将只会显示 TOC，而将阅读进度组件忽略而不显示。 当你的阅读超过第一个帖子的时候，TOC 将不会进行显示，取而代之的是整个内容的阅读进度显示条。 简单来说，TOC 只针对第一个帖子有效，后续的帖子将会使用阅读进度条。 针对移动终端盒桌面应用的显示是相同的。 使用这个组件会有什么问题 针对作者和官方的说法，使用这个组件目前还没有遇到任何问题。 所有的内容显示是在客户端完成的，用行话来说，就是所有的内容是在前端完成的，所以后端的数据提供没有受到任何的影响。 当你禁用这个组件以后，所有的内容将会恢复成原样。 使用限制 这个组件使用的是标准的主题布局。 如果你使用的布局对对标题的使用进行了修改的话，那么这个 TOC 组件将没有办法正常工作。 例如已知的，如果使用了 Vincent theme 这个主题的情况下，这个组件是没有办法正常工作的。 针对一些非常流行的主题支持，对官方这个插件来说是下一个需要考虑的内容和反向。 开发者 官方的作者是基于 Greg Franko’s tocify.js 库进行开发的。 但是，非常不幸的是，这个库已经很长时间没有更新了，所以作者针对这个库的内容删除了很多不需要的内容和没有必要的特性和代码后把相关的特性整合到 Discourse 中了。 整个组件的大小在 ~ 4kb 左右（使用 gzip 压缩的情况）。 作者也感谢 @erlend_sh 提出了很多很好的建议和 @david 帮助完成了翻译工作。 需要改进的（TODO） 在编辑的时候，实时对照显示 TOC （这个可能对资源的消耗非常大） 支持一些主流的主题来显示 TOC 单击标题的链接按钮同时还自动拷贝到剪贴板中。 针对这个版本的发布，作者表示的是：这个发布还是比较早期的发布，如果你对这个组件有什么问题，建议和改进的话，欢迎直接和原作者取得联系。   https://www.ossez.com/t/discotoc/14455