共计 2531 个字符，预计需要花费 7 分钟才能阅读完成。
经过半年的沉淀，加上对 MySQL，redis 和分布式这块的补齐，终于开始重拾信心去投了两家之前心水已久的公司。
鹅厂
面试职位：go 后端开发工程师，接受从 Java 转语言
都知道鹅厂是 cpp 的主战场，而以 cpp 为背景的工程师大都对 os，network 这块要求特别高，不像是 Java 这种偏重业务层的语言，之前面试 Java 的公司侧重还是在数据结构、网络、框架、数据库和分布式。所以 OS 这块吃的亏比较大
一面基础技术面
电话面试，随便问了些技术问题，最后还问了个 LeetCode 里面 medium 级别的算法题，偏简单
redis 有没有用过，常用的数据结构以及在业务中使用的场景，redis 的 hash 怎么实现的，rehash 过程讲一下和 JavaHashMap 的 rehash 有什么区别？redis cluster 有没有了解过，怎么做到高可用的？redis 的持久化机制，为啥不能用 redis 做专门的持久化数据库存储？
了不了解 tcp/udp，说下两者的定义，tcp 为什么要三次握手和四次挥手？tcp 怎么保证有序传输的，讲下 tcp 的快速重传和拥塞机制，知不知道 time_wait 状态，这个状态出现在什么地方，有什么用？（参考 quic）
知道 udp 是不可靠的传输，如果你来设计一个基于 udp 差不多可靠的算法，怎么设计？
看你项目里面用了 etcd，讲解下 etcd 干什么用的，怎么保证高可用和一致性？
既然你提到了 raft 算法，讲下 raft 算法的基本流程？raft 算法里面如果出现脑裂怎么处理？有没有了解过 paxos 和 zookeeper 的 zab 算法，他们之前有啥区别？
你们后端用什么数据库做持久化的？有没有用到分库分表，怎么做的？
索引的常见实现方式有哪些，有哪些区别?MySQL 的存储引擎有哪些，有哪些区别？InnoDB 使用的是什么方式实现索引，怎么实现的？说下聚簇索引和非聚簇索引的区别?
有没有了解过协程？说下协程和线程的区别？
算法题一个，剑指 offer 第 51 题，数组中的重复数字？
自己的回答情况，redis 这块没啥问题，具体 rehash 有印象是渐进式的，但是具体原理可能答的有点出入。tcp 的 time_wait 这块答的不是很好，之前没有了解过 quic 机制的实现，所以问可靠性 udp 的时候，基本上脑子里就照着 tcp 的实现在说。raft 算法这个因为刚好在刷 6.824（才刷到 lab2。。。），答的也凑合，不过 paxos 确实不熟悉，直接说不会。MySQL 这块很熟了，没啥说的，协程和线程，主要说了 go 程和 Java 线程的区别以及 go 程的调度模型。面试官提示没有提到线程的有内核态的切换，go 程只在用户态调度。最后一个算法题，首先说使用 HashMap 来做，说空间复杂度能不能降到 O(1)，后面想了大概 5min 才想出来原地置换的思路。
二面项目技术面
主要针对自己最熟悉的项目，画出项目的架构图，主要的数据表结构，项目中使用到的技术点，项目的总峰值 qps，时延，以及有没有分析过时延出现的耗时分别出现在什么地方，项目有啥改进的地方没有？
如果请求出现问题没有响应，如何定位问题，说下思路？
tcp 粘包问题怎么处理？
问了下缓存更新的模式，以及会出现的问题和应对思路？
除了公司项目之外，业务有没有研究过知名项目或做出过贡献？
基本都没有啥问题，除了面试官说项目经验稍弱之外，其余还不错。
三面综合技术面
这面面的是阵脚大乱，面试官采用刨根问底的方式提问，终究是面试经验不够，导致面试的节奏有点乱。举个例子：
其中有个题是 go 程和线程有什么区别？答：1 起一个 go 程大概只需要 4kb 的内存，起一个 Java 线程需要 1.5MB 的内存；go 程的调度在用户态非常轻量，Java 线程的切换成本比较高。接着问为啥成本比较高？因为 Java 线程的调度需要在用户态和内核态切换所以成本高？为啥在用户态和内核态之间切换调度成本比较高？简单说了下内核态和用户态的定义。接着问，还是没有明白为啥成本高？心里瞬间崩溃，没完没了了呀，OS 这块依旧是痛呀，支支吾吾半天放弃了。
后面等等的面试都是这种情况，结果就是回答的节奏全无，差不多都是上面这种形式，基本都能达到一点，但是深入的 OS 层面就 GG 了。
后面问了下项目过程中遇到的最大的挑战，以及时怎么解决的？
后面还问了一个问题定位的问题，服务器 CPU 100% 怎么定位？可能是由于平时定位业务问题的思维定势，加之处于蒙蔽状态，随口就是：先查看监控面板看有无突发流量异常，接着查看业务日志是否有异常，针对针对 100% 那个时间段，取一个典型业务流程的日志查看。最后才提到使用 top 命令来监控看是哪个进程占用到 100%。果然阵脚大乱，张口就来，捂脸。。。本来正确的思路应该是先用 top 定位出问题的进程，再用 top 定位到出问题的线程，再打印线程堆栈查看运行情况，这个流程换平时肯定能答出来，但是，但是没有但是。还是得好好总结。
最后问了一个系统设计题目（朋友圈的设计），白板上面画出系统的架构图，主要的表结构和讲解主要的业务流程，如果用户变多流量变大，架构将怎么扩展，怎样应对？这个答的也有点乱，直接上来自顾自的用了一个通用的架构，感觉毫无亮点。后面反思应该先定位业务的特点，这个业务明显是读多写少，然后和面试官沟通一期刚开始的方案的用户量，性能要求，单机目标 qps 是什么等，？在明确系统的特点和约束之后再来设计，而不是一开始就是用典型互联网的那种通用架构自己搞自己的。
总结
tcp/udp 还有网络这块（各种网络模型，已经 select，poll 和 epoll）这块一定要非常熟悉
一定要有拿的出手的项目经验，而且要能够讲清楚，讲清楚项目中取舍，设计模型和数据表
分布式要非常熟悉
常见问题定位一定要有思路
操作系统，还是操作系统，重要的事情说三遍
系统设计，思路，思路，思路，一定要思路清晰，一定要总结下系统设计的流程
一点很重要的心得，平时 blog 和专栏看的再多，如果没有自己的思考不过是过眼云烟，根本不会成为自己的东西，就像内核态和用户态，平常也看过，但是没细想，突然要自己说，还真说不出来，这就很尴尬了。勿以浮沙筑高台，基础这种东西还是需要时间去慢慢打牢，去思考去总结。
系统设计相关资料:
系统设计入门
系统设计典型问题的思考
东南亚互联网公司
TODO