3. 编程与工具链面试
精算模型工程师的编程面试，很少单纯考算法题，而是围绕“数据能否跑通、模型能否复现、流程能否自动化”三条主线展开。面试官真正想确认的是：你能否用代码把精算假设变成可交付、可审计、可协作的模型资产。因此本章不按语言罗列语法，而是按工具链在精算工作流中的位置来拆解考点。
一、核心原理：工具链是精算交付的“证据链”
面试官评估编程能力时，底层逻辑是“可追溯”。SQL 决定数据口径是否可解释，Python/R 决定模型逻辑是否可复现，Git 决定变更是否可审计，Airflow 决定流程是否可重跑，VBA 决定业务侧是否可落地。任何一环断裂，模型都可能变成“只有作者能跑”的黑箱。因此回答编程题时，不要只讲语法，要讲清楚数据从哪来、怎么处理、如何验证、出错怎么回滚。
面试表达公式：工具定位 + 关键操作 + 验证方式 + 协作影响。例如“我用 SQL 做分层抽样，用 Python 做向量化定价，用 Git 管理假设版本，用 Airflow 每日重跑并校验差异”。
二、方法流程：从取数到调度的五步闭环
- SQL 取数：先确认粒度、时间窗口、主键唯一性，再写聚合。常用校验是行数对比与空值率。
- Python/R 建模：优先向量化，避免逐行循环；关键假设写成配置或参数表，便于复现。
- Git 管理：按功能开分支，提交信息写清假设变更，合并前做代码评审。
- Airflow 调度：用 DAG 定义依赖，设置重试与告警，保留每次运行的血缘信息。
- VBA/Excel 交付：把结果封装成业务可操作的模板，锁定公式并加校验页。
# SQL 粒度校验示例
SELECT policy_id, COUNT(*) AS cnt
FROM premium_table
GROUP BY policy_id
HAVING COUNT(*) > 1;
# Python 向量化定价片段
import numpy as np
def price(age, sum_assured, rate):
return sum_assured * rate * np.exp(0.03 * age)
# Airflow DAG 依赖片段
with DAG("actuarial_model_daily", schedule="0 2 * * *") as dag:
extract = PythonOperator(task_id="extract", python_callable=run_extract)
model = PythonOperator(task_id="model", python_callable=run_model)
extract >> model三、案例/场景：面试高频追问与应对
| 工具 | 高频追问 | 加分回答要点 |
|---|---|---|
| SQL | 如何排查数据重复？ | 先查主键唯一性，再查关联膨胀，最后用窗口函数去重 |
| Python | 循环太慢怎么办？ | 向量化、分块、用 numpy/pandas 替代逐行，必要时用 numba |
| R | 与 Python 如何取舍？ | 统计建模与可视化选 R，工程化与调度选 Python，按团队栈决定 |
| Git | 假设变更如何管理？ | 假设入配置，分支隔离，PR 评审，tag 标记监管版本 |
| Airflow | 任务失败如何恢复？ | 设置 retries，幂等设计，支持 backfill，保留日志与血缘 |
| VBA | 为什么不用 Python 替代？ | 业务侧 Excel 环境受限，VBA 可嵌入模板，降低使用门槛 |
公司侧重点差异：互联网保险偏 Python + Airflow + 云数仓；传统寿险偏 SQL + Excel/VBA + 监管报表；再保险与咨询偏 R + Git + 可复现报告。面试前先判断目标公司属于哪一类，再调整回答权重。
四、误区与复盘：编程面试的四个常见失分点
- 只讲语法不讲场景：面试官更关心你用工具解决了什么精算问题，而不是你背了多少函数。
- 忽略数据质量：不校验空值、重复、口径，模型结果再漂亮也不可信。
- 版本管理缺失：假设变更没有记录，监管或审计时无法解释差异来源。
- 调度设计不幂等：重跑产生重复数据，导致报表口径漂移。
复盘建议：每次项目结束后，用“数据—代码—版本—调度—交付”五栏做一次工具链自检，把缺失环节补成下一轮面试的案例素材。
总结来说，精算模型工程师的编程面试，考的是你能否用工具链把精算假设变成可复现、可审计、可协作的交付物。回答时始终围绕“口径、复现、版本、调度、交付”五个关键词，就能把编程题答出精算专业度。