前言

讲道理现在AI面试都搞出来了，实在是震惊了。现在处于找工作的环节中，不免好奇，于是体验了一下牛客的AI面试（头条-数据分析岗）。说说我的感受：

• ai界面模拟了正常公司面试的组成结构，有面试官（假的）和自己的视频区，主要的界面还是做题区，代入感很强，建议没什么面试经验的人可以尝试一下，感受下那个氛围
• 题目类型有两种，一种是综合能力题，比如自我介绍，做了什么项目，里面发挥了那些作用，聊聊自己做过的一件工作，AI只分析语序流畅程度，不对内容做点评（没法点评），这种题目就没有打分
• 第二类是问答题，有明确答案，暂时遇到的都比较简单，如数据库三范式、ACID的特性。很惭愧过了4年，当时对答如流的问题现在都磕磕绊绊，话都说不清楚

现在积累的计划有三部分：

1. 第一部分可以统称为自我介绍部分（工作经历，学习心得这种），要结合日常工作，做每日复盘，做针对性口述能力的强化，把频率最高的几个问题准备好，其他的就有余地自由发挥。
2. 第二是做题+系统性知识补充。光会做题，会问答知识点的问题，会写sql不行，还得懂原理，知识点扩展，有工作经验延伸，有问题储备，能解决问题，有优化方向，提升工作效率的想法和方案，毕竟社招了，不像应届生一样要求那么低了（工作四年几乎没用长进，难受）。
3. 第三部分就是加深对岗位和职业发展规划的了解，比如对岗位的负责内容、行业的特性、工作要掌握的一些基本技术技能和综合能力，有了解就有方向学习。然后是职业规划， 不仅仅是为了应付面试官，如果自己没有奋斗的方向，没有奋斗的目标，没法在这个大家都夺命狂奔的路上追赶超越。

模拟面试题汇总

项目介绍

自己具体的内容肯定是没法分享的，涉及到一些个人隐私的事情，后续找找是否有公开的资料一起学习

数据库ACID的特性

ACID的前提是事务工作模式，在这种模式下：

1. 原子性是指事务是一个不可分割的工作单位，事务中的操作要么都发生，要么都不发生。
2. 一致性指事务前后数据的完整性必须保持一致。
3. 隔离性指多个用户并发访问数据库时，一个用户的事务不能被其他用户的事务所干扰，多个并发事务之间数据要相互隔离。
4. 持久性是指一个事务一旦提交，它对数据库中数据的改变就是永久性的，即便数据库发生故障也不应该对其有任何影响。

事务的出现，主要是为了解决数据库操作中，因为程序出错或者其他原因导致的整作业没法完整执行的时候的处理方案。就比如现在你要去ATM存钱，
中间会经历插卡、读卡、识别卡信息、输入密码、成功则开始放钱、数完了钱封存起来、写入账号增加现金余额、退卡。其他步骤还好说，一旦机器获取了你的现金，在数钱时卡住，要怎么办？如果是用户体验至上的方案，会这么处理：

1. 判断卡住的原因：假钞、破损的纸钞、机器某环节出错、是否有异物卡住
2. 针对上面的问题，为真就全处理一遍，把能验通过的钱全部验一遍
3. 实在验不了的，再退还用户，再次放入

看上去看简单对不对，但是步骤二非常难实现，考虑到实际卡住的情况非常多，如果没法穷举所有的卡住原因，就没法妥善的解决步骤二，全国这么多人这么高频次（微信支付宝出现以前还是很频繁的）的使用，考虑不周出了bug直接给你整个系统下线都有可能。因此这时候最简单也是最偷懒的方案就是，一旦数不下去了，直接原路退回，一张都不数，这就是事务的原子性，数钱中间环节出了问题，整个回滚，不数了，结果只有成功和失败。一致性就是指事务前后的数据保持一致，即用户塞了1w，机器肯定只能是1w，不能多不能少，数完以后加到用户账户里的也是1w，数据流向的环节都是保证一致性的。隔离性也很好理解，事务执行期间，是封闭式操作的，不会被别的事务打扰，机器数钱的时候你是没法执行查询余额，取钱这些其他事务的操作的（因为会动到同一个账户余额）。持久性就是结果的确定性，一旦确定将钱存入账户，就无法回滚，就是事务的不可逆性。

数据库三范式的理解

标准答案：https://segmentfault.com/a/1190000013695030
既然已经有标准答案，我就自己再总结下，输出以后脑子比较容易记得住：
三范式是一种数据库设计标准，第一是列的属性原子化，无法再分割（不能分割则表示数据的冗余度为0，但是系统的复杂度也会上升，仿佛现代工厂的流水线设计，每一个步骤都由一个精密设备来实现，研发难度下降，可以将一个环节的效率提升到极致，但是整个流水线的装配和运行就非常复杂，反过来也是一样，提高设计冗余度就是采用多面手的机器，整体操作的体验和复杂度会下降，但是对机器的要求较高，并且前一发动全身，核心部件要更换的话所有的功能都会停摆）
第二范式是在第一范式的基础上，保证其他列式完全依赖主键的，如果不是这种强绑定关系，就会出现列属性依赖的情况，也就是第三范式不允许的情况，如果列的数据是原子化的，但是属性之间相互关联，更新一个列的属性数据必须要将其他列的数据也一起变掉才行，系统的复杂度和不稳定性都会上升（因为列属性相互依赖是内在逻辑，在使用数据或者ETL的过程中需要人为的主动去完善这一个过程，一旦依赖关系过多谁能保证没有纰漏呢？）但是实际情况不太一样，相比于减少列属性的相互依赖，如果满足范式需要拆分的数据非常多（想想是维护几十个满足范式的事实表和关系表简单，还是维护几张违反范式的宽表简单），反而不如降低范式标准，建立宽表数据，将数据依赖集中在某些常用的数据场景下，反而更容易的开展工作。

因此，实际工作情况中，一定会有违反3范式的情况，提高冗余度，降低系统设计复杂性，鲁棒性和可维护性才能提升