数据库面试的几个常见误区
由于业务的需要，最近面试了很多数据库候选人。发现很多候选人在面试准备时会有一些普遍的误区，借此机会展开聊聊我作为面试官的一些建议。这次主要讲四个误区：代码基础差、工程素养弱、沟通思维无、知识框架碎。
作者：木鸟杂记 https://www.qtmuniao.com/2023/08/21/database-interview-myth 转载请注明出处
误区一：代码基础差
数据库是一个工程性极强的领域，因此代码是面试考察中非常重要的一个环节，可以说代码写得好，即使背景稍弱，也可能会通过面试；但反之则不然，遇到过一些候选人，分布式事务的一些细节可以说的头头是道，但却连链表等基础数据结构都写不太明白，这个情况就是想给过也有心无力。
说到代码，我们并不期望候选人要能做出多么难的算法题。反而，会更针对偏基础、偏工程的方向考察。
- 基础数据结构。基础数据结构包括链表、哈希表、树等常见的数据结构和相关算法，最好都能快速地自己实现，并了解每种数据结构的特点。图偶尔会考察，但比较少，而且考察点很固定，通常就是最基本的遍历（BFS、DFS）、最短路、最小生成树和拓扑排序等三四个固定的算法。
- 常见算法。最基本的就是几种常见的排序算法，弄清楚其时间复杂度和空间复杂度以及基本的优缺点。另外一个初学者比较难理解的就是基于树的回溯算法，这个本质上是对递归思想了解的不透彻。当然，我当年也是花了很久才理解这种思想，但一般不会考很难的回溯。另外就是二分算法和分治算法，其核心思想是拆解问题域，去解决子问题：二分就是不断缩小问题规模，分治则是在缩小规模的基础上，还要将子问题的解进行组合，进而求解原问题。动态规划算法会比较难，通常不会考，即使考也只会考非常简单的，比如最基础版本的 01 背包问题。
- 工程题目。我之前去面试其他公司，偏工程题目被考到最多的就是 LRU，因为他结合了哈希表、链表等多个数据结构，Corner case 也比较多，是很看代码功底的题，但是后来背的人多了，区分度也就不太高了。另外就是前缀树，也就是 Trie 树，这个相对少一些，代码写起来也会细节很多。我自己多会问一些基础数据结构的实现，比如实现一个哈希表，这个题可以有很多 follow up，比如扩缩容、线程安全等等；此外一些涉及文件读写、字节操作、多线程的题目偶尔也会问，由于这些 API 通常都很难记，这时候我通常让候选人可以随便查阅互联网，只需要让我看着就行。其实看候选人如何解决问题、如何搜索的过程本身也是一种考察。
误区二：工程素养弱
现代的数据库代码，动辄数十万行，如果没有良好的代码规范，会在项目演进过程中很快变得不可维护。因此如果候选人在写代码时能够比较注意代码风格、体现出工程素养，会非常加分；反之如果胡乱命名、没有基本的抽象和复用，则会很减分。
另一个很能够体现工程素养的点是：解决实际问题的思路。比如当面试官考察一些工程代码时，题目可能比较模糊、宏大。这时候候选人如果能：
- 用一些计算机常识，将模糊地带进行确定化。比如题目不要求基于内存还是文件，我们都先假设都在内存中，然后跟面试官说下利用 WAL 和 SnapShot 等方法应对宕机即可。
- 做一些简单假设，将问题域进行收束。比如数据类型不确定时，我们可以假设是最简单的整形；又如文件数据格式不确定时，我们可以假设一行一个数据。
- 抽象出基本模块，先走通宏观思路。也就是做项目时常用的最小可用原型思想，将每个子问题（比如读写文件、排序等）模块化，使用最简单实现、甚至暂时留白，从而专注主干逻辑搭建，迅速实现一个可用的原型，尔后再跟面试官讨论，对需要的模块进行优化。
其中，最后一点非常重要，因为面试时间通常都很有限，如果你很快陷入某一块的工程细节中，比如如何读写文件、如何取舍 buffer 大小、如何处理 offset ，轻则时间到了还写不完、重则由于紧张陷进去根本出不来。这时候一定要注意使用最小可用模型、自顶向下逐步求精等思想，因为这也是我们在实际工作中完成任务常见的思想，是非常能够体现工程素养的一个侧面。
本篇文章出自我的持续更新的数据库、分布式系统专栏：《系统日知录》，还剩下两小段，欢迎前往专栏查看。
