Writing a Data Science Intern Job Description That Actually Works
I spent a few years hiring interns before I figured out what was going wrong. The problem was never the candidates. It was the job description sitting on the careers page, packed with buzzwords that made zero sense to anyone reading it. Most of these documents are copy-pasted from last year's template with the titles changed. I've seen "proficient in TensorFlow" require four lines down from "Python scripting," which tells me whoever wrote it didn't know what they were hiring for either. The first thing you need to do is figure out what work this person will actually do. Not what sounds good on paper. What work. Will they be cleaning messy CSV exports from a legacy system at 2 AM? Will they be building dashboards in Tableau for a stakeholder who changes requirements weekly? Or will they actually get to write some model code? I wrote a job description once that listed scikit-learn, XGBoost, Docker, and cloud deployment as requirements for a three-month summer internship. We got forty applications. Twelve qualified on paper. Only one could actually deploy anything. The rest had completed online courses where the data was already clean and the model already fit. I realized pretty quickly that I'd written the requirements for a mid-level engineer role, not an intern position. The workaround was to split the JD into "must-have" and "nice-to-have" and move everything that required production experience to the optional section. The quality of applicants jumped significantly after that.
What to Include and What to Leave Out
A functional Data Science Intern Job Description needs the same core sections as any other posting, but the content has to be calibrated for someone who has maybe six months to a year of hands-on experience, if that much. Here's the breakdown of what actually matters. Role overview. This should be two or three sentences. State the team, the general domain, and what success looks like by the end of the internship. Something like: "You'll join the pricing analytics team and build out a feature pipeline for our churn model over twelve weeks." That tells an intern exactly what to expect. Vague descriptions like "work on cutting-edge ML projects" tell them nothing and attract the wrong people. Technical requirements. List the tools your team actually uses. Python or R, SQL, whatever. Be specific about the level. "Familiarity with pandas and NumPy" is honest. "Expert-level programming skills" is dishonest and you will get rejected applications from people who don't meet that bar and applications from people who do. Don't ask for both. Pick one lane.
Project scope. This is where most job descriptions fail. Interns need to know what they'll be building. Name the project or describe it clearly. If the project doesn't exist yet and you're still figuring it out, say that. Honesty here saves everyone time. "You will work on exploratory analysis and prototyping for an undefined customer segmentation project" is better than hiding behind "contribute to strategic initiatives." Soft skills and learning expectations. interns are hired partly because they're eager to learn. Mention mentorship, code reviews, and team collaboration. If there's no mentor assigned, say so. If interns are expected to figure things out alone, that's a different kind of internship and you should be upfront about it. Logistics. Location, remote or hybrid, duration, compensation range. Compensation transparency is increasingly expected and in some places legally required. It also filters out people who can't commit for the stated period. I've seen internships fall apart because the student accepted another offer with better pay after they'd already committed. Put the salary range in the JD and you avoid that entire conversation.
Get the Full Details
Common Mistakes That Make Intern JDs Obsolete Instantly
I've seen the same errors repeated across dozens of postings. The most expensive one is over-promising on technical depth. A candidate spends two weeks learning Spark because your JD mentions it, arrives on day one, and never touches Spark again because your actual work uses pandas. That's wasted time on both sides. Another mistake is copying the requirements from a full-time senior role and dialing the title down to "intern." The JD becomes a wish list that no intern can satisfy. You end up either getting no applicants or applicants who are severely overqualified and leave after two weeks because the work is too simple. Neither outcome helps anyone. There's also the buzzword stacking problem. Listing Python, SQL, Machine Learning, Deep Learning, NLP, Computer Vision, AWS, Docker, Kubernetes, and Tableau in the same posting makes it look like you're hiring a data science team, not one intern. I once worked with a team that put "strong communication skills" as a requirement for a backend-focused modeling role. The person they ended up hiring was brilliant at code but couldn't explain their work to anyone on the product team. You should match the requirements to the actual daily work, not the aspirational version of the role.
The Hidden Section Nobody Talks About: Prerequisites vs. Requirements
There's a difference between prerequisites and requirements that most JD writers don't make clear. Prerequisites are things the intern should know before starting. Requirements are things your team will help them develop. A well-written JD separates these. For example: Prerequisites: SQL, basic Python, comfort with statistical concepts. These are baseline expectations. If a candidate lacks these, they'll struggle in week one regardless of how good the mentorship is. Requirements: Experience with A/B testing frameworks, familiarity with our internal dashboarding tool, understanding of version control workflows. These are things you'll teach. The intern doesn't need to know them beforehand. In fact, listing them as hard requirements will scare off good candidates who haven't had the opportunity to work with those tools yet.
I learned this the hard way when I posted an intern JD that listed our proprietary internal tooling as a requirement. Three qualified candidates withdrew after realizing they'd never used it. The tool was something we trained people on in their first week. By listing it as a requirement, I'd essentially filtered out the people who would have benefited most from the role.
Where to Post It and How to Screen
The JD is only half the equation. Where you post it determines who sees it. University career centers, LinkedIn, Indeed, and specialized platforms like Kaggle or GitHub Jobs reach different audiences. LinkedIn and Indeed are the broad net. Kaggle and GitHub are where you find people who are already doing the work outside of school. If you want someone who builds projects on their own time, post where those people hang out. Screening should start with the resume but shouldn't end there. A technical screen—something practical, not a whiteboard interview—catches the gap between what someone claims on paper and what they can actually do. I've used a simple take-home exercise: provide a messy dataset and ask for a brief analysis with conclusions. It takes about thirty minutes for the candidate and five minutes for you to review. It reveals more about their actual ability than any five years of coursework listed on a resume. The data I'm working with is current through mid-2026, so the landscape of what companies expect from interns may have shifted since then. If you're writing a JD right now, check that your tech stack requirements match what's actually in use at your organization. JDs that reference deprecated tools or frameworks that haven't been standard in years tend to attract candidates who are studying outdated material.
