前言
本文我们通过一篇真实的一线面经,带大家去体验一下 BAT 等互联网公司的面试现场氛围!面试者是笔者以前的下属,多年的好朋友。这是他去年早些时候出去面试,拿到 BAT 等多家一线互联网公司技术专家 Offer 的面试经历。
先介绍一下这位朋友的个人经历:
本科毕业,接近 10 年工作经验。跳槽之前,在国内某大型互联网公司里带一个 8 人左右的技术团队。
由于公司业务发展较为平缓,所以职业上升机会较少。
朋友对其负责的系统架构和技术已经非常熟悉,薪资上也较难有大幅度的增长,至于晋升更高的级别,短期内也不容易。
因此,在仔细思考一番之后,决定出来看看机会,能否在带团队的规模、技术以及薪资上实现一个突破。
一面
一面是一个猎头给朋友推的一个职位,BAT 中某一个大厂的某个团队,具体就不说是哪个部门了。
一面就直接过去当面聊了一次,大概从下午 2 点聊到了下午 4 点多,时间很长,炮火相当猛烈。
一面面试官也是专家职级,上来就是先聊项目,针对项目中的各种细节仔细问,就项目展开,而且极其注重细节。
下面的内容,是根据朋友面试之后的回忆,整理出的部分问题:
![img_4cb5369ca69d869c744e58ce8849bbf7.jpe](https://yqfile.alicdn.com/img_4cb5369ca69d869c744e58ce8849bbf7.jpeg?x-oss-process=image/resize,w_1400/format,webp)
面试同样是通过互联网公司最喜欢的连环炮形式发问。比如在面试过程中,聊到了缓存,连环炮如下。接着,面试官继续深扣了很多细节。
面试官:
那请说一下,这些请求具体是落在哪些接口上?
哪些数据是数据库和缓存双写一份的?
双写一致性如何保证?保证一致性的同时如何保证高并发和性能?
缓存线上是如何部署的?给了多大的总内存?命中率有多高?
缓存抗了多少 QPS?数据流回源会有多少 QPS?
是否某个 key 出现了热点缓存导致缓存集群中某个机器的负载过高?如何解决的?
是否出现超大 value 打满网卡的问题?如何规避这个问题?
线上是否出过缓存集群事故?如果出现了你们怎么解决有什么高可用保障预案?
平时如何监控缓存集群的 QPS 和容量?如果要扩容该怎么扩?能否平滑扩容?扩容会导致系统需要停机吗?
聊聊 Redis 的集群原理?扩容的时候会不会导致数据丢失?key 寻址算法都了解哪些?
你了解一致性 hash 算法吗?画个图说说 Redis 线程模型和内存模型?
朋友:纸笔翻飞,大脑高度运转,一个接一个的回答。。。
![img_a3a78b46f701c0d76cd6f93af1981c0f.jpe](https://yqfile.alicdn.com/img_a3a78b46f701c0d76cd6f93af1981c0f.jpeg?x-oss-process=image/resize,w_1400/format,webp)
如上所述,所有问题,全部结合项目,落地到生产中,同时注重聊技术的很多细节,包括技术的一些原理。
像缓存这样的连环炮提问法,面试官还用来问了 MQ、MySQL 分库分表、高可用、JVM、多线程并发,等各种问题。
简单总结:
一面其实关注了技术广度,同时结合项目死扣各种细节。
另外也兼顾了一定的技术深度,会就一个技术往深了问下去。
总体来说,一面还算顺利,毕竟都是结合项目来问的,各种细节平时朋友进行架构设计时,都会仔细考虑过。
而且朋友也做过线上的高并发系统,踩过很多坑,所以这些问题基本都回答的不错。
但是这里给大家提醒一句,一般某个同学出去面试,回来之后其他人问他面试经验,一般都是问:都有啥面试题?面试官是怎么问的?
说实话,大家看了上面那些问题,可能会觉得说,哦,其实我也可以答出来,没什么特别的。
但其实并不是这样,如果只是拿高级岗位的 Offer,你的技术会占很大比重。
但是如果要拿专家岗位的 Offer,你到底有没有线上真实的高负载的系统架构经验,非常重要。
同样的问题,普通人会回答的很普通,但是经历过真实几十亿流量请求的人一定会说出大量经验总结、教训以及踩坑。
而且对整套复杂的大型系统到底是如何抗住高并发的,会了然于胸,熟悉所有的细节。
所以针对一面,一般就是结合项目,深挖细扣,看你到底有多少水平,做过多复杂的系统。
这块说实话,做过就是做过,没做过就是没做过,是不可能作假的。很多同学可能自己平时也看过很多书和博客,但是看书和博客只是基础,如果没有真实的线上生产环境的历练,是肯定不够的。毕竟实践出真知!
二面
一面就顺利通过了,紧接着安排了第二轮面试。二面面试官应该是这个团队的 Leader,P8 级别的,如果进去,应该就是朋友未来的顶头上司。
据朋友讲,二面面试官态度非常好,很和蔼,看来一面面试官反馈之后,这个 Team 对朋友还是比较重视的。
技术深度
二面内容就从广度变成深度了,面试官技术实力很深厚,应该是有十几年经验。对相关技术深挖了很多东西。
同样,二面也聊到了缓存相关的问题。问了朋友具体了解过哪些缓存技术,Redis、Memcached,还有阿里开源的 Tair,哪个了解过内核原理?
朋友之前看过一些 Redis 的内核,就聊了聊 Redis 内核的一些数据结构和实现原理。包括集群、持久化在内核层面的一些东西。
此外在 MQ 这块,朋友正好对 Kafka 做过深入的研究,就聊了聊 Kafka 的源码。
比如 Kafka Controller 在故障转移这块的源码,日志存储、网络通信的一些细节。
如何保证磁盘读写的高性能,零拷贝那块的底层实现,leader 和 follower 之间的数据是如何同步的,都是从源码层面来聊。
此外,还聊了 Dubbo 的源码以及 MySQL 内核层面的东西。
系统设计、工程素养、带团队
同时二面非常重视考察系统设计能力、工程素养、带团队的能力。比如面试官就这个部门负责的一块业务,出了一个相关的系统设计题目。
题目细节记不清楚了,大体内容是给出具体的用户量、业务场景、并发量、数据量,然后让你整体负责这个系统的架构设计。
朋友需要阐述自己的整体设计思路,从哪些点来考虑,存在着哪些技术挑战,并且现场画出来具体的架构设计图。
工程素养这块,让朋友聊了聊平时如何做的技术设计、技术评审、编码规范、测试、上线、回滚、灰度、压测、监控等等。
带团队,让朋友说一下,如何招人、面试标准、如何搭建团队的人才梯度,等等。
架构演进
此外,还会问一下,整个系统架构是如何一步一步进行演进的。从 0 到 1 的时候是什么架构?从 1 到 10 的时候是什么架构?从 10 到 100 的时候是什么架构?这块就是看看你的整体架构能力,以及技术规划能力。
说到这里,笔者提一句,如果出去面试,尤其是去 BAT 等大型互联网公司面试,必须精心准备。
包括你的项目的每个细节,你解决过的各种线上问题和坑,你简历里的技术是否达到一定的深度,你平时其他的工程、设计能力,这些都一定要精心准备一下。
绝对不要裸面!绝对不要裸面!绝对不要裸面!重要的事情说三遍!裸面必败,而且如果一问三不知,那么给人的印象就是很差的。
如果要冲着心仪的大公司去,最起码精心准备 1 个月以上,大家务必记住这一点,这也是朋友这次的一个重要心得,准备充分了,才能有备无患。
三面
二面之后,又等了大概一两周。。。因为越往上面,领导级别越高,平时越忙,有时人家可能出差开会去了,不过等了一两周,那边总算约上了三面。
三面是总监级别的,不太确定是走的 M 线还是 P 线。如果是 P 线,那么一定是 P9,但是观察面试风格应该是 M 线的总监。
这一面,聊技术其实并不多,更多的是跟朋友聊过往的各种公司的经历和项目经验,具体负责过哪些比较有挑战的大型的系统。
另外,考察了各种软素质。比如说责任心、抗压能力、自我驱动,让朋友举例说明自己过去的一些事情,来证明软素质。
同时还会聊聊职业价值观,是否愿意加班,等等吧。最后也聊了聊朋友的职场期望,包括这个团队是干什么的,未来的发展方向之类的。
朋友觉得最重要的还是前面两面,其实这一面,只要人品端正,平时干活儿认真负责,一般的都没什么太大的问题。
终面
接着又过了一两个礼拜,因为当时二面面试官,也就是那个未来可能成为朋友 Leader 的人,对朋友还是比较看重的,私下还短信联系了一段时间,就怕朋友跑去别的公司了。
他告诉朋友说是因为 HR 那边太忙了,所以终面还未安排上。关于 HR 面,朋友印象真是相当之深刻,为什么呢?
因为 HR 是直接电话聊的,没过去了,过去实在太折腾,而且二面面试官也是去打了招呼。
HR 当时居然是晚上 11 点打来的电话,人家刚刚加班开会结束,就打来了电话,真是不得不佩服其敬业精神!
而且这位 HR 是相当专业的,如果是普通的 HR 其实随便聊聊就行了,但是这边的 HR 问了很多问题,大概聊了 1 个小时左右。
主要是跟朋友聊了一些价值观的东西,比如之前觉得做过最难的事情是啥,怎么克服的,当时啥心态。
还有就是为啥要离职,没有发展空间?那当时没考虑过公司内部 transfer(转岗)吗?为啥不好 transfer?你的绩效平时怎么样?你觉得你跟同事相处的怎么样?
终面内容,总结起来,其实还是一句话,你人品正就好了,一般都问题不大,老老实实的踏实回答。
后来 HR 面了过后,那边的薪资确实给到位了,达到了朋友的期望薪资。但是那边给的规划是未来可以带的团队人数也就是 10 人以内,而且不是配发集团股票,是配发的正在快速发展的这个团队的期权。
所以朋友当时纠结了一下,但还是先答应了,于是 Offer 就发了过来。
后记
本来朋友想的是,如果没有别的更好的机会,那么这个机会也可以考虑,毕竟薪资上还是可以的。
但是当时包括 TMD(头条、美团、滴滴)这边,也都有人内推朋友过去试试,所以当时也面了其他的几个一线互联网公司。
其实如果经历了 BAT 这种互联网公司的几轮技术面试洗礼,那么去国内任何一个公司都没什么问题了,所以当时面试也都很顺利,驾轻就熟。
同样,朋友也不出意外的拿到了那些一线互联网公司的 Offer。经过一番对比,朋友最终没有选择去最初面试的那个 BAT 中的某个大厂,而是去了上面说的那几个超级独角兽公司中的其中一个。
原因是这家超级独角兽公司给出的薪资超出期望之外,而且领导对朋友同样非常重视,配发了大量的期权,承诺可以独立带 20+ 人的团队。
而朋友更看重的是这个超级独角兽公司未来的潜力:
公司发展速度快,人员扩张迅猛,所以给到的带团队的机会非常好,能带更大的团队,比朋友当前带的团队规模大了一倍多。
虽然 BAT 的那家大厂同样配发了期权,但是这家超级独角兽的期权未来潜力可能更大。事实证明,的确如此。
所以综合考虑了之后,朋友最终还是根据自己的职业发展选择了独角兽公司,没有再回到 BAT 行列中。