摘要：加拿大数据岗求职里，专业叫Data Science或Business Analytics，不代表面试就以Machine Learning为主。一名女王大学商业分析硕士、本科统计学背景的学生，Python、SQL、R基础都不差，却一度把注意力过多放在模型和技术细节上。蒸汽教育（Stem Career Group）重新按银行Analytics岗位拆解项目、SQL、Metrics和Business Recommendation后，他最终拿到Scotiabank Global Banking and Markets数据分析团队Offer。

很多Data Science、Statistics和Business Analytics硕士准备加拿大求职时，会有一个非常自然的思路：

自己读的是Data Science，就应该重点准备Machine Learning。

于是从开学开始复习Regression、Tree-based Model、Clustering、Neural Network，课程项目做了不少，Kaggle也刷过，简历上写着Python、R、Machine Learning。

真正开始面试以后，却经常遇到一个让人有点困惑的情况：

为什么对方一直在问SQL？

有时候甚至整轮面试都没有让你推一个复杂模型。

反而在问：

两张表怎么Join？

怎么找每个用户最近一次Transaction？

如何处理Duplicate？

一张业务表出现异常值，先怎么查？

这个Metric为什么突然下降？

如果数据结果和业务团队的判断冲突，你会怎么验证？

最后再问一句：

“所以你建议Business怎么做？”

蒸汽教育（Stem Career Group）服务过一名很典型的加拿大数据岗学生。

本科就读于加拿大Western University统计学专业，研究生进入Queen's University Smith School of Business的Business Analytics硕士项目。

他的Data背景并不弱。

Python、SQL、R都有基础，研究生阶段也做过Predictive Modeling和Data Visualization相关项目。真正的问题不是“不会Machine Learning”，而是他最开始理解的数据岗，仍然比较接近学校里的Data Science：

拿到数据，训练模型，比较Metric，解释结果。

但他后来真正申请的，是Scotiabank Global Banking and Markets的数据分析岗位。

这两个世界之间，差了一层非常重要的东西：

企业不是为了训练模型而训练模型，它需要你先把数据变成一个可以用于决策的答案。

第一次拆岗位，他才发现Data Scientist只是数据岗的一种

这名学生最初看招聘网站时，会把很多带Data、Analytics、BI、Data Science的岗位放在同一个文件夹里。

这也是留学生数据岗求职特别容易出现的问题。

学校里的专业名称可能是Data Science。

于是学生下意识认为：

“我以后找的应该都是Data Scientist。”

但真实Job Market里的Title并没有这么整齐。

同样在加拿大银行和大型企业里，Data Scientist、Data Analyst、BI Analyst、Business Intelligence、Analytics岗位，实际工作重点可能差很多。

比如更偏Data Scientist的岗位，通常会更关注：

统计建模、Machine Learning、Python、Model Evaluation、Experiment，部分团队还会进一步涉及模型部署、Data Pipeline、Cloud或者现在的LLM应用。

Data Analyst则经常离业务更近。

SQL、Excel、Dashboard、Reporting、Data Quality、Metric Definition、Ad-hoc Analysis和Business Recommendation，可能反而是每天真正大量使用的东西。

BI岗位又会继续偏向：

SQL、Data Modeling、Dashboard、Reporting Layer、Power BI或Tableau，以及如何把不同业务部门的数据需求转成稳定的报表和指标体系。

还有很多只写着Analytics的岗位。

名字最模糊。

有的接近Product Analytics，要做Metrics和Experiment；

有的接近Finance Analytics，要做Reporting、Reconciliation和Forecast；

有的接近Data Analyst；

有的甚至已经很接近Data Engineering。

所以蒸汽教育团队给这名学生做岗位规划以后，第一件事并不是继续增加Machine Learning课程，而是把他准备申请的岗位重新分类。

不要按照自己的专业名称准备工作，要按照具体JD准备。

这句话后来几乎贯穿了整个申请季。

Scotiabank现在的数据岗，也能看出这种区别

如果把这个历史案例放到现在看，这种岗位差异反而更加明显。

Scotiabank目前在Toronto公开的Data Analyst岗位，核心能力仍然大量集中在SQL、Data Analysis、Dashboard、Reporting、Data Quality以及Business Recommendation。

有的岗位明确把Strong SQL放在主要Technical Skills中，同时要求Power BI、Tableau、Excel，以及对大型数据集和Relational Database的使用能力。

Python或者R当然有价值，但在部分Data Analyst JD中甚至只是Asset，而不是整个岗位最核心的筛选条件。

再看同一家银行当前公开的Data Scientist - AI/ML岗位，能力要求马上变了。

Python的重要性明显提高，同时需要Machine Learning、Deep Learning、NLP、LLM、模型Evaluation、Data Pipeline、SQL、Spark，以及如何把Solution部署进Production。

公司相同。

都和Data有关。

面试准备却不应该相同。

这也是为什么一个学生如果看到“Scotiabank”以后只准备一套Machine Learning题库，很容易出现偏差。

真正应该先看的是：

你到底申请Scotiabank里的什么岗位？

他的课程项目最大的问题，是一直在解释模型

这名Queen's学生开始准备时，学校项目并不少。

其中有一段比较典型的Customer Churn Prediction项目。

如果按照学校Project的方式介绍，学生很容易从技术开始：

先做Data Cleaning。

再做Feature Engineering。

尝试几个Classification Model。

比较Accuracy、Precision、Recall或者F1。

最后选择效果最好的Model。

从课程角度看，完全合理。

但是把这个项目拿去申请银行Analytics岗位，mentor问的第一句话却可能不是：

“你为什么选择Random Forest？”

而是：

“银行为什么要预测Customer Churn？”

这一下，项目的重点就变了。

如果一个客户可能离开银行，Business真正关心的是什么？

哪些客户值得Retention？

所有可能流失的客户都要提供相同Offer吗？

如果Retention Campaign需要成本，怎么决定优先级？

你预测准确以后，业务团队下一步到底做什么？

这时候学生才开始意识到，他以前的项目介绍经常停在：

“模型预测得不错。”

但企业真正想继续问的是：

“所以呢？”

因此，蒸汽教育后面重新整理这段经历时，没有凭空改变项目本身，而是把学生真实做过的Data和Model工作重新放回Business Context。

从“客户流失预测模型”，逐渐整理成：

为什么要研究客户流失；

哪些数据可能解释流失；

模型如何区分高风险客户；

怎么评价预测结果；

如果给Business一个Recommendation，会怎么设计Retention Strategy。

项目还是那个项目。

但学生开始从“展示算法”转向“解决问题”。

为什么SQL到了银行Data岗位，反而绕不过去

很多DS学生不太愿意接受的一件事情是：

自己学了那么多Machine Learning，为什么找工作还要花大量时间写SQL？

但如果真正进入企业Data Workflow，答案其实很简单。

模型开始之前，数据在哪里？

通常不会整整齐齐放在一个CSV里等你下载。

可能在Customer Table。

可能在Transaction Table。

可能在Product Table。

可能来自不同System。

甚至同一个Customer ID在不同Data Source里还存在不一致。

所以真实数据问题往往从SQL就开始了。

比如一个看似简单的业务问题：

“过去三个月，哪些高价值客户的信用卡活跃度明显下降？”

在模型之前，首先要回答：

高价值客户怎么定义？

活跃度用Transaction Count还是Spend衡量？

过去三个月和哪三个月比较？

一个客户有多张卡怎么办？

退款Transaction算不算？

缺失值怎么处理？

异常的大额交易怎么判断？

这些东西如果取错，后面的Machine Learning做得再复杂，也是在错误数据上优化。

所以Mock里，SQL训练也不会只停在：

SELECT、WHERE、GROUP BY。

会继续练：

JOIN。

Subquery。

CTE。

Window Function。

Aggregation。

Date Function。

Ranking。

以及最容易被忽略的Data Quality。

例如一道基于服务经验设计的模拟场景：

有一张Customer Table和一张Transaction Table，希望找出每名客户最近30天的总消费额，并与过去90天平均水平比较。

学生很容易直接开始写Query。

mentor会先追问：

一名客户有没有Multiple Account？

Transaction表里有没有Refund？

同一天重复记录怎么办？

Timezone会不会影响Date？

如果客户过去90天没有交易，平均值怎么定义？

这些追问不是故意把SQL变难。

而是在训练学生意识到：

企业数据很少像课程Dataset一样干净。

真正面到Scotiabank时，SQL后面还有一个更重要的问题

这名学生进入Scotiabank Global Banking and Markets的数据分析招聘流程后，最终经历了初筛、Technical Interview和Team Interview等环节。

历史服务记录中，有一个环节非常能说明加拿大银行Analytics岗位到底在看什么。

Technical过程中，学生需要使用SQL和Python分析一个银行客户数据场景。

如果准备只停在：

“SQL写出来了。”

其实还没有结束。

真正重要的是，他还需要根据分析结果继续给出Business Recommendation。

这也是整个案例前后最大的变化。

刚开始时，他很容易把70%的时间用来解释技术：

用了什么Model。

为什么这个算法表现好。

代码怎么写。

Metric是多少。

到后期，他开始习惯在技术回答之后主动增加另一层：

这个结果对Business意味着什么？

比如一个客户群体的Churn Risk明显升高。

不能只回答：

“Model显示这一组客户的流失概率是0.72。”

还需要继续：

哪些Feature可能驱动这个结果？

是不是某个Product的问题？

是否集中在特定Customer Segment？

应该先验证哪些假设？

如果做Retention Campaign，优先针对谁？

怎么判断Campaign真正有效？

这个时候，SQL、Statistics、Metrics和Business Recommendation才开始连成一条线。

Metrics也不是“知道几个名词”就够了

Analytics岗位还有一个特别容易被Data Science学生低估的部分：

Metric。

学校训练Machine Learning时，Metric可能是Accuracy、AUC、Precision、Recall、F1。

但企业里一旦进入Business Problem，Metric的范围马上扩大。

比如银行想提升信用卡客户活跃度。

到底看什么？

Monthly Active Customer？

Transaction Frequency？

Average Spend？

Product Penetration？

Retention？

Revenue？

如果活动上线以后Transaction增加了，但每笔金额明显下降，这算成功还是失败？

如果收入上升，但Customer Complaint也明显增加，应该怎么看？

这已经不是一道统计公式题。

而是在定义：

什么才叫“业务变好了”。

所以蒸汽教育在后面的训练里，会把学生从“看到题就找Model”这个习惯往后拉一步。

先问：

Business Goal是什么？

Primary Metric是什么？

Secondary Metric是什么？

有没有Guardrail Metric？

数据从哪里拿？

如何判断变化真的来自策略，而不是Seasonality或者其他因素？

如果需要Experiment，再讨论A/B Test。

如果不适合做Experiment，再考虑其他分析方法。

这个顺序和学校里的机器学习作业差别非常大。

学校可能先告诉你：

“Build a predictive model.”

工作里更常见的问题可能只有一句：

“最近这个业务指标为什么掉了？”

至于需不需要Machine Learning，要等分析以后才知道。

Data Quality看起来基础，却可能决定整个Recommendation靠不靠谱

学生后期还有一个变化，就是开始认真对待Data Quality。

这类问题在学校项目里存在感往往没有Model Selection强。

但到了银行、保险、零售等大型企业，它非常现实。

例如Dashboard显示某个地区的Customer Acquisition突然上涨30%。

一个刚开始做Analytics的学生可能马上进入Business Interpretation：

是不是Marketing Campaign成功了？

是不是新Product推动增长？

但更成熟的第一反应往往是：

数据是真的吗？

Tracking有没有改？

定义有没有变？

新系统上线以后有没有重复记录？

某个Region是不是晚传了一批数据？

Customer ID是否出现Deduplication问题？

数据日期是否完整？

这也是为什么加拿大银行当前Data Analyst JD里，Data Validation、Reconciliation、Data Integrity、Data Quality和Governance会反复出现。

它们听起来没有Machine Learning“高级”。

但企业必须先相信数据，才会相信结论。

而这类能力往往也是学生从课程环境进入真实Analytics工作时，最需要补的一层。

后来真正被补强的，不是SQL，而是岗位判断

如果只看最后结果，很容易把这个案例总结成：

“学生SQL练好了，所以拿到了Scotiabank Offer。”

其实并不准确。

这名学生本来就有Python、SQL和R基础。

蒸汽教育真正做的，是重新调整了他使用这些技能的方式。

首先是岗位定位。

不再把Data Scientist、Data Analyst、BI和Analytics全部当成“数据岗”，而是根据具体JD判断每一个职位到底偏Modeling、Reporting、Business Analytics还是Data Engineering。

接着是简历。

原本比较学术化的预测项目，被重新拆成Business Problem、Analysis和Recommendation能够连起来的经历。没有做过的商业结果不会为了简历好看凭空补充，但真实项目为什么有业务价值，需要提前想清楚。

第三是行业场景。

导师帮助学生理解银行里的Customer Segmentation、Risk、Market Analysis以及Analytics的使用方式，而不是只熟悉学校Dataset。

第四是面试。

SQL和Python继续练，但同时加入Product Metrics、Data Quality、Business Case以及如何向非技术背景的人解释分析结论。

最后才是正式申请和Networking。

通过Queen's校友网络和目标团队员工交流，学生逐渐了解真实岗位需要什么，再结合申请推进到Scotiabank面试。

最终获得Scotiabank Global Banking and Markets Analytics & Insights团队秋季实习Offer。

这个结果并不证明：

“学Machine Learning没有用。”

恰恰相反，学生的统计和建模基础一直是优势。

真正的问题是：

不能因为自己的硕士叫Data Science或者Business Analytics，就默认招聘方一定最关心Machine Learning。

加拿大数据岗，到底应该怎么区分准备方向

如果一个加拿大Data Science硕士现在同时看到四个岗位：

Data Scientist。

Data Analyst。

BI Analyst。

Analytics Analyst。

最不应该做的，就是用同一份Resume、同一套面试题全部申请。

可以先看JD里的动词。

如果大量出现：

Build Model、Train、Machine Learning、Prediction、Optimization、Deployment、LLM。

这个岗位更可能偏Data Science或者ML。

如果大量出现：

Query、Analyze、Report、Dashboard、Insights、Recommendation、Data Quality。

通常更偏Data Analyst。

如果核心是：

Dashboard、Data Model、Reporting、Power BI、Tableau、Business Requirement。

可能更接近BI。

如果反复出现：

Metrics、Experiment、Customer Behavior、Performance、Strategy。

就需要重点准备Analytics和Product Sense。

当然，企业Title永远不会百分之百标准化。

有些Data Scientist每天大量写SQL。

有些Data Analyst也会做Predictive Model。

有些BI岗位实际上需要很强的数据工程能力。

所以最后还是要回到一句话：

不要根据Title猜工作，要根据JD准备面试。

这也是这个Scotiabank案例对加拿大Data Science、Statistics和Business Analytics学生最有参考价值的地方。

如果面试官一直问SQL，不一定代表你Machine Learning白学了。

更可能是在提醒你：

你申请的这份工作，本来就不是一道Machine Learning考试。

企业真正想知道的是：

能不能找到正确的数据。

能不能判断数据是否可靠。

能不能选择合适的Metric。

能不能完成Analysis。

能不能解释结果。

最后能不能告诉Business：

接下来应该做什么。

当这条链路真正建立起来以后，Machine Learning才会从“我硕士学过的一门核心技能”，变成数据工作中真正应该出现时才使用的一种工具。

信息核验日期：2026年9月4日。文中女王大学Smith School of Business商业分析硕士、统计学本科背景、加拿大银行数据岗求职、蒸汽教育（Stem Career Group）的行业场景训练、简历与项目梳理、商业沟通、Networking及Scotiabank Global Banking and Markets Analytics & Insights历史Offer结果，依据蒸汽教育真实服务经验与案例记录整理；当前Data Scientist与Data Analyst在SQL、Python、Machine Learning、Data Quality、Reporting、Dashboard、Data Pipeline及Business Recommendation等能力上的差异，结合Scotiabank等加拿大企业公开招聘信息重新核验。为保护学生隐私并降低第三方面经、题库及文章内容的版权风险，文中的SQL、Metrics、Data Quality、Experiment和Business Recommendation问题及面试场景，均基于蒸汽教育长期数据岗辅导经验进行匿名化整理与化用，不直接复制第三方受版权保护的面经、题库或文章，也不代表Scotiabank、RBC、TD或其他企业的固定题目、内部题库或当期必考内容。不同团队即使使用相同职位名称，实际职责和面试重点也可能不同，具体以申请当期JD和候选人实际收到的招聘通知为准。