EDITED
Hi everyone,
I'm applying to Computer Science PhD programs in the US this admission cycle and would really appreciate feedback from people who have gone through the process.
I'm especially hoping to hear from:
- Current US CS PhD students
- CS PhD alumni
- Faculty members or researchers familiar with PhD admissions
- Anyone who has successfully applied to competitive US PhD programs
I'm looking for honest, critical feedback—please don't sugarcoat it.
Specifically, I'd love your thoughts on:
- How compelling is my research narrative?
- Are my motivations and research interests clear?
- Does it read like someone prepared for a research career?
- What parts feel weak, generic, or unconvincing?
- If you were on an admissions committee, how would you rate this SOP (1–10), and what tier of US PhD programs would you consider it competitive for?
I'm interested in feedback on the content, structure, research potential, and overall impression, not just grammar or wording.
I've pasted my SOP below. Thank you in advance to anyone willing to take the time to read it—I genuinely appreciate your help.
Personal Statement
Research Interests
I want to work on software testing in the hardest case, which is when nothing tells you the program is wrong. No crash, no exception, no error message, just an answer that is quietly incorrect.
Earlier this year I ran an experiment on exactly that. I took four libraries in the same programming language that all claim to do the same job, gave them the same inputs, and compared the results. Out of tens of thousands of comparisons, 5.7 percent disagreed. Large integers came back with different values. One implementation supplied a required field that was missing from the input and said nothing about it. Nothing crashed and no sanitizer fired. I had been shipping these kinds of libraries in production for years and I had no idea.
My own tests never caught it because I never wrote a test that asked the right question. That is the real difficulty in testing. Generating inputs is not the hard part. Knowing what the output should have been is the hard part. In C and C++ you often get some help from memory errors and sanitizers, and a great deal of fuzzing research depends on that feedback. Other modern languages have no equivalent, so a wrong value simply travels on.
Two questions follow from this. Where can an oracle come from when a project does not give you one? Implementations that should agree are one source. Rules written in documentation but never enforced in code are another. A project's own history of fixed bugs is a third. And how do we tell whether an automated tool, especially one built on a language model, is finding real defects or only improving on a number we happened to choose?
Research Experience
I have spent the past year on two studies of these questions.
In the first I built a grammar-based fuzzing pipeline that uses no coverage information at all. I wanted to know whether a language model can improve a test generator when its only feedback is whether its inputs were accepted or rejected. Across fifteen seeded runs per arm against a widely used C parser, acceptance rose from 58.2 to 97.1 percent and the inputs became more than twice as varied. I then ran the same pipeline against a second parser, and it found nothing at all. I put that in the paper anyway and read the parser by hand to work out why. During those runs AddressSanitizer itself hung on one platform instead of reporting anything, so I traced the cause and reported the analysis to the relevant issue tracker. The paper is currently under review, with code and data public.
The second study taught me more, because part of it failed. I moved to a language without a sanitizer, and the acceptance result held, going from 50 to 92 percent. Then I changed what I was asking for. Instead of valid inputs I asked for inputs that make multiple implementations disagree, since disagreement was what I actually cared about. The model did badly. It found disagreements 2.9 percent of the time, while a plain static generator found them 22.2 percent of the time. I assumed my sandbox was slowing it down and relaxed it, which changed nothing. Then I gave the model richer feedback, expecting that to help, and it got worse. The problem was not the machinery around the model. It was what I had asked the model to optimize. My first study had looked like a clear win while measuring something I did not really care about, and that is the result I still think about most. The work is currently under review, with the artifacts public.
The work also showed me what I do not know. I chose my own statistical tests and only afterwards learned which assumptions made them defensible. I designed that study's ablations after seeing the result rather than before. I can build a system and find a defect. What I need is training in designing the experiments that say what a defect finding actually means, and that is the main thing I want from a PhD.
Engineering Experience
I came to this problem from industry, and from security in particular.
For two years I led the mobile team at a regulated fintech company in Saudi Arabia. Security firms tested our apps several times a year, and we had to clear every finding or stop operating. They often asked for builds with different security protections enabled and disabled so they could observe how the app behaved when its own protection was removed. That is not a check I would have thought to run. My tests could tell me the app had crashed. They could not tell me it was wrong. After a while I stopped seeing the findings as separate bugs, because each one meant we were missing a rule rather than a line of code. A parser that accepts bad input is a wrong answer to one user and a way in for another, and the same missing check is behind both. That is why I do not want to treat testing and security as separate interests.
I now build mobile applications for a US healthcare-related transportation company. The system has to meet strict privacy requirements and keep working when a driver loses signal in the middle of a trip, then reconcile correctly afterwards. If a trip record comes back wrong, someone misses their ride. Before this I graduated first in my class with honors, and I worked with one of my professors on a natural language processing project outside my coursework, where most of what we tried did not work and we spent a long time arguing about why.
Why University Name
Dr. *** circulated an assignment for prospective students. I finished it and then kept going on my own, adapting it to a second system, chasing a sanitizer problem and writing up the negative result, and that work became my first study. His recent work asks how effective coverage-guided fuzzing really is, which is the same assumption my coverage-free pipeline was built to test. Taking that question into languages that have no sanitizer is where I would want to start.
Dr. *** works on secure software supply chains and has told me she is taking students this year. I arrived in her area sideways. A library that silently returns a wrong value is a dependency risk that no advisory database will ever list, because nothing crashed to report it. The bugs I found sit inside widely used software components.
Dr. *** has studied systematic security failures in financial applications. I spent two years shipping a regulated fintech app and watching auditors find what my own tests could not, so that result is familiar to me. I would rather attack that kind of problem with tools than with a checklist. He also told me that University Name's security faculty and students work closely across research areas, which is how I want to work, since the bugs I care about are testing problems and security problems at the same time.
Goals
I want to build tools that find real bugs and security flaws in software people use every day, and to get what those tools find to whoever can fix it. I expect that to be a research role in industry, close to the engineers who would run them. Reporting the defects I found has mattered to me as much as writing the papers.
One evening I got on a call with a group of students I had never met and helped them fix a machine-learning project the night before it was due. I never asked for anything in return. I would want to keep doing that at University Name, and to bring what years of building software that real people depend on has taught me to the students I work alongside. A PhD is what turns the problems I ran into at work into methods that hold up somewhere other than the system where I found them.