TapTap（TDS）招聘前端工程师（全栈方向）

太长不看版 JD：

要求

• 有扎实的工程师基础：熟悉常用数据结构与算法，了解现代 web 应用是如何工作的。
• 熟悉现代化的前端工程：有能力选择合适的方法与工具，完成从需求分析到方案设计、开发、测试、发布、运维的完整流程。
• 有以下一个或多个领域的知识与技能：产品、用户体验设计、后端开发，能独立完成相关工作。
• 有优秀的学习、沟通与协作能力。
• 工作地点：上海 /北京 /远程。

加分项

• 是活跃的开源社区贡献者。
• 了解游戏开发或运营。

职责

• 负责 2B 客服系统（一个或多个模块）的迭代，利用自己的专业技能，推动问题解决，为客户创造价值。
• 参与维护其他工具与服务，为 TDS 各业务团队提供前端支持。

请发送简历到 [email protected] 。我们部门同时也在招其他职位，可以访问 TDS 的招聘页面了解详情。

接下来我想展开介绍一下关于这个职位的更多信息。

关于要求

首先，你需要是一个优秀的工程师。一个优秀的工程师需要做到在为你做代码 review 时你的同事不需要关心命名、逻辑正确性、是否存在性能问题这些方面，而是可以把重点放在问题抽象、模块拆分、接口设计层面。要做到这点并不容易，你需要有良好的英语水平，需要有扎实的计算机基础、熟悉常用的数据结构与算法，需要了解现代 web 应用的各个部分大约是如何工作的，当遇到不熟悉的领域时知道如何快速学习对应的知识，以及最重要的一点，需要有动手能力把所有的这些变成可以运行的工具或服务。

然后，你需要是一个专业的前端工程师。你需要了解前端领域的最新状态，知道要解决的问题是什么，哪些已经被解决了，哪些进展到了什么程度。你需要熟悉现代的前端工程的完整流程，有能力选择合适的方法与工具，独立完成一个需求的前端部分从需求分析到方案设计、开发、测试、发布、运维的完整流程。你还需要对其他与前端有交集的角色—包括但不限于产品 /运营、设计、DevOps 、SRE—负责的事情有基本的认知，知道不同角色之间的边界与接口，有能力辨别合作方案中不合理的设计。

你还需要熟悉除了前端之外的至少另一个栈：产品、用户体验设计或后端开发。拥有跨栈的能力有以下优势：1. 减少沟通成本，可以更灵活地分配时间 ，从而更快的进行迭代； 2. 可以从更高的视角看问题，从整体利益出发设计更合理的方案。对于其他栈，你不一定有像前端领域一样全面的知识体系，但依然要有独立完成相关工作的能力（当然反过来也可以，比如你是专业的视觉设计师，同时熟悉前端开发，我们同样需要你）。

最后一项是沟通能力。正如「代码是写给人看的」，工程师很大一部分工作是在与各种各样的人沟通。因此你需要能通过书面或口头的形式有效地描述事实（问题、方案）、表达观点。

说完了要求，再来说说不要求什么。

首先，不要求工作经验。能力比经验重要的多，只要你能证明你满足上述的能力要求我们都会邀请你来面试（当然项目经历是最常见的能力证明，如果你在工作经验上没有优势，请务必确保你在简历中体现出了能力）。出于同样的原因，我们也会按照简历中与面试时展现出的能力提供我们认为与之匹配 offer ，而非根据过往的职级或薪资（我们甚至不会问）。

然后，这个职位不要求你是某个领域的技术专家。我们目前阶段，绝大部分需求依然来自业务。能在广泛的领域中选择合适的工具把一个需求从 0 做到 80 分要比在某个具体领域把需求从 80 分优化到 99 分对当前的我们更有价值。当然这并不是说我们不重视技术深度，只是说如果你的职业规划是深耕某个技术方向的专家，对具体业务兴趣不大，那这个职位可能不能满足你的期望。

关于 base ，这个职位接受远程。尽管我们一直在践行异步沟通的工作方式（我们小组就分驻京沪两个办公室），但目前绝大部分的公司同事依然是 on-site 的，这事实上对远程工作的同事提出了更高的要求，包括自我管理能力、主动推进目标的能力与良好的异步沟通习惯。这部分能力很难直接通过简历或面试体现，所以如果你希望远程，请务必事先了解这一点。

关于团队

说了很多对候选人的期望，接下来分享一下我们团队的更多细节。其中很多是我们与候选人沟通时经常被问到的，本也不是什么需要保密的信息，不如在这里公开介绍一下。

关于 TapTap 与 TDS

公司层面，包括部门的基本情况，以及文化、面试流程、工作方式等信息，可以参考《文化、制度和工具 | TDS 博客》，不在此赘述了。

关于我们组

我们是 TDS 前端团队的一小组，目前由 4 位成员组成。目前除了前端支持团队的本职工作，我们在主导一个新的客服产品的开发。我们希望能向 TapTap 开发者提供一个兼顾用户体验、客服体验、客户体验与开发者体验的客服产品。我们使用的主要的技术栈是 React + NestJS with TypeScript （并非限制）。

关于我们的工作方式

我们按照需求分工，一个人负责一个完整的需求，从需求分析一直推进到最终发布。如果某些重要的工作不在你擅长的领域，你可能会需要在组内或组外找到合适的人与你合作完成（ TDS 层面还是有专精产品、设计、测试、DevOps 的团队的）。同时我们要求每个人又都是一个或多个模块的 owner 。这个模块可大可小，大到一整个业务方向，小可以是某个具体功能，相同的是都要求这个人是全公司最了解这个模块的人，要对这个模块负责（更具体一点，要收集与分析模块的需求、思考与决定模块的目标与计划、review 涉及到该模块的方案与 MR ）。一个需求可能会涉及到对其他人负责的模块的改动，此时需求的 owner 需要找到模块的 owner 商量方案，多数情况下还需要负责实现并提交 MR 。

公司践行 OKR ，每个团队有自上而下对齐的目标（ O ），它们是我们日常大小决策的依据。我们组每个月初会根据团队目标讨论并确定当月的工作计划，然后每个人独立拆分更细的任务与个人计划。每个季度结束后，TDS 每个团队负责人会以 OKR 为线索通过直播向所有人汇报工作。

我们的日常议事原则是提供完整上下文、广泛充分发表意见、owner 拥有最终决定权。为了做到这些，整个 TDS 团队几乎所有的代码都是内部公开的，工作中所有的沟通都需要以公开的方式进行（比如 Slack 公开频道、Confluence / GitLab / Figma comments ），保证任何人都可以在任何时候看到整个决策过程。

这个 JD 有点长，但工程师招聘是一个相互了解与选择的过程，我们深知互相坦诚在这个过程中的重要性。因此如果你看完上面这些后，认同我们的目标与追寻目标的方式，并认为可以胜任该职位，请不吝将简历发送到 [email protected] （或者 [email protected] ，如果你想单独找我聊聊）。

感谢你的关注。