With your proof map in hand, it’s tempting to sketch an exciting next project, such as “Train a neural network to classify images of plant diseases.” It sounds impressive, and it would be a fun way to spend a few weekends.
Now hold it up against a typical requirements map for a junior data analyst, which might list SQL, cleaning messy data, spreadsheets and dashboards, and explaining findings to nontechnical people. Which of those rows does the plant project cover? Hmm, maybe a bit of data cleaning, if you squint. Everything else stays empty.
How a Reviewer Reads a Project
To a hiring manager, your project is a sample of how you’d work on their team. In a couple of minutes, they’re trying to answer four questions:
- Is this a real problem, or one a tutorial handed out?
- Did they finish it?
- Does it look like the work we do?
- Which decisions were theirs?
Size and fashionable technology barely show up on that list. Two or three finished, relevant projects that you can explain line by line say more than a dozen tutorial clones or one ambitious project that doesn’t run. Al Sweigart makes a similar case for finishing small things in Advantages of Completing Small Python Projects.
