[新西兰远程工作] Web 高级全栈/Node.js/React.js/TypeScript/Ruby on Rails，工作地点随意，无加班 996

关于我们

我们是一家在新西兰的公司，主要产品是一个 SaaS 平台，方便用户管理和购买微软产品以及提供一些云服务，目前主要业务在新西兰地区。在去年疫情期间，公司转型全员远程办公，同时我们在扩张业务到全球其他地方，所以目前开始进行海外开发人员招聘。

工作要求

具体详细的原版要求请参见这里：https://www.seek.co.nz/job/51735261 我这里简单摘要方便节约你的时间：

精通 Ruby on Rails 及相关（此项可以弱化，已经劝说老板迁移 Node 新架构，只要愿意学习能快速上手即可）
精通 JS 和 Node.js （ 3 年+开发经验）
熟悉 TypeScript
熟悉 React.js 以及 Antd
熟悉 PostgreSQL 、Redis 等
熟悉 DevOps 、CICD 、K8S 等最好是 Azure 平台
能用英文进行沟通面试，具备一定的听说读写能力，因为是英文的工作环境，但如果能力突出，前期可以由我辅助沟通协作
了解或者有 Nest.js 经验，全新 Node 应用将会基于这个框架

工作模式

全远程办公，不限制你的位置，比较灵活自由。每周最多工作 40 小时，没有加班和 996，多陪陪家人。适合想要自由生活、逃离北上广、喜欢到处旅游的人群。我的老板近几年每年都要在国外边旅游远程办公两三个月。
基本不开会。全部例会只有每天不到 15 分钟的 Standup 和每两周一次大概 2 小时的 Sprint Planning 。
合同工，至少签约两周起，优先选择长期合作，因为我们是一个长期维护的 SaaS 的平台，不是短期的小项目，因此倾向于每周 40 小时的全职远程办公，只不过以合同工的形式签约。提交工作时间表的方式统计工时。

薪资待遇和招聘流程

由于我们会在多个国家和地区招聘，然后每个人的情况和经验也不一样，每个地区的情况也不一样，所以我们采取自己定价。如果你觉得你符合 JD 的要求，即可准备一份英文 resume 发过来，同时附带你期望的薪资。我们将会评估并考虑进行下一步面试等。

格式：

Subject: Hi Harry, I am [your English name], this is my resume
Body: 英文版的目前情况简介，包括现在是否在工作，以及其他的合作方式和每周工作时间，期望薪资（ RMB 即可），以及你想要问的问题等等
Attachment: PDF 或者 Word 文档，英文简历

先发送到我的私人邮箱 hi[at] harryyu[dot] me 然后我先初步沟通聊一下，OK 的话我再转发给 Team Leader，然后跟进安排面试。有任何问题咨询也可以直接发送邮件到我邮箱。

薪资会按照协商的方式转账，需要个人或者个人挂靠、注册公司来自己处理当地税务、社保等问题，需要具体协商。

常见问题

可否先兼职一段时间再决定是否签长期合同？

可以。我也跟老板反馈了一下，很多朋友可能在职有想法，但是直接辞职签约也有很大的风险和担心，所以最好的方式是可以先利用晚上和周末能兼职一下，比如一周先只做 20 个小时左右，然后磨合一段时间双方再做决定。

老板表示只要是人才，都可以协商，关键看水平。

有时差怎么办？

我们目前是一个比较小的团队，所以比较灵活，我们可以调整例会的时间来符合大家的作息。

公司是否会帮助办理新西兰签证等？

抱歉，由于一些法律等的限制，在海外的招聘只能以合同工的方式签约，无法按照当地人的方式签（因为没有税号、Visa 等）因此也无法担保新西兰工签等签证。但有一定新西兰本地公司的工作经验，相比没有肯定是有一定帮助的，可以锻炼英语、增加当地人脉，后续边境开放可以直接旅游签过来面试我们公司或者其他公司，有一定优势。

本信息有效期暂定 2021 年 5 月 20 日，目前刚刚启动面试流程，疯狂收简历安排面试中，有兴趣的朋友赶紧准备投递，名额有限，招满就没了。

felixin

2021-03-21 15:30:13 +08:00

比如怎么做定制 logging，继承官方那个简陋的 Logger 自己写实现，然后发现 logger 的注入不推荐用 constructor 注入，而是要使用成员变量初始化，并且在 app module 之外的 logger 和依赖注入管理的 logger 是不同的初始化方式——和 java 或.net 之类的对比一下;

比如要上 graphql，dataloader 怎么使用文档没提，最后是根据网上的代码改了一个自己做的装饰器，用 ModuleRef 在 context 里动态写入属性;

怎么和数据库交互，typeorm 是个 leaky abstraction，join 的写法比直接写 sql 还复杂，而且也不能覆盖数据库原有的特性，比如写不了 cte 。pg 的 view 只支持写一次不支持更新，最后研究了 typeorm 的源码在每次启动的时候得把旧的 view 删了再重新创建 view;怎么做 transaction，用 query runner 对象显式执行 sql，如果这个 transaction 横跨多个 service，要把这个 query runner 一路传递出去，看看 nestjs 的文档那一节，再和 ef core 之类的对比看看;想要做 @Transactional 注解，需要深入研究 cls-hooked，一不小心就内存泄漏;

换了一个 slonik，类型标注是用 flow 写的（最近改成 ts 了），用稍微复杂点的数据结构就需要处理 type parser 问题; transaction 的写法一样要用 cls-hooked 自己封装，否则 service 调用 service 就是两个不同的 transaction;

mode_modules 依赖稍微多点，打包 docker 直接 1~2G，还经常爆出被依赖投毒，yarn2 的 berry 搞了快两年还是一堆兼容性问题，基本无法实用。

最重要的是 typescript 本身的问题，毕竟它只是 js+type，不是真静态类型语言，改变不了 js 动态的本质，有时候看着 type 都没问题跑起来一样 type error，重构改名都要担心哪里会 break; 从 ror 换成 nodejs 换汤不换药，ror 解决不了的问题 nodejs 一样无能为力。

还有很多和业务强相关的就不说了，一路上大小坑要么网上只有几个人遇到同样的问题然后 publish 一些 dirty 方案，要么在官方 issue 上挂了一两年的没有解决最后被 close 。确实这些问题不是不能自己动手解决，只不过我们精力没必要放在它们上面。

nestjs 想做 nodejs 上的 aspnetcore/spring，那为什么不直接用他们呢，这两者已经做到极致了。我们的看法 nodejs 只适合做 view 层，比如 SSR 就很合适，但不适合处理深层次的业务逻辑。当然团队水平不同，业务能力不同，看法不一样，方案也不一样，我们是小团队，也许适合别人不适合我们。