头部量化CTO｜从业8年，交易科技依然让我兴奋

我们公司是国内第一批做低延迟交易的团队。我感觉交易技术蛮有挑战，并且是长期存在的，这非常吸引我。

回顾一下，进入公司后，我的职业生涯大致可以分几个阶段：

第一个阶段，2013-2014年，我作为开发人员独立负责一个模块，解决早期交易的自动化，随后开始解决研究的自动化。

第二个阶段，从2015年到2018年，我开始带一个组，积累技术，开始开发一个更强的量化研究平台。

第三个阶段，从2019年到现在，我开始带多个组，解决业务增长过程中出现的更多问题，有更深的问题，也有新的技术方向。

整个阶段的发展速度其实比我加入公司之前的预期要稍微快一点。回过头看，几个阶段，特别是第2阶段做的不够好。

那么作为技术骨干，自己怎么样去摸索找方向呢？了解业务要求之后，你就知道要解决技术的哪些问题。技术目标确定后，会去想各种方法。并且需要在现有技术下再深入一层，比如应用层遇到问题时，需要从操作系统层入手。或扩宽解决问题的广度，比如看一下同行其他人怎么在解决，或从国外一些机构公开获取的资料推断，自己实验并验证，或从学术界获取一些思路。

工作中，总体方向其实还是很清楚的，主要是如何具体去做。大部分问题从本质上看是计算机领域的经典问题，其他人大概率已经遇到过，我们不是第一个遇到的。这个过程中要不断积累技术的深度和广度，以及对业务本身的理解。

回顾起来，由于没有在尽量短的时间里把业务理解，导致后面遇到很多问题时，严重缺乏从业务角度解决问题的最佳方案，踩过一些印象深刻的坑。我毕业后第一份工作做的是与专业完全匹配的方向。转换行业到量化后，在思维惯性下，业务知识的缺乏没有引起注意，没有系统性地对业务知识快速补充。

具体举例来说，前面讲到的第二阶段，从2015年到2019年整整5年，其实做了几个很失败的项目。失败的因素非常多。当时使用的技术不是我所擅长的，业务的理解没有准备充分。我后来直面了其中的关键问题，集中精力逐个迅速解决。从感觉上讲，就是把过去担心的地方变成放心的地方。解决过程中，依靠团队的同时，还需要发挥自己的主动性，克服自我的思维缺陷或行动阻力。

比如当时数据存储层频繁出现性能问题，持续了较长一段时间。我后来痛定思痛，集中精力深挖技术细节，learn something the hard way（用深刻的方式学习教训）。解决这个问题后，发现这里再也没什么值得担心的了。

02. 技术上能不能沉下来、能否折腾

我和团队相处，矛盾比较少。工作中也经历过几次团队和自我角色的转换，都还能处理过来。我觉得工作中很多问题可以通过沟通解决，关注自己想做的事情就行。

我向上沟通时，其实更多的是承担能承担得起的压力，忽略工作无关的情绪因素，及时暴露发现的风险，主动沟通发现的机会。

和团队沟通时，我在不停的寻找一些动态平衡点。我其实对自己的成长有蛮大的焦虑感。加上时间精力比较分散，需要去兼顾团队和自己的成长。比如各种实盘问题，紧急需求，重要项目交错出现，每天都有突发的事情，很容易顾此失彼。

要解决这些问题，很多方面都很重要。首先我们要找到对的人，招聘相当重要。二是自己需要持续成长，能解决新的问题。然后尽量达到团队和个人的共同成长。我认为工作的意义也在于此。

所以我招人时比较看重的，一是他看技术上能不能沉下心来，不断提升自己的技术深度，这是第一项必备的能力。因为深度不够很快会出现成长的瓶颈，容易迷失方向。第二，我会看他在沉下心来的同时，能不能折腾出新的东西、取得突破。这两点看起来有些矛盾，所以同时满足的很稀有。

另外要看个人的成长和公司的成长能不能双赢，双方匹配才算是合适。我也遇到过一些95后，他们年轻，更独立，作为互联网的原住民，对一些趋势的认识比石器时代的居民更敏锐。但对待技术时，还是需要他们能沉下心来，掌握底层原理，尝试原创，而不是追逐技术潮流，被几年一次的各种方法论带偏（no silver bullet）。如果在一个有具体技术应用场景，有明确的成长方向，严格的要求下，成长可能会相对顺利些。

量化相比其他传统行业，会不停出现新的东西。所以技术从业者需要自己去发现问题，然后才是解决问题。技术上无法按照已有行业标准，或提前规划好的产品节点开发。

这个行业需要能适应高度竞争，不断变化的环境；对量化有认知，有热情，喜欢挑战的人。

03. 技术对团队胜利不可或缺

研究和技术在量化中是同步发展的，市场发生变化时，常常需要研究和技术协同去解决。技术看起来像是游戏中的辅助型角色，但作为独立的角色，对团队取得胜利不可或缺。

从技术的角度看，比如早期的低延迟交易，延迟非常关键，延迟问题会导致部分策略无法工作。到最近的GPU算力，直接影响策略的迭代速度。

如果在这个行业待得不久，第一印象肯定觉得技术是纯粹性支撑的作用。做个三五年，可能还是会有这种感受。如果对业务开始有一定的理解，同时对技术有更深的理解，慢慢的会觉得有很多阻碍业务发展的（技术）问题需要去解决，有些问题已经存在很长时间了，可能并不是当初认为的、满足眼前的要求就行了。有些问题解决后会打开新的视角，带来不一样的机会，不能用线性的思维外推。

所以我认为，技术职位能否有成就感，关键看他有没有足够的勇气和主动性去解决行业内一些比较重要的问题。其实问题一直都在的，只是有些人选择忽视，觉得这个东西不重要。如果去问下有更有经验的人，他们可能会有不一样的看法。

   04. 宽度和深度

这两个其实都不矛盾。宽度，至少应该达到领域相应本科通识教育的水平，不管是技术还是业务。宽度上的缺乏会导致很难提出系统或更优的解决方案。对于非计算机专业从事技术开发的同学，需要在技术基础上具备计算机本科的程度。

接下来是深度，需要对领域内主要的技术挑战有比较本质的理解，比如常见的CPU和IO问题。

比如某人加入了一家量化公司，成为技术人员，他是就研究算力、低延迟，或者数据库这一个方向，还是说每个方向都有一个比较宽的了解？我认为如果他不想看全局，只想解决一些很特定的问题，其实他也可以发展好。比如可以只解决延迟的问题，或只解决算力的问题，如果想有更全面或更深的理解的话，业务上的问题或计算机系统的问题可能都需要去看一下。

技术人员的全面其实会更重要，因为量化行业分工不像互联网那么细，互联网每个岗位同时有多个人在做，而量化行业多个方向可能只有一个人在做，需要他有更宽的知识面。如果缺少综合能力，可能会很难主动发现问题。

另外，时间不够用是常态，技术从业者需要利用好工作中的时间，以及工作之余的时间，根据实际工作中所在团队具体的工作安排，去解决问题。一段时间集中精力尽量解决一件事，待解决的比较彻底后，再去解决新的问题。

 05. 对业务技术足够理解后，能提前预知和准备问题

从工作内容来看，技术方向可能分两种：一种比较偏底层，一种比较偏上层(应用)。偏底层的，可能更需要人能沉下心来，积累大量的东西，才能从系统或更底层的角度解决一个问题或提出新的问题。偏应用需要能贴近业务，看到业务上有什么机会或问题，然后迅速迭代解决问题。

技术方面的创新其实还蛮多的，有市场变化带来的，也有新技术的出现带来的，两种因素交替出现。比如新的交易方式，CPU的升级，新网络设备的出现，GPU计算架构的升级，存储硬件，新的软件架构都会带来新的机会，而且创新的速度非常重要。

另外我们技术团队的部门名称中就包含“创新”两字，也直接说明了这一点，创新是我们职责所在。

如果对业务和技术有足够的理解，应该会提前知道接下来哪些地方会碰到问题，或存在新的机会。这个时候就可以投入时间，提前准备解决方案。

比如我们早期编写策略时用C++，如果团队对C++都比较熟悉，那么不会存在问题。随着团队的扩充，必然有新的同学对C++没有那么熟练，这个时候策略出现程序问题，就不太容易定位具体是哪个模块出现问题。C++程序问题绝大部分都是内存相关问题。报错的地方并不总是问题原因，所以每个模块的开发人员没法在不介入的情况下证明自己的模块没有问题。这导致解决问题效率非常低。

当这种问题出现的频率逐渐增加时，我们开始从计算机语言方向去寻找一些解决方案，试图找到一个性能几乎没有损失，兼容已有C++程序，能规避常见内存问题，方便调试的方案。后来的解决方式在今天看来就非常常见了，我们当时hack了一些Python底层库来解决，当时解决问题时，市场上还不太容易找到相应技术的人才。

语言是工具，其实机器学习、深度学习也是工具，数据本身也是工具，通过分析来帮助决策。每种工具有擅长的地方和不擅长的地方，要看它能不能更好的解决这个领域遇到的问题，然后看一些基本指标能不能满足。学习曲线怎样，开发和维护成本怎样，会用的人多不多，比如是不是容易上手，出现问题容不容易解决。

语言的采用不仅需要看语言本身的成熟度，也要结合自身的情况判断，不同的语言对于开发，运行效率会有一些影响，但不会是决定性因素。

另外，创新一定会犯错，但错误的成本可以做到尽量可控。在推进的过程中也一定会遇到阻力，需要推动大家改变过去的习惯。和改变自身习惯(通常是不好的习惯）的阻力类似，这个过程也会帮你反复检验创新的方向，只有真正给大家带来价值的创新才有意义。

我认为试错是一种次优的方式，工程上一定有方法来解决这个问题。我觉得最好还是提前去准备，积累知识，试验改进，测试充分，设想可能出现的问题，真出现问题时快速应对。

对于技术人员来说，创新意味着可能刚开始不停出问题，然后不停的被批评。你会怀疑，又需要做不一样的尝试，又不让犯错，是不是无解。但实际上是有解的，有些东西你提前做充分的测试，或者做一下模拟，就可以去解决。就好比发射火箭，犯错的成本相当高，一定有工程上的办法可以把犯错的成本降低到可控的程度。

 06. 量化技术未来方向

在计算机体系结构上，延迟和吞吐会是长期存在的瓶颈，需要不断突破。在算力上，性能和计算架构也是长期需要解决的问题。和业务紧密相关的部分，还是不断会有新的方向出现，比如新的计算方式，数据处理方式，新的AI模型。

至于关于超算，我觉得与其讨论它是否是一个方向，它更接近于是一个需要迫切解决的问题。市场的变化、高频因子的失效可以通过提升算力解决，使因子迭代速度更快。但是否算力越高，因子表现越好，是一个不太容易论证的问题。

 07. 通过阅读保持对技术的兴趣

我每天早上差不多6:40起床，送小孩上学。到公司一般是7:30左右，开盘前会自己看一些东西，比如电子书，文档，pdf资料等。早上看书居多。

到交易时段时，会去处理一些跟实盘相关的问题，如果没有实盘问题，会去讨论开发问题或业务需求，然后根据情况解决其中的部分问题。

晚上一般也会在公司待到8:00或9:00，回家后有时候会接着看一下文档和电子书，减少使用电脑屏幕的时间，或者处理一些沟通上的问题，工作时长我觉得还好。

周末我大概有1/2的时间陪小孩上各种培训，期间会间断看一下pad上的文档。另外1/2时间工作，家务，或锻炼。业余时间拓宽知识面多一些，有利于你去保持一些技术兴趣，看到一些有意思的地方，你会很兴奋，因为不仅有用，也很有趣，这种兴奋会持续一段时间，让你总想着去完成一些有意思事情。

这样你在处理其他技术工作的时候，不会显得很枯燥，找不到这种乐趣的话，工作起来确实会非常难受。所以需要自己能找到一些乐趣，能自己折腾起来。大部分是网上自己找的电子书，pdf文档等，每段时间看的主题都不太一样，会结合实际需要和技术兴趣，还是实用性东西看的居多。

搜索资料的第一种途径是自己在网上搜索，再根据文章中的引用，接着去找更原始的第一手资料，比如wikipedia上有非常系统的资料，会交代非常详细的背景。另外我会从人或公司的角度去查找一些相关的资料。我记得上大学那会选修过《信息检索》一门课，当时没有太深的印象，其实对我的潜在影响持续到今天。

 08. 量化VS互联网 量化VS传统金融

互联网或通讯行业的技术路线大部分已经提前规划的比较好，且分工明确，或有些领头的公司或行业专家输出成果，大部分情况是如何应用到实际场景。量化行业中可能大部分问题需要自己发现。少部分人的创新成果不太会公开，所以需要自力更生。

传统金融行业，如银行、保险，是比较明确的业务驱动型，业务的稳定性会高于技术的更新。量化行业的技术还是存在不断更新的压力。各有优劣，如果你喜欢竞争或创新，在量化行业就会比较适应。

 09. 要自己思考和实证

进入某个行业，首先需要对行业有一定的了解，然后看行业中要解决的问题是不是自己喜欢的，行业较长期的发展怎样，是否能在其中贡献自己的价值，发挥自己的优势。

还要看自己在乎什么，不在乎什么，没有一个行业或公司是完美的，需要有自己的判断。

以技术为例，比如网上一些观点，认为技术含量低，最好自己做下思考或实证。通常情况下，每个行业的专家不会认为自己无事可做，马上失业，真实情况是，他们会看到大量其他人看不到的问题或机会，这些也是诞生创新的地方。

从技术上看，比如经常碰到的延迟问题，延迟很低时吞吐一定很高，而吞吐很高时，延迟不一定低。吞吐问题可以用并行，流水线，Cache等方式解决，而延迟解决起来手段就很受限、更硬核。

我觉得可能大部分量化做技术的，公司管理应该还是会相对比较开放的，他不会说代码都不给你看。如果技术人员能证明自己的价值和潜力，会获得不一样的机会。

即使自己看得见的机会再少，也不要给自己设定天花板，很可能这个天花板会被自己降得太低了，提升自己的专业能力，市场自然会给你准确的定位，何况在量化这样高度竞争的行业，好的人才具备非常高的溢价。举例说，如果是做后端开发也有多个发展路径，可以继续做深技术，量化行业用到的数据分析，机器学习等需要后端开发参与解决；也可以深度参与到业务中去，证明自己的潜力，方向都是开放的，关键靠自己去争取。我身边就有非常多的这样的例子。

*点击左下角阅读原文获取交易门最新职位信息