최근의 인터뷰에서 나는 인터뷰 자들에게 “신기술과 라이브러리 (예 : SignalR)를 평가하고 그것들을 사용하게하려면 어떻게해야합니까?” 그들은 그렇지 않다고 말했습니다. 대신에 모든 것을 스스로 작성하므로 다른 사람에게 의지 할 필요가 없습니다.
이 회사는 정부 나 국방 계약 업체 나 안전에 중요한 프로젝트 나 그와 비슷한 일을 위해 일하지 않습니다. 그들은 평균적인 중간 규모의 소프트웨어 개발 회사 일뿐입니다.
제 질문은 팀이 모든 것을 스스로 작성하는 것이 얼마나 흔한 일입니까? 팀이 걱정해야합니까?
편집-대부분의 모든 응답에서 이것이 우려되는 부분이라고 말했습니다. 두 번째 인터뷰는 집안에있는 모든 것을 쓸 때 자신의 입장을 분명히하고 / 반복하도록 요청하기에 적절한 시간입니까?
답변
타사 라이브러리를 사용 하지 않는 태도 는 터무니 없습니다. 코드베이스의 모든 행이 회사 직원이 작성해야하는 엄격한 비즈니스 요구 사항이없는 한, 모든 것을 직접 작성하는 것은 회사 시간을 끔찍하게 사용하지만, 이는 특히 민간 기업과 같은 특이한 시나리오입니다. 당신은 설명했다.
보다 합리적이고 철저한 답변은 다음과 같은 타사 라이브러리 만 사용한다는 것입니다.
- 그렇지 않으면 스스로 작성하는 코드의 요구를 충족
- 회사의 비즈니스 모델과 호환되는 라이센스에 따라 사용 가능
- 포함 된 테스트
- 코드 검토 통과
이러한 기준이 충족되면 (그리고 제 경험상 코드 검토가 특히 우수한 테스트가있는 경우 매우 유연합니다) 더 이상 “다른 사람에 의존하지”않습니다. 암호.
코드가 오픈 소스 인 경우 최악의 경우 타사 라이브러리는 유지 관리되지 않습니다. 그러나 누가 신경 쓰나요? 테스트 결과 라이브러리가 사용자의 요구에 적합하다는 것이 입증되었습니다!
또한 기존의 타사 라이브러리로의 혐오감은 프로그래머의 생산성을 심각하게 저해합니다. 회사가 웹 애플리케이션을 작성하고 있고 (예를 들어) jQuery 사용을 거부했다고 가정 해 DOM 조작을 단순화하기 위해 자체적 인 교차 브라우저 라이브러리를 작성했습니다. 거의 확실하게 우리는 그들의 구현이 다음과 같다고 가정 할 수 있습니다.
- jQuery에 이미 익숙한 개발자에게 외국 API가있을 것입니다.
- jQuery만큼 잘 문서화되지 않습니다
- 라이브러리 사용시 문제가 발생했을 때 관련 Google 검색 결과가 없습니다.
- jQuery만큼 필드 테스트되지 않습니다.
이러한 모든 점은 프로그래머의 생산성에 큰 장애물입니다. 기업은 어떻게 그런 생산성을 포기할 수 있습니까?
질문을 업데이트하여 두 번째 면접에 도움이되는지 물었습니다. 절대적으로 그렇습니다.
첫 번째 인터뷰에서 면접관의 답변을 잘못 해석했을 수도 있고, 면접관이 회사의 입장을 잘못 설명했을 수도 있고 새로운 면접관이이를 명확히 할 수도 있습니다.
외부 라이브러리에 대한 입장에 대해 우려하고 있다고 설명하면 가능한 두 가지 결과가 있습니다.
- 그것들은 변화하기에 개방적이며, 그들의 과정에 대한 당신의 관심은 다른 후보들보다 당신을 더 좋아 보이게 만듭니다.
- 그들은 변화에 개방적이지 않으며, 당신을 “우리가 고용하고 싶지 않은 종류의 개발자”라고 생각합니다. 중요하지 않습니다, 그것은 당신이 어쨌든 일하고 싶은 곳이 아닙니다.
답변
엄청나게 경쟁적이지 않은 것 같습니다. 나는 Hibernate와 같은 표준 오픈 소스 라이브러리를 건너 뛰고 “치명적인”누락 된 기능으로 인해 자체 롤업하기로 결정한 상점에서 일했다. 결국 소프트웨어는 구축 및 유지 관리 비용이 엄청나게 비쌌습니다. 물론 사내 도서관의 비용은 크게 과소 평가되었습니다. 사내 라이브러리가 작성되는 동안 표준 라이브러리는 빠르게 발전하여 사내 라이브러리에서는 사용할 수 없었던 새로운 기능을 추가했습니다. 결국 표준 라이브러리를 사용하는 데 1 시간이 걸리는 작업에는 이틀이 걸렸습니다. 그리고 세상이지나 가면서 개발자의 경력에 나쁜 영향을 미쳤습니다. 나는 그런 가게를 피할 것입니다. 나는 전달하는 것을 좋아하며 재사용 할 수있을 때 다시 써야 할 인내심이 없습니다.
답변
가게에는 Not Invented Here 라는 질병이 있습니다 . 즉석에서 인터뷰를 종료하고 즉시 떠나는 것이 좋은 이유입니다. 이것은 일어날 가능성이 거의없는 하향식 집 청소로만 치료할 수 있습니다.
당신의 질문에 대답하기 위해, 그것은 당신이 생각하는 것보다 슬프게도 훨씬 더 일반적이며 그것은 반드시 걱정해야 할 이유입니다.
답변
예, 확실히 걱정하십시오! 그것은 오만과 어리석은 말입니다. 두뇌가 절반 정도 인 프로그래머는 signalR과 같은 라이브러리를 직접 작성하는 대신 사용합니다. 이미 해결 된 문제를 해결하는 데 시간을 낭비 할 필요는 없습니다. 나는 아마도 더 많은 정보를 먼저 찾으려고 노력할 것입니다-그들은 당신을 오해했을 수도 있습니다 (면접이 끝나면 어려울 수 있습니다!)
답변
나는 여기에 증후군을 발명하지 않은 소프트웨어 하우스에서 일하는 두 명의 친구가 있습니다 . 그래서 마음가짐이 있습니다.
그들이 한 관찰은 개발팀에서 배양 한 접근 방식의 문화에 관한 것이었다. 그들은 둘 다 소프트웨어 개발에 대한 전망 측면에서 상당히 고립 된 사람들과 실제로 새로운 것을 배우고 품질을 추구하도록 이끌지 않은 사람들과 협력했습니다. 경력의 어느 단계에 관계없이 항상 동료로부터 새로운 것을 배울 수있는 곳에서 일하고 싶습니다. 그러나 이러한 종류의 환경은 일반적으로 모든 것을 스스로 롤링하려는 곳에서 발견되지 않는 것 같습니다.
답변
내가 사는 곳은 흔하지 않으며 동료를 통해 많은 회사를 알고 있습니다. 나는 그것이 바로 “감사하지 않는다”고 말하기까지했다.
나는 이미했던 좋은 점들을 되풀이하지 않을 것이지만 한 가지를 추가 할 것이다.
그들은 방금 고용을 훨씬 더 어렵게 만들었습니다.
- 모든 신입 사원은 소프트웨어 / 도메인의 주요 부분보다 학습 곡선이 훨씬 가파 릅니다.
- 최고의 후보자들은 그들의 기술이 사용되지 않기를 원하기 때문에 연기 될 것입니다.
- 사람들이 자신이 좋아하는 도구를 사용하지 않는 것이 얼마나 나쁜지 알게되면 직원들은 오래 머 무르지 않을 것입니다.
당연히 도전을 좋아하는 사람들이있을 것입니다. 그러나 나는 그들이 소수에 있다고 생각합니다.
마찬가지로 “인터넷 규모”, 아마존, 페이스 북 등에서 운영하는 일부 회사는 사용자 지정 요구가 미치지 만 소수의 회사도 있습니다.
답변
저는 소프트웨어 회사가 타사 및 / 또는 오픈 소스 소프트웨어에 의존하지 않고 오늘날에도 살아남을 수 있다고 생각하지 않으며, 경쟁력을 유지하기 위해서는 물론 새로운 기술을 적극적으로 추적해야합니다. 그러나 적어도 그것에 대해 다소 방어적인 견해를 취하는 데에는 충분한 이유가 있습니다.
예를 들어, 소프트웨어를 판매하고 연중 무휴 24 시간 지원을 제공한다고 주장하고 소프트웨어가 올바르게 작동하는 데 대한 법적 책임이있는 경우, 문제가있는 경우 발생할 수있는 일에 대한 매우 정확한 아이디어가 필요합니다. 예를 들어, 1 시간의 생산 중단 시간이 수백만 달러에 달하는 공장에서 소프트웨어를 사용하면 사용중인 오픈 소스 라이브러리에 심각한 버그가 발생합니다. 나를 믿으십시오. 문제가되는 소프트웨어에 대해 매우 철저한 평가를 수행 할 것입니다.
당신이 작성한 것으로부터,이 시나리오는 문제의 핵심이 아닌 것 같습니다.