Choose the project you can defend
A small project you understand is better interview material than a large team project whose methods you cannot explain. Berkeley recommends connecting your experience to the role; choose the part that matters here, whether analysis, testing, design or coordination.
Prepare one short walkthrough and the detail behind it. You should be able to answer why you chose the method, what an alternative would have changed and which work was yours.
Sources[1]
A complete fictional walkthrough
'For a class project, I built a dashboard to compare bus-route punctuality using a practice dataset. My part was cleaning the records and calculating the percentages. I initially compared the share of recorded trips that were on time, but noticed that one route had many more missing outcomes. I separated missing trips from known late trips and showed both the punctuality rate and data coverage. The dashboard could compare the observed records, but it could not establish that one route was more reliable across all trips. My next check would be to find out why those outcomes were missing before recommending a route.'
This is an original teaching example, not an actual transit study or work history. In your own answer, identify the real dataset, your contribution and the checks you performed.
The numbers behind the limitation
Here is a small version of the fictional dataset. 'Observed punctuality' uses only trips whose outcome is known.
| Route | Total trips | Known outcomes | On time | Missing outcomes | Observed punctuality |
|---|---|---|---|---|---|
| A | 100 | 90 | 81 | 10 | 81 ÷ 90 = 90% |
| B | 100 | 50 | 48 | 50 | 48 ÷ 50 = 96% |
Be ready to explain what would change the conclusion
B looks better among observed trips, but half its outcomes are missing. If every missing trip were late, the all-trip on-time shares would be 81% for A and 48% for B. If every missing trip were on time, they would be 91% and 98%. These are bounds from the invented data, not estimates of what really happened.
A useful follow-up is: 'Why not treat every missing record as late?' Answer: that would turn an unknown outcome into a known failure. You can show that assumption as a scenario, but should not hide it inside the headline statistic.
For your own project, prepare the equivalent explanation. A design project might have untested usability assumptions. A business recommendation might depend on a cost estimate. The interviewer should be able to see where your evidence ends.
Explain what your project cannot establish
A project explanation should include an important limitation, not only a result. In our fictional comparison-group case, the difference in changes is 12 units. Without a defensible counterfactual, that arithmetic is not automatically a causal effect. In the hardware exercise, passing functional tests does not establish physical timing or production reliability.
Choose a limitation that actually matters to the decision. Explain what additional evidence or test would address it and what would still remain uncertain. This demonstrates that you understand the work rather than merely remember its output.
Keep your individual contribution explicit. A course project, simulation or independent work sample does not become an employer assessment or client engagement because its subject is professionally relevant.