인터뷰에서 임의의 시스템을 어떻게 디자인합니까? [닫은]

Tech Interview의 일반적인 질문은 일반적으로 회사의 기존 제품인 특정 시스템을 설계하는 것입니다. 예를 들어 "Design Google Docs"입니다.

그러한 질문에 대한 예상 답변은 무엇입니까? 내 말은, 그러한 시스템은 반드시 모든 인터뷰 범위를 벗어난 복잡한 디자인을 가지고 있다는 것을 의미합니다. 짧은 시간에 면접관들은 무엇을 기대하고 있습니까?

뇌가 어떻게이 문제를 바라 보는가에 대한 통찰력. 다음은이 대화를 시도하는 방법에 대한 몇 가지 시작점입니다.

• 하향식-매우 높은 수준에서 내려다보고 디자인을 만들고 다양한 구성 요소가 완료되면 디자인을 구체화합니다. 여기에 볼 수있는 몇 가지 구성 요소가 있습니다 ....

• 상향식-처음부터 살펴보면, 조립을 시도 할 수있는 비트와 조각이 있습니다 ....

• 요구 사항 설명-이 디자인에 사용 된 예상 규모, 규모, 예산 및 팀에 대한 질문. 개인 코드를 매우 단순화 된 워드 프로세서로 만들거나 Google 문서를 극단적으로 활용 한 최고의 문서 관리 시스템을 만들기 위해 수억 달러를 쓰도록 계획 할 수 있습니다. 또한 여기에 "Google Doc의 의미는 무엇입니까? 그 기능 중 얼마나 많은 부분을 복제 하시겠습니까?"와 같은 질문을 할 수 있습니다. 질문도 있습니다.

핵심은 사용자가 접근하여 "2 주 후에 이와 같은 것을 만들 수 있을까요?"라는 질문을하면서 이러한 종류의 문제를 해결하기위한 생각과 접근 방식을 얼마나 잘 전달할 수 있는가입니다. 실제로 일어날 수 있습니다. 따라서, 어떻게 당신이주는 대답은보다 더 중요한 무엇인지 답변입니다.

내 개인적인 의견은 과거의 프로젝트가 여기에 좋지 않다는 것입니다. 우리가 찾고자 하는 것은 과거에 어떤 일이 일어 났는지 회상하기보다는 새로운 분야 에서 어떤 종류의 창의성과 의사 소통 기술을 찾는 것입니다 . 새로운 위치에서 발생하는 일이 과거의 일과 비슷할 수 있지만 기존 솔루션으로는 불가능할 정도로 충분한 차이가있을 수 있습니다. 그렇기 때문에 빌드 할 수있는 것은 기존 응용 프로그램과 유사하지만 솔루션을 초기 예제와 크게 다른 다양한 사용자 지정이있을 수 있습니다.

인터뷰는 양방향 거리입니다. 관리자 및 기타 개발자는 인터뷰 마스터가 거의 없으므로 면접에서 주제 전문가가되어야한다고 언급하는 데 가치가 있는지 잘 모르겠습니다. 채용 담당자 인터뷰를하는 방법을 알고 싶어하지만, 이것이 항상 좋은 생각이 아닌 이유의 예로 사용할 수있는 가난한 채용 담당자가 많이 있습니다.

특히 선임 개발자의 경우 이러한 질문이 매우 좋습니다. 그들은 개발자가 크고 복잡한 설명에서 현실적인 구현으로 이동할 수 있음을 보여줍니다. 완전히 익숙하지 않은 시스템을 사용하더라도 면접관을 위해 여러 가지 흥미로운 활동을 수행 할 수 있어야합니다.

• 질문에 답변하기위한 요구 사항 수집 (예 : 범위)
• 문제를보다 관리하기 쉬운 부분으로 나누십시오. 필요할 수있는 인터페이스 또는 객체를 식별하거나 로직을 프론트 엔드, 백엔드, DB 등으로 나눕니다.
• Google 문서 도구의 경우 웹 앱과 같은 해당 시스템 유형의 구조와 개념에 대한 친숙 함을 보여줍니다.
• 디자인 문제 (오브젝트 디자인? SQL 테이블? 디자인 패턴)가 나타날 때 집중하려는 경향을 보여줍니다.
• 상사에게 당신과 함께 새로운 시스템을 개발하는 것이 어떤 것인지 미리보기를 보여주십시오. 여기서 상사는 사양에 따라 "이것을 구축하는 데 무엇이 필요할까요?"라고 말합니다.

이 질문은 "이것에 사용할 개체 계층 구조를 설명합니다."의 상위 버전에 불과합니다. "이를 위해 디자인 할 인터페이스에 대해 설명하십시오." "이 데이터에 대한 관계형 DB 테이블 세트를 디자인하십시오. ..."등은 중급 개발자에게 제공 될 것입니다. 저급 개발자의 경우 면접관은 회사의 장기 성장 가능성을 평가하거나 압도적 일 수있는 큰 문제에 직면했을 때 자신이하는 일을보고있을 수 있습니다.

그것은 당신의 사고 과정이 실제로 행동하는 것을 보는 것입니다. 그들은 해결책에 관심이 없지만 문제를 해결하는 방법, 질문 할 질문, 식별 할 문제 등

Google 문서 도구의 예를 고려할 때 기억해야 할 명백한 문제는 스토리지, 보안, 확장 성, 가용성, 클라이언트 인터페이스 디자인, 브라우저 호환성 등과 같은 것입니다. 서버와 클라이언트간에 책임을 어떻게 구분 하시겠습니까? 백업을 어떻게 처리 하시겠습니까? 서버가 다운되면 어떻게됩니까? "폐기 된"문서 (오래 동안 액세스하거나 수정하지 않은 문서)로 무엇을 하시겠습니까?

다시 말하지만, 요점은 이러한 문제 를 해결 하는 것이 아니라 문제를 식별 하고, 이야기하고, 문제 를 해결 하는 방법에 대해 약간 브레인 스토밍하는 것입니다.

저는 인터뷰에서 이런 유형의 질문을 자주하는 유죄 자 중 한 사람입니다. (기록을 위해, 나는 그들의 "좋아하는 프로젝트"에 대해서도 비슷한 질문을한다.) 내가 묻는 이유는 그것이 우리가 자주 여기에서하는 일이기 때문이다. 우리는 인터페이스의 모든 측면에서 설계 엔지니어, 시스템 엔지니어링, 테스트에서, 그리고 기능에 대한 고객 사용 사례에 대한 지식을 가진 사람을 얻습니다. 우리는 화이트 보드 주위에 서서 "좋아, 어떻게하면 될까?"라고 말합니다. 종종 그 시점에서 새로운 기능에 대해 거의 알지 못하며 시스템 부분에 대한 전문 지식으로 인해 존재하지만 여전히 생산적으로 기여할 것으로 예상됩니다. 단순한 학문적 운동이 아닙니다.

예를 들어, 중앙 사무실에서 20 개의 내장 된 라인 카드를 통해 서버에서 새 펌웨어를 다운로드 할 수있는 시스템을 설계하여 현장에서 5000 개의 셋톱 박스를 한 번에 업그레이드 할 수 있습니다. 서버와 라인 카드 사이의 링크에 여분의 용량이 거의 없다고 가정하십시오.

나쁜 대답 :

음, 아마도 이더넷이나 그와 비슷한 것을 사용할 것입니다.

좋은 답변 :

이미지가 얼마나 큰가요? [약 7MB] 글쎄, 다운로드하는 동안 서비스가 영향을받지 않았 으면합니다. 한 번에 두 개의 이미지를 저장하려면 추가 플래시 또는 RAM이 필요합니다. 서버에서 동일한 이미지가 계속 다운로드되는 것을 피하기 위해 라인 카드에 이미지를 캐시하려고 할 수 있습니다. 내장 된 라인 카드는 CPU 자체가 제한되어 있으므로 서비스를위한 충분한 용량을 확보하기 위해 다운로드를 직렬화해야 할 수도 있습니다. 이미지가 양호한 지 확인하고 작동하지 않으면 이전 버전으로 폴백 할 방법이 필요합니다. 업그레이드에 실패한 경우 몇 번 다시 시도하고 사람에게 오류를보고 할 수있는 방법이 필요합니다. 다른 셋톱 박스 브랜드가있는 경우 전송해야 할 이미지를 식별 할 수있는 방법이 필요합니다.

그것들은 거의 다른 두 후보의 단어 전사에 대한 단어입니다. 대부분의 지원자들은 중간에 있지만 일반적으로 약간의 프롬프트로 끝납니다. 우리는 여기서 다음 아인슈타인을 찾지 않고 단지 매일 우리가 일하는 문제의 종류에 대해 지능적으로 추론 할 수 있음을 나타냅니다.

나는 또한 이런 종류의 질문을하고 다른 답변들 대부분에 동의합니다. 인터뷰 대상자가 왜 이런 유형의 질문이 중요한지 이해하는 데 도움이 될 수 있습니까? 우리가 결정해야 할 중요한 비즈니스 결정이 있다고 가정하고,이를 위해서는 새로운 시스템을 구축해야합니다. 누군가 당신에게 달려 가서 X를 수행하는 시스템을 구축하는 데 무엇이 필요한지 물어 보면, 필요한 주요 도전과 자원을 예측하는 통찰력있는 답변을 줄 수 있습니까?

주니어 프로그래머는 어디서부터 시작해야할지 모른다. 자세한 사양이 없으면 대화를 시작할 준비가되지 않았습니다. 선임 프로그래머는 문제에 대한 많은 측면이 있다는 것을 즉시 알 수 있으며 도전에 착수하려고합니다. 모든 측면을 설계 할 필요는 없으며, 아키텍처 문제를 파악한 다음 해결 방법을 찾아보십시오.

Google 문서 문제를 고려하십시오.

흥미로운 것은 요청의 전단 규모입니다. 하나의 서버 만 가져와 코드를 배포 할 수는 없습니다. 이는 더 큰 사업입니다. 성공적인 인터뷰 대상자는 이에 착수 할 수 있으며, 필요한 리소스 유형과 그 규모로 구현할 때의 기술적 과제 중 일부는 상태뿐만 아니라 여러 사용자간에 상태를 공유하는 응용 프로그램으로 설명합니다.

Google 문서 도구의 또 다른 흥미로운 점은 여러 사람이 동시에 편집 할 수 있다는 것입니다. 성공적인 인터뷰 대상자는 결과 문서가 가비지 않은지 확인하는 메커니즘에 대해 논의 할 수 있으며, 진정으로 훌륭한 후보자는 편집을 동기화 또는 병합하는 다양한 방법이 성능 및 UX에 큰 영향을 줄 것임을 알게 될 것입니다. 어쩌면 변형도 토론 할 수 있습니다. 코드 작성을위한 공유 문서 편집기는 다른 순서로 발생하거나 약간 다른 구조를 갖는 결과에 다른 결과가 있기 때문에 일반적인 Google 문서와는 다른 충돌 해결 방법을 사용해야합니다.

Google 문서 도구와 같은 앱을 만드는 올바른 방법은 없습니다. 모든 트레이드 오프에 대해 수행 할 작업을 식별 할 필요는 없지만 흥미로운 문제가있는 영역을 찾아서 해당 거래를 명확하게 설명하는 것이 좋습니다 -오프일지도 모른다.

-티.

면접관이 듣고 싶은 것은 :

Google 문서는 워드 프로세서를위한 웹 인터페이스입니다. 사용자 문서는 입력 및 저장되며 동일한 컴퓨터 또는 다른 컴퓨터에서 사용자가 검색 할 수 있습니다.

더 논의하고 싶은 것은 무엇입니까?

그런 다음 공이 면접관에 있습니다. 그녀가 더 자세한 정보를 원하면 요청할 수 있습니다. 면접관이 찾는 것은 문제 나 제품을보고 디자인을 추출 할 수 있습니까?

나를 위해, 핵심 유스 케이스 / 스토리를 식별하는 것으로 시작하지 않으면이 특정 기술을 필요로하는 입장에 대해 준비가되어 있지 않다는 것을 알기에 충분합니다.

이후 주요 사용 사례 / 스토리를 기반으로 아키텍처 솔루션을 개발할 수 있어야합니다. 그들이 모듈을 뽑는 것 이외의 모듈을 식별하기 위해 체계적인 프로세스를 사용했으면 좋겠다 ... 솔루션의 인터뷰 상황에서는 더 이상 기대하지 않을 것이다.

그러나 아키텍처 모듈 중 하나를 선택하고 좀 더 세부적인 디자인을 요구할 수 있습니다. 또한 실패 사례 / 성능 문제를 고려하는 것도 좋을 것입니다. 그러나이 시점에서 우리는 타임 월에 빠질 것이라고 생각합니다. 따라서 시간이 너무 많기 때문에 이러한 문제를 고려하지 않은 것에 대해 실제로 불이익을 줄 수 없었으며 가능한 모든 시나리오를 고려하는 것이 시간 제한 인터뷰 상황에서 예상되지 않는다고 가정하는 것이 합리적이라고 생각합니다.

최근에 엘리베이터 제어 시스템을 설계하라는 요청을받은 인터뷰가있었습니다. 기본적으로 그들은 작업에 대한 귀하의 접근 방식을보고 싶어합니다. 이 질문을 받으면 아마도 당신을 위해 매우 높은 수준의 직업을 가지고있을 것입니다. 축하합니다.

중요한 것은 문제 해결 방법과 제공하는 솔루션의 장점, 그리고 큰 그림 문제를 처리 할 수있는 방법입니다.

한 가지 중요한 것은 요구 사항에 대해 질문 하는 것입니다. 당신의 애완 동물 솔루션이 작동 할 수 있다고 가정하지 마십시오. 예를 들어, 문서를 바로 인쇄하려는 유혹적인 방법을 알고있을 수도 있습니다. 그러나 Google 문서 도구는 직접 인쇄되지 않습니다. 클라이언트가 인쇄 한 PDF를 생성합니다. 따라서 시작하면 문제의 일부가 아닌 문제를 해결하는 데 절반의 시간이 걸리고 고객의 문제를 해결하는 것보다 뜨거운 기술을 사용하는 데 더 관심이 있음을 알 수 있습니다.

이러한 유형의 인터뷰 질문을 처리하려면 관심있는 프로젝트뿐만 아니라 자신의 경험과 거리가 멀다고 생각되는 프로젝트뿐만 아니라 "일이 어떻게 작동하는지"를 이해하는 데 일반적인 관심을 가져야합니다.

이것은 블로그, 기사, http://www.infoq.com , 해커 뉴스 등을 읽는 것을 의미합니다 . 심지어 코딩 공포의 하드웨어 허풍.

읽은 내용의 대부분을 잊어 버릴 것이라는 사실에도 불구하고 (그러한 정보는 개인적으로 귀하의 작업에 연결되어 있지 않기 때문에) "상상력의 씨앗"이되는 약간의 혼란이있을 수 있습니다. 먼 미래에 비슷한 문제가 발생하면 발아합니다.

따라서 면접관은 아마도 당신의 독서 습관 (취미의 일부)에 관심이 있고 임의의 장소에서 아이디어의 씨앗을 수집하는 습관이 있는지 알아볼 것입니다.

이런 종류의 질문을하는 것은 당신의 마음에 대한 통찰력을 얻는 것입니다. 내가 사용하는 일반적인 질문은 프로그래머에게 PacMan을 시뮬레이션 할 수있는 시스템을 설계하도록 요청하는 것입니다.

그리고 네, 먼저 유스 케이스를 찾고 그 사람이 생각하고 있음을 보여줍니다. 그런 다음 멀티 스레딩의 경우 데이터 구조를 먼저 고려해야합니다 (문제에 사용될 수있는 것, 그 다음에 결정 이유가있는 더 적절하거나 구체적인 것).

이것은 선임 개발 직책에서 고려해야 할 사항입니다. 사람들이이 수준의 개발자 경험에서 정렬 구현에 대한 질문에 앉아 대답하는 것은 어리 석고 무의미합니다. 시스템 설계는이 수준에서 기대할 수있는 것입니다.