프로그래밍 스타일에 대한 인터뷰 질문을 처리하는 방법 [닫기]

인터뷰에서 C ++ 프로그래머로서 반복적 인 상황에서 인터뷰자는 좋은 프로그래밍 스타일에 대한 지식을 조사하기를 원했습니다. 이들은 일반적으로 OOP에 대한 기본 지식을 중심으로 이루어졌습니다.

OOP가 개념을 캡슐화하는 데 유용하며 매일 사용한다는 것을 알고 있습니다. 그러나 C ++과 같은 언어는 많은 다른 스타일을 허용하고 TMP 또는 STL 알고리즘과 같은 일부 C ++ 접근법은 전혀 OOP가 아니지만 (기능적 프로그래밍과 비슷합니다) 다른 접근법에 대한 내 지식을 가장 잘 팔리는 방법에 푹 빠져 있습니다. 거만하거나 기초에 대한 인식없이 누군가를 만나지 않아도됩니다. 요청자의 OOP에 대한 이러한 강조가 OOP가 모든 치료법으로 여겨 졌던 90 년대에 사회화되는 데서 오는 것이라 생각합니다. 그러나 그것은 오만한 입장입니다.

이와 같은 질문을 최대한 활용하려면 어떻게해야합니까?

모든 종류의 질문에 최선을 다해야하는 것처럼 이런 종류의 질문에 최선을 다해야한다고 말하고 싶습니다.

나중에 면접관에게 질문 할 기회가 주어지면 다음과 같은 질문을하여 주제를 제기해야합니다.

• OOP 만합니까?
• 다른 프로그래밍 방식을 사용하는데 팀에서 어떻게 사용할 수 있습니까?

그리고 이런 식으로 여러분은 다른 접근 방식으로 전문 지식을 판매하는 것에 대한 대화를 시작할 수있을뿐만 아니라, 해당 팀 / 회사에서 OOP에 얼마나 엄격하고 얼마나 많은 강조가 제공되는지 확인할 수 있습니다.

asker의 동기에 대해 너무 걱정하지 말고 정직하게 대답하십시오. 인터뷰는 양방향 거리입니다. 당신은 이데올로기 적으로 융통성이없는 회사에 갇히고 싶지 않습니다.

그것은 당신이 면접관의 의도에 대해 약간의 편집증이되고 있다고 생각합니다. 엄청나게 많은 전문 프로그래머들이 OOP의 기본을 이해하지 못합니다. 99 %의 시간에, 면접관들은 당신이 OOP kool-aid를 마 셨는지 보려고하지 않고, 당신이 OOP kool-aid를 마셨다면 그것을 이해하고 싶어합니다. 다른 패러다임이 특정 솔루션에 더 적합하다고 생각하더라도 인터뷰 담당자는 정보에 입각 한 결론이며 OOP에 대해 무지하지 않다는 것을 알고 싶어합니다.

합리화는 누군가가 무언가를 이해하지 못하는 경우 매우 일반적인 방어 메커니즘입니다. 사람들이 개념을 이해하지 못하면 개념이 자신의 무지를 인정하기보다는 어리 석거나 적용 할 수 없다고 주장합니다. OOP가 정답에 대한 좋지 않은 선택이라고 생각하더라도 합리화와는 차별화해야합니다. 에 그렇게 할 수있는 방법은 모두 OOP의 솔루션을 설명 하고 당신이 그 상황에서 가난한 선택입니다 생각하는 이유.

OOP 등의 SOLID 원칙 을 따르는 것이 중요합니다. 코드가 객체 지향임을 보장 할뿐만 아니라 SOLID 원칙에 따라 객체를 대체하는 것이 비교적 간단한 작업입니다. 그것은 당신이 OOP를 알고 있다는 메시지를 보낼뿐만 아니라, 좋은 OOP 코드를 C로 프로그래밍하는 사람이 작성한 해커 복잡한 OOP 코드와 구별하는 것에 대한 미묘한 점을 이해하고 다른 모든 언어는 프로그래밍되어야한다고 생각한다는 것을 보여줍니다 솔직히 말해서 같은 방식으로 OOP를 사용할 수있는 것이 아니라 훌륭한 프로그래머가됩니다.

각각의 중요성과 그 원칙을 무시하는 코드에 발생할 수있는 5 가지 원칙 각각에 대해 철저히 설명 할 수 있도록 준비하십시오.