여러 가지 상황적 변수를 고려해본 경험 <<< 순수하게 코드를 얼마나 잘 짜는지에 대한 능력
(1) 실무에서 신경써야 하는 요소를 적용할 필요 없음
- 실무 경험에 따른 유불리가 적은 편
(2) 시간과 메모리에 대한 제한 사항 有
(3) 다른 것보다 ‘효율성’에 대해 최대한 고민 必
- 현실적인 문제로 효율성을 포기해야 할 일이 없음
(4) 단, 언어별로 존재하는 한계점 및 특징에 대한 대책을 기억해둘 필요가 있음
코드를 짜면서 필요한 ‘논리’를 끌어낼 줄 알아야 한다.
코드의 작동과 적용상황만 알고 끝내지 말고, 그 코드가 그 상황에 ‘왜’ 적용되어야 하고, 다른 코드보다 그 코드를 사용하는 게 더 좋은 ‘이유’를 공부해야 한다.
문제를 풀면서 이 알고리즘을 ‘왜’ 선택했고, ‘어떻게’ 활용했는지에 대해 끊임없이 생각하고 고민하길. ★
코딩 테스트의 주요 출제 유형
: 배열, 문자열, 재귀, 완전 탐색, 정렬, 해시, 동적 프로그래밍(DP), 탐욕 알고리즘, 스택, 큐/덱, 이진 탐색, 우선순위 큐, 그래프
① 문제를 읽고, 알고 있는 모든 지식을 총 동원해, 충분한 시간과 노력을 들여 문제를 푼다. ★
② 모범 답안에서 풀이 과정을 되짚어가며, 문제 이해 방법 / 내 풀이와의 차이점 / 나의 부족했던 점 등을 생각해본다.
③ 설명이 이해되지 않는 부분은 체크해놓고 과감히 일단 넘기고, 나중에 책을 끝까지 한 번 다 본 뒤에 돌아와 다시 본다.
④ 모범 답안의 풀이를 모두 이해했다면 한 문제를 푼 것이다. 하지만 한 가지 방법이 아닌 여러 가지 방법으로도 풀어볼 수 있으니, 문제에서 제시된 동일한 키워드를 각 풀이에서 어떻게 다르게 풀어나갔는지 분석한다.
평가요소(3가지) : ⓐ 시간 복잡도, ⓑ 공간 복잡도, ⓒ 가독성
‘컴파일 에러’보다 “런타임 에러”가 더 치명적일 것
(1) 존재하지 않는 요소에 접근하진 않았는가 (ex. 인덱스 접근)
(2) 파이썬의 배열 슬라이싱
- [시작(포함O), 끝(포함X), 간격]
(3) 부등호의 경계값 포함 O/X 여부
- <와 ≤의 차이
(4) 연산자 우선순위 문제
- ‘괄호’로 해결 가능
(5) 자료형 변환
(6) 최대치/최소치 검사
- 숫자 제대로 잘 썼는가
(7) 반복문 / 재귀함수의 종료 조건
(8) (계산 문제의 경우) ‘0’ 주의
- 특히, 0으로 ‘나누기’ 금지
[ 논리에 맞는 코드 → 주어진 테스트 케이스를 통과하는 코드 → 모든 테스트 케이스를 통과하는 코드 ]
순으로, 작은 구상에서 큰 구상으로 단계를 지나면서 코드 풀이를 완성하는 게 일반적.
처음 풀어보거나 익숙지 않은 유형이라면 이 과정에서 디버깅과 시행착오를 겪게 되는 건 불가피하다.
하지만 ‘불필요한’ 디버깅과 시행착오를 겪는 시간은 줄여보자.
(1) 프로그램의 순서를 과정별로 ‘모듈화’한다.
- 에러의 책임소재가 있는 범위를 확 좁힐 수 있음
- 모듈화의 ‘정도’는 스스로 적당한 선을 세워보길.
(2) ‘변수’의 사용 범위(상수/전역 변수/지역 변수)를 확실히 명시하기
- 변수의 사용 범위를 파악하지 힘들게 하는 ’한 줄 코딩’ 지양
(3) ‘의미 있는’ 변수 이름 짓기
(4) ‘내부 표준 라이브러리’를 적극적으로 사용하는 습관 들이기
(5) 파이썬에서 지원하는/지원하지 않는 기능을 정확히 파악하기
- 특히, ‘지원하지 않는’ 기능 잘 알아두고, 그 대체 기능을 반드시 알아둔다.