What a Data Analyst Needs to Know: 10 Skills You Can Test on a Project

You know Excel, have learned some SQL and are watching a Python course. Meanwhile, another AI tool arrives every week. It is easy to conclude that a data analyst should know everything, preferably yesterday. I would start with a smaller question: which problem can you already take from a vague request to an answer you have checked?

My list covers five technical skills and five skills related to how you work. It retains the perspective of the original 2026 article, but it is not a survey of every employer’s requirements. The depth you need depends on the role, organization and responsibility involved. These foundations remain useful after the excitement around the next model release has faded.

I started in customer service and later worked in data analysis and data architecture. That is why I care about connecting tools to an actual process. A course can teach you syntax and where to click. A project reveals whether you understand the result, notice an error and can explain what someone should do next. The project below uses entirely synthetic data and situations.

One project that makes your skills visible

Imagine that a support coordinator wants to investigate outstanding tickets. You receive a snapshot of six tickets submitted during one week, with their status as of Monday at 9 a.m., Europe/Warsaw time. Each ticket belongs to one team. This simplified exercise allows two statuses: open and closed. There are no missing or duplicated ticket identifiers.

A separate lookup maps A to Alpha and B to Beta. Alpha has closed two of its three tickets, approximately 66.7%. Beta has closed one of three, approximately 33.3%. Overall, three of six tickets are closed: 50%. These are shares within a selected group at the snapshot time. They do not measure productivity or whether deadlines were met.

We do not yet know ticket age, complexity, team staffing or agreed deadlines. The three open tickets could be recent arrivals. They could also have been waiting for a customer response for some time. The result should help us ask the next question. Six rows will not support a fair employee ranking, even if the dashboard has a very serious navy header.

The deliverable is a small package: a question, input data, a calculation, a check, a chart and a short recommendation. Start in a spreadsheet if that helps, then reproduce the calculation in SQL or Python. I assess each skill through what it contributes to that same package. You do not need a separate impressive-looking project for every tool on your CV.

1. Excel: check what you are actually counting

I like Excel as a place to sketch the first version. For this exercise, I would create a table with one row per ticket, clear headers and a filter. I would add a short explanation of the two statuses and keep the original sample separate from the output. Adjusting the presentation should not accidentally change the input.

In a PivotTable, use teams as rows, status as columns and a count of ticket identifiers as values. Check the aggregation: adding ticket numbers is meaningless here. After adding records, refresh the result and confirm that its source includes them. Microsoft explains these mechanics in its PivotTable documentation.

For junior-level evidence, I would want you to reproduce the answer by hand and explain each output column. Add a seventh ticket, open and assigned to Alpha. The number closed should stay at two, while the denominator rises to four. If the report still says 66.7%, investigate the source range or refresh process. This small change makes a much better check than staring at the original answer.

The file also needs to survive a handover. Calling a sheet “final_final2” does not explain how it works. Record the snapshot time, filters and update procedure. Someone opening it next week should know where new data goes and which cells contain results. I discuss the broader role of spreadsheets in Excel for data analysts.

2. Asking questions: establish the decision first

“Show me the backlog” leaves plenty of room for interpretation. My first question would concern the decision the coordinator wants to make. Are we allocating extra support today, looking for a process problem or preparing a weekly update? Each need implies a slightly different dataset and time horizon. Clarifying that is useful work before you open a chart editor.

Next, I would agree what an outstanding ticket means. Does waiting for the customer count? What happens when a ticket is reopened? Are we examining tickets submitted during the week or every ticket still open at a particular moment? Our example uses the first group. Older tickets fall outside it, so the result does not describe the department’s total workload.

You do not need to turn the conversation into an hour-long interrogation. Prepare three important questions and record the answers in a few sentences. If the requester cannot choose a definition, offer two alternatives and explain their consequences. That helps them make a decision without making them solve the entire analytical problem themselves.

The evidence for this skill is a short brief that lets another person identify the required records. In a portfolio, you can define the assumptions yourself and explicitly mark them as part of the exercise. There is no reason to invent a meeting with a board of directors to make a learning project sound more professional.

3. SQL: protect the meaning of one row

I would begin SQL practice with filtering, grouping and joins. Once those foundations are reliable, I would introduce window functions and more complex queries. The number of CTEs in a solution does not tell me whether the analysis is good. First, I want to know whether one row after a join still represents one ticket.

Suppose you join the six tickets to an event table. Ticket one has two events; each remaining ticket has one. A straightforward join produces seven rows. Summing a closed-ticket flag after that join gives four instead of three because the first closed ticket appears twice. The PostgreSQL join documentation describes how matching rows produce this result.

The correction depends on the question. You might reduce the events to one row per ticket before joining, or check only whether a relevant event exists. Adding DISTINCT across the output does not explain which information you intended to preserve. Two events with different timestamps remain different rows. You need to resolve the unit of analysis deliberately.

For the exercise, record the ticket count before and after each step. Also inspect identifiers that disappear. A junior does not need to know every optimization technique, but should notice when a result grows unexpectedly. If this part is unfamiliar, continue with SQL join examples. Practice explaining a small join by hand before increasing the number of tables.

4. Business understanding: separate a metric from a judgment

Alpha appears to be doing better until you ask about the work involved. Perhaps Alpha handles straightforward account changes while Beta handles complicated complaints. That is a hypothesis to investigate. The table alone cannot tell us whether the difference reflects organization, difficulty, arrival time or chance. Treating one possible explanation as a finding would overstate the evidence.

To allocate support, I would want at least the age and priority of open tickets and whether they are waiting for someone else. To assess timeliness, I would need a deadline for each ticket. The share closed and the share closed on time answer different questions. I would not relabel the first metric just because the extract lacks the information needed for the second.

Test your process understanding by describing one ticket’s path from submission to closure. Identify who can change its status and what that action means. Consider whether the metric might encourage people to close easy tickets while difficult ones wait. You can raise that possibility without claiming anyone is actually behaving that way. It is a question about the consequences of a measurement choice.

My recommendation for this exercise would be modest: inspect the three open tickets and gather the missing information needed to decide about support. I would not publish a team ranking from this sample. That boundary belongs in the result. Explaining what a dataset cannot establish is part of understanding the business question.

5. Visualization: put the result in context

A table or two bars showing open-ticket counts will do: one for Alpha, two for Beta. The title should specify the selected submission week and the snapshot time. Show the group sizes nearby. A percentage can look persuasive when the audience cannot see that it rests on only a few observations. Give them the information needed to interpret it.

Choose a tool that fits the environment where the report will be used. Power BI, Tableau or a spreadsheet can handle this project. I would not turn my personal preference into a claim that one product dominates the market. During learning, understanding how data, filters and results connect matters more than collecting screenshots from a succession of applications.

If you build a Power BI model, keep the ticket table separate from the team lookup and relate them by identifier. Microsoft’s modeling guidance emphasizes consistent fact-table grain. Here the grain is one ticket. Evaluate every additional dataset against that choice before using it to create a more elaborate report.

I would check the visualization with another person. Give them a minute, then ask what they learned and what remains unknown. If they conclude that Beta works twice as badly, revise the title, context or presentation. A polished report that encourages an unsupported decision needs another iteration. The review should test understanding as well as whether the colors look good.

6. Plain language: leave a useful message

Try explaining the result in three sentences. “Of the six tickets submitted during the selected week, three remain open in the Monday snapshot. One belongs to Alpha and two to Beta. Before assigning extra support, check their age, complexity and deadlines, which are missing from this extract.” That is a message someone can act on without decoding analytical jargon.

It contains an observation, a limitation and a next step. Words such as “synergy” will add very little. A contact who can supply the missing information would help, as would a deadline if the decision is needed today. In a synthetic project, make it clear that any organizational roles are hypothetical. You are demonstrating a communication approach, not documenting a real engagement.

Plain language still needs precision. “Half the tickets are overdue” is shorter, but we do not know their deadlines. Open does not necessarily mean late. A small change of wording could substantially alter how the audience judges a team’s work. Read your own message with that risk in mind before sending it.

Practice answering “where did that number come from?” You should be able to move from the sentence to the output table, then to the three specific records. If the explanation depends entirely on the author’s memory, add a traceable calculation. I would rather see a result someone can inspect than hear a very confident presentation that nobody can reproduce.

7. Python: reproduce the result and reject bad input

I would develop Python where processing needs to be repeated. It offers no scale advantage for six tickets, but this example demonstrates a readable calculation and input checks. The code requires pandas. Run the entire block: it creates its own synthetic data, so you do not need to obtain a file from an employer.

import pandas as pd

tickets = pd.DataFrame(
    [(1, "A", "closed"), (2, "A", "closed"), (3, "A", "open"),
     (4, "B", "closed"), (5, "B", "open"), (6, "B", "open")],
    columns=["ticket_id", "team_id", "status"],
)
teams = pd.DataFrame(
    [("A", "Alpha"), ("B", "Beta")],
    columns=["team_id", "team"],
)

def summarize(tickets, teams):
    if tickets.empty:
        raise ValueError("No tickets in the selected snapshot")
    if tickets.isna().any().any() or teams.isna().any().any():
        raise ValueError("Missing input value")
    if tickets["ticket_id"].duplicated().any():
        raise ValueError("Duplicate ticket_id")
    if not tickets["status"].isin(["open", "closed"]).all():
        raise ValueError("Unknown status")
    joined = tickets.merge(
        teams, on="team_id", how="left",
        validate="many_to_one", indicator=True,
    )
    if not joined["_merge"].eq("both").all():
        raise ValueError("Unknown team_id")
    result = (
        joined.assign(closed=joined["status"].eq("closed"))
        .groupby(["team_id", "team"], as_index=False)
        .agg(tickets=("ticket_id", "size"), closed=("closed", "sum"))
    )
    result["closed_pct"] = (100 * result["closed"] / result["tickets"]).round(1)
    return result

print(summarize(tickets, teams).to_string(index=False))

Alpha’s result is three tickets, two closed and 66.7%; Beta’s is three, one and 33.3%. The validate="many_to_one" argument checks key uniqueness in the right-hand lookup, while indicator lets us detect unmatched records. The pandas documentation explains both options. These checks address distinct problems, so neither replaces the other.

An empty input deliberately raises an error. I do not want to imply that having no tickets means zero effectiveness. The code also rejects unknown statuses instead of silently treating them as open. Those are choices for this exercise; a production process would need agreed rules and a way to handle the failure when a report is run.

Now break the input. Duplicate an identifier, add an unknown team and remove a status value. Also try making every ticket open and then every ticket closed. One successful run is a starting point. I want to know whether you understand the assumptions behind the program and what happens when they are violated. Keep those cases alongside your project so another person can repeat them.

8. Independence: recognize when to ask for help

I would assess independence through the quality of your next step after encountering a problem. If a ticket references an unknown team, you can check the lookup source, export dates and other records with the same identifier. Record what you find. Inventing a team name to make the validation stop complaining would hide the unresolved question.

A useful request for help might read: “Two records contain team C, which is absent from the supplied lookup. I checked both files and their export dates. I need the current mapping or confirmation that these records should be flagged separately.” The recipient can see the issue and the decision they can make. They do not have to reconstruct what “the report is broken” means.

Set a reasonable investigation window based on urgency. An hour spent hunting for one punctuation error may be less useful than a short question. Conversely, continually asking which button to press prevents you from learning the process. For your project, write down where you got stuck, what you tried and what eventually resolved it. That record makes progress visible.

Your limits are also useful information. A junior should flag an ambiguous definition or a risk of misleading the audience. Pretending to be certain transfers the problem to the report’s reader. Independent work should remain inspectable by someone else, and asking a precise question can be the most responsible way to move it forward.

9. AI: test suggestions against a known answer

I would use AI in this project to suggest edge cases, explain an error or compare two versions of a result description. I would provide the synthetic sample, metric definition and expected output. That context also gives me a reference for assessing the response. It is easier to catch a mistake when I already know what a small example should produce.

Ask a model to review the code, then examine every consequential suggestion. It might propose removing duplicates without investigating their cause or replacing missing values with zero. Either change requires a return to the meaning of the data. An elegant-looking edit still needs a reason that fits the process being analyzed. Test the revised output rather than trusting its explanation alone.

At junior level, I care more about verifying an answer than claiming familiarity with many models. Advanced knowledge retrieval systems or automated agents can be a later direction if the role calls for them. I would not make those systems a prerequisite for every first analytical project. Start with a task whose output you can evaluate reliably.

Include a short note in your portfolio: where AI helped, what you checked yourself and which suggestion you rejected, with a reason. At work, use tools and data within the scope permitted by your organization. This exercise gives you everything needed without reaching for real support tickets or customer information. You can demonstrate the method entirely with the supplied sample.

10. Learning: choose a gap exposed by your work

After finishing the task, choose one problem to practice next. If you used the wrong denominator, another visualization course probably will not resolve it. If the calculation works but you struggle to explain its limits, practice writing the result and discussing it with a reader. A useful learning plan grows out of observations about your own work.

I suggest three short sessions. First, reproduce the example without looking at the solution. Second, change a condition, such as adding a team or supplying an empty sample. Third, show the project to someone and record the questions you could not answer. Then improve that specific part. This is a proposed practice structure, with no promise about how quickly it will lead to a particular job.

Leave room for rest and ordinary responsibilities. A plan that requires several hours of concentration every evening may simply be incompatible with your life. I would prefer a smaller project with completed checks to an ambitious timetable containing ten unfinished courses. Finishing the loop gives you something concrete to review and a better basis for choosing the next step.

My self-assessment would have three labels: “I can do this independently,” “I can do this with help” and “I cannot do this yet.” Next to each, I would record evidence from the project. I would avoid averaging scores in a way that implies a good chart compensates for an incorrect count. If the central result is wrong, the calculation needs attention first.

What to show when you finish

The finished package should let another person reproduce the numbers without your involvement. Include run instructions, the library version, the selected ticket group and the snapshot time. Preserve the synthetic input and the checks you used. Separately state what cannot be established from this sample and what information you would request next. This makes both the achievement and its boundaries visible.

Ask someone to change one open ticket to closed and check whether the result responds as expected. Then ask them to identify the most important conclusion in your description. You are testing the technical work and communication together. Neither requires a fictional story about deploying the report at a large company. The exercise can stand on its own as evidence of your approach.

That package gives you material for a useful development conversation. You can show a mistake, how you found it and the correction. This is where I would start assessing analytical competence: can you explain your choices, check the answer and define the limits of what you know? Choose the next tool in response to a problem that actually appears along the way.