30 秒看懂
Ron Minsky 与 Jeanne Van Briesen、Matt Else 和 Grace Zhang 讨论他们在 Jane Street 的实习经历,以及转为全职后承担的工作。他们谈到交易风险控制、用户界面库和序列化,也探讨反馈、团队匹配和归属感。
- 1服务真实用户的风险控制Grace 搭建了一种方法,在保留可配置边界和硬性上限的同时,加快某些风险限额的提升。
- 2API 及其迁移Jeanne 合并了 Incr_dom 的接口,并通过语法转换帮助迁移现有代码。
- 3更广泛的全职职责嘉宾比较了范围明确的短期实习项目与需要识别问题、安排优先级的持续性工作。
- 4反馈是共同责任Jeanne 希望得到更频繁的鼓励;Minsky 认为实习项目管理者应该主动提供反馈。
要点建议
- 实习项目既可以为新人精心限定范围,也可以为真实用户创造价值。
- 导师、代码审查和课程能帮助实习生熟悉陌生的代码库和业务。
- 全职工程师有更大的空间提出项目,并权衡相互竞争的优先事项。
- 频繁反馈能帮助实习生理解正常的不确定感,让他们感受到支持。
按章节阅读整理后的全文
认识 Jane Street
嘉宾讲述自己如何了解这家公司以及申请的原因。Minsky 解释,申请者不必事先掌握 OCaml。
Ron Minsky 与 Jeanne Van Briesen、Matt Else 和 Grace Zhang 讨论他们在 Jane Street 先后担任软件工程实习生和全职工程师的经历。话题包括真实项目、转为全职的过程,以及学习大型代码库和陌生业务时获得的支持与面对的不确定感。
Jeanne 从 Carnegie Mellon 来到公司,此前在那里接触过函数式编程和 OCaml。这样的背景让她对 Jane Street 使用这门语言产生兴趣,实习则让她看到如何用它解决真实的工程问题。
Grace 通过 Harvard 的一次外展活动了解到 Jane Street,随后申请了实习。Cambridge 学生 Matt 从朋友那里听说了这家公司,对解决有分量的技术问题的机会产生了兴趣。
Minsky 强调,通常并不要求申请者事先有 OCaml 经验。面试者可以使用自己最熟悉的语言,重要的是思考和解决问题的方式。公司希望人们入职后再学习所需工具。
嘉宾回忆起进入一家交易公司时既好奇又不确定的心情。他们不必一开始就了解工作所需的全部金融背景,但需要愿意提问,并向同事学习。
实习体验
疫情前的项目将团队轮换、课程和导师指导结合起来。Grace 介绍她如何让风险限额的提升流程更安全、更快捷。
疫情之前,典型的实习安排是在两个团队各工作约六周。最初的培训介绍了技术和组织情况,实习生还一起上课、参加活动,共同摸索如何适应环境。
项目将团队工作与系统教学结合起来。实习生可以参加介绍所用工具的技术课程,学习系统背后的一些金融知识,并在完成项目的过程中向导师和审查者寻求帮助。
导师指导并不限于一次约好的谈话。项目中会有人解释代码库、审查修改,并帮助实习生找到合适的人,询问交易或设计方面的问题。
嘉宾记得工作很快就变得具体起来。他们并非只是观察员工,而是拿到了有真实用户的项目,能够看到自己的修改与团队工作方式之间的联系。
Grace 的第一个项目涉及手动录单的风险限额。交易员有时需要在多个范围内提高限额,而原有流程可能需要修改代码并经过审查。她的项目让某些限额提升更容易申请和实施。
这个区别很重要:项目并非简单地取消风险控制。允许提升的幅度可以配置,硬性上限仍然提供边界。目标是加快常见的操作调整,而不是让所有请求都不受限制。
Grace 与既了解软件又了解交易员需求的人合作。尽管她还在学习周边系统的作用,这些合作仍帮助她决定界面和适当的控制方式。
后来,Grace 以全职工程师的身份回来,从一位工具用户那里听到了反馈。看到实习项目在那个夏天结束后仍有价值,令她格外满足;这也说明工作流程的细节会在很大程度上影响工具的实用性。
交易与开发工具项目
Matt 解释手动询价的风险检查,Jeanne 则介绍 Incr_dom 的 API 与迁移。两个项目都将技术设计和向其他工程师学习结合起来。
Matt 的项目涉及询价,也就是 RFQ。Jane Street 有自动报价系统,但销售交易员也会手动处理请求。他的任务是为这一手动流程加入风险检查。
编程只是挑战的一部分。Matt 首先需要理解相关金融活动,以及为什么需要这些检查。同事向他解释业务背景,让他能够把代码与交易员需要做出的决定联系起来。
他记得公司鼓励提问,即使他觉得问题很基础。身边的人会提供背景,指出大型系统中相关的部分,而不是期待实习生独自推断整个业务的运作方式。
代码审查是这段经历的重要部分。审查者讨论设计选择,帮助他理解团队惯例。因此,审查既是修改进入代码库之前的一道关口,也是学习团队如何思考软件问题的方式。
这种协作过程也意味着实习生可以参与真正的生产工作。范围明确的项目对用户可能很重要,同时也能为新人提供可掌握的起点和指导。
大家指出,在不熟悉的系统中,即便是很小的改动也可能引出许多问题。除了学习编程语言,学会去哪里查找信息、向谁提问,也是最初几周的重要内容。
Jeanne 的实习项目是 Incr_dom,这是一个使用 Incremental 构建用户界面的库。她致力于合并一个易用接口和一个功能更强大的接口,让用户不必在便利性和能力之间做不必要的取舍。
这项工作涉及 API 设计:好的接口既要让常见情况易于处理,也要保留表达复杂行为的能力。当一个库在整个代码库中共享时,这些权衡会影响许多用户。
Jeanne 还使用了一种 OCaml 语法转换工具 PPX,帮助迁移现有代码。转换需要保留有用的源码位置,让错误信息和工具仍能将开发者指向他们实际编写的代码。
覆盖整个代码仓库的迁移让项目不只是一个独立原型。Jeanne 能看到库的修改如何影响现有用户;她说,实习结束后,这项工作的成果仍在使用。
Minsky 和 Jeanne 讨论了能够做出设计判断的吸引力,而非只完成预先规定的机械任务。导师可以提供经验和审查,但实习生仍需自行思考一个有意义的问题。
这个项目也让 Jeanne 练习如何平衡 API 的易用性和足够的表达能力。成功与否取决于其他工程师实际如何使用它,而不仅是新代码能否通过编译。
从实习生到全职工程师
嘉宾比较了范围明确的实习任务与更加开放的全职职责。他们还讨论了团队匹配、项目选择和疫情造成的打断。
嘉宾转为全职工程师后发现,实习期间熟悉过团队或代码库,并不意味着不再需要学习。Grace 说,她回来看自己写过的代码时,发现已经忘记了其中的细节。
她也接触到了更多与系统相关的金融知识,包括期权定价。成为全职员工后,她可以追问超出实习项目既定范围的问题,花更多时间理解周边背景。
实习项目必须有足够的分量,既有趣又有用,同时范围也要让新人能在几周内取得进展。全职工作的形态往往没有那么明确,决定要解决什么问题本身也可能成为工作的一部分。
Jeanne 加入 RFQ 团队后,最终部署了与 Matt 过去实习项目有关的工作。这种交集说明项目会持续演进:一位实习生贡献其中一部分,另一位工程师日后将其纳入更广泛的工作流程。
成为全职工程师后,Jeanne 也开始参与思考适合实习生的项目。角色互换让她考虑哪些问题既有足够的分量,又能在短时间内上手。
她介绍了一个拟议的实习项目,涉及 RFQ 验证、冻结和指示性报价。这项工作既需要理解用户需求,也需要决定界面及其底层行为如何运作。
春季实习因 COVID-19 中断,最终由 Jeanne 完成了这个项目。夏季项目也为适应远程工作而重新安排,其中包括让实习生只在一个团队工作,而不是在两个团队之间轮换。
Grace 介绍了她作为全职员工参与的一个项目:为 Redis 增加客户端缓存。她通过自己的指导人了解到这个可能性,将想法带给团队,发现同事愿意接受一位较新工程师的提议。
她的例子体现了职责的变化:全职员工不再只是接受固定的实习任务,还可以发现问题、提出方向,并与他人共同决定是否以及如何推进。主动权的范围扩大了,同时仍有人提供支持。
话题转向新入职的全职员工如何寻找团队。大家可以与多个小组交谈,了解各自的工作和偏好,通过这些交流找到合适的匹配,而不是盲目接受安排。
Grace 在与其他人讨论各种可能性后,选择了一个自己之前接触过的团队。熟悉感很有帮助,但这些交流也让她更清楚什么样的工作和团队环境适合自己。
共享代码与跨团队项目
嘉宾将这个项目与其他实习经历作比较,并介绍在模块化代码库中工作的体验。Matt 讲述了一个涉及其他团队的序列化项目。
谈到 Jane Street 与其他实习经历的区别时,嘉宾提到了实习生群体的规模和组织方式。共同参加的活动和课程帮助他们结识直属团队以外的人,也让他们拥有一个一起学习的群体。
Jeanne 比较了编写新代码与进入大型现有代码库的区别。在 Jane Street,她需要学习已有组件如何配合,但模块化的组织方式让她不必一次理解所有部分,就能着手其中一部分。
这段经历也让实习生接触到维护共享软件的实际问题。一处修改可能只涉及局部,但它必须适应许多依赖该软件的用户所需的接口、惯例和需求。
Matt 介绍了后来参与的一个项目,围绕名为 Zero 的序列化协议展开。与 Cap'n Proto 等系统类似,它旨在高效编码数据,同时允许格式以兼容的方式演进;当服务需要长期交换数据时,这一特性很有用。
他开发了支持该协议的 PPX,并将协议集成到市场数据场景中。问题跨越了团队边界,因此技术设计和与部署、使用该协议的人员协调都很重要。
好用的序列化 API 只是工作的一部分。现有服务必须能够采用它,负责这些服务的人也需要对迁移有信心。Matt 讲述了如何与其他团队共同解决这些实际部署问题。
与短期实习相比,这个项目给了他不同的视角:决定会影响更大的系统,需要持续讨论。他既能深入技术细节,也能学习如何推动一项变更在组织中落地。
用户、优先级与工作方式
工程师向交易员了解需求,同时平衡支持工作、功能开发与技术债务。嘉宾比较了自己对专注时间、课程和办公室交流的偏好。
Jeanne 说,与交易员交谈有助于工程师理解为什么需要某些 RFQ 功能。当她了解工作流程以及交易员试图解决的问题,而不是只看到一份修改需求清单时,就更容易安排优先级。
这种紧密联系既带来功能想法,也带来支持工作。用户遇到问题时,工程师可能需要响应;这些交流还会揭示现有工具的不足,而这些不足单靠阅读代码很难发现。
团队必须在眼前的需求、技术债务和较长期的架构工作之间取得平衡。Jeanne 介绍了如何结合真实用户的情况做取舍,Grace 则指出,跨团队使用的风险基础设施需要协调。
嘉宾再次讨论如何安排一天的工作。实习生要在课程、团队会议和项目工作之间分配注意力;对于把活动集中安排还是分散到一周中,不同人有不同偏好。
有的人希望拥有较长、不受打扰的时间段来推进工作;Jeanne 喜欢将一天分割成不同活动带来的变化,Matt 则处于两者之间。讨论表明,适合一个人的日程不一定适合所有人。
远程工作让其中一些选择更加明显。办公室里的随意交流可能更难重现,预先安排的通话也不总能替代转身向身边同事快速提问的便利。
办公室也有自己的干扰:交易员的问题和支持请求并不总是按可预测的时间出现。这些打断提供了有用的背景和与用户的联系,但也会占用工程师集中工作的时间。
嘉宾怀念一些面对面共处的体验,包括交易大厅的声音和自发交流。他们的讨论反映了公司和实习生在疫情期间进行的特定调整,而不是对所有远程工作安排作出的定论。
反馈与归属感
Jeanne 希望得到更频繁的反馈,Matt 谈到冒名顶替感。Minsky 解释了管理者为什么应主动提供鼓励和清晰的信息。
Jeanne 说,实习时如果能得到更频繁的反馈和鼓励,她会很受益。新人可能不知道沉默意味着进展顺利还是不顺利,尤其当他们把自己的不确定感与别人表现出的自信作比较时。
Minsky 认为,提供反馈是实习项目的责任,而不只是实习生主动询问的责任。管理者应该认识到,许多实习生都同样需要明确的信息和鼓励。
Matt 回忆起冒名顶替综合征带来的感受:面对陌生问题时的挣扎,会让他怀疑自己是否适合这里。Minsky 说,这种感受与表现未必相关,即使做得很好的人也可能经历它。
指导人或导师可以帮助实习生客观看待困难,解释什么样的进展是正常的。嘉宾的经历展示了一种项目安排:将有意义的工作和技术挑战,与有意识的支持及坦诚的反馈结合起来。
同频道的其他文章
1:48:29EN → 简体中文
1:05:45EN → 简体中文
1:25:00EN → 简体中文
1:16:29EN → 简体中文
1:34:29EN → 简体中文
1:34:36EN → 简体中文