Como transformar descrições de vagas em um plano de estudo de habilidades

1. Declare a decisão de estudo

Escreva quatro escolhas antes de coletar anúncios. Um anúncio é uma vaga publicada.

Nomeie uma família de cargos. Uma família de cargos é um tipo de trabalho, como analista de dados. Nomeie um nível. Nível de entrada significa um primeiro emprego nesse cargo. Nomeie um mercado. Um mercado é o país ou a cidade onde você quer trabalhar. Escreva a data em que você leu os anúncios.

Este é um plano de estudo para essa escolha. Não é prova de escassez nacional de uma habilidade. Não é promessa de entrevistas.

Não misture vagas seniores com vagas de primeiro emprego de analista. Se você precisar dos dois grupos, estude cada grupo à parte. Não misture dois mercados em uma tabela.

A lição mais adiante neste artigo é ficção original. Ela usa trabalho de analista de dados em nível de entrada. Ela usa um mercado inventado chamado Mercado Um. A data de leitura é 13 de outubro de 2026. A mesma data do calendário é também a data de verificação do Actor. Essa coincidência não significa que essas vagas foram coletadas.

2. Colete descrições completas

Verifique cada linha antes de rotular uma habilidade. Confirme a identidade da vaga. Confirme que o texto completo está presente. Confirme se o limite de linhas ou uma execução que falhou interrompeu a coleta.

Um limite de linhas é o máximo de linhas que você pede para coletar. Uma execução que falhou é desconhecida. Não trate uma execução que falhou como zero vagas.

Use a entrada salva da Task só como início:

{"searchTerm": "data engineer\nsoftware engineer\nproduct manager", "startUrls": [], "saveOnlyUniqueItems": true}

Essa entrada mistura engenheiro de dados, engenheiro de software e gerente de produto. Substitua a mistura por um cargo e um mercado. A lista vazia `startUrls` faz parte da entrada salva. Este método usa os sete campos nomeados acima.

Para uma primeira verificação pequena, informe estes valores:

Esta verificação é uma amostra de texto. Não é cada vaga aberta. Não é um levantamento completo de empregadores.

Mantenha estes campos de saída em cada linha que você revisar:

`descriptionStatus` tem dois valores úteis. `full` significa que a descrição está completa o bastante para rotular. `missing` significa que o texto completo não está disponível. Se o status for missing, não rotule habilidades. Conte a linha como uma lacuna.

Um título sozinho pode omitir deveres. Um trecho curto pode esconder um dever exigido. Ele também pode fazer uma habilidade preferida parecer exigida. Leia `descriptionText`.

Alguns campos opcionais podem estar ausentes. Ausente não é o mesmo que zero. Se `companyName` estiver ausente, o empregador é desconhecido. Não invente um nome. Se `jobUrl` estiver ausente, mantenha a linha só se `jobId` ainda a identificar.

Use `jobId` para descartar cópias repetidas do mesmo anúncio. Fique com uma cópia. Não descarte dois anúncios diferentes só porque um empregador publicou os dois. Mantenha o empregador em cada anúncio. Um empregador com muitos anúncios pode fazer uma habilidade parecer mais comum do que é.

Verifique `query` e `searchLocation`. Se eles não corresponderem ao seu cargo e ao seu mercado, deixe a linha fora deste grupo. Se `locationRaw` nomear um mercado diferente, deixe esse anúncio de fora. Não o misture no Mercado Um nem no seu mercado real.

Uma verificação de controle do build 0.2.19 coletou três IDs de vagas de origem. Ela também coletou URLs de origem, momentos de coleta e `descriptionText` completo. Esse controle usou um cargo diferente e um mercado diferente. Ele atingiu o limite de três linhas. Essas três linhas não são todas as vagas daquele mercado. O controle mostra que o texto completo pode ser coletado. Ele não escolhe habilidades para o trabalho de analista de dados. Ele não sustenta as contagens fictícias abaixo.

3. Salve uma linha de evidência por habilidade

Leia uma descrição completa de cada vez. Para cada habilidade ou dever, salve uma linha de evidência.

Salve a vaga, o empregador e a frase exata da origem. Salve o link da origem quando você tiver um `jobUrl` real. Salve um nome curto de habilidade, uma classe de requisito, o dever e uma nota.

Uma classe de requisito é o rótulo que você dá depois de ler a frase. Use só quatro rótulos.

• Obrigatória significa que o texto diz que você precisa ter a habilidade.
• Preferida significa que o texto pede a habilidade, mas não diz que ela é obrigatória.
• Contexto significa que o texto nomeia uma ferramenta, mas não como um teste para você.
• Indefinida significa que você não consegue identificar a classe pelas palavras.

A frase "Usamos Python" não basta. Não rotule Python como obrigatória só por essa frase. Rotule como contexto ou indefinida.

Mantenha as palavras originais. Não as substitua por uma redação mais fluente antes de rotular a classe.

Uma contagem bruta de palavras trata cada menção como igual. A classe impede esse erro. Uma habilidade preferida não é uma habilidade obrigatória. Uma menção de contexto não é uma habilidade que você precisa aprender primeiro.

4. Mantenha uma lista pequena de habilidades

Escolha um nome curto de habilidade para cada habilidade. Mantenha as palavras originais ao lado desse nome.

SQL é uma linguagem usada para fazer perguntas a tabelas. Use um só nome de habilidade para SQL e Structured Query Language somente quando o texto se refere a essa mesma linguagem.

Não una Java e JavaScript. São linguagens diferentes. Não una o trabalho com gráficos a um nome de produto. Não una todo serviço de nuvem em uma habilidade. Um serviço de nuvem é software acessado pela internet. Serviços diferentes podem ser habilidades diferentes.

Um sinônimo é uma palavra diferente para a mesma habilidade. Você decide os sinônimos à mão. Se dois rótulos entrarem em conflito, mantenha as duas notas. Não afirme que uma ferramenta automática de habilidades fez este trabalho. Este Actor não rotula habilidades.

5. Conte anúncios e empregadores à parte

Contagem de anúncios significa quantos anúncios diferentes declaram a habilidade nessa classe. Contagem de empregadores significa quantos empregadores diferentes a declaram. Três anúncios de um empregador são três menções de anúncio. Eles continuam sendo um empregador.

Informe a classe com as duas contagens. Use só anúncios com texto completo como o total de anúncios. Não chame o resultado de demanda de clientes. Não chame de taxa nacional. Não chame de crescimento de contratações. Este tipo de busca não é uma amostra aleatória de todas as vagas.

Amostra fictícia

As tabelas abaixo são ficção original. Elas ensinam as contagens. Não são saída do Actor. Não são o controle de três linhas.

A ficção tem seis anúncios que você pode rotular. Cinco empregadores os publicaram. O Empregador A publicou J1 e J2. O Empregador B publicou J3. O Empregador C publicou J4. O Empregador D publicou J5. O Empregador E publicou J6. Os rótulos J1 a J7 são nomes da lição. Não são IDs de origem. Esta ficção não tem URL de origem. Em uma tabela real, salve `jobId` e `jobUrl`.

Uma sétima linha coletada, J7, não tem `descriptionText`. O status fictício dela é missing. As habilidades dela são desconhecidas. Desconhecido não é zero. Deixe J7 fora das contagens de habilidades. Declare a lacuna. Uma de sete linhas coletadas não pode ser rotulada. O total de anúncios para habilidades é seis, não sete.

"Não declarado" significa que este texto fictício não diz. Não significa que a habilidade está ausente do trabalho real do empregador.

SQL obrigatória está em quatro de seis anúncios. Esses anúncios pertencem a três de cinco empregadores: A, B e C. J1 e J2 são ambos do Empregador A. O quarto anúncio de SQL acrescenta um anúncio. Ele não acrescenta um empregador.

O trabalho obrigatório com planilhas está em três de seis anúncios. Esses anúncios pertencem a três de cinco empregadores: A, B e D. O Empregador D exige planilhas e não menciona SQL.

Python preferida está em três de seis anúncios. Esses anúncios pertencem a três de cinco empregadores: A, C e E. Python não é obrigatória nesta tabela.

O produto de dashboard é contexto só em J6. Nenhum dos seis anúncios o marca como obrigatório. Esse "nenhum" é uma contagem de rótulos para estes seis textos. Não é um resultado de país. J7 continua desconhecido, então não faz parte desse "nenhum".

Uma ordenação por palavra-chave colocaria SQL em primeiro, porque quatro é mais do que três. Depois empataria planilhas com Python. Ela também poderia manter o produto de dashboard. Essa ordenação é a ordem errada de estudo.

A contagem de empregadores deixa SQL, planilhas e Python iguais, com três empregadores cada. A classe de requisito então coloca Python atrás das duas habilidades obrigatórias. Ela também tira o produto de dashboard da lista de estudo. O anúncio extra de SQL é o Empregador A duas vezes. Ele não deve colocar SQL sozinha à frente do trabalho com planilhas.

Não transforme quatro de seis em uma taxa para todas as vagas de um país. Quatro de seis descreve só este conjunto fictício.

6. Marque a prova que você tem

Um nome de habilidade em um currículo não é prova. Prova é trabalho concluído que outra pessoa pode inspecionar. Uma consulta pode ser prova. Uma tabela limpa pode ser prova. Um gráfico com uma decisão escrita pode ser prova.

Marque cada dever repetido como presente, parcial ou ausente. Presente significa que existe prova inspecionada. Parcial significa que parte do dever é mostrada e parte falta. Ausente significa que nenhuma prova é mostrada. Não invente uma pontuação de contratação. Não preveja entrevistas.

Nesta ficção, quem estuda consegue escrever um filtro básico de SQL. Um filtro mantém algumas linhas e descarta outras. Essa prova está presente. Quem estuda não tem uma junção concluída. Uma junção liga duas tabelas por uma chave compartilhada. Essa prova está ausente. Quem estuda não tem um relatório cujos totais foram reconciliados. Reconciliar significa que os totais de saída coincidem com os totais de entrada. Essa prova está ausente. Um gráfico de planilha também está ausente. Python não é a primeira lacuna, porque a classe dela é preferida.

A amplitude da habilidade não é a amplitude do dever específico. As habilidades de SQL abrangem 3 empregadores. As habilidades de planilha abrangem 3 empregadores. O dever de junção aparece em J1 no empregador A. O dever de reconciliação aparece em J3 no empregador B. O dever do gráfico aparece em J1 e J5 nos empregadores A e D. Em conjunto, esta evidência explícita de dever abrange os empregadores A, B e D. Ela não abrange o empregador C. Estes deveres não abrangem, cada um, 3 empregadores.

Mais prática de filtro repetiria uma prova que já está presente. A prova obrigatória que falta é a junção, os totais reconciliados e o gráfico. O primeiro projeto precisa cobrir essas lacunas. Não deixe que J2 sozinho transforme Python no plano inteiro.

7. Escolha um projeto

Nesta ficção, use a junção de SQL, a reconciliação e o gráfico de planilha. Este conjunto é uma combinação deliberada. Os três deveres cabem em um trabalho. Os três têm texto de origem que os marca como obrigatórios. O dever de junção aparece em J1 no empregador A. O dever de reconciliação aparece em J3 no empregador B. O dever do gráfico aparece em J1 e J5 nos empregadores A e D. Em conjunto, a evidência explícita de dever abrange os empregadores A, B e D. Ela não abrange o empregador C. As habilidades de SQL abrangem 3 empregadores. As habilidades de planilha abrangem 3 empregadores. A amplitude da habilidade não é a amplitude do dever específico. Estes deveres não abrangem, cada um, 3 empregadores.

Um projeto útil prova esse trabalho. Uma lista longa de ferramentas não o torna útil. Nomeie as habilidades que você precisa praticar primeiro. Pratique primeiro uma junção básica e uma soma em planilha. Não acrescente Python até conseguir explicar o resultado de SQL e de planilha.

Uma verificação de aceitação é um teste que diz que o projeto está concluído. As verificações abaixo são um plano. Não são resultados medidos de quem estuda. Este artigo não executou uma consulta. Os totais abaixo são uma verificação manual do fixture.

Um fixture é um conjunto pequeno de linhas inventadas, usado para o teste. Mantenha as linhas de entrada sem alteração.

Linhas de clientes: 4 IDs de cliente.

Linhas de pedidos: 10 pedidos.

Leia estes como duas contagens diferentes. A tabela de clientes tem 4 IDs: C1, C2, C3 e C4. Os pedidos usam 4 chaves de cliente diferentes: C1, C2, C3 e CX. Três dessas chaves de pedido são IDs de cliente conhecidos. Uma chave de pedido não tem correspondência. A chave sem correspondência é CX. C4 não tem pedidos. CX não é o mesmo fato que C4.

A olho, cada ID de cliente aparece uma vez. A contagem esperada de IDs de cliente duplicados é 0. Cada ID de pedido também aparece uma vez. Esta é uma leitura manual do fixture. Não é o resultado de uma consulta.

Totais manuais, se cada pedido permanecer na tabela mensal:

• Os valores de January são 10, 20, 15, 12 e 8. A soma deles é 65.
• Os valores de February são 25, 30, 5, 40 e 18. A soma deles é 118.
• As somas dos meses são 65 e 118. A soma delas é 183.
• Os dez valores dos pedidos também somam 183.
• Os valores de CX são 12 e 18. A soma deles é 30.
• O valor com correspondência é 183 menos 30, que é 153.

Uma tabela mensal correta que inclui cada pedido deve mostrar January 65, February 118 e um total de 183. O gráfico deve mostrar esses dois valores de mês. Este artigo não inclui um gráfico concluído. Você constrói o gráfico em uma planilha.

Os pedidos sem correspondência são O8 e O10. Os dois usam CX. Um teste correto de chave sem correspondência deve apontar para essas duas linhas.

Resumo do projeto para esta ficção:

• Entrada: as 10 linhas de pedidos e as 4 linhas de clientes acima.
• Saída: uma tabela mensal de vendas, um gráfico de planilha e dois achados escritos.
• Método: ligar pedidos a clientes, marcar CX e somar amount por mês.
• Verificação de qualidade: some a entrada à mão e faça 183 coincidir com a tabela mensal.
• Mostre: o texto da consulta, o gráfico, a chave sem correspondência e um limite.

Dois achados devem ser possíveis a partir do fixture. Primeiro, CX não está na tabela de clientes, e o valor dele é 30. Segundo, C4 não tem pedidos. Esses achados são a explicação esperada. Não são resultados de uma execução.

Texto planejado da consulta para a tabela mensal. Este artigo não a executou.

SELECT o.order_month, SUM(o.amount) AS month_amount
FROM orders AS o
GROUP BY o.order_month

Texto planejado da consulta para chaves de pedido sem correspondência. Este artigo não a executou.

SELECT o.order_id, o.customer_id, o.amount
FROM orders AS o
LEFT JOIN customers AS c
  ON c.customer_id = o.customer_id
WHERE c.customer_id IS NULL

Use estas verificações de aceitação:

1. As 10 linhas originais de pedidos e as 4 linhas originais de clientes permanecem sem alteração.
2. O trabalho informa 10 pedidos.
3. O trabalho informa 4 IDs de cliente.
4. O trabalho informa 4 chaves de cliente diferentes nos pedidos.
5. Essas 4 chaves são nomeadas como 3 IDs conhecidos mais a chave sem correspondência CX.
6. A nota explica CX e não o confunde com C4.
7. Uma verificação manual mostra que os valores dos pedidos somam 183, e a tabela mensal também soma 183.
8. O texto da consulta e o gráfico são ambos mostrados.
9. Quem estuda explica um limite.

Um limite claro basta. Por exemplo, o total mensal inclui os 30 sem correspondência, enquanto o total com correspondência é 153. Outro limite verdadeiro é que este projeto não prova Python. Um terceiro é que seis anúncios fictícios não são um resultado nacional. Qualquer um destes limites pode passar na última verificação.

8. Ordene o plano

Coloque o trabalho em quatro partes. Não comece pela habilidade preferida.

A parte um é a prática que você faz primeiro. Pratique uma junção neste fixture. Pratique uma soma em planilha.

A parte dois é o projeto combinado. Construa a tabela mensal. Construa o gráfico. Escreva os dois achados.

A parte três é a revisão. Outro leitor usa as verificações de aceitação. O leitor não precisa confiar em uma pontuação. O leitor pode contar 10 pedidos, contar 4 IDs de cliente, achar CX e somar os valores.

A parte quatro é a explicação. Explique a chave sem correspondência. Explique um limite.

A ordem para esta ficção é curta. Primeiro, faça a junção, a reconciliação e o gráfico. Esses deveres são obrigatórios, e a prova está ausente. Este projeto é uma combinação deliberada. A evidência explícita de dever abrange os empregadores A, B e D. Ela não abrange o empregador C. Estes deveres não abrangem, cada um, 3 empregadores. As habilidades de SQL abrangem 3 empregadores. As habilidades de planilha abrangem 3 empregadores. A amplitude da habilidade não é a amplitude do dever específico. Em seguida, revise esse projeto com as verificações. Só depois de conseguir explicar esse trabalho, pratique Python. Deixe o produto de dashboard fora do plano de habilidades.

Você define os blocos de tempo. Um bloco de tempo é o tempo que você escolhe gastar. Não é uma promessa de que você vai dominar a habilidade. Neste plano fictício, use uma sessão para a prática. Use uma sessão para o projeto. Use uma sessão para a revisão e a explicação.

Se você mudar o cargo, o nível ou o mercado, colete uma amostra nova. Use as mesmas regras. Não reutilize esta ordem fictícia para um cargo diferente.