在SQL面试中夺得王牌的六个小贴士

2020-10-24 07:28:57

分析师面临的最常见的技术面试,特别是在他们职业生涯的早期,就是SQL面试。它有着极其尴尬的经历的坏名声,但从招聘的角度来看,它仍然是回答两个问题的好方法:

该候选人是否能够独立编写逻辑以成功高效地拉取数据?他们能够恰当地解释数据吗?

这些采访(假设他们是现场直播的,而不是带回家的,也不是采访)通常是这样进行的:

应聘者将SQL写在白板上、记事本文件中或其他可能能够也可能无法处理SQL的地方。我们鼓励考生在写下他们的问题和回答问题时详细讨论他们的逻辑。

这一系列问题变得更加困难,因为前几个问题的结构通常是为了让应聘者有时间熟悉并询问有关数据的问题。

如果你担心SQL面试,或者一直在苦苦挣扎,这里有一些小贴士,它们在我的整个职业生涯中都对我有帮助:

SQL面试经常让我想起学校的考试,除非有人在我工作时仔细地看着我。它增加了大多数分析师日常生活中根本不存在的压力。

以下是人们可能会觉得尴尬,但在SQL面试中完全可以接受的行为列表:

2.做好笔记,特别是关于表格的格式。(带上纸和笔以防万一。)。

我很难记住新表格的结构,即使是简单的表格。在容易接近的地方写下表格格式,并问面试官任何你可能有的问题。错过了其中一根柱子的名字吗?对某事的含义感到困惑吗?不确定该表是按用户计算还是按帐户计算?问。

记住,面试官是一种资源,他们有责任弄清楚问题的前提。

3.说出你的想法。如果你需要时间来整理你的想法,你可以要求花点时间。

虽然这些问题通常有正确的和错误的(和有效的和无效的)解决方案,但是SQL练习是关于逻辑推理的。面试官对你的思路给予了部分信任,但如果你从来不表达出来,面试官就不知道发生了什么。

我需要客户组A和客户组B的平均收入来了解哪一组通常在我们的产品上花费更多。

我需要表A和表B,第一个用于收入,第二个用于客户所属的组。因为表A是一个事务列表,所以我需要首先汇总。

我的查询的这一部分将表A中每个客户的收入相加。我想在连接到我们的组类型数据之前确定这一点。

在第一部分中,我先将每个客户的收入数据相加,然后根据客户ID从一个单独的表中加入客户类型数据,然后在这里按客户组计算每个客户的平均收入。

A组的平均收入较高,但看看这个组是否足够大,我们应该更多地关注他们,而不是B组,这将是一件有趣的事情。

如果您从未解释过如何编写SQL,请花些时间练习一下。在面试本身,你也可以要求时间,这样你就可以更清楚地谈论你已经经历的步骤或决定下一步的行动。

SQL面试很少是为了测试某人记住语法细节的能力,他们打字的速度,他们写得有多好,或者任何与成功的分析师无关的因素。记住我们使用的SQL类型的“case When”语句的语法不会对您有什么坏处,但我们不会测试那些通过谷歌搜索就能轻松解决的问题。

面试官通常也不会试图欺骗你(毕竟,数据库通常不是用来欺骗分析师的)。我们只是想确保您能够构建逻辑(和/或看到您的逻辑中的缺陷)来获取您需要的数据。

作为一名面试官,我有时担心自己无法阅读或理解一个查询,每当我看到一个很长的嵌套查询时,我就会惊慌失措。如果这封信对你来说很难写,那么我可能也很难读懂。

虽然没有必要强调你的SQL格式或做笔记的细节,但它帮助了我和我的面试官在这里投资。在有帮助的地方缩进,标记查询的不同部分,为新列指定实用名称,并使用`with‘/cte语句来分解查询,而不是使用嵌套查询。像“假设X是不同的”或“条件假设这些值都不是负值或零”这样的注释对面试官和您自己都很有帮助,可以提醒您注意查询的基本逻辑。(#34;假设X是DISTINCT;或";条件假设这些值都不是负值或零值)对面试官和您自己都很有用。

演示这项技能也很好,因为这种组织和文档对于野外分析师来说很重要。毕竟,我们确实会重新访问我们自己的查询,并彼此共享查询。

当谈到SQL面试时,没有什么可以替代真正擅长编写SQL来拉取数据。练习!

毫无疑问,连接是查询中最常见、最难处理的部分,因为它往往是我们使用的最常见、最抽象的语句,有可能彻底毁掉一切。像这样的视觉效果会有所帮助:

其他可能出现的常见语句有`group by`(及其关联的聚合)、`case When、`和`union`。

根据我的个人经验,SQL练习侧重于基本逻辑,因为可以相当快地学习更复杂的语句(有时还可以通过更简单的语句来完成)。

有兴趣成为HubSpot的分析师吗?今天就申请我们空缺的分析师职位吧!

在这里注册,我们会让您随时了解HubSpot的最新产品、用户体验和工程设计。

从HubSpot产品博客直接返回最新的工程、用户体验和产品新闻到您的收件箱。