Why can’t I find a job? How I approach a career change into analytics

“Why can’t I find a job?” becomes an easy question to ask after another email thanking you for your interest. You probably know the genre. Three polite sentences, no useful explanation, and the feeling that another week has disappeared into space.

When I think about changing careers, I start with the distance between what I can do today and the work an employer needs someone to do. There are several ways to reduce that distance. Sometimes I need training, sometimes a clearer description of my experience, and sometimes an adjacent role that gives me access to relevant problems.

My own path took me from humanities studies and customer service into working with data. I understand the temptation to see the industry as a club where everyone else received the password. My experience does not guarantee the same outcome for everyone. It does suggest an approach worth considering: building on what I can already access.

The examples below describe hypothetical candidates and projects. They are not stories about particular students, and the plan does not promise employment after a fixed number of weeks. I want a process that helps me make better decisions, even when the hiring outcome remains uncertain.

First, I locate the actual bottleneck

Not having an offer is an outcome. It tells me little about the cause. I might be applying to roles requiring different experience, describing my work unclearly, or struggling at a particular interview stage. A company might also have paused hiring. Some parts of this process are outside my control.

Instead of placing everything under “I am hopeless,” I record stages: application, invitation, initial conversation, task, further interview and decision. I add the role, requirements, CV version and date. An ordinary spreadsheet is sufficient. Spending three weekends building an application-management system is unlikely to bring the first invitation forward.

If I get no conversations, I inspect role selection and the opening part of my CV. If interviews happen but technical tasks repeatedly stop progress, I have a more specific learning target. If I reach the final stage, I review how I explain my work, expectations and whatever feedback I can actually obtain.

I avoid drawing sweeping conclusions from two applications. Small samples allow chance to impersonate a strategy. I compare similar roles and conditions, and treat silence as missing information. That is less dramatic than diagnosing my entire personality, but considerably more useful.

Two situations that need different responses

Suppose someone sends twenty applications, fifteen of them to jobs requiring experience implementing data warehouses. Their current experience consists of introductory spreadsheet projects. I would first change the target roles, rather than spending another evening adjusting the photograph on the CV.

In another case, a candidate gets interviews but cannot explain why joining two tables increased the reported sales total. I would practise relationships, data grain and validation. Both candidates may type the same question into a search engine. Their next useful actions are different.

The purpose of tracking applications is to narrow the next decision. I am not trying to create a performance dashboard that makes rejection feel even more official. If recording a field will not change what I do, it probably does not belong in the tracker.

I choose a role by its work

“I want to work in IT” is a reasonable opening ambition and a weak job-search filter. It covers many different working lives. I try to describe a concrete week instead: preparing reports, speaking to users, cleaning data, explaining changes and maintaining dashboards.

Titles help, but they are insufficient. An analyst in one company produces operational reports; in another, the role involves data modelling; elsewhere it centres on gathering requirements. I read responsibilities and examples of problems. A title on LinkedIn has surprisingly little power to change the contents of the calendar.

I would review a manageable set of current vacancies matching the locations and working arrangements I can realistically accept. I would list recurring tasks and tools, distinguishing essential requirements from preferences where the employer makes that distinction. My own interpretations would remain labelled as interpretations.

The O*NET description of Business Intelligence Analysts offers a broader reference point. It includes reporting, BI tools, documentation and communicating information. This is an American occupational profile, so I use it as a map of work, rather than a hiring forecast for Poland or a universal list of employer requirements.

An adjacent role that actually moves me forward

I would consider positions in operations, customer service, logistics, administration or sales support if they include meaningful work with data. They can let me use existing domain knowledge while expanding the analytical part of my responsibilities. This is the central idea behind the career-change strategy I am describing.

A large employer does not guarantee that opportunity. I could spend a year copying cells without permission to improve anything. A smaller organisation might give me responsibility for a useful report much earlier. I investigate actual conditions rather than attaching magical powers to the word “corporate.”

At an interview I would ask which reports the team produces, who uses them, whether a new employee can improve the process, and how the team works with analysts. I would request an example of a recent improvement. A specific answer tells me more than “we value development,” which fits comfortably on almost any company mug.

I also consider the practical trade-off. A role may offer relevant experience but an unsuitable schedule or a pay change I cannot sustain. A sensible transition has to work in my actual life. A theoretically perfect stepping stone that I cannot afford to stay on is not much of a bridge.

I inventory the experience I already have

Changing industries can make previous years of work feel like a long waiting room before real life begins. I ask more useful questions: which processes do I understand, which mistakes can I recognise, and whom can I communicate with? Handling complaints, planning shifts and checking stock all provide knowledge about what business data represents.

Someone from customer service may understand contact reasons, handovers and the difference between closing a ticket and resolving a problem. That knowledge helps them ask sensible questions of a report. Technical skill still needs development, but the starting point is concrete.

I make a simple inventory: process, problem, my action, tool, outcome and how the outcome was checked. If I did not measure the result, I say so. I do not invent a 37% efficiency improvement because 37 somehow looks more convincing than 40. An interviewer may ask where it came from, and the conversation then becomes improvised fiction.

I also identify tasks I cannot yet do independently. Perhaps I prepare data but someone else interprets it. Perhaps I maintain a report without understanding its source. That gap suggests the next exercise. A list of missing skills is useful when it leads to practice rather than another evening of self-criticism.

Describing ordinary work accurately

“Customer service and Excel” says little about how I work. If accurate, I could write: “I standardised ticket categories and prepared a weekly breakdown of contact reasons for the team lead.” That identifies the action, information, frequency and recipient.

If the work changed a process, I describe what changed and how it was checked. Without a measured result, I can state an observable outcome, such as the report being used in the team’s weekly review. Precision is enough. Every bullet does not need an artificial financial miracle.

I keep the scale honest too. Improving one team’s spreadsheet can be worth discussing without becoming an “enterprise analytics transformation.” The smaller, accurate version is easier to explain and defend. It gives the interviewer a clearer picture of what I might contribute next.

I build a small project around a real question

I begin with a problem I can explain without naming the tool. “I want to understand which types of support requests most often return to the team” is concrete enough. “I will build a dashboard using a popular technology” leaves the most important decision until later.

For a public portfolio, I choose public data with suitable usage terms or clearly labelled synthetic data. I do not move employer information onto a personal computer or into a public repository without the appropriate permission. Replacing customer names does not automatically give me the right to publish the dataset.

Then I identify the unit of observation. Does a row mean a ticket, a message or a status change? I inspect missing values, duplicates, date coverage and category meanings. If I misunderstand that layer, an attractive chart will only spread the mistake more efficiently.

The project should end with an answer, a limitation and a next step. For example, a synthetic sample may show more repeated contacts in one category. Without accounting for case difficulty, I would avoid judging individual employees. I might suggest reviewing the procedure and a sample of cases. That already resembles an analytical conversation.

What I would include in the portfolio

I would provide a short problem statement, data provenance, reproduction instructions, a few important checks and the findings. I would choose one clear chart over a gallery of every visualisation type the software offers. The reader should understand my reasoning without mounting an archaeological expedition through folders.

I would also introduce a small change in requirements. What happens when a new category appears or one month of data is missing? Does the solution still behave sensibly? Those changes are common in actual work. Explaining my response gives stronger evidence than a perfect screenshot based on a single prepared table.

The final recommendation needs a connection to the original question. If I started with repeated support contacts, I should finish with something relevant to that problem. Discovering that Wednesdays contain many rows might be interesting, but I need to explain why anyone should act on it.

For a starting exercise, my SQL histogram tutorial covers changes in aggregation level and edge cases. My guide to business KPIs can help frame the business question. I would then change the topic and data so that the project becomes a solution I have worked through myself.

I learn for the next task

I prefer to organise learning around the next piece of work. If I need to combine three monthly files, I practise the relevant transformation. If I need to count customers, I investigate grouping and identifiers. That makes it easier to tell whether the skill remains after the lesson closes.

I would initially choose a narrow set of tools matching the target work and project. A spreadsheet, SQL and one visualisation tool can already provide plenty to practise. The sequence depends on my starting point. I would not add five programming languages simply because someone placed them on an impressive career roadmap.

After a lesson, I try to reproduce the task without prompts, then change the data or a condition. If I can only complete it at the instructor’s pace, I need more practice. Watching somebody write excellent SQL establishes that they can write excellent SQL. My own ability still requires a separate check.

AI can help explain an error, propose an edge case or comment on a solution. I still validate the result using small examples I can calculate manually. My portfolio needs to show decisions I understand. During an interview, a chat window cannot take responsibility for my explanation when the conditions change.

A practical threshold for independence

I choose a task and ask whether I can start from a blank file, locate useful documentation, explain the steps and validate the result. I do not require perfect recall of every function. I do expect to know what I am looking for and why.

I also ask another person for specific criticism: which explanation is unclear, which conclusion goes beyond the evidence, and what breaks when the input changes? “Is my project nice?” often produces politeness. Questions about identifiable parts of the work produce improvements.

When feedback identifies several problems, I prioritise the ones affecting correctness and comprehension. A wrong customer count matters more than inconsistent chart colours. That order is worth practising because real analytical work also comes with limited time and competing demands.

I make the fit visible in my CV and interviews

I organise the CV around the role’s work while preserving the truth about my experience. Relevant tasks and projects appear early. Professional responsibilities and learning exercises stay clearly distinguished. Completing a course can support the story, but I do not describe it as a commercial client implementation.

For every important skill I want an example. “SQL” should lead to a conversation about what I calculated, which data I used and how I checked it. “Business communication” should have an audience, a question and an outcome. Labels are cheap, so the market has a generous supply.

I prepare a few short stories: problem, my action, result and limitation. I practise saying them aloud. I pay particular attention to “I”: what did I personally do, and what did the team do? I can acknowledge collaboration while making my own contribution clear.

When I do not know an answer, I explain how I would investigate it. I can sketch an example, identify documentation or propose a test. Invented certainty is expensive because it usually requires more invented answers. I prefer to demonstrate a sensible route towards a result.

Conversations and useful feedback

I would speak to people doing similar work about specific tasks. I might ask for feedback on one project description or how reporting works in their team. That helps test my assumptions and learn the vocabulary used in a particular business setting.

I would not expect every new contact to become a referral. I respect the other person’s time and show that I have already done some work. A short question with context is easier to respond to than a message asking a stranger to explain an entire career from scratch.

After an interview, I note what I could explain well and where I became vague. Even when the employer provides no feedback, I can often identify one question worth practising. I avoid inventing an explanation for the hiring decision itself when I do not have evidence.

I build a plan I can sustain

I would use the first stage for diagnosis: reviewing vacancies, inventorying experience and choosing a direction. The next stage would combine a small project with the most important skill gap. Then I would prepare the explanation, CV and a set of well-matched applications. These stages can overlap and take different amounts of time.

I schedule realistic blocks. If I have two evenings a week, I plan for two evenings instead of the fictional life of somebody who never sleeps or does laundry. Regularly finishing small tasks is more useful than designing a magnificent new timetable after each previous timetable collapses.

Each week I review outputs: a completed project section, an explained error, an improved description, a relevant application or useful feedback. Hours are secondary. A long evening at the computer can mean productive work or an elaborate method of avoiding the first task.

I account for transition costs, family responsibilities and rest. Leaving the current job should not be treated as a compulsory display of determination. A sustainable route can provide more space for learning than the pressure to accept the first available offer.

Comparing two possible offers

Suppose one role has “analyst” in its title but mainly involves manually updating fixed spreadsheets. Another role sits in operations but includes data-quality checks, conversations with report users and permission to improve the process. I would compare what I could actually learn over the next few months rather than selecting by title alone.

I would examine tool access, independence, support from an experienced colleague, frequency of data work and employment conditions. Anything unconfirmed becomes a question for the employer. “You can do analytics later” needs detail: which tasks, when, and who will help make time for them?

I would set a personal checkpoint too. After a few months, I would want to describe a useful report, an improvement or a resolved problem while respecting confidentiality. If the position offers no realistic route to that evidence, I would be more cautious about treating it as a career-change step, even if it is a perfectly reasonable job in other respects.

These criteria have different weights for different people. A predictable schedule may enable somebody with family responsibilities to study consistently. Access to an analytical team may matter most to someone else. I want the choice to follow my circumstances and confirmed information rather than the prestige of a new email signature.

When I adjust the direction

After another comparable set of applications, I return to the tracker. If the same problem remains, I change one significant element: target roles, project explanation or a specific skill. Changing everything simultaneously makes it harder to understand what helped.

I also review an adjacent role after taking it. Am I gaining data-related responsibilities? Can I learn from someone? Is my independence growing? If the answers remain negative, I look for another way to build experience. Passing months do not automatically perform the learning for me.

For today, I would choose one action: review five suitable vacancies, describe one task I have done, or ask a clear question of a small dataset. That creates material for the next step. This is how I approach a career change: decisions that leave me with more skill, evidence and understanding than I had before making them.