--- name: hiring-prep-coding-test description: 특정 회사의 코딩테스트를 리서치해 플랫폼·형식(라이브 코딩 vs 프로그래머스형 공채)·난이도·빈출 유형·허용 언어를 파악하고, 유형별 실전 문제 링크가 담긴 회사 맞춤 코테 준비 문서를 생성합니다. 기본은 프로그래머스, 부족한 유형은 리트코드로 보강 + 학습 플랜 + 시험 당일 전략 포함. argument-hint: "<회사/공고 URL 또는 회사명 · 직무>" user-invocable: true triggers: - "코딩테스트 준비" - "코테 준비" - "코테 대비" - "코딩테스트 대비" - "회사 코테 준비" --- # 코딩테스트 준비 문서 생성 (Hiring Coding-Test Prep) 특정 회사의 코딩테스트를 리서치해, 그 회사에 맞춘 자기완결형 준비 문서(마크다운)를 만든다. 산출물은 "이 회사 코테를 어떻게 뚫을지"를 담은 실전 가이드다. **리서치 방법론:** `hiring-common/interview-research.md` — 회사 코테 리서치(플랫폼·형식·라이브 여부·난이도·소스 tier). 필요할 때 연다. ## Step 1 · 입력 "준비할 회사/공고를 알려주세요 — 공고 URL·회사명·직무. 지원 형태(신입/경력)와 이미 아는 정보(플랫폼·허용 언어 등)가 있으면 함께." 공고 URL이면 열어 **전형 단계·허용 언어·코테 언급**을 먼저 확인한다. 회사 정보가 전혀 없으면 직무 일반 커리큘럼으로 진행함을 고지. ## Step 2 · 리서치 (핵심) `interview-research.md`를 따라 조사한다. **반드시 판별할 것:** - **플랫폼** — 프로그래머스 / 해커랭크 / 백준 / 자체 등 (과거·현행 다를 수 있음, 최신 우선) - **형식** — 문항 수 · 시간 · 알고리즘/SQL/구현 · **라이브 코딩 여부** - 라이브 코딩은 보통 **공고에 명시**되고 개인 블로그(velog·tistory)에서 확인된다. **프로그래머스로 보면 라이브가 아니다.** → 라이브형/공채형을 명확히 구분해 표기. - **난이도 좌표** — 프로그래머스 Lv / 백준 티어 / 리트코드 난이도로 환산 - **빈출 유형** — 구현·완전탐색·BFS/DFS·DP·이분탐색·구간합 등 + **거의 안 나오는 유형**(투자 금지 대상) - **허용 언어** — 공고 상세요강 기준 (Python 미제공 등 사례 주의) - **평가 방식** — 코테 단독 컷 vs 서류 합산 - Graceful degradation: 후기 없으면 공고+직무 일반 기준으로 폴백하고 명시. 없는 회사 정보를 지어내지 않는다. ## Step 3 · 문제 선별 (매번 새로 리서치) 문제를 **고정 목록에서 꺼내지 않고 매 실행마다 새로 찾는다.** - **기본은 프로그래머스** — 국내 다수의 실제 시험 플랫폼. 회사 빈출 유형별로 문제를 낸다. - **프로그래머스가 약한 유형만 리트코드로 보강** — 구간합·투포인터·이분탐색(답 탐색)·knapsack. 백준은 티어로 안내(링크 오배치 방지). - 유형·난이도로 검색해 실제 문제를 고른다(예: 프로그래머스 '[유형]' Lv2~3, 리트코드 '[topic]' Medium). 회사 기출로 확인된 유형을 **최우선**. - **링크 검증(필수):** 실제 존재하는 문제의 정확한 링크만. 확신이 없으면 **지어내지 말고** 검색 경로("프로그래머스에서 '[유형]' Lv2~3 태그로")로 대체한다. 가능하면 링크를 열어 확인. - 회사 정보가 없으면 직무 일반 유형으로 폭넓게 선별. ## Step 4 · 문서 생성 아래 구조로 마크다운을 출력한다. 회사·직무·Step 2~3 결과로 채우고, 해당 없는 섹션은 뺀다. 0. **핵심 결론 (먼저 읽기)** — 플랫폼·형식(문항/시간/라이브 여부), 난이도 좌표, 빈출 유형, 평가 방식, 허용 언어. 함정·주의 1~2개. 1. **전형·플랫폼 팩트** — 확정 사실 vs 편차(회차·직무). 후기 표(출처·형식·내용). 2. **난이도 좌표** — 프로그래머스/백준/리트코드 환산표 + "반드시 커버" 목표선. 3. **빈출 알고리즘 유형 우선순위** — ★★★/★★/★ + "거의 안 나옴(투자 금지)". 4. **【주】 프로그래머스 커리큘럼** — 빈출 유형별 **3~5개** 문제 링크(Step 3에서 선별·검증한 실제 문제). 5. **【부】 리트코드 보강** — 프로그래머스가 약한 유형만 **유형당 2~3개**. 6. **N주 학습 플랜** — 주차별 목표·할 일 표. 시간 부족 시 최소 조합 명시. 7. **시험 당일 전략** — 문제 배분, 제출 전 자가검증 체크리스트(최대입력·경계·빈입력·격자 엣지·오버플로), 복잡도 먼저 계산, 언어 리스크, 가독성. 8. **출처 & 한계** — 실제 접근한 URL 목록 + 투명 고지(회차 편차, 후기 시점, 링크·허용 언어 원문 재확인 당부). ## 원칙 - **확정 사실과 참고 통념을 구분** 표기한다(리서치로 확인 vs 일반 경향). 교차 확인 2건 이상만 "확정". - **형식·허용 언어·SQL 포함 여부는 공고 원문 재확인**을 문서에 당부한다. - 죽은 링크·지어낸 문제 금지 — 확신 없으면 검색 경로로 대체. - 문서를 만든 뒤 모의로 이어가려면 `hiring-sim-coding-test`(회사 스타일 문제 출제 + 채점)로 안내한다.