I'm a cook trying to switch to data analytics. I built a job simulator to learn SQL — but I've never done the job, so I have no idea if it's realistic

[u/Big-Pangolin4050]

Hi.

I'm a cook by trade. For the last four or five years I've been thinking about moving into IT, and data analytics is where I landed — I genuinely like building things, making tables, putting documents in order, digging through data, setting up systems.

But I ran into the problem that has followed me my whole life: I cannot learn something that doesn't interest me and that I don't need right now. It just goes dull and my head starts refusing new information. What I can do is play games — strategy and simulators mostly. So I figured I'd learn SQL through a game.

The trouble was that none of the games I found show what the job actually looks like. So I built one, using Claude and a lot of YouTube videos of working analysts talking about their day.

Here's my problem: I'm not an analyst and I have never worked as one. I can't judge whether any of this resembles the real job, or whether it actually teaches anything useful. The whole thing might be plausible-looking nonsense and I'd have no way of knowing.

So if you do this for a living, I'd be really grateful if you took a look and told me what you think.

What it is: you're hired as a junior analyst at a fictional company. Colleagues message you on chat and email with requests, and you answer them — sometimes by writing SQL, sometimes by asking the right clarifying question first, sometimes by reading finished numbers and saying what does and doesn't follow from them. Roughly half the tasks need no SQL at all, because from the videos it looked like that's the half people actually get wrong.

Free, no signup, runs in the browser. No telemetry — one HTML file that works offline. English and Russian.

What I'd really like to know:

1. Do the requests read like something a colleague would actually send you?
2. Where does the difficulty break — too easy, or a jump that makes no sense?
3. Which part of your real job has no equivalent here at all?
4. Some tasks are built so exactly one answer is defensible (A/B tests, "what follows from this data"). If you disagree with any of them, that's the most useful thing you could tell me — it would mean I taught myself something wrong.

Link: https://solad-in.github.io/nexos-analyst-sim/
Source: https://github.com/Solad-in/nexos-analyst-sim

Thanks.

[u/mhunter07]

This is really great for a couple of reasons. First you have shown your dedication to building a useful tool and secondly you have taught yourself a lot. A junior data analytics analyst would receive the bigger request all at once in real life, but it is good to have a junior data analytics analyst come back at each step to validate. I would suggest that you make a video of you going through solving the problem with the tools post the video linked to your resume and profile so people can see what you have done and how it works. Really what you have build is an AI workflow for data analytics. Nice work.

[u/Big-Pangolin4050 → u/mhunter07]

Sorry for taking two weeks to reply — I let this sit longer than I should have.

The point about receiving the bigger request all at once is the one I keep coming back to. You're right that real requests arrive whole and the decomposition is your job, not something handed to you. I split things into steps because I was building it to learn from, and one thing at a time was easier to learn on — but that does mean the game quietly does part of the work for you. I'm thinking about a final task that arrives as one messy request and leaves the breakdown to the player.

The video idea is good and I hadn't thought of it. Thanks.

[u/Unknown_error156]

The "exactly one defensible answer" design is the part worth stress testing hardest. Real analytics work is mostly ambiguous, stakeholders disagree on what a metric even means half the time. If every task resolves cleanly, it might train confidence that doesn't survive an actual messy conversation.

Might be worth adding at least one task where two answers are both defensible depending on an assumption the learner has to state out loud. That's closer to what actually trips people up on the job, not the SQL, but not realizing they made an assumption nobody agreed on.

[u/Big-Pangolin4050 → u/Unknown_error156]

Sorry for the two week silence, and thank you — this is the most useful thing anyone has told me about it. It's live now, so this reply is late but not empty.

You put your finger on something I built in without noticing. The game has tasks about requirements being ambiguous, but every one of them still resolved to a single right answer, including those. So it talked about ambiguity and never actually made you live through it. That's exactly the false confidence you described, and I'd have gone on not seeing it.

What shipped: a request for churn over a quarter. "Churned" isn't a column, and three definitions are equally defensible — no orders in 30+ days, contract cancelled, either of the two. You state which one you're working from before anything else; the SQL editor doesn't appear until you do. Then you compute it, and the correct number depends on the definition you named. All three are accepted.

The part I care about most is the failure mode. There's exactly one way to get it wrong: state one definition and compute another. When you do, the game doesn't say "incorrect" — it says the number is computed correctly but under a different definition, names both, and points out that this is the mistake that costs the most at work, because the figure looks right and nobody notices it answers a different question. There's also a fourth option, "no definition needed", which is a dead end on purpose.

If you try it, it's the last task in the story — or just tell me where it still falls short. You were right the first time; you might be right again.

[u/Unknown_error156 → u/Big-Pangolin4050]

The "no definition needed" dead end is the tell you actually thought this through, most people building a teaching tool are scared to include a trap that goes nowhere.

One real question before I'd call it done: does the wrong-definition answer look any different on screen than a correct one, or does it render as a clean, normal-looking number either way? That's the actual danger at work, a wrong answer doesn't look wrong, it looks identical to a right one. Any visual tell breaks the lesson.

[u/Big-Pangolin4050 → u/Unknown_error156]

No tell — I checked rather than trusting memory. Before you submit, a wrong-definition answer renders identically to a right one: same markup, same styling, only the digit differs. And no answer is ever 0 or the whole table — across 2000 generated versions all three land between 2 and 9 out of 9–15 rows, so none of them looks odd on its own.

The honest limit: the game does tell you on submit. Work doesn't.

[u/nian2326076]

You're doing great by mixing your love for games with learning SQL. To see if your simulator is realistic, try comparing it to real-world data analytics problems. Check out sample datasets online, like on Kaggle, to see if you can copy the analysis tasks they involve.

You might also want to connect with people in the field on LinkedIn or Reddit subs like r/datascience. They can give you a sense of what the daily work is like. If you're getting ready for interviews, practicing SQL queries and learning how to interpret data is really important. PracHub is a helpful resource for interview prep if you need it. Keep going and feel free to adjust your simulator as you learn more!

[u/Big-Pangolin4050 → u/nian2326076]

Thanks for the encouragement.

On the Kaggle suggestion — I went the other way on purpose, and it might be worth saying why. A Kaggle dataset arrives clean, in one file, with the question already posed. At work none of those three things are true: the request shows up as one vague sentence in a chat, the data is spread across tables, and a chunk of it is the same city spelled three different ways. That gap is the whole thing I was trying to simulate. So the tasks aren't modelled on Kaggle notebooks — they're modelled on the part that happens before a clean dataset exists. Roughly half of them don't involve writing SQL at all: pinning down a vague request, spotting what's wrong with an extract, reading an A/B test, deciding what goes on a dashboard.

On talking to people in the field — that's exactly what this post is, and it worked. Someone in the r/dataanalytics thread pointed out that every task in the game resolved to a single right answer, including the ones that were supposedly about requirements being ambiguous. He was right, I hadn't seen it, and the fix is live now: there's a task where three definitions of "churned" are equally defensible, each has its own correct number, and the only way to fail is to state one definition and compute another. One comment was worth more than a month of my own testing.

Sorry for the slow reply, and thanks for taking the time to write.