면접에서 까다로운 문제에 대한 무차별 대입 솔루션을 코딩하거나 면담을 면밀히 조사하는 것이 낫습니까? [닫은]

면접관의 의도 여부에 관계없이 면접 질문이 어려운 경우도 있습니다. 제한된 인터뷰 시간을 사용하여 추악하고 비효율적 인 무차별 대입 솔루션을 코딩하거나 면접관과 관련된 문제의 모든 측면을 이해하는 데 시간을 소비할지 여부를 선택할 수 있습니다.

예를 들어 Project Euler의 91 번 문제는 가능한 모든 삼각형을 계산하고 isRightTriangle () 테스트를 작성하고 테스트를 통과 한 모든 삼각형을 세트로 채우는 어려운 무차별 대입 솔루션으로 해결할 수 있습니다. 그러나 두 쌍의 X / Y 좌표는 상수 값이 높은 O (x ^ 4) 솔루션을 만듭니다. 친구와 나는 방금 훨씬 우아하고 효율적인 솔루션을 생각해 냈지만 우리 둘은 3 시간을 보냈고 수십 개의 다이어그램을 그렸고 여러 공식을 테스트하고 여러 접근법을 검사했습니다.

모든 인터뷰 질문이 공정한 것은 아닙니다. 또한 한 사람에게는 쉬운 것이 다른 사람에게는 어려울 수 있습니다. 누군가가 질문으로 어려움을 겪고 있다면, 당신은 작동하는 무차별 대충 추악한 해결책에 더 감명을 줄 것입니까? 아니면 문제 해결 능력이 뛰어나고 우아한 솔루션을 지향하고 있지만 코딩 된 솔루션은 없는가? 20 분 후에 어떤 식 으로든 코딩을 시작해야하는 규칙이 있습니까?

우선, 숙련 된 개발자 2 명을 우아하게 최적화하는 데 3 시간이 걸리는 질문은 인터뷰 질문에 대한 잘못된 선택입니다. 당신이 그것을 요구한다면, 당신은 완벽한 대답을 기 대해서는 안됩니다.

반면에 때때로 누군가가 한계에 도달하면 누군가에 대해 가장 많이 알게됩니다. 그렇기 때문에 많은 대학 과정이 난이도를 높인 다음 곡선에서 점수를 매 깁니다. 모든 시험에서 모든 사람이 100 % 점수를 얻는다면 많은 잠재적 인 학습 결과를 얻을 수 있습니다.

나의 이상적인 후보는 아마도 복잡도 계산을 먼저 할 것입니다. 그런 다음 면접관이 요청하지 않는 한 반드시 구현하지 않고도 최적화 방법을 논의 할 것입니다.

부분적으로, 이것은 현실 세계에서 발생하는 많은 프로젝트 오일러 유형 문제가 한 번 해결 한 다음 잊어 버려야하는 원샷 문제이기 때문입니다. 내가 고용 한 사람이 쓰기에 2 분이 걸리고 실행하는 데 10 분이 걸리는 무차별 알고리즘을 인식 할 수 있다는 것을 알고 싶습니다. 한 번만 실행하십시오.

채용 관리자로서, 내가 당신 앞에있는 코드의 문제를 해결하도록 요구한다면, 코드 자체를보기 위해 너무 중요하지는 않지만 (중요하지만) 방법과 이유를 확인하기 위해 노력하고 있습니다. 당신은 당신이 한 일을했습니다. 당신이 할 수있는 것들 중 하나는 코드를 작성 하는 것이 아니라 문제 자체의 측면을 조사하여 더 잘 해결하는 것입니다. 그것은 나에게 의미가 있으며 일반적으로 코드에 제시된 솔루션보다 더 의미가 있습니다. 그러나 그것은 모든 사람이하는 방식이 아니며 모든 사람이보고 싶어하는 것이 아닙니다 (실제로 사람들에게 인터뷰 환경에서 코드를 요구하는 것은 거의 없지만 테이블에 문제를 제기하고 의사와 대화하며 때로는 의사 코드가 나타납니다) 그것은 나에게도 좋다 ).

모든 인터뷰 질문이 공정한 것은 아니며, 누군가가 쉬운 것은 다른 환경에서는 어렵고, 그러한 환경에서 그러한 제약 조건을 가지고 있기 때문에 이해하기 쉬운 인터뷰는 일반적으로 코드 솔루션을 찾지 않는 이유입니다. 다시 말하지만, 그것은 중요한 역할을합니다) 오히려 솔루션 프로세스 입니다.

"20 분 후 규칙에 관계없이 코딩을 시작해야합니까?" 나는 문제에 대해 생각하는 아주 짧은 시간 안에 적어도 뭔가 를해야한다고 말함으로써 이것에 대답합니다 더 많은 질문을하거나 해결책을위한 프레임 워크를 스케치하거나 할 수 없다고 말하면서 어디서부터 시작해야할지 모르겠다.

내가 어려운 문제를 당신과 당신이 제공 한 해결책 (시간의 제약과 당신이 가진 것)을 감안할 때 무차별하고 추악한 경우, 나는 그것이 왜 그런지에 대해 일련의 질문을 할 것입니다. 더 우아한 정보로 바꾸는 것은 무엇입니까? 더 많은 정보? 더 많은 시간? 다른 환경? 인 자기 인식과 연락을 왜 당신이 한, 당신이 한 것을 무엇 되지 수행하고, 합리적으로 설명 할 수있는, 내 책에 큰 골드 스타이지만, 그 개발자의 종류입니다 I 찾다. 따라서 "우수한 문제 이해력과 우아한 솔루션을 향한 길"은 나에게도 효과가있을 것입니다.

둘 다 원하지만 한 솔루션에서 "작동하는 코드"를 표시 한 다음 해당 문제를 개선하기위한 잠재적 인 솔루션에 대해 논의 할 수 있습니다.

누군가에게 코드 작성을 요청하고 코드가없는 가능한 솔루션에 대해서만 이야기하고 싶다면 걱정할 것입니다.

당신이 말했듯이, 누군가는 어떤 이유로 든 특정 문제로 어려움을 겪을 수도 있지만, 문제를 해결하는 방법을 알아야합니다. 그들은 운이 좋을 수 있으며 이미 비슷한 문제에 대한 해결책에 대해 들었습니다. 일어난다.

다른 사람이 충분한 코드를 작성하고 토론하는 것을보고 작업에 적합한 지 알아낼 수 있습니다.

20 분 후에 어떤 식 으로든 코딩을 시작해야하는 규칙이 있습니까?

아니요,하지만 업무에 착수하기 전에 20 분 동안 문제를 분석하면 이미 문제가있을 수 있습니다. 인용 한 것과 같은 질문을하는 고용주는 주로 문제에 접근하는 방법에 관심이 있지만, 코딩 문제로 질문하면 코드도보고 싶을 것입니다. 당신의 사고 과정을 통해 그들에게 이야기하십시오 ...

자, 명백한 접근법은 무차별적인 힘입니다. 3 개의 꼭짓점에 대해 직각 삼각형을 인식 할 수있는 방법이 있다면, 두 점과 직각 삼각형을 찾는 원점을 모두 조합 할 수 있습니다. 피타고라스 정리를 사용하여 직각 삼각형을 식별하는 함수를 작성할 수 있습니다. 더 쉽게하기 위해 거리 공식을 사용하여 두 점 사이의 거리를 결정하는 함수도 작성합니다 ...

이러한 기능을 작성하는 데 약 3 분이 소요됩니다. 이제 몇 분만에 이미 기본 지오메트리를 기억하고 실제로 코드 작성 방법을 알고 있음을 보여주었습니다. 또한 이야기 ​​할 내용이 있습니다.

따라서 우리는 분명히 isRightTriangle(p1, p2, p3)함수를 네 개의 for루프 중간 에 놓고 두 변수 포인트 각각에 대해 가능한 모든 선택을 반복 할 수 있습니다. 보자 ... 문제는 50x50 격자의 원점을 포함한 직각 삼각형의 수를 요구하므로 무차별 대입법을 사용하면 각 점의 각 좌표에 대해 50 가지 가능성을 확인할 수 있습니다. 그것은 50 ^ 4 검사입니다 ... 우리가 더 잘할 수 있다고 확신하지만 코드는 분명합니다.

이제 중첩 for루프 를 사용하는 함수 와 isRightTriangle()방금 작성한 함수를 작성합니다. 문제를 해결했지만 면접관이 어디로 가고 있는지 확인할 수도 있습니다. 그들의 목표가 당신이 코드를 작성할 수 있다는 것을 보는 것이라면, 그들은 멈추라 고 말할 수 있습니다. 아마도 그들은 자신이하고있는 일을 알고있는 사람과 이야기를 나누게되어 기쁘고, 얼마나 멀리 갈 것인지 알고 싶어 할 것입니다. 그래서 당신은 계속 ...

제가 글을 쓰는 동안 대칭을 이용할 수 있다는 것이 저에게 일어났습니다. 주어진 직각 삼각형을 45 ° 선 주위에 반영 할 수 있으므로 해당 선의 한쪽에만있는 점 중 하나만 확인하기로 선택한 경우 삼각형에 대해 한 번, 삼각형에 대해 한 번만 찾은 직각 삼각형을 세어 볼 수 있습니다. 그것의 반영을 위해. 수표 수를 반으로 줄입니다. 또한, 지금 살펴보면, 두 점 사이의 거리를 찾기 위해 제곱근을 취하고 있습니다. 그러나 우리는 다시 그 점을 제곱합니다 isRightTriangle().

등등. 다시 말하지만, 그들은 일반적으로 완벽한 솔루션을 원치 않으며 솔루션에 어떻게 도달 하는지를 원합니다. 당신의 사고 과정은 위의 과정과 같을 필요는 없습니다. 단지 큰 소리로 생각할 수 있다는 확신은 많은 것을 의미합니다. 실수를하더라도 땀을 흘리지 마십시오. "음, 난 여기서 난 레일을 벗어난 것 같아요. 한 걸음 물러서겠습니다."

관리자로서, 테스트 코드를 작성하도록 요청하면 다음에 가장 관심이 있습니다.

• 코드 작성 가능 여부
• 코딩 스타일
• 선택한 알고리즘
• 시도가 문제를 이해했음을 나타 냅니까
• 내가 특정 기술에 대해 정말로 뜨겁다면, 당신이 그 기술을 어느 정도 알고 있다는 것을 보여 주었습니까?

첫 번째 항목은 미친 것처럼 보일지 모르지만 놀랄 것입니다 ...

코딩 스타일-괄호를 어디에 두는 것이 아니라 다음과 같은 것을 의미합니다.

• 그 문제를 해결하기 위해 작곡이나 상속을 선택 했습니까? 왜?
• 그 값을 위해 왜 열거 형 대 문자열 대 int (또는 어떤 순열이 적용되는지)를 사용하기로 선택 했습니까?
• 해당 값에 속성, 필드 또는 get / set 메소드를 사용 했습니까? 왜?
• 수업에서 상태를 어떻게 처리 했습니까?
• 상속, 인터페이스 및 람다 작동 방식을 이해하십니까?
• 언어의 매개 변수 규칙을 이해합니까 (ref와 value는 무엇입니까?)
• 단위 테스트를 작성하는 방법을 알고 있습니까?

내가 정말로 신경 쓰지 않는 것은 다음과 같습니다 .

• 컴파일 (필자는 메모장을 주었고 컴파일러는 없다고 가정)
• 하나의 함수에서 두 매개 변수의 순서를 메모리로 알고 있음
• SQL Server 또는 Oracle 연결 문자열을 암송 할 수 있음
• 모든 실수를 지켜 보면서 어깨 너머로 서있는 동안 완벽하게 코딩 할 수 있습니다.

솔직히 말해서, 나는 스타일을 분석하는 도구를 제외하고는 코딩 테스트를 좋아하지 않았습니다.

이 경우 우아한 솔루션을 향한 길은 나쁘지만 완전한 솔루션보다 낫습니다. 두 경우 모두 좋습니다. 문제를 이해하고 실제로 프로그램을 코딩 할 시간이 없어도 문제를 해결하려는 방법을 보여주는 pusdocode를 작성하는 것이 좋습니다.

나는 당신이 실제로 대답이없는 '정답'이 아닌 질문을하고 있다고 생각합니다. 내가 말하는 이유는 전적으로 사람이 질문하는 가치에 달려 있기 때문입니다.

면접관은 하드 코어 실용 주의자가 실제로 무언가를 빨리 작동시키고 시간이 남는 경우 우선 순위가 낮은 활동으로 최적화하는 것을보고 싶어 할 수 있습니다. 면접관이 구글의 채용 관행에 대한 최고의 인상을 남겼고 가장 섹시하고 가장 우아한 알고리즘 외에는 관심이 없으며 "브 루트"와 " 서로의 5 단어 내에서 또한 면접관이 "면접 질문"을 검색하고 5 분 전에 인터넷에서이 문제를 발견했으며 그가 원하는 것을 모를 가능성도 있습니다.

모든 경우에있어 가장 좋은 방법은 면접관이 원하는 내용을 바탕으로 추론 할 수없는 경우 설명을 요청하는 것입니다. 모든 면접 질문이 공정한 것은 아니며 실제로 모든 질문이 좋은 질문이거나 이해하기 어려운 질문도 아닙니다. 인터뷰는 "속도 데이트"와 매우 흡사 한 활동으로, 누군가와 한 시간 또는 두 시간을 보내며 두 사람은 그 시간을 기준으로 다음 시간 동안 함께 일할 것인지 여부를 추측하려고합니다. 5 년 그런 관점에서 살펴본 결과, '규칙'에 대한 귀하의 질문에 대한 답변이 실제로 없다고 말하는 것이 더 분명하기를 바랍니다.

누군가가 당신에게 당신의 역량에 대한 통찰력을 제공하고 그들의 팀과 잘 어울릴 것이라고 생각하는 질문을합니다. 당신은 그들의 팀, 당신이 그들에 대해 아는 것, 면접관의 성격, 그리고 수십 가지 다른 요소들을보고 그들이 대답 할 가능성이있는 답변, 접근 및 프로세스에 대해 최선의 추측을해야합니다. 개인적으로, 나는 당신이 최선의 생각이라고 생각하는 방식으로 접근해야한다고 말합니다. 그들이 당신에게 동의하지 않는다면 어쨌든 상처가 잘 맞지 않았을 수도 있습니다.

면접관은 어쨌든 솔루션 개선을 요구할 것입니다.

"브 루트 포스 솔루션 우선"접근 방식에는 확실한 이점이 있습니다. 이상적인 솔루션을 찾지 못하면 여전히이를 보여줄 수있는 무언가가 있습니다.