Getting Into AI: The Skills That Mattered and the Ones That Didn't

Start with the job, not the course

Before you learn anything, figure out what you'd like to do all day. Seriously. It sounds obvious, but I know people who spent half a year on deep learning and then realized they hated it. They wanted to work with business data and explain things to people. Totally different path.

“AI” is a huge umbrella. Somebody cleaning up delivery records for a logistics company is working in AI. So is someone training a model on protein structures. If you pick wrong, you'll study a lot of stuff you never use. I did exactly that, and I'm still a bit annoyed about it.

Python, unfortunately

I'd love to say you can skip it. You can't. Almost every library and every job listing assumes you can write it.

You don't have to be great. You just need to stop being scared of it. My own first script was unremarkable and broke in an unremarkable way, but fixing it taught me more than any tutorial.

The best practice is the dumb kind. A script that renames two hundred photos. A little program that adds up your monthly spending. They're not impressive, and that's fine. You're learning to read an error message without panicking, and that matters more than any syntax.

About the math

People bail here, so let me say it plainly: you need less than you think, but not nothing.

Statistics comes first for me. Not the heavy theory, just the instinct to ask “is this real, or did we get lucky?” A model that does 3% better on one test run might not be better at all. I've seen clean, well-written projects fall apart because nobody questioned the numbers.

Linear algebra and a little calculus can come later. You should know what a gradient is for, though you won't need to derive one by hand. If you're going toward research, that changes, and you'll need a lot more. Otherwise, learn it when a project forces you to. Everything I studied “just in case” was gone in a few weeks.

Data is a mess

Practice datasets are tidy because someone already did the cleanup for you. Real ones are awful. One column says “N/A,” the next says “none,” another is blank, and the dates are in four formats because four different people typed them.

This is where most of the hours go. Learn SQL early, since nearly every company keeps its data in a database. Learn Pandas. Learn to make a chart that someone can understand without you explaining it. If I had to choose between a person who's average with algorithms but really knows their data, and the opposite, I'd take the first one every time.

Don't jump to the fancy stuff

When a new model hits the news, everybody wants to try it immediately. Wait a few weeks. Go through regression, decision trees, overfitting, and why you never touch your test set until the end. It feels old, I know. But the big models are built out of these ideas, and once you've watched a simple one fail in an obvious way, the huge ones feel a lot less magical. Neural networks and PyTorch can come after.

What the work looks like now

A few years ago you'd train your own model. These days, a lot of jobs involve taking a model someone else built and getting it to do one useful thing. That means calling it through an API, writing instructions it actually follows, connecting it to a company's documents, and then checking what it says.

The checking part is the one that counts. These tools sound very sure of themselves even when they're wrong. Whoever on the team can spot that quickly is worth more than they look on paper. I wouldn't build a whole career on prompt writing, though. It's a handy skill, but it's not a profession.

The boring engineering

A model that runs in your notebook is a demo. A model that works for thousands of people on a rough Monday morning is a product. Learn Git. Write code that a stranger could read. Get a rough sense of how things get deployed to the cloud. No one posts about this, but it's often what decides who gets the job.

Stuff that isn't on any syllabus

Knowing what the actual problem is. Some of the worst projects I've seen were technically brilliant and completely pointless. Sometimes the right answer is “you don't need AI for this,” and it takes some nerve to say it.

Explaining things simply. If your manager asks whether it works, don't quote an F1 score. Tell them what it gets right, what it gets wrong, and who's affected when it's wrong.

Knowing some field well. A nurse, an accountant, or a farmer who picks up a bit of AI often does better than a pure programmer, because they already know which problems are real.

Thinking about who gets hurt. These systems make mistakes, and real people live with them. Ask that before you ship, not after.

And being a beginner, again and again. Whatever's popular now will look different in two years. You just have to be okay with that.

If I were starting over tomorrow

I'd spend the first month on Python with small, silly projects. Then I'd pick a messy dataset about something I care about, like cricket scores, monsoon rainfall, or old film ratings, and try to make sense of it. I'd pick up the basic machine learning ideas along the way, build a few models, and let some of them fail.

Then I'd choose a direction and make three or four projects I could show people. I'd write about them honestly, including the parts that went wrong. A post about a project that half worked tells an employer more than a certificate does. Last, I'd explain what I learned to a friend. They'll say “wait, why?” and you'll find out fast what you don't actually understand.

Do you need a degree?

It helps, especially for research roles. But I know people who came in from teaching, finance, design, even biology. Employers mostly want to see that you can do the work and think clearly. Where you learned it comes second.

Last thing

You're not going to feel ready. I still look up things I figure I should already know. So don't wait for the perfect plan. Pick one small thing this week and finish it. Then pick the next one.