인터뷰 중에 구문 적으로 올바른 것이 얼마나 중요합니까? [닫은]

인터뷰 후보에게 화이트 보드에 프로그램을 쓰도록 요청할 때, 후보자가 구문 상 올바른 코드를 작성할 것으로 기대하십니까?

나는 두 개의 후보자를 가지고 있는데, 그중 하나는 구문 적으로 올바른 프로그램을 작성했지만 논리는 최고점에 도달하지 못했고 다른 하나는 논리를 더 잘 작성했지만 구문은 쓰레기였습니다.

나는 첫 번째 후보를 선호합니다.

나는 문제를 통해 추론하고 좋은 해결책을 찾은 다음 나에게 그들의 해결책을 설명 할 수있는 사람을 선호합니다. 그들의 논리가 100 %가 아니더라도, 올바른 길을 가고 문제를 통해 추론하고, 올바른 질문을하고, 올바른 길을 가고 있다면 그것은 내 승자가 될 것입니다.

작업에서 코드를 개발할 때 구문 및 논리에서 실수를 찾는 IDE, 컴파일러, 정적 분석, 단위 테스트, 통합 테스트 및 승인 테스트 절차 등 많은 도구가 있습니다. 화이트 보드에 작성하는 경우 이러한 도구가 없으며 구문 (오류, 메서드 이름, 세미콜론, 중괄호를 잊어 버림)에 실수를 범해야하며 용서할 수 있습니다.

내 유일한 질문 : 후보자가 알고리즘, 디자인 전략 및 논리적 사고에 중점을 두지 않고 화이트 보드에 실제 코드를 작성하게하는 이유는 무엇입니까? 프로그래밍 언어는 변하지 만 문제 해결은 변하지 않습니다.

나는 두 번째 후보를 선호합니다. 논리는 정확히 맞기 어려울 수 있습니다 ( 매우 어려울 수도 있음) . 구문이 될 수 있습니다 매우 는 IDE 및 컴파일러 및 기타 분류 된 도구를 도울 때 제대로하기 쉽습니다.

첫 번째 후보는 컴파일러 오류를 유발하지 않을 수 있지만 코드가 모든 종류의 이상한 (그리고 덜 이상한) 경계 사례에서 종종 실패하는 경우 세미콜론을 넣을 위치를 아는 것은 그만한 가치가 없습니다.

실제 구문 오류에 따라 구문 검사가 일반적으로 기계에 더 잘 남아 있기 때문에 두 번째 후보를 선호한다고 생각 합니다 .

세미콜론 누락, 괄호 닫기, 인수 목록에서 쉼표 잊어 버림 등과 같은 오류, 함수 호출시 일반적으로 구문 강조 표시기, 컴파일러 또는 코드가 처음 실행될 때 인수 순서 전환과 같은 비구 문적 오류 , 일반적으로 사용하지만 화이트 보드에서는 사용할 수없는 모든 항목이 있습니다.

그러나 기술적으로는 구문 오류 만 있지만 더 많은 오해가있는 일부 오류가 있습니다.

요점을 알 수있는 다소 인공적인 예 : 모든 변수 앞에 $를 붙이거나 for 루프를로 쓰는 파이썬 프로그래머를 고려하십시오 for list as item. 기술적으로, 둘 다 구문 오류이지만 파이썬에 대한 노출이 제한되어 있어도 유효한 문자와 for 루프에 대해 알아야합니다. 후보가 PHP (또는 perl?)를 알고 자신의 파이썬 기술에 대해 허풍을 피우려고한다는 것은 좋은 추측 일 것입니다.

화이트 보드가 로직보다 구문에 더 큰 영향을 미치며 구문 실수는 수정하기 쉽다는 이론에 따르면 IDE 또는 컴파일러가이를 수행 할 수 있다는 두 번째 후보를 선호합니다.

나는 거의 13 년 동안 SQL과 CSS (내가 아는 가장 단순하고 기본적인 언어)를 작성해 왔으며 항상 구문을 기억할 수는 없다.

내 친구 (또한 개발자)는 헤지 펀드를 위해 일하며 삽입 문의 구문을 기억할 수 없습니다.

우리는 둘 다 W3CSchools 을 끝내고 , 우리는 당황해야한다고 생각합니다 (그는 학위를 가지고 있으며 박사 학위가 있습니다).

그러나 솔직히 말해서 우리의 우선 순위가 정확하다고 생각합니다. 구문은 중요한 기술이 아닙니다.

구문 오류에 대한 몇 가지 생각 ... 구문이 모두 정확해야한다는 것을 분명히했는지 궁금합니다. 때때로 사람들은 의사 코드가 정상이라고 가정합니다.

또한 누군가가 언어에 대한 수년간의 경험을 주장하고 기본 구문을 올바르게 만들 수 없다면 주장을 의심해야합니다.

구문 오류는 다양 할 수 있으므로 누군가가 메소드 이름을 잊어 버린 경우 괜찮습니다 (그러나 나에게)하지만 누군가 클래스의 메소드를 참조하는 방법을 모르거나 (점 표기법) 간단한 수업,이 사람이 언어를 오랫동안 사용하지 않았을 가능성이 있습니다.

구문이 정확하지 않은 사람에게는 적절한 언어 편집기를 사용하여 실수를 쉽게 해결할 수 있다고 생각하십니까? 그렇다면 나는 그에게 투표한다.

내가 생각하고있는 것은 구문 오류가 한계 내에서 수용 가능하다는 것입니다.

주니어 보조 프로그래머 나 소프트웨어 툴은 논리가 좋으면 잘못된 구문을 찾아서 고칠 수 있습니다. 나쁜 논리 .. 어떤 수정이라도 확실하지 않습니다. 모든 프로그래머가 망할 것입니다. 망가진 사람을 더 쉽게 찾아서 고칠 수있는 사람을 고를 것입니다.

문제가 미묘하고 대부분의 면접 질문이 아닌 한, 첫 번째 후보자는 실격 처리됩니다. 알고리즘 디자인보다 언어 구문을 배우는 것이 훨씬 쉽습니다. 현재 기술에 대한 경험이없는 경우에도 여러 언어로 성공적인 작업 경력을 가진 프로그래머를 고용 할 것입니다. 오늘해야 할 일이 있다면 이것이 최선의 전략은 아니지만, 앞으로 12 개월 동안 많은 일을해야하는 경우에는 항상 특정 경험보다 일반적인 능력을 선택합니다.

구문 검사는 컴파일러의 목적입니다. 컴파일러는 논리를 향상시킬 수는 없지만 구문을 수정하는 방법을 알려줄 수 있습니다. 즉, 컴파일러를 사용하여 코드를 작성하는 모든 작업에서 논리는 본질적으로 구문 적으로 올바른 것보다 훨씬 더 중요합니다.

인터뷰는 항상 어색한 상황입니다 - 당신이 밖으로 걸을 때, 당신은 즉시 모든 당신이 것들을 생각하기 때문에 당신이 말할 수 있어야 말했다, 또는 질문하고 당신이 그들에게 물어 싶었지만 잊었 것들에 대한 정답. 따라서이를 감안할 때 구문 오류없이 완벽하게 작성된 코드를 기대하는 것은 비현실적입니다.

또한, 완벽한 코드에 대한 귀하의 기대치 (화이트 보드에 있음)는 면접자와 일치하지 않을 수 있습니다. 복사 생성자에서. 그래서 나는 a = b로 설정했지만 아무것도 만족시키지 못했습니다. 문제에 대한 나의 기대는 사본 ctor를 필요로하지 않았으므로 문제가 해결되는 것과 관련이없는 것으로 남겨 두었습니다. 나는 그의 숨겨진 코딩 표준에 따라 완전히 호환되는 컴파일 코드를 작성할 필요가 없었습니다. 솔루션에 대한 나의 이해. (이 똑같은 면접관은 내 솔루션을 좋아하지 않았으며, 그가 그렇게 분명히했을 방법이 아니 었습니다.

인터뷰 대상자의 작업 코드를 원하면 컴파일러에게 제공하십시오. 그들이 당신을 청구 할 때 다음 불평하지 마십시오 :)

따라서 자신이하고있는 일을 아는 사람, 즉 단어를 앵무새로 만들 수 있지만 그 의미를 이해하지 못하는 사람을 찾으십시오.

인터뷰 중에 면접관은 귀하의

1. 문제에 접근
2. 문제를 해결하는 데 사용되는 기술과
3. 효과적인 솔루션을 효과적으로 제공하는 데 걸리는 시간

구문은 그렇게 중요하지는 않지만 문제를 해결하는 동안 중요한 위치를 차지합니다. 구문에 큰 실수가 있으면 면접관에게 깊은 인상을 줄 수 없습니다.

적절한 논리와 구문을 함께 사용하면 인터뷰에서 유용한 정보를 얻을 수 있습니다.

논리가 충분하다면 사소한 실수라도 큰 비용이 들지 않습니다.

더 나아가 적절한 형태의 구문이라도 쉽게 만들 수있는 IDE를 사용할 수 있습니다. 그러나 어떤 방법을 언제 어디서 그리고 가장 중요한 사용하는 이유 만 실제 피사체의 적절한 논리와 지식을 가진 사람에게 알려진 것입니다.

코드를 작성하기 위해 화이트 보드 또는 메모장 이상의 것을 제공하기를 바랍니다.

나는 두 번째 후보 와 함께 갈 것입니다 . ..

어떤 사람들은 훌륭한 Java 개발자, 훌륭한 C # 개발자, 훌륭한 C ++ 개발자 등을 원합니다. 그런 경우라면 A와 더 많은 힘을 얻으십시오. 내가 가진 한 가지 문제는 그들이 문제를 해결할 이유가 없다면 어떻게 비즈니스 문제를 추론하고 해결할 것을 기대할 수 있습니까?

다른 사람들은 필요한 언어로 작업 할 수있는 훌륭한 개발자를 원합니다. 그들은 문제를 생각하고 모델링 한 다음 어떤 언어로든 구현합니다. 갑자기 .NET 흡인을 결정하고 Java로 전환하거나 그 반대로 전환하면 배를 뛰어 넘거나 배우기를 거부하지 않는 개발자입니다. 또한 독점적 인 언어가있는 자동화 패키지 / 계산 패키지 유형이 있고 자동화 된 작업이 필요한 경우이를 수행 할 수있는 개발자 유형입니다. 실제 사례 ... 노인 고용주를 위해 맞춤형 그린 영역의 우편 번호를 추출하기 위해 매핑 소프트웨어 패키지에 대한 맞춤형 독점 스크립팅 언어를 찾아야했습니다. 또 다른 예는 ... 현재 고용주는 보고서 작성을위한 사용자 정의 언어가 포함 된 독점 자산 관리 시스템을 보유하고 있습니다.

또한 화이트 보드에는 추가 압력 / 신경이 있으므로 아무도 최선을 다하지 않습니다. 또한 코딩 할 때마다 완벽하다고 확신합니다. 나는 당신이 컴파일하거나 실행하고 약간의 오류를 발견했다고 생각합니다. 또한 언어에 따라 다릅니다. C는 언어 / 핵심 라이브러리의 대부분을 기억할 수있을 정도로 작습니다 (필요하지는 않지만). Java / C #에는 라이브러리를 암기하는 데 큰 도움이되는 거대한 라이브러리가 있습니다.

또한 여러 언어를 아는 것이 도움이 될 수 있습니다. C #과 Java가 서로 간섭합니다. 그러나 특히 C # / Java 외에 스크립팅 언어 및 기능적 언어를 알고있는 경우 여러 언어를 알면 시야가 넓어 질 수 있습니다.

그래도 두 후보 모두 올바른 논리로 문제를 해결하면 올바른 구문을 가진 사람이 유리할 수 있습니다. 하나는 문제를 해결하고 다른 하나는 해결하지 못하면 개인적으로 문제를 해결할 수있는 사람과 함께 갈 것입니다.

여전히 누군가 Java 전문가라고 주장하고 if 문 또는 while 루프를 사용하여 배열을 선언 할 수없는 경우 거짓말을하는 것일 수 있습니다. 그러나 누군가 Java의 전문가이지만 최근에 많은 C #을 동원하여 Map 또는 무언가를하려고 시도하는 경우 이해할 수 있습니다. 또한 라이브러리의 세부 사항을 얻거나 누군가 myArray 대신 myArray.length를 수행하는 경우 .Length 또는 string.length () / string.Length / string.length 대신 string.length () ... 사소한 것들. 또는 일부 라이브러리 호출의 인수 순서를 잊어 버린 경우. 또는 여기나 거기에 오타 / 세미 콜론이 있습니다 ....

나는 그들 중 어느 것도 가져 가지 않을 것이다.

프로그래머가 문제 해결에 능숙하지 않으면 좋은 구문은 쓸모가 없습니다. 그리고 주어진 언어에 대한 구문이 좋지 않다는 것은 후보자가 특정 언어에 익숙하지 않다는 것을 의미합니다. 직접적인 경험이 부족할 수도 있습니다.

어쨌든 논리는 구문보다 훨씬 중요합니다.

항상 그렇듯이 그것은 다릅니다. 구문 오류가 비교적 사소한 경우 무시합니다. 그들이 지구가 떨고 거대하다면, 나는 그들에게주의를 기울이고 그들이 왜 존재하는지 추론하려고 노력할 것입니다.

나는 논리 오류가 구문 오류보다 나쁘다고 생각한다. 추론 및 확인).

인터뷰 위치와 언어에 따라 달라집니다.

C ++에서 작업하면서 구문을 방해하는 사람이 있다는 것은 무서운 일입니다. C ++은 어두운 구석으로 가득 차 있으며, 트랩은 기본적으로 모든 곳에 배치됩니다. 문법이 더듬 거리는 것은 언어에 대한 표현이 열악하다는 것을 의미하며, C ++ 초보자는 많은 실수를합니다 (다른 사람들이 때때로 그렇지 않다는 것은 말할 것도 없습니다).

질문에 대답하려면 다음을 수행하십시오.

• 간단한 개발자 위치를 채워야한다면 C ++ 구문을 잘 이해해야합니다. 그는 빛나지 않지만 너무 많은 재앙을 유발해서는 안됩니다.
• 리드 개발자 자리를 채워야한다면 어느 쪽도 취하지 않을 것입니다. 수석 개발자는 경험과 논리가 모두 있어야합니다.

하나의 경고가 있습니다 : 경험 부족을 인정하는 사람들. 이상적으로 사람들은 선택한 언어로 코딩하거나 원하는 경우 의사 코드를 작성해야합니다 (예 : 학생).

사실, 나는 직접 손으로 써야 할 때 C # 이벤트의 구문을 잊어 버립니다. 때때로 인터뷰에서 발생합니다. 키보드로 코딩 할 때 문제가 없습니다.

코드를 작성할 수는 없지만 구문을 기억할 수없는 사람을 선택하십시오.

종이 / 화이트 보드에 코드를 작성할 때, 면접에서도 기본적으로 큰 구문을 건너 뜁니다. 나는 세미콜론을 사용하지 않고 메소드 호출을 퍼지합니다. 코드 자체보다 4 줄의 기본 코드를 설명하는 문장을 작성할 가능성이 큽니다. 실제로, 나는 PHP와 같은 의사 코드를 사용하고, 내가하고있는 동안, 내가하고있는 일을 통해 이야기하고, 내가 좋아하는 것들을 설명하기 위해 빠른 주석을 적어 둡니다 (이론적으로 실제로 중요한 것은 아닙니다) 프로그램)

인터뷰에서 코딩 할 때의 목표는 타이피스트가 메모장에 입력하여 실행할 수있는 것을 지시하지 않고 문제를 해결하는 방법을 보여주는 것입니다.

짧은 이야기 : 첫 번째 프로그래머가 왜 까다로운 구문을 사용 했는지 고려해야한다고 생각 합니다. 그는 그것을 잘 알았지 만 인터뷰와 관련이 없다고 생각하고 어려운 부분 (논리적 문제 해결)에 집중하는 것을 선호했습니다.

논리적으로 대답을 충족시킬 수없는 사람은 자격이 없습니다. 업계에 너무 많은 사람들이 가비지 코드를 생성하지만 실제로는 수행해야 할 작업을 수행하지 않거나 오류 또는 엣지 케이스를 처리하지 않습니다.

두 번째 사람은 오류의 유형과 수, 그리고 예상 한 내용의 난이도에 따라 자격이 없을 수도 있고 그렇지 않을 수도 있습니다. SQL 용어 (내가 쓰는 언어)에서 명시 적 조인 구문을 기억할 수없는 사람은 데이터베이스를 쿼리해야하는 작업에 적합하지 않습니다. 예외는 없습니다. 기억에 남는 CTE를하는 방법을 기억할 수없는 사람 (그러나 그들이 존재하는 것을 알고 사용하려고하는 사람)은 아닙니다. 다시 말해서, 나는 당신이 항상 쓰는 기본 코드에 대해 구문이 더 정확할 것이라고 기대하지만 복잡한 구문이 아닌 때때로 수행하는 작업에는 적합하지 않습니다.

내가 아는 사람이 관련 분야에서 우수한 자격을 갖추고 있지만 내 특정 언어에 대한 최소한의 지식 만 가지고 있다고 생각한다면 구문 오류도 더 많이 용서할 것입니다. 차라리 SQL Server 작업을 위해 평범한 SQl Server 개발자보다 훌륭한 Oracle 개발자를 고용하고 싶습니다 (물론 훌륭한 SQL Server 사람이 가장 좋을 것입니다). 오라클에서하십시오. Java 및 C # 사람들과 마찬가지로 문제 해결 능력이 뛰어난 사람은 언어 능력이 뛰어나지 만 항상 승리합니다 (때로는 찾기가 어렵습니다).