During fall recruiting season, I was writing my own resume. For the project experience section, I had two tools each draft a version, and then took both versions to a senior who had served as an interviewer for feedback. Here are his exact words.
Version A: WorkBuddy template version
"Responsible for the design and implementation of ×× experiments, mastered ×× methods, and possess strong ×× abilities." Senior's comment: The wording is fine, but this passage could apply to any student in materials science—there are no numbers and no details. As soon as the interviewer follows up with "How many sets of experiments did you specifically run, and what was the error?", it falls apart.
Version B: MuchSci material version
The approach was different: I retrieved the experiment records and data reports I had accumulated over the year from the knowledge base, selected two projects according to the target role, and the quantified descriptions came directly from the records—"Optimized the preparation process, increasing the yield from 71% to 89%." Senior's comment: "This is the kind of writing that would make me follow up, and he would have an answer."
The gap between the two versions is not in the writing but in the source material: WorkBuddy only knows the impressions I described orally, while MuchSci reads the facts I have recorded. A resume is not written; it grows out of records—I have verified this again and again during interview season.
A quick share of the pipeline as well: material collection, selecting highlights, quantified descriptions, final draft output, and consistency of wording. The last step is very important—your interview answers need to match the resume, and the original records in the knowledge base are your backing.