Ian Klosowicz
Most people trying to break into data analytics build portfolio projects in a vacuum — downloading public datasets, building dashboards about things they don't care about, and trying to convince a hiring manager they're ready for analytical work. The people who break in fastest usually have a better starting point: their current job.
You don't need to work in analytics to build an analytical project. You need access to a real business problem, familiarity with the context, and enough initiative to build something that answers a question your organization actually has. That combination is more powerful than any tutorial dataset, and it's available to almost everyone who's currently employed.
This post covers how to identify the right project in your current role, how to build it without using proprietary data publicly, and how to talk about it in interviews in a way that lands.
A portfolio project built on your current job has advantages that no public dataset can replicate.
The context is real. You know why the question matters. You know what decisions the answer would inform. You know what the data actually represents, what its quirks are, and what the business does with the output. That contextual fluency comes through immediately when you talk about the project, and it's something a candidate who just downloaded a dataset off Kaggle simply cannot fake.
The domain knowledge is native. If you've worked in healthcare for 5 years, you know what a 30-day readmission rate is and why it matters before you write a single SQL query. That foundational understanding means the interview conversation can go deeper faster, and the answers you give to follow-up questions sound like someone who's been in the room where these decisions are made — because you have been.
The problem is pre-validated. You didn't have to invent a question to ask of the data. Your organization already has the question. Possibly your manager has been asking it for months without anyone providing an answer. Building that analysis gives you a real project with a real stakeholder, and the ability to say "my manager used this to make a staffing decision" or "this was presented to the operations team" is a sentence no tutorial project produces.
I didn't start in data analytics. I built skills while working somewhere else and got hired. The domain familiarity I had from my prior work made the transition faster, not slower. The analytical thinking you develop by noticing the questions your organization can't answer is some of the most valuable preparation you can do before the job search starts.
The right project is usually visible in the questions your team can't answer or the reports that don't exist yet. Look for:
Something your manager guesses at. If someone in your organization is regularly making a decision based on gut feeling or rough estimates because nobody has pulled the actual data, that's a project. "I think our busiest day is Tuesday" is an invitation to find out whether it actually is, and why.
A report that gets manually updated. If someone in your team or department copies numbers from one spreadsheet into another every week, that process contains a project. The data exists. The question is implicit. You can automate it, analyze it, and build something that answers the underlying question rather than just moving numbers around.
A metric your team tracks but doesn't understand the drivers of. "Our sales are down this quarter" is not an analysis. "Our sales are down this quarter and the decline is concentrated in the 18-34 demographic in the Southeast region, which started 6 weeks ago coinciding with a competitor's promotional campaign" is what analytics produces. If your team is tracking a metric without understanding what's moving it, the driver analysis is your project.
A decision that gets made the same way every time without evidence. Scheduling, inventory, pricing, staffing, resource allocation — if someone in your organization makes a recurring decision the same way every time based on habit rather than data, you have a project. The question is whether the habit-based approach actually produces the best outcome.
Once you've identified the question, check whether it maps to a standard analytics output: a SQL query set, a BI dashboard, or a Python analysis. If it does, you have a portfolio project.
The most common concern about using current-job data is the obvious one: you can't publish proprietary company data in a public portfolio. Customer names, transaction records, internal financials, employee data — none of that belongs in a GitHub repo or a Tableau Public dashboard.
This is a real constraint, but it doesn't eliminate the option. It just shapes how you use it.
What you can use publicly: the analytical approach, the structure of the problem, the methodology, and the finding described at a level of abstraction that doesn't reveal proprietary data. You can describe what you built and what you found without publishing the underlying data.
What you can't use publicly: the actual data, specific customer or employee identifiers, exact financial figures tied to the company, or anything your employer would consider confidential.
The practical question before building anything: would your employer be comfortable knowing you built this analysis and are describing it in interviews? If the answer is yes, the project can go on your resume with a note that the data is proprietary. If the answer is no, go to the mock-rebuild approach below.
Ask your manager if you're not sure. Most managers, when asked "I'd like to build a data project that answers [specific question] — is it okay if I mention that I built this in my job search?" will say yes. The analysis helps them. The visibility helps you. It's usually a straightforward conversation.
If the data is too sensitive to describe publicly, or if you want a project you can actually show rather than just talk about, the mock rebuild is the answer. The approach:
The mock rebuild works because the skill being demonstrated is the analytical approach, not the specific dataset. A hiring manager who sees a cohort retention analysis built on public e-commerce data and hears that you built the same analysis for your current employer's customer base has seen everything they need to see.
Current-job projects have a specific interview advantage: the story arc is complete. You identified a real problem, built something to answer it, and the output was used by a real person to make a real decision. That arc is impossible to manufacture with a public dataset project.
Structure the walkthrough around the business context, not the technical execution:
That structure produces an answer to "tell me about a project you've worked on" that sounds like a working analyst, not a job seeker. The interviewer is hearing about someone who sees analytical opportunities in their environment and acts on them. That's the thing they're trying to hire for.
On the proprietary data question: be direct and brief. "The underlying data is proprietary, but I'm happy to walk through the approach and what we found at a high level." Most interviewers will respect that boundary and the conversation will move to the methodology, which is what they actually want to understand anyway.
The Analyst Hive program covers how to frame prior work experience and current-job projects on a resume and in interviews, as part of the Month 1 asset build. The way you describe analytical work you've done is as important as the work itself.
To make this concrete: here's what a current-job project looks like across different backgrounds that are common among people trying to break into data analytics.
Healthcare (nurse, medical assistant, clinic coordinator): Patient flow through a clinic — which appointment types run over schedule most often, and is there a provider or time-of-day pattern? Build it on de-identified scheduling data if your clinic uses an EHR system with reporting exports. The public version: use CMS appointment wait time data or synthetic patient flow data.
Retail (store associate, inventory coordinator, department manager): Which product categories sell out fastest on weekends, and is the reorder threshold set correctly given the typical lead time? Build it on your store's inventory export if you have access. The public version: use the UC Irvine Online Retail dataset with the same analytical question applied to product categories and reorder signals.
Finance (bookkeeper, accounts payable, loan processor): Which invoice categories run over 30 days to payment most often, and is there a vendor or department pattern? Build it on anonymized AP data from your accounting system. The public version: use CFPB complaint data as a proxy for financial process failure analysis, applying the same pattern-identification approach.
Operations (dispatcher, warehouse coordinator, logistics analyst): Which fulfillment routes or carriers have the highest on-time delivery rate, and does order size or destination region predict delays? Build it on shipment export data from your WMS or TMS system. The public version: use Bureau of Transportation Statistics on-time performance data for commercial carriers.
Marketing (coordinator, social media manager, email marketer): Which email subject line characteristics correlate with open rate, and does that relationship hold across different audience segments? Build it on your platform's campaign export (Mailchimp, HubSpot, etc. all export performance data). The public version: use public email marketing benchmark datasets or a structured A/B test analysis on a synthetic dataset.
Education (teacher, administrator, counselor): Is there a relationship between attendance rate and assessment performance, and does it differ across grade levels or demographic groups? Build it on de-identified school data if your district publishes it. The public version: use NCES school-level data, which is publicly available at the district and school level.
What if my current job has nothing to do with data?
Almost every job touches data in some form — sales numbers, inventory counts, customer interactions, scheduling, financial records, performance metrics. The question isn't whether data exists; it's whether you can identify a question that the data could answer that your organization would actually care about. Start by listing the decisions your team makes regularly and asking which ones are made without data that could inform them. That list usually contains at least 1 project.
Do I need my manager's permission to build this?
You need their permission to use the data publicly. You don't necessarily need permission to build the analysis internally and describe it in interviews without publishing the underlying data. That said, asking is almost always a better move than not asking. Managers who know you're developing analytical skills and using your role as a learning environment are usually supportive, and the conversation itself signals initiative.
What if I'm worried about getting in trouble for using company data?
Then use the mock-rebuild approach. Build the equivalent project on public data and reference the real-world context in interviews without publishing the proprietary version. You get the story arc ("I built this because we had this problem at work") without the data exposure risk. The public version is what interviewers see; the real-world context is what makes the conversation richer.
Can I list this as a work project on my resume, not a portfolio project?
Yes, and that framing is often stronger. If you built it during work hours as part of your role — even if it wasn't formally assigned — it belongs in your work experience section as an accomplishment bullet: "Built a Power BI dashboard tracking [metric], reducing manual reporting time by [X hours] per week." If you built it on your own time using work-adjacent data, it belongs in the projects section. Either placement works; the key is that it's on the resume somewhere with a clear description of the question it answered.
What if the project I built at work is too simple to be impressive?
Simplicity isn't the problem if the business impact is real. "I built a dashboard that tells our store manager which products to reorder before they run out, and it eliminated the Sunday morning stockouts that were costing us X in lost sales" is more compelling in an interview than a technically complex project built on a Kaggle dataset that didn't inform any real decision. The bar isn't technical complexity. It's whether the work was real and whether you can talk about the impact.
How do I handle it if the project didn't produce a useful result?
Be direct about it and frame it as information rather than failure. "The analysis showed that the pattern we assumed was there wasn't actually in the data, which told us the problem was somewhere else in the process." A null result from a real project is more credible than a dramatic finding from a tutorial dataset. The credibility comes from the fact that it was real work on a real problem, regardless of what the data showed.
If you want a structured approach to turning your current role into portfolio-ready analytical work — identifying the right project, building it, and framing it on a resume that gets read — the Analyst Hive program covers all of it in Month 1. Daily tasks, built around getting hired from wherever you're starting.
