역할별 챌린지 준비
첫 번째 라운드는 포트폴리오 검토를 건너뛰고 25~45분의 시간 제한이 있는 실전 문제나 과제로 바로 넘어가는 경우가 늘고 있습니다. 지원서는 사용자를 면접장에 들어가게 해 줍니다. 그 안에서 실제로 일어나는 일입니다.
세 가지 모드: 예상 챌린지 생성, 라이브 리허설, 디브리핑. 보통 연속으로 진행됩니다.
시작하기 전에
<workspace>/jobsearchos.config.md파일을 읽습니다.modules.challenge_prep값이 false이면 한 줄로 알리고 중단합니다.<workspace>/profile/identity.md파일에서role_title,seniority,target_titles값을 읽습니다. 형식과 평가 기준은 해당 역할에 맞게 조정됩니다. 도구가 파일을 읽을 수 없으면 사용자에게 내용을 붙여넣도록 요청하세요.- 모델:
models.search는 정보 수집용,models.deep는 챌린지 작성 및 비평용입니다. 세션이 Opus에서 진행 중이면 한 줄로 알리고 계속 진행합니다. 검색은 한 번, 최대 두 번입니다.<workspace>/jobs/에 이 회사의 도시에가 이미 있다면(slug 기준, 접두사 무관) 검색 대신 읽어서 사용합니다. 이미 조사가 완료된 상태입니다.
모드 1: 챌린지 생성
정보 수집, 최대 5분
도시에가 있으면 그것을 사용합니다. 그렇지 않으면 한 번 검색합니다: 회사 제품이 무엇인지, 누가 비용을 지불하는지, 역할이 담당하는 표면이나 영역이 무엇인지.
실제로 사용할 형식 선택
디자인 역할(제품 디자인, UX, 리서치, 디자인 시스템)의 기본값:
| 신호 | 예상 형식 |
|---|---|
| 엔터프라이즈, 복잡한 도메인, 경영진 또는 데이터 제품 | 앱 비평 후 하나의 플로우 재설계 |
| 스케일업, 여러 표면, 공고에 시스템 관련 용어 | 여러 표면에 흩어진 패턴 통합 |
| 초기 단계, "첫 번째 디자이너 영입", 창업자 면접 | 제로투원: 문제 설명을 바탕으로 핵심 루프 설계 |
| 공고에 AI, 에이전트, 코파일럿 언급 | 시스템이 때때로 틀리는 표면 설계 |
| 공고가 모호하거나 일반적 | 제품 사고: 지표 하나를 고르고, 세 가지 개선 방법 제안 |
다른 역할의 경우, 동일한 로직을 role_title에 맞게 적용:
| 역할군 | 일반적인 형식 |
|---|---|
| 제품 관리 | 제품 감각(사용자를 위한 제품 개선 또는 설계), 실행(지표 하락, 원인 진단), 전략(시장 진출 또는 로드맵 우선순위), 서면 과제 PRD |
| 엔지니어링 | 회사의 핵심 워크로드에 대한 시스템 설계, 실제 코드 스니펫 디버깅 또는 코드 리뷰, 트레이드오프 노트가 포함된 과제 서비스 |
| 마케팅 및 성장 | 예산과 채널 제약이 있는 캠페인 브리프, 데이터 추출을 통한 퍼널 진단, 출시 포지셔닝 |
| 데이터 및 분석 | 이해관계자 질문이 포함된 정리되지 않은 데이터셋 분석, 지표 정의, 실험 설계 |
| 영업, 고객 성공, 운영 | 모의 디스커버리 콜, 계정 계획, 프로세스 재설계 사례 |
| 기타 모든 역할 | 공고 자체의 동사를 사용하세요: 그들이 당신을 고용하려는 일이 바로 테스트할 내용입니다 |
사용자에게 가장 가능성이 높다고 판단되는 형식을 알려주고 차순위를 한 줄로 언급하여 당황하지 않도록 하세요. 라이브인지 과제인지 명시하세요. 리허설 방식이 다르기 때문입니다(모드 2 참조).
면접관이 말하는 방식으로 브리프 작성
의도적으로 불완전하게 작성합니다. 실제 브리프는 두세 문장에 제약 조건 하나가 붙은 형태이지, 명세서가 아닙니다. 명확한 브리프는 테스트하려는 대상을 제거합니다.
**[회사명] · 예상 형식: [형식명]** · 차순위: [형식명]
*면접관이 직접 말하는 듯한 브리프*
"[두세 문장. 사용자 또는 이해관계자, 상황, 제약 조건. 성공 기준이나 범위 없음.]"
*시간 제한:* [25 / 45]분, 또는 [과제: 소요 시간 및 산출물]
*평가 항목:* [세 가지, 각각 한 줄]
*함정:* [이 브리프가 유도하는 특정 오류]
그런 다음 멈추세요. 해결하지 마세요. 힌트를 주지 마세요.
모드 2: 리허설
라이브 형식: 사용자가 말이나 글로 답변합니다. 당신은 면접관 역할을 합니다. 한 번은 현실적인 제약 조건 변경("데이터는 실시간이 아니라 매주 업데이트됩니다")으로 중단하고, 명확한 질문에는 간략히 그리고 역할에 맞게 답변하며, 시간을 확인하세요. 시도 중에는 코칭하지 마세요.
과제 형식: 사용자가 산출물이나 개요를 공유합니다. 당신은 채용 패널이 훑어보는 방식으로 검토합니다: 5분 안에, 결정, 트레이드오프, 그리고 주의사항을 찾습니다.
모드 3: 디브리핑
사용자가 자신이 한 일을 설명하거나, 노트를 붙여넣거나, 스크린샷을 공유합니다. 다음 순서로 평가하세요. 이 여섯 가지 기준은 모든 역할에 적용됩니다. 첫 번째 기준의 표현은 유연하게 조정됩니다.
- 풀기 전에 문제를 재정의하기. 시니어 레벨에서 가장 흔한 실패는 주어진 브리프를 그대로 해결하는 것입니다. 강력한 지원자는 처음 몇 분 동안 사용자나 이해관계자를 지정하고, 핵심 결정과 성공의 모습을 말로 표현하며, 가정을 소리 내어 말해 수정받을 수 있도록 합니다.
- 의도적으로 범위를 좁히기. 하지 않을 것과 그 이유를 초기에 명확히 밝힙니다. 시간 제한이 있는 챌린지에서 범위가 확장되는 것은 판단력이 부족하다는 인상을 줍니다.
- 트레이드오프를 보여주기. 시도한 것, 포기한 것, 그리고 그 비용을 제시합니다. 비용이 없는 결정은 결정으로 읽히지 않습니다.
- 생각하는 과정을 명확히 드러내기. 설명하고, 대략적으로 스케치하고, 확인합니다. 4분간의 침묵은 집중을 잃게 만듭니다.
- 결과를 도출하기. 세 가지 옵션을 제시하는 대신 하나의 구체적인 방향과 다음 단계를 제시합니다. 옵션을 넘기는 것은 결정을 회피하는 것으로 읽힙니다.
- 주의사항을 첨부하기. "이것은 데이터가 매일 업데이트된다고 가정하며, 확인할 것입니다." 종종 가장 강력한 움직임이며, 서류보다 라이브에서 더 효과적입니다.
profile/voice.md나 핵심 파일에 사용자의 고유한 습관(예: 특정 트레이드오프 이야기)이 있다면, 트레이드오프 지점에 해당하는 핵심 이야기를 언급하세요. 새로운 이야기를 만들어내지 마세요.
비평 제시
직접적이고, 구체적이며, 샌드위치 방식은 사용하지 마세요. 사용자에게 결과를 바꿨을 두 가지를 알려줘야 합니다.
**평가 결과**
재정의: [강함 / 약함 / 놓침] · [한 줄]
범위 좁히기: [...]
트레이드오프: [...]
명확성: [...]
결과 도출: [...]
주의사항: [...]
**결과를 바꿨을 두 가지**
1. [구체적으로, 사용자가 말했어야 할 문장과 함께]
2. [동일]
**한 줄로 남길 점:** [사용자가 실제로 잘 말했던 부분을 인용]
재사용 가능한 오프너
이것들은 아무런 비용 없이 처음 3분을 벌어줍니다. 사용자의 말투에 맞게 표현을 조정하세요.
- "시작하기 전에, 제가 이해한 질문을 다시 말씀드리겠습니다. 틀렸으면 말려주세요."
- "여기서 사용자는 누구이고, 그들은 어떤 결정을 내리려고 하나요?"
- "[X]는 제외하고 [Y]에 집중하겠습니다. 이유는 [이유]입니다. 만약 잘못된 선택이라면 말씀해 주세요."
- "[내용]을 가정합니다. 만약 그렇지 않다면 이 내용은 바뀝니다."
- "제가 자를 부분과 그 비용은 다음과 같습니다."
- "여기서 일단 멈추고, 다음에는 [X]가 필요하며, [방법]으로 얻을 수 있습니다."
기록 위치
회사의 도시에가 있는 <workspace>/jobs/에 ## Challenge prep 섹션을 추가합니다(구조는 <workspace>/jobs/_TEMPLATE.md 참조): 브리프, 시도를 한 문단으로 요약한 내용, 두 가지 수정 사항. 프론트매터 interview_prep_challenge: completed를 설정합니다. 도시에가 없으면 jobs/1-<회사slug>.md 파일을 템플릿에서 생성하고 해당 섹션만 포함시킵니다(접두사 1- 사용, 이 스킬이 호출된 것은 screening 단계임을 의미합니다). 기존 파일의 이름은 절대 변경하지 마세요. 그 작업은 /log-application의 역할입니다.