技术面试中与OO设计相关的问题[关闭]

我最近参加了很多访谈，并且公司要求他们多次回答“设计[插入模型]”问题。

1. 如今，这在行业中很正常吗？我进入软件界已有二十多年了，参加了我的部分采访，但是我看到这种采访模式只是在最近才出现。
2. 我觉得这个问题很开放。例如：我被要求绘制一个类图以“设计停车场”。我不确定面试官期望的详细程度。这是在网上测试中，我应该附上一个visio图，所以我不能问他们对他们的期望是什么。
3. 您是否在面试过程中使用了这类问题？它们仅与类图相关，还是您还询问顺序，流程图和ERD（当然取决于职位的性质），它们在招聘过程中是否有效？

*编辑凯文的回应*

例如：一个完整​​的问题可能是“设计可用于查找空位的停车场管理系统”

我可以用2班来完成，ParkingLot而Slot我也可以继续添加IVehicle和Vehicle及Car和Motorcycle类。我在哪里划界线？

public class ParkingLot
{
   IVehicle Vehicle {set; get;}

   List<Slot> GetEmptySlots() { };
}

public class Vehicle : IVehicle
{
  Slot SlotNum {set; get;}
}

public class Slot
{
  int Row {set; get;}
  int Column {set; get; }
}

1. 在某种程度上，是的。任何人都可以背诵语法或通过解决方案复制/粘贴自己的方式。我们想雇用可以解决问题的人。

2. 他们希望您能充分记录设计，以便他们能够理解（并且仅此而已）。

3. 我问人们如何解决XYZ问题。通常他们只是口头描述它。我想看看他们是否提出问题以澄清要求。我想看看他们如何与其他程序员交流。我想看看他们是否可以思考。

这对我很有帮助。我不需要代码猴子，我想要软件工程师。

我觉得这些问题很愚蠢。真正的答案是“用例是什么？” 没有用例，就不需要任何设计。例如，这是对停车场问题的一个完全合理的答案：

class ParkingLot {
 boolean isFull();
 void carEntered();
 void carExited();
}

它满足一个明显的用例。

实际上，您在编辑中演示了此问题的一种用法，在该情况下您无法设计可行的模型。

public class ParkingLot
{
   IVehicle Vehicle {set; get;}

   List<Slot> GetEmptySlots() { };
}

public class Vehicle : IVehicle
{
  Slot SlotNum {set; get;}
}

public class Slot
{
  int Row {set; get;}
  int Column {set; get; }
}

var parkingLot = new ParkingLot();
var v1 = new Vehicle();
v1.Slot = parkingLot.GetEmptySlots()[0];
parkingLot.Vehicle = v1; // WHAT!??

您还提到了创建Car和Motorcycle类，无需进一步考虑就没有多大意义。您的设计不会因继承子类而受益Vehicle。如果您引入时Motorcycle没有任何行为差异Vehicle，我会认为这是一个失败。

如果您没有发现单个Vehicle问题，那么我们将在现场采访中完成很多工作。如果您对此进行了纠正（可能是通过进行了纠正List<IVehicle>），那么我将以此为出发点来研究设计的演变。有一个基本的要求是有原因的，并且没有明确定义的用例-这几乎就是整个世界的工作方式。

我可能会向您提出“两辆摩托车可以在一个插槽中停放”的新要求，以了解您如何改进设计来处理它。然后，也许我们围绕并发进行了讨论（如果我们有两个入口，同时有两辆汽车同时行驶-您的设计会失败吗？怎么办？我们该怎么做才能解决它？）。其他可能探索的途径将是如何实施分配的停车，停车收费，每排收费（也许更近的排必须支付更多），限时停车以及如何找到违规者等。

我还认为您在停车场周围的思考过程可以表明您具有智能分析问题的一般能力。如果您不得不问我一些基本的用例和/或想出一些奇异的用例（例如2个停车位上有1个特价商品），我会开始担心您以前从未真正使用过停车场，而我们在有些复杂的事情上很难沟通。

我曾经问过这些问题-回到我们创建用于代码生成的类图时。我有时还是这样做，但不是经常。我喜欢这个问题，因为它让我看到人们的想法。

它打算是开放式的。没关系。没有一个正确的答案。我心中没有答案。我想看看它的方向。我认为最好亲自问一个问题，而不是“通过电子邮件发送”。这是关于沟通，假设和互动的；不只是一个答案！

1. 我至少在12年前见过这种类型的采访。这是我最近6年使用的方法。经验表明，与提出20个问题相比，它会选择更好的候选人，并给他们20分中的满分。

2. 再说一次，我也将其设为开放式。目的是为候选人展示能力提供空间。有一个候选人在这个阶段问相关问题将是一个加号。候选人会做出良好的假设，但会标明它们是假设，在实施之前需要进行审核。

3. 我确实要求所有潜在员工在面试时展示他们所需的技能。对于程序员来说，他们将需要实现一些代码，并讨论其设计。这对于防止不良雇用非常有效，但要做好面试时90％的失败率的准备。

设计小型系统实际上是在面试中提出的非常相关的练习。它显示了您提出针对域问题的良好软件解决方案的技巧。

但是，我发现奇怪的是，只要求在没有人工干预的情况下在线发布类图：

• 他们会错过基本要素-图表背后的原因以及导致您以这种方式设计事物的原因。
• 没有“隔离墙”阻止申请人走得太远。如果您在图中反映了最终的实现，则可能会有数十个类和不可读的架构。
• 能够绘制UML类图并不是真正的必不可少的技能，它只是其中的一种OO表示法。能够创建可靠的设计。

在现场面试中，我希望候选人采取的理想步骤是：

• 与招聘人员讨论问题，并开始口头表达基本解决方案，提出问题并根据招聘人员提出的更精确需求进行调整。
• 站起来，勾勒出系统的整体视图以及组件如何相互作用。可能是UML最纯粹的样式，可能只是方框和圆圈。
• 为组件/类之一编写测试，可以是高级验收测试，也可以是单元测试。
• 开始编写相应的实现。

希望在某个时候，招聘人员将收集到有关候选人技能的足够信息，并称之为一天。目标不是实施完整的解决方案（除非它是变相采访中的这些无偿服务之一）。

OOP问题是开放式的。没有正确或错误的答案，但是访问员希望遵循一些原则（例如使用构造函数初始化变量，使方法保持较小，在适用时使用封装/合成/多态/继承等）。

在面试中总是希望获得与数据结构，OOP和数据库相关的问题，它们很常见。诸如“破解编码访谈”和“公开编程访谈”之类的书可以帮助您进行准备。

不久前，有人要求我提出一个停车场设计。首先没有给我任何用例，但稍后提到了一些。我认为我的设计与面试官的想法不符。我同意任何软件设计仅对给定用例有效。回到这个面试问题，我相信我的面试官没有任何现实世界的设计经验。这些人相信他们知道自己的要求。这是否真的是另一回事。