Jane Street Expands Alt-Data Desk as Neural Networks Exploit Bad Inputs

神经网络易受劣质输入误导，Jane Street扩大另类数据团队规模 下游机器学习模型愈发强大，反而提升了数据工程的价值，因为神经网络会极易利用供应商的数据修正以及时点数据泄露。 Eric Mannes回顾了自己从交易能源ETF、应对2020年WTI原油负值结算等历史性异常事件，到建立Jane Street另类数据部门的历程。本次对话对比了传统财务指标与停车场卫星图像、信用卡消费样本等另类数据源，详细阐述了数据工程师必须应对的供应商混乱修正、时点数据限制以及企业实体解析等问题。Mannes还深入探讨了Jane Street本地数据仓库Superstore背后的架构，并解释了为何不断演进的机器学习模型与“苦涩的教训”（Bitter Lesson）需要更干净的数据，而非让数据工程走向消亡。 Jane Street将其专门的另类数据工程团队规模从2023年的单名员工扩展至2026年的20多名工程师，以负责为交易部门梳理混乱的非传统数据输入。 (36:46) 该公司在dbt和Trino的基础上运营名为Superstore的专有本地数据仓库，从而避免了公有云对即席探索性查询计费不利的收费模式。 (72:47) 下游深度学习模型以及萨顿的“苦涩的教训”提升了数据工程的重要性，因为强大的神经架构会极其容易利用数据泄露和事后追溯的供应商数据修正。 (69:35) 所有流入的外部另类数据均在Jane Street的系统边界被标记上精确到纳秒的时间戳，以防止在回测过程中出现前视偏差和供应商的事后泄露。 (61:30)

Jane Street trader and data engineering lead Eric Mannes argues that quantitative trading relies heavily on understanding messy physical realities and domain metadata rather than purely abstract mathematical modeling. Transitioning from embedded desk engineering to alternative data systems, Mannes illustrates how building resilient software and strictly managing point-in-time data underpins alpha generation. Physical Realities and System Assumptions in Commodity Trading (11:54) Trading commodities connects quantitative finance directly to physical infrastructure, exposing electronic risk systems to severe domain edge cases. Futures contracts introduce multi-layered mechanics—such as contract multipliers (e.g., 1,000 barrels per crude contract) and conflicting quoting conventions (dollars versus cents)—that create substantial operational metadata risk. In April 2020, this vulnerability materialized when CME West Texas Intermediate crude fell to negative $37.63 per barrel as storage at Cushing, Oklahoma reached capacity, crashing industry execution and risk systems predicated on non-negative asset values. The Evolution from Spreadsheet Fragility to Embedded Desk Engineering (22:11) To address domain-specific complexities, Jane Street transitioned from centralized infrastructure developers toward embedded "desk devs" who build tailored software alongside traders. On the commodities desk, initial risk tracking was managed via a large macro-enabled Excel file, `US commodities risk.xlsm`. While Excel provided direct data visibility, it suffered from severe calculation bottlenecks, untyped VBA meta-programming, and zero version control. Modernizing these systems required decomposing domain logic into robust OCaml systems while bridging the cost models of software engineers and the high manual pain thresholds of traders. Sourcing and Structuring Alternative Datasets for Quantitative Signal (34:19) At Jane Street, standard exchange market feeds and basic contract metadata are classified as traditional data, while nearly everything else—including corporate SEC filings and external consumer panels—is treated as alternative data. Because ad-hoc data ingestion originally led to isolated, fragile desk datasets, the firm built a dedicated alternative data organization encompassing data strategy, platform infrastructure, and data engineering. The team sources datasets from catalogs and matchmaking conferences, filtering out indirect proxies like satellite parking lot photos in favor of direct, normalized signals like consumer credit card transactions. Point-in-Time Integrity, AI Leakage, and On-Premises Architecture (61:30) The primary technical hurdle in alternative data is preserving point-in-time integrity to avoid lookahead bias during backtests. Vendors frequently revise historical series or change entity mappings, prompting Jane Street to log internal network ingress timestamps at the nanosecond level. Although large language models accelerate unstructured text parsing, Mannes warns they risk leaking future corporate outcomes into historical features, while more powerful downstream neural nets aggressively exploit uncleaned data errors. Architecturally, Jane Street processes these pipelines on-premises via Superstore, dbt, and Trino, avoiding public cloud query metering models that penalize ad-hoc exploratory research. Profile and Evaluation of Data Engineers in Adversarial Markets (78:49) Jane Street's data engineering headcount expanded from a single engineer in early 2023 to more than twenty, targeting candidates with investigative mindsets often drawn from science or startup generalist backgrounds. Mannes distinguishes data engineering from machine learning modeling and systems infrastructure, emphasizing that the role centers on untangling domain ambiguity. In interviews, candidates are evaluated on how methodically they explore unfamiliar, messy datasets, identify hidden generation mechanics, and validate hypotheses before implementing transformations. Financial markets operate as anti-inductive environments where edges decay as participants adapt, leaving low signal-to-noise price movements. Consequently, sustainable advantages rely not on one-time predictive models, but on continuously maintaining rigorous data foundations and human investigative curiosity about real-world market mechanics.

Jane Street 交易员兼替代数据业务负责人 Eric Mannes 阐述了量化交易的核心挑战：金融市场具有反归纳特征，仅靠抽象数学模型无法建立持久优势，交易与数据工程必须深入理解底层现实世界的物理机制与数据元数据。从大宗商品交割约束到清洗杂乱的另类数据，工程团队的核心价值在于弥合数据表象与现实真相之间的脱节。 反归纳市场与物理现实的约束 (0:02) 金融市场与物理世界截然不同，被 Eric Mannes 描述为“反归纳环境”。在物理学中，自然法则一旦被发现便保持恒定；而在金融市场中，交易者一旦发现可预测的模式或优势，其他参与者的跟进竞争就会侵蚀这一机会，迫使从业者持续重新探索。此外，这种对抗性动态将交易行为与现实世界紧密锚定。以大宗商品交易为例，合约不仅是屏幕上的代码，更对应着具体的实物资产交割规则与交割地点（例如俄克拉荷马州库欣交付的 1,000 桶原油或数万磅活牛）。 当系统假设脱离物理现实时，便会遭遇灾难性失效。2020 年 4 月 20 日，CME 西德克萨斯中质原油（WTI）临近到期合约结算价暴跌至每桶负 37.63 美元，起因是早期 COVID-19 封锁导致需求骤降，库欣实物储油设施容量饱和，持有未平仓多头的交易者面临无处储油的交付困境。该异常直接击穿了全行业依赖“资产价值恒为正”这一硬编码假设的自动化系统，不仅算法交易无法输入负收益率，风险引擎亦难以计算保证金。这表明量化交易不仅涉及顶层数学建模，更离不开对仓储能力、合约乘数与数据源报价规则等物理与元数据细节的掌握。 从电子表格到驻桌开发的工程演进 (22:11) 在 Jane Street 早期，开发人员主要集中于公司级核心基础设施（如行情分发、成交登记与核心撮合），交易台通常只能消费标准化数据并自行搭建临时脚本。在大宗商品交易台，日常风险监控曾高度依赖一个名为 US commodities risk.xlsm 的庞大宏启用 Excel 工作簿。尽管 Excel 在数据可见性方面具有类似函数式编程的直观优势，但该工作簿面临严重的性能瓶颈、缺乏静态类型检查的 VBA 元编程、无法在版本控制中进行差异对比以及历史技术债务累积等缺陷，最终演变成无人能完全理解的黑盒。 为消除脆弱的遗留工具，公司确立了“驻桌开发”（Desk Dev）模式，将软件工程师直接嵌入各交易业务线。通过交易背景与工程技能的协作，团队从第一性原理出发解构业务逻辑，将分散在表格中的隐式业务规则重构为经过严格类型检查的 OCaml 生产系统。这一变革不仅建立了能够跨能源大类、单一合约层级灵活切片的稳健风险引擎，也改变了交易员习惯于忍受低效临时工具的妥协文化，让专业化软件工程能力能够直接作用于复杂资产类别的实际需求。 另类数据的本质与元数据治理 (34:19) 在传统华尔街语境中，另类数据常被定义为非常规投资数据（如用卫星图像统计沃尔玛停车场的车辆数以预测营收）。但在 Jane Street，由于其电子做市商的历史背景，划分界线更为严格：除交易所实时订单流和基础合约元数据属于传统数据外，其余外部信息（甚至包括传统 SEC 财务报表）均被归入另类数据。Mannes 指出，被行业广泛推崇的停车场卫星图像在实际交易中信号微弱且噪音极大，它不仅每店每周仅有少量静态切片，且完全漏掉了占沃尔玛销售额 20% 以上的线上交易，更无法直接反映顾客的实际消费金额；相比之下，银行与支付网络提供的聚合匿名信用卡面板数据具有直接的消费映射，但也必须仔细校正样本偏差与面板人员流动问题。 哪怕是处理最标准的上市公司 SEC 季度财报，数据工程也面临深刻的本体论与元数据难题。例如在双重上市结构中，两家独立法人实体可能共享管理层和董事会，并在经济上完全等同，系统必须准确映射这些关系至具体可交易证券代码（如 ISIN、SEDOL）；此外，财报的后续追溯调整、会计周期变更以及供应商在清洗数据时对历史商户标签的回溯修正，极易导致“未来信息泄漏”。如果研究人员基于修改后的历史数据进行回测，无异于借助“时间机器”进行不可能的模拟。因此，Jane Street 坚持在数据接入其内部网络时打上纳秒级内部时间戳，严格维护时间点完整性以防止前瞻偏差。 AI 工具、苦涩教训与自建基建的经济学 针对人工智能对数据工作的冲击，Mannes 指出大语言模型（LLM）极大地提升了非结构化文本特征提取的效率，取代了繁琐的正则表达式，但也带来了新的因果陷阱：若直接使用包含未来知识的现代 LLM 提取历史数据，模型已预知安然破产等后续结果，同样会引发前瞻偏差。谈及 Rich Sutton 的“苦涩教训”（即算力扩展最终将超越手工特征工程），Mannes 强调，神经网络与深度学习越强大，它对异常值与未来泄漏的过拟合与利用就越极端，这反而大幅提升了底层数据清洗与时间点准确性的重要性，人类在数据验证与审美层面的判断成为真正的瓶颈。 在底层架构上，Jane Street 采用 dbt 进行模块化、可测试的 SQL 转换，并以 Trino 配合 Python 处理交互式查询，但在数据仓储上坚决避开 Snowflake 或 Google Cloud BigQuery 等第三方公共云方案，转而依托内部自研的高吞吐本地数据仓库 Superstore。这一选择背后是深刻的基础设施经济学考量：公共云按扫描字节或算力时间计量计费，会在研究人员探索性查询时施加直接边际成本，倒逼工程师浪费大量精力去针对云厂商账单进行防御性优化与工作负载整形；而公司本身为了超低延迟交易早已在机房部署、多播网络和 FPGA 等本地硬件上积累了深厚底蕴，通过自持物理硬件摊销资产折旧，使量化研究员能够不受财务阻碍地运行海量即席分析。 Jane Street 的数据工程实践表明，决定量化系统成败的往往不是高层抽象算法的堆砌，而是对底层数据生成机制的严谨探究。随着公司数据工程团队自 2023 年的一人迅速扩张至二十余人并建立多年期招聘渠道，其选拔标准始终聚焦于在模糊、混乱的数据中抽丝剥茧的好奇心与科学求证方法，而非单纯追求机器学习算法实现。

## Background 该内容由自营交易机构 Jane Street 于 2026 年 9 月 2 日在其官方 YouTube 频道（播客栏目 Signals and Threads）发布。节目由 Ron Minsky 主持，邀请了在公司深耕十余年、曾任大宗商品交易员并主导另类数据团队建设的 Eric Mannes，围绕如何将纷乱的外部现实世界数据梳理为可靠的量化交易数据集展开深入探讨。 ## TL;DR 对话从 Eric 在 Jane Street 的成长路径切入，回顾了他在大宗商品交易台的实战经历，以及早期交易系统过度依赖庞大 Excel 宏表格的历史与系统破局。随后，两人详细拆解了华尔街另类数据生态中的实体建模难题、因果性陷阱、点截面（Point-in-Time）数据架构以及自建机房和现代数据工具栈的权衡。最后，双方重点探讨了在 AI 与大语言模型时代，数据质量反而变得更加关键的底层逻辑，并分享了数据工程团队长周期的人才招募与实战考察标准。 ## Atmosphere & style 整场对话充满极客务实精神与风趣自嘲，不仅有资深从业者拆解高危交易场景（如原油期货负价格）时的惊心动魄，更有工程人直面“祖传巨型 Excel 表”与脏数据时的心领神会。主持人和嘉宾的互动默契而平实，在严肃探讨第一性原理、因果律泄漏和系统架构的同时，穿插着对交易员极端耐痛阈值以及数据相亲大会的幽默调侃。聆听体验就像置身于一流量化机构内部工位旁的复盘交流，理性、严密且深刻连接着物理世界的粗粝现实。 ## Bulletin - [41:44](https://www.youtube.com/watch?v=a5eirWk7xic&t=2504s) Jane Street 的另类数据团队始于 2023 年仅 1 名数据工程师的尝试，因迅速转化为交易 P&L 触发“诱导性需求”，在短时间内扩张至超 20 人，并建立了长期梯队培养体系。 - [01:12:51](https://www.youtube.com/watch?v=a5eirWk7xic&t=4371s) 针对另类数据工程，Jane Street 采用自建 IDC 与自研存储系统 Superstore，结合开源工具 Trino 和 dbt，有效避免了商业云数仓按查询扫描量计费所带来的创新抑制与成本调优负担。 - [01:09:35](https://www.youtube.com/watch?v=a5eirWk7xic&t=4175s) 前沿机器学习与大语言模型（LLM）的普及并未降低数据清洗的重要性，反而放大了未来信息泄露等因果律陷阱的风险，使点截面（Point-in-Time）数据架构与输入纯净度成为更关键的壁垒。 - [00:02](https://www.youtube.com/watch?v=a5eirWk7xic&t=2s) 金融市场具备“反归纳”属性，规律一旦公开便会被套利抹平，因此交易数据工程的本质是深入物理现实的机械细节，从混乱的现实数据中提炼出未被充分定价的真实信号。 ## Key takeaways - [00:02](https://www.youtube.com/watch?v=a5eirWk7xic&t=2s) 金融市场具有“反归纳”特性，一旦交易模式被发掘，套利力量会迅速将其利润竞价抹平，使残余价格波动趋近于随机漫步，迫使量化机构必须不断寻找新的未定价信号。 - [03:37](https://www.youtube.com/watch?v=a5eirWk7xic&t=217s) 低注码的模拟实战（如 Figgie 卡牌游戏）对于交易直觉的形成不可替代，它能促使交易员在充满不确定性与逆向选择的对抗场景下，快速推断对手方的私有信息并做出双向报价。 - [11:54](https://www.youtube.com/watch?v=a5eirWk7xic&t=714s) 期货交易与股票存在根本差异，其涉及复杂的合约乘数、度量单位换算与物理交割约束，厘清元数据（Metadata）往往是构建风控体系时最易出错的关键环节。 - [18:53](https://www.youtube.com/watch?v=a5eirWk7xic&t=1133s) 2020 年原油期货负结算价事件表明，交易与风控系统底层的固有假设（如价格必须为正）若脱离物理现实约束（如库欣储油罐爆满），极易在极端行情下发生系统性崩溃。 - [26:23](https://www.youtube.com/watch?v=a5eirWk7xic&t=1583s) 巨型 Excel 表格虽然具备直观和灵活的函数式特性，但缺乏类型安全、元编程混乱、缺少单元测试与版本控制，在核心生产与极端行情下会成为巨大的技术债务瓶颈。 - [30:40](https://www.youtube.com/watch?v=a5eirWk7xic&t=1840s) 嵌入式交易台开发者（Desk Dev）的核心价值在于架起业务与架构之间的桥梁，既把隐性领域知识翻译成形式化系统，又为交易员引入合理的软件成本模型以拓宽研究边界。 - [34:19](https://www.youtube.com/watch?v=a5eirWk7xic&t=2059s) Jane Street 内部对“另类数据”的定义具有历史路径依赖：交易所行情与核心交易元数据被视为传统数据，而上市公司官方财报文件与非结构化外部数据则统一归属于另类数据范畴。 - [49:52](https://www.youtube.com/watch?v=a5eirWk7xic&t=2992s) 数据团队分为三层分工：数据战略聚焦供需挖掘，数据基础设施产出通用的软件与平台服务，而数据工程则深入业务领域知识，交付可直接用于投研的高质量数据集。 - [53:02](https://www.youtube.com/watch?v=a5eirWk7xic&t=3182s) 即使是上市公司财报这类传统数据，在实体建模时也会遭遇“何为一家公司”的本体论难题，双重上市、股权类别多重映射及会计准则变更等细节对特征工程提出了极高要求。 - [57:00](https://www.youtube.com/watch?v=a5eirWk7xic&t=3420s) 卫星拍摄停车场等间接指标存在频次低、忽略线上消费且噪声大的局限；而信用卡样本数据虽贴近真实消费，却潜藏发卡行人群偏差、人口统计学偏离及样本出入扰动等统计缺陷。 - [01:01:30](https://www.youtube.com/watch?v=a5eirWk7xic&t=3690s) 数据供应商的回溯修正容易引发致命的前瞻偏差（Look-ahead Bias），量化回测必须严格依赖点截面（Point-in-Time）数据与本地物理接收时间戳，确保完全还原历史可获知信息。 - [01:07:23](https://www.youtube.com/watch?v=a5eirWk7xic&t=4043s) 使用大语言模型处理历史金融文本时极易遭遇因果性泄漏问题，若模型训练语料包含了未来的破产或财报信息，其提炼的特征将在历史回测中严重作弊。 - [01:09:35](https://www.youtube.com/watch?v=a5eirWk7xic&t=4175s) “苦涩的教训”在数据质量层面呈现反转：下游神经网络模型的表达能力与拟合能力越强，就越容易对微小的数据污染过度拟合，反而极大推高了严格数据清洗与工程验证的价值。 - [01:16:30](https://www.youtube.com/watch?v=a5eirWk7xic&t=4590s) 在计算架构上，公有云按量付费模式会因账单压力严重抑制量化人员的探索性全表查询，而基于自建 IDC 硬件与 Trino 的私有化方案将单次查询边际成本降至趋近于零，整体商业性价比更高。 - [01:18:49](https://www.youtube.com/watch?v=a5eirWk7xic&t=4729s) 优秀的数据工程师最核心的特质在于探究精神与对混乱现实的耐性，招聘考核重在检验候选人探索未知脏数据时的严谨假设验证能力，而非脱离业务的纯算法技巧。 ## Detailed walkthrough ### [00:02](https://www.youtube.com/watch?v=a5eirWk7xic&t=2s) 三个暑假与“反归纳”的市场本质 主持人 Ron 介绍了在 Jane Street 工作了约十年的 Eric Mannes。Eric 历任交易员、技术研发等多个跨界岗位，目前正带领团队专注推进替代数据（alternative data，简称 alt data）的研究与落地。在被问及最初是如何加入 Jane Street 时，Eric 回忆称自己本科主修数学，当年环顾身边的同学，去向大致分为三类：一部分留在波士顿等地从事学术科研，一部分前往旧金山湾区投身科技行业，还有一部分则奔赴纽约从事金融业务。既然大学有三个暑期，他便规划每个暑假分别尝试其中一个方向。经过一番比较，他发现 Jane Street 不仅是最有趣的选择，也是与自己最契合的工作环境。 进入 Jane Street 担任交易实习生后，Eric 最大的感触是学习密度的惊人。Ron 指出，金融交易与软件工程截然不同：外聘的软件工程师通常具备成熟的开发经验，但绝大多数进入交易团队的新人此前对市场一无所知。Eric 坦言，校外根本没有途径让人提前练习实盘交易或深入思考市场运作机制，而 Jane Street 的资深员工却投入了大量时间向实习生讲解底层逻辑——从逆向选择（adverse selection）到如何规范地开展量化研究。 谈及金融与物理等自然科学的区别，Eric 提到了金融市场的“反归纳”（anti-inductive）特性：在物理学中发现的客观定律不会因为被发现而失效；但在金融市场中，一旦某个模式或规律被研究出来并公之于众，市场各方就会蜂拥而上将其利润“竞价抹平”（competed away），曾经有效的规律自此失效或权重剧降，逼迫交易员必须持续发掘新规律。Ron 补充解释道，这正是金融信号的信噪比（SNR）往往极低的原因：市场本身就是一个无休止提取有效信号的庞大系统，剩下无法被解释的部分自然越来越像纯粹的随机漫步（random walk）。Eric 也指出：“当你在系统中采取行动时，其他人会做出反应并改变自身行为，这种反应是你在历史训练数据中根本看不到的。” ```mermaid flowchart TD accTitle: 反归纳市场与信息发现循环 accDescr: 展示现实世界数据如何通过市场竞争被定价，最终使信号衰减为随机漫步的循环机制 subgraph Signals ["信息发掘与定价"] A["现实世界数据<br/>（大宗商品 / 替代数据）"] --> B["交易员发掘规律与信息"] B --> C["注入实盘交易行动"] end subgraph MarketDynamics ["反归纳机制"] C --> D["市场价格形成更可靠估值"] D --> E["竞争者调整行为<br/>利润空间被竞价抹平"] E --> F["残余市场动态呈现随机漫步"] F -->|"原规律失效，驱动新发掘"| B end ``` - **大学规划的三方对照**：学术科研（波士顿等地）、科技行业（旧金山湾区）、金融业（纽约）。 - **物理规律 vs. 金融规律**：物理定律具有归纳恒常性，而金融规律具备“反归纳性”，规律一经发现便会被套利力量消除。 - **市场的信息发现职能**：交易本质上是一种妥协与激励体系，它奖励人们发掘现实世界的真相，但代价是必须通过交易行为将部分私有信息“交出去”贡献给市场价格。 --- ### [03:37](https://www.youtube.com/watch?v=a5eirWk7xic&t=217s) 模拟交易、Figgie 与低风险决策训练 针对 Jane Street 在实习生培养上投入的非同寻常精力，Ron 直言公司在打造顶级实习体验上倾注了“近乎病态的工作量”（a pathological amount of work），因为公司深信吸引顶尖人才至关重要。对于实习期间的具体学习形式，Eric 重点提到了“模拟交易”（mock trading）或低注码实操训练。他强调，抽象地探讨“什么是好的决策”毫无意义，“在实战中亲自上手操作是无法被替代的”（there’s no replacement for actually trying to do it live）。在一个必须做出明确承诺并承担选择后果的环境中实践，能带来最直接有效的反馈。 早期 Jane Street 的先驱者大都成长于传统交易所的公开喊价交易大厅（trading pits），在真实交易环境中直观体会信息流与逆向选择。但如今绝大多数传统交易池早已不复存在，公司便自主搭建了模拟证券交易所系统，设计了一到两小时的微缩对抗场景，将复杂的现实交易逻辑浓缩为时间受限的玩具模型。 Eric 举了一个名为“Figgie”的卡牌博弈游戏为例：四名玩家各自掌握关于不同花色卡牌内在价值的部分私有信息，并在场内开展交易撮合。玩家不仅需要根据自己的底牌报价，还必须仔细观察其他对手的买卖举动，推断对方掌握了何种私有信息才会做出此种反常行为，进而快速更新自己的估值模型。这种训练能让新人迅速熟悉做市商行话（例如“7个筹码买入或卖出黑桃”），学会在不确定性下敢于开出双边报价。在被 Ron 调侃问及是否看过《安德的游戏》（Ender's Game）时，两人笑称，出于牌照监管与合规要求，显然不能像小说那样瞒着实习生把模拟盘暗中切成实盘，但这种免受真实资金亏损心理重压的沙盘演练，确实极大加速了直觉的形成。 此外，两人探讨了交易博弈的本质。Ron 指出，金融市场整体是一个“小幅正和博弈”（small positive-sum game），但对单笔具体交易而言，零和博弈色彩极重；如果一方赚大钱，交易对手往往就面临巨额亏损。对此，Eric 深刻地总结道：“识别你是在与某人做一笔正和交易，还是在面对一个与你一样聪明的人、双方却对某个事实存在分歧，至关重要；在后一种情况下，你们之中必有一个人是错的，因此你必须深入反思自己为何会得出当前的结论。” - **Figgie 游戏机制**：4 名玩家各自持有部分私有信息，通过对卡牌估值进行动态双边撮合与报价推断。 - **做市语言适应**：训练新手克服心理障碍，敢于在不确定性下主动报出双向价格（如公开喊出筹码买卖特定花色）。 - **对手方认知**：面对同等聪明的对手方产生认知分歧时，必须时刻警惕自己是否才是犯错的那一方。 --- ### [08:47](https://www.youtube.com/watch?v=a5eirWk7xic&t=527s) 从实习生到大宗商品交易员：工位旁的实战复盘 转正成为正式交易员后，Eric 发现工作比实习时更加迷人。实习期间受限于知识产权与商业机密保护，许多核心策略细节无法公开讨论；而一旦以全职身份入职，整个公司真实的持仓、决策和核心战略向他完全敞开。Eric 最早被分配在大宗商品交易台（commodities desk），主要负责交易原油和天然气相关的 ETF，以及约 50% 权重由能源类标的构成的大宗商品指数 ETF。 在日常交易中，交易员需要反复审视盘面发生的每一笔交易并持续拷问核心逻辑：这些成交到底合不合理？它们是不是好交易？我们为什么要在这个点位入场？如果是一笔优秀的交易，为什么我们当时没有做更大的仓位？而如果是糟糕的交易，为什么我们不知不觉吃下了这么多头寸？ Eric 的整个成长期都是在与一位经验丰富的资深交易导师并排而坐的过程中度过的。每当市场上闪过密集的成交潮，导师转过头就会直接考问身旁的 Eric：“好了，你觉得我们现在应该怎么做？我们应该如何调整接下来的交易行为？”Eric 往往思索片刻后给出自己的应对方案，而导师通常会平静地回应：“嗯，但我们实际上要采取另一种做法。”随后，导师便会抽丝剥茧地向他拆解，当前局面下为什么还必须把宏观变量、现货交割、对冲摩擦等“这个、那个以及其他维度的因素”一并纳入考量，从而在实战中一步步重塑新人的交易框架。 ### [10:40](https://www.youtube.com/watch?v=a5eirWk7xic&t=640s) 从小处着手建立专业度与影响力 在被问及作为一名新人交易员，需要花多长时间才能提出真正影响公司交易业务的积极建议时，Eric Mannes 坦言，从小事做起其实“相当快”（“I think in the small like pretty quickly”）。其中的核心逻辑在于，大型交易机构中总有许多细枝末节是其他人无暇顾及的，新人根本不需要一开始就“比所有人更厉害”才能创造价值。 通过潜心钻研某个冷门标的，新人可以迅速建立起自己的立足点。Eric 描述了这种成长的渐进过程：刚开始只是小试牛刀，提出一些类似“我认为我们可以做这个微调，你怎么看？”的构想，并在此过程中不断建立信心；随着对业务的理解加深，负责的决策范围逐渐扩大，最终能够独立拍板更大的交易决策，并在拿不准时主动寻找他人汲取意见。 - **快速见效的途径**：选择无人关注的细分领域进行深度思考，例如成为简街（Jane Street）内部对某只特定 ETF 及其交易动态最了解的“本土专家”。 - **成长曲线**：从小规模的建议与频繁反馈起步，逐步扩大舒适区，最终过渡到能够自主做出重大决策。 ### [11:54](https://www.youtube.com/watch?v=a5eirWk7xic&t=714s) 期货合约、乘数陷阱与元数据泥潭 谈及自己早期成为专家的“冷门角落”，Eric 回忆起了简街当年系统升级的时期。当时公司的交易系统相对较慢，正逐步推行快上约两个数量级的新一代系统。虽然新系统仍不及行业最前沿，但需要有人去深入分析并优化利用方案，评估速度提升究竟带来了哪些收益，或者错过了哪些机会。作为有时间钻研的新人，Eric 接下了这项任务。 随后，Eric 深入探讨了他在大宗商品交易中耗费大量心力研究的领域：**期货与股票在风险考量上的根本差异**。在股票交易中，风险计算直截了当，单笔交易的现金流起点就是简单的“价格 × 数量”。然而在期货世界中，这种直觉会被完全打破。期货本质上是一份在未来特定时点基于某种基准进行现金结算或实物交割的协议。这其中充斥着极度抽象且碎片化的行业惯例： ```mermaid flowchart TD accTitle: 期货交易与风险计算的复杂度来源 accDescr: 展示期货交易中从报价到底层头寸与风险计算的各层抽象转换 subgraph Quoted["市场报价层面"] P["盘口显示价格 (例如: 1 桶原油或 1 磅活牛)"] Tick["合约代码与单位 (美元 vs 美分)"] end subgraph Multiplier["元数据与乘数转换"] M["合约乘数 (例如: 原油 1,000 桶 / 活牛 20,000+ 磅)"] Unit["货币与度量单位对齐 (×100 换算因子)"] end subgraph Position["实际风险与交割敞口"] Notional["真实名义价值 = 报价 × 乘数"] Delivery["物理交割风险 (俄克拉荷马库欣仓储) / 保证金每日划转"] end P --> M Tick --> Unit M --> Notional Unit --> Notional Notional --> Delivery ``` - **标的结算规则的琐碎性**：标普 500 指数期货（S&P 500 futures）锚定的是特定时点的成分股一篮子价值（关于是开盘价还是收盘价、具体是哪个月份的周五、在哪家交易所结算，现场两人甚至展开了笑谈）。 - **实物交割的现实约束**：买入原油期货意味着同意按某种指数结算，或在俄克拉荷马州库欣（Cushing, Oklahoma）接收 1,000 桶实物原油；活牛（Live Cattle）期货则涉及数万磅牛肉的交割。作为金融机构，简街显然无意在库欣接盘原油，也没有地方存放两万磅牛肉。 - **保证金与价差符号惯例**：期货通过交易所保证金制度进行每日盯市结算（Mark-to-Market）。交易跨期价差（Calendar Spread）时，头寸会拆解为两个不同月份的独立合约（例如做多 9 月合约 CL U6，同时做空 10 月合约 CL V6）；而在标普 500 期货价差中，符号正负的定义甚至恰好相反，光看代码记号根本无法确定方向。 - **致命的乘数（Multiplier）与元数据差异**：期货盘口报价通常仅显示 1 桶油或 1 磅牛的价格，但实际合约名义价值包含乘数（如原油乘数为 1,000）。更为危险的是，不同数据源提供的报价单位经常不一致（例如有些按“美元”报，有些按“美分”报，存在 100 倍的差距）。正如 Eric 所强调的： > “And as long as you always keep track of which prices correspond to which multipliers and never mix up the two, you won't accidentally trade 100 times less or, much worse, 100 times more than you intended.” > —— Eric Mannes 主持人 Ron 补充指出，从风险控制的角度来看，理想的架构是让风控系统退后一步，脱离具体交易策略的细节，在外围设立一道刚性防线。然而，由于金融世界中充斥着各类不必要的复杂约定，厘清合约细节的“元数据问题”（Metadata Problem）反倒成了构建风控系统时最棘手、最容易出错的环节。 ### [18:53](https://www.youtube.com/watch?v=a5eirWk7xic&t=1133s) 原油期货负价格与打破常识的现实系统 元数据与规则不仅复杂，交易和风控系统底层写入的固有假设有时还会被物理现实无情击穿。最典型的案例发生在 2020 年 4 月 20 日，芝加哥商品交易所（CME）即将到期的 WTI 原油期货结算价历史性地下跌至负数。 常识认为商品之所以叫“商品”（Goods），是因为它们天然具有价值（“Goods are good”），购买它们理应支付正数金额。但当时的情况是：受全球宏观环境影响，需求出现断崖式下跌，而供应依然严重过剩；原油实物交割地俄克拉荷马州库欣的储油罐接近饱和，市场上没有任何多余空间可供存放原油。对于即将到期合约的多头而言，如果无法承接实物，就必须平仓或转仓。由于当天没有任何买家愿意进场承接实物交割，多头不得不倒贴巨资求人接盘，造成了结算价为负的极端现象（尽管随后几天的最终结算价重回正值）。 这一极端异象给量化与风控系统带来了毁灭性打击： - **系统底层假设失效**：绝大多数电子交易和报单系统的校验逻辑都默认“资产价格永远为正”。面对负价格时，报单系统甚至无法理解什么是“-100% 的回报率”，导致本应在剧烈波动中提供流动性的做市商系统彻底瘫痪，无法向交易所报单。 - **跨资产定价模型崩溃**：对于依赖原油价格输入来对其余金融资产（例如石油公司股票、衍生品）进行联动定价的模型，直接将负价格作为自变量传入，会导致衍生出的所有理论定价彻底失真。 针对这一事件，主持人总结道，交易从来不仅仅是精巧的数学建模、高深算法与顶尖技术栈的结合；在很大程度上，它要求交易员深涉现实世界的泥潭（“a bunch of grotty detail”）。你必须透彻理解底层市场的机械结构、结算机制，甚至必须清楚知道俄克拉荷马州库欣究竟还剩下多少立方米的储油空间——现实物理世界中那些看似琐碎的细节，随时都会反向重塑金融交易系统的运行逻辑。 ### [22:11](https://www.youtube.com/watch?v=a5eirWk7xic&t=1331s) 大宗商品交易与嵌入式交易台开发者的兴起 谈及量化交易公司，外界往往会联想到高科技、超高性能计算以及精深的数学模型。虽然这些确实是交易的一部分，但作为一名高效的交易员，深入理解现实世界运转的细节同样不可或缺。在大宗商品（commodities）领域，这一特征表现得尤为明显：交易员买卖的标的物——如原油和小麦——深深扎根于物理世界，是人类实际生产、消费，甚至偶尔需要进行实物交割的物品。 在专注于交易业务的同时，Eric Mannes 也参与了交易台内部技术架构的搭建。当时 Jane Street 的软件研发模式正经历一场“相变”（phase shift）。早期的软件工程师主要集中开发支撑全公司交易的核心底层基础设施，例如通用交易系统、市场行情数据管道（market data）和成交确认系统（bookings pipeline）；而大宗商品或美国本土 ETF 等具体业务台的交易员只负责接入这些系统，极少亲自参与系统研发。随着工程资源的扩充，公司意识到针对大宗商品这类具有独特业务痛点的交易台，有必要量身定制专有系统。这一转变并非一蹴而就，而是随着各交易台对技术需求的紧迫程度，在数年间陆续推进。如今，Jane Street 的每一个交易台都已经配备了嵌入式的交易台开发者（desk devs）。 - 交易台开发者（Desk Dev）模式的演进：从早期的“全公司集中式核心基建团队”逐步过渡到“各业务线内嵌专用开发者团队”。 - Eric 的背景优势：作为前技术实习生并参加过 OCaml 新兵训练营（OCaml boot camp），他在交易团队中具备较强的工程技术背景，因此承担起构建大宗商品专有交易系统的初期规划工作。 ### [24:43](https://www.youtube.com/watch?v=a5eirWk7xic&t=1483s) 庞大的 Excel 表格：US commodities risk.xlsm 大宗商品交易面临的一大技术挑战是多层级的风险敞口（risk exposure）监控。交易员在观察能源类持仓时，可能需要随时在不同的抽象层级之间无缝切换：从宏观的整体能源敞口，细化到纯原油相关产品，再下钻到西得克萨斯中间基原油（WTI Crude Oil），甚至精细定位到某一品种具体的 11 月合约。交易员必须随时下钻追踪风险的根本来源。 在专门的系统建成前，大宗商品台的整套风险监控完全依赖一个名为 `US commodities risk.xlsm` 的巨型 Excel 文件。交易员每天点击一个按钮，宏程序便会拉取成交和持仓数据并执行计算。这个工作簿是由精通 Excel 且深谙商品交易业务但并非专业软件工程师的人员多年累加构建而成的。系统运行缓慢，虽然大部分时间能用，但偶尔会在关键时刻罢工。要想实现更雄心勃勃的业务功能，团队意识到必须回归第一性原理，从底层打好基础，用健壮可靠的软件体系将其彻底替换。 ### [26:23](https://www.youtube.com/watch?v=a5eirWk7xic&t=1583s) 作为函数式编程语言的 Excel 及其工程局限 针对 Excel 的评价，Ron Minsky 与 Eric Mannes 指出，没有深度使用过 Excel 的人往往低估它的强大，而高频深度用户则深知其局限。Excel 提供了极佳的数据可视化检查方式、极高的灵活性，而且在很多关键层面上非常易于调试。Eric 将其视为世界上使用最广泛的函数式编程语言，甚至随着 Microsoft 引入 Lambda 表达式与 Let 绑定（Simon Peyton Jones 等人参与了其设计），Excel 的函数式特质更加纯粹。 在 Python 等传统编程语言中，代码逻辑直接摆在眼前，而数据在被显式可视化前是隐藏的；Excel 则相反，数据居于核心显眼位置，计算逻辑隐藏在单元格之后，这对于依据即时数据作决策的用户而言非常直观。然而，用它作为核心生产系统存在严重的工程缺陷： 1. **极端行情下的性能瓶颈**：在平常时段运行尚可，但在市场波动最剧烈的关键时刻，性能往往急剧恶化。 2. **缺乏类型安全的元编程**：该系统本质上是一种“单元格元编程”（cell meta programming）。交易员不是直接写单元格公式，而是写一堆嵌套的 Visual Basic (VBA) 宏代码，点击按钮后由程序生成包含持仓、交易以及分析公式的整张工作表。缺少编译器的类型检查和鲁棒的单元测试机制，极难捕获隐蔽错误。 3. **版本控制缺失与技术债堆积**：Excel 无法像常规源码那样进行版本控制。为了在跨表格迁移时定位逻辑，Eric 曾专门编写了一个针对 Excel 的搜索工具（Excel grep utility），用以快速搜索单元格公式及 VBA 宏代码。长年累月下来，任何人随手在某个角落写下的临时分析公式都会永久留存，“最终会演变成谁也无法完全搞懂它到底在做什么的局面”。 ```mermaid flowchart TD accTitle: Excel Risk System Architecture and Flaws accDescr: Visual Basic macros pull trade data, dynamically generate formulas into Excel, but suffer from version control, performance, and maintenance bottlenecks. subgraph DataIngestion["数据与自动化层"] A["交易与持仓数据 (Trades & Positions)"] B["VBA 宏脚本 (Nested Macros)"] end subgraph ExcelWorkbook["US commodities risk.xlsm"] C["动态生成的单元格公式 (Cell Meta-Programming)"] D["临时留存的分析逻辑 (Ad-hoc Legacy Formulas)"] E["多层级风险报表 (Energy -> Crude -> Contract)"] end subgraph Bottlenecks["维护与运行瓶颈"] F["无静态类型检查与单元测试"] G["版本控制极其困难"] H["极端行情下性能严重下降"] end A --> B B -->|"点击运行，动态构造工作表"| C C --- D C --> E B -.-> F C -.-> G E -.-> H ``` ### [30:40](https://www.youtube.com/watch?v=a5eirWk7xic&t=1840s) 消除交易员与工程师之间的鸿沟 彻底替换该表格的最大难点在于，这套旧宏表格中蕴含着无数没有文档记录的隐性领域知识（tacit knowledge）。Eric 在其中承担了双向“翻译官”的角色：将交易员头脑中的业务知识，提炼成软件工程师能够直接理解并构建健壮架构的形式化描述。他帮助工程团队理清系统的基本要素（basic atoms）、输入源及其组合方式，画出从原始输入到最终风险敞口的流向图，使得工程师能够放心地分块构建并组装。 与此同时，这种沟通也反哺了交易团队。非技术出身的领域专家往往想象不到专业软件能将工作流优化到何种地步。Ron 笑着调侃 Jane Street 交易员普遍具有极高的“耐痛阈值”（high pain thresholds）：“如果必须对着桌子磕三次头再打自己一巴掌才能让机器吐出钱来，他们就会一遍又一遍地那么干。”他们早已习惯了在残缺简陋的工具下受罪，甚至意识不到自身需要更优秀的工具。正如 Eric 指出的，一名优秀的交易台开发者最关键的作用之一，就是站出来果断叫停： > “不，你们绝对不能再用那种方式干活了。如果我们打造出这个新工具，那些现在做起来极其痛苦或者根本没人敢去做的研究分析，就会变得容易得多。” ### [33:44](https://www.youtube.com/watch?v=a5eirWk7xic&t=2024s) 工程师与交易员的沟通与成本模型 工程师在与交易员沟通时，核心不仅在于汇报技术细节，还在于传达一个清晰的“成本模型（Cost Model）”。交易员往往并不清楚某些改进在工程实现上的真实代价——有些看似极难的改动实际上成本极低，而某些看似简单的要求却极其昂贵。通过建立准确的成本模型，工程师能帮助交易员理解技术边界与可行性。 然而这并不仅关乎成本核算。拥有独特技术视角与专业知识的工程师，可以直接为业务带来突破性的想法。正如 Eric Mannes 所言，他们的根本使命不是被动执行任务，而是：“我是一个拥有这套特定技能和知识的人，我的职责是帮助 Jane Street 做出最优秀的交易（It's like I am someone with like this particular set of skills and knowledge and my job is to help Jane Street, you know, do the best trades）。” ### [34:19](https://www.youtube.com/watch?v=a5eirWk7xic&t=2059s) 什么是另类数据（Alt Data）？ 华尔街通常将“另类数据（Alternative Data）”定义为在传统投资决策中未被常规使用的数据。Ron 调侃这种命名方式极不稳定——随着某种数据被越来越多人使用，它是否就会褪去“另类”的标签？华尔街最经典的另类数据范例是卫星拍摄的沃尔玛停车场照片：通过统计车位上的车辆数量来推算客流量，车多则生意兴隆，车少则是利空信号。 相比之下，“传统数据（Traditional Data）”指的是交易所的订单与成交行情、基础标的资产信息，或者像沃伦·巴菲特（Warren Buffett）研读公司年报时关注的资产负债表与利润表。 然而在 Jane Street，另类数据的定义有着独特的历史路径依赖（Path Dependency）。Jane Street 最初以做市商（Market Maker）起家，随后逐步扩展到其他投资领域。因此在公司内部，交易所实时行情数据和维护交易、风控、记账所需的基础元数据（如乘数）被划归为“传统数据”，由专门的 Market Data 和 Metadata 团队负责；而上市公司向 SEC 提交的官方财报文件、卫星图像等在传统机构眼中的基础数据，在 Jane Street 却全部被归入另类数据团队的范畴。 ```mermaid flowchart TD accTitle: Jane Street 与传统华尔街的数据分类差异 accDescr: 对比传统金融界与 Jane Street 在传统数据和另类数据分类上的边界划分 subgraph Street["传统华尔街分类"] T1["传统数据: 行情、财务报表、SEC 申报文件"] A1["另类数据: 卫星图、信用卡消费、非结构化数据"] end subgraph JS["Jane Street 内部实际分类"] T2["Market Data & Metadata 团队: 交易所实时行情、核心交易标的元数据"] A2["Alt Data 团队: 卫星图、SEC 财务文件、其他所有外部采购数据"] end ``` ### [36:46](https://www.youtube.com/watch?v=a5eirWk7xic&t=2206s) 另类数据团队的诞生与“各显神通”的早期时代 在 Jane Street，员工拥有极大的自主权：“在 Jane Street，只要是正确的事情，你想做什么都可以。你的工作不是维护某一个特定系统，或者交易某一种特定产品，你的职责是帮助公司实现长期 P&L 的最大化（At Jane Street, you can do whatever you want as long as it's the right thing to do. Your job is not to maintain this one system or to like trade this one product. Your job is to, you know, help Jane Street like maximize its P&L over long term）。”只要发现一个值得投入且能为公司创造价值的问题，任何人都可以主动推动解决。 在专门的另类数据团队成立前，Jane Street 的外部数据管理处于高度分散和去中心化的状态： - **各桌面各自为政**：大宗商品（Commodities）桌面、国内 ETF 桌面等各自提出采购需求，数据供应商管理团队完成商务采购后，由各桌面的交易员、开发人员或桌面运维工程师（TradeOps）自行接入。 - **基础设施混乱**：引入的数据往往散落在庞大的 NFS（网络文件系统）共享目录的某个角落，或者随意存放在某个数据库中。 - **重复造轮子**：接入管道的交付质量通常只有理想状态的 60% 左右。处理数据的人日常职责并非构建数据管道，缺乏通用复用思维，也很少考虑全公司的共享需求。 Eric Mannes 敏锐地发现，公司的实时行情流处理基础设施极其先进，配备了专门的架构和工程团队，但用于处理其他所有外部数据的基础设施却相当薄弱。由于外部数据极其难用且难以导入内部环境，研究人员甚至无法从中挖掘出本应存在的交易机会。 ### [41:44](https://www.youtube.com/watch?v=a5eirWk7xic&t=2504s) 从小步快跑验证到数据工程的“诱导性需求” 面对庞大的混乱现状，Eric 和早期成员（包括曾作客播客的开发人员 Jacob 及极少数数据工程师）选择从小规模实验切入，而非直接推倒重建： 1. **攻坚核心痛点**：挑选一个基础但使用体验极差的核心数据集，投入精力彻底理清其数据模型和极端边界情况（Edge Cases）。 2. **释放商业价值**：当这组数据被彻底清洗并变得开箱即用后，研究员和交易员立刻从中发现了以往被数据噪音掩盖的交易信号，直接转化为公司真金白银的收益（P&L）。 3. **推动团队规模化**：直观的商业回报让全公司意识到专业数据工程的巨大价值。 Jane Street 直到 2023 年才正式聘用了公司历史上的第一位数据工程师（Data Engineer）。随着优秀工程实践带来的成效显现，各部门对高质量数据管道的诉求出现爆发式增长，形成了典型的“诱导性需求（Induced Demand）”——越多人看到数据工程的威力，就有越多的业务想要接入这套工具。从 2023 年最初的 1 人起步，该团队在短期内迅速扩张到了 20 余人。 ### [44:12](https://www.youtube.com/watch?v=a5eirWk7xic&t=2652s) 数据战略团队与供应商市场 另类数据团队并非全由纯工程人员组成，其中一个核心分支是**数据战略（Data Strategy）**团队。 - **对内沟通**：深入各交易桌面，理解交易员当前正在攻坚的问题，以及拥有更优质的数据后能够解锁哪些潜在策略。 - **对外挖掘**：走入外部生态，对接复杂繁琐的数据供应商市场，参加各类行业会议，并与 Neudata 等专业的数据目录与评估机构（Data Catalog Companies）密切合作。 - **业务定位**：数据战略团队不直接编写工程代码，其核心使命是精准摸清 Jane Street 的内部需求与外部商业数据的供给情况，促成两者之间的匹配，为后续的数据工程管道搭建提供最源头的原料保障。 ### [45:38](https://www.youtube.com/watch?v=a5eirWk7xic&t=2738s) 数据市场的“速配相亲”与买卖双方生态 在金融另类数据领域，数据供应商与数据需求方之间存在着一套独特且成熟的撮合机制。市场上存在专门对各类数据进行整理编目的服务商，像 Jane Street 这样的数据买家会付费订阅这些数据目录。此外，这些中介机构还会组织专门的数据行业大会，把买卖双方聚集在一起，安排类似“速配相亲”（speed dating）的交流环节。 Eric Mannes 解释道，买家在参会前会阅读大量供应商的资料简介，圈选出“我想和这些机构聊聊”，随后系统会安排十几次、每次 10 到 15 分钟的连续面对面会谈。在短短十几分钟内，卖方向买家介绍自己的数据产品，买家则抓紧提问，以快速判断这套数据是否值得引入。 Ron Minsky 开玩笑地问，参会时是不是就像相亲一样端着一杯霞多丽白葡萄酒边喝边聊。Eric 笑着回应：“通常是聊完之后才去喝酒。”在那样的会场里，现实情况往往是聊完一部分后心想“这确实挺有意思，但我看我们不合适”，而遇到真正匹配的供应商，则会留下名片和电话，约好后续深入详谈。 关于这个双边市场的参与者画像，Eric 和 Ron 梳理了核心的买方与卖方群体： - **买方群体**：不仅包含像 Jane Street 这样的自营交易公司，还涵盖各类多策略（multistrat）对冲基金、中小型资产管理公司、投资银行，以及越来越多开始买入另类数据的私募股权（PE）基金，其目的都是为了支持投资决策、量化分析或宏观研究。 - **卖方群体**：包括提供卫星遥感图像（例如监控沃尔玛停车场车流）的卫星公司；覆盖全行业海量数据集的传统金融巨头（如 Bloomberg、S&P、Refinitiv/LSEG）；深耕特定垂类的专业机构（如专注消费者信用卡交易数据的公司）；以及在日常经营中无意间沉淀了大量“废气数据”（exhaust data，即副产品数据）并尝试将其变现的普通实体企业。 ```mermaid flowchart LR accTitle: Alternative Data Two-Sided Market accDescr: Diagram showing data sellers, the matching platform, and data buyers in the alternative data ecosystem. subgraph Sellers["数据卖方 (Sellers)"] S1["卫星影像供应商"] S2["传统巨头 (Bloomberg, S&P)"] S3["垂直领域商 (消费交易)"] S4["拥有废气数据的实体企业"] end subgraph Platform["撮合平台 / 行业大会"] M1["数据目录索引"] M2["10-15分钟速配相亲"] end subgraph Buyers["数据买方 (Buyers)"] B1["自营交易公司 (如 Jane Street)"] B2["对冲基金 (多策略/量化)"] B3["资管公司 & 投行"] B4["私募股权基金 (PE)"] end Sellers --> M1 M1 --> Buyers Platform <--> Sellers Platform <--> Buyers ``` --- ### [48:45](https://www.youtube.com/watch?v=a5eirWk7xic&t=2925s) 交易视角与广告投放对数据隐私的本质分歧 当讨论到金融领域与其他行业（如广告营销）对数据的使用差异时，Ron 提到很多消费类数据同样会被用于精准广告投放。Eric 指出，量化交易与广告变现在底层需求上存在根本不同：交易机构对于“具体个人是谁”没有任何兴趣。 交易机构关心的是宏观或聚合层面的消费趋势，比如大众最近在 Lululemon 上的消费金额是不是变多了，或者奥利奥饼干和丽兹饼干（Ritz crackers）的销量走势如何。研究人员需要的只是用于加权统计的人口统计学标签，或者“买了商品 A 的人是否大概率会买商品 B”这种关联分析，完全不需要刺探个人身份标识。 相反，在广告营销领域，尤其是微定向投放（micro targeting）场景下，识别并定位到具体的某一个个体，往往正是该业务的核心诉求所在。 --- ### [49:52](https://www.youtube.com/watch?v=a5eirWk7xic&t=2992s) 数据战略、数据基础设施与数据工程的分工 围绕数据的全生命周期，Jane Street 内部形成了一套清晰的职能划分，涵盖数据战略（Data Strategy）、数据基础设施（Data Infrastructure）以及数据工程（Data Engineering）。 ```mermaid flowchart TD accTitle: Data Roles and Responsibilities accDescr: Three pillars of data operations showing strategy, infrastructure, and engineering workflows. subgraph Strategy["数据战略 (Data Strategy)"] DS1["第一性原理思考：需要回答什么问题？"] DS2["寻找数据源：目录检索与主动发掘未售数据"] end subgraph Infra["数据基础设施 (Data Infrastructure)"] DI1["摄取、转换通用框架"] DI2["流水线监控与基础构件"] DI3["产出：软件、系统与底层服务"] end subgraph Eng["数据工程 (Data Engineering)"] DE1["搭建具体业务流水线"] DE2["理解数据领域知识与业务建模"] DE3["产出：可直接用于投研的高质量数据集"] end DS1 --> DE2 DS2 --> DE1 DI1 --> DE1 DI2 --> DE1 DE1 --> DE3 ``` 数据战略关注数据源与数据消费点之间的匹配：一方面通过外部目录寻找已知的数据产品；另一方面则从第一性原理出发，推导当前交易需要回答什么底层问题、哪类数据能够解答该问题，并主动寻找可能持有这些数据的实体——即使对方目前并没有将该数据作为商业产品出售，也可以通过合作推动其开发出新产品。 关于后两者的区别，Eric Mannes 总结道：“数据基础设施的产品是软件、系统和服务，做这块的人绝大多数是我们通过标准软件工程招聘流程招进来的；而数据工程同样是工程师，但他们的产品是一个优质的数据集。” - **数据基础设施**：聚焦通用的摄取、转换工具以及监控数据流水线（pipeline）的底层积木，属于纯正的软件工程范畴。 - **数据工程**：负责将外部数据接入公司内部，清洗转换成研究员和交易员能够直接用于量化回测的结构化形式。数据工程师不能只做机械的代码搬运，他们必须深入理解数据背后的业务领域：“这套数据究竟在对什么现实实体进行建模？”从而决定 Jane Street 该如何正确使用它。 --- ### [53:02](https://www.youtube.com/watch?v=a5eirWk7xic&t=3182s) “究竟什么才是一家公司？”——传统财报数据的实体建模难题 尽管流水线编写本身是代码层面的工作，但数据工程的难点往往在于对领域内“字段含义”的解析。为了说明这种复杂性，Eric 举了一个完全不“另类”的反例：上市公司财务报表。 在美国，上市公司每季度都会向 SEC 提交财报文件（如 10-Q、10-K），同时发布新闻简报。这些文档大多是 PDF 或非结构化的大段文本，市场上虽然有供应商专门将其解析并转换为表格数据出售，但真正落到交易系统中时，立刻会遭遇哲学般的本体论难题。正如 Eric Mannes 所言：“让我们从头开始思考：究竟什么才是一家公司？” 现实商业世界中充斥着复杂的法律与组织架构。例如所谓的“双重上市公司”（dual-listed companies）：公司 A 与公司 B 在法律上完全独立，互非母子公司，甚至在不同的国家上市；但它们却共享同一套管理团队、同一个董事会，并通过跨公司协议紧紧绑定在一起，使得持有 A 公司的股票在经济利益上与持有 B 公司完全等价。 这种结构给数据工程师带来了极大的挑战： - 当供应商推过来一行财报数据时，它代表的到底是指 A 公司、B 公司，还是两者合并后的实体？ - 在映射到具体的可交易证券（securities）时，这个财务指标究竟适用于该实体旗下的所有股票，还是仅对应特定的某个股份类别（share class）或某个特定的上市挂牌（listing）？ - 证券元数据（metadata）的命名极其繁杂，国际通用的 ISIN 码、基于不同结算系统的 SEDOL 码各不相同，同一实体在不同系统中的表示方式多达上百种。 此外，上市公司还会频繁发布修正财报，变更财年日历（fiscal calendar）或调整会计核算准则，导致不同时期的历史数据无法直接对齐。数据工程师必须严密审查时效性问题，精确界定“在历史上的具体哪一个时间点，哪一部分数据是真正为人所知的（knowable）”，才能为量化模型提炼出真正可用、不产生未来信息泄露的特征。 ### [57:00](https://www.youtube.com/watch?v=a5eirWk7xic&t=3420s) 卫星停车场照片的局限与信用卡样本数据 Ron 提出一个跳出传统元数据（metadata）范畴的问题：在面对那些数字本身含义模糊、可能存在误差、或者对不同公司具有完全不同意义的领域特定数据时，数据工程团队该如何理解并处理？Eric 顺着这个话题提到了另类数据界最经典的老案例——沃尔玛（Walmart）停车场的卫星照片。Ron 笑着调侃这简直是老掉牙的例子，就像人们总喜欢探讨“坐飞机向下看数车位算不算内幕交易”一样，并询问这种照片到底算不算高质量的数据源。 Eric 直言不讳地指出，他不认为这是个好数据源，甚至打趣说这期播客发布后，自己的 LinkedIn 大概会被一群兜售停车场照片的数据供应商挤爆。Eric 解释道，这类数据极其麻烦且充满噪声：不仅拍摄成本高昂、单店单周的照片频次很低，而且它完全无法捕捉线上消费（沃尔玛线上销售额已占 20% 以上，其他品牌甚至更高），也根本无法衡量纽约市等非驾车主导城市的消费习惯。更根本的是，数车位是一种极其间接的指标，“到店客流”与“实际消费金额”根本不是一码事。 从第一性原理出发，最清楚消费者花了多少钱的只有三方：沃尔玛自身（但只在季度末财报公布）、消费者本人（逐个询问不切实际），以及金融支付机构。银行、Visa 和 Mastercard 网络、或者为各大信用合作社（credit unions）提供借记卡和信用卡底层技术支持的基础设施公司，天然掌握着真实的刷卡数据。如果这些机构愿意提供匿名化（anonymized）或汇总后（aggregated）的统计数据，量化机构就能获得一组持卡人群体（panel）的真实消费画像。 ```mermaid flowchart TD accTitle: 从交易源头到另类消费数据的流转与偏差 accDescr: 展示消费者刷卡后数据经金融机构脱敏再到量化分析的过程以及潜在偏差 subgraph Source ["数据生成端"] C["消费者消费"] --> B["发卡行 / 支付网络 / 信用社"] B -->|脱敏与聚合统计| P["信用卡 Panel 数据集"] end subgraph Biases ["样本偏差与建模挑战"] P --> D["人群偏好偏差<br/>(信用社持卡人 vs. 高端卡持卡人)"] P --> G["人口结构偏差<br/>(偏离全美整体消费结构)"] P --> S["样本进出扰动<br/>(总样本量变化 vs. 真实消费额变动)"] end subgraph Action ["工程与交易协作"] D --> M["调整模型与跨源交叉比对"] G --> M S --> M end ``` 然而，信用卡样本数据同样存在棘手的统计缺陷： - **非随机抽样**：样本仅覆盖特定发卡行或信用合作社的网络，持有信用合作社卡的人群与持有 Chase Sapphire Reserve（摩根大通蓝宝石高端卡）的高净值人群消费习惯大相径庭。 - **人口统计学偏离**：样本人群在地域、年龄和收入分布上无法完全代表全美整体结构。 - **样本流动与扰动**：消费者会不断加入或退出样本池。如果监测到的沃尔玛消费额增加了，必须厘清这究竟代表单客消费上升，还是仅仅因为样本库整体膨胀。 ### [01:01:22](https://www.youtube.com/watch?v=a5eirWk7xic&t=3682s) 供应商的修订困局与点截面（Point-in-Time）数据 面对这些样本偏差与噪声，Ron 询问这套建模、校准和交叉对比工作究竟属于数据工程，还是属于交易台（trading desk）。Eric 回应称这是两者的结合：虽然一部分工作发生在交易台，但其基石完全依赖于数据工程师对这套数据集底层运作机制、数据在何时提供了何种信息的深刻理解。 Ron 进一步指出，上游供应商所做的聚合与匿名化处理本身就可能引入难以察觉的系统性偏差。Eric 对此深有体会，表示供应商在数据处理上常常漏洞百出：有时会突然缺失数据；有时宣称某列指标是用某种算法生成的，很久之后才轻描淡写地承认“算错了，请替换成新数值”；更有甚者，商户与对应股票代码的映射规则随着时间被供应商不断优化修补，导致原本归属于 A 公司的交易记录被追溯改写为 B 品牌。 这种回溯修正直接引出了量化研究中最致命的因果律陷阱。如果研究人员根据供应商修正后的“完美历史数据”进行回测，评估当初若订阅该数据是否能赚到钱，本质上是在用“时光机”作弊，暗中偷渡了未来信息。Eric 强调了点截面（Point-in-Time）数据架构的绝对重要性： > “如果供应商说‘这就是我们在某个特定时刻交付的真实内容，而这是在另一个时间点修正后的版本’，那是我们最喜欢的。” 由于并非所有供应商都能做到如此规范，简街（Jane Street）建立了一套不依赖供应商诚信的工程防线：无论数据何时流入，系统都会完整持久化原始接收状态并打上本地接收时间戳。Ron 指出这与简街处理交易所行情（market data）的做法完全一致——交易所的时钟可能会出现不同步或漂移，因此机构最信任的永远是数据包触达自身网络边界时的纳秒级时间戳。 - **因果律污染风险**：回测修正后的数据模拟的不是“订阅该数据能做出的交易决策”，而是“拥有时光机时的未来表现”。 - **时间戳防御机制**：通过严格记录内部接收时间戳，确保后续无论执行何种业务清洗与转换，量化模型都能精准复原出“在历史特定时点上我们究竟可知什么”。 ### [01:06:08](https://www.youtube.com/watch?v=a5eirWk7xic&t=3968s) AI 浪潮对另类数据工程的双重冲击 在探讨完底层数据捕获与清洗之后，Ron 将话题转向近年来技术格局的最大变量——人工智能（AI）。Ron 指出，AI 在简街内部正在两个平行维度上重构工作流：一方面，越来越多的前沿机器学习模型和神经网络被直接接入交易决策管线以消化海量数据；另一方面，极度强大的大型语言模型（LLM）成为了日常工程中的通用生产力工具。他询问这种技术跃迁如何重塑另类数据团队的角色。 Eric 赞同这一划分，并指出机器学习模型的进化从根本上拉高了数据工程的战略价值。当团队拥有了更强大的模型去从复杂世界中捕捉细微模式并生成高质量预测时，输入端的质量就成为了整套飞轮的核心瓶颈： > “这意味着我们所有数据、高质量数据集的价值，就这么直接提升了。” ### [01:07:23](https://www.youtube.com/watch?v=a5eirWk7xic&t=4043s) 大语言模型、特征提取与数据因果性陷阱 在非结构化文本处理上，大语言模型（LLM）展现出了前所未有的威力。过去从海量文本中提取结构化特征不仅极其繁琐，而且往往是一堆难以维护的正则表达式（regex）嵌套。Ron 称赞道：“它们是从非结构化文本中提取结构化数据的绝佳工具。”（“They're like an amazing tool for extracting structured data from unstructured text.”）然而，这种便利背后隐藏着极具迷惑性的“因果性问题（causality problem）”。 如果使用包含现代互联网语料最新训练的 LLM 去处理历史数据，模型其实“预知”了未来。Eric 笑称：“LLM 知道像安然（Enron）那样的公司最后遭遇了什么。”（“Yeah, the LLM knows what happened to like Enron.”）如果模型在训练阶段就已经读过一家公司后来的财务报告，甚至破产清算的信息，再用它来为十年前的某份季报提炼特征，就会不可避免地将未来的先验知识泄漏回过去。 ```mermaid flowchart LR accTitle: LLM 特征提取中的因果性泄漏问题 accDescr: 展示包含未来先验知识的 LLM 在处理历史数据时导致的前瞻偏差风险 subgraph Training["模型训练阶段"] A["历史金融文本"] --> C["现代 LLM 权重"] B["未来事件及财报 (如安然破产)"] --> C end subgraph Extraction["特征工程阶段"] C --> D["回测特征提取"] E["历史原始财报"] --> D D --> F["带有前瞻偏差 (Look-ahead Leakage) 的特征"] end ``` 在日常软件和数据工程中，AI 编程工具同样带来了双刃剑效应。虽然这些工具极大地降低了编写分析代码的门槛，但在没有深厚经验的人手里，产出劣质代码的速度也被前所未有地放大了。Ron 直言：“在成本层面上，仅仅是‘把事情做了’与‘把事情做好’之间的鸿沟从未像现在这样巨大。”（“Never has the gap between merely doing something and doing something well been larger in terms of cost, right?”）开发者很容易通过几行提示词得到一个貌似跑通的脚本，误以为自己解决了问题，实际上却完全误解了业务本质。 --- ### [01:09:35](https://www.youtube.com/watch?v=a5eirWk7xic&t=4175s) 苦涩的教训：为什么更强的神经网络反而需要更纯净的数据 谈到更深层次的模型变革，Ron 提到了机器学习界著名的“苦涩的教训”（The Bitter Lesson）——随着模型规模的增长和通用计算力的跃升，人类过去手工设计的许多特征工程和归纳偏置（inductive priors）往往会被端到端的模型内部表示所取代。这是否意味着数据工程与清洗的价值正在缩水？ Eric 给出了截然相反的判断：模型的表达能力越强，输入数据的洁净度反而越致命。如果数据缺乏严格的时点真实性（point-in-time），内部悄悄夹杂了来自未来的信息，“这些更强大的模型一定会把这种漏洞抓出来，并围绕它进行过度拟合”。现代深度神经网络对某些特定的异常值或脏数据极其敏感。虽然人类或许不再需要手动精巧地构筑每个特征，但保证输入通道绝不掺假、剔除毒性样本的工程价值被无限抬高了。 两人的共识是，在可预见的未来，人类判断力依然是不可替代的瓶颈。Ron 强调，在 AI 能以光速生成代码和方案的当下，“验证瓶颈（verification bottleneck）变得尤为关键”，唯有人类对业务系统和底线标准的敏锐直觉，才能裁决出什么是真正有价值的方案。 - **因果泄漏风险**：如果用来解析历史公告的 LLM 见过未来的股价或破产事件，历史回测便完全失去了统计有效性。 - **验证瓶颈的上升**：自动化生成极度廉价之后，区分高质量数据架构与脆弱拼凑代码的“工程品味（taste）”成了核心壁垒。 --- ### [01:12:51](https://www.youtube.com/watch?v=a5eirWk7xic&t=4371s) 自研与采购权衡：dbt、Trino 与自建机房的护城河 在另类数据基础设施的建设中，Jane Street 采取了务实的“自研与外部集成结合”路线。他们并不排斥业界优秀的成熟工具。例如，数据工程团队广泛使用了 dbt（Data Build Tool）。Eric 指出，在过去的工作经历中，他甚至见过长达 300 行的 PostgreSQL 视图和函数，错综复杂且无法维护；而 dbt 则允许团队用 SQL 声明转换流程，同时引入软件工程的规范化流程——将复杂变换拆解为细粒度模块，进行严格的代码审查（code review）、单元测试以及依赖编排。在查询引擎层，团队则选用了 Trino 并辅以丰富的 Python 生态来处理表格数据。 ```mermaid flowchart TD accTitle: Jane Street 另类数据技术栈与基础设施布局 accDescr: 展示 dbt、Trino 及自建底层存储 Superstore 与云方案的差异 subgraph DataStack["数据流水线与治理"] direction TB DBT["dbt<br/>(模块化 SQL / 测试 / 代码审查)"] Trino["Trino 查询引擎"] Py["Python 数据处理生态"] DBT --> Trino end subgraph Infra["底层混合基础设施"] direction TB SS["Superstore<br/>(自研核心数据仓库)"] Prem["自建数据中心 (On-prem)<br/>(极低延迟 / FPGA / 组播)"] Trino --> SS SS --> Prem end ``` 然而，在底层存储与机房架构上，Jane Street 走了一条与绝大多数全面上云的科技公司截然不同的重资产路线。由于早期从事低延迟高频交易，Jane Street 必须将服务器机柜部署在距离交易所极近的专属托管机房内，并自研了一整套对 FPGA 加速卡、网络组播（multicast）以及物理层拥有极致控制权的高性能架构。 当另类数据团队组建时，这些现成的内部基建成为了坚固的基础。公司此前自研的数据仓库 Superstore 自然而然地承接了另类数据管道的全部存储需求。不仅保证了海量另类数据能够与公司内部各类交易服务、结算系统无缝连接，也在全生命周期成本上拉开了巨大差距。 --- ### [01:16:30](https://www.youtube.com/watch?v=a5eirWk7xic&t=4590s) 云厂商计量账单与自建算力的商业账本 在探讨为什么不直接使用 BigQuery 或 Snowflake 这类公有云原生数仓时，Eric 和 Ron 深入算了一笔账。公有云数仓的商业模式通常建立在按查询扫描的数据量（bytes scanned）或按使用的计算单元（slots/compute credits）计费之上，其背后蕴含着极高的毛利率（gross margins）。Eric 坦言：“我甚至不敢想象，如果我们现在运行的所有查询都在云数据仓库里按量付费，那得烧掉多少计算积分或配额。”（“I don't want to imagine how much we would spend in credits or slots if all of the queries that we are running now were like billed in like a cloud warehouse.”） 相比之下，自建架构的核心成本是硬件购置与机房运维。拥有自建数据中心的企业，其每次查询的“边际成本（incremental cost）”接近于零。这种计费模型的差异深刻影响了工程师与量化研究员的行为心理： 1. **创新与探索摩擦力**：在公有云计费模式下，开发人员每尝试一次全表扫描、编写一个实验性质的重型探索查询，都必须战战兢兢地考虑账单成本；而在自建机房内，研究人员可以放开手脚自由探索。 2. **算力采购的真实算力比**：正如 Ron 总结的那样，如果把支付给云厂商的高昂溢价折算成物理设备，公司完全可以采购极其豪华的本地服务器集群，从而在无需时刻为成本做微观优化的前提下，支撑起惊人规模的数据吞吐量。 ### [01:18:07](https://www.youtube.com/watch?v=a5eirWk7xic&t=4687s) 算力成本陷阱与自建数据基础设施的经济账 在评估外部托管数据仓库与自建方案时，成本模型与工程精力的分配往往与直觉相反。若采用市面上主流的商业托管数据产品，团队通常不得不花费巨额时间去监控和微调开支，竭力重构内部工作负载以迎合外部厂商严苛且昂贵的计费规则。相比之下，Jane Street 采购物理硬件并在自建环境上运行 Trino 等开源分布式查询引擎，虽然仍需关注查询性能与数据仓库优化，但在开销优化上耗费的心智显著更少。正如 Eric 所指出的那样：“撇开经济学理论和底层架构不谈，现实中的定价模型运行机制就是如此。”通过直接掌控硬件资源，整体计算与存储成本反而更低，使工程师得以从无休止的“账单塑形”中解放出来，将精力聚焦于核心业务本身。 - 托管商业产品通常迫使工程团队将大量工时消耗在成本调优与负载限制上。 - 自建硬件配合 Trino 数据仓库虽然需要关注性能，但实际运营总成本明显更低。 --- ### [01:18:49](https://www.youtube.com/watch?v=a5eirWk7xic&t=4729s) 数据工程团队的扩张与优秀数据工程师的特质 Jane Street 的数据工程团队经历了爆发式增长：团队在 2023 年仅有 1 名数据工程师，而如今已迅速扩张到 20 多人，且仍在持续积极招聘。在谈及这一岗位需要何种人才时，Eric 强调最重要的品质是“好奇心与扎实的探究能力（investigative process）”。数据工程师的核心日常是不断接触全新的商业领域、陌生的行业模式、冷门的数据源以及复杂的交易逻辑。真实世界的数据不仅有用，而且往往异常混乱，内部潜藏着各种各样隐蔽的缺陷。能够胜任这项工作的人，必须由衷享受深入底层细节、厘清“已知与未知”、并从零开始梳理严密逻辑链条的过程。拥有自然科学或社会科学背景、习惯于从混乱现实中提取有效信息的专业人才往往极为适配。 ```mermaid flowchart TD accTitle: 优秀数据工程师的核心能力画像 accDescr: 展现数据工程师在探索意愿、领域认知、软件质量和真实世界理解上的综合要求。 subgraph Traits["核心特质"] A["求知欲与探索流程"] B["直面混乱数据的耐性"] end subgraph Execution["工程实现"] C["商业与业务领域建模"] D["清晰、可维护的流水线代码"] end subgraph Foundation["底层驱动"] E["关注数据背后的真实世界"] end Traits --> Execution Execution --> Foundation ``` 同时，该岗位对软件工程底线有着严格要求。虽然数据工程师面对的系统架构复杂度可能不及某些核心系统软件工程师，但其数据模型和业务复杂度却极高。正如讨论中特别强调的：“数据管道本质上就是代码，你依然希望它们是优秀的软件——清晰、正确且易于维护。” - 团队规模自 2023 年的 1 人增长至超过 20 人，并保持强烈的招聘需求。 - 候选人画像偏好：习惯处理混乱现实数据的自然科学/社会科学研究者，或在初创公司承担全局数据治理并兼具软件工程素养的骨干。 - 团队明确区分技术兴趣：热衷于纯粹搭建前沿神经网络模型或超大规模基础软件架构的人固然优秀，但这并非数据工程团队所寻求的目标画像；团队首要寻找的是“始终将数据本身置于首位”的人才。 --- ### [01:21:43](https://www.youtube.com/watch?v=a5eirWk7xic&t=4903s) 跨越数年的长期人才培育与数据清洗实战面试 在人才梯队建设上，Jane Street 展现出极具前瞻性的长期规划节奏。以往团队引入的均为具备实际工作或科研数据处理经验的成熟人才，而目前正在逐步建立面向在校生的实习生培养管线：例如在 2025 年便开始统筹谋划，计划于 2026 年启动面试，选拔 2027 年夏季实习生，这批人才将在 2028 年毕业后全职入职，并在 2029 年左右全面完成业务爬坡、输出关键价值。这种长达数年的规划，旨在系统性发掘那些对深挖数据怀有本能兴奋感、并具备成长为优秀工程师潜质的早期人才。 在甄别候选人实际水准的面试环节，团队摒弃了脱离业务的纯算法考核，设计了高度还原实战的“数据调查/数据整理（Data Investigation / Wrangling）”面试。面试官会提供一个候选人完全陌生的脏数据集，要求其现场探索结构、抽象运行模型并完成业务交付。评估的关键在于考察候选人的思维严谨性与对底层物理事实的敬畏心：他们是否审慎思考了每一项已知条件与潜在假设，是否主动设计了验证假设的手段，抑或是写了一堆脚本后仅仅寄希望于“但愿这行得通”。正如 Ron 在总结本期对话时所归纳的那样：“再次回到那个核心——与数据底层所投射的真实世界建立深度连接，切实思考现实中正在发生什么，并看清这是否会影响你眼下应当采取的行动。” - 招聘面试通过陌生的混乱数据集，重点检验候选人的探究思路、边界假设与验证严密性，杜绝盲目碰运气的编码习惯。 - 核心要求在于透过冷冰冰的行与列，准确还原并映射出其背后动态变化的现实物理世界。 ## Notable quotes > [00:02](https://www.youtube.com/watch?v=a5eirWk7xic&t=2s) 当你在系统中采取行动时，其他人会做出反应并改变自身行为，这种反应是你在历史训练数据中根本看不到的。 — Eric Mannes > [01:18:49](https://www.youtube.com/watch?v=a5eirWk7xic&t=4729s) 数据管道本质上就是代码，你依然希望它们是优秀的软件——清晰、正确且易于维护。 — Eric Mannes > [49:52](https://www.youtube.com/watch?v=a5eirWk7xic&t=2992s) 数据基础设施的产品是软件、系统和服务，做这块的人绝大多数是我们通过标准软件工程招聘流程招进来的；而数据工程同样是工程师，但他们的产品是一个优质的数据集。 — Eric Mannes > [03:37](https://www.youtube.com/watch?v=a5eirWk7xic&t=217s) 识别你是在与某人做一笔正和交易，还是在面对一个与你一样聪明的人、双方却对某个事实存在分歧，至关重要；在后一种情况下，你们之中必有一个人是错的，因此你必须深入反思自己为何会得出当前的结论。 — Eric Mannes ## Mentioned Jane Street, Eric Mannes, Ron Minsky, Figgie, CME, WTI, OCaml, Excel, VBA, Simon Peyton Jones, Microsoft, Python, Warren Buffett, SEC, Neudata, Bloomberg, S&P, Refinitiv/LSEG, Walmart, Visa, Mastercard, Chase Sapphire Reserve, Enron, dbt, Trino, PostgreSQL, Superstore, Snowflake, BigQuery ## Video description "Alternative data" is Wall Street’s name for information that comes from non-traditional sources: satellite photos of parking lots, credit card panels, weather forecasts. Eric Mannes has spent over a decade at Jane Street, first as a commodities trader and now helping lead the firm's alternative data team. In this episode, Eric and Ron talk about what it takes to turn messy external data into datasets a trading strategy can rely on. Along the way, they cover the day oil futures settled at a negative price and the systems that broke as a result; the years when the commodities desk's risk system was one very large Excel spreadsheet; the hard question of what a company even is; and why better ML models raise the value of careful data engineering. Apply for Data Engineering roles at Jane Street, including our internship https://www.janestreet.com/join-jane-street/departments/?dept=data-engineering https://www.janestreet.com/join-jane-street/position/8631973002/ For more episodes, visit: https://signalsandthreads.com/ 00:00:00 – Start 00:00:02 – Three summers and an anti-inductive market 00:03:37 – Mock trading and Figgie 00:08:47 – From intern to commodities trader 00:11:54 – Futures, multipliers, and metadata 00:18:53 – The day crude oil went negative 00:22:53 – Desk devs and a very large spreadsheet 00:26:23 – Excel as a functional programming language 00:30:40 – Translating between traders and engineers 00:34:19 – What counts as alternative data 00:36:46 – Starting the alt data team 00:44:12 – Data strategy and the vendor market 00:49:52 – Data infrastructure vs. data engineering 00:53:02 – What even is a company? 00:56:51 – Parking lots vs. credit card panels 01:01:30 – Point-in-time data and vendor revisions 01:06:05 – What AI changes about data work 01:12:47 – Build vs. buy 01:18:44 – Hiring data engineers [Source](https://www.youtube.com/watch?v=a5eirWk7xic)

[0:02] Eric Mannes: 当你在系统中采取行动时，其他人会做出反应并改变自身行为，这种反应是你在历史训练数据中根本看不到的。 [78:49] Eric Mannes: 数据管道本质上就是代码，你依然希望它们是优秀的软件——清晰、正确且易于维护。 [49:52] Eric Mannes: 数据基础设施的产品是软件、系统和服务，做这块的人绝大多数是我们通过标准软件工程招聘流程招进来的；而数据工程同样是工程师，但他们的产品是一个优质的数据集。 [3:37] Eric Mannes: 识别你是在与某人做一笔正和交易，还是在面对一个与你一样聪明的人、双方却对某个事实存在分歧，至关重要；在后一种情况下，你们之中必有一个人是错的，因此你必须深入反思自己为何会得出当前的结论。

[61:30] Eric Mannes: You're not actually studying like what trades you would have done if you'd been subscribing to the data set. You're simulating what you would have done if you had a time machine. [67:23] Eric Mannes: Never has the gap between merely doing something and doing something well been larger in terms of cost

[0:01] [music] [0:02] It's my pleasure to introduce Eric [0:04] Manis. Eric has been at Gain Street for [0:05] about a decade and he's had a really [0:07] interesting range of roles here spanning [0:08] trading and technology and these days [0:10] thinking a lot about alt data which is a [0:12] lot about what we're going to talk about [0:13] today. So thanks for joining me. [0:15] >> Thanks for having me. [0:16] >> So maybe to start with I just like to [0:17] hear a little bit more about how you got [0:19] to Jane Street in the first place. [0:20] >> I studied math in college and I looked [0:23] at what many of my peers did and a lot [0:25] of them were going into academic [0:28] research. um perhaps in Boston. Uh a lot [0:31] of them were going into tech often in [0:34] San Francisco and uh some of them were [0:37] going into uh finance uh usually in New [0:40] York City. And so I thought like well I [0:42] have three summers in undergrad and I'll [0:45] just spend one summer trying each of [0:47] these and at the end I was like Jane [0:50] Street is by far the most interesting of [0:53] these and the best fit for me so I'll do [0:56] that. So what about the trading [0:58] experience struck you as so interesting? [1:00] >> So uh I was a trading intern and I was [1:04] really struck by like how much I was [1:07] learning. [1:08] >> But I mean I guess one of the [1:09] interesting things about trading is like [1:11] by and large it's not a thing that [1:12] anybody knows, right? Like we hire [1:14] software engineers and they've often [1:16] done software engineering in other [1:18] places but like the vast majority of [1:19] people who come here have no experience [1:21] in the trading world, [1:22] >> right? And so um there was nothing [1:25] really um outside that had you know [1:29] given me like practice trading or any [1:33] depth in thinking about markets. And um [1:37] when I came here, I was struck by like [1:39] how much time people at Gan Street like [1:43] spent teaching the interns like about [1:46] like the fundamentals of how markets [1:47] work uh about um concepts like adverse [1:49] selection, how to do research well and [1:54] people use the word anti-inductive [1:56] environment of like when you discover a [1:59] law in when when you discover some [2:00] effect in physics, it's not like that [2:02] effect goes away in finance like the um [2:06] things that you find um the patterns [2:09] that you find often get discovered and [2:11] competed away over time and the things [2:14] that you like knew stop being true or as [2:20] important. Um and so you like have to [2:23] keep discovering new things, [2:25] >> right? And then what remains looks ever [2:27] more and more like a random walk. This [2:30] is why actually our signal to noise [2:31] ratios are kind of miserable because [2:33] there's this whole system whose job is [2:34] to like extract signal from the system [2:36] and have it look more like a kind of [2:39] pure representation of our remaining [2:41] uncertainty which is sort of by its [2:43] nature looks more random [2:44] >> right and when you act in this system [2:47] other people like respond uh and change [2:50] their behavior in ways that like weren't [2:52] visible in your training data. [2:54] >> Yeah. Like kind of an amazing thing [2:56] about like the world of trading is it's [2:57] this interesting like compromise and [3:00] incentive system that rewards people for [3:04] learning things about the world but does [3:06] it in a way that essentially forces them [3:07] to give some of that information up. So [3:09] you have this kind of information [3:10] discovery system where all of these [3:12] people trading and competing with each [3:14] other feeds information into the markets [3:15] and then the markets now are a kind of [3:17] more reliable gauge for what things are [3:20] worth which tells you all sorts of [3:21] things about what's happening in the [3:22] world. I think that felt uh very real on [3:25] um commodities and on in my current work [3:27] on alt data where like we are looking at [3:32] data from the real world to understand [3:34] it better and incorporate that [3:35] information into market prices. So you [3:37] said that like you were struck by the [3:39] amount of effort that people put into [3:41] teaching and I think teaching really is [3:42] an important thing here and actually I [3:44] think one of the interesting like facts [3:46] about G& Street which is maybe not [3:47] obvious from the outside is like the [3:49] insane amount of effort that goes into [3:51] the internship. Uh because we think like [3:53] getting great people is incredibly [3:54] important and we've kind of put almost a [3:57] pathological amount of work into making [3:58] the internship a really great [3:59] experience. Um but I'm kind of curious [4:02] like how did you feel like that played [4:03] out? like what were examples of the [4:04] kinds of things that happened in the [4:05] internship that you felt like taught you [4:07] more about how to think about markets [4:09] and and and kind of what the job was [4:11] like? [4:12] >> One uh important part of the internship [4:15] was like mock trading or trading at low [4:18] stakes. You can talk about good [4:23] decision-m in the abstract but [4:26] >> no replacement for actually trying to do [4:27] it live. [4:28] >> Yeah. [4:28] >> Yeah. [laughter] [4:29] There's no replacement for actually [4:31] trying to do it live. doing it in a [4:34] context where you kind of commit to [4:37] something and there are consequences to [4:41] what you choose. I think provides like [4:44] useful feedback, [4:45] >> right? And I think this goes back to the [4:46] fact that very early on at James Street, [4:48] we felt like people the early people [4:50] here learned an enormous amount from [4:51] like being on the trading floors and in [4:54] this kind of live trading environment [4:56] like kind of the nature of what trading [4:57] is and how it works and the basics the [4:59] kind of basics of adverse selection and [5:01] information flow and all of that. But [5:03] like you can't actually send everyone [5:05] back to the trading floors. Many of them [5:06] don't exist anymore. So like what does [5:08] it actually look like being in a mock [5:10] trading session? [5:11] >> Yeah, this has improved a lot over time. [5:13] But like uh one thing that we do is uh [5:16] like we did do have like a simulated [5:19] stock exchange where interns can trade [5:22] and we'll have these like one or two [5:26] hour like scenarios um that kind of [5:30] distill like some important trading [5:34] concept or thing that happens in real [5:36] life into a like time boxed toy model of [5:41] it. So, what's an example? Um, we have a [5:46] uh trading card game, not trading card [5:49] game. Well, it is trading and it is a [5:50] card game. Um, [laughter] [5:52] >> close enough. [5:54] >> Uh, called Figgy. Um, where, you know, [5:57] you and three other players um have each [6:00] have some private information about what [6:03] the different cards in the game are [6:07] worth, and you do trades um based on [6:10] that information. [6:11] And you pay attention to what other [6:15] people are doing, what information [6:18] uh that they have that is probably [6:20] causing them to behave in that way. And [6:22] think about whether like how you should [6:24] update what you were doing or the trades [6:26] that should happen when like you [6:32] and someone else have different [6:34] information or like reasons to value the [6:37] same thing differently. It also, you [6:39] know, gets people like used to market [6:43] making language and like putting [6:47] themselves out there and being willing [6:49] to buy or sell spades for seven ships. [6:54] And I think like getting people [6:59] comfortable with making decisions under [7:02] uncertainty [7:04] in these like kind of control controlled [7:07] low stakes environments I think is good [7:12] practice for doing it in the real world [7:16] um without like the psychological [7:18] pressure that would normally get in the [7:21] way. Have you read the book Enders Game? [7:23] >> I have. Right. Um [7:26] >> classic. [7:27] >> Yeah. Like we can't actually do that in [7:30] uh [7:31] >> like have people do like mock trading [7:32] and then slowly at some point discover [7:34] the mock trading is actually real [7:35] trading. [7:35] >> Right. I I I think for licensing legal [7:38] [laughter] [7:39] >> supervisory reasons um it's problematic. [7:42] But I it is easier to teach uh [7:44] intuitions about trading in this game [7:49] like environment where you can like try [7:52] things and see the outcome that isn't [7:55] quite like the heat of battle, [7:57] >> right? And and and I guess like like a [7:59] game like there is an adversarial [8:02] component to it, right? It's not like [8:03] the markets aren't a zero- sum game. [8:05] They're like a positive sum game. In the [8:06] end, people bet all you know people all [8:09] in benefit from participating in the [8:10] markets but like small positive sum [8:13] right and so if like player A is like [8:15] winning a lot then player B who they're [8:17] trading with is losing a lot and like [8:18] that gets reflected in the kind of game [8:20] structure as well I imagine [8:22] >> yeah identifying when you are doing a [8:26] positive some trade with someone versus [8:29] situations where you and someone who is [8:32] just as smart as you disagree about some [8:35] fact of the Right. One of you is wrong. [8:38] >> One [laughter] of you is wrong. And you [8:40] should think hard about like why you [8:43] think what you do. [8:44] >> Right. And why you're not the one who's [8:46] making the mistake. [8:47] >> That's right. [8:47] >> Okay. So, you learned a lot through this [8:49] internship and you decided actually this [8:51] is the thing that you wanted to do. What [8:53] was it like going from having been an [8:55] intern to like actually being here as a [8:57] trader? It was like even more [9:00] interesting than I expected because like [9:02] there were all of these like real life [9:05] trading decisions and strategies that [9:08] like we couldn't get into the details of [9:11] for IP reasons. But um [laughter] [9:14] I felt like I was learning a lot during [9:16] the internship. And then once I like got [9:19] to Jane Street, we could talk about like [9:21] the trades that we were actually doing [9:24] as a firm and the like decisions that we [9:28] were making as a firm. And so I started [9:30] off on the commodities desk um learning [9:33] to trade uh oil and natural gas um ETFs [9:38] and index ETFs which are about 50% like [9:41] oil and uh energy related products and [9:45] looking at the trades that we were doing [9:49] and thinking about like did they make [9:53] sense? Were they good trades? [9:57] um why were we doing them? Um if they [10:02] were good trades, why didn't we do more [10:04] of them? And if they were bad trades, [10:06] why did we do so many? All of this [10:08] happened like sitting next to you know a [10:12] mentor who was an experienced trader who [10:14] had been here a long time and you know a [10:17] bunch of trades would happen and then he [10:19] would say like okay well what do you [10:23] think we should do here? how should we [10:25] change our uh behavior? I would think [10:28] for a bit and say something and he would [10:30] say, "Well, okay, we're doing something [10:32] else and then work through with me like, [10:37] okay, well, you should also take into [10:39] account like this, that, and the other [10:40] thing." And over time, you know, through [10:44] working through all of these examples [10:47] and like getting this feedback, you've [10:49] learned to make better decisions in [10:51] these contexts. How long do you feel [10:52] like it took until you were able to make [10:56] positive suggestions that like actually [10:58] would influence the trading that we do? [11:00] >> I don't know, a couple. [11:01] >> I mean, I suppose like in the small [11:03] >> I think in the small like pretty [11:05] quickly. Um [11:06] >> because it's just stuff that like other [11:08] people don't have time to pay attention [11:09] to and you can you don't have to like [11:11] better than everybody else to add value. [11:13] you can become, you know, Jane Street's [11:16] expert on this one ETF and its trading [11:19] dynamics or like think really hard about [11:21] something that um no one else at the [11:24] firm has yet and have some interesting [11:27] suggestions and over time like the scope [11:29] of what you are comfortable doing on [11:32] your own increases. At first it's like [11:34] hey I think we should make this small [11:37] change. What do you think? And you'd get [11:41] comfortable with doing that. and [11:44] eventually get more comfortable like [11:45] making the bigger decisions on your own, [11:48] but like reaching out and gathering more [11:52] input when you weren't sure. [11:54] >> What you you said that you you could [11:55] become like James Street's expert on [11:57] like some particular corner. Can you [11:58] give me like an example of like some [11:59] little corner of the world that at some [12:01] point you became like the local expert [12:03] in? [12:04] >> Oh man, [12:06] >> we're going back a lot of years. Um, I [12:09] think at the time our trading systems [12:12] were pretty slow and we were rolling out [12:18] a new generation of trading systems that [12:21] were considerably faster by like two [12:24] orders of magnitude or something and but [12:27] still slower than the frontier and [12:29] slower than we are today. Someone had to [12:33] think about like how to optimize our use [12:36] of these systems and analyze like where [12:42] we were gaining from speed or what [12:46] opportunities we were missing. And I [12:48] don't know who should do that. Eric knew [12:50] he has time. [laughter] [12:53] I think another thing is like [12:58] I spent a lot of time [13:01] thinking about like futures and their [13:06] multipliers and the risk that you have [13:13] when you trade a future and how that's [13:15] different from like when you trade a [13:18] stock. Yeah, this seems like a dumb [13:20] corner of the world, but also one that [13:21] I've spent a weirdly large amount of [13:22] time over the years thinking about where [13:24] it's like you get used to trading [13:25] equities and it's like this is great [13:27] when I want to think about the risk of [13:28] the trade I can, you know, a starting [13:30] point is the cash flow. What's the cash [13:33] flow of the trade? It's just the product [13:34] of like the price and the size. This is [13:36] so nice and then like turns out not so [13:38] much in futures, [13:40] >> right? [13:40] >> Right. Maybe we're saying what is a [13:41] future? A future is like an agreement in [13:44] the future, hence the name [13:46] >> to exchange some money, [13:48] >> right? based on some other like [13:50] benchmark that this thing is tied to. So [13:52] like you know the S&P 500 futures are [13:55] tied to like the closing value of the [13:57] basket of S&P 500 stocks at a particular [14:00] point in time I think [14:01] >> or is it No, I think it's actually the [14:04] opening [14:05] >> the opening. [14:06] >> Okay. [14:06] >> On what I know [laughter] [14:08] >> uh Friday [14:10] >> of the month. [14:12] >> Amazing. [14:12] >> Um but on which exchange? [laughter] [14:16] >> Yeah. In when you buy a like uh crude [14:19] oil future, you are uh you agree to pay [14:23] some money for either like the value of [14:27] some you know index related to oil [14:31] prices or you know a thousand barrels of [14:34] oil delivered to you in Cushing, [14:36] Oklahoma. Um [14:39] and [14:39] >> so-called physical delivery. Yeah, [14:41] physical delivery or like you know live [14:45] cattle where actually sometimes the [14:47] cattle are delivered um dead but uh [14:51] >> you know tens of thousands of pounds of [14:53] beef. We you know were generally [14:57] financial players who did not want to [15:00] take delivery of [15:03] a thousand barrels of oil in pushing [15:05] Oklahoma. [laughter] Um I've never been [15:07] there. Um, [15:10] and like I don't know [15:13] where I would store, you know, the [15:15] 20,000 lbs of beef. Um when like when [15:20] you buy a future like you put up some [15:25] margin with the exchange and you know if [15:29] you are long and the future goes up um [15:33] the exchange credits some money to you. [15:37] When the future goes down, the exchange [15:41] removes some of your money and possibly [15:44] asks you to put up some more margin so [15:47] that they know that you'll be able to [15:48] pay off losing bets. [15:50] >> Mhm. [15:50] >> Another thing you can trade is like the [15:52] spread of two futures. Um, you get long [15:56] one and short another. So like the CL um [16:01] U6 CL V6 spread uh if you buy that on [16:06] the CME you get longer crude oil futures [16:10] deliverable in September and shorter [16:14] crude oil deliverable in October. And if [16:17] you trade like S&P 500 future spreads [16:20] you have the opposite sign convention. [16:23] But uh in either case like your [16:26] position, sorry, the thing you trade [16:28] like decomposes into [16:32] um two different positions rather than [16:34] like the one thing you bought, [16:36] >> right? And I guess the point here is [16:38] that all of this is like one level more [16:40] abstract than like the underlying things [16:42] are being traded. So like you know [16:44] instead of trading the outright thing, [16:46] you're trading this future on the thing. [16:48] And then there's a bunch of conventions [16:50] and some of the conventions are about [16:51] like it has a name that says what the [16:53] two legs of the spread are but like [16:54] which one is positive and which one is [16:55] negative depends on the future right and [16:57] you can't just like look at the notation [16:59] for sure and know the answer. And then [17:00] where we started this other crazy thing [17:02] called the multiplier which like [17:04] actually tells you the real size of [17:05] this, [17:06] >> right? Like when you pull up the ticker [17:08] for some future say crude oil, uh you'll [17:13] see a price for like one barrel of crude [17:15] oil or one pound of live cattle. But [17:20] actually like when you buy the contract [17:22] and take delivery, you get a,000 [17:25] barrels. Um, and the like notional value [17:28] is a thousand times of like the coded [17:31] price. And different sources will [17:35] depending on where you're getting your [17:36] pricing from, you will get different [17:40] prices and different multipliers and [17:44] sometimes like different currencies. Uh, [17:47] like someone will quote in uh dollars [17:51] and another person will quote it in [17:53] cents. It's a small matter of a factor [17:55] of 100. [17:56] >> Yeah. And as long as you [18:00] always um keep track of which prices [18:05] correspond to which multipliers [18:07] and never mix up the two. You won't [18:10] accidentally trade 100 times less or um [18:14] much worse 100 times more than you [18:16] intended. [18:17] >> Right? And so this matters kind of from [18:18] a risk perspective. Like ideally we'd [18:20] like to have relatively simple systems [18:21] that are kind of like stepped back from [18:23] the details of the trading strategy [18:25] which kind of put a kind of outside [18:26] envelope on the risk that the systems [18:28] are taking. And that's like way easier [18:30] if you actually know what's going on. [18:32] But this is what you're pointing to is [18:33] this all this whole like what we call a [18:35] metadata problem of like actually [18:37] understanding the details of how these [18:40] contracts actually work. And it's Jade, [18:42] it's just made much more complicated by [18:44] the fact that like the world is full of [18:46] huge amounts of unnecessary complexity [18:48] of like different conventions and [18:50] different details of how these things [18:51] are quoted in different contexts. [18:53] >> Yeah. And like you have assumptions that [18:57] are baked into your um trading and risk [19:01] systems like this price will always be [19:04] positive that turn out to not be true. [19:07] on April 20th, 2020, the price of the [19:11] like almost expiring uh crude oil future [19:14] on the CME um [19:17] settled at a negative price. Um and you [19:21] know, you'd always think like, well, [19:23] goods are good. They're not [19:26] >> they're worth something. [19:27] >> They're worth something. They're not [19:28] bad. You should [laughter] pay a [19:29] positive amount of money for them. [19:31] >> And that breaks a lot of assumptions. [19:35] Um, but how can it happen? How can a [19:38] crude oil future be worth negative? Like [19:39] goods normally are good. Like what [19:41] happens? [19:41] >> Yeah. So that crude oil contract was for [19:46] oil delivered to a particular place at a [19:51] particular time. And um at the time in K [19:55] Cushing, Oklahoma storage was getting [19:59] full. There wasn't much place to put the [20:01] crude. Supply of oil everywhere was high [20:06] and demand um for obvious reasons was uh [20:10] considerably lower [snorts] [20:12] >> than usual. [20:13] >> If you remember, [20:14] >> if you remember, [20:15] >> April 2020. Yeah. And that added up to [20:19] like [20:21] well if you were [20:25] long, what would you uh do with it? And [20:29] this isn't quite true because the like [20:32] for one day the settlement price was a [20:35] negative number and the like final [20:39] settlement price of this contract was [20:42] positive. Like in the end people were [20:45] willing to pay positive dollars for [20:48] crude. [20:49] But on April 20th, there just were not [20:53] enough people willing to step seven and [20:55] say, "I will pay uh money for this [21:00] thing." [21:00] >> Right? And when all of your systems had [21:01] assumed this price was positive for a [21:03] long time, yes, [21:03] >> maybe your trading systems do not have a [21:05] great day, [21:05] >> right? Maybe the people who would [21:09] normally provide to these moves weren't [21:10] able to send orders because like their [21:14] order entry system didn't know what to [21:15] do with a negative 100% return. [21:18] [laughter] [21:19] Um, also like if you were modeling other [21:24] products based on the price of crude oil [21:27] on that day, how are you modeling oil [21:30] companies or everything else? Should you [21:32] be using like that negative crude [21:35] future? I'm not sure. [21:38] >> Right. Seems [21:39] >> I guess this like zooming out for a [21:40] second. This like points to like a thing [21:41] about trading which is some of trading [21:43] is thinking hard about the technology [21:45] stack and the math and the modeling and [21:48] some of it is just diving into a bunch [21:50] of groy detail of like how does the [21:52] world actually work what are the [21:54] mechanics of the markets and the systems [21:55] and like the amount of storage space [21:57] there is in Cushing Oklahoma and like [21:59] all of those things can play in and this [22:01] is like a general fact about trading is [22:02] like lots of different kinds of things [22:05] about the world can flow into the [22:07] trading process. It's not like I think [22:09] sometimes people who hear about James [22:11] Street think it's all about like you [22:12] know high-tech high performance smart [22:14] math models and stuff and like that [22:16] stuff is all real and part of it but [22:18] there's also a lot of detailed [22:20] engagement with how the world actually [22:22] works that also plays into being an [22:23] effective trader [22:24] >> right and I think that's true across uh [22:29] like all of our businesses but it is [22:32] very true in commodities where like the [22:35] things that you are buying and selling [22:38] are connected to the physical world. Oil [22:41] and wheat and things that like people [22:45] actually uh physically produce and [22:49] consume [22:49] >> and occasionally deliver to you [22:50] >> and occasionally deliver to you. [22:53] >> Yeah. [22:53] >> So in addition to thinking about all of [22:56] these kind of trading focused concepts [22:57] on the desk, you also spend a bunch of [22:59] time thinking about technology on the [23:00] desk. Can you say a little bit more [23:02] about what that was like? [23:03] >> Right. At the time, I think how Jane [23:06] Street approached developing technology [23:09] for uh trading was having a bit of a [23:12] phase shift. We went from having [23:15] developers who primarily worked on like [23:17] the core infrastructure that undergurted [23:20] our trading, the trading systems, the [23:23] market data, bookings pipeline, that [23:25] sort of thing. while like traders like [23:29] people on our commodities desk and our [23:31] domestic ETFs desk uh would plug in to [23:35] those systems but do like less systems [23:38] development themselves. And at that [23:41] time, I guess we finally felt that we [23:44] had enough breathing room to say like, [23:48] well, what if we built commodity [23:49] specific systems to help address the [23:52] unique problems with like trading [23:54] commodities? And this is like a thing [23:56] that happened not like all at once, but [23:58] like at different desks at different [24:00] points of time. Some desks were more [24:01] technical in their needs, some were [24:03] less. And so this kind of like desk dev [24:06] phenomenon like unrolled like you know [24:08] over a period of years as we kind of got [24:10] enough capacity and now like every desk [24:13] across the firm has embedded desk devs [24:15] because you just kind of need it [24:16] everywhere. [24:16] >> Mhm. Right. But at the time it felt like [24:19] well this is working here we should try [24:21] this elsewhere too. And when we were [24:23] starting to build out the commodities [24:24] desk dev team we needed someone from [24:28] trading to help think about it. and I [24:30] was relatively technical having done my [24:33] tech internship for one of my free [24:34] summers. Um, and having learned o camel [24:38] and o camel boot camp, I uh got involved [24:40] with that and that involved things like [24:43] thinking about how we like keep track of [24:46] our risk or exposure to different [24:48] commodities. If you're looking at your [24:50] positions in energy products, like you [24:54] could look at it at a very high level or [24:56] you could look at just oil and related [24:58] products. Um, you could look at like [25:01] West Texas Intermediate crude oil alone [25:03] or you could look at like the, you know, [25:06] November contract of this one commodity [25:10] and you need to be able to like shift [25:13] from level to level all at once and be [25:15] able to dig into exactly where your [25:19] exposure to these was coming from. And [25:21] we've been doing this before. It was in [25:24] large Microsoft Excel spreadsheet, US [25:27] commodities risk.xlsm. XLSM [25:29] and you'd like press a button and it [25:32] would pull in, you know, data about our [25:35] our trades and um positions and crunch [25:39] some numbers. One, it sometimes it was [25:41] slow. Um, two, it it was something that [25:45] had built up over time and was built by [25:48] people who, you know, were very good at [25:51] using Microsoft Excel and very [25:53] knowledgeable about commodities but were [25:57] not by and large like software engineers [26:00] and kind of like building it up again [26:02] from first principles and making sure [26:06] that you got the foundation right to [26:10] something that we could uh really trust [26:12] let us build, you know, more and more [26:14] ambitious things on top of that and we [26:16] were able to build when it was an Excel [26:19] spreadsheet that ran slowly and worked [26:23] except occasionally when it didn't, [26:24] >> right? I feel like people who don't use [26:27] Excel much probably underestimate how [26:30] good it is and then like when you've [26:32] used Excel a lot, you have a really good [26:33] sense of like oh my god, what the [26:34] limitations are. Like Excel in many ways [26:36] is kind of great. like it's like gives [26:39] you great ways of visually inspecting [26:40] and understanding the data. It's [26:42] extremely flexible. It's actually quite [26:44] easy to debug in important ways. Um but [26:47] yeah, there are like profound [26:48] performance limitations. Like what what [26:49] else actually was like bad about doing [26:51] it in Excel? What were the downsides? [26:53] >> Yeah, I should say before all of this [26:55] that I love Microsoft Excel and I don't [26:59] use it very much anymore. Um but you [27:03] know, we like functional programming [27:04] here. Excel formulas, spreadsheet [27:07] formulas are, I think, the world's most [27:09] widely used functional programming [27:11] language. [27:11] >> For sure. [27:12] >> I think Excel has lambdas now. [27:13] >> It does. And let bindings. [27:15] >> And let bindings. Yeah. Um [27:18] >> I think thanks to Simon Payton Jones and [27:20] some other people at Microsoft who [27:21] helped build it. [27:22] >> Yeah. When you write like Python code, [27:25] usually you have the like code in front [27:28] of you, the logic in front of you, but [27:30] the the data is like hidden away until [27:32] you like write something that like [27:35] visualizes it for you. And with Excel, [27:39] like the data is front and center and [27:43] the logic um is hidden in the back. And [27:48] like that's pretty useful. people are [27:51] making decisions about what to do based [27:55] on the data that they see. Uh so what [27:57] were the problems here? Performance uh [28:00] was sometimes fine uh sometimes at [28:04] critical moments quite bad. [28:06] You aren't just like writing the cell [28:10] formulas yourself. You're writing Visual [28:14] Basic to construct the spreadsheet [28:19] that you use, you know, [28:20] >> right? This is what this is like cell [28:22] meta programming. You write a program [28:24] that writes a program that's like laid [28:26] out in this in the sheet. You press a [28:28] button that like runs a nest of Visual [28:30] Basic macros that like initialize [28:33] um a sheet with all of our um positions [28:37] and trades and the code the uh code on [28:42] top to analyze them. And Visual Basic is [28:46] okay. [laughter] [28:47] No, I mean it like it was impressive [28:50] what we were able to do with it, but [28:53] having a [28:55] uh type- safe language where the [28:59] compiler can catch a lot of your [29:01] mistakes where you can write robust [29:04] tests and interfaces is an advantage [29:07] that many programming languages have [29:10] that is like hard to do in Visual Basic. [29:13] Um, also like version control. Yeah. [29:15] >> Um, hard to do version control in a [29:18] spreadsheet. [29:18] >> Um, [29:19] >> Excel is not optimized for that. I [29:23] once wrote an Excel GP tool that yeah [29:29] was just like a firm utility for [29:31] searching through spreadsheets because [29:33] like opening them up one at a time and [29:36] in Excel and control fing um first [29:40] through the cell formulas and then [29:43] through the visual basic [29:45] is impractical. [29:46] >> No way to live. [29:48] >> Yeah. And like if you need to do like [29:51] large migrations of many spreadsheets at [29:53] once, which we sometimes did, it helped [29:55] to be able to search them. Maybe related [29:58] to the lack of version control is that [30:00] like things just build up. Uh someone [30:04] like put some throwaway cell formulas [30:09] for analysis in like one corner of one [30:12] sheet and then it's just there forever. [30:15] >> Yep. So, you get to a point where like [30:19] no one [30:21] fully understands [30:24] what it's doing, though some people know [30:26] a lot and are pretty sure. And it's hard [30:29] to like rebuild that model of how the [30:33] spreadsheet works and like become like [30:38] confident that there are no issues. Um, [30:41] >> so that itself I feel like makes the [30:43] process of replacing it hard, right? [30:46] spreadsheet, it's an artifact, it has a [30:48] lot of embedded [30:50] like no human [30:55] in trying to help bridge the gap between [30:57] like the spreadsheet that did a thing [30:58] and then like the piece of software that [31:00] we were going to build to replace it. [31:02] >> Right. So a lot of what I did was [31:04] translating between the domain [31:06] understanding that like uh the other [31:09] traders and I had and a description of [31:14] the domain and the problem that like a [31:16] software engineer can work with and like [31:20] build a robust system around rather than [31:24] someone saying well I want this and it [31:28] should do that and that and the other [31:29] thing like distilling that down into [31:33] like what we're fundamentally trying to [31:36] do which is you know model the risk [31:40] exposures of our uh commodities desk. [31:43] >> Mhm. and how [snorts] we are trying to [31:47] do it. This the input sources and how [31:50] they should fit together, what the basic [31:51] atoms are. And we built up model of the [31:57] thing we're building, the flowchart of [31:59] how all this data like fit together and [32:02] turned into like the end result. And [32:05] then people were able to just [32:07] confidently [32:08] build um some part of it knowing that it [32:12] would fit together into like the hole [32:15] correctly. [32:16] >> I imagine it's like much better for the [32:18] software engineers if they don't just [32:20] like have like a spec a narrow speck of [32:22] a thing to build, but also they like [32:23] understand the background of the domain [32:25] in a way that's like a little more kind [32:27] of actionable and fills out their [32:28] understanding of the world. [32:29] >> Yeah. And information flows the other [32:31] way as well. Um I think the domain [32:33] experts like who are not themselves [32:36] software engineers like don't understand [32:38] how good things can be if we build the [32:42] right software for it. Um the like I [32:47] have suffered for years like doing [32:51] things in this way because there weren't [32:53] tools to help me do it better. And I've [32:56] gotten so used to it that I don't [33:00] realize I need something better. [33:03] >> Right? Like one of the characteristics [33:05] of many James Street traders is high [33:06] pain thresholds, right? People are like [33:08] willing to deal with like pretty messy [33:11] things and pretty unpleasant things if [33:13] like you know I have to like you know [33:15] you know knock my head on the table [33:16] three times and slot my cheek in order [33:18] to like cause money to come out of the [33:20] machine. They'll just like do that all [33:21] over [33:22] >> over and over. [33:23] >> Yeah. And someone who makes a good desk [33:25] dev at Jean Street [33:28] can say like, "No, there's no way you [33:31] should be doing it that way. [laughter] [33:33] If we, [33:35] you know, built this tool, it would be [33:37] much easier to do these studies that are [33:42] either difficult to do now or that no [33:44] one would bother doing now because we [33:46] don't have the right language for [33:47] working with them. [33:48] >> Right? Right. So part of what you need [33:49] to convey to the traders is like a [33:51] better cost model. Like understanding [33:53] what's possible and understanding that [33:54] like some improvements are like maybe [33:56] way cheaper than they imagine and some [33:57] are more expensive than they imagine. [33:59] It's not just the costs. You can have [34:03] like great ideas for what we as a like [34:07] desk or as a company should be doing [34:09] differently. It's like I am someone with [34:12] like this particular set of skills and [34:14] knowledge and my job is to help Jane [34:18] Street, you know, do the best trades. [34:21] >> All right. So, you're no longer on a [34:22] trading desk. Today, you help lead our [34:24] alt data effort. [34:25] >> Um, can you say more about like like [34:29] what is alt data and what is it at Gain [34:32] Street? Yeah. So, [34:34] out in the world on Wall Street, um, [34:39] alternative data is like data that you [34:43] use for the investment process that [34:45] isn't normally used in the investment [34:48] process. [34:48] >> It's an unstable naming convention, [34:50] >> right? Like if enough people use it, [34:52] does it like drop its alt like moniker? [34:56] The canonical example of alternative [35:00] data is like a satellite photo of a [35:03] Walmart parking lot. You take a photo of [35:05] the parking lot. You see how many cars [35:07] are there. If there are a lot of cars, [35:09] they have a lot of customers and you [35:11] know they're doing well. If they parking [35:14] lot's empty, um that's a bad sign. And [35:18] in contrast, there's like traditional [35:20] data, orders and trades on exchanges, [35:24] basic like information about like [35:28] instruments, stocks. Imagine like Warren [35:31] Buffett like reading an annual report [35:35] and thinking about the balance sheet and [35:36] income statement. That's traditional [35:39] data. [35:40] >> Okay. [35:41] >> And at Jane Street, a lot of data is [35:44] alternative. The the satellites are [35:46] alternative. the like company filings [35:49] with the SEC are alternative. Um [35:53] the things that are traditional are like [35:59] the like real-time market data from [36:02] exchanges, you know, the basic [36:03] instrument metadata that we need in [36:05] order to like run our like trading and [36:08] risk systems and booking and so on. [36:11] >> Right. Back to the multipliers. [36:12] >> Yeah. And it's based on, you know, the [36:16] path dependent evolution of Jane [36:18] Street's trading, you know, starting as [36:21] a market maker and then expanding um [36:25] into adjacent areas, [36:27] >> right? In fact, it's reflected in like [36:29] team structure. We have a market data [36:31] team that does that kind of like live [36:33] data from exchanges and from other [36:34] places and we have a metadata team and [36:36] then we have this alt data team which in [36:38] some sense is like kind of picking up [36:40] the rest of that [36:41] >> Yeah. of that of that kind of value that [36:43] you get from other sources of [36:44] information. [36:45] >> Mhm. [clears throat] [36:46] >> And then how did you get involved in [36:47] this space? [sighs] [36:49] >> How did I get involved in this space? [36:51] [laughter] [36:52] >> Um, so at Dain Street, you can do [36:56] whatever you want as long as it's the [36:57] right thing to do. Your job is not to [37:00] maintain this one system or to like [37:04] trade this one product. your job is to, [37:07] you know, help Jane Street like maximize [37:11] its P&L um over long term. What that [37:15] means is that if you see a problem that [37:19] you think is important to solve, what's [37:22] stopping you from solving it? I mean, [37:24] probably you should talk to other people [37:28] and make sure that like this is a real [37:32] problem and that it is worth fixing and [37:38] it is worth your time fixing. [37:41] >> Mhm. And you know, at some point I was [37:45] thinking about like a bunch of different [37:48] data related things at Jane Street and [37:51] realized that like we were failing to [37:55] find trades because our data was too [37:58] hard to work with because like external [38:01] data specifically was too difficult to [38:04] work with. like our infrastructure for [38:07] streaming in real time and um surfacing [38:11] for like historical studies of like the [38:13] real-time market data was great and had [38:17] lots of engineers and specialized [38:18] infrastructure. While the data [38:21] infrastructure for all that other data [38:24] was kind of weaker, it was annoying to [38:28] just get data in the walls of street [38:31] both like from a contractual [38:34] perspective. [38:36] >> There was no alt data team at [38:37] >> there was no alt data team. [38:38] >> So how did it happen? Like where was the [38:39] work done? Who was doing the work? Like [38:41] what was the shape of all that? Yeah, I [38:43] I think when we started it was like [38:47] me and you know a small number of devs [38:51] including Jacob who was on uh the [38:55] podcast earlier. [38:56] >> Mhm. [38:56] >> And uh a very small number of data [39:01] engineers and we had three areas we were [39:07] focusing on. Wait, but I think you're [39:08] going ahead. I thought like I was sort [39:10] of thinking like like the the early [39:12] version of this I assume was just like [39:14] kind of crowdsourced by the death [39:17] >> before like how sure we were using [39:19] external data um before we had an alt [39:22] data team [39:23] >> and the work of building the like data [39:27] pipelines and integrating that data [39:30] would [39:32] be done by whoever was around and [39:36] available at the time. So someone on the [39:39] uh commodities desk would say like we [39:42] want this data set and our data vendor [39:44] management team would go out and buy [39:47] that data set and a dev or a trader or a [39:50] trading desk operations engineer would [39:53] like bring in the data and put it [39:55] somewhere maybe in some corner of a [39:59] large NFS tree um or shared file system [40:04] maybe in a database but which [40:06] Um and like the result would be I don't [40:13] know like 60% as good as it could be [40:15] like [40:15] >> and I guess this process is happening [40:16] like some on the commodities desk [40:19] domestic ETF desk some whatever like [40:21] various different desks reinventing the [40:23] wheel doing slightly different versions [40:25] of it [40:25] >> by people whose job was not primarily [40:28] like thinking about how to build data [40:29] pipelines well who were not thinking [40:33] about what could be shared between those [40:36] processes who sometimes but not always [40:39] thinking about like how should people [40:41] around the firm not just like in the use [40:44] case that I'm thinking about right now [40:46] be using this data. [40:47] >> Mhm. [40:48] >> And thesis was that we could have a [40:51] centralized team try to do that. think [40:53] about a centralized team to source [40:57] um some of these weirder alternative [41:00] data sets to [41:03] build better tools for building these [41:04] data pipelines and to maintain some of [41:08] these data pipelines especially like [41:10] ones that kind of had formide impact [41:13] that would be used in a lot of different [41:15] places. So how did you go from like the [41:17] recognition of like man this is kind of [41:20] a mess like people are generating data [41:21] sets in messy ways don't have great ways [41:24] of distributing them don't have good [41:25] technology for serving the data don't [41:28] have good ways of cleaning the data [41:29] don't have good shared practices and so [41:30] like we have less good data that is like [41:33] just harder to convert into valuable [41:35] trades and is therefore worth less money [41:37] so like that seems like a key [41:38] observation how did you go from that [41:40] observation to like actually doing [41:42] something about it [41:44] >> so like sure you've identified a problem [41:48] and many people at the firm would agree [41:52] that it was bad in all these ways but [41:54] like why there are lots of things we can [41:57] make better like why this one part of it [42:00] was like we'd experiment we'd do [42:05] something on a small scale and the [42:08] results would work well so we do it more [42:11] we'd like find one [42:16] particularly [42:18] basic but annoyingly difficult to use [42:21] data set and make it easier to use, like [42:24] think very hard about it. And people [42:27] would start using that new thing. And lo [42:31] and behold, like there were effects that [42:33] they like were not able to find when the [42:37] data was really difficult to work with [42:39] that they were suddenly able to find [42:41] when the data was uh easy to work with [42:44] and when someone had you know thought [42:48] really hard about those edge cases and [42:51] like put in the work of understanding [42:53] like the data model and so on. So [42:56] basically incrementally go do some [42:59] things, make it better, demonstrate that [43:00] it's worth money. You can sort of see [43:02] the P&L coming out the other side. And [43:04] after a while it just kind of becomes [43:05] clear to everyone that like, oh, we [43:06] could use like a lot more of this. [43:08] >> We could use a lot more of this. And so [43:10] like um we hired our first data engineer [43:14] at Jane Street ever in 2023 and the [43:20] feedback has been like, "Oh, we could [43:24] really use a lot more data engineering [43:26] help." Actually the more people work [43:28] with data engineers and see like the [43:34] results from good data engineering work [43:37] the more they are excited to like apply [43:42] that toolkit to other problems I guess [43:45] by informing people about how uh much [43:49] easier it is to like build good quality [43:52] data sets than it was before and be like [43:56] results that we're able to get in doing [43:58] so they want to do it more. [44:01] >> So induced demand [44:02] >> induced demand. [laughter] [44:03] >> Yeah. So what just to like step back so [44:06] like we went in 2023 from like having [44:08] our first data engineer like how many do [44:10] we have now? [44:11] >> Let's say [44:13] 20 something. [44:15] >> Got it. So like a much bigger effort [44:17] like as as it's grown out like I'm kind [44:20] of curious like what's the structure of [44:22] the team? Right. You mentioned data [44:24] engineers, right? But I think I don't [44:26] think all data is just just data [44:27] engineers. So like how does the team [44:29] break down into different kinds of [44:30] people with different kinds of [44:31] expertise? [44:33] >> One group is uh data strategy and that's [44:36] not engineering at all. Um but their job [44:38] is to understand what data gain street [44:41] uh needs and what data is out there in [44:45] the world and then if there's a match uh [44:49] like you know get the data uh for us so [44:54] that we can do good data engineering to [44:56] it and so internally that looks like [44:58] talking to our different trading desks [45:00] and understanding like what problems [45:01] they are trying to solve and what [45:05] problems they could solve with better [45:07] data. The external part involves getting [45:11] out there and showing up and [45:13] >> but it's like another case where you [45:14] have to understand like grate details of [45:16] the real world. [45:17] >> Yeah. We go to conferences where we'll [45:20] like talk to data vendors. Um so there [45:25] are these like data catalog companies [45:28] one example of which is new data and the [45:31] like data catalog companies like they [45:35] have analysts who learn about the [45:38] different kinds of data that are being [45:40] offered to um the financial industry and [45:43] like document them somewhere and um data [45:47] consumers like us you know pay for a [45:49] subscription to that catalog and they'll [45:52] also like organize these conferences um [45:55] where data you know data buyers show up, [45:57] data sellers show up. They'll have like [46:00] speed dating between the buyers and [46:03] sellers where you'll like read all these [46:07] profiles [46:09] and you'll say like, "I want to talk to [46:12] these ones and then they match you and [46:16] you have like 10 uh 15 minute uh dates [46:20] in a row where they explain their [46:23] product to you and you ask the questions [46:27] that you have and try to figure out [46:29] whether like this is some data that [46:31] would make sense for [46:32] >> do you sit there with like a glass of [46:33] Chardonnay as your [46:34] >> uh [laughter] [46:36] yeah uh usually it's drinks after but [46:40] and you know you go there and [46:43] some of them [46:46] you say well this was interesting but I [46:48] don't think there's a match here and [46:49] [laughter] [46:50] other others you say like we should talk [46:53] more can I get you know your number your [46:55] business card [laughter] [46:57] >> so that's one way of two-sided market, [46:59] right? There's like buyers and sellers. [47:03] >> Like are who are the who are they? Like [47:05] first of all, who are the buyers? Like [47:06] it's obviously people like us, trading [47:08] firms. Is it all trading firms? Who are [47:09] the buyers? [47:11] >> Yeah. So I think there are a lot of [47:14] trading firms that don't look like us. [47:17] There are like hedge funds whether like [47:19] big multistrats or small um asset [47:23] managers, banks, um participants who [47:28] want data for their like investment [47:32] decisions and analysis or research. Some [47:36] of them are expanding into like [47:41] other uh kinds of buyers uh like private [47:45] equity or whatever the sellers vary. Um [47:48] there are satellite providers say you [47:51] know who have satellite data. Um [47:53] >> so you can see the Walmart parking lot. [47:54] >> So you can see the Walmart parking lot. [47:56] So there are like big [48:00] companies that own [48:02] lots of data sets over lots of [48:04] verticals. the like Bloomberg, S&P, [48:07] Elsag refinatives of the world. There [48:10] are companies that like focus on a [48:14] specific kind of data, consumer [48:17] transaction data. Mhm. [48:19] >> Um [48:22] there uh are companies there are [48:24] companies that like happen to have data [48:25] from their business either like you know [48:28] they're a satellite company and they [48:30] they have satellites or they're like a [48:35] company that like provides goods or [48:38] services and they have exhaust data and [48:40] they think hm like [48:42] maybe someone would want to buy this. Do [48:45] you actually have a sense of like how [48:47] much of this big market for data is has [48:53] trading of various forms or financial [48:55] companies for various forms on the [48:57] buying side and how much is other stuff? [48:59] >> Some of this data is probably also used [49:01] for like targeting ads. [49:04] >> Sure. Um, and like one important [49:07] difference between the trading use case [49:10] and the ad use case is that we don't [49:14] want to know like who the individual [49:18] consumers are, [49:20] >> right? We want to know like oh like [49:23] people are spending more at Lululemon, [49:25] people are you know buying more Ritz [49:28] crackers but like apart from you know [49:31] demographic information that might help [49:33] us weight the data or maybe information [49:36] that would let us see like oh people who [49:39] buy this also buy that. We don't want to [49:42] know [49:44] >> who the actual person is. Well, with [49:46] advertising, I think it's the point, [49:49] >> right? [49:50] >> For so [49:51] >> for at least if you're doing this kind [49:52] of like micro targeting. [49:53] >> Yeah, if you're doing the micro [49:54] targeting. [49:55] >> Okay. So, let's take a step back. So, we [49:57] just said like one part of this is this [49:58] data strategy which is kind of thinking [50:00] about the sources and the syncs [50:01] understanding places where data can come [50:03] from and places where data can be used [50:04] internally and doing this like kind of [50:06] internal and external kind of [50:07] matchmaking process. [50:09] >> Yeah. Like some of it is through that uh [50:13] through cataloges, data sets that are um [50:17] advertised and exist and some of it is [50:18] from thinking you know from first [50:20] principles like what question am I [50:21] trying to answer and what data could [50:24] help me answer that question and who [50:26] might have that data whether they are [50:28] selling it right now or not. [50:31] >> Um some I guess there's like someone who [50:33] you think might have data who isn't [50:34] selling it but like you can go talk to [50:36] them and maybe there's a product they [50:37] can make. [50:37] >> Yes. In addition to like data sourcing [50:41] like we have our you know data [50:44] infrastructure the like uh tools for [50:48] ingesting and transforming data for like [50:53] monitoring our data pipelines the [50:56] building blocks that people who are [50:58] building data pipelines actually use. [50:59] >> Got it. And this is what looks maybe [51:01] more like a kind of straight ahead [51:02] software engineering role. Yeah, that is [51:05] more like software engineering. Your [51:06] product is like software and systems [51:10] >> and services and the people who do that [51:15] are largely people we hired through our [51:17] you know standard software engineering [51:19] pipelines. And then we have uh data [51:21] engineering where like they're also [51:24] engineers [51:26] um but the product is like a good data [51:31] set. What they do is like they build uh [51:34] data pipelines. They bring data into [51:36] chain streets walls and they transform [51:38] it into the like form that we need in [51:43] order to like use it in research and [51:45] trading. Um but they also have to learn [51:49] a lot when doing so. They have to [51:52] understand like how does this data set [51:56] work? How does this data domain work? [52:00] like what what is this data actually [52:03] modeling? Um they have to like [52:07] understand how we're going to use the [52:08] data, understand how the data is [52:10] produced and synthesizing all of that [52:13] like figure out like okay what should [52:15] Jane Street be doing with this data. So [52:18] you said a lot about what they need to [52:19] understand, but I'd love to hear a [52:20] little more about what they actually do, [52:22] right? Part of what you said is writing [52:23] a pipeline, and a pipeline itself is [52:24] just a kind of program, right? You some [52:27] program that like brings in and [52:29] transforms and regularizes the data into [52:31] the shape that you need. But like to [52:33] what degree is that just like a [52:34] mechanical matter of like parsing and [52:37] understanding, you know, you know, what [52:39] is the shape in which the the bits have [52:40] been laid out? And to what degree do you [52:43] need stuff that's like more kind of in [52:45] the domain and like I what's the shape [52:47] of that work that you need to do that [52:48] involves understanding more about the [52:50] data? [52:51] >> Some of it is mechanical but like we [52:54] build tools to automate as much of that [52:56] as possible. [52:57] >> Um part of it is thinking about what [53:02] does this field actually mean? Maybe [53:05] like we could go into an example like [53:07] what's an example of like some data [53:08] source that has some like stuff that is [53:10] on its base hard to interpret and then [53:12] you go out and like understand more [53:13] about the domain and can produce an [53:15] easier to use version of that data. [53:16] >> So company financials are like not [53:20] alternative at all. They're they're the [53:22] opposite of alternative like you know in [53:25] the US um at the moment companies um [53:29] public companies publish their financial [53:31] statements every quarter and you know [53:34] they it's published via like filings [53:37] with the SEC um maybe a snippet is [53:42] shared via press release at around the [53:44] same time and you have all of this data [53:48] about you know from like lines from a [53:51] company's balance sheet or income [53:52] statement and you want to turn that into [53:58] some like structured form that we can do [54:01] like quantitative studies on top of. [54:03] >> So that's like rough when you say [54:04] structure versus unstructured there's [54:06] like like a PDF or a big pile of text [54:08] and you want to convert that into like [54:10] morally like rows in a table. [54:12] >> Yeah. And you know there are companies [54:14] that will do this um that sell uh like [54:19] tabular versions of [54:21] um company financials. Let's start off [54:24] with what even is a company? How do you [54:27] know like what a company is? How do you [54:30] know which financial statements are [54:32] about the same company or about the same [54:34] like financial period of a company? Um, [54:37] some companies like uh have these like [54:42] weird structures. is a I think they're [54:46] called like dual listed companies where [54:48] there's company A and there's company B [54:51] and neither one is a uh parent company [54:54] of the other but like they have the same [54:55] management the same board often um and [55:00] there is some I don't know intercomp [55:03] agreement that they have such that like [55:05] owning them is economically equivalent [55:08] >> okay [55:08] >> and like [55:10] >> so you have two things are like formally [55:12] different companies [55:13] >> different companies practice [55:14] economically like are the same thing. [55:17] >> Yeah. And so you you think about edge [55:18] cases uh like that and how do you like [55:23] you receive data about something? Is it [55:26] one company? Is it both companies [55:27] together? What is it exactly? And [55:31] because you're trading on this, you [55:33] associate it with like securities. Um [55:37] does it apply to all the securities of [55:40] like both companies? [55:42] >> Right. And this just kind of goes back [55:43] into the metadata problem of like there [55:45] are all sorts of weird company [55:46] structures and different names for [55:48] things and different naming conventions [55:49] and sometimes you talk about the is [55:51] which is like the name of the thing [55:53] internationally and sometimes there's [55:54] the seedall which differs depending on [55:58] >> which clearing system you're in [56:00] >> and which um like does the data apply to [56:04] the company or like a share class um or [56:09] a specific or a specific listing like [56:12] >> this is a million ways of expressing the [56:14] names of things and there's a bunch of [56:15] like complex structural stuff that like [56:18] is kind of real but also maybe you want [56:20] to collapse thinking about it [56:22] >> and then companies publish multiple um [56:26] versions of their financial statements. [56:28] they'll put out uh one and then they [56:33] might like revise it or they'll like [56:36] change their you know fiscal calendar or [56:40] accounting in ways that make like a not [56:42] completely comparable to b throughout [56:44] this you have to think through like what [56:48] data was knowable at what point in time [56:51] and like what features do I actually [56:53] need for our trading [56:55] >> are there other like the I mean the kind [56:57] of metadata one is one that kind of come [56:58] up a lot in this conversation. Are there [57:00] are there like good non-metadated [57:02] examples where you have to like you know [57:04] you get some data source it has a bunch [57:05] of numbers in it but like what actually [57:08] do these numbers mean and like how do [57:10] you go from like oh yeah they told you [57:12] some stuff to like understanding like [57:14] where there might be errors in the [57:15] numbers or where like you know it might [57:18] you know mean different things for [57:20] different companies or different records [57:22] or different examples or whatever like [57:23] what's like just to get a sense of like [57:26] how the kind of domain specific stuff [57:29] shows up like beyond the kind of [57:31] traditional metadata problems and into [57:33] like the wilder world of the different [57:35] kinds of data you encounter. [57:37] So, like we talked about the satellite [57:40] photos of uh Walmart parking lots [57:44] >> and and by the way that's like an old [57:46] it's like such an old example like [57:47] people used to talk about when people [57:49] talk about like the classic example of [57:50] like [57:51] >> does it count as insider trading if like [57:52] you're flying in a plane and you look [57:54] down and you see like [57:55] >> you know I guess people you know that [57:56] you you see like you know something like [57:58] this like does that does that one is [58:00] that actually a good one? [58:01] >> I don't think so. [laughter] Um, I'm [58:04] might get like a bunch of LinkedIn [58:06] messages from vendors after this saying [58:08] like, "You're totally wrong. I have [58:11] these great photos of parking lots that [58:13] I'd like to sell you." Um, one problem [58:17] is that I don't know, it's kind of [58:19] annoying. You have to get a take a lot [58:22] of photos of a lot of parking lots. It's [58:24] noisy. Maybe you get not that many [58:27] photos per store per, you know, day or [58:31] week. Walmart has 20% of it its shopping [58:35] online. Other companies have more and [58:37] parking lots are not going to help you [58:39] when [58:40] uh you know measuring the behaviors of [58:43] New York City shoppers. And it's also [58:45] just like really indirect. Like the [58:47] thing you're getting at is like how many [58:51] people showed up which is different from [58:53] how much they're spending. [58:55] >> Mhm. [58:56] And like you kind of think from first [58:59] principles like who knows what people [59:04] are spending at Walmart stores. Well, [59:06] Walmart does, but they're not going to [59:08] tell you uh until the end of the quarter [59:12] >> um than uh the consumers do. So, I don't [59:16] know. You could ask them. [59:18] >> Although, one by one, it's going to take [59:19] a while. [59:19] >> Yeah, it's going to [laughter] take a [59:20] while. Um but like you know their bank [59:23] knows um the person the the bank that [59:26] gave them that credit card or you know [59:29] the Visa or Mastercard network or like [59:33] the company that provides the you know [59:37] plumbing to a host of like credit unions [59:43] or for their like uh credit and debit [59:45] card programs like [59:47] >> they know and maybe they're willing to [59:51] share like anonymized or aggregated um [59:54] statistics about like what spend they're [59:56] seeing. And so you get some information [60:01] about the transactions that some panel [60:05] of cards uh are making and then where do [60:10] you go from there? It's not a random [60:12] sample all consumer transaction in the [60:16] United States. [60:17] >> Mhm. [60:17] >> Transactions belonging to like one [60:20] credit card program. Maybe the people [60:23] who shop uh and have cards from like uh [60:28] credit unions are different from the [60:31] transactions from people who like have a [60:35] Chase Sapphire Reserve. Maybe like the [60:37] demographics of the panel are just not [60:41] the same as the broader United States. [60:45] Maybe people uh like drop in or drop out [60:49] of the panel. And you know, if there are [60:53] more consumers on the sample, does that [60:56] mean that people are spending more at [60:58] Walmart or does it mean there are more [61:02] consumers in the sample? Um, [61:05] >> and so like there are interesting [61:09] modeling questions about like well we [61:12] have this information and how do we like [61:18] make good predictions based on it [61:20] adjusting for all of those factors. [61:22] >> And is that like trying to kind of model [61:24] out and adjust and maybe like cross [61:26] compare different sources? Is that part [61:27] of the data engineering work or is that [61:29] part of what happens like on the trading [61:30] desk after you get like the cleaned up [61:32] data put in front of you? [61:33] >> It's a mix of the two. I think the but [61:36] like some of this like really just does [61:39] happen. um on the trading desk. But I [61:44] think the groundwork for doing all of [61:46] this comes from like a deep [61:48] understanding of like how these data [61:50] sets work and what information they [61:53] provide you when which the data engineer [61:57] typically like builds up a good [61:59] understanding of. [62:01] >> One thing I' I'd worry about you [62:02] mentioned there's all this like [62:04] aggregation and anonymization that's [62:05] done by the upstream vendors. You can [62:07] imagine like that could be done wrong or [62:10] just done in ways that introduces weird [62:12] biases into the data that's hard for you [62:14] to see. Like is that a problem that you [62:16] guys end up having to wrestle with? [62:18] >> Oh, I mean [62:20] so yes, vendors like [62:25] do weird things with their data all the [62:28] time. Um [62:31] sometimes they'll uh like you know have [62:36] data missing. Um sometimes they they [62:39] will say uh we compute this column one [62:43] way and then later tell you whoops made [62:46] a mistake. All those values were wrong. [62:49] Here's what you should have used [62:50] instead. [62:51] um sometimes you know sometimes [62:53] associating like a transaction with the [62:56] like stock of the I don't know the [62:59] merchant is difficult and they improve [63:03] these taggings over time. So sometimes [63:05] they'll like say you know these [63:08] transactions that you know we said were [63:11] one thing are actually like from this [63:14] other company or other brand. [63:15] >> Mhm. And actually, one thing that like [63:17] shows up if you have this issue where [63:18] like they're going back and fixing stuff [63:20] in the past is there's all these [63:21] causality questions. Right. [63:23] >> Right. On one hand, you know, isn't that [63:26] helpful? They're [63:28] fixing the data set. [63:29] >> Yeah. It was wrong now. [63:30] >> It was wrong. Now it's right. On the [63:32] other hand, if you are like doing a [63:36] study at a firm like Jane Street and [63:39] you're trying to figure out like if I [63:40] had been subscribing to this data set, [63:43] like would I be able to do good trades? [63:46] >> Mhm. [63:47] >> Um should I purchase the data set? If [63:49] you're trying to make that decision and [63:52] you are looking at the data that is not [63:54] actually what you would have received, [63:56] but instead you know the corrected more [63:59] accurate version later, you're not [64:01] actually studying like what trades you [64:03] would have done if you'd been [64:04] subscribing to the data set. You're uh [64:08] simulating what you would have done if [64:09] you had a time machine, [64:11] >> right? [64:11] >> And [64:14] although it's subtle, right? It depends [64:15] on the nature of the correction, right? [64:17] is sort of there's a question of like in [64:18] some sense what could have been known at [64:20] the time and also like what does it mean [64:22] for like what could have been known in [64:23] the future. There could be some data set [64:24] where like the underlying data like has [64:27] real information and then they correct a [64:29] completely mechanical thing and then [64:31] it's okay. But like it's very easy when [64:33] you're doing that thing to smuggle [64:34] information into the past and like it [64:36] becomes very subtle. Whereas if you just [64:38] like time stamp what you had at the time [64:40] then you know well at least it was [64:41] definitely possible to have it at the [64:43] time because at the time I had it. [64:45] >> Yes. Um so uh what we love is when [64:51] vendors say like this is exactly what I [64:54] delivered at this moment in time and you [64:58] know here is the corrected version that [65:00] I delivered at this other point in time [65:02] and not everyone does that and so what [65:05] we try to do is save all the data that [65:08] we have access to along with the like [65:11] time we received it so that no matter [65:13] what transformations we do later we can [65:16] always reconstruct like what we would [65:18] have known when, [65:19] >> right? And no matter what the vendor [65:20] does with their time stamps, we at least [65:22] always capture our time stamps of when [65:23] we got it, which by the way is a very [65:25] close analogy what we do with market [65:27] data, right? Market data also comes with [65:29] time stamps from the exchange and we [65:30] look at them with a certain amount of [65:31] like suspicion because like all sorts of [65:33] weird stuff can happen. You can have [65:34] some weird clock synchronization. The [65:36] times can be off in various ways, but we [65:38] capture stuff when it lands on our [65:40] network. And again like we sort of [65:42] there's still information in their [65:44] timestamps but like there's a way in [65:45] which we trust ours more than we trust [65:47] theirs. [65:48] >> Yeah. And knowing like okay I received [65:51] this packet at this nancond in time [65:54] gives us more confidence you know making [65:58] decisions based on our historical [66:00] studies than like uh I received this [66:03] packet at about this moment in time. [66:07] >> Right. [66:08] >> Yeah. So to switch gears for a sec, [66:11] yeah. Um, one thing that has changed a [66:13] lot in the last handful of years, in [66:15] fact, you know, a lot of that change [66:17] over overlapped with a period of, you [66:18] know, building up the alt data team is [66:21] boy golly has AI moved a lot. [66:23] >> Um, and I think it's kind of there's [66:27] kind of two different ways within the J [66:29] Street context for change. One is we [66:31] have a lot more ML models, neural net [66:34] models that are being used as part of [66:36] the trading process for consuming data [66:38] and transforming it. And then also we [66:40] have these like super smart LLMs that [66:43] are like useful productivity tools. And [66:45] I feel like both of these have lots of [66:47] potential to change the alt data [66:49] process. And I'm kind of curious how the [66:51] impact of those has landed along the [66:54] last few years. So uh I think there are [66:58] two kinds of impacts of AI here. One is [67:00] that like we [67:03] have better models for consuming this [67:07] data and making predictions about the [67:09] world, finding patterns and you know [67:12] that means that like the value of all of [67:17] our data of good quality data sets has [67:20] just like gone up. And with LMS in [67:23] particular, like it's easier to make use [67:28] of text data to like [67:32] extract information or features from [67:36] text that like would have been manual, [67:40] annoying, impractical, [67:43] a nest of reaxes, right, [67:45] >> uh beforehand. [67:46] >> Yeah. They're like an amazing tool for [67:47] extracting [67:49] structured data from unstructured text. [67:51] Yeah. Although also there's like a huge [67:53] causality problem, right? Because if you [67:54] use like a really up-to-date LLM to like [67:57] that knows stuff about old data and [68:00] trying to, you know, use it to featurize [68:02] some old data, [68:03] >> like you're going to get very confusing [68:05] things happen because the LLM is smart. [68:06] It knows things about the future. Then [68:08] >> yeah, the LM knows what happened to like [68:10] Enron. um [laughter] [68:14] >> the LLM training data like maybe it [68:17] includes the financial statement or a [68:20] future one right uh so that presents [68:22] some difficulties so then there's like [68:24] AI as a tool where like a lot of the [68:29] same trends and limitations that you see [68:33] in software engineering also high to [68:35] data engineering. They uh make it easier [68:39] to produce code to do analyses and in [68:44] the hands of like good data engineers [68:46] who know what they're trying to get from [68:51] these tools and [68:54] can tell whether the results are good or [68:56] bad. They're really helpful and you know [68:58] our data engineers um use LLMs also. Oh, [69:02] they make it easier than ever to [69:03] generate like bad code, [69:07] >> right? [laughter] [69:08] >> Um, [69:08] >> never has the gap between merely doing [69:10] something and doing something well been [69:12] larger in terms of cost, right? It's so [69:14] easy to just do something, but like [69:16] sometimes the results are very bad. [69:18] >> Yeah. And it's easy to do something and [69:22] think I have solved the problem when in [69:25] fact you have like failed to understand [69:27] the problem. [69:27] >> Mhm. [69:28] >> Right. So you have the normal ups and [69:30] downs of using AI tools like they're [69:32] they're amazing and also they have lots [69:34] of pitfalls. [69:35] >> Um and then you talked about AI as a [69:37] kind of feature extraction but there's [69:39] also like neural nets as models right as [69:42] new ways of extracting value out of the [69:45] data that you get. Like has that changed [69:48] the process? Has it changed like the [69:50] value of having alternative data? Has it [69:51] changed the pitfalls of using it? It [69:53] certainly changed the value of having [69:58] data alternative of or otherwise like [70:01] >> it's generally more valuable. Um maybe [70:05] like some shapes and quantities of data [70:09] are like more amunable to these models [70:12] than others. [70:12] >> So one thing I'd wonder about is like [70:14] the value of [70:16] some of the kind of what in other [70:18] contexts we'd call feature engineering. [70:20] Like I think one of the there's the the [70:22] whole like bitter lesson idea that lots [70:25] of ways that you try and like express [70:28] priors into the data itself or the shape [70:32] of the model or whatever maybe become [70:34] less useful as the models get bigger and [70:37] more powerful and stuff because some of [70:38] the kind of regularization and [70:40] featurization can kind of be done inside [70:41] of the model. Um, so there's like that [70:44] and then there's also the question of [70:45] like how just in general how much like [70:47] data cleaning and data preparation like [70:49] is that like more useful in the in a [70:51] neural net context is it less I think [70:54] the value of cleaning the data is [70:57] greater I think like I don't know if [71:00] your data is not point in time and [71:03] secretly leaking information from the [71:05] future into data that should be in the [71:07] past these stronger models are going to [71:21] certain kinds of like outliers and weird [71:26] patches of data that like some models [71:29] like handle well and other models like [71:31] handle poorly in their training process [71:34] and getting the quality right uh is you [71:37] know more important um for those models [71:39] I so like internally [71:42] that models will be able to do more. You [71:45] will have to like handcraft features [71:47] less and it will be better at figuring [71:50] out like which ones are um important or [71:54] not. But like the value of getting the [71:59] data that you do pass in right is pretty [72:02] high. And I think then it becomes like, [72:07] well, are LLMs with the skills and [72:12] harness and whatever we build about them [72:14] going to be able to completely automate [72:17] that? I think that's similar to will we [72:21] replace all software engineers with [72:23] LLMs. Um, [72:24] >> right too, [72:25] >> right? the current horizon and at least [72:27] what you can see immediately. It seems [72:28] like an enormous amount of like human [72:30] judgment [72:31] >> is incredibly important. [72:33] >> Yeah. [72:33] >> Like in some ways it feels like human [72:34] judgment just gets more important as [72:36] like it becomes the thing that unlocks [72:38] like you can like do all the stuff [72:40] really fast if you can figure out if [72:41] it's good. So like the verification [72:43] bottleneck becomes really important and [72:45] there's a kind of very critical human [72:47] part of that at the moment. [72:48] >> Taste for what should be built. Well [72:50] >> absolutely. [72:51] >> Yeah. Speaking of what should be built, [72:54] um I feel like the alt data world here [72:56] has been like, you know, a kind of Jane [72:59] Street flavored software engineering [73:02] adventure in that like boy, we've made a [73:04] lot of our own exciting custom stuff. Um [73:07] and we've also used some like external [73:09] outside world stuff. And I'm I'm curious [73:10] like how you guys have thought about and [73:12] navigated the question of like where [73:15] does it make sense to buy some external [73:17] product for like helping to manage this? [73:19] After all, we're not the only people who [73:21] manage these kind of alter data [73:22] pipelines. Um, and where we have decided [73:26] to make our own things and like has that [73:29] been good, has it been bad, like how do [73:30] you think about the choices there? [73:32] >> Yeah, some of our software stack like is [73:34] very much pulled from the rest of the [73:37] world. Like a lot of data engineers [73:39] outside Jane Street use dbt which stands [73:41] for data build tool. Mhm. [73:43] >> Um a data build tool is like a tool for [73:46] like describing and orchestrating [73:50] um transformations like in your data [73:52] warehouse usually like using SQL queries [73:56] but in like a code reviewable testable [74:02] composable good software engineering [74:04] practices way. [74:05] >> Sounds great. Um so I have seen 300 line [74:10] postres um views and functions uh in my [74:15] time at Jane Street and we don't want [74:18] any of that like dbtf lets you break [74:20] down the data transformation problem [74:22] into smaller components and like test [74:25] the properties of the data at each stage [74:27] so that you can like rely on it. [74:31] >> Mhm. Our like data warehouses query [74:34] engine is Trino. There are lots of [74:37] Python tools for like processing tabular [74:41] data. But other things, you know, we do [74:43] build ourselves where like if we were [74:45] starting from scratch and we're entirely [74:48] cloud-based. Um maybe we would do [74:51] something more offtheshelf. Um, but one [74:53] thing that is pretty cool is that Jane [74:55] Street is like good at building and [74:59] operating like on-prem data centers and [75:02] we had to be in order to like run low [75:06] latency trading systems before we were [75:10] doing any of that alter alternative data [75:12] stuff. [75:13] >> That's right. Right. We need and we need [75:14] our own data centers in part for like [75:15] the kind of physical location thing [75:16] where you need to like have your boxes [75:18] close to the exchange and also just some [75:20] of the like underlying abstractions like [75:21] clouds no good at giving you multiccast [75:24] right there like you can't easily deploy [75:27] FPGAAS there's all sorts of things that [75:29] you want [75:29] >> in terms of like control of the physical [75:31] architecture that you get in your own [75:34] data center that you just kind of can't [75:35] get in the cloud and like the cloud [75:36] gives you a bunch of other benefits and [75:38] these days we do a lot of both [75:40] >> right if you do have the ability to do [75:42] things well on prem solution that works [75:45] is maybe not the one that uh you would [75:48] use if you were like just using BigQuery [75:51] or Snowflake or um what have you, [75:55] >> right? And I guess part of this is like [75:56] you know came up in the previous uh one [76:00] of these conversations was we built our [76:02] own data warehouse, right? So we have [76:03] supertore and we didn't build it for alt [76:06] data or at least not primarily for alt [76:08] data but like that's like a tool that [76:10] alt data now uses. [76:11] >> Yes. And uh it's great. It's great [76:14] having all of our data in one place and [76:17] being able to handle the volumes of [76:20] trading data and other data that we use. [76:24] It's useful for being able to join it to [76:26] all of our other services um internally. [76:30] And the cost model is different. I don't [76:34] want to imagine how much we would spend [76:39] in credits or slots if all of the [76:42] queries that we are uh running now were [76:46] like build in like a cloud uh warehouse. [76:51] >> So, so why is that like what how is the [76:53] how is the cloud cost model different [76:54] from the kind of cost model that we get [76:56] from this thing that we built ourselves? [76:58] So like the cloud uh cost model will be [77:04] based on you know [77:07] either the amount of data you read or [77:10] the amount of like time on like in their [77:17] units of compute. [77:18] >> Mhm. um they use. And what we can do is [77:23] just think about like the cost of [77:24] acquiring the hardware and operating the [77:27] hardware which all in all is like [77:29] significantly lower like they have like [77:33] large uh curse margins. Um [77:36] >> is it is it that the overall margins are [77:38] are large or is it more that like the [77:41] incremental cost [77:42] >> model? You're also not thinking about [77:45] like the cost of like trying this one [77:47] new thing, this one new query. [77:49] >> And if you just sort of take the things [77:51] that you get from cloud vendors and say [77:53] let's let's look at those prices and [77:56] then apply it to our workloads, you'd be [77:57] like, wow, I could get a lot of hardware [77:59] for that cost. So just like the way the [78:00] math in practice works out is that like [78:03] it would incentivize us to spend a lot [78:05] of time figuring how to optimize and do [78:07] less work on the system than it does [78:10] when we actually go out and buy the [78:11] physical hardware. So like economic [78:13] theory and like architecture aside, it's [78:14] just like that's how the pricing model [78:16] seems to work. [78:18] >> Yeah. If we were using one of these like [78:22] uh other products, we would spend a [78:25] tremendous amount of time like [78:27] optimizing our spend and and like trying [78:31] to shape our workloads [78:33] to like fit their cost model. And we do [78:37] think about the performance of Trino and [78:39] our data warehouse. we end up spending [78:42] less time on that, [78:44] >> right? Because because overall the costs [78:46] in fact are lower. [78:47] >> Yeah, [78:48] >> makes sense. [78:49] >> So another thing I think is maybe [78:51] interesting to talk about is like you [78:53] know we went from in 23 one data [78:57] engineer to now more than 20 data [78:58] engineers. Um and it sounds like we're [79:01] continue to be very hungry and are [79:03] eagerly hiring [79:04] >> love to hire more. [79:05] >> Um and so I'm curious like what makes a [79:09] good data engineer? like what are you [79:10] looking for when you're trying to hire [79:11] someone and then how do we find them? [79:14] >> Yeah. So the most important [79:19] um characteristics I think are like [79:22] curiosity [79:24] and a good investigative process. As [79:28] part of the job, you'll be learning [79:29] about some new domain, some industry, [79:32] some kind of data, some kind of trading, [79:35] and [79:36] also you will have like [79:40] messy, unfamiliar data that is useful, [79:45] but also has lots of embedded problems [79:48] in it. And [79:50] I think to succeed, you kind of have to [79:54] enjoy learning about all these new [79:57] things. [79:58] >> And you have to enjoy learning about [80:00] these new things. You have to enjoy like [80:02] getting into the details. You have to be [80:04] careful and think about like what you [80:08] know and what you don't yet know and how [80:12] you would support going from point A to [80:14] point B. I think people with science or [80:18] social science backgrounds who do work [80:21] with like messy real world data and try [80:25] to make sense of it are well suited to [80:28] this. We also you know look for [80:30] engineering skills. I think the systems [80:32] complexity of [80:35] what data engineers are doing is you [80:38] know lower than much of what we ask our [80:40] software engineers to do. But like the [80:44] data and business complexity is still [80:46] very high. [80:47] >> Um data pipelines are code. Um [80:51] >> you still want them to be good. [80:53] >> Software. You want them to be good code. [80:54] You want it to be like uh you know [80:56] clear, correct, maintainable. [80:58] >> Mhm. [clears throat] [80:59] >> And we look for that too. Um and where [81:02] do we find uh data engineers? Some of [81:05] them have worked in the financial [81:06] industry before. Some of them are people [81:11] who were like the data person at their [81:16] like small or midsized startup where [81:20] they like had to like [81:24] kind of understand the data and the [81:28] business context and deal with its [81:31] messiness because there were only so [81:35] many other people around to do do that [81:38] who also you know have developed like [81:40] good software engineering skills. [81:43] >> And so so are you mostly looking for [81:45] people who essentially kind of have data [81:47] wrangling experience as kind of a thing [81:50] they've done already professionally? [81:52] >> Usually though like that doesn't have to [81:55] be like [81:57] you know at a company it can be like as [82:01] part of like research of doing science [82:04] or some other way. Mhm. [82:06] >> Um, all of the people we've hired so far [82:09] have been experienced hires who, you [82:12] know, were doing some thing [82:17] beforehand. Next year, we're hoping to [82:20] venture into hiring like interns. Yeah, [82:24] we [82:25] started talking in 2025 about like [82:29] interviewing in 2026 for an internship [82:31] that runs in the summer of 2027. for [82:34] people who start in 2028 after [82:36] graduating from school probably and you [82:40] know are really ramped up and um doing [82:42] useful work in 2029 um right which is [82:46] long-term planning and I think we're [82:49] we're looking for people who like care [82:50] about the data first and you know maybe [82:54] they have good engineering skills now [82:55] maybe they like have the potential to [82:58] after a bunch of training. [83:01] >> Mhm. Right. Right. But like the kind of [83:03] excitement about digging into the data [83:04] is like the primary thing you're looking [83:05] for. [83:06] >> Yeah. While on the other hand, there are [83:08] people who work with a lot of data and [83:10] are like I am excited about building you [83:12] know fancy models and neural networks or [83:16] about like building scalable systems the [83:20] ML or the software engineering [83:22] >> parts of it. And you know we want those [83:26] people at Jane Street too but not for [83:29] this role. [83:30] >> Got it. And then just at the interview [83:32] side like you want you know to find [83:35] people who are excited about and have [83:37] good taste about how to think about and [83:39] dig into data like how do you use an [83:41] interview to sus that out? [83:43] >> It's hard. Um [83:46] we uh have you know a few data [83:51] investigation interviews [clears throat] [83:53] or data wrangling interviews um where we [83:57] give them some unfamiliar data set and [84:01] they investigate and build some model of [84:04] how it works and like do something with [84:08] it. seeing how someone approaches that [84:13] problem. Are they careful and detail- [84:16] oriented and do they like think about [84:20] what they know? Um what assumptions [84:23] they're making, how they would test [84:25] those assumptions or do they like write [84:28] a bunch of code and say hopefully this [84:30] works [84:32] but I'm not sure, [84:34] >> right? Right. And once again, kind of [84:35] rounding back to the like, you know, [84:36] kind of engaging with like the real [84:38] world underneath the data and trying to [84:40] actually think about what's going on and [84:42] >> seeing if if that affects what you [84:44] should be doing. [84:45] >> Yeah. [84:45] >> Awesome. All right. Well, maybe that's a [84:47] good place to end it. [84:48] >> Yeah. [84:48] >> Thanks for joining me. [84:49] >> Thanks, Ron. [84:51] >> You'll find a complete transcript of the [84:53] episode along with show notes and links [84:55] at signalsandthreads.com.