Interviewing Goose Factory, I was abused on three sides...


Poke the blue word " CSDN Cloud Computing " to follow us!

640?wx_fmt=jpeg

Author |  codegoose

Source |  https://segmentfault.com/a/1190000017864721

 








After half a year of precipitation, plus the completion of MySQL, redis and distributed, I finally regained my confidence in the interview and went out again.

goose factory

Interview position: go back-end development engineer, accepting language transfer from Java

We all know that Goose Factory is the main battlefield of cpp, and most engineers with a cpp background have particularly high requirements for OS and network, unlike Java, which focuses on the business layer.

The companies that interviewed Java before focused on data structures, networks, frameworks, databases, and distribution. So the OS suffers a lot.

One side: basic technical side

In the telephone interview, I asked some technical questions casually, and finally asked a medium-level algorithm question in LeetCode, which was relatively simple. I roughly sorted out my memory:

  • Have you ever used redis, commonly used data structures and scenarios used in business.

  • How is the hash of redis implemented?

  • What is the difference between the rehash process and the rehash of JavaHashMap?

  • Have you ever learned about redis cluster, how to achieve high availability?

  • Let’s talk about the persistence mechanism of redis. Why can’t redis be used as a dedicated persistent database storage?

  • If you don’t understand tcp/udp, let’s talk about the definitions of the two. Why does tcp shake hands three times and wave four times?

  • How does tcp ensure orderly transmission, and talk about the fast retransmission and congestion mechanism of tcp

  • Do you know the time_wait state, where does this state appear, and what is the use?

  • UDP is an unreliable transmission. If you design an almost reliable algorithm based on UDP, how do you design it?

  • What is the difference between http and https? Tell me what problem https solves, and how? Talk about the handshake process of https.

  • Seeing that etcd is used in your project, explain what etcd is used for, and how to ensure high availability and consistency?

  • Now that you mentioned the raft algorithm, how about the basic flow of the raft algorithm? What to do if there is a split brain in the raft algorithm?

  • Have you ever learned about the zab algorithm of paxos and zookeeper? What is the difference between them before?

  • What database do you use for persistence in the backend? Have you used sub-database and sub-table, and how do you do it?

  • What are the common implementations of indexes and what are the differences?

  • What are the storage engines of MySQL and what are the differences?

  • What method does InnoDB use to implement indexes, and how? What is the difference between a clustered index and a non-clustered index?

  • Have you heard about coroutines? Talk about the difference between coroutines and threads?

  • Algorithm question one, Jianzhi offer question 51, repeated numbers in the array?

I would like to talk about my own answer. There is no problem with redis. I have the impression that rehash is gradual, but the specific principle may be a little different.

The answer to time_wait of tcp is not very good. I haven’t learned about the implementation of the quic mechanism before, so when I asked about the reliability of udp, I basically talked about the implementation of tcp in my mind.

There is nothing to say about https. Similar things were used in previous projects, and the research is relatively clear.

As for the raft algorithm, because I happened to be working on 6.824 (I just got to lab2...), the answer is okay, but I am really not familiar with the paxos and zab algorithms, so I just said no.

I am very familiar with MySQL, including indexes, locks, transaction mechanisms, mvcc, etc. There is nothing to say, and everything has been completed.

Coroutines and threads mainly talk about the difference between go routines and Java threads and the scheduling model of go routines. The interviewer reminded that there is no mention of the kernel-mode switching of the thread, and the go process is only scheduled in the user mode.

The last algorithm question, first of all, use HashMap to do it, and ask whether the space complexity can be reduced to O(1). After thinking about it for about 5 minutes, I came up with the idea of ​​​​in-place replacement.

Generally speaking, the answer is not bad, and that's it for one side.

Two sides: the technical side of the project

Ermian transferred from the basic technology inspection to the project, and mainly asked me the following questions:

  • For the projects you are most familiar with, draw the project architecture diagram and the main data table structure of the project.

  • Talk about the technical points used in the project, the total peak qps of the project, and the delay.

  • Have you analyzed where the time-consuming delays occur and where is there any improvement in the project?

  • If there is a problem with the request and there is no response, how to locate the problem and talk about the idea?

  • How to deal with the problem of tcp sticky packets?

  • Then I also asked about the mode of cache update, as well as the problems and solutions that will arise?

  • 除了公司项目之外,业余时间有没有研究过知名项目或做出过贡献?

这一面答的也比较顺利,因为都是围绕项目,自己很熟悉,基本都没有啥问题,除了面试官说项目经验稍弱之外,其余还不错。

三面:综合技术面

这面面的是阵脚大乱,面试官采用刨根问底的方式提问,终究是面试经验不够,导致面试的节奏有点乱。举个例子:

其中有个题:go程和线程有什么区别?

:起一个go程大概只需要4kb的内存,起一个Java线程需要1.5MB的内存;go程的调度在用户态非常轻量,Java线程的切换成本比较高。

接着问为啥成本比较高?因为Java线程的调度需要在用户态和内核态切换所以成本高?为啥在用户态和内核态之间切换调度成本比较高?我简单说了下内核态和用户态的定义。

接着问,还是没有明白为啥成本高?心里瞬间崩溃,没完没了了呀,OS这块依旧是痛呀,支支吾吾半天放弃了。

后面所有的提问都是这种模式,结果回答的节奏全无,感觉被套路了。大多度都能回答个一二甚至是一二三,但是再往后或者再深入的OS层面就GG了。

后面问了下项目过程中遇到的最大的挑战,以及怎么解决的?

还问了一个问题定位的问题,服务器CPU 100%怎么定位?

可能是由于平时定位业务问题的思维定势,加之处于蒙蔽状态,随口就是:

  • 先查看监控面板看有无突发流量异常

  • 接着查看业务日志是否有异常,针对CPU100%那个时间段,取一个典型业务流程的日志查看

  • 最后才提到使用top命令来监控看是哪个进程占用到100%

果然阵脚大乱,张口就来,捂脸。。。 

对这个问题,本来正确的思路应该是先用top定位出问题的进程,再用top定位到出问题的线程,再打印线程堆栈查看运行情况

这个流程换平时肯定能答出来,但是,但是没有但是。还是得好好总结。

最后问了一个系统设计题目(朋友圈的设计),白板上面画出系统的架构图,主要的表结构和讲解主要的业务流程,如果用户变多流量变大,架构将怎么扩展,怎样应对?

这个答的也有点乱,直接上来自顾自的用了一个通用的架构,感觉毫无亮点。

后面反思应该先定位业务的特点,这个业务明显是读多写少。然后和面试官沟通一期刚开始的方案的用户量,性能要求,单机目标qps是什么等等?

在明确系统的特点和约束之后再来设计,而不是一开始就是用典型互联网的那种通用架构自顾自己搞自己的方案。

面试结果:3天后收到短信,被拒

总结:
  1. tcp/udp,http和https还有网络这块(各种网络模型,已经select,poll和epoll)一定要非常熟悉

  2. 一定要有拿的出手的项目经验,而且要能够讲清楚,讲清楚项目中取舍,设计模型和数据表

  3. 分布式要非常熟悉

  4. 常见问题定位一定要有思路

  5. 操作系统,还是操作系统,重要的事情说三遍

  6. 系统设计,思路,思路,思路,一定要思路清晰,一定要总结下系统设计的流程

  7. 一点心得,平时blog和专栏看的再多,如果没有自己的思考不过是过眼云烟,根本不会成为自己的东西,就像内核态和用户态,平常也看过,但是没细想,突然要自己说,还真说不出来,这就很尴尬了。勿以浮沙筑高台,基础这种东西还是需要时间去慢慢打牢,多去思考和总结。

640?wx_fmt=png

福利

扫描添加小编微信,备注“姓名+公司职位”,加入【云计算学习交流群】,和志同道合的朋友们共同打卡学习!


640?wx_fmt=jpeg


推荐阅读:


It smells so good, I'm watching it!

Guess you like

Origin blog.csdn.net/FL63Zv9Zou86950w/article/details/96789564