如何面试后端程序员？

发布网友 发布时间：2022-04-21 04:32

我来回答

共1个回答

热心网友 时间：2022-06-18 00:07

计算机网络常见面试点总结

计算机网络常见问题回顾

2.1 TCP、UDP 协议的区别

2.2 在浏览器中输入url地址 ->> 显示主页的过程

2.3 各种协议与HTTP协议之间的关系

2.4 HTTP长连接、短连接

2.5 TCP 三次握手和四次挥手

三 Linux

3.1-简单介绍一下-linux-文件系统？

3.2 一些常见的 Linux 命令了解吗？

四 MySQL

4.1 说说自己对于 MySQL 常见的两种存储引擎：MyISAM与InnoDB的理解

4.2 数据库索引了解吗？

4.3 对于大表的常见优化手段说一下

五 Redis

5.1 redis 简介

5.2 为什么要用 redis /为什么要用缓存

5.3 为什么要用 redis 而不用 map/guava 做缓存?

5.4 redis 和 memcached 的区别

5.5 redis 常见数据结构以及使用场景分析

5.6 redis 设置过期时间

5.7 redis 内存淘汰机制

5.8 redis 持久化机制（怎么保证 redis 挂掉之后再重启数据可以进行恢复）

5.9 缓存雪崩和缓存穿透问题解决方案

5.10 如何解决 Redis 的并发竞争 Key 问题

5.11 如何保证缓存与数据库双写时的数据一致性？

六 Java

6.1 Java 基础知识

6.2 Java 集合框架

6.3 Java多线程

6.4 Java虚拟机

6.5 设计模式

七 数据结构

八 算法

8.1 举个栗子（手写快排）

九 Spring

9.1 Spring Bean 的作用域

9.2 Spring 事务中的隔离级别

9.3 Spring 事务中的事务传播行为

9.4 AOP

9.5 IOC

不需要写代码就能衡量候选人的方法可能有一万种。我常用的三个主要方法可以覆盖许多不同的技能。在面试过程中，我们会谈论候选人的经验，要求他们做一些代码审查，并与别人合作设计一个系统。

下面我会详细解释这个过程。

我试图通过这些方法找到真正能够胜任技术工作的候选人，并且他们必须能在单纯的编程技能之外给团队带来价值。通常在一次面试中我能在大约一个小时内覆盖所有三个部分。我有信心这些信息能让我找到好的候选人。

1、深入挖掘他们的经验

许多团队已经这样做了。他们会在面试一开始花几分钟，询问候选人之前的工作，他们对工作的态度，等等。大多时候这就像随意谈话一样。

但这是不对的。

记住这是面试。你需要尽可能地理解他们构建系统时使用的技术。

为了做好这一点，你需要在面试开始之前仔细阅读他们的简历。这不是开玩笑，在面试开始之前至少花上10分钟仔细阅读（不是略读）简历，如果花30分钟时间则最好。要从简历中尽可能多了解些他们之前的项目，Google一下看看能否找到他们项目的公开信息。面试时挖掘背景信息所花的时间越少，就越能获得好的效果。

在面试中，要求候选人谈谈他最近最感兴趣的项目。要练习主动的倾听，要学会参与。假装你是他团队中的一员，或者假装你们是在做架构审查。你要努力了解他们构建的东西以及构建的方法。这样做的好处和坏处是什么？要让候选人知道，不知道答案无所谓，但重要的是能勾起你的好奇心。

下面是我认为能获得好的答案的问题：

你在项目中的职责是什么？这个问题本身并不是决定性的。即使在项目中承担的职责很小，他们也可能很适合你们的团队。你的候选人也许正是因为没能获得重要的职责而在寻找新的机会。因此，知道他们过去的职责会很有帮助。

你从他人那里获得了什么帮助？无法感受他人的帮助是个极其危险的信号。即使是个人项目，也一定需要别人的帮忙。你肯定不想要一个以自我为中心的同事。

给我介绍下那个功能的工作原理。解释下数据的来源和去向、存储方式以及这一切能带给最终用户的好处。这个问题的答案足以吸引你的好奇心。

这个项目中最糟糕的技术债务是什么？好的工程师必须理解他们做出决定时需要付出的代价。问完这个问题，可以继续询问他们怎样改正这些问题，或者尚未改正的理由。

有没有出过生产环境下的bug或服务中断？测试下他们是否理解bug的原因，以及团队解决bug的方法。他们是否提前预期到了bug？下次怎样才能避免同样的问题发生？

这一部分面试能让你直接了解候选人的经验。做好这一部分还能让你了解他们如何感谢别人或责备别人。你将会了解到他们如何在两难的工程问题上做出抉择，他们会与你分享最近的教训，他们与别人沟通技术的能力应该也很明显。

如果他们选择了不太适合的项目，可以考虑谈论其他项目。所谓不太适合的意思是项目不够复杂或他们记不清的情况。

注意，这一步要避免询问类似于“告诉我你解决过的最难的bug”之类的问题。要求别人回忆系统的某一部分的具体原理会带来大量的虚假负面判断。人们不可能拥有他们修复的bug相关的一切知识，这种问题会给面试过程带来很大压力。

2、让他们审查你们的代码

这项活动一半是代码审查一半是角色扮演。你可以借此筛选出那些能够提升团队整体代码质量并促进办公室氛围的人。

下面是代码审查过程中需要关注的一些方面：

他们怎样与代码的“作者”交流？交流是否有用？是否高效？是否友善？

他们会着重哪些问题？是否能明确表达出他们的疑问？他们是否会立即指出哪些无关紧要的问题？

他们是否善于阅读自己不熟悉的代码？

这个方法需要提前准备很多东西。你需要找到或编写一段代码供候选人审查。你还需要为你希望候选人找出的问题创建一个优先级列表。不要让面试管当场出题，一定要事先准备好。

在选择需要审查的代码时，不要选择产品代码。你的候选人没有你所拥有的背景知识，这样做实际上是将候选人与你的同事比较，而不是与其他候选人比较。

努力降低代码示例中的复杂度。面试的时候，候选人没有太多时间阅读代码，而且很可能他们并没有想到会做代码审查。热身就要花很长时间。

在代码中加入一两个真实的bug，但不要强调找bug。一般来说，代码审查并不是个好的找bug方法，特别是审查者从来没有见过代码的情况下。能自证的bug（如给需要数组的函数传递字符串）最好。在你的优先级列表中，bug的优先级应该是最低的，bug应该是给极其优秀的人的加分项。

最后，代码应该做一些实际的事情。如果你的公司很出名，那可以选择你的产品简化版本。但如果你需要花大量时间为候选人提供背景信息的话还是算了。

最好的选择要么是虚构的代码（也许可以选择本文竭力避免的代码面试中用到的代码），要么是开源代码中的一个拉取请求。

一旦决定了要审查的代码，你应该期待候选人找出下面这些东西：

过于糟糕的拉取请求的描述或提交信息；

能用但无法自洽的代码；

过于复杂的代码（需要重构的代码）；

混乱的变量或方法名；

过度设计的代码（即实际上永远不会用到的功能）。

如果代码中没有足够的问题，就多加一些。

这里有个潜在的问题，我还没有确定的答案。这个问题是：你是否应该提前将代码发给候选人？

如果你这样做，就又给那些有空闲时间的人以巨大的优势。如果不这样做，就要面临增加面试压力的风险。

我倾向于后者。好的面试官可以减轻压力，方法之一就是让面试者提前知道他们将做代码审查，你也可以在审查开始之前介绍你的期望。