Perla › Manifest › a job in data
Manifesting a Job in Data the query, then the caveat
You picture a slick dashboard getting praised in a meeting. The actual day is a dataset full of duplicate rows, a query that finally runs after three failed attempts, and a caveat you insist on including even though it complicates the story.
- A full script for a job in data, written in the present tense and ready to read tonight.
- Shorter versions — one for falling asleep, one for the morning, and one line to carry with you.
- How to use it: No script cleans the dataset, writes the query or gets an offer sent — that is real technical skill, a portfolio and applications, and this page names that plainly.
- The common mistake: Picturing only the polished dashboard and the praise in the meeting while skipping the unglamorous cleaning and the caveats that make an analysis honest sets you up to produce work that looks good and misleads someone, which tends to catch up with you fast in a real data role.
The script
Read it slowly, in the present tense, as though it has already happened. It is written to be spoken aloud, but silently is fine.
I open the dataset someone's asked me to analyse and it's messier than the request implied, duplicate entries, inconsistent date formats, a column that means two different things depending on who entered it, and cleaning it properly takes longer than the actual analysis will. I don't shortcut this part, because a clean analysis built on dirty data is worse than no analysis at all. The query fails twice before I catch the join that was quietly duplicating rows, and getting it right on the third try is its own small, specific satisfaction. The result is interesting but not simple, an effect that holds for one segment and not another, and in the write-up I include that complication honestly rather than smoothing it into a cleaner headline number that would be easier to present but less true. In a meeting, someone wants the exec-summary version, one number, and I give it to them along with the one caveat that actually matters, briefly, without over-explaining. A colleague asks how I found the join bug and I explain it plainly, because sharing that kind of thing is part of what makes a team actually good at this. I close my laptop having made something true exist that took real, unglamorous care to get right.
Shorter versions
Two for the ends of the day, and one line to carry through the middle of it.
The join bug got found and fixed, the query runs clean now, the caveat that mattered made it into the write-up instead of getting smoothed away. Nothing about tonight needs rechecking. I let the dataset stay closed, its mess sorted for today. The number I gave them was true, not just simple. That's enough to close the day on.
I open yesterday's query fresh, checking it still runs clean before building on it. Whatever mess the day's dataset brings, duplicates, inconsistent formats, I won't shortcut past it just to get to the interesting part faster. I am not chasing a slick dashboard moment. I am doing careful, honest work with numbers that actually deserve to be trusted.
The join bug quietly duplicating rows finally got found on the third try.
How to use it
No script cleans the dataset, writes the query or gets an offer sent — that is real technical skill, a portfolio and applications, and this page names that plainly. Read this before a technical interview or a take-home task, to settle into the ordinary discipline of the work, the cleaning, the caveats, rather than the polish of a finished dashboard, and let the actual practice and portfolio carry their own real weight.
The mistake to avoid
Picturing only the polished dashboard and the praise in the meeting while skipping the unglamorous cleaning and the caveats that make an analysis honest sets you up to produce work that looks good and misleads someone, which tends to catch up with you fast in a real data role. The other failure is rehearsing an interviewer's approval instead of your own comfort with messy, ambiguous data. Keep the scene in the cleaning and the caveat, and let the portfolio carry the rest.
Questions
Do I need a statistics or computer science degree for a data job?
Not always — many analysts and data scientists come from varied academic backgrounds, though strong numerical reasoning and technical skill matter regardless.
What's the difference between a data analyst and a data scientist?
Roughly, analysts focus more on interpreting existing data for decisions, while data scientists often build predictive models, though the line blurs by employer.
How important are caveats and limitations in real data work?
Very — a number presented without its limitations can mislead a real decision, which is why honest, experienced practitioners include them as standard practice.
Have this written about you
The script above is written for anyone. Perla asks about your actual situation, writes it as a present-tense narrative and reads it back to you — in a calm voice or your own, recorded once. One ritual instead of ten apps.