标签:接受 数据库 研究 运行 提问 基础 off 不可 级别
经过半年的沉淀,加上对MySQL,redis和分布式这块的补齐,终于开始重拾面试信心,再次出征。
面试职位: go后端开发工程师,接受从Java转语言
都知道鹅厂是cpp的主战场,而以cpp为背景的工程师大都对os,network这块要求特别高,不像是Java这种偏重业务层的语言.
之前面试Java的公司侧重还是在数据结构、网络、框架、数据库和分布式。所以OS这块吃的亏比较大
电话面试,随便问了些技术问题,最后还问了个LeetCode里面medium级别的算法题,偏简单。大概整理回忆了一下:
大概说下我自己的回答情况,redis这块没啥问题,具体rehash有印象是渐进式的,但是具体原理可能答的有点出入。
tcp的 time_wait 这块答的不是很好,之前没有了解过quic机制的实现,所以问可靠性udp的时候,基本上脑子里就照着tcp的实现在说。
https这块没啥说的,之前项目里面有用到类似的东西,研究的比较清楚了。
raft算法这个因为刚好在刷6.824(才刷到lab2。。。),答的也凑合,不过paxos和zab算法确实不熟悉,直接说不会。
MySQL这块很熟了,包括索引,锁,事务机制以及mvcc等等,没啥说的,都已经补齐了。
协程和线程,主要说了go程和Java线程的区别以及go程的调度模型。面试官提示没有提到线程的有内核态的切换,go程只在用户态调度。
最后一个算法题,首先说使用HashMap来做,说空间复杂度能不能降到O(1),后面想了大概5min才想出来原地置换的思路。
总得来说,答的还行,一面就这么过了。
二面从基础技术考察转移到了项目,主要问了我下面一些问题:
这一面答的也比较顺利,因为都是围绕项目,自己很熟悉,基本都没有啥问题,除了面试官说项目经验稍弱之外,其余还不错。
这面面的是阵脚大乱,面试官采用刨根问底的方式提问,终究是面试经验不够,导致面试的节奏有点乱。 举个例子:
其中有个题: go程和线程有什么区别?
答 :起一个go程大概只需要4kb的内存,起一个Java线程需要1.5MB的内存;go程的调度在用户态非常轻量,Java线程的切换成本比较高。
接着问为啥成本比较高?因为Java线程的调度需要在用户态和内核态切换所以成本高?为啥在用户态和内核态之间切换调度成本比较高?我简单说了下内核态和用户态的定义。
接着问,还是没有明白为啥成本高?心里瞬间崩溃,没完没了了呀,OS这块依旧是痛呀,支支吾吾半天放弃了。
后面所有的提问都是这种模式,结果回答的节奏全无,感觉被套路了。大多度都能回答个一二甚至是一二三,但是再往后或者再深入的OS层面就GG了。
后面问了下项目过程中遇到的最大的挑战,以及怎么解决的?
还问了一个问题定位的问题,服务器CPU 100%怎么定位?
可能是由于平时定位业务问题的思维定势,加之处于蒙蔽状态,随口就是:
果然阵脚大乱,张口就来,捂脸。。。
对这个问题,本来正确的思路应该是先用 top 定位出问题的进程,再用 top 定位到出问题的线程,再打印线程堆栈查看运行情况
这个流程换平时肯定能答出来,但是,但是没有但是。还是得好好总结。
最后问了一个系统设计题目(朋友圈的设计),白板上面画出系统的架构图,主要的表结构和讲解主要的业务流程,如果用户变多流量变大,架构将怎么扩展,怎样应对?
这个答的也有点乱,直接上来自顾自的用了一个通用的架构,感觉毫无亮点。
后面反思应该先定位业务的特点,这个业务明显是 读多写少。 然后和面试官沟通一期刚开始的方案的用户量,性能要求,单机目标qps是什么等等?
在明确系统的特点和约束之后再来设计,而不是一开始就是用典型互联网的那种通用架构自顾自己搞自己的方案。
面试结果:3天后收到短信,被拒
标签:接受 数据库 研究 运行 提问 基础 off 不可 级别
原文地址:https://www.cnblogs.com/Java-no-1/p/11070624.html