I am always looking for curious, persistent, and motivated students to join my group at Harvard SEAS, both as Ph.D. students and as research interns. We work on storage systems, databases, and systems for machine learning, with a particular interest in efficiency, scalability, and reliability.

You do not need to arrive as an expert. You do need to enjoy building things, following evidence, and staying with a difficult problem after the first few ideas fail.

What the work feels like#

Systems research rewards a particular temperament: the willingness to read a flame graph for an hour, distrust your own design until the numbers support it, and find genuine joy in deleting code.

The work moves constantly between levels. On one day, you may be asking a broad question about how storage systems should be designed. On the next, you may spend six hours discovering that an experimental result came from a unit conversion bug. Both are research. The broad idea matters, but so does the patience to make every layer beneath it correct.

Progress is rarely linear. A failed experiment may invalidate a week of work, but it can also reveal that the original question was wrong. The students who thrive are not those who avoid being wrong. They are those who turn being wrong into information.

The best systems students I know are not the ones with the most background. They are the ones who cannot leave a surprising measurement alone—and who are willing to challenge their own assumptions.

What I look for#

Evidence that you build#

A class project, an open-source contribution, a research prototype, or a tool you wrote because something annoyed you can all be strong evidence. The project does not have to be famous or polished. I care about what you built, the decisions you made, what broke, and what you learned.

A concrete artifact tells me much more than a list of technologies on a resume. Systems research requires engineering, and the best way to develop engineering judgment is to build systems that encounter reality.

Curiosity that survives the first answer#

Good research begins when an ordinary result becomes difficult to explain. I look for students who ask why a measurement is surprising, what assumption it violates, and what experiment would prove their current explanation wrong.

Curiosity is not simply having many interests. It is the inability to stop at an answer that does not make sense.

Comfort with being wrong#

Research is a sequence of small failures: a hypothesis does not hold, a design is slower than the baseline, or a result disappears when the experiment is fixed. None of these is a personal failure. They are evidence.

I value students who report bad news early, change their minds when the data changes, and would rather discover a flaw themselves than have a reviewer find it later. Defending an idea is less important than understanding why it is right or wrong.

Care for work that matters outside the paper#

I value systems that run, tools that other people can use, and results that hold up outside one carefully selected experiment. A paper is important, but it should not be the only reason to do the work.

This means caring about reproducibility, documentation, edge cases, and the unglamorous engineering needed to turn an idea into something real. Impact often comes from the parts of a project that are easiest to dismiss as “just engineering.”

A willingness to work hard—and sustainably#

Systems research takes time. Experiments fail, infrastructure breaks, and important ideas often emerge only after long periods of concentration. This is not work that always fits neatly between 10 a.m. and 5 p.m. I look for students who are willing to work intensely when a project requires it and who take ownership rather than waiting to be assigned every next step.

The goal is not to maximize hours. It is to care deeply, use time well, and develop the judgment to know when a project needs another push and when you need to step away.

What I do not require#

You do not need publications, years of systems experience, or a perfect transcript before contacting me. Background creates opportunities, but it is not the same as potential.

I care more about evidence of how you think and work: a difficult bug you tracked down, a project you carried further than the assignment required, an unexpected result you investigated, or an open-source issue you helped solve. Show me something that made you curious enough to keep going.

How to reach me#

I read emails carefully and often respond when the message demonstrates your understanding of our work. I generally do not respond to generic emails, a resume with no context, or a few lines of AI-generated text that is tailored to me.

Your email can be short. It should tell me:

  1. who you are and which kind of position you are seeking;
  2. about one system you built, contribution you made, or measurement that surprised you;
  3. what you learned from it, especially when something went wrong; and

Include a link to code, a project page, or a paper if one exists. You do not need elaborate praise or a long summary of my work. Specific evidence of your own curiosity is far more useful.

If you are applying to the Ph.D. program at Harvard SEAS, you are welcome to mention my name in your application. Directly emailing me does not help.

If this description sounds exciting rather than intimidating, I would be glad to hear from you.