meghnesium/preparacao-desafio

Preparação de desafio por cargo

Primeiras rodadas cada vez mais pulam a apresentação do portfólio e vão direto para um problema ao vivo com tempo limitado, geralmente 25 a 45 minutos, ou um take-home. A candidatura coloca o usuário na sala. Isto é o que acontece nela.

Três modos: gerar o desafio provável, ensaiá-lo ao vivo, fazer o debriefing. Geralmente em sequência.

Antes de tudo

1. Leia <workspace>/jobsearchos.config.md. Se modules.challenge_prep for falso, diga isso em uma linha e pare.
2. Leia <workspace>/profile/identity.md para role_title, seniority e target_titles. O formato e a pontuação se adaptam a esse cargo. Se sua ferramenta não conseguir ler arquivos, peça ao usuário para colá-lo.
3. Modelos: models.search para reconhecimento, models.deep para escrever o desafio e a crítica. Se a sessão estiver no Opus, diga isso em uma linha e continue. Uma pesquisa, no máximo duas. Se existir um dossiê para esta empresa em <workspace>/jobs/ (correspondência por slug, qualquer prefixo), leia-o em vez de pesquisar: a pesquisa já está feita.

Modo 1: gerar o desafio

Reconhecimento, no máximo cinco minutos

Use o dossiê se existir. Caso contrário, uma pesquisa: o que o produto faz, quem paga, qual superfície ou área o cargo controla.

Escolha o formato que eles realmente usarão

Padrão para cargos de design (product design, UX, pesquisa, sistemas de design):

Sinal	Formato provável
Empresa, domínio complexo, produto executivo ou de dados	Crítica de aplicativo, depois um redesign de um fluxo
Scaleup, múltiplas superfícies, linguagem de sistemas no anúncio	Consolidar um padrão que se desviou entre superfícies
Estágio inicial, "nosso primeiro contratado", entrevista com fundador	Do zero ao um: projetar o ciclo principal a partir de uma declaração de problema
Anúncio menciona IA, agentes ou copilotos	Projetar uma superfície onde o sistema às vezes erra
Anúncio é vago ou generalista	Pensamento de produto: escolher uma métrica, propor três maneiras de movê-la

Para outros cargos, adapte a mesma lógica para role_title:

Família de cargo	Formatos típicos
Gerenciamento de produto	Senso de produto (melhorar ou projetar um produto para um usuário), execução (uma métrica caiu, diagnosticá-la), estratégia (entrar em um mercado ou priorizar um roadmap), PRD escrito como take-home
Engenharia	Design de sistema para a carga de trabalho principal da empresa, depuração ou revisão de código de um trecho realista, serviço take-home com nota escrita de trade-offs
Marketing e crescimento	Briefing de campanha com orçamento e restrição de canal, diagnóstico de funil a partir de um extrato de dados, posicionamento para um lançamento
Dados e análise	Análise de conjunto de dados bagunçado com uma pergunta de stakeholder, definição de métrica, design de experimento
Vendas, sucesso do cliente, operações	Chamada de descoberta simulada, plano de conta, caso de redesenho de processo
Qualquer outra coisa	Use os verbos do próprio anúncio: o que eles contratam você para fazer é o que testarão

Dê ao usuário aquele que você julgar mais provável e nomeie o segundo colocado em uma linha para que ele não seja pego de surpresa. Indique se é provavelmente ao vivo ou take-home, já que o ensaio difere (veja Modo 2).

Escreva o briefing como um entrevistador diria

Deliberadamente subespecificado. Briefings reais são duas ou três frases com uma restrição anexada, não uma especificação. Um briefing claro remove o que está sendo testado.

**[Empresa] · formato provável: [nome]** · segundo colocado: [nome]

*O briefing, como eles diriam em voz alta*
"[duas ou três frases. Um usuário ou stakeholder, uma situação, uma restrição. Nenhum critério de sucesso, nenhum escopo.]"

*Timebox:* [25 / 45] minutos, ou [take-home: horas e entregável]
*O que estão pontuando:* [três coisas, uma linha cada]
*A armadilha:* [o erro específico que este briefing convida]

Depois pare. Não resolva. Não dê dicas.

Modo 2: ensaiar

Formato ao vivo: o usuário responde em voz alta ou por escrito; você faz o papel do entrevistador. Interrompa uma vez com uma mudança realista de restrição ("os dados são atualizados semanalmente, não ao vivo"), responda perguntas esclarecedoras brevemente e no personagem, e controle o tempo. Não treine durante a tentativa.

Formato take-home: o usuário compartilha o entregável ou um esboço. Você o revisa como um painel de contratação o folhearia: em cinco minutos, procurando a decisão, o trade-off e a ressalva.

Modo 3: debriefing

O usuário descreve o que fez, cola anotações ou compartilha uma captura de tela. Pontue nesta ordem. Estes seis valem para todos os cargos; a redação do primeiro é flexível.

1. Reenquadrar antes de resolver. A falha mais comum em nível sênior é resolver o briefing como declarado. Candidatos fortes passam os primeiros minutos nomeando o usuário ou stakeholder, a decisão em jogo e como é o sucesso, e dizem a suposição em voz alta para que possa ser corrigida.
2. Focado de propósito. Nomeou o que não está fazendo, e por quê, cedo. Escopo excessivo em um desafio com tempo limitado parece mau julgamento.
3. Mostrou o trade-off. O que foi tentado, rejeitado e o que custou. Uma decisão sem custo não parece uma decisão.
4. Permaneceu legível enquanto pensava. Narrando, esboçando superficialmente, verificando. Quatro minutos de silêncio perdem a sala.
5. Entregou algo. Uma direção concreta com um próximo passo, não três opções devolvidas. Devolver opções parece evitar a decisão.
6. Anexou a ressalva. "Isso pressupõe que os dados são atualizados diariamente, o que eu verificaria." Frequentemente o movimento mais forte, e funciona melhor ao vivo do que no papel.

Onde profile/voice.md ou os arquivos pilares mostrarem os hábitos do próprio usuário (por exemplo, uma história de trade-off característica), nomeie qual história do pilar se encaixa no ponto de trade-off. Não invente uma.

Entregue a crítica

Direta, específica, sem rodeios. O usuário precisa das duas coisas que teriam mudado o resultado.

**Pontuação**
Reenquadramento: [forte / fraco / perdido] · [uma linha]
Foco: [...]
Trade-off: [...]
Legibilidade: [...]
Entrega: [...]
Ressalva: [...]

**As duas coisas que teriam mudado o resultado**
1. [específico, com a frase que deveria ter dito]
2. [mesmo]

**Uma frase para guardar:** [algo que ele realmente disse que foi bom, citado de volta]

Aberturas reutilizáveis

Isso não custa nada e ganha os primeiros três minutos. Adapte a redação à voz do usuário.

• "Antes de começar, deixe-me repetir o que acho que você está pedindo, para que possa me parar se eu entendi errado."
• "Quem é o usuário aqui e que decisão ele está tentando tomar?"
• "Vou deixar [X] de fora e focar em [Y], porque [motivo]. Me diga se essa é a metade errada."
• "Estou assumindo [coisa]. Se isso não for verdade, isso muda."
• "Aqui está o que eu cortaria e o que isso custa."
• "É aqui que eu pararia por agora. Depois eu gostaria de [X], e conseguiria por [método]."

Onde registrar

Adicione uma seção ## Preparação de desafio ao dossiê da empresa em <workspace>/jobs/ (estrutura em <workspace>/jobs/_TEMPLATE.md): o briefing, a tentativa em um parágrafo, as duas correções. Defina o frontmatter interview_prep_challenge: completed. Se não existir dossiê, crie jobs/1-<slug-da-empresa>.md a partir do template com apenas essa seção (prefixo 1-, já que chegar a esta skill implica triagem). Nunca renomeie arquivos existentes; isso pertence a /log-application.