압력이 가해질 때 용액으로 점프하는 것을 피하는 방법은 무엇입니까? [닫은]

특히 엄격한 프로그래밍 마감 시간 (예 : 1 시간)을 겪을 때 전혀 패닉 상태가되면 실제 계획없이 코딩에 뛰어 드는 경향이 있습니다. 충분한 시간이 주어지면 효과가있을 수 있지만, 인터뷰에서 반 생산적이지 않더라도 상당히 성공하지 못했습니다. 나는 시계가 똑딱 거리는 동안 항상 거기 앉아 생각하는 것이 편하지는 않다.

코딩을 시작하기에 충분히 문제를 이해했을 때 인식 할 수있는 점검표가 있거나 기술이 있습니까? 몇 가지 실험을 코딩하고 더 많은 코드를 생각하고 디자인하는 것이 언제 가장 생산적인가?

다음은 수학 시험 과 구술 시험을 위한 기술 목록입니다 . 압력을받는 프로그래밍 문제를 처리하는 비슷한 기술 목록이 있습니까?

답변 : 이것이 올바른 답변이라고 생각합니다 : 그것을 해결하는 방법 . 솔루션으로 해결하거나 접근 하기 위한 단계에 대한 답변으로이 링크를 찾았습니다 . 에서 정말 좋은 팁이 있었다 정말 인터뷰 최선의 전략 중에 큰 소리로 생각은? . TDD에 대한 위대하고 간결한 주장은 TDD 작성 코드에 대한 첫 번째 대답과 문제에 대한 답을 찾는 것입니까? .

나는 불 마셜이 불 현장에 도착했을 때 어떻게 행동 계획을 형성하는지에 관한 연구를 읽는 것을 기억한다. 이 연구는 아이디어를 내놓은 것을 관찰하고 정죄 한 다음 첫 아이디어를 즉시 추구했다. 시간의 압박으로 인해 "이것은 효과가있을 것"과 "확인하자." 이 연구는 더 좋고, 더 빠르고, 더 안전한 옵션을 이용할 수 있다고 말했지만, 마샬이 먼저 생각하지 않았기 때문에 단순히 따라 가지 않았다.

"화재"를 다루기위한 구조화 된 접근 방식을 원한다면 여러 단계를 규정하는 (새로운) 책에서 잎을 꺼내십시오.

RRAPID

1. 반응-사고에 대한 리소스 동원
2. 정찰-상황에 대한 데이터 수집
3. 감사-최상의 시나리오와 최악의 시나리오를 기반으로 행동 과정을 선택하십시오.
4. 계획-행동 과정을 기반으로 계획을 개발
5. 주문 발행-표준 브리핑 형식 사용
6. 배포-실행 및 모니터링

또는 더 일반적인 용어로 :

1. 모든 사람을 깨우고 움직이게
2. 무슨 일이 일어나고 있는지 운동
3. 브레인 스토밍 솔루션
4. 하나를 선택하고 계획
5. 자신의 직업이 무엇인지 모두에게 알리십시오
6. 실행 및 모니터링

나는 항상 요구 사항을 이해하고 대답이 필요한 요구 사항을 찾는 것으로 시작합니다.

그런 다음 가능한 두 가지 또는 세 가지 해결책을 스케치합니다 (매우 대략 종이 또는 화이트 보드에). 그리고 나 자신에게 묻습니다. "이것들을 구현하기 위해 알아야 할 다른 것이 있습니까?"

초기 질문이 있으면 (100 %의 질문이 있고,없는 경우에는 요구 사항을 자세히 보지 않은 것입니다.) 이해 관계자로 돌아가서 답변을 얻습니다.

나는 그들의 답변을 쓰고있는 동안 내 솔루션을 고려하고 질문에 대한 답변을 얻은 후에 다른 솔루션보다 나은지 또는 더 나은지 확인합니다. 예를 들어 질문이 얼마나 빨리 필요한지 즉시 알 수 있다면 개발 속도가 가장 빠르지 만 나중에 디자인을 개선 할 수있는 방법을 열어 둘 수 있습니다. 그들이 성능이 중요하다고 말하면 솔루션을보고 어떤 솔루션이 더 성능이 좋을지 결정합니다 (이 시점에서는 추측이지만 일반적으로 정보를 제공합니다). GUI가 관련된 경우 몇 가지 다른 디자인의 종이 프로토 타입을 구성하고 이해하기 쉽도록 이해하기 시작합니다 (보통 그들은 XYZ에 대한 정보를 잊어 버렸습니다. 디자인!)

일단 답변을 받으면 거친 디자인을 선택한 다음 구현하기 위해해야 ​​할 모든 일의 목록을 작성합니다. 그런 다음 코딩을 시작합니다.

... 내 경향은 실제 계획없이 코딩에 뛰어 들어가면서 내가 알아낼 수 있기를 바랍니다.

나는 대학에있는 동안 이것을했다. 실제 문제가되었으며 일반적으로 코드를 다시 작성하게됩니다. 나는 코드를 작성하지 않음으로써 이것을 해결하기 시작했다. 나는 그 문제에 대한 생각을 강조했다. 충분히 연습하면 키보드가 아닌 본능적으로 생각에 도달 할 수 있습니다.

... 면접에서 반 생산적이지 않더라도 꽤 성공하지 못했습니다. 나는 시계가 똑딱 거리는 동안 항상 거기 앉아 생각하는 것이 편하지는 않다.

인터뷰 내에서 솔루션에 대한 합리적이고 신중한 구현이 있어야하며 항상 쉬운 것은 아닙니다. 당신이하고 싶지 않은 것은 생각없이 대답을 흐리게합니다. 답을 알고 있다면 신속하게 답변하십시오. 그렇지 않다면, 당신의 생각에 의존하여 해결책을 추론하십시오. 솔루션을 찾는 방법을 모르는 경우 항상 표시하고 설명하십시오.

코딩을 시작하기에 충분히 문제를 이해했을 때 인식 할 수있는 점검표가 있거나 기술이 있습니까?

나는 당신이 그것에 단단히 의존 할 수 있기 때문에 그런 것을 권장하지 않습니다. 오히려 코딩을 시작하기에 충분히 문제를 이해했는지 스스로에게 물어보십시오. 당신은 어떻게 알겠습니까? 당신이 당신의 접근 방식을 추론하고 검토 할 때, 당신의 언어에 대한 당신의 현재 지식이 주어진다면, 그것은 의미가있을 것입니다. 항상 계획과 접근 방식이 있습니다. 또한 코드는 완성되지 않았으며 진화하지 않은 코드는 죽을 수 있으므로 코드로 자주 돌아올 것으로 예상하십시오.

몇 가지 실험을 코딩하고 더 많은 코드를 생각하고 디자인하는 것이 언제 가장 생산적인가?

전반적인 디자인을 알고 생각할 수 있습니다. 그런 다음 클래스 구조와 스텁을 작성하기 시작합니다. 그런 다음 다시 검토하십시오. 말이 되나요? 코딩 실험은 무언가 잘 작동하는 것을 보여줄 수있는 좋은 방법이며 사용하는 코드를 작성하거나 코드를 작성하는 데 의존해서는 안됩니다.