北美 2023 被裁员的感悟 发布一周以后，没想到在网络有了好几千的围观还收获了不少的评论。 更多的是情绪的另外一种转变。   可以开始在外面烤点，顺便思考下一步的发展和路径。 有时候，环境的变化更会刺激去思考。 情绪 裁员或者被裁这种事情，本身就每天都在发生的事情，其实并没有什么太多要说的。 可能最近因为经济的下行，讨论这个问题的内容越来越多。同时，类似前公司的这种裁员方式有点出乎意料，主要对情绪上的影响还是从一个已知的环境抛向到未知的环境，并且要强迫自己离开舒适空间的一种不适应。 很多朋友把再找到工作叫做上岸，有时候也需要思考下这个上岸是往回游找到类似的工作叫做上岸，还是像有些人往更远的地方游去找到其他的地方上岸呢？ 收获 这次小的经历其实也是收获满满的。 从事情的发展上认识到了还有很多的不足，需要改进的地方。同时，也收获了不少同事和朋友。 昨天在 LinkedIn 上突然收到了前组员的好友邀请和消息，他没有在这次裁员的名单中，他的职位是中级软件开发工程师。 他和我说：非常感谢这 1 年来对他和整个团队的照顾，并且我们团队一直在改进和努力中。实在没有想到会以这样的一种方式结束。并且感谢我这一年来对他的帮助，让他能够学到了更多的东西。如果需要 reference 的话，他非常愿意帮我写个 reference。 收拾好情绪和心情，再出发。 正如，同组同事说的，更光明的未来在前面等着。 祝福每一位朋友，不管是认识的还是未知的。   https://www.ossez.com/t/topic/14495

因为有些要求感觉实是太过奇葩，收集下来娱乐下大家。 代码规范要求 要求如果代码可以静态导入的话，就必须要静态导入。 所有的代码如果不静态导入，就直接 PR 拒绝合并。 举例： equalsAnyIgnoreCase("test","test"); 这个必须要使用 import static org.apache.commons.lang3.StringUtils.equalsAnyIgnoreCase; 如果我们写成： StringUtils.equalsAnyIgnoreCase("test","test"); 奇葩的架构师，要求这个必须要修改为静态导入。 奇葩解读 Java 的静态导入 （import static） 是从 JDK 1.5 版本开始提供的，其目的是为了减少字符输入量，提高代码的可阅读性，以便更好地理解程序。 用于导入指定类的某个静态成员变量、方法或全部的静态成员变量、方法。如果一个类中的方法全部是使用 static 声明的静态方法，则在导入时就可以直接使用 import static 的方式导入。 滥用静态导入会使程序更难阅读，更难维护。 静态导入后，代码中就不用再写类名了，但是我们知道类是“一类事物的描述”，缺少了类名的修饰，静态属性和静态方法的表象意义就会被无限方法，这会让阅读者很难弄清楚其属性或方法代表何以，甚至是哪一个类的属性（方法）都要思考想一下，特别是在一个类中有多个静态导入的时候还使用了通配符（*）这个静态导入简直是个噩梦。 还是用 StringUtils 来举例。 不是只 Apache Commons 才有 StringUtils 的。   随便拉个项目，你看看就有多少个 StringUtils，同时 equalsAnyIgnoreCase 这个方法名也不是在一个包使用的。 可能在很多包中都用了这个方法名。 这种奇葩的强制使用静态导入的要求，简直是令人发指，在特定阶段的时候破坏了程序的可读性。 在实际使用的时候，对于一些公共方法名，尽量不要使用静态导入。 但是针对测试的一些测试类中使用的断言，还是可以使用静态导入的。 import static org.hamcrest.CoreMatchers.instanceOf; import static org.hamcrest.MatcherAssert.assertThat; import static org.junit.Assert.assertEquals; 如果上面我们常用的一些测试中使用的断言。   https://www.ossez.com/t/topic/14492

Dice 是科技求职者的主要网站。 我的第一份工作就是在 Dice 上找到的，针对 IT 的工作 Dice 上还是非常多的。     在 2008 年的金融危机阶段，Dice 上投放的工作数量通常可以作为当前市场情况的一个指标，最少的时候上面只有 1万多职位。 在经济回暖后，上面同样的关键字搜索的话，职位会恢复到 7 万多，正常应该在 5 万多左右。 心得 Dice 本是 IT 求职人员的首选网站。 但是后期，因为 Dice 被很多 Contract 给占领了，对于要留在美国的人来说，Contract 工作没有办法解决身份的问题。 同时 Contract 简历投太多的话，会有很多噪音，不少人为了更有针对性就不在 Dice 上面去放简历了。 如你没有身份限制，并且也愿意做 Contract 的话，Dice 也未尝不可以去试试。   https://www.ossez.com/t/topic/14481

Glassdoor 本来的目的就是求职者对公司的一个大众点评。 在你还没有进入公司之前就可以让你对公司的运营和文化有所了解，Glassdoor 目前的运营和市场占有率也非常迅猛，数据也比较准确。 心得 Glassdoor 算是用得比较多的招聘平台。 主要是通过 Glassdoor 来对招聘公司有所了解，包括招聘公司的企业文化怎么样。 有些公司表面上看起都很好，但 Glassdoor 的评论就会让人却步。 对公司的评价比较多的就是有毒的文化，美国公司擅长营造一种归属感，让你觉得你就是公司的主人，公司的决策和运营都是透明的。 但实际上却不是这样的，很多公司的运营可以来说是完全透明，比如说这次我们公司的大规模裁员就发生在一瞬间，这个行为是可以理解的，但是又感觉又被当前公司的毒文化给 PUA 了。 在这个网站上面，toxic culture 算是一个高频词了。   https://www.ossez.com/t/topic/14481

Indeed 对自己的定位其实就是一个工作的搜索引擎，Indeed 会到互联网上去搜索最近发布招聘职位的公司。     并且 Indeed 自己也为公司提供招聘服务，在 Indeed 上有时候会直接把你导航到招聘公司的网站上，你可以在招聘公司的网站上自己提交申请。 有些公司就会直接使用 Indeed 的招聘服务。 心得 Indeed 的使用噪音比较大，很多公司多是些小公司，上面的薪资水平可能没有那么高。 各大公司都有自己的招聘平台和系统，很多时候可以使用 Indeed 来搜索公司，然后到公司的网站上上传简历。 但，Indeed 的覆盖比较全，所以就算噪音比较大，还是找工作海投比较主流的平台。 有时候猎头也在自己公司发布招聘职位，然后被 Indeed 搜到后导航到猎头公司的网站，你可以把简历提交到猎头公司的网站上。 猎头公司有些职位是 contract to hire，通常会要求做几个月的 Contract 然后再雇佣，这种公司的流动性相对小，公司也比较稳定。   https://www.ossez.com/t/topic/14481

这个就不用说了吧。 只要你是工作过或者准备工作的朋友，应该都会有一个 LinkedIn 界面。     你可能不会在 LinkedIn 放很多东西，但是经常有猎头在上面进行游荡。 上次的工作就是猎头通过 LinkedIn 找到了我，然后开出了非常诱惑人的条件，并且 PUA 去试试，结果试试就试走了。 心得 LinkedIn 这个基本上有求职需求的都会有一个，在上面发布一些专业性的内容，或者对自己的工作状态进行更新都不是坏事。 建议不管有没有失业，有时候刷刷 LinkedIn，在上面建立一些人脉，刷刷存在感，对以后万一出了状况就很有帮助。 其实简单的，就是更新了一些工作的内容和在哪里工作过的情况罢了。 不过呢，对自己的隐私情况需要注意保密，省得到时候麻烦。   https://www.ossez.com/t/topic/14481

因为有些要求感觉实是太过奇葩，收集下来娱乐下大家。     代码规范要求 在所有无参数构造函数，全参数构造函数，Getter 和 Setter 方法必须要使用 Lombok。 所有的 Builder 方法也必须要用 Lombok。 简单来说是就是 Lombok 没有提供的才可以使用其他方法。 如果对 Lombok 不是非常了解的，请参考文章：到底应不应该使用 lombok 大部分人对使用 Lombok 其实还是持有保留意见，但也不拒绝使用。 在所有的代码中使用有时候就会出现问题，我们提出过的疑问是： Lombok 循环依赖 在一致的 Lombok 问题中，可能会出现循环依赖的问题，这个问题怎么解决。这个问题到底怎么解决，这个架构师到现在还没有给我们一个准确的答复。 JDK 和 Lombok 版本冲突 如果 JDK 和 Lombok 版本冲突了怎么办？ 奇葩架构师的回复是：在版本控制上是他负责的，他会解决版本冲突问题，由他来控制所有的版本，你们只管用就行。 既然这样说了，也行吧，反正到时候出了问题也不是我们的问题。 Lombok 的有时候错误是运行时错误，等这个时候再 BB 把。 说实话，Lombok 的使用是一只比较有争议的，用也行，不用也行，最好别滥用就好了。 奇葩架构师的要求是能用 Lombok 的地方就必须要用，不管这个使用会不会产生什么样的影响，等有影响再说。 就这心态还是有点爆炸的。   https://www.ossez.com/t/lombok/14488

因为有些要求感觉实是太过奇葩，收集下来娱乐下大家。 代码规范要求 如果代码在 IntelliJ 出现了警告提示，所有的警告必须要在提交之前处理完成，否则 PR 合并全部被拒绝，不管有些警告是不是有点奇葩， 同时，如果你在提交代码的时候被这个奇葩架构师发现有警告没有处理的话，他会非常严厉的指出这个奇葩的问题，并且多次发现或者忽略这个问题的时候，他就会把这个问题上升到原则高度，说你根本不会编程，不会写代码，然后告诉全公司，这哥们压根不懂代码。 为什么要这样要求的解释：警告是程序错误的一种，如果你对警告不处理就是视而不见，是能力问题也是态度问题。 我们提出过异议：从 Apache 克隆一些代码，你会看到上面有成千上万条警告，这难道证明这些 Apache 的提交不是优秀代码，难道他们还不如我们吗？ 得到的回复是：因为 Apache Commons 的包的警告被很多人证明这不是问题，所以不需要去处理。不同项目要求不一样，我们不能要求 Apache。     来看看 Apache 的这个类，估计他得哭晕在厕所里了。 其实并不反对对警告有些关注，但是这样吹毛求疵的要求所有警告被处理，就有点过分了。 比如说有些类，可以不用定义为 Public，奇葩架构师也要求进行修改，然后下次用得时候如果需要用这个类的方法还得再改回来。 还有呀，他对警告级别的认定不经过所有人的同意，也不经过任何其他人的同意。 突然那天脑袋被驴踢了，就改了 IntelliJ 警告基本设置，结果就出现程序员本地没有警告，在他那里全是警告，然后说你为什么不修改警告？ 一言难尽的折腾，你们怎么看？ https://www.ossez.com/t/intellij/14485

这次公司的裁员是教科书基本的真的是没错。 但是美国同事的心态和离职类型也让人大开眼界。 后来在公司同事建立的被裁群中才了解到，PM 组也是重灾区，也超过了 50%，不少在公司工作超过 5 年的 PM 都被毫不留情的裁掉了。 就算这次勉勉强强被留下的人的心态也可想而知了。 昨天自动化测试组的同事不在这次裁员之列，可能现在还需要她们写些测试用例，不在这次裁员之列。所有测试工程师都在这次被保留了。 她也是人心惶惶，已经开始积极找工作了。 下面来说说被裁后的几种类型，娱乐娱乐大家。 清家产型 公司这次裁员不需要电脑上交。 我这想着嘛，这电脑还凑合能用，留给家里上个网算了。另外一个同事比我可快多了，第二天就把电脑给卖了。 然后在群里面说，昨天去了一趟 Best Buy，直接卖了 700 多，一脸嘚瑟。 另外同事，就直接拿着电脑在朋友圈里面给处理了。也全都变现了。 还有同事更有意思的，不但把电脑给处理了，还顺便把公司所有的周边产品，文化衫，水壶这些东西都全部一并给处理了个干净。 度假型 在裁员后的第二天，一前同事就带着家人去海边度假去了。 然各种展示下海边的风景和温暖的阳光。 更多的貌似都在周边晃悠玩呢，这同事跑得比较远，直接去佛罗里达玩去了。 摆烂型 一同事昨天电话我说是已经申请了失业保险。 现在在家摆烂长膘中，问我要不要过去整点啤酒一起摆烂。 美国人这炸毛离职类型和心态的心态。 不管怎么样，应该都在经历一个心态调节的过程，等过了这个阶段，相信所都会慢慢恢复正常。 整体感觉他们心态更加悠闲，可能也因为他们没有很多的身份忧虑，少了很多烦恼。 如你也在离职之列，你是属于那个类型呢？   https://www.ossez.com/t/topic/14482

首先说明下公司的技术架构。 MySQL + PHP + Java，纯互联网应用，Docker 容器部署微服务在 AWS 上面。 数据上没有过多敏感性，不涉及到很多敏感数据，身份识别信息通常使用的是第三方平台，我们本地不存储用户身份信息。 电脑只能使用 Mac 如果你是 Mac 电脑的深度爱好者，那你有福了。 公司规定电脑只能使用 Mac，这个规定在我进入公司之前没有强制实施。 强制实施的的时间是在2022年的8月左右，对已有的 Windows 电脑进行强制报废，使用 Mac 电脑。我可能是这个公司里面所剩不多（应该不超过 5 个）的人员之一。 理由 在程序编码的时候 Windows 可能会出现一些意想不到的问题。 具体什么问题，没有说。负责开发的副总解释的原因是就是可能出现问题。 我猜测可能是 NodeJS 编译的时候的问题和 Windows 和 Java 使用的字符，空格，以及回车换行标识符有区别。 但，我们通常不都用 UTF-8 吗？开发 Java 用 Windows 或者 Mac 实在是没有区别。 NodeJS 的问题，根据习惯，可以使用 WSL 来解决。 开发人员没有管理员权限 公司所有的电脑都没有管理员权限，包括开发人员使用的电脑。 理由 出于安全考虑，防止开发人员电脑携带病毒和安装一些公司不同意安装的软件。 所有的电脑都没有管理员权限。 我认为这个并没有什么不妥，对一般用户确实不应该给与管理员权限。开发人员因为使用的开发工具比较多，这些工具的安装给个管理员权限就更加方便些。 对这个问题，我其实没有什么异议。 但是每次安装升级都需要等好几个小时，让其他人远程到你公司来进行安装，非常繁琐。 曾经工作过的另外公司的处理就比较灵活，对于要安装的软件通过在线提交的方式，由远端授权，他们通常会很快的授权给你安装，而不需要等好几个小时。 哪怕是升级也如此。 导致一个问题就是新电脑环境难配，从一台新电脑到把环境真正配好到开发状态，需要超过数周时间。   https://www.ossez.com/t/topic/14473