这次只是电话面试的一个第一次接触。 公司背景 公司属于一个类似数据分析公司，公司规模算是比较小的公司。 主要做的产品是收集用户在网站上的行为，获得对应的用户数据，然后对用户的数据和行为进行一些算法上面的处理。 将处理的结果生成为报表提供给客户公司使用。 这样，客户公司可以根据提供的数据和报表能够更有针对性的投放广告。 职位需求 这个职位属于技术领导类似的。技术领导这个职位主要对团队进行一些负责，对团队中的人员进行开发组织。 同时这个职位还需要有比较好的沟通能力，能够了解 PM 的需求，同时对团队中的人员进行相关的跟踪和调配。 在开发技术上，这个职位可能不需要非常强的开发能力，但是也需要有比较强的开发基础和背景，这样才能更好的完成开发任务。 电话面试过程 在电话面试的过程中，主要是 HR 先对公司的产品和要做的东西进行了一些说明。 因为公司的业务和数据比较单一，因此对公司的业务类型和需要做什么还是比较容易理解的，不会出现太多理解上的偏差。 公司基于的云平台是 Google 提供的云平台，使用的技术栈为 Java 技术栈。 随后，HR 对我的情况进行了一些了解，比如说当前的职位是什么，有没有什么项目管理的经验等。 针对 HR 的问题，我都一一做了回复，针对项目管理上面的经验来看，和我现在的工作职位还是比较接近的，所以和比较容易的回答了 HR 的一些问题。 同时，利用当前使用的一些例子来用例子来进行说明，希望能够让 HR 更好的理解我的工作职责和技术水平。 因为，这次面试只是电话面试，所以很多东西只是通过电话来了解下，主要是了解下沟通能力和双方的好感程度。 通常，第一次的电话面试是不会涉及到过多的技术细节。 HR，同时还告诉我说，整个招聘流程有 3 轮面试。 在第一轮电话面试完成后，如果项目组觉得还可以，就会让 VP 单独和我面试下，时间是 1 个小时。 当 VP 面试完后，会有下一轮主要是各个 Team Lead 之间的一个沟通和面试。 最后才是组员同事的面试和沟通。 整个过程完成后，如果觉得没有设么问题，就会进行背景调查，他们还希望对我曾经工作过的同事进行 Reference。 当然，如果到最后一步了，这些都不是问题。 总结 个人总结这次面试更加像是一种热身。 因为有比较长的时间没有参加各种面试了，所以感觉自己组织的还不是非常理想。 但是好在第一步只是个人行为方面的沟通。 这几天又因为感冒了，嗓子也不是非常好，说话声音都是沙哑的。 总结下需要提高的是，如果是面试技术经理岗位的话，沟通能力非常重要，同时对各种理解和自己的规划也非常重要。 可能是因为公司会通过你对你的自己规划来了解你的期望和公司的要求是否一致，相对来说技术方面可能要求并不是那么高。   https://www.ossez.com/t/topic/14513

在中小公司进行规模化裁员的时候一直想考虑下哪些职位更容易受到影响？ 前几天和朋友聊了裁员这个事情后感觉有点启发。 当然，如果你的项目被整个一锅端了，那就没有什么好说的了。 这里想表达的是，如果是项目还在，但是公司需要收缩，重组，并把很多项目小组合并，哪些岗位更容易受到影响一些。 同时，大公司和中小公司的裁员方式也不一样，这个主要是讨论下中小公司。 中层和小组长级别 开始觉得这个岗位还是相对比较稳定。 后来和朋友聊天后才知道，这个岗位比初级程序员还不稳定。 主要原因是： 公司给的工资足够高。 如果项目组进行合并的时候，这个岗位不好安排，如果采取降职合并，通常也干不了多久。中小公司可能的态度就是干脆裁掉。 进行重组，被裁撤的项目组可能因为合并会导致更多纠纷，公司怕麻烦，并且希望不希望支付太多工资水平。 在中小公司，项目组长或者中层反而是最不安全的。 在公司高层不是说不会裁员，通常他们更有能力获得相应的信息，能够更加容易的做好准备找好下家和准备好备选方案。 公司中层，通常和上面关系不那么紧密，获得信息的渠道和下面也差不多，但是又是职位最不好安排的一个职位。 高级开发工程师和架构师 高级开发工程师的危险系数稍微小一点点。 但是，因为高级开发工程师的薪资水平也比较高，公司为了更加高效的裁员，通常高级工程师会按照一定比率的进行裁员。 在保障最低运营水平的情况下，对工资水平比较高的高级开发工程师开刀。 同样的道理，所谓的架构师在很多时候也会被拿来作为开刀的对象。 初中级开发工程师 这个岗位对裁员的影响反而更小。 主要原因还是这类工程师的薪资水平较低，公司能够有效的控制成本。 具体做事还是需要有人做的不是。通常公司会选择一些老实点的，比较听话的，工资水平不高的人暂时保留。 这次我们公司的裁员明显感觉有这个套路，裁员的方向都在高级和中层。 低级点的基本上都保留了。 其他人员 其他人员会随着项目的保留和公司预期来不按套路裁撤。 比如说项目中的 Scrum Master （敏捷专家或者敏捷大师）通常也会是重灾区。 测试项目组成员，如果过多的话，也会被裁掉大部分。 总结 整体来说，如果公司进行大规模收缩的话，谁都不安全。 而且公司的裁员通常不是一轮裁员，会按照多轮裁员的方式持续进行下去。 在第一波裁员被保留下来以后，不代表在后面的裁员会继续保留。 如果公司已经开始进行了大规模裁员的情况下，更主要的是说明公司在经营上面出现了比较严重的问题，才想到通过裁员来削减支出。 也许，在保留好现有职位，积极寻找更好的机会才是上策。   https://www.ossez.com/t/topic/14512

Discourse 附件上传大小是需要修改配置文件后重启的。 官方的帖子在：Change the maximum attachment/upload size - sysadmin - Discourse Meta 页面中。     默认的上传大小为 10 MB 需要把上面的参数添加到 Discourse 配置文件后重新编译。 修改完成后，进入目录：/var/discourse 然后运行命令： ./launcher rebuild app 来进行重新编译。 管理控制界面修改 只修改上面的配置文件是不够的，还需要在后台的管理控制界面内也进行调整。     至此完成修改后，就可以让你的 Discourse 支持更大的附件上传了。   https://www.ossez.com/t/discourse/14511

北美 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