你如何采访数据库程序员/pipe理员申请人？

这里是我对高级数据库pipe理员的十大面试问题，以下是Tom LaRock针对初级DBA的十大问题。

我注意到其他人build议候选人应该排除服务器故障。 如果采取这种方法，请使用具有快照的虚拟机。 以特定的configuration或性能问题的方式设置服务器，拍摄快照，然后在每次采访后，您可以回滚到快照。

如果你这样做，把任务限制在你实际做的任务上。 不要问生产DBA关于规范化，也不要问开发DBA为什么一个节点不会join集群。

生产DBA任务可能是：

• 为备份，索引维护和DBCC设置作业。 看他们是否问你多久备份一次数据库，以及是否希望在本地备份或通过networking进行备份。 不要问他们如何configuration一个特殊的磁带备份软件，除非它已经在他们的简历上。
• 找出为什么约翰尼不能login并运行他的查询。
• 有人抱怨缓慢的查询。 告诉我你在哪里看看发生了什么事。 然后说，他们只是打电话来说，他们的查询完成，但他们要确保它不会再发生。
• 从昨晚的备份中恢复单个表。

开发任务可能是：

• debugging这个存储过程。
• 解释这个执行计划。
• 创build一个视图join客户发票。

使用AdventureWorks架构。 可能是他们最近没有玩过，但至less很容易解释。

在我的软件团队中，作为面试的一部分，我们testing了数据库的理解。

我们提出 – 一个非常糟糕的devise（思考CRM类应用程序），并要求他们在大约30分钟的思考时间后改进devise。

然后，我们根据他们所谈论的问题向他们提出更多的问题。

我们正在探索的理解

• 性能V标准
• 关键devise和参考完整性
• 改进的地方 – 可选数据库结构 – 触发器，查看，采购
• devise薄弱的领域 – 如何克服多方面的关系
• 这是如何影响服务器的 – 维护
• 数据安全问题
• 应用安全问题

我们作为一个团队，然后想到我们会认为是这些types的问题的初级/高级/build筑师types的答案。

因此，对于 – 性能v规范化 –

会首先看到这个问题，并能够讨论为什么（初级）

会build议4/5 NF，但理解与性能的问题，他们denormalised和理解如何阐明这个问题（高级）

他们会推荐一个不同types的devise，例如星型模式（Star Schema），并讨论许多层面的影响（build筑师）

• 关键devise和参照完整性

将会看到ref的完整性需要强制数据关系，并能够讨论这个，但不会看到与关键select和devise（初级）的问题，

将讨论与数据量和数据types有关的问题v寻找数据中的自然键，并且能够讨论为什么他们正在查看这些数据 – 以及参照完整性（高级）

可以争论与Keys和Integrity有关的各种观点，并能够提出各种实际的快速devise模型（build筑师）

你得到的照片。

如果你想让我添加更多，然后发表评论，并会详细说明我们对其余部分的看法，但只是包括了前两个部分，让我们了解我们的想法。

问题的关键在于思考1，问题2，我们作为一个团队 ，然后想到我们会认为是什么样的初级/高级/build筑师types的答案这些types的问题。

我强调球队是候选人，球队必须对进入球员的技术有信心，如果他们提出了他们所看到的不同层次的答案，那么进入球队的人将会更好地适应球队。 它也使团队有能力影响候选人的select。 他们还提名一个人在问题面板上。 帮助球队买入。

你可以组成一个虚构的数据库，其中有一些正常化问题，潜在的安全问题，但是总的来说，看起来很像典型的员工数据库。 然后，您可以开始向受访者询问简单的问题，他们将如何通过连接来获取数据库中的某些数据，从而解决关于正常化和安全问题的难题。

看到聪明，并获得了东西

…问他们最近读了哪些书，读了什么博客，听什么播客。 并询问他们是否参与stackoverflow.com和serverfault.com 😉

这不一定是与数据库相关的，但是我想添加到面试中的事情是动手解决问题和devisescheme。

对于动手问题，build立一个或多个系统，让他们可以访问并让他们解决一个开放式问题。 我个人最喜欢的就是performance问题，因为它不一定是需要面试的东西，而且很less有一个正确的答案。 相反，您可以通过查看故障排除过程来观察应聘者，还需要与您进行讨论，以获取有关环境的更多信息。 关键是让面试官对问题保持诚实，不要把情况变成寻找错误configuration设置的东西。

对于devise场景，我给予候选人一个新项目（即没有遗留依赖项）的大纲，并要求他们在其特定领域（无论是DBA，系统还是networking）提出符合项目目标的总体devise。 关键是要保持项目小到可以让整个场景处于最佳状态，并且花费不到几分钟的时间来解释。

我在这里用于我的系统和networking人员的一个例子是描述他们devise一个小型分支机构，因为我们的业务有一定的限制。 在DBA方面，也许使用一个小的/明显的CRUD应用程序。 在这两种情况下，你都不是在寻找详细的devise，而是更多的概述，看看候选人是否会寻找出现的常见问题。

这两种情况的重要一点是就这个话题进行讨论，让候选人用自己的问题来引导讨论。 应该很清楚，你并不是要求一个确切的答案。

就像你可以成像一样，我在访谈中很不喜欢琐事，我认为这让我对候选人能力有了更深的了解。

让他/他说话。 询问过去的经验，问他遇到了什么问题，以及他们如何处理。 select这个或那个解决常见问题的动机是什么？ 监控？ 扩大规模，扩大安全]。

我想你可以通过倾听来告诉很多人。

那么如果你正在寻找特定领域的具体专业知识，那么请问详细的问题 – Stefan Thyberg的build议非常好。