프로그래머 인터뷰는 항상 커뮤니티에서 기꺼이 토론할 수 있는 뜨거운 주제였습니다. 2006년 인턴십 이후 저는 Fortune 500대 통신회사, 옵션 및 선물 거래에 종사하는 유럽의 중소 금융회사, 대기업을 위해 Android를 개발한 사람 등 모두 외국 기업인 4개의 소프트웨어 회사에서 근무했습니다. 자동차 제조사. 스마트카 스타트업. 저는 IT 업계에 입문한 이후 취업 과정에서 많은 면접을 경험했고, 지난 2년 동안 다른 사람에게도 여러 차례 면접을 본 경험이 있습니다. 이제 이 글은 면접관의 관점에서 프로그래머 면접 질문을 단계적으로 성찰하고 경험을 요약한 글입니다.
목표
저도 많은 친구들처럼 몇 년간의 직장 경험을 쌓고 선배가 된 이후부터 다른 사람들과 인터뷰를 시작했다고 믿습니다. 초기에는 그냥 상상대로 면접 목표를 '기초가 좋은 프로그래머 찾기', '알고리즘이 뛰어난 프로그래머 찾기', '안드로이드 개발 경험이 있는 프로그래머 찾기' 등으로 잡았습니다. 그러나 실제 경험에 따르면 특히 "좋은 기본"과 "좋은 알고리즘"을 목표로 채용된 사람들은 결국 좋은 결과를 얻지 못할 것입니다. 예를 들어, 일부 인터뷰 대상자는 프로세스, 스레드, 메모리 등의 명확한 개념을 갖고 있으며 해시, 이진 트리, 빠른 정렬과 같은 기본 데이터 구조 및 알고리즘에 익숙합니다. 입사 후 실제 업무 성과가 좋지 않습니다. 나중에 보니 면접 대상에 뭔가 문제가 있다는 것을 알게 되었는데, 원래 면접 방식은 대학의 알고리즘이나 운영체제 기말고사에 가까웠고, 이 방식에 따르면 부적합한 사람들이 많이 합격하는 동시에 합격하기도 했습니다. 적합한 사람을 많이 놓쳤을 가능성이 있습니다.
나중에 생각해보니 회사 입장에서는 면접의 근본적인 목적이 '일을 잘 할 수 있는 사람', '고학력', '좋은 알고리즘', '좋은 기초를 갖춘 사람을 찾는 것'이었다. ", "경험이 있다"는 것은 근본적인 것이 아니라 증상이며, "좋은 일"과 직접적으로 동일시할 수는 없습니다.
방법
목표는 분명하지만, 다음 질문은 면접관이 블랙박스 시스템이라고 가정하는 것입니다. '잘했어'는 직접적으로 관찰할 수 있는 변수가 아닙니다. 직접 관찰합니다. 변수는 기초, 알고리즘, 경험, 교육, 성격, 대화, 나이 등입니다. 그래서 사실 '좋은 기초', '좋은 알고리즘' 등 직접적으로 관찰할 수 있는 수량에서만 '잘 작동'할 확률을 추론할 수 있습니다. 이는 'X가 좋다'라는 조건에서 '잘 작동'할 조건부 확률입니다. ". 질문: P(잘했어요 | X 좋아요).
이 모델에 따르면 인터뷰에서 어떤 측면을 살펴봐야 하는지, 즉 가장 두드러지는 측면을 선택해 살펴봐야 한다는 것이 명확하다. 예를 들어 면접관의 체형 특성을 조사하는 것은 별 의미가 없습니다. 잘 했어 | 날씬하다)는 모두 똑같습니다. 따라서 신체적 특성은 차별적이지 않으며 인터뷰에서 중점을 둘 부분은 아닙니다.
면접관은 직위의 요구 사항에 따라 어떤 요소를 더 잘 구별할 수 있는지 결정해야 합니다. 예를 들어, 기술 수준이 상대적으로 높은 3D 게임 엔진 개발 엔지니어를 채용하려는 경우 면접관 A는 3D 게임 엔진 개발 경험이 있지만 면접관 B의 기본 지식 및 알고리즘 면접에서의 성적은 평균 수준입니다. , 기본 지식 및 알고리즘 인터뷰에서 성능이 좋지 않지만 게임 개발 경험이 없으며 둘 중 하나를 선택해야 합니다. 당신은 누구를 선택합니까? 실제로 이는 두 가지 조건부 확률 문제 P(좋은 직업 | 좋은 경험, 평균 기반, 평균 알고리즘)와 P(좋은 직업 | 경험 없음, 좋은 기반, 좋은 알고리즘)입니다. 이 질문은 면접관의 판단에 맡깁니다. 개인적으로 기술 축적이 필요한 높은 기술 수준의 직위의 경우 경험이 더 잘 설명됩니다. 따라서 저는 면접관 A를 선호합니다.
다음에는 제 경험을 바탕으로 인터뷰에서 공통적으로 보이는 점에 대해 말씀드리겠습니다.
알고리즘
알고리즘은 구글, MS 등 대기업 면접의 핵심이다. 저는 개인적으로 알고리즘을 매우 좋아합니다. ACM/ICPC에 참가한 적이 있으며 베이징 대회에서 13위를 차지했습니다. 그러나 개인적인 경험으로 볼 때 제가 접촉한 대부분의 개발 직책에서는 알고리즘이 인터뷰 대상자의 강점과 약점을 평가하는 주요 요소로 적합하지 않습니다. 일반적인 비알고리즘 개발 직책의 경우 면접관의 알고리즘을 테스트하는 것은 그가 탁구를 잘 하는지 테스트하는 것과 같습니다. "잘 했어"라는 목표와의 상관관계가 너무 낮습니다.
제 개인적인 경험으로는 거의 P(좋은 직업 | 좋은 알고리즘) = 50%, 즉 알고리즘 면접은 별 차별성이 없습니다.
특히 좋은 알고리즘을 가진 인터뷰 대상자들 사이에서는 '나무를 자르지 않고 칼만 가는 것'이라는 매우 나쁜 상황도 있습니다. 그것은 무엇을 의미합니까? 어떤 사람들은 A* 알고리즘, 비동기 프로그래밍, JVM 클래스 로딩 메커니즘과 같은 순전히 기술적인 문제에만 관심이 있고 사용자 요구를 실현하는 데에는 관심이 없습니다. 이러한 유형의 사람은 일정한 기술적 능력을 가지고 있는 것처럼 보이지만 회사에 대한 기여도는 매우 제한적이며, 심지어 평균적인 능력을 가지고 있지만 진지하고 책임감 있는 사람보다 열등합니다. 그래서 일단 좋은 알고리즘을 갖춘 면접관을 만나면 그 사람이 '나무를 자르지 않고 칼만 갈는' 사람인지 특별히 주의 깊게 살펴보겠다.
그리고 개인적으로 구글과 MS를 알지는 못하지만, 알고리즘 역량 테스트에 특히 중점을 두는 면접 전략에 회의적입니다. 이런 세계적인 기업에서도 알고리즘은 중요하지만, 프로젝트를 진행하면서 겪게 되는 다양한 문제 중 알고리즘 문제는 대부분의 경우 주요 병목 현상이 되지 않을 것이며, 모든 사람이 필요로 하는 수준까지는 아닐 것이라고 짐작할 수 있습니다. 모두 알고리즘 마스터의 사례입니다. 실제로 대부분의 프로젝트의 실제 어려움은 한두 가지 알고리즘 병목 현상이나 심지어 단일 기술 병목 현상이 아니라 시스템적 구성, 조정, 설계 및 개발 문제가 별로 없어 보이는 문제가 많이 있습니다. 기술적인 부분이 많고, 정보가 부족해서 문제가 많이 발생합니다. 강력한 기술력이 이러한 어려움을 극복할 수 있는 것은 아닙니다. 팀에는 상호보완적인 강점이 있는 것이 가장 좋습니다. 어떤 사람은 알고리즘에 강하고, 어떤 사람은 비즈니스 분석에 강하고, 어떤 사람은 백엔드 서비스에 뛰어나고, 어떤 사람은 프런트엔드 인터페이스에 능숙합니다. 이것이 최고입니다. '알고리즘이 좋다'라는 단일 기준으로 인재를 선발한다면 분명 수많은 우수한 인재들이 배제될 것이다.
기초
기초 면접은 포인터 사용, 프로세스 및 스레드 개념과 같은 기본 지식을 검토하는 인터뷰를 의미하며 대학 기말 시험 문제와 매우 유사합니다. 예전에는 기본적인 면접이 매우 중요하다고 생각했는데 지금은 그렇지 않습니다. 직장에서는 기초가 정말 중요하지만, 면접 과정에서는 의미가 있도록 차별화되어야 합니다. 즉, P(Good Job | Good Foundation) 확률이 높다는 것입니다. 그러면 포인터의 사용과 차이점을 살펴보십시오. 프로세스와 스레드 사이에는 기본적인 질문만 의미가 있습니다. 제 실제 경험으로는 기본 면접은 알고리즘처럼 거의 P(좋은 직업 | 좋은 기초) = 50%에 불과합니다. 동시에 기본 면접은 준비가 가장 쉽습니다. 중국인은 오랜 시험 중심 교육 경험을 가지고 있기 때문에 몇 가지 질문을 준비하는 것이 너무 쉽습니다.
그런 면접관을 만난 적이 있는데, C 언어에 대한 기본 지식과 컴파일 및 링크의 원리가 매우 훌륭해서 인터뷰에 대한 나의 결론은 다음과 같았습니다. 범위가 넓지 않고 C언어만 알지만 기초가 탄탄한 저를 채용하는 것이 좋습니다. 이후 사건을 통해 그 결론의 전반부는 맞았지만 '취업 추천서'는 틀렸다는 것이 증명됐다. 그는 실제 작업이 엉망이었고 요구 사항이나 전반적인 아키텍처를 이해하지 못했고 동시에 작업 시간은 프로젝트에 소비되지 않고 "프로그래머의 자기 개발"과 같은 책을 읽는 데 소비되었습니다. 결국 이 동료는 장기간의 '비활동'으로 인해 회사를 떠났습니다.
기초가 중요하지 않은 것은 아니지만, 면접관이 일을 잘할 수 있다는 것을 보여주기에는 '좋은 기초'만으로는 충분하지 않습니다. 기초는 부분적인 지식인 반면, 실제 업무에는 포괄적인 능력이 필요하며, 둘 사이의 큰 차이. C 언어와 운영체제는 시험에서 높은 점수를 받을 수 있지만, 여전히 대학에서 프로그램을 작성할 수 없는 사람이 그렇게 많지 않습니까? 소프트웨어 개발은 집을 짓는 것과 같습니다. 종합적인 능력은 디자인과 뼈대이며, 기본 지식은 코딩 벽돌입니다. Zhang Xiaolong은 원래 Delphi에서 Foxmail을 개발했지만 C#을 모릅니다. .NET 이메일 클라이언트를 개발할 사람을 모집하려면 그 사람이 CLR을 잘 이해하고 있는지 확인하는 것이 합리적입니까? Zhang Xiaolong이 C# 버전의 Foxmail을 개발하는 것이 정말 어려운가요? C#에 능숙하지만 이메일 클라이언트 개발 경험이 없는 사람을 채용하는 것이 정말로 장샤오롱보다 더 신뢰할 수 있을까요?
기초 지식이 중요하지 않다고 말하면, “한 걸음도 구덩이 없이는 천리도 갈 수 없다”는 옛말과 모순되는 걸까요? 모순이 없습니다! '와부'와 '첸리'는 누적 관계를 갖고 있지만 '기본 지식'이 아무리 많아도 '종합 능력'이 될 수는 없습니다. 학습 소프트웨어 개발은 처음에는 완전한 시스템이어야 하며 규모가 크지 않고 문제도 많지만 점차 작은 시스템에서 큰 시스템으로 진화합니다. 단순한 시스템부터 복잡한 시스템까지.
따라서 좋은 기초만으로는 너무 많은 문제를 설명하기에는 부족하며, 종합적인 능력을 추가적으로 검토해야 합니다. 기본 면접에서 좋은 성적을 내지 못한 면접관에 대해서는 시간이 허락한다면 추가 조사를 실시해야 합니다. 일부 면접관은 실제로 능력은 있지만 준비가 충분하지 않습니다. 물론 가장 이상적인 상태는 기본능력과 종합능력을 모두 고려하는 것이 불가능하다면 종합능력을 우선시해야 한다.
경험
여기에 언급된 경험은 근무 연수로 측정되는 것이 아니라 주로 면접관의 경험, 예를 들어 소프트웨어를 완전히 구현했는지 또는 메인 개발자가 프로젝트를 완료했습니다. 경험의 중요성은 개인의 전반적인 능력을 설명하는 능력에 있습니다. 프로젝트의 성격, 규모, 난이도 등을 통해 면접관은 면접관의 전반적인 능력을 대략적으로 판단할 수 있습니다. 면접관이 대기업에서 소형 모듈의 개발 및 유지 관리 업무를 담당했다면 기본적으로 단독으로 또는 메인 개발자로서 프로젝트를 수행할 능력이 없고 유사한 업무에만 적합하다고 판단할 수 있습니다. 다른 대기업에 있는 것들. 장기간의 기술 축적이 필요한 높은 수준의 직책의 경우 Linux 커널 개발, JVM 개발, 게임 엔진 개발, 데이터베이스 구현, 고급 UX 등 관련 경험이 더욱 중요합니다. 이러한 직위의 경우, 경험이 부족한 면접관이 전반적인 자질이 우수하더라도 자격을 갖추기까지는 오랜 시간의 연구와 축적이 필요합니다. 따라서 기본적으로 귀하의 직위가 이 범주에 속한다고 판단되면 관련 경험이 의심할 여지 없이 첫 번째 선택 요소가 되어야 합니다. 즉, P(좋은 직업 | 좋은 관련 경험)의 확률이 매우 높습니다.
기본 및 알고리즘 테스트보다 프로젝트 경험을 통해 면접관의 장점을 판단하는 것이 더 신뢰할 수 있습니다. 따라서 인터뷰 과정에서 면접관은 면접관이 프로젝트 경험과 수행을 소개하는 것을 듣는 데 더 많은 시간을 투자해야 합니다. -면접관의 지식, 사고력, 표현력 등을 이해하기 위해 토론하고 소통합니다. 동시에 프로젝트에 기반한 몇 가지 기본 지식과 알고리즘 질문을 할 수 있습니다. 예를 들어 면접관이 C++ 관련 프로젝트를 수행했다면 메모리 관리 방법을 물어볼 수 있습니다. 스마트 포인터에 대해 잘 알고 계시나요? 면접관의 대답이 만족스럽지 않다면 기본적으로 그의 프로젝트가 그다지 잘 진행되지 않고 있다고 판단할 수 있습니다.
경험 역시 다차원적인 것이라는 점에 유의해야 합니다. 예를 들어 C++ 주식 거래 미들웨어 시스템에는 세 가지 차원(C++, 미들웨어 및 주식)이 포함됩니다. 면접관 A가 C++ 주식 거래 클라이언트에 대해 작업했고, 면접관 B가 C의 주식 거래 미들웨어에 대해 작업했다고 가정합니다. 언어적 관점에서 볼 때 A가 가장 적합합니다. 프로젝트 성격의 관점에서 볼 때 B가 가장 적합합니다. 어떻게 선택합니까? 여러 차원 중에서 어느 차원이 더 중요하냐는 질문입니다. 이 예에 관해서는 미들웨어 개발 경험이 주요 모순이라고 생각하고 C에서 C++로 전환하는 것은 문제가 되지 않기 때문에 개인적으로 B를 선호합니다. 따라서 면접관은 어떤 경험이 일차적인 경험이고 어떤 경험이 부차적인지를 판단해야 합니다. 예를 들어, 우리는 Android 애플리케이션 개발자를 모집하고 있습니다. 이 직위에 대한 Android 기술 기준은 높지 않습니다. 실제로 좋은 사용자 경험(UX)을 만드는 데 있습니다. 따라서 면접관이 Android 경험이 없어도 괜찮습니다. 하지만 UX 경험이 있고 최소한 다른 플랫폼용 모바일 애플리케이션 개발을 했으면 좋겠습니다.
성격
이제 제가 가장 중요하게 생각하는 요소인 성격에 대해 말씀드리겠습니다. 이것은 면접을 처음 보는 많은 친구들에게는 상상도 할 수 없는 일입니다. 어떻게 성격이 가장 중요할 수 있습니까? 솔직히 저는 이 사실을 알고 깜짝 놀랐습니다! 직설적으로 말하면 P(Good Job | Good Personality)가 확률이 가장 높다. 제가 실제로 경험한 바에 따르면, 좋은 성격을 가진 사람은 좋은 일을 할 가능성이 가장 높습니다. 좋은 성격은 좋은 기반과 좋은 알고리즘보다 훨씬 더 신뢰할 수 있습니다.
기술적으로 부족하고 경험이 부족하더라도 성격이 좋으면 팀 내에서 다른 사람들이 그 자리를 채우기 쉽고, 그 사람도 점차 채워지기 쉬울 것입니다. 반대로 성격이 나쁘면 기술과 경험의 장점이 모두 발휘되지 않거나 부정적인 영향을 미칠 수 있으며 성격의 단점은 바꾸기 어렵습니다. 저는 실무에서 요구되는 것은 종합적인 능력이고, 이러한 종합적인 능력을 키우려면 인성이 중요하다고 늘 말해왔습니다. 프로젝트에는 기술적인 문제가 발생할 뿐만 아니라 의사소통과 조정도 필요합니다. 다양한 사람과 다양한 부서가 협력과 마찰을 겪게 됩니다. 이러한 문제를 해결하려면 좋은 성격이 필요합니다. 개발팀에서 당신을 특별하게 만드는 것은 당신이 졸업한 학교나 과거 경험이 아니라 당신의 성격이라고 말할 수 있습니다.
물론 성격은 여러 측면을 포함하는 복잡한 요소로, 프로그래머 인터뷰에서 모든 측면을 중점적으로 다룰 필요는 없습니다. 내 경험에 따르면 다음 측면을 조사하는 데 집중할 수 있습니다.
1) 태도가 긍정적입니까, 부정적입니까? 일부 면접관은 대화를 통해 자연스럽게 긍정적이고 의욕적인 느낌을 주거나 그들의 경험에서 긍정적인 요소를 찾을 수 있습니다. 오히려 일부 면접관의 부정적인 감정을 분명히 느낄 수 있습니다. 긍정적인 태도는 직장에서 매우 중요합니다. 긍정적인 사람은 팀에 활력을 불어넣고 협력을 더 쉽게 만듭니다. 기본적으로 면접관의 태도가 긍정적이라고 판단되면 합격할 가능성이 크게 높아지며, 반대로 면접관의 태도가 부정적이라고 판단되면 나는 매우 조심할 것이다. 기술력이 좋습니다.
2) IQ. 내 경험에 따르면 전반적으로 똑똑한 사람들이 직장에서 더 나은 성과를 낸다. 인터뷰에서 그 사람이 똑똑한지 테스트하려면 구글이나 MS처럼 IQ를 테스트하는 특별한 지능 질문을 반드시 찾을 필요는 없다. 사실 그 사람이 문제를 매우 논리적으로 논의하는지, 생각이 있는지만 보면 된다. 그리고 빠르게 판단할 수 있습니다. 또한, 눈은 인간의 영혼을 보여주는 창입니다. 사람이 똑똑하든 그렇지 않든 눈은 말할 수 있습니다. 그러나 똑똑하다는 것이 전적으로 장점이 되는 것은 아닙니다. 예를 들어, 회사나 프로젝트에 어려움이 닥치면 똑똑한 사람들이 먼저 도망가고, 평균 IQ를 가진 사람들은 남는 경향이 있습니다.
3) 언어 표현 능력. 프로그래머에게 있어 언어 표현 능력은 프로젝트의 원활한 의사소통과도 직결되는 매우 중요한 자질입니다. 면접관은 자신이 진행한 프로젝트를 간결한 언어를 사용하여 명확하게 소개할 수 있는지, 핵심 내용을 파악할 수 있는지, 청취자의 관련 배경을 고려할 수 있는지 확인할 수 있습니다. 일반적으로 언어 표현 능력이 뛰어나다고 해서 전반적인 능력이 떨어지는 것은 아닙니다.
4) 사용자 인지도가 있는지 여부. 어떤 사람들은 프로그래머가 연구개발을 한다고 하는데, 사용자는 어디에 있습니까? 영업 및 마케팅 담당자만이 사용자를 상대합니다. 사실 이것은 완전한 오해입니다. 당신은 모듈이나 API를 작성하고 다른 사람이 그것을 사용하는 한 그들은 당신의 사용자입니다. 일부 프로그래머는 항상 사용자의 관점에서 모듈이나 소프트웨어를 고려하고 이를 사용자에게 최대한 편리하게 만드는 데 익숙합니다. 사용자 인식이 좋은 사람들은 단순히 자신과 지역의 관점에서 문제를 생각하기보다는 다른 사람의 감정과 전반적인 요구를 더 잘 고려할 수 있습니다. 면접관이 과거 프로젝트 경험에 대해 이야기할 때 면접관은 종종 사용자의 관점에서 질문을 하고 그 과정에서 사용자 인식이 좋은지 관찰할 수 있습니다.
5) 의심과 압박감에 대처하는 방법. 면접관은 면접관의 답변과 과거 프로젝트에 대해 합리적으로 질문하여 그가 어떻게 반응하는지 확인해야 합니다. 한 인터뷰어가 게임 로그인 서버 구축 경험에 대해 이야기한 적이 있는데, 저는 "로그인 서버가 실패하면 어떻게 해야 합니까?"라고 물었습니다. 그는 원래 이 문제를 고려하지 않았지만 어떤 식으로든 개선할 수 있다고 말했습니다. 사실, 프로젝트에 여러 가지 불완전함이 있다는 것을 모두가 이해하고 있으며, 여기에는 많은 이유가 있습니다. 의심과 압박감을 침착하게 처리하고 좋은 방향으로 생각하고 해결하기 위해 열심히 노력할 수 있다면, 그럴 필요는 없습니다. 결점을 은폐하고 감정이 없어야합니다. 인터뷰 대상자들을 만나보니, 자신의 프로젝트에 대해 질문을 하면 곧바로 반항하거나, 불만스러워하거나, 문제가 있음을 인정하지 않는 모습을 한 눈에 봐도 알 수 있다. 직장에서 질문하고 비판하는 사람들과 협력하기가 어렵습니다.
6) 성격 특성. 많은 면접관들이 이력서에 "C++/Linux에 능숙하다"라고 적는 것을 좋아합니다. 누군가 "C++/Linux처럼"이라고 쓰면 눈이 밝아지는 느낌을 받습니다. '숙련'은 감정이 없는 서술형인 반면, '좋아요'는 면접관의 성격을 담고 있는 것 같아요. 나는 무언가에 대한 진정한 열정이 현재의 숙달 수준보다 훨씬 더 중요하다고 믿습니다. 실제로 N년간의 경험을 통해 같은 반의 학생들과 같은 프로젝트 팀의 동료들이 매일 같은 지식을 배우고 같은 일을 하더라도 실제로는 모두의 성적과 성과의 차이가 매우 극명하다는 것을 알 수 있습니다. 의. 그렇다면 본질적인 차이점은 무엇입니까? 사실 그것은 모든 사람의 성격입니다. 어떤 사람은 여가 시간에 공놀이를 하고, 어떤 사람은 여가 시간에 책을 읽고, 어떤 사람은 리눅스를 좋아하고, 어떤 사람은 맥을 좋아하게 만드는 것이 성격이다. 팀에서 개인의 역할은 그의 성격과도 많은 관련이 있습니다. 면접관은 지원자의 성격이 드러나도록 지도하고, 그것이 팀에 도움이 되는지 판단해야 한다.
요약
마지막으로 내 경험은: 1) 면접관의 목표는 '일을 잘하는' 사람을 찾는 것이고, 면접은 이 목표를 중심으로 진행되어야 한다는 것입니다. 2) 면접을 알고리즘이나 운영체제에 대한 최종 시험으로 보는 오해 2) 면접 과정은 면접관이 학력, 인성, 기초, 경험, 경력 등 테스트 가능한 요소를 통해 '일을 잘할' 확률을 종합적으로 판단하는 것입니다. 알고리즘 3) 다양한 요인 중 성격 > 경험 > 기반 > 알고리즘. 성격이 가장 중요합니다. 성격이 좋지 않으면 모든 기술 능력이 크게 저하되고 기술 결함은 보완하기 쉽지만 성격 결함은 경험이 사람의 종합적인 능력을 반영하므로 판단할 수 있습니다. 어떤 종류의 작업을 수행할 수 있고 수행할 수 없는가? 기본과 알고리즘은 주로 보조 참조 역할을 합니다. 기본이 좋은 프로그래머는 일반적으로 더 적응력이 뛰어나고 새로운 기술을 더 빨리 배울 수 있지만 판단하지 않는 것이 중요합니다. 오로지 기본에만 충실한 사람.