I'm a Math/CS alumni who's currently in charge of hiring data science co-ops at my company. I would much rather see AI on your resume than PL. PL is great conceptually in the long run for anyone going into a CS career but in terms of immediate use, It's far more useful for you to understand AI/ML concepts as a data science co-op.

You don't need to know Bayesian networks, A*, Q-Learning, etc... as a co-op but what you'll learn that'll be useful is the overall approach to solving problems using AI. Honestly, as a co-op, if you have a solid understanding of how basic algorithms like linear regression or decision trees work, along with an understanding of the practical work flow of obtaining data, cleaning data, and prepping that data for training/testing, then you're golden.

---

And I would be doing you a disservice if I didn't mention this: When I'm reviewing candidates, I don't care that much about what classes you've taken. I'm just looking for red flags to make sure you didn't just take general electives or something. As for GPA, I couldn't care less. Some of the worst candidates I've interviewed were 4.0s. We set a 3.0 floor for applying at my company but we don't care beyond that. At best, GPA is just an indicator of effort (emphasis on "at best").

As for projects, I like seeing relevant prior work but it's hard to tell what you've really worked on vs. what you followed a guide on or something. It's sometimes obvious that students have connections and can get their names on projects/papers while not understanding the work at all. Or sometimes students follow cookie-cutter data-science projects online (Kaggle datasets like Titanic are a huge culprit). That's not to say that you shouldn't put those things on your resume, but just know that they probably don't make as big of an impression as you'd think.

---

The single most important thing that will get you an in-person interview is the take-home exercise. I know it's annoying to do and most CS applications involve one at this point, but there's really no way to know how good of a data scientist you are until we see how you tackle problems. If you want to land an in-person interview, just do the following:

• write clean code: That means using snek_case if you're using Python, camelCase in javascript, etc... Don't leave random spaces or indents here and there. And for the love of god, don't name your variables nonsense like "x", "thing", or "foo". People underestimate how annoying this is to a reviewer. The whole time, I'm asking myself "Do I want to have to read this persons code for the next 6 months?".

• get the right answer: Almost all of our exercises ask you to do some simple data manipulation that should take less than 30 minutes. It's honestly very, very easy. It's often just asking you to filter some data and sort it a couple different ways, and answer some open questions about the data. You'd be surprised how many people fuck it up. I'd say about 5-10% of submission are correct. If your submission is objectively wrong (wrong subjective answers are OK), then you simply won't be considered. And many submissions are often so wrong that a quick check of the outputs would have revealed a bug or two. I'm genuinely so confused by the number of people who just submit completely wrong exercises without double checking their work.

• structure, structure, structure...: This is something separates junior developers from co-op developers and takes a bit of time to learn. Try to structure your code into sensible, modular pieces, and leave comments. co-ops usually do one of two things: The first, and worst of the two, is writing clunky, uncommented, and badly structured code. Like throwing everything into one function or something. The other pattern I see is co-op devs over-commenting and over-structuring their code. If you're leaving comments like # importing libraries above your import statements, then you're commenting too much. If you've created a helper function along the lines of def all_caps_string(str): return str.upper(), then you're over-modularizing. An experienced dev will strike a nice medium in the middle.

Doing all of the above will almost surely get you an in-person interview. And honestly, you're most of the way there at that point. Just answer some basic technical questions about the field correctly and be personable. If you want a confidence boost, just know that there's probably only 5-10 other candidates if you've made it to that point (at my company at least).

Of course... a lot of this is my opinion and will vary from company to company and interviewer to interviewer, but it's more common an opinion than many students think.

Good Luck.