OO 기술 인터뷰에서 디자인 관련 질문 [닫기]

최근에 몇 번의 인터뷰에 참석했으며 회사에서 "[insert model] 디자인"질문에 몇 번 이상 대답하도록 요청했습니다.

1. 요즘 업계에서 이것이 정상입니까? 저는 20여 년 동안 소프트웨어 업계에 있었고 인터뷰에 참여해 왔지만 인터뷰에서이 패턴이 최근에야 등장하고 있습니다.
2. 나는 그 질문이 매우 개방적이라고 생각한다. 예를 들면 : "주차장 디자인"에 대한 클래스 다이어그램을 그려 달라는 요청을 받았습니다. 면접관이 어떤 수준의 세부 사항을 기대하는지 잘 모르겠습니다. 이것은 온라인 테스트에서 visio 다이어그램을 첨부 할 것으로 예상되었으므로 기대치가 무엇인지 물어볼 수 없었습니다.
3. 인터뷰 과정에서 이런 종류의 질문을 사용하십니까? 클래스 다이어그램에만 관련이 있습니까, 아니면 순서, 플로차트 및 ERD도 요청합니까 (직위의 성격에 따라) 고용 과정에서 효과적입니까?

* Kevin의 답변 편집 *

예를 들면 다음과 같습니다. "빈 슬롯을 찾는 데 사용할 수있는 주차장 관리 시스템 설계"

나는이 개 클래스를 함께 할 수있는, 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>), 나는 이것을 당신의 디자인의 진화를 보는 출발점으로 사용할 것입니다. 요구 사항이 기본적이며 이유가 잘 정의되어 있지 않은 이유가 있습니다. 이는 세상이 작동하는 방식과 거의 같습니다.

"두 개의 오토바이가 하나의 슬롯에 주차 할 수 있습니다"라는 새로운 요구 사항을 충족하여 설계를 처리하기 위해 어떻게 진화했는지 확인할 수 있습니다. 그렇다면 동시성에 대한 대화가있을 수 있습니다 (두 개의 입구가 있고 두 개의 자동차가 동시에 당겨지면 디자인이 실패합니까? 어떻게해야합니까?). 다른 가능한 방법으로는 할당 된 주차 방법, 주차 요금 청구, 행당 요금 (행이 더 가까울 수 있음), 시간 제한 주차 및 위반자를 찾는 방법 등이 있습니다.

또한 주차장에 대한 귀하의 사고 과정이 문제를 지능적으로 분석하는 일반적인 능력을 나타내는 것으로 생각합니다. 기본적인 유스 케이스를 요청하거나 홀드 볼 (예 : 주차의 1 스페셜에 대한 2)을 생각해 내야한다면 실제로 주차장을 사용한 적이 없으며 우리가 약간 복잡한 것에 대한 의사 소통이 어려울 것입니다.

코드 생성을 위해 클래스 다이어그램을 만들 때 다시 질문했습니다. 나는 여전히 가끔씩하지만 일상적으로하지는 않는다. 나는 그 사람이 생각하는 것을 볼 수 있기 때문에 질문을 좋아한다.

개방형으로 설계되었습니다. 괜찮아. 정답이 하나도 없습니다. 나는 내 마음에 답이 없습니다. 그것이 어디로 인도되는지 알고 싶습니다. "응답 이메일"이 아니라 직접 물어 보는 것이 더 좋은 질문이라고 생각합니다. 의사 소통, 가정 및 상호 작용에 관한 것입니다. 답이 아닙니다!

1. 나는 적어도 12 년 전에 이런 유형의 인터뷰를 보았습니다. 지난 6 년간 제가 사용한 접근법입니다. 경험에 의하면 20 번의 질문을하는 것보다 직업에 대한 더 나은 후보를 선택하고 20 점 만점에 점수를 얻는 것으로 나타났습니다.

2. 다시 말하지만, 나는 그것을 너무 개방적으로 만들었습니다. 목표는 응시자가 능력을 발휘할 수있는 공간을 제공하는 것입니다. 이 단계에서 관련 질문을 한 후보자가 있으면 더할 나위없이 좋습니다. 후보는 좋은 가정을하되 가정이라고 가정하고 이행하기 전에 검토해야한다.

3. 나는 모든 잠재적 인 직원들에게 면접에서 필요한 기술을 보여줄 것을 요구합니다. 프로그래머는 코드를 구현하고 설계에 대해 이야기해야합니다. 그것은 나쁜 고용을 예방하는 데 매우 효과적이지만 인터뷰에서 90 %의 실패율에 대비해야합니다.

작은 시스템을 설계하는 것은 실제로 인터뷰에서 요구하는 매우 관련성 높은 연습입니다. 도메인 문제에 대한 훌륭한 소프트웨어 솔루션을 제공하는 기술을 보여줍니다.

그러나 인간의 상호 작용없이 온라인으로 수업 다이어그램을 게시하도록 요청하는 것이 이상하다고 생각합니다.

• 다이어그램의 추론과 그런 식으로 디자인하게 된 필수 요소를 놓치게됩니다.
• 신청자가 너무 멀리 가지 못하게 막는 "난간"이 없습니다. 다이어그램에서 최종 구현을 반영하면 수십 개의 클래스와 읽을 수없는 스키마가있을 수 있습니다.
• UML 클래스 다이어그램을 그릴 수 있다는 것은 실제로 필수적인 기술이 아니며 다른 것들 중에서 하나의 OO 표기 일뿐입니다. 견고한 디자인을 만들 수 있습니다.

실시간 인터뷰에서 후보자가 취할 것으로 예상되는 이상적인 단계는 다음과 같습니다.

• 채용 담당자와의 문제에 대해 이야기하고 기본적인 솔루션을 구두로 표현하고 질문을하고 채용 담당자가보다 정확한 요구를 제공하도록 조정하십시오.
• 시스템의 전체 모습과 구성 요소가 상호 작용할 수있는 방법을 일어 서서 스케치하십시오. 가장 순수한 스타일의 UML 일 수 있으며 상자와 원일 수도 있습니다.
• 구성 요소 / 클래스 중 하나에 대한 높은 수준의 승인 테스트 또는 단위 테스트 중 하나를 테스트하십시오.
• 해당 구현 작성을 시작하십시오.

어느 시점에서 모집자가 후보자의 기술에 대한 충분한 정보를 수집하여 하루라고 부를 수 있기를 바랍니다. 목표는 완전한 작업 솔루션을 구현하지 않는 것입니다 (변장 면접에서 이러한 무료 서비스 중 하나가 아닌 한).

OOP 질문은 개방적입니다. 옳고 그른 대답은 없지만 인터뷰어가 볼 것으로 예상되는 몇 가지 원칙이 있습니다 (예 : 생성자를 사용하여 변수를 초기화하고, 메서드를 작게 유지, 캡슐화 / 조성 / 다형성 / 상속성을 사용하는 등).

인터뷰에서 데이터 구조, OOP 및 데이터베이스 관련 질문을 항상 기대하십시오. "코딩 인터뷰 크래킹"및 "노출 인터뷰 프로그래밍"과 같은 책은 준비하는 데 도움이 될 수 있습니다.

얼마 전까지 만해도 주차장을위한 디자인이 나오라는 요청을 받았습니다. 처음에는 유스 케이스가 없었지만 나중에 언급했습니다. 내 디자인이 면접관의 생각과 맞지 않는다고 생각합니다. 모든 소프트웨어 디자인이 주어진 사용 사례에만 유효하다는 데 동의합니다. 이 면접 질문으로 돌아가서, 나는 면접관이 실제 디자인 경험이 없다고 생각합니다. 그 사람들은 자신이 원하는 것을 알고 있다고 생각합니다. 그것이 사실인지 아닌지에 대한 또 다른 이야기입니다.