经过半年的沉淀,加上对MySQL,redis和分布式这块的补齐,终于开始重拾信心去投了两家之前心水已久的公司。
面试职位:go后端开发工程师,接受从Java转语言
都知道鹅厂是cpp的主战场,而以cpp为背景的工程师大都对os,network这块要求特别高,不像是Java这种偏重业务层的语言,之前面试Java的公司侧重还是在数据结构、网络、框架、数据库和分布式。所以OS这块吃的亏比较大
电话面试,随便问了些技术问题,最后还问了个LeetCode里面medium级别的算法题,偏简单
自己的回答情况,redis这块没啥问题,具体rehash有印象是渐进式的,但是具体原理可能答的有点出入。tcp的time_wait这块答的不是很好,之前没有了解过quic机制的实现,所以问可靠性udp的时候,基本上脑子里就照着tcp的实现在说。raft算法这个因为刚好在刷6.824(才刷到lab2。。。),答的也凑合,不过paxos确实不熟悉,直接说不会。MySQL这块很熟了,没啥说的,协程和线程,主要说了go程和Java线程的区别以及go程的调度模型。面试官提示没有提到线程的有内核态的切换,go程只在用户态调度。最后一个算法题,首先说使用HashMap来做,说空间复杂度能不能降到O(1),后面想了大概5min才想出来原地置换的思路。
基本都没有啥问题,除了面试官说项目经验稍弱之外,其余还不错。
这面面的是阵脚大乱,面试官采用刨根问底的方式提问,终究是面试经验不够,导致面试的节奏有点乱。 举个例子:
其中有个题是go程和线程有什么区别?
后面等等的面试都是这种情况,结果就是回答的节奏全无,差不多都是上面这种形式,基本都能达到一点,但是深入的OS层面就GG了。
后面问了下项目过程中遇到的最大的挑战,以及时怎么解决的?
后面还问了一个问题定位的问题,服务器CPU 100%怎么定位?可能是由于平时定位业务问题的思维定势,加之处于蒙蔽状态,随口就是:先查看监控面板看有无突发流量异常,接着查看业务日志是否有异常,针对针对100%那个时间段,取一个典型业务流程的日志查看。最后才提到使用 top
命令来监控看是哪个进程占用到100%。果然阵脚大乱,张口就来,捂脸。。。
本来正确的思路应该是先用 top
定位出问题的进程,再用 top
定位到出问题的线程,再打印线程堆栈查看运行情况,这个流程换平时肯定能答出来,但是,但是没有但是。还是得好好总结。
最后问了一个系统设计题目(朋友圈的设计),设计系统的架构图,主要的表结构和讲解主要的业务流程,如果流量变大,架构将怎么扩展,怎样应对。
这个答的也有点乱,直接上来自顾自的用了一个通用的架构,感觉毫无亮点。后面反思应该先定位业务的特点,这个业务明显是读多写少,然后和面试官沟通一期刚开始的方案的用户量,性能要求,单机目标qps是什么等,?在明确系统的特点和约束之后再来设计,而不是一开始就是用典型互联网的那种通用架构自己搞自己的。
TODO