Job Descriptions, Skill Gaps and Portfolio Projects with AI

Choosing what to learn for a job search can feel like standing in front of a wall of postings, each asking for a different mix of tools. "Python, SQL, Power BI, Tableau, statistics, communication, 2 to 4 years' experience." Where do you start? Which of these actually matter? What if you have none of them yet?

This is a good problem for AI, because it is a sorting and planning task with checkable inputs. It is also a problem where AI can mislead you if you ask it what "the market" wants. This article shows how to use it where it is strong and avoid it where it is not.

• How to read a job description critically.
• A method to analyse several postings and build a requirements table.
• How to run a skill-gap analysis against your own evidence.
• How to plan learning without trusting invented resources.
• How to choose and describe portfolio projects.
• How to write honest outreach messages.

A job description is an employer's wish list, written in a hurry and often padded. Some items are essential, some are "nice to have" and some are copied from a previous posting. Reading several postings for the same kind of role shows a pattern: skills that appear again and again are more likely to matter than ones that appear once.

AI cannot know the current job market. It knows patterns from its training data, which may be old, and it cannot see which jobs are open today. So do not ask "what skills are employers looking for?" and trust the answer. Instead, collect real postings yourself and use the assistant to organise them, which is a task you can check.

For a sourced view of broader demand, see Which Skills Are in Demand in India Right Now? An Honest Guide, and always favour recent postings from the places where you plan to apply.

• Must-have versus nice-to-have. Phrases such as "required", "must have" and "minimum qualifications" are stronger than "preferred", "bonus" or "familiarity with".
• Years of experience are often negotiable, especially if you can show equivalent work. Do not treat them as a wall, and do not ignore them either.
• Job title versus actual work. Look at the responsibilities. A "Data Scientist" role may be mostly reporting, and an "Analyst" role may include modelling.
• Tools versus skills. "Tableau" is a tool, and "building dashboards that answer a business question" is the skill. The skill transfers.
• Red flags such as unpaid trial work, requests for payment, vague company details or "guaranteed placement" claims deserve caution.

1. Collect 5 to 10 postings for the same target role, from different employers. Copy the text yourself. Note the date.
2. Extract. Ask the assistant to pull out requirements, with quotes.
3. Count. See which requirements recur.
4. Compare with your own evidence (the facts document from article 23).
5. Prioritise the gaps.
6. Plan the learning and the projects.
7. Revisit in a month with fresh postings, since needs change.

Below are 6 job descriptions for junior data analyst roles, labelled Posting 1 to 6.For each posting, extract the requirements as a table with columns:posting number, requirement (short), category (technical skill, tool, soft skill,experience, education), level (required or preferred), and the exact quote.Use only the text. If a requirement is vague, say so. Do not add requirements thatare not in the text.[paste postings, each labelled]

You get a long table. Spot-check ten rows against the original text, since models can drop or invent items. Then ask for a count:

Group similar requirements together (for example "SQL" and "writing SQL queries")and count how many of the 6 postings mention each. Show the result as a tablesorted by count, and list which postings mention each.

Counting is a place where models can slip, so verify the top five by searching the postings yourself for the keyword. A small illustrative result might look like this (made-up numbers, for shape only):

Your sample of six postings is small and not representative, so treat the pattern as a guide and not a statistic.

Take the requirements and compare them honestly with your facts. Use three levels:

Here is a requirements table from 6 postings and my fact sheet. For each of the top10 requirements, classify my status as "can show", "partial" or "missing", citingthe line of my fact sheet that supports your classification. If my fact sheetdoes not mention it, classify it as "missing" and do not assume. Then list thegaps in order of how many postings mention them.

You then correct its classification where it is too generous or too harsh. You are the authority on what you can actually show.

Not every gap is worth closing first. Score each gap on three questions:

1. How often does it appear? (from your table)
2. How central is it to the role? (required versus incidental)
3. How learnable is it in my available time? (one weekend or six months)

Prefer high-frequency, high-importance, quick-to-learn gaps first. SQL for an analyst role scores high on all three. A deep specialism that appears once scores low. Be honest about your time: hours per week, and for how many weeks.

You can ask the assistant for a plan:

I have 8 weeks and 7 hours a week. My top gaps for a junior data analyst role are:SQL (partial), a BI tool (missing), statistics basics (partial). Propose aweek-by-week plan with, for each week, a learning goal, a small practice task andthe evidence I will have at the end. Describe the *types* of resources I should useand the search terms to find them. Do not name specific courses, books or URLs.

The last instruction is deliberate. Assistants can invent course titles, instructors and links that look real. If you want actual resources:

• Find them yourself through official documentation, your library or well-known learning platforms, then check reviews, syllabus and date.
• Check that anything the assistant names exists, with the exact name, on the provider's own site.
• Prefer free, official material first, so cost does not become a barrier.
• Treat the plan as a draft. Cut it down to what you can actually do. Plans are usually too ambitious.

Define "done" for each week as something you can show, such as a query set in a repository or a dashboard. Evidence beats certificates.

Employers cannot see what is in your head. A small number of well-chosen projects let them see how you think. The people reading your portfolio often have limited time, so quality and clarity beat quantity.

• It solves a real problem, even a small one: your own finances, a local shop's sales, a public dataset with a question you care about.
• It is finished, and small enough that you could finish it. One complete project beats three abandoned ones.
• It targets a gap from your analysis, so it proves something the role needs.
• It shows your thinking, not just the outcome: the question, the choices, what did not work and what you learned.
• It uses data you are allowed to use, with the source and licence stated. Do not use private or confidential data, and do not scrape sites in ways their terms forbid.
• It is explained honestly, including what you built and what a tool or assistant did.

Ask for ideas in a way that avoids generic answers (see article 16):

Suggest 8 portfolio project ideas for a junior data analyst. Constraints: eachshould be finishable in about 20 hours, use free public data, require SQL and a BItool, and answer a question a real organisation might ask. Avoid the most commonbeginner projects. For each, give the question, the data type and the skills itwould show.

Then check any dataset it mentions exists, is current, and has a licence that allows your use.

Use a short, consistent structure in your README or write-up:

1. The question and why it matters.
2. The data (source, size, date, licence).
3. The method (tools and steps).
4. The result (what you found, with the limits).
5. What I would do next, and what I learned.
6. Who did what, including the role of AI assistance if you used it.

An assistant can help tighten the writing. The thinking and the claims must be yours. If it cannot be explained in an interview, it should not be on the list. For the building side, see Vibe Coding vs Responsible AI-Assisted Building.

AI can help you write a clear, short message to a person you would like to learn from. It should not be used to mass-produce spam or to fake familiarity.

Good outreach:

• Is specific. It mentions something real about the person's work or a shared context.
• Asks for something small, such as a 15-minute chat or one question, and makes it easy to say no.
• Is honest about who you are and what you want.
• Is short.

Draft a 4-sentence LinkedIn message from me to a data analyst at a logisticscompany. Facts, and only these: I am a final-year student; I read her post aboutcleaning delivery-time data; I am building a similar project on public data; I wouldlike to ask one question about how she handles missing timestamps. Tone: polite anddirect. Do not add compliments I did not give or claims about shared connections.

Check the name, the company and every claim before sending. Do not send ten near-identical messages. Do not pretend to know people you do not know. Remember that not everyone will reply, and that is normal.

• Do not invent projects, skills or experience. Article 23 lists the red lines.
• Do not trust AI claims about the job market without evidence you can see.
• Do not paste other people's private information.
• Do not buy expensive "job guarantee" programmes because a plan told you to. No course, plan or portfolio guarantees a job, and if a provider says it does, be cautious.

• Asking the assistant what employers want instead of analysing real postings.
• Learning ten tools shallowly instead of the top three properly.
• Following a plan with invented resources.
• Building tutorial clones and presenting them as original.
• Overbuilding. A project nobody finishes shows nothing.
• Sending generic outreach to many people.
• Skipping the check of datasets and licences.

• Next: Interview Preparation and Mock Interviews with AI helps you practise what you have learned and built.
• For a general career-switching view, see How to Switch to an IT or Data Career at 25 to 35 Without Starting Over.
• For the fundamentals of learning a skill in a limited time, see How to Learn a New Skill in 90 Days: A Practical Framework.