你见过最差的算法工程师能差到什么程度？

做算法不等于写代码。

Hold out: 在训练前，把数据集根据一定比例分成training和test，模型通过training来训练，test来评估。训练的时候常常继续把training分成training和validation，使用validation的反馈来帮助调整参数。严格来说，并不完全可以算作cross validation。k-fold cross validation（k折交叉验证）: 数据量不够大时，或者想追求更精确的训练结果时，可以将数据集均匀分成k份，每次用其中的一份数据集作为test，其它的k-1份作为training，学习k次，最后得到k个模型，用k个模型预测的平均值作为结果。leave-p-out cross validation（留p交叉验证）: 遍历数据集中所有可能的p个数据的组合，分别做测试集，每次使用剩下的数据作为训练集。不是特别常用，因为复杂度太高，得到的模型个数是阶乘级别。

leave-one-out cross validation（留1交叉验证）: 每次只使用一份数据，而不是一份数据集来作为测试集。等于p为1的留p验证，也等于k为数据集大小的k折验证。Iterated K-fold validation with shuffling: 每次都进行数据随机排列，然后进行完整的k-fold。适用于数据量小的情况。嵌套k-fold，不怎么常见，但是可以了解一下。在工业级别的项目上，目前我还没使用过这个。

注：*是一个非常常用的python库

注：*取值小于5，X取值大于3，XX取值两位数

基础非常扎实。问他/她一些比较经典的算法，能够很清晰地说出算法的特点、适用的场景、坑点、里面的细节等等。工程能力很强。我是一位“工程狗”，自己的工程能力很菜，但对工程能力强的同学非常崇拜 Orz 如果碰到一位算法工程师的工程能力很强，仅凭这一点，我就认为他/她基本上一定是大佬Orz重视代码的测试。算法岗的工作并不完全就是调参炼丹，往往也是需要去写一些代码的，例如写些spark/sql代码获得特征，写模型等等。既然是写代码，就可以而且应该在其中加上测试。实际上，根据我的经验，如果碰到某个其他地方好用的模型在自己的场景下效果很差（不reasonable得差），那很可能是数据、特征的处理代码有问题，或者模型的代码有问题。这种问题可以用单元测试（断言等）来提前发现，也可以用一些sanity check来发现。对场景业务的认识很深刻。软件工程没有银弹，机器学习也没有银弹。用什么样的特征、什么样的预估目标、什么样的评价指标、甚至什么样的模型，这些东西都是要与场景业务结合的。换言之，工业届里，业务先于技术。很多大神在这个方面做得尤其出色。在实际场景中，注重先把整个pipeline搭建起来。个人认为，这一点在实际应用中往往应该是最优先的。搭建起来之后，机器学习系统的上下游也都可以工作，也可以更好地判断系统的瓶颈所在，把好刚用在刀刃上。这其实就与做开发的程序设计一样，较早地抽象出比较好的接口、搭建一个系统原型是很重要的。能够持续学习新的知识，跟踪最新的成果，对各种模型的motivation有自己的理解，有自己的insight与vision。这里举几个我自己学习过程中碰到的例子来说明一下这点。例如，推荐系统中，在Youtube 16年的推荐paper中，为何step1和step2的优化目标是不一样的？人脸检测中，MTCNN为何要分为多阶段？landmark检测中，3000FPS为何要分为两个阶段？（这些是设计相关的motivation）Google的wide&deep为何在Google store的场景下效果好，而在其他的场景下效果不一定好（这是对场景的motivation理解）？文字检测中，PixelLink为何要引入link？OCR中，CRNN为何要引入一个RNN？机器学习系统中，LightGBM是如何针对xgboost存在的哪些缺点进行改进的？（这些是对改进的motivation理解）我认识的一些大佬们会主动结合文章思考这些问题，有的时候会有与paper所claim的不同的理解（毕竟写paper的story很多时候也不一定靠谱，大家都懂），甚至还会做实验验证自己的理解。然后拿这些问题来考我，在我思考不出来后再告诉我他们的理解与实验结果Orz做多数实验之前有自己的假设，根据实验结果会根据实验结果做进一步实验，或修正假设、或进一步探究。自己参与的项目，对其中与自己比较相关的内容的细节比较清楚，自己负责的部分能够了如指掌。能系统性地分析出机器学习整个系统的瓶颈所在，并提出相应的解决方案。当系统效果不好的时候，知道如何去debug，找到问题所在，改进系统的性能。这方面是我个人尤其欠缺的点。