美文网首页Spring-Boot
【行走的Offer收割机】记一位朋友斩获BAT技术专家Offer

【行走的Offer收割机】记一位朋友斩获BAT技术专家Offer

作者: 70b39f9dc443 | 来源:发表于2019-07-05 16:30 被阅读6次

    背景介绍

    PS:

    面试者是笔者以前的下属,多年的好朋友。

    这是他今年早些时候出去面试,拿到BAT等多家一线互联网公司技术专家Offer的面试经历。

    先介绍一下这位朋友的个人经历:

    本科毕业,接近10年工作经验。跳槽之前,在国内某大型互联网公司里带一个8人左右的技术团队。

    由于公司业务发展较为平缓,所以职业上升机会较少。

    朋友对其负责的系统架构和技术已经非常熟悉,薪资上也较难有大幅度的增长,至于晋升更高的级别,短期内也不容易。

    因此,在仔细思考一番之后,决定出来看看机会,能否在带团队的规模、技术以及薪资上实现一个突破。

    一面

    一面是一个猎头给朋友推的一个职位,BAT中某一个大厂的某个团队,具体就不说是哪个部门了。

    一面就直接过去当面聊了一次,大概从下午2点聊到了下午4点多,时间很长,炮火相当猛烈。

    一面面试官也是专家职级,上来就是先聊项目,针对项目中的各种细节仔细问,就项目展开,而且极其注重细节。

    下面的内容,是根据朋友面试之后的回忆,整理出的部分问题。

    面试同样是通过互联网公司最喜欢的连环炮形式发问。比如在面试过程中,聊到了缓存。连环炮如下:

    接着,面试官继续深扣了很多细节

    面试官

    那请说一下,这些请求具体是落在哪些接口上?

    哪些数据是数据库和缓存双写一份的?

    双写一致性如何保证?保证一致性的同时如何保证高并发和性能?

    缓存线上是如何部署的?给了多大的总内存?命中率有多高?

    缓存抗了多少QPS?数据流回源会有多少QPS?

    是否某个key出现了热点缓存导致缓存集群中某个机器的负载过高?如何解决的?

    是否出现超大value打满网卡的问题?如何规避这个问题?

    线上是否出过缓存集群事故?如果出现了你们怎么解决有什么高可用保障预案?

    平时如何监控缓存集群的QPS和容量?如果要扩容该怎么扩?能否平滑扩容?扩容会导致系统需要停机吗?

    聊聊Redis的集群原理?扩容的时候会不会导致数据丢失?key寻址算法都了解哪些?

    你了解一致性hash算法吗?画个图说说Redis线程模型和内存模型?

    朋友

    纸笔翻飞,大脑高度运转,一个接一个的回答。。。

    如上所述,所有问题,全部结合项目,落地到生产中,同时注重聊技术的很多细节,包括技术的一些原理。

    像缓存这样的连环炮提问法,面试官还用来问了MQ、MySQL分库分表、高可用、JVM、多线程并发,等各种问题。

    简单总结:

    一面其实关注了技术广度,同时结合项目死扣各种细节。

    另外也兼顾了一定的技术深度,会就一个技术往深了问下去。

    总体来说,一面还算顺利,毕竟都是结合项目来问的,各种细节平时朋友进行架构设计时,都会仔细考虑过。

    而且朋友也做过线上的高并发系统,踩过很多坑,所以这些问题基本都回答的不错。

    但是这里给大家提醒一句,一般某个同学出去面试,回来之后其他人问他面试经验,一般都是问:都有啥面试题?面试官是怎么问的?

    说实话,大家看了上面那些问题,可能会觉得说,哦,其实我也可以答出来,没什么特别的。

    但其实并不是这样,如果只是拿高级岗位的Offer,你的技术会占很大比重。

    但是如果要拿专家岗位的Offer,你到底有没有线上真实的高负载的系统架构经验,非常重要。

    同样的问题,普通人会回答的很普通,但是经历过真实几十亿流量请求的人一定会说出大量经验总结、教训以及采坑。

    而且对整套复杂的大型系统到底是如何抗住高并发的,会了然于胸,熟悉所有的细节。

    所以针对一面,一般就是结合项目,深挖细扣,看你到底有多少水平,做过多复杂的系统。

    这块说实话,做过就是做过,没做过就是没做过,是不可能作假的。

    很多同学可能自己平时也看过很多书和博客,但是看书和博客只是基础,如果没有真实的线上生产环境的历练,是肯定不够的。毕竟实践出真知!

    二面

    一面就顺利通过了,紧接着安排了第二轮面试。

    二面面试官应该是这个团队的leader,P8级别的,如果进去,应该就是朋友未来的顶头上司。

    据朋友讲,二面面试官态度非常好,很和蔼,看来一面面试官反馈之后,这个team对朋友还是比较重视的。

    (1)技术深度

    二面内容就从广度变成深度了,面试官技术实力很深厚,应该是有十几年经验。对相关技术深挖了很多东西。

    同样,二面也聊到了缓存相关的问题。问了朋友具体了解过哪些缓存技术,redis、memcached,还有阿里开源的tair,哪个了解过内核原理?

    朋友之前看过一些redis的内核,就聊了聊redis内核的一些数据结构和实现原理。包括集群、持久化在内核层面的一些东西。

    此外在MQ这块,朋友正好对kafka做过深入的研究,就聊了聊Kafka的源码。

    比如KafkaController在故障转移这块的源码,日志存储、网络通信的一些细节。如何保证磁盘读写的高性能,零拷贝那块的底层实现,leader和follower之间的数据是如何同步的,都是从源码层面来聊。

    此外,还聊了dubbo的源码以及mysql内核层面的东西。

    (2)系统设计、工程素养、带团队

    同时二面非常重视考察系统设计能力、工程素养、带团队的能力。

    比如面试官就这个部门负责的一块业务,出了一个相关的系统设计题目。

    题目细节记不清楚了,大体内容是给出具体的用户量、业务场景、并发量、数据量,然后让你整体负责这个系统的架构设计。

    朋友需要阐述自己的整体设计思路,从哪些点来考虑,存在着哪些技术挑战,并且现场画出来具体的架构设计图。

    工程素养这块,让朋友聊了聊平时如何做的技术设计、技术评审、编码规范、测试、上线、回滚、灰度、压测、监控等等。

    带团队,让朋友说一下,如何招人、面试标准、如何搭建团队的人才梯度,等等。

    (3)架构演进

    此外,还会问一下,整个系统架构是如何一步一步进行演进的。

    从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行列中。

    相关文章

      网友评论

        本文标题:【行走的Offer收割机】记一位朋友斩获BAT技术专家Offer

        本文链接:https://www.haomeiwen.com/subject/azmehctx.html