인터뷰에서“C #에 대해 싫어하는 다섯 가지를 줘”라는 질문에 대답하기가 왜 어려운가요? [닫은]

에서 팟 캐스트 73 , Spolsky 조엘과 제프 앳 우드, 다른 과목들, "모든 사람들이 자신이 좋아하는 프로그래밍 언어에 대해 싫어합니다 다섯 가지를"토론

현재 툴 체인에 만족한다면 전환 할 이유가 없습니다. 그러나 좋아하는 프로그래밍 언어에 대해 싫어하는 5 가지를 나열 할 수 없다면 아직 판단 할만큼 잘 모른다고 주장합니다. 대안을 알고 사용하는 것이 무엇이든지 건강하게 비판하는 것이 좋습니다.

궁금해서 인터뷰 한 후보자에게이 질문을했습니다. 그들 중 누구도 C # ¹에 대해 싫어하는 것을 하나도 인용 할 수 없었습니다.

왜? 이 질문에서 너무 어려운 점은 무엇입니까? 인터뷰의 스트레스가 많은 상황으로 인해 인터뷰 대상자가이 질문에 대답하기가 불가능합니까?

이 질문에 대해 인터뷰하기에 나쁜 점이 있습니까?

분명히 C #이 완벽하다는 의미는 아닙니다. 나는 C #에 대해 내가 싫어하는 다섯 가지 목록을 가지고 있습니다.

• 제네릭의 변수 유형이 부족합니다 ( params인수 와 유사 ).
  Action<T>,
  Action<T1, T2>,
  Action<T1, T2, T3>,
        ⁞ 심각 하 게!
  Action<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10, T11, T12, T13, T14, T15, T16>
  

• F #에서와 같이 측정 단위에 대한 지원 부족

• 읽기 전용 속성이 없습니다. private readonly읽기 전용 속성을 원할 때마다 백업 필드를 작성하는 것은 지루합니다.

• 기본값이있는 속성이 없습니다. 그리고 네, 매개 변수가없는 생성자에서 초기화하고 다른 모든 생성자에서 호출 할 수 있다는 것을 알고 있습니다. 그러나 나는 원하지 않습니다.

• 다중 상속. 그렇습니다. 혼란을 야기하며 대부분의 경우 필요하지 않습니다. 매우 드물지만 일부 경우에 여전히 유용하며 혼동이 동일한 이름의 메소드를 포함하는 여러 인터페이스를 상속하는 클래스에도 적용됩니다 (C #에서 해결됨).

나는이 목록이 완전하지 않다는 것을 확신한다. 그리고 강조 할 점이 훨씬 많으며, 특히 나보다 더 좋은 점이있다.

^{¹ 일부 사람들이 .NET Framework의 일부 어셈블리 나 프레임 워크의 일부 라이브러리가 없다는 것을 비판하거나 CLR을 비판했습니다. 질문 자체 는 언어 자체 에 관한 것이기 때문에 중요하지 않으며 .NET Framework의 핵심에 부정적인 영향을 줄 수 있습니다 (예 :에 대한 공통 인터페이스가 없다는 사실과 같은 TryParse경우). 문자열을 여러 유형으로 구문 분석하려면 모든 유형에 대해 반복해야합니다.) JSON 또는 WCF에 대한 답변은 주제가 완전히 다릅니다.}

내가 추측해야한다면 :

1. 일부 프로그래머에게는 다양한 언어 노출이 부족합니다. 더 나은 것들이 존재한다는 것을 모르면 언어에 문제가있는 것을보기가 어렵습니다.

2. 일부 프로그래머는 단순한 코드 원숭이입니다. 그들은 프로그래밍 언어가 어떻게 더 좋을지 말고는 물론, 그들 앞에있는 문제를 간신히 분석합니다.

3. 특히 중요한 사람들은 거의 없습니다. 그들은 단점이 아니라 이점과 기능을 봅니다. 인터뷰가 그런 식으로 진행되지 않으면 사고 방식으로 전환하기가 어렵습니다.

4. 적어도 여기에서, 지나치게 비판적인 것은 치명적인 성격의 결함으로 간주됩니다. '내가 살았던 일부 지역과 같이'일을하는 더 나은 방법을 찾는 통찰력있는 개발자가 아니라 '모든 것을 미워하는 그 놈'입니다. 언어로 싫어하는 것을 생각할 수있는 사람들조차도 인터뷰 환경에서 덜 식욕을 돋 우지 않을 수 있습니다.

인터뷰 중 질문에 대답하기가 너무 어렵다고 생각합니다.

1. 정말 예상치 못한

2. 많은 생각과 인터뷰 중에 사용 된 것과는 다른 방식으로 생각해야합니다.

3. 짧은 시간 내에 (일반적으로 인터뷰 전에 준비하지 않은 경우) 대답하기가 어렵습니다.

1. 예상치 못한

예상치 못한 질문은 특히 스트레스가 많은 상황에서 정말 어렵습니다. 인터뷰 중에 다음과 같은 대화를 상상해보십시오.

HashSet<T>and 와의 차이점은 무엇입니까 List<T>?
hash 해시 셋은 요소 검색이 매우 빠르도록 최적화되었습니다. 예를 들어 set.Contains()루프 내에서 여러 번 사용하는 경우 set목록에서 해시 세트로 이동하면 작업 속도가 빨라질 수 있습니다.
read 읽기 전용 속성을 어떻게 만듭니 까?
‒ readonly게터 만있는 속성에 대해지지 필드로 표시된 필드를 사용합니다 .
‒ 사용법은 sealed무엇입니까?
inherit 상속해서는 안되는 클래스에 사용합니다.
dentist 치과 의사를 마지막으로 본 것은 무엇입니까?
- 뭐?!

2. 다른 생각 이 많이 필요하다

일반적인 인터뷰 유형의 질문을 받으면 기억을 사용하여 책이나 언어 및 프레임 워크에 대한 연습에서 배운 내용을 기억합니다. 답을 찾기 위해 조금 생각할 수도 있지만 너무 많지는 않습니다.

반면에, 당신이 싫어하는 다섯 가지에 관한 질문에는 더 깊은 생각이 필요합니다. 당신은 책에서 배운 것을 기억할 수 없으며 비유로 아무것도 찾을 수 없습니다. 수동적이 아닌 비판을 받고 사용하는 언어에서 무엇이 불쾌한 지 찾아야합니다.

3. 시간이 필요하다

솔직히, 나는 C #에 대해 싫어하는 다섯 가지 (실제로 더 많은) 것들의 목록을 가지고 있지만 오랫동안 그것에 대해 생각했습니다. .NET Framework 2 시대의 몇 가지가 있습니다. .NET Framework 2에 대해 나열된 대부분의 문제는 LINQ 및 일부 기능 프로그래밍 관련 항목, 동적 프로그래밍 관련 사항으로 제거되어 더 이상 유효하지 않습니다. 이 질문을 준비하지 않고 인터뷰 중에 다섯 가지 요소를 모두 찾을 수 있을지 확실하지 않습니다.

단어 5 때문에 어렵다고 생각합니다 . 그리고 증오 라는 단어로 인해 어느 정도까지는 .

다섯 ? 네 가지만 생각해 내면 어떨까요? 질문에 대답하지 못했습니까? 5 명 이상 이면 어떻게 합니까? 이제 그 자리에서 가장 적합한 5 개 중 어느 것을 사용해야하는지 알아야합니다.

증오 는 매우 부정적인 단어입니다. 사람들이 인터뷰에서 피하도록하는 것은 일종의 부정이다. 또한, 나는 많은 것을 그들은 하루 종일 프로그래밍을 지출됩니다 언어에 대한 그들은 "증오"를 가지고 많은 사람들에게 이상한 소리 것이라고 생각 어떤 사람들은 트릭 질문은 생각도 있습니다. 실제로 경우 않는 올 다섯 가지로, C #을 너무 많이 프로그래밍하여 프로그램하기에 너무 부족합니다. 불행히도, 이런 종류의 속임수 질문은 인터뷰에서 들어 본 적이 없습니다.

대신 C #이 자신에게 있다면 어떤 점을 개선 하시겠습니까? 이를 통해 인터뷰 대상자는 여러 가지로 답변 할 수 있습니다. 이 문구는 또한 상대적으로 긍정적 인 "개선"을 위해 "증오"라는 단어의 부정성을 교환합니다.

• 대부분의 후보자들은 대조를 위해 하나 이상의 언어 나 패러다임에 깊이 관여하지 않습니다 . 나는 5 년 이상 다른 객체 지향 언어로 일하지 않았으며 (PowerBuilder)에서 일한 언어가 많이 있었습니다.와 함께. 대학 밖에서 온 신입생들은 대부분 한 언어에서 두 가지 언어로 인기가 있고 (혹은 두 언어로), 3 개 또는 4 개 이상의 "노출"을 받았습니다. 그것을 공부하는 과정). 언어에 어떤 문제가 있는지 실제로 알기에는 지식이나 경험이 충분하지 않습니다. 현실 세계에서 직업을 구하십시오. 그 초점은 상당히 좁아집니다. 당신은 다른 어떤 것보다 월급을받는 언어에 대해 더 많은 것을 배우고, 그 과정에서, 언어가 할 수 없거나 이상한 방식으로 기억하지 못하는 점을 받아들이게됩니다. 다르게하고 있습니다.

• Java / C / C ++와 비교하는 C #에 정통한 대부분의 후보는 그것에 매우 만족합니다 . C #은 처음부터 Java (이벤트, 콜백, 그래픽 라이브러리, 데이터베이스 작업)보다 훨씬 많은 작업을 수행하도록 설계되었습니다. Java는 차례로 사용하기 쉽고 C ++보다 올바른 코드에 더 중점을 두도록 설계되었습니다. 블리 스터링 성능 및 회로 수준 제어가 중요하지 않은 환경에서 C ++로 돌아 가기를 원하는 C # 프로그래머를 아직 만나지 못했습니다.

다시 말해, See-Sharpers는 모든 것을 고려하여 꽤 훌륭합니다.

내 목록은 다음과 같습니다.

• Lambda 문은 감시 / 평가할 수 없습니다 . 명명 된 메소드에 대한 호출은 VS의 QuickWatch에 연결될 수 있습니다. 식도 마찬가지입니다. 그러나 람다? 아닙니다 (적어도 VS2010에는 해당되지 않음). Linq 체인을 디버깅하는 것은 정말 번거 롭습니다.

• string 이외의 참조 유형에 대한 선택적 매개 변수 값은 null 만 가능합니다 . 오버로드 스택을 만드는 경우 다른 기본값을 사용하고 싶을 수 있습니다. 속성 또는 다른 매개 변수를 기반으로 한 간단한 식을 기반으로 한 값을 기본값으로 지정할 수 있습니다. 그러나 나는 할 수 없습니다. 따라서 옵션 매개 변수 옵션이 크게 제한되면 과부하 스택을 만들지 않아도되는 값 (ReSharper와 같은 리팩토링 보조 도구로는 적음)이 줄어 듭니다.

• C #은 심각한 레거시 코드 문제가 발생할만큼 오래되었습니다 . 원래 1.1로 작성된 코드는 4.0에 익숙한 사람은 누구나 공포에 질려 버립니다. 2.0 코드조차도 많이 빠져 있습니다. 동시에, ADO.NET과 같은 것들이 매우 원시적 인 것처럼 보이도록하는 타사 라이브러리가 등장했습니다 (그리고 ADO.NET의 "연결된 모델"의 대부분은 이제 큰 반 패턴입니다). 그러나 이전 버전과의 호환성을 위해 .NET은이 오래되고 나쁜 코드를 모두 지원하며 "ArrayList는 그것을 할 수있는 엉뚱한 방법이었습니다. 대신 List를 사용하고 다양한 유형의 목록이 절대적으로 필요한 경우로 선언하십시오 List<Object>.

• 스위치 문 규칙이 심각하게 제한됩니다 . PowerBuilder에 대해 말할 수있는 가장 좋은 점 중 하나는 Choose Case 문 (스위치와 동일)이 변수를 기반으로 부울 식을 허용한다는 것입니다. 또한 코드가 있어도 switch 문을 통과 할 수있었습니다. 나는 두 번째 것이 허용되지 않는 이유를 이해하지만 (의도적으로 의도하지 않고 의도적으로 수행 될 가능성이 높음) 때때로 다음과 같은 진술을 작성하는 것이 여전히 좋을 것입니다.

  switch(someInt)
  {
      case < 0: //all negative values enter here
         //...
         break;
      case 0: 
         //...
         break;
      case 1:
         //...
         //no break; continue through to the code for > 1
      case > 1 // all positive values enter here (including 1)
         //...
         break;
  }

• INumeric 인터페이스가 없습니다 . 숫자이면 수학으로 할 수 있습니다. 많은 경우에 실제 방법은 정확히 어떤 유형이 연결되어 있는지 신경 쓰지 않아도됩니다. 정확성은 발신자의 책임입니다. 그러나 숫자 유형 만 GTP로 허용 할 수있는 일반 메소드 또는 클래스를 작성할 수는 없습니다.

문제의 일부는 나쁜 대답을하는 것에 대한 두려움이라고 제안합니다 .X를 싫어한다고 말하거나, 면접관은 X를 좋아하거나 X를 싫어하는 이유가 바보라고 생각합니다. 괜찮은 것이 덜 논란의 여지가있는 옵션이라고 생각할 수 있습니다.

또한 대부분의 사람들이 실제로 많은 생각을하지 않은 것입니다. 그들은 현재의 문제와 과거의 문제를 가지고 있으며, 언어가 원인이 된 과거의 문제는 끝났기 때문에 사람들은 주로 해결책을 생각하고 문제가 더 중요하지 않다고 생각하며 언어로 인한 현재 문제는 거의 없습니다.

인터뷰의 경우 1 또는 2 만 요청하지만 사용하는 도구의 제한을 지정할 수 없으면 잘 모르는 것 같습니다. 우리는 SSIS에 관한이 정확한 질문을하는데 그것은 밀과 겨를 분리하는 데 정말로 도움이됩니다. 이 질문에 잘 대답 한 우리 모두가 훌륭한 직원으로 변했습니다. 우리는 사전 지식을 가진 사람이 필요합니다. 그리고 그게 당신이 원하는 것입니다.

나는 그것이 유효한 질문이고 많은 사람들이 대답 할 수 없다는 사실은 많은 후보자들이 실제로 얼마나 가난한 지에 대한 예일 뿐이라고 생각합니다. 누군가 툴의 일부 구성 요소를 파악할 수있을만큼 분석적이지 않다면 어떻게 어려운 프로그래밍 문제를 해결하기에 충분히 분석적인가?

C #에 대한 심층적 인 경험 부족 및 / 또는 다른 언어에 대한 노출 부족이라고 말한 것처럼 들립니다. 나는 C #의 표면에 가벼운 흠집조차도 그들에게 공개해야 할 몇 가지 질문에 대답 할 수없는 선임 자라고 생각한 많은 개발자를 인터뷰했습니다.

충분히 파지 않으면 언어의 한계에 도달하지 못하고 언어가 사라지기를 바랍니다. 누군가 궁금해하는 경우를 대비 한 상위 5 개

1. 불변 객체는 기본적으로 객체가 불변 인 기능적 언어와 달리 많은 의식이 필요합니다.
2. 메타 프로그래밍은 어렵습니다. 유형 방출을 Lisp 매크로와 비교하십시오. (컴파일러 서비스는 앞으로이 작업에 많은 도움이 될 것입니다).
3. 확장 방법은 훌륭합니다 ... 확장 속성과 확장 연산자 (특히 내재적 및 명시 적 연산자)가 더 좋습니다.
4. 명시 적 캐스트는 런타임 대신 컴파일 타임에 해결됩니다.
5. No Sequence Matching 기능 오버로드보다 훨씬 깨끗합니다.

나는 그의 라운드에서 그가 말하는 방식에 대해 생각합니다. 그것이 깨 졌다고 생각하면 아마도 그것이 왜 그런지 이해하지 못할 것입니다. 당신의 지식에는 구멍이있을 수 있습니다.

아이러니하게도, 인터뷰 질문으로 이것을 사용하여 "위대한 조엘"을 인용한다고 생각하는 인터뷰어는 아마도 요점을 놓치고있을 것입니다.

그들은 그들이 언어에 대해 싫어하는 5 가지를 열거 할 수 있다면 면접관이 돌아 서서 '오, 우리는 C #'닌자 '를 찾고 있는데 언어를 좋아합니다. '또는'언어가 마음에 들지 않으면 왜 일자리를 신청 했습니까? '.

인터뷰 대상자는 인터뷰 중에 긍정적 인 태도를 유지해야한다는 압박을 많이받습니다.

언어는 우리가 생각하는 방식을 형성 하기 때문에 . 매일 C #을 사용하면 언어 문제를 자연스럽게 해결할 수있는 방식으로 코드를 생각하고 디자인하는 습관을 들이게됩니다.

당신은 지금 당신이 그것을 모르고, 생각없이 그것을합니다. 이것이 나쁜 것이 무엇인지 지적하기가 어려운 이유입니다. 의심 할 여지없이 C #을 배우기 시작했을 때 많은 문제가 발견되었지만 이제는 더 이상 문제가 표시되지 않습니다. 습관은 강력한 것입니다. 더 습관을 생각하십시오 .

이것의 긍정적 인 측면은 C #의 결함을 나열하기가 어렵다는 것을 알면 C # 프로그래머가 좋고 언어를 좋아하고 다른 언어보다 더 많이 사용하기 때문입니다.

그러나 C #의 결함을 더 많이보고 싶다면 사고 방식을 바꿔야합니다. 더 많은 프로그래밍 언어 배우기 익숙해 지십시오. 가장 다른 언어를 목표로하십시오. 정적 타이핑에 익숙하십니까? 파이썬이나 루비를 사용해보십시오. 당신은 객체 지향적이고 명령적인 것에 익숙합니까? 하스켈은 완전히 다른 세계입니다.

그리고 C #으로 돌아 오면 "하스켈에서 한 줄에 불과한이 간단한 일을하기 위해 왜 100 줄의 C #이 필요합니까?"와 같습니다. C #에 대해 많은 것을 싫어할 것입니다.

• C #에는 nullable이 아닌 참조 형식이 없습니다.
• 대수 데이터 형식이 없습니다.
• 문자열 보간이 없습니다.
• 구문은 모든 곳에서 지나치게 장황합니다.
• 매크로 시스템이 없습니다.
• 형식 유추가 제한됩니다.
• 정규 표현식 리터럴이 없습니다.
• 구조적 타이핑이 없습니다.
• 불변성에 대한 지원이 부족합니다.
• C # 구조체는 오류가 발생하기 쉽습니다.
• 표준 컬렉션 라이브러리는 매우 제한적입니다.
• 생성자의 매개 변수에 대한 제한 조건을 정의 할 수 없습니다.
• 수학 연산자에 대한 제약 조건으로 일반적으로 프로그래밍 할 수 없습니다.
• '새 유형'이 없습니다.
• 배열 슬라이싱, 범위 리터럴 없음.
• 함수는 타입의 일부로 할 수있는 부작용을 나열하지 않습니다. :)

(물론 언어는 모든 것을 가질 수 없습니다. 언어 디자인은 매우 어렵고 모든 언어를 같은 언어로 추가 할 수 없습니다. 다른 목적을위한 다른 도구입니다.)

그렇습니다. 특히 면담 중에 질문에 잘 대답하기가 어렵습니다. 그러나 대답 할 수있는 사람들은 자신이 그것에 대해 생각하고 있으며 일부 관점을 가지고 있음을 증명합니다.