SOP Critique - length & intro

Post Reply
Posts: 6
Joined: Sat Dec 08, 2018 3:21 pm

SOP Critique - length & intro

Post by sphonino » Sat Dec 08, 2018 3:31 pm

Hi everyone, I've written my second draft of my SOP but it's frankly overly long. Hoping for some help on cutting it down and also any other feedback people have. Greatly appreciate your time.

My goal has always been to learn, so I am applying to graduate school in order to work towards that goal. I have an endless, almost infuriating number of questions, a compulsion to understand some small part of everything around me, so it took me a while to decide to study physics – there are so many things I want to learn and desperately little time. However, physics is simply the most compelling field to me. It is the fundamental element of all these other fields and so to me, the greatest beauty is that every phenomenon we observe arises from some small set of rules.

My time in university reflects this range of interests. I began my undergrad as a physics and astronomy major intending to do cosmology research, however, I ended up with an electrical engineering minor and studying particle physics instead. I've enjoyed myself greatly in these topics, but I hope to return to my original aspiration of researching observational cosmology in graduate school.

On paper, my background is more like that of an electrical engineer than that of a physicist. Indeed, the nature of engineering work appeals to me, as I enjoy the process of designing and building something from start to finish, with all complications, fixes, and collaboration. Throughout college, I have been trying to find a way to do both – pursue physics goals, but focus on hardware projects. I accordingly found working on detectors very fulfilling and ideally, I would continue similar work in graduate school. While my experience is with particle physics, I find that electronics skills can be widely applied.

The first university group I joined was BURPG, the Boston University Rocket Propulsion Group. As part of an effort to reach the Karman line, (100km above sea level), the team is designing and building a 30-ft single stage liquid propellant rocket. During my freshman and sophomore year I designed, built, tested, and/or programmed PCBs to act as flight computers, data acquisition systems, and anything else as was needed. Some of these were used in the test campaign of a 2500 lb-thrust liquid rocket engine named Lotus which was designed by BURPG members. I was also heavily involved in conducting ignition tests of Lotus and the installation of necessary instrumentation.

I learned a great deal during my time on BURPG, as there are few environments where a college student can be independently assigned such complex projects and also be given enough resources, expertise, and guidance to complete them safely. When things went wrong, there was no professor to consult. Instead, I either worked towards a solution myself or with colleagues, often with a short deadline. We took our work extremely seriously, knowing the risks involved in what we were doing. The professionalism and independence I gained from being on the rocket team have become indispensable to me. But perhaps most valuable to me was the resourcefulness. Specifically, I can look at something that isn’t working and can instinctively start considering the possible issues, figuring out how to test each option.

During my freshman and sophomore year, I also worked at the EDF (Electronics Design Facility) in the physics department. There, I worked on electronic systems for at Boston University research groups and for various physics experiments, including CMS, ATLAS, and g-2. The work in the EDF was more rigorous than the work I did in BURPG, as I was integrating my work into an already existing, complex architecture. In BURPG, I had learned how to design electronics systems holistically, as I was required to maintain the entire DAQ system for our ignition tests, as well as design and test PCBs from scratch. By contrast, in the EDF I got to work within existing software/hardware structures that were more complex and required more care and expertise. However, I was given the support I needed from my supervisor Dan Gastler and director Eric Hazen.

With all of this experience, I served as a TA for the Electronics Lab course in the physics department during my junior spring semester after being recruited by the instructor, Prof. Larry Sulak. This course was aimed at giving physics undergraduate students the necessary electronics experience to work in experimental physics. Students were given a crash course on implementing useful analog circuits using transistors, op-amps, and the like, the intent of the course being to give students a feel for the process of assembling, testing, and fixing circuits independently. I helped students understand the circuits they were building and their usefulness. I also guided students through debugging their circuits, hoping to instill good habits and intuition.

At the end of my sophomore year, I felt that I had gained enough electronics experience and wanted to begin applying myself in physics projects. I began research with Prof. Ed Kearns and Prof. Robert Carey in particle physics. I joined the LArIAT (Liquid Argon TPC In A Testbeam) collaboration, working on a small liquid argon R&D experiment located at Fermilab. During the summer before my junior year, I went to Fermilab to help with the installation of 3mm wire planes into the LArIAT TPC. When I arrived, I didn’t even have a chance to put away my luggage before I had a soldering iron in hand and was fixing down wires, resistors, and capacitors to the new wire planes. Throughout the installation we ran into issues, and I got to work with my collaborators to try and understand and address each of them. Once we successfully installed the new wire planes into the detector and began taking data, I presented to the LArIAT collaboration on the entire month and a half process. This experience cemented my goal of doing hardware work for physics detectors. For the rest of the summer, I worked with Jen Raaf, a co-spokesperson for LArIAT on another project – a small scale pressurized gaseous argon TPC as a proposal for the far detector for DUNE. I worked on simulations to determine how the interaction rate of neutrinos with argon atoms changed as the pressure in the TPC vessel increased while minimizing interactions in the steel vessel.

After that, I began research on the effect of wire spacing on TPC data and read out. This work is intended to help with future large TPC design, such as with DUNE in order to optimize their resolution while minimizing electronics costs and installation complexity. LArIAT had previously taken data using wire planes with 4mm and 5mm spacing. Using the data taken using 3mm, 4mm, and 5mm wire spacings, I did a signal to noise analysis of the wire planes, and am now working to improve Monte Carlo simulation of raw wire signals read out from the TPC in each wire spacing. This research has been my first time doing any significant software work beyond serial communication and embedded software, and I have learned a great deal about working with large software suites.

(specifics on university)

User avatar
Posts: 241
Joined: Sun Sep 23, 2018 6:37 am

Re: SOP Critique - length & intro

Post by Nishikata » Sun Dec 09, 2018 2:38 pm

I would skip the first and second paragraph. Start directly with the third. Your relevant introduction starts there.

What you wrote here is definitely a long list of experience. It is nice to have in CV but your SOP should be tailored for each uni that you apply to. That means for some uni you should take certain paragraphs out of the statement.

I would also take out the TA paragraph as you spent most of it explaining the course you’re TA-ing. Unless you encountered special events during your service, which i think you didn’t, the TA experience does not bring anything new that guarantees a paragraph being entitled to it. You can just put it in your CV.

For most of us, our experience don’t make a good chronological order. Usually we do whatever project we get, therefore it is better not to write them in this order. Just go with experience 1, 2, 3 unless there’s really a continuation for your subsequent projects.

Post Reply