코딩 인터뷰에서 ReSharper의 효과 [닫기]

R # 또는 CodeRush를 사용한 사람은 간단한 키보드 단축키로 간단한 구성 (및 복잡한 구성을 리팩토링) 할 수있는 속도를 알고 있습니다. 그러나 이러한 생산성 플러그인으로 인해 인터뷰 중에 능력이 잘못 평가됩니까?

생산적인 코드 작성기 (및 인터뷰에서 첫인상을 얻는 것)의 일부는 좋은 코드를 빠르게 작성하는 것입니다.

두 명의 후보자가 있다면 :

1. 플러그인을 사용하지 않습니다. 그녀는 문제에 대해 생각하고 인터뷰 PC의 스톡 IDE에 앉아 자신과 똑같이 보이고 평소와 같이 1-2 분 안에 코드를 입력합니다. 끝난. 통과하다.

2. 플러그인을 사용합니다. 그는 문제에 대해 생각하고 인터뷰 PC에서 스톡 IDE에 앉아 "fe + tab"이 더 이상 foreach 루프를 자동으로 쓰지 않으며 모든 단축키가 사라 졌다는 것을 알고 있습니다. 그런 다음 키보드를 돌아 다니면서 정상적인 핫키를 치고 이상한 창을 띄워 펄럭입니다. 보통 30 초가 걸리는 것을 쓰려면 3 분이 걸립니다. 끝난. 그들은 때때로 IDE를 둘러싼 길을 모르는 것처럼 보였습니다. 이 IDE에 익숙하지 않아서 IDE 또는 언어에 대한 경험이 많지 않아야합니다. 통과하지만 이름 옆에 'meh'표시가 있습니다.

경험상 면접관이나 면담 관으로서 면담 중에 플러그인을 어떻게 처리합니까? 응시자가 실제로 알고있는 모범 사례는 무엇입니까? 코드를 이해하지 못하고 R #을 목발로 사용하는 후보가있을 수 있습니다. 내장 VS 또는 Eclipse 템플릿보다 훨씬 빠르기 때문에 코드를 알고 사용하고 R #을 사용하는 후보자가있을 수도 있습니다. IDE를 전혀 사용하지 않는 것이 가장 좋습니까? 그들 자신의 PC를 가지고 오게 하시겠습니까? 다른 사람?

나는 최근에 인터뷰에서 후보 2였습니다 . 비표준 키보드와 익숙하지 않은 테스트 프레임 워크가있는 PC에 IDE를 바닐라로 설치하고 단위 테스트를 통해 간단한 Fizz-Buzz 앱을 작성하라는 요청을 받았습니다. 나는 그것을 플러 프했다. 코드를 해킹하려고 시도하면서 어둠 속에서 뒤죽박죽이 된 완전한 멍청한 놈처럼 보였을 것입니다. 말할 것도없이, 나는 입장을 제안받지 못했습니다.

내가 배운 것은 플러그인에 크게 의존한다는 것입니다. 코드를 더 빨리 입력하는 것이 아니라 실제로 코드에 대한 생각 과 코딩에 대한 방식을 결정합니다. 예를 들어, 변수 이름은 사실 후에 변경하기가 어려울 수 있으므로 변수 이름에 대해 매우 신중하게 생각했습니다. 대조적으로, 나는 변수를 어떻게 사용하고 코드를 해킹하고 변수가 무엇인지 알려주고 리 팩터-> 이름 바꾸기를 사용하여 더 적절한 것으로 반쯤 구운 추측을합니다. .

이것이 저에게 유능한 후보가됩니까? 어떤면에서는 그렇게 생각합니다 . 메모장에서 코드를 작성하고 올바르게 컴파일하고 실행할 수있는 사람은 얻을 수있는 모든 IDE 장점이 필요한 나와 같은 사람에 비해 특정 이점이 있습니다. 그런 관점에서, 나는 왜 어떤 회사가 나 같은 툴 헤드를 고용하지 않기로 선택했는지 완벽하게 이해합니다.

다른 한편으로 , 나는 여전히 재능 있고 유능한 선임 개발자입니다. 나는 나에게 어떤 효과가 있는지 배웠고, 나 자신의 약점과 한계를 감안할 때 생산성을 높이는 게으름을 연습한다. 요컨대, 나는 나를 버린 회사와 같은 회사에 실제로 혜택을 줄 수있는 일종의 프로그래머입니다 .

흥미롭게도, 나는 몇 주 전에 또 다른 인터뷰를 가졌습니다. 이전 경험에 따라 추가 도구 나 구매 예산에 대해 질문했습니다. 없었다 둘 것을 (오히려 관대 한) 제공을 거절 나에게 또 하나의 이유를 준 발견 그들이 에 만든 나 .

따라서 Groucho의 말을 인용하자면, " 저는 직원을 위해 저와 같은 사람을 가진 회사에 가입하지 않겠습니다. "

어쨌든 그들이 ReSharper를 사용하도록 허용하지 않는 한 아닙니다.

그들 ( 후보자 )이 원하는 것을 사용하게하십시오. 옛날, 스위스 군용 칼로 월마트를 짓고 접근 할 수 있다는 것을 보여줍니다 . 그들은 그들의 일상 업무에 필요한 것을 사용하려고합니다 (물론 저는 그렇게 희망합니다). 그래서 그들이 인터뷰에서 원하는 것을 사용하게하십시오. 최종 결과는 중요합니다. 그리고 시중에서 구할 수있는 도구와 그 도구를 효율적으로 사용하는 방법을 알고 있고 수동으로 수행하는 도구를 아는 후보자를 훨씬 더 기꺼이 고용 할 것입니다. 이것은 킬러 산업입니다.

ps 예를 들어, Vim (또는 Emacs)을 생각해보십시오-사용자 정의 설정, 플러그인 등없이 사용 하시겠습니까?

나는 ReSharper와 같은 도구가 실제로 당신보다 더 나은 후보자가 될 것이라고 주장합니다.

예를 들어, ReSharper와 같은 것은 당신이 알지 못했을 언어 구성과 문제에 대해 생각하거나 가독성을 높이기 위해 코드를 구성하는 더 좋은 방법에 대해 가르쳐 줄 것입니다. 어떤 의미에서 ReSharper는 나쁜 습관이나 구식 습관으로 돌아가거나 나쁜 종류의 게으름을 악화시키지 않기 위해 슬링 코드에 대한 모범 사례를 잘 활용합니다.

좋은 코더는 기본 구성을 이해해야하지만 수동으로 입력해서는 안됩니다. 좋은 게으른 종류는 도구가 태어나고 거친 작업을 수행 할 수 있도록하며, 대신 시간을 절약하기 위해 문제를 생각합니다. 이것은 전반적으로 더 나은 개발자가됩니다.

인터뷰 과정이 막대기와 돌 칼을 선호한다면 근본적으로 고장 났다고 말함으로써 추론의 선을 완성했습니다.

이것이 사람들에게 IDE가 아닌 화이트 보드에서 코딩하도록 요청하는 이유 중 하나입니다. 경기장을 평평하게합니다. 그리고 사람들은 "오, 으르렁 거리는 사람이 보통 나를 위해 이것을 처리한다"고 말합니다. 내장 된 스 니펫은 루프를 처리하며 화이트 보드에서는 제공 할 수 없습니다. 이 경우 "문구가 바로 있기를 바랍니다. 저는 R #입니다"와 같은 문구를 사용하면 구문 문제가 발생하지 않도록해야 할 것입니다.

화이트 보드에 이해할 수있는 코드를 작성하는 능력이 필요하므로 우리는 어떻게해야하는지에 대한 회의를 가질 수 있습니다. 그리고 물론, 당신이 실제로 당신의 인생에서 코드를 작성한 적이 있는지보고 싶습니다. 인터뷰 내용이 다를 수 있습니다.

좋은 질문 BTW-나는 종종 이것을 숙고했습니다.

숙련 된 도구는 훌륭한 개발자가되기위한 핵심 기술입니다. 개발자 가 IDE를 사용하는 것 보다 메모장에서 코딩 하는 것을 선호 한다고 주장 할 때 항상 알람 벨이 울리는 느낌이 들었습니다 . 그는 제품보다 프로세스에 더 관심이 있음을 시사합니다.

그것은 괭이 대 트랙터로 토양을 경작하는 것을 선호하는 것과 같습니다. 취미 정원사라면 괜찮지 만 경쟁 경제에서 산업 농부로는 지원할 수 없습니다.

그러나 우리는 도구에 의존하게됩니다. 사람들이 도구가 갑자기 사라지는 가상의 상황에서 어떻게 대처할 것인지에 대해 사람들이 놀라워하는 것 같습니다. 계산기를 시험에 허용하는 것과 같은 주장이있었습니다.

실제로는 도구가 매년 더 좋고 나아지고 저렴하며 저렴 해지며 도구가 없을 것이라고 생각할 이유가 없습니다. 도구는 높은 품질로 반복적 인 작업을 수행하는 데 탁월합니다. 즉, 우리는 어려운 호모 사피엔 지능의 힘을 어려운 (그리고 흥미로운) 부분에 집중할 수 있습니다.

ReSharper는 Visual Studio에 추가 된 멋진 기능입니다. 인터뷰를 할 때 현재 회사에 ReSharper가 없었지만 인터뷰에서 그것에 대해 너무 복음 적이 어서 입장을 받아 들였을 때 사본을 사서 인터뷰 한 개발자를 위해 사본을 구입했습니다. 이제 회사 전체에 배포되고 있습니다. 좋은 도구는 전혀 비용을 지불하지 않습니다.

따라서 질문에 답하기 위해 : 도구에 대한 의존성 은 면접에서 자신의 능력을 잘못 평가할 수 있지만 항상 면접관의 능력을 정확하게 평가할 것입니다. 회사가 인터뷰에서 도구 지원의 가치를 인식하지 못한다면, 그들에게 빛을 보여 주어야합니다. 그리고 그들이 여전히 그것을 볼 수 없다면, 나는 그곳에서의 입장을 받아들이는 것에 대해 매우 걱정할 것입니다.