사람의 디버깅 기술을 확인하거나 평가하는 방법은 무엇입니까? [닫은]

코드를 쉽게 디버깅 할 수있는 사람을 결정하는 기술은 무엇입니까? 얼마 전 내 친구는 비교적 좋은 프로그래머와 인터뷰를했습니다. 프로그래머가 고용되었습니다. 그는 좋은 코드를 작성하고 프레임 워크와 디자인 패턴을 이해할 수있었습니다. 그가 빠진 것은 디버깅 기술이었습니다. 그는 전혀 디버깅 할 수 없었으며 자신이나 다른 사람의 코드에서 문제를 발견하는 것이 그에게 큰 고통이었습니다.

그 이후로 우리는 사람의 디버깅 기술을 평가하거나 추정 할 수있는 방법에 대해 생각하고 있습니다.

첫 번째 질문은 사람이 소프트웨어를 효과적으로 디버깅 할 수 있는지 여부를 결정하는 기술은 무엇입니까?

그리고 두 번째 : 인터뷰 중에 이러한 기술을 테스트하는 방법은 무엇입니까?

사람이 가장 먼저하고 싶은 일은 코드를보고 디버거로 코드를 단계별로 실행하는 것입니다.

아직 행동 계획이없고 디버거 블라인드에 뛰어 든다면 기본적으로 부활절 달걀입니다. 이것은 모든 종류의 문제 해결에 해당됩니다.

인터뷰 상황에서 시스템 작동 방식을 묻고 시스템 기록에 대해 묻는 사람은 문제 해결에 도움 이 될 수 있습니다. 시스템을 먼저 생각하고 역학을 먼저 생각하는 사람은 좋은 문제 해결 방법이 될 수 있습니다.

이것은 복잡한 시스템에서도 마찬가지입니다.

특정 언어 또는 프레임 워크에서 우수한 소프트웨어 개발자의 최선의 방법은 복잡한 문제를 비판적으로 분석하고 언어 또는 프레임 워크에서 우수한 디버깅 기술을 보유하는 능력이라고 주장합니다. 이들은 일반적인 디버깅 도구를 사용하여 높은 수준의 디버깅 능력뿐만 아니라 낮은 수준의 디버깅을 보여줄 수 있어야합니다.

이는 선택한 IDE에서 높은 수준의 디버깅 도구를 보여주는 시나리오를 만드는 것을 의미합니다. 다음과 같은 것을 찾아야합니다.

• 디버그 모드에서 샌드 박스 응용 프로그램 또는 서버 실행 또는 디버깅을위한 심볼이있는 응용 프로그램 빌드

• 원격 디버깅 포트 사용 가능 및 시연 또는 심볼로 작성된 샌드 박스가 아닌 응용 프로그램의 디버깅 (언어에 적용 가능한 경우)

• 중단 점의 전략적 사용

• 중단 점의 사용자 정의 특성, 중단 점의 조건식 (언어에 적용 가능한 경우)

• 변수 값 또는 참조를 모니터링하기 위해 표현식 또는 변수 시계 사용

• 임시 변수 값 또는 참조 또는 포인터 조작을 실시간으로 사용

• 응용 프로그램 흐름을 시작, 종료 및 종료 할 수있는 능력을 보여줍니다.

• 콜 스택의 중요 평가

• 멀티 스레드 응용 프로그램을 디버깅하고 이해합니다.

로그 및 소스 코드 분석, IDE를 사용하지 않고 저수준 디버깅을 수행하는 기능과 같은 도구가없는 다른 디버깅 전략도 시연해야합니다.

나는 당신이 당신의 시스템에있는 버그를 인터뷰의 맥락에서 논의 할 수있는 것으로 증류 해 내고 싶다. 디버거를 시작하고 그를 보자.

그에게 다음과 같은 질문을하십시오.

1. 문제를 어떻게 해결합니까?

2. 복잡한 프로젝트 중 하나는 무엇이며 어떻게 달성 했습니까?

3. 어떤 디버깅 도구를 사용 했습니까?

4. 특정 도구를 선호합니까?

5. 자신의 시나리오의 예를 제시하고 어떻게 대처할 것인지 물어보십시오.

6. 다른 사람의 코드를 작성하는 능력을 어떻게 평가 하시겠습니까?

질문을하여 문제를 해결할 수 있습니다. 그가 특정 기술에 능숙하거나 좋지 않을 위험이 항상 있습니다. 그러나 그가 좋은 학습자라면 많은 도움이 될 것입니다.

프로그래머가 디버깅 할 수 있는지 확인하려면 수정할 코드를 제공하십시오. 코드를 작성할 수 있는지 확인하려는 경우에도 동일한 방법입니다. 그들에게 문제를주고 코드를 작성하도록하십시오.

이제 코드 작성에 문제는 없지만 디버깅을 요청할 때 실패하는 프로그래머에 대해 혼란스러워합니다. 이 사람은 코드 예제를 취소하거나 데이터베이스에서 읽고 쓰는 것과 같은 경험이있는 영역을 고수합니까? 그들이 코드를 처음으로 얻지 않으면 고칠 수 없습니까?

아마도 사람은 디버깅을 좋아하지 않고 노력하지 않습니까? 나는 이것에 능숙하지 않기 때문에 나에게 그것을 요구하지 말아라. 무력을 배웠다.

기존 코드 기반으로 작업하려면 코드를 살펴보고 문서를 작성하고 메모를 작성해야합니다.

디버깅이 실패한 프로덕션 코드를 수정하는 것으로 생각하지만 코드를 작성하는 동안 디버깅해야합니다. 이 사람은 아주 좋은 프로그래머가 아니거나 새로운 코드를 작성하는 것을 선호합니다. 우리 모두하지 마십시오.

다른 사람의 코딩 능력을 결정하는 것과 같은 방식으로 디버깅에 관해 질문하십시오.

주어진 상황에서 버그를 어떻게 추적 할 것인지 "어떻게"물어보십시오.

한 걸음 더 나아가 컴퓨터 앞에 앉아 문제를 디버그하는 것을 지켜보십시오.

나는 종종 후보자들에게 가상의 상황을 주었다. 너 뭐하니? "로그 확인"이라고 대답 할 수 있으며 "문제가 발생한 이후 로그에 기록 된 내용이 없다는 것을 제외하고는 로그에 비정상적인 것이 표시되지 않습니다"라고 말합니다. 그리고 문제 해결 능력을 평가 한 것에 만족할 때까지 계속됩니다.

일반적으로 좋은 적성을 가진 사람도 좋은 디버깅 기술을 가진 사람입니다.

인터뷰 중에 (연령에 따라) 일부 알고리즘과 같은 퍼즐과 같은 과제를 부여 할 수 있습니다. 간단한 방법입니다.

가능하면 일부 작업에서 코드를 인쇄하여 여기에 문제가 있는지 여부와 문제를 해결하는 방법을 문의하십시오.

나는 사람들이 구문을 읽고 수정하는 능력에 초점을 맞추는 난독 한 인터뷰 질문을하는 것을 선호하지 않습니다.

인터뷰 중에 과거에 수정 한 버그와 디버깅에 사용한 단계에 대해 설명하도록 요청하십시오.

그들이 마지막 직장에서 무엇을했는지, 숙제를 할당했는지 등, 문제를 찾기 위해 겪은 일에 대해 설명하게하십시오.

디버깅에서 후보 기술 테스트에 대한 신입 사원 관점과 경험을 공유하겠습니다. 한 번은 3 단계의 인터뷰를 받았습니다. 두 번째 단계는 "실제 사례"였습니다. 나는 그 순간에 더 몰랐다. 거기에서 나는 작동을 멈추고 모르는 시스템이 있다고 들었다. 몇 가지 버그가 뒤에 있습니다.

이전 테스트 환경에 원격 데스크톱으로 배치되었습니다. 아마도 플러그가 뽑히거나 고립 된 환경 일 것입니다. 이 프로젝트는 일부 ASP.NET 컨트롤 및 관련 코드 파일 코드가 포함 된 몇 가지 웹 양식이었습니다. 코드 파일은 dll이 있고 소스 코드와 메소드 설명이없는 일종의 비즈니스 계층을 참조했습니다. Webforms는 기대할 수있는 CRUD 기능을 수행했습니다. 작은 검색 기능도 있습니다. 비즈니스 계층은 SQL 서버에서 Views 및 SP와 통신했습니다.

그들은 다른 수준에서 일부 부품을 부러 뜨 렸습니다. 증상이있는 종이를 받았습니다. "검색 할 수 없습니다" "마지막 업데이트 후 '지역'필드가 사라졌습니다"등. 사용자로부터받을 수 있습니다.

모든 세부 사항을 기억하지는 못하지만 적어도 테이블 필드의 이름이 바뀌어 SP가 손상되어 검색 기능에 사용되었습니다. 이는 VS에 오류가없고 필드 이름을 추적하는 BL 소스 코드가 없음을 의미합니다. Sqlcommand에 대한 SELECT 매개 변수의 철자가 잘못되어 웹 양식이 오작동했습니다. 또한 GridView (자동 생성 열)에서 누락 된 필드 인 필드가 생략되었습니다. ASP.NET 버튼은 복제되고 강화 된 방법이어야하고 버튼을 새로운 방법으로 가리킬 수있는 "잊어 버린"것을 의미합니다.

또한 HTML 태그에서 제목을 사용하는 것이 허용되지 않는 사소한 일입니다. 또한 반대의 ALT 태그는 그것을 필요로하는 컨트롤에서 생략되었습니다. 올바르지 않은 닫힌 html 태그에 오류가 있었지만 오작동하지 않았습니다. 모든 것이 순수한 극장 프로젝트 오류인지 또는 다른 모집을위한 동일한 프로젝트인지 확실하지 않습니다. 나는 묻지 않았다. 물론 난이도는 신입 사원의 필요와 일치해야합니다.

이러한 테스트는 인터뷰 후 디버깅이 어떻게 수행되었는지 확인하기 위해 스크리닝 (추종 안 함)되어야합니다. 그 단계에서 나 자신을 위해, 나는 시험이 조금 어리 석다는 것을 알았지 만 그것이 큰 포인트 일 것입니다. 그것이 아니거나 그렇지 않은 경우, 많은 가치가있는 후보자가 올바른 장소에 있어야합니다.

* 나는 테스트가 후보자 / 내 기술에 입증되었다고 생각한다.
* 외국 시스템 분석
* 최소한의 정보를 사용하여 오류 및 버그 찾기
* 시간이 지나도 스트레스없이 누군가가 당신을 도와주지 않고 코드를 수정 함
* 다른 지식 수준;
** SQL DB 및 저장 프로 시저,
** 프로젝트에서 dll 사용,
** asp.net 기술,
** 계층 구조
** 문제 지향 측면

또한 개발자 환경을 처리하고 Db 서버 관리 도구를 찾고 이해하는 것과 같은보다 명백한 사항도 있습니다. 분명히 종이에는 정말 멋져 보이지만 실제로는 그러한 작업에 멈출 수있는 후보들이 있습니다.

나는 직책과 관련된 실제 문제를 골라서 후보자에게 나에게 제시된대로 제시한다. 물론 나는 그들에게 일반적인 배경과 코드 스 니펫 또는 회로도와 같은 소량의 관련 문서를 제공합니다.

나는 그들에게 그들의 임무는 문제를 해결하는 것이며 그들이 가지고있는 기술적 인 질문에 답변하고 그들이 수행하고자하는 실험의 결과를 말해 줄 것을 제안합니다. 그들이 "여기에 스코프 프로브를 놓을 것"이라고 말하면, 그들이 찾은 것을 추적 할 것입니다. 그들이 printf루프 에 삽입하고 싶다면 절대로 나오지 않거나 (!) 먼저 "7"을 인쇄 한 다음 반복적으로 "5"라고 알려줍니다. 그들이 잡초에서 멀리 떨어져서 의미있는 대답을 할 수 없다면 나는 우리가 잘못된 길을 가고 있다는 것을 인정하고 다른 곳으로 돌아갈 것입니다. 그들이 막히면 나는 앞으로 나아갈 수있을 때까지 주요한 질문을하거나 힌트를 줄 것이다.

내가보고 싶은 것은 질서 정연한 사고 과정, 해결책을 찾기위한 결의, 잘 고려 된 질문과 실험, 이상적으로는 문제의 성공적인 식별입니다. 때때로 나는 누군가가 한 시간의 인터뷰에서 완전히 디버깅하기에 너무 복잡한 문제를 선택하고 결국에는 실제 답변을 제공합니다. 그 시점에서 나는 그들이 "aha"순간과 그 원인에 도달하는 만족과 그 문제에 관여하고 있음을 보여주는 반응을 찾고있다. 최고의 후보자들은 그 시점에서 자발적으로 후속 질문을하여 문제에 대한 그들의 정신지도를 실제로 진행되고있는 것과 연계 시키려고 노력할 것입니다.

널 포인터 참조 또는 + 소스 코드 + gdb로 segfaults하는 간단한 바이너리 (디버그 포함) 기호가있는 컴퓨터에 앉아 충돌의 원인을 찾을 수 있는지 확인하십시오.

응시자가 예비 코드 테스트를 수행하는 경우 인터뷰 중에 코드를 수정하여 버그를 해결하거나 새로운 기능을 추가하거나 더 나은 기능을 추가하도록 요청하십시오. 코드 테스트 사양을 상당히 모호하게 만들면 "버그"가 포함 된 테스트 사례를보다 쉽게 ​​만들 수 있습니다.

작은 코드 스 니펫에서 "버그"를 찾는 것은 매우 인공적인 상황입니다. 퍼즐과 두뇌 티저와 같은 방식으로 도움이 될 것이라고 생각합니다.

보다 포괄적 인 접근 방식은 후보자가 과거에 특정 사건을 인용 한 후 어떻게 디버깅을 수행했는지에 대한 행동 적 질문을하고 후속 질문을합니다.

문제 해결에 능숙한 사람은 IDE의 디버그 기능 이상의 것을 이야기 할 수 있습니다. 버그보고 도구, 최종 사용자 상호 작용, 버그 재현, 로그 파일 분석, 확인은 어떻습니까?

코드 블록을 통해 추적하는 것보다 디버깅에 훨씬 더 많은 것이 있으며 디버깅에 대한 누군가의 숙련도를 평가하면 문제가 해결됩니다.

회사에서 프로덕션 환경에서 실행하는 멋진 코드를 누군가에게 제공하십시오. 미묘한 버그를 소개하도록 요청하십시오. 그들이 왜 그 것을 골랐는 지 물어보세요. 그들이 그것을 찾고 고치는 방법에 대해 물어보십시오.

원래 코드에서 버그를 발견하면 보너스 포인트입니다.

원래 코드에서 버그를 수정할 수있는 경우 두 배의 보너스 포인트.

나는 사람들에게 그들이 추적하고 고쳐야했던 가장 어려운 버그와 그것을 찾아서 고치기 위해 무엇을했는지 설명해달라고 요청하는 경향이있다. 또한 가장 어려운 버그가 초보자만으로는 찾기 어려울 것으로 예상되는 경우 문제 해결 방법이 아닐 수 있습니다 (진입 레벨에 대한 인터뷰가 아닌 한). 그것이 정말로 어려운 일이고 그들이 그것을 추적하려고 할 때 그들의 사고 과정을 묘사한다면, 나는 그들의 기술 수준이 무엇인지 느낄 수 있습니다. 나를 놀라게 한 것은 "헤드 라이트의 사슴"모양을 얻고 그들이 한 일의 하나의 예를 생각할 수없는 수많은 사람들이 복잡하다는 것입니다. 다른 사람이 고치기 어려운 문제를 남긴 사람은 학교 밖을 제외하고는 내가 관심이있는 사람이 아니라는 것을 유감스럽게 생각합니다.

다음과 같은 몇 가지 기술에 무관심한 질문을합니다.

• 근본 원인을 식별하고 버그 (결함)를 해결하기 위해 취한 모든 단계를 수행하십시오.
• 멀티 스레딩 앱을 디버깅하는 동안 콜 스택을 사용하는 방법

이것은 전화 인터뷰에서 특히 효과적입니다. 문제를 해결하는 동안 자신이 실제로 어떻게 작동하는지 보여주는 확실한 답변을 제공하는 사람 만 있으면됩니다.