This past May I completed my final year at UC Berkeley after graduating with a B.S./M.S. in Computer Science, thus marking the end of my 2.5 year career as an academic student researcher. Encouraged by my research advisors, I’d like to share my own personal experiences, and hopefully inspire others to consider research or learn a little more about what makes research at Berkeley great! This post summarizes how and why I got started doing research as an undergraduate, gives a detailed account of my experiences and learnings, tries to provide advice to those interested in pursuing a similar path, and includes additional remarks regarding graduate school.

Disclaimer: I try to illustrate what computer science research at Berkeley is like based on my own experiences and observations. Each student’s experience is unique; however, I try to be as general as possible when giving advice and note special circumstances wherever they may be.


Motivations

When I was an undergraduate student, I wanted to get involved with research for multiple reasons. It seemed like there were many interesting and difficult challenges in computer science, and I wanted to gain a deeper understanding of a specific area. I thought it would be exciting to work on problems that haven’t been solved before, and make attempts at solving those problems through experimentation. And a great aspect about computer science research specifically is that those solutions can end up influencing the real world in a short amount of time. Having witnessed many previous research successes come out of Berkeley, I saw a very good opportunity to make meaningful contributions to research projects I thought were important.

A guiding principle that has served me well throughout college has been to diversify my experiences as much as possible. I believe this is the best way for someone who is young and inexperienced to discover what they enjoy doing and what they are good at. Perhaps phrased another way: no one cares about grades in courses, the best differentiator is what you do outside of class. In practice, this meant focusing less on my coursework and instead embracing all the other opportunities I had around me in college such as research, internships, study abroad, teaching, personal projects, student clubs, etc. Considering that UC Berkeley is one of the top computer science research institutions in the world, I felt I would be wasting a major opportunity if I didn’t at least try research during my time in college. I had the rare chance to work with people who are leading experts in their field, and I had incredibly smart peers to lean on and learn from.

When thinking about my career choices after college, I wasn’t sure what I wanted to do exactly, but the choice was primarily between working in industry or pursuing graduate studies. A PhD program seemed like an appealing and worthwhile goal at the time, but I had no idea what it was actually like or if it was really what I wanted to do. Since the primary function of a PhD student is to produce quality research, I figured that getting involved with undergraduate research would be the best way to find out what being a PhD student is like. I have also seen cases of students who think they want to pursue a Master’s or PhD program but have never even tried research before. While it is possible that such a student might enjoy the work anyways, I believe it is less risky to figure that out earlier rather than later. And as someone who was considering the PhD track myself, it was useful to get started early and accumulate experience and mentorship.

Note that there is little explicit reward to doing undergraduate research. You are very unlikely to have a paid research position, but can most likely earn some amount of course credit. For me that didn’t really matter, since the extra credits I earned never affected my ability to graduate. In my opinion, research is more rewarding for its intrinsic and long-term benefits such as experience, skills, mentorship, and pure satisfaction. In the end, research was very fulfilling for me and I enjoyed it so much that it became a huge part of my college experience. This never would have happened if I didn’t have the motivation to try it in the first place.

Most of these thoughts about research started bubbling in my mind during my second year at Berkeley, as a consequence of me finishing all my lower division course requirements. I wanted something to focus on during the time I had left in school, but I wasn’t sure what I wanted to do. I felt that research was potentially something worthwhile to pursue, so I decided to give it my best effort to find a research position during that year.


Getting Started

Finding an undergraduate research position is actually less daunting than it seems. There are literally hundreds of graduate students, postdocs, and professors in the Berkeley EECS community working on all kinds of research projects. Many of these projects are very welcoming to motivated undergrads, but few are actively seeking them out because the process of filling a position can be time consuming and professors are busy people. Thus as an undergrad, the trick is to be proactive about finding a research project even if they aren’t being advertised. While resources like URAP and Beehive are very useful for finding projects, another effective method is to just ask people. Concretely, this means looking up interesting projects and professors, and cold emailing them to ask if there are any opportunities for an interested student with no research experience. This is exactly how I went about it, and I was able to get a successful response from the first person I asked.

It took me a few weeks of soul searching to find out what research area I wanted to pursue, but I eventually felt that database systems was the most interesting area to me. I had some practical experience working with databases for small web apps, and I wanted to learn more about modern systems research. So I approached Joe Hellerstein, one of the primary database faculty at Berkeley, about any opportunities for me to get involved with a research project. It took a few emails, but he eventually agreed to meet with me to discuss some plans. To my relief he was very welcoming to the idea of working with me, but unfortunately he didn’t have any projects open for me to work on at the time. Instead, he introduced me to Eugene Wu, a postdoc working in the Berkeley AMPLab. He was doing some research on graphical perception, and was thankfully willing to train and bring an inexperienced undergrad onboard. I was super excited, and knew I had to prove myself during those first few weeks.

To get started, Eugene sent me some papers to read on the subject to familiarize me with the overall topic and the type of experiments we would run. I had never read any computer science research papers before, so naturally I thought I was pretty screwed. It turns out the papers were not too difficult to comprehend, but did take a lot of time to digest since they were so information dense. Reading academic papers can be very slow and intimidating, especially for a new subject matter. I remember spending many hours that first week slowly reading those papers, scribbling down notes as I went and constantly looking up terms and concepts I wasn’t familiar with. Writing down notes was a very useful mechanism for organizing my thoughts, and is a good habit to keep as a researcher. I would often reference my notes later when meeting with Eugene, which would help me formulate questions and ideas. I have gotten a lot better at skimming and reading papers since then, after having gone through dozens of papers while conducting research and taking graduate courses.

Reading a few papers about a specific research topic is a good strategy for gauging your own interest in that area. After reading through those papers on graphical perception, I was pretty excited about the topic and the type of experiments we would run. It was more closely related to human-computer interaction (HCI) rather than databases, but it helped establish a research trend on data visualization which would later become the focus of my graduate studies.

However, after reading some papers there may be a point when you’re not feeling particularly interested in the topic. It’s best to be straightforward about this with your professor and continue searching for a different research project to work on. There is no shame in doing this, and it’s beneficial for both sides for you to be personally interested in the research. I’m not sure I personally would have had the courage to say I’m not interested in a project after trying really hard to get a position, but it’s always good to explore other options and the researcher will most likely not be offended. As someone who later tried to help recruit undergrads for a research project, it was important to find students who were both qualified and genuinely interested in working on the problems at hand.


Learning and Feedback

During my first semester attempting research, it was helpful that Eugene was very accessible as a mentor. We would have regular one-on-one meetings on a weekly basis, and he gave me access to his workspace in the AMPLab where I could freely ask him questions or get feedback about the project. This was especially important as an undergrad without any real experience with research, since getting feedback and guidance regularly helped me understand things quicker and perform better.

Later projects I was involved in required much more asynchronous communication. During my second semester of undergraduate research, I worked on a collaborative project between Joe and Arnab Nandi’s group at Ohio State University on data tweening. We had weekly meetings where I would show up to Joe’s office, and we’d get on a video call with Arnab and Meraj. This time I was working with two professors and one graduate student, rather than one-on-one with a postdoc. It was quite different from the dynamic I had with Eugene, but I managed to adapt and the project ran pretty smoothly despite a lot of the communication happening online through email and video calls. I can’t imagine the project would have gone nearly as well if that had been my first research experience. There is a sizable overhead in onboarding a new, inexperienced researcher that is made a lot easier with enough face-to-face communication. And since the project was primarily led by Meraj at OSU, I was mostly working directly with him rather than with Joe who was present at Berkeley. It was an interesting experience to collaborate with researchers from other schools, and I’m glad I was given multiple opportunities to do so in all the research projects I’ve worked on so far.

After completing these projects, I later realized that it is much easier to work directly with a graduate student or postdoc than with a professor since professors usually do not have a lot of time on their hands to spend on undergrads. I think this is important to consider for undergraduates looking to join a research project. Much of the actual work for a research project is done by the graduate students and postdocs, whereas professors mainly play an advising role. As an undergrad, you’re probably going to be working on the gritty details of the project such as prototyping or running experiments. So it’s a good idea to find professors who are actively advising graduate students who work on projects that interest you. One notable exception to this is that a newly hired professor is as good if not better to work with than a graduate student. This is because new professors are trying really hard to publish to earn tenure and thus are way more likely to get involved in the actual research work. Tenured professors on the other hand typically have a lot more commitments to attend to and will defer to their graduate students.

I also realized that weekly research meetings can be key motivators, but they can also be nerve-wracking moments. If I came into a meeting with one of my research advisors and hadn’t done anything substantial since the last meeting, then it was pretty apparent and the meeting would usually be wasted and momentum lost. Professor time is precious and should be utilized judiciously. This would sometimes result in me pulling some crazy hours trying to make progress on something the night before the meeting, often during weeks when I had quite a few other things occupying my time. Digesting the feedback from these meetings was also very important, and learning when to absorb or disregard comments is something that I’m still not sure I’ve properly figured out.

There were many times during meetings where I felt it was hard to keep up with the pace of discussion and I would become lost, especially when the topics would get very abstract. During such times I wasn’t able to contribute as much as I wanted to, and was afraid to interrupt with questions in fear of feeling really dumb and disrupting the flow of conversation. I think this can be a difficult hurdle to overcome for many people, as it was for me at least. I think the best way to avoid these situations is to ground the discussion in something concrete. I felt most confident in meetings where I had actual experiment results to share or a new implementation idea to show off. It’s also helpful to schedule more one-on-one meetings rather than large group meetings, since it becomes easier to ask questions and have a succinct conversation and less likely to go off on tangents or highly abstract discussions.


Useful Skills

The research I have completed largely focused on data visualization, which touches on concepts from database systems, human-computer interaction, and cognitive science. I had some prior experience using databases and designing interactive web interfaces, which was helpful both in terms of motivation and skill set. I think the work complemented my background as someone who had a lot of practical experience with UI/UX and strong academic interest in systems. In this section, I describe useful skills that I learned specifically in the context of visualization research, and which may or may not be useful for other research fields.

Since I was working on data visualization, it was very helpful that I had a lot of front-end programming experience to lean on. As an undergrad researcher, I mostly fulfilled a programmer role in building visualizations and setting up online experiments. I think programming is a good way to get started with computer science research and meaningfully contribute very quickly, since most projects will require some amount of programming. But while having programming experience is useful, I do believe that it can also be made up for with enough time and ability to learn quickly. Having enough time to commit to research is in some ways more crucial than experience. In fact, younger students can be great researchers because they generally have few competing commitments and many semesters left to do research. Some professors may not even consider accepting an undergrad without at least a year’s worth of commitment. Overall, the most common failure modes I see when undergrads try to get involved in research is a combination of lack of research experience, programming experience, and time commitment. I think starting to do research around second or third year of undergrad is the optimal point for experience and time, but there are also a lot of other personal factors that might affect this.

I originally thought I would need to take more computer science classes before I was ready to understand the technical concepts needed for research. For example, I hadn’t taken any database or HCI courses when I got started. But it turns out that I was able to comprehend the papers decently well, and was able to look things up as necessary without much trouble. Even after I had taken the relevant courses, I found that I used only a little knowledge from those courses in my research projects and only really for contextual and motivational reasons. There is a lot more specific knowledge involved with research that isn’t covered by the breadth of an undergraduate curriculum, though this can vary depending on subject matter.

However, a solid understanding of statistics was also really important for the type of research I was doing. Knowing how to design experiments, run statistical tests, and report results is useful for HCI work, though other research areas may not require much statistics knowledge at all or may require knowing a lot. I had never taken a statistics course at Berkeley, so I struggled to pick things up as needed and learned in a very ad hoc manner. It probably would have been better for me to take a proper statistics course early on, though at the time I had no idea I would be doing anything related to HCI research. Different areas require different skill sets, and so it’s good to have some idea of what you want to do early on. It could be just as easy for me to say that a strong understanding of linear algebra, probability, or algorithmic proofs is important if I had done research in those other computer science topics which require them.

Another skill I picked up that was specific to my research area was learning how to use Amazon Mechanical Turk (MTurk) to run online user experiments. The MTurk platform lets researchers post small tasks online that anonymous workers can complete in return for payment. This allows researchers to deploy experiments to study participants around the world and receive hundreds of responses within hours. It was often my role to build and run the experiments for our projects, and so I gradually became very experienced with MTurk. After having used it on every research project I’ve worked on, I felt very confident in knowing how to conduct user experiments. This is a pretty fundamental skill to have as an HCI researcher, and it was extremely useful to have that experience when I later became a graduate student.

On a more general note, strong writing and editing skills are remarkably useful when it comes time to finally publish your work. The best research papers are concise, clear, and well-motivated; but it took me some time to realize a more subtle tip for academic writing: know your audience. It is important to tailor the writing towards the academic community that you’re trying to publish to. When submitting a paper to a peer-reviewed conference venue, properly contextualizing the results of your work for the reader can have a substantive effect on how your submission may be perceived. For example, in our asynchronous interactive visualization project, we would wrestle with questions of whether to approach our arguments from a systems perspective or an HCI perspective. Ultimately, this ends up mattering more than you might think and the proper framing can mean the difference between acceptance and rejection. Writing ends up taking an enormous amount of time and is the most dreadful part of the research process in my opinion, but if you are good at writing and enjoy it then that can be a huge advantage.


Academic Success

The typical metric of success for a researcher is the amount of published work you’ve authored as well as the magnitude of the contributions for each publication. Generally being listed as first author on a paper signals that you were the primary contributor and lead of the project. If brought onto a project as an undergrad, you’ll typically be second or third author. Attaining a first author publication as an undergrad is a huge mark of success that is rarely accomplished. It requires leading an entire research project including forming the idea, designing/prototyping, and managing the work to completion. Academic success matters a lot if you want to go to grad school, but otherwise only counts for bragging rights. I didn’t really understand the significance of this authorship signaling until I became a grad student, where it suddenly became more important.

For reference, here is my own record of all the research paper submissions I contributed to, including both acceptances and rejections:

Graphical Perception
CHI 2016 conference paper ❌ rejected
Data Tweening
SIGMOD 2016 undergraduate poster ✅ accepted
🏅 runner-up for best undergraduate poster
VLDB 2017 conference paper + demo ✅ accepted
Asynchronous Interactive Visualization
InfoVis 2017 conference paper ❌ rejected
UC Berkeley EECS M.S. Thesis 👍 approved

Over the course of two and a half years, I contributed to three different projects with varying success. The first two were completed during my undergraduate studies, in which I made secondary contributions. The last project was completed during my graduate studies together with Yifan Wu, another grad student advised by Joe. These submissions were made towards top-tier database and HCI conferences with acceptance rates around 20%. The undergraduate poster acceptance rate was likely much higher. Finally, my M.S. thesis was approved by a thesis committee consisting of Joe and Eugene.

I was really excited about my first paper submission to a conference for the graphical perception work, so naturally I was pretty disappointed when it got rejected. However, that failure was instrumental in making me realize that success is about more than just publishing papers. At the end of the day I still learned a lot and gained the skills and experience to become a better researcher. It didn’t discourage me from continuing research, but rather I think it motivated me to do more work to redeem it. Nowadays I think academic success isn’t that important, it’s kind of just a nice bonus to have. If I was pursuing a PhD I would most probably have a different outlook. Honestly, I get more excited about the thought of attending conferences so I can travel to interesting places, hang out and meet cool people, and learn new things. If your professor is nice and well-funded, then the cost of attending will typically be covered too!

I was lucky enough to attend a conference for one of my projects, which is actually something not every undergraduate researcher gets a chance to do. I attended SIGMOD in San Francisco last summer and presented some work on data tweening as part of their undergraduate research competition. That was pretty convenient for me since I was interning at Dropbox in San Francisco at the time. Even though I didn’t get to travel very far, it was still a great experience to participate and share my work. Until being at one of these conferences, I didn’t realize how well-connected people in the academic communities were. It kind of felt like everybody knew everybody else, and it was an awesome opportunity to meet really smart folks who shared similar research interests. I met grad students and famous professors from other schools, reconnected with Eugene and Arnab, and met many of Joe’s former PhD students. It was all really inspiring, but also pretty fun at times. This was also a time when I was considering the PhD track, so it was helpful to be able to talk to so many PhD graduates and see where they ended up.

Though with regards to actually submitting papers, it often felt like we were heavily rushing towards the nearest conference paper deadline. Originally I thought the conference paper is something you prepared only after completing the research, and that the writing would take substantial time. It turns out a lot of the writing happens at the last minute, because things end up taking longer than expected and deadlines are always looming. I never liked this constant grind towards paper deadlines which seems to be a pervasive behavior among research projects. I recall this happening during the asynchronous interactive visualization project when we were rushing to meet the EuroVis 2017 paper deadline. We were really time-crunched and ran last-minute experiments days before the deadline hoping that the results would look good. Instead, we missed the deadline and it took us three more months to get in good shape for an actual submission to a different conference. It is much easier when a conference has a rolling deadline like VLDB which accepts submissions every month, since there isn’t as much pressure to finish by a specific date. However this tends to be less common among the research venues I’ve submitted to.


Grad School

By the end of my third year of undergrad, I finished my degree requirements and decided that I liked research enough to pursue a Master’s degree. So instead of having a relaxing senior year of undergrad, I somehow decided that completing the 5th Yr M.S. program would be a good idea. I convinced myself of this since (i) I would finish school at the same time as my other friends, (ii) I was interested in taking graduate courses, (iii) the graduate program cost the same amount of money as undergrad, and in fact ended up being cheaper since I was covered under a GSI/GSR position throughout the year, (iv) I wanted to continue doing research, but not to the extent of time that completing a PhD would require, and (v) I didn’t want to start working a full-time job just yet.

Thankfully I had a lot of research experience by that point and Joe agreed to be my graduate advisor, so getting into the program was a fairly painless matter. It ended up being a hectic school year and a ton of work, but ultimately very intellectually rewarding in the end. As an undergrad, I spent maybe 10-15 hours per week on research during a semester. But as a grad student I would literally spend hours every day including weekends doing research, if not spend most of my waking hours at least thinking about research problems. This is sort of the norm as a grad student. Despite the extra responsibilities, requirements, and busyness, in many ways it felt more rewarding than being an undergraduate researcher because it opened up a lot of new opportunities. I had more control over my research agenda, was well-funded with dedicated office space, and was part of the RISELab community along with Joe’s other grad students. I attended several memorable research talks, gave some not so memorable ones of my own, and spoke with industry folks interested in our research. I was a teacher and mentor while still being a student myself, read more papers than I had ever done previously before, and published my own 40-page thesis about a topic I became obsessed with.

In the end, I’m glad I decided to pursue the 5th Yr M.S. at Berkeley, despite losing all the free time I would have had otherwise. It gave me the chance to engage deeply with research and play a much larger role than in my previous projects. At the end of it, I’m confident that I have the skills and expertise to lead and conduct my own research ideas. And even beyond research or academia, the skills I learned (e.g. critical thinking, design, communication) will certainly be beneficial in the future. Part of me wishes that I had more time to devote to it, another year perhaps, but the 5-6 year PhD track is too long for my tastes. Maybe I’ll reconsider sometime later in life and find myself back in school. Otherwise, I believe the experience has helped me understand how to approach and think about difficult problems. And even now after graduating I’ll continue trying to keep up-to-date with new research papers that interest me since I still want to feel connected to the academic research community.


Special thanks to Joe Hellerstein and Eugene Wu for providing feedback on earlier drafts of this post, and for overall being incredible mentors.