给定一个表'员工'
employee_id | salary | department_id
-------------+--------+---------------
仅使用 SQL 查找从一个部门到另一个部门的员工调动的所有变体,因此“出发”和“到达”部门的平均工资都增长了。
PS我在一次采访中被问到这个问题,从来没有给出答案,谷歌也帮不上什么忙。
给定一个表'员工'
employee_id | salary | department_id
-------------+--------+---------------
仅使用 SQL 查找从一个部门到另一个部门的员工调动的所有变体,因此“出发”和“到达”部门的平均工资都增长了。
PS我在一次采访中被问到这个问题,从来没有给出答案,谷歌也帮不上什么忙。
因此,您正在寻找收入低于当前部门平均水平但高于预期新部门平均水平的员工。
获得所有满足此要求的员工调动的一种可能方法是
鉴于这是一个面试问题(而不是测试问题),根据上下文有几种可能性。
如前所述,该问题不完整,并且
不能也许不应该以目前的形式回答(请参阅下面的更新部分)。什么不见了?好吧,例如:如果这更像是一个 OLTP 表,那么应该在
employee_id
字段上定义一个 PK / Unique Index / Unique 约束。在这种情况下,每次只有一个条目employee_id
,因此无法确定转移(即没有“旧”department_id
记录)。如果这更像是一个 OLAP 表,那么这可能是一个缓慢变化的维度,在这种情况下会有多
employee_id
条记录。但是,还需要有ValidFrom
DATEValidTo
/ DATETIME 字段,以便可以按照正确的顺序确定出发和到达部门。如果没有这些字段,就无法确定哪个部门是出发部门,哪个部门是到达部门。并且不知道这种区别将允许取回与请求相反的记录。因此,如何解释这个问题的“背景”就是这个问题被这样陈述的原因。
您在采访之间忘记了一些细节并在这里询问:
它发生了,但如果是这种情况,那么您需要更新问题以填写缺失的信息,或者它仍然无法回答(至少在获得有意义的答案方面)。
该问题已在此处准确转录,而这些问题不为面试官所知或无意为之:
在这种情况下,如果您知道这些问题并且他们期望得到答案,那么您可以将其用作将他们淘汰出可能的雇主的一种手段;-)。
该问题已在此处准确转录,并且这些问题是面试官知道或有意为之的:
在这种情况下,他们可能只是通过查看原始技术能力来将其用作淘汰人员的一种手段。由于大多数最终用户和产品所有者等不会考虑/谈论低级技术细节,并且经常会遗漏必要的部分,因此提出问题以明确您正在从事的项目通常非常重要。重要的是不要假设而是回到请求的来源以获得澄清,这样您就不会浪费时间在错误的方向上工作。
请记住,您不是在面试一个简单地在真空中回答技术问题的职位。您正在面试一个从事项目工作的职位,并且在要求您做的事情中总是存在模棱两可和/或误导性信息。一位优秀的面试官会尝试了解您的技能水平以及您是否真正富有成效。在采访人们时,我曾问过这样的问题,以淘汰那些在回答技术问题方面做得很好但需要过多牵手并最终会拖慢团队速度的人。
更新:
只是为了澄清那些认为这是一个简单的查询技能问题的人,解释为@Martin 在他的回答中所做的:我们甚至不知道这是否是提交给 OP 的问题的确切措辞但是我们确实知道,就我们所能相信的情况而言,这是在一次采访中给出的。而且很好面试官提出的问题不仅会引出候选人的技术技能,还会引出他们的非技术/“软”技能。很可能马丁在他的解释中是正确的,即问题是询问潜在的未来转移组合(即“有时雪茄只是雪茄”)。如果这是一个测试问题,那么如果他的答案不正确,我会感到惊讶。但是,这不是一个测试问题。当然,这可能是一个面试问题,由一个不想了解候选人是什么类型的人以及他们在设计会议中如何表现的人提出的问题,在这种情况下,这种模棱两可的问题出现得比大多数人都注意到的还要多。但没有得到任何答复,把事情做好(在页面上搜索“你正在寻找的人”,但你真的应该阅读整件事)。所以,在两个各方面都是平等的候选人之间,一个假设解释并且是正确的,而另一个提出问题然后得到正确答案的候选人,我肯定会选择第一个提出的。