Opinions on Undergrad Computer Science Research
I’ve been getting some great questions about undergrad research at Georgia Tech :) Here are some generalized (and very opinionated) tips.
A quick heads up: most of these opinions are reflective of undergraduate computer science research at the intersection of Machine Learning (ML), Human Computer Interaction (HCI), and Natural Language Processing (NLP). This is a work-in-progress and I’ll be updating this as I think of things. Feel free to reach out if you have any questions!
Last Updated: 21th December, 2021
0. Have fun!
If you’re reading this you’re probably an undergrad, which means you’re here to explore! Turn your brain off regularly, try new things, and be open to your interests changing. When I first came to GT, my interests were very different from what they are now.
Some of the ideas I’m most proud of are things I’ve thought of while actively not working, or while working on things seemingly unrelated to my research. Relax! Research is supposed to be fun :)1
Finally, this is very, very opinionated! Take this advice with a bucket of a salt.
1. Getting Started
When should I start?
I would recommend starting as early as you’re comfortable. This might mean after you’ve taken a class in the area you think you’re interested in, completed a side-project, or done some independent studying. There’s no perfect time! I would, however, dissuade undergrads from jumping the gun and starting too early: having no prerequisite knowledge can be a significant roadblock. Finally, if you’re thinking of graduate school or how to broadly schedule research through your undergraduate years, John Hewitt has a great blog post that’s more focused on timelines.
I want to do research, but I don’t know what I’m interested in.
This is a hard question to answer and requires a bit of introspection and exploration. First, I’d recommend going to research talks scheduled at your school; these talks are generally accessible to newcomers and provide a high-level overview on specific research problems in a given subfield. If your college has a newsletter, they’ll advertise the time and location of upcoming talks. Your school might also have undergraduate clubs focused on computer science research. I’d recommend checking out these resources if they’re available to you.
Taking classes that sound interesting is another option! You also don’t have to wait to formally take a class—there’s a swath of open coursework online (from GT and other institutes). Looking at the introductory lectures or homeworks from these courses will give you a better idea of the background associated with a specific area. This isn’t a foolproof strategy though: research is distinctly different from coursework. Classes are a rough proxy for identifying interests and are not indicative of the research process itself. Finally, I’d caution against following hype. A lot of fields look shiny because of popular science coverage (looking at you, AI et al.); again, taking or auditing introductory courses will give you a more accurate representation of a specific field.
You can also try to find a subfield that bridges prior interests. Do you have any hobbies that might be tangentially related to a specific area? For example, I’ve always enjoyed reading/writing and working on people-facing things—HCI and NLP felt somewhat related to these interests.
I know what I’m intersted in. Who do I reach out to?
There are several ways to go about this. Professors who teach courses in a subarea usually conduct research in the same field. You can also pull up faculty directories and filter by interests; however, these listings are usually fairly outdated and challenging to navigate.2 There’s also CSRankings, but I don’t particularly like this tool either. I’m honestly not sure there’s a generalizable “good way” to do this, since directories differ significantly from school to school.
Some schools also have formal undergraduate research programs. For example, Georgia Tech has a CS undergraduate research fair (free pizza, usually!) where professors will advertise their work and ask for undergraduates to contact them. If you’re not a GT undergraduate, check if your school has a similar event!
I’ve identified a faculty member I’d like to work with. How do I reach out?
I definitely felt (and still feel) a little uncomfortable reaching out to faculty. First, try to find their website and see if they have a recommended channel for contact. Some professors will explicitly mention that students should directly email them; others might have an online form you need to fill out. Professors get a lot of email, so if you do end up emailing, make sure you include relevant details from their work and from your background.3 It’s a lot more impressive if you’ve read their prior work and can communicate what you want to work on and/or how it intersects with your interests.
2. Cool, I’ve joined a lab! Now what?
Congrats! In my experience, professors will either assign you to start helping on a pre-existing project, or will let you pitch your own idea to work on. Usually, you’ll start with the former. You’ll probably have weekly, biweekly, or adhoc meetings with your advisor for your specific project(s). Most labs also have a weekly lab meeting, where everyone gets together and provides updates on miscellaneous things. You should definitely…
Go to lab meetings! (if your schedule allows it)
Meeting people is fun! There’s so much to learn from the interactions you have with your peers—definitely do not take this for granted. Through these meetings, you’ll also meet and potentially collaborate with other brilliant undergraduate/Ph.D. students whose interests align with yours. Looking at and reading your peers’ works is miles away from learning what drives your peers. Beyond meeting other members of the lab, you’ll have an outlet to brainstorm ideas, debug technical issues, and learn what other people are working on. Even though your lab is focused on a specific area, you’d be surprised at how much research diversity exists in a single group.
Exposing yourself to different viewpoints (through these meetings) is invaluable at an early stage in your research career. Not only are you learning from your peers, but your peers will learn from how you work/think too!
Acknowledge Imposter Syndrome
Feeling like you don’t know what’s going on is perfectly normal, especially if this is your first research experience. There’s a lot of jargon and terminology that’s inaccessible to newcomers. Ask your peers if there are any resources that helped when they initially joined the lab: seminal papers, blog posts, related coursework, etc. The good news is that everyone is in your shoes—part of doing research is regularly not knowing what’s going on. As for the bad news: I’m not sure that feeling ever really goes away. Worse yet, it disproportionately affects marginalized groups. Personally, I try to focus on how much I’ve learned or improved, instead of comparing myself to others. I’ve also bookmarked this useful NYT guide on dealing with imposter syndrome; it has some tips that might be handy, especially since it’s easy to spiral into “imposter mode.” Again, you’re not alone!
Be aware of advising styles and project meetings.
There’s significant variation in how professors organize research meetings. Broadly, these meetings fall between two categories: firehose or directed. Firehose meetings are, well, like a firehose: you’ll leave with several potential avenues for future work, but filtering these avenues down to a manageable few might be challenging. In contrast, directed meetings will give you less, more pointed advice, which can constrict independent exploration. One style is not inherently better than the other! It’s just something useful to recognize early on. I’d recommend reading over Alex Tamkin’s post on this. You’ll likely be able to tell where your advisor falls after your first few research meetings.
Regardless of your advisor’s style, there are general strategies to stay on track during project meetings. Before you meet, I’d highly recommend centralizing your agenda and notes in a shared agenda doc. For each meeting, I add a new page with 4 sections: (1) the high level research questions, (2) progress made since last meeting, (3) planned future steps, and (4) notes/discussion. Here’s a template I actively use.
Section 1 (high level RQs) will look pretty much the same as the project progresses, but will likely be in flux at the start of your project or if you pivot. Section 2 highlights progress after your last meeting; this section is also a good place to put questions you have about some of the observations you’ve found. Section 3 has concrete future steps, along with questions about these steps. Finally, Section 4 is note-taking space you can use during your meeting. You don’t have to follow this template, but visiting these broader points before each meeting saves time, especially since these meetings tend to be short.
Depending on your advisor’s style, there might be more/less content in each of these points. For example, if your meeting is a “firehose,” you’ll have a lot of points under Section 4 (misc. notes). You can filter ideas from these notes and place progress for a subset in next meeting’s Section 2 (current progress). On the other hand, if your meeting is more directed, you can suggest broader ideas in Section 3 (future steps). Having everything in a centralized place, along with questions in each category, should help with organization.
Finally, pinning things like the agenda doc and a Zoom/BlueJeans link to a Slack channel will help you quickly locate these items at the start of a meeting.
Set realistic deadlines—deadlines in mirror are closer than they appear.
I’ve gotten burned by this countless times. It’s really really hard to predict how long a task will take, especially for programming related things. Unfortunately, this looks like a skill you learn through trial and error. Fortunately, you do get better at it over time. Underpromsising and overdelivering (don’t under-under promise though) is a strategy I’ve used to deal with time estimation. Finally, if you have an ugly week, with a bunch of projects and tests due, feel free to notify your advisors in advance and take a break. Your advisors were undergraduates at some point too, and they’ll understand.
Learn miscellaneous useful skills.
I’d spend some time asking senior students what specific technical skills are most useful for your field. Generally, things like typesetting with LaTeX, being able to write shell scripts, knowing how to SSH-into a server and keep sessions alive (tmux/screen), port-forwarding, and running jobs with Slurm (or whatever computing cluster you have) will lie on this list. I’d recommend glancing over this course (The Missing Semester of Your CS Education) to learn some of these skills.
Finally, here’s an extensive list of skills from Dr. Dragomir Radev—this is targeted towards Computer Science Ph.D. students, but some of these are relevant for undergraduate research.
Propose your own ideas or ask questions!
Don’t be afraid to do this! As someone new to a lab or field, you’re in a unique position where you can identify problems that more senior folks take for granted! Really, there are no stupid questions: a question you ask might inspire ideas for new projects. Also, don’t be afraid to directly propose ideas for projects! If it’s a promising idea, you and your advisor can draft concrete research questions and objectives. Otherwise, your advisor will outline why the idea isn’t suitable for a research project.
A strategy I’ve found helpful is collecting ideas into a personal doc (inspired by Dr. Eric Gilbert’s Ph.D. syllabus). Every once in a while, I’ll revisit this doc and run an idea by my advisors or peers. If it’s promising, I’ll draft a one-pager with the high level research questions, the methods I’ll use to answer these questions, and some broader implications of the project. Proposing ideas is a great way to build research taste (the ability to identify problems that are interesting, fairly unexplored, and impactful)—something I’m personally working on. Your advisors have great research taste, so I’d highly recommend practicing with them!
Finally, don’t feel bad if your advisor shoots down an idea: just because it’s not a suitable topic for a research project doesn’t mean it would be a bad project! Academic research is centered around novelty (for better or worse), and sometimes good ideas don’t overlap with novel ones. One of my go-to strategies for coming up with something novel and interesting is…
3. Reading and Writing
I cannot overstate the importance of reading papers. The area I’m interested in (HCI / NLP), for example, has several venues (CHI, CSCW, ACL, EMNLP, etc.) where researchers with similar interests publish their work. Talk to students in your lab, see where your peers have published their work, and skim through some of the proceedings. These proceedings are sometimes segmented by research area, from topics like NLP for Social Good to Human-AI Interaction. Paper reading groups, group meetings, internal lab slack channels, and misc. talks are also various ways to find interesting work. You can also use social media to follow faculty or Ph.D. students that publicize work online.4
Once you read enough, you’ll start to pick up on some useful trends! How do people even structure academic papers? What are some interesting related works in that field? Most papers will have a Future Work section, where the author(s) will explicitly outline avenues that might pique your interest. Finally, you’ll start to see some frequently repeated names in the author list: take note of these names! If you’re considering pursuing a graduate degree down the line, having a list of names will help you build a shortlist of graduate schools.
Reading work in your area of interest will also pay off when you’re trying to brainstorm your own ideas for projects. Because you’ll have an internal “map” of what papers in your field look like, you’ll know where unchartered areas are. Furthermore, you’ll have an idea of which areas you’re most excited to explore! My opinion here: I think reading is a fantastic way to build research taste.
Writing is also incredibly important! Following all your qualitative and quantitative work, you’ll need to construct a coherent narrative around what you discovered.
This is a particularly challenging task, especially when it’s your first rodeo: a lot of the papers you read are usually finished products, so it’s hard to know where or how to start. If you’re ever given the opportunity to write sections of a paper (or better yet, write the entire thing!) go for it! After reading several similar papers in the field, you’ll have some idea of what paper components look like: an intro, related works, methods, discussion, conclusion, etc. Revisit the broader research questions & design principles associated with your work, and align each section around these broader questions. Depending on your lab’s approach, or the set of coauthors you’re working with, writing strategies might look a little different.
Usually, senior Ph.D. students in your lab will already have papers directed towards the audience you might be writing for. Feel free to ask them for help on higher level structure, especially if they’re a coauthor. Finally, Dr. Stevie Chancellor has a fantastic blog post on spaced writing strategies that I try to follow.
It’s hard to strike a balance between all your work as an undergrad, and that’s understandable! Figuring out your sweet spot for classes, projects, and research is important when committing to a new project. I overshot pretty badly my sophomore year: classes and research were starting to conflict, and it was hard to find free time to relax or pursue other hobbies.
Research vs. Classes
I’m probably in the minority here (?), but I think classes are important—especially if they’re not in your direct area of interest. Some of these seemingly disparate fields might inspire future ideas, or force you to reevaluate how computer scientists approach problems. I’m somewhat confident about this claim for HCI and NLP (at least), but I’m not sure how well it generalizes to other subareas.
What I’m very confident about, however, are grades. I regret spending time focusing on grades instead of sleeping/hobbies/research. I would encourage shooting for an A in important classes that might be relevant to your area of interest. In other courses, I’d focus on learning about what interests you instead of aiming for a perfect score. At GT, a 90 is the same as a 100—if you’re happy with your understanding of a topic, stop studying :)
Research vs. Research (or strategically avoiding shiny things)
Yup, Research vs. Research is also a problem I’ve noticed! Make sure you have bandwidth for new research if you already have other projects on your plate. It’s easy to yes to a lot of shiny things, or propose to work on something new when you’ve already committed to a specific project. As an undergrad, I try to limit what I work on each semester to 1 serious project and 1 kinda-fling where the outcome is more high-risk/high-reward. I’m not sure what the ideal distribution looks like for a full-time Ph.D. student, but I think limiting yourself to 1 or 2 a semester as an undergrad is reasonable.
There are a lot of shiny ideas/projects that you might think are better than what you’re working on now! Put them in your ideas doc, and ignore that nagging feeling to abandon ship. If it’s really irritating you, spend at most a day or two hacking together a proof of concept: the shine usually goes away once you realize that (a) the idea straight up does not work lol or (b) there are a lot of hidden steps you didn’t notice. If the shine is still there (I’ve never had this happen), I’d still recommend evaluating if you have bandwidth to take on another project. It’s usually better to complete what you’ve started now than to start something anew and have N + 1 unfinished projects.
There are exceptions! If you strongly believe that your interests better suit a different project, or you think you’ve hit a dead-end with the other research you’re doing, it’s O.K. to pivot—but I would proceed with caution and speak with your advisor first.
Here are some common questions that I’ve also heard, but couldn’t fit neatly into the subsections above.
What are REUs? Should I apply to them?
REUs are a great opportunity to conduct research at another institution. Usually, these experiences are more structured than other research projects, with your assigned mentor giving you a project that will span over 2-3 months. Learning how other labs and institutes operate will expose you to different research styles. I might be in the minority here again (?), but I would not discount REUs in areas that are different from your interests: you may be able to take inspiration from other subfields or inspire other researchers.
There is one negative that you should not ignore about REUs: they will not pay as much as a standard industry internship for a big Silicon Valley company. If you’re depending on summer employment to pay for your cost of living or tuition, and the math isn’t adding up with an REU, do not be afraid to forgo an REU opportunity.
Dealing with rejection
A big chunk of academia is dealing with rejection. Your first rejection will sting: it’s O.K. to mentally take the day off and “mourn” your application/submission. Honestly, when I get rejected now, I sorta just laugh, mentally check out, and eat ice cream. When things you don’t expect happen, it’s usually “all for the best”—more opportunities are always out there. It’s easy to let it affect you, but try not to! There’s a lot of random noise in an application process and “they” are not judging you. I’d recommend reading this blog post from Dr. Niklas Elmqvist on dealing with rejection.
How do I get a publication?
I don’t think there’s a secret strategy to “get published;” I also believe that directly optimizing for publications is a terrible idea. In my experience, as projects drew to a close, publications were the next natural step. It might be helpful to inform your advisors that your goal is to publish your work, but don’t feel pressured to rush anything! A publication is only half the battle. Making an impact and publicizing your work is equally (if not more!) important.
None of this was concocted in my brain. All of this is advice from wonderful professors and students I’ve worked with over the last ~3 or so years: Polo Chau, Diyi Yang, Omar Asensio, Andrea Won, and more!
This is mostly true: it’s not fun when you’re reading research code, or you’ve been tearing your hair out over a nasty bug for 3 days that ends up being a cache problem, a bug in one of your dependencies, or something dumb with torch.zero_grad() ↩
Frankly, the emails I sent to my advisors are pretty cringeworthy. Don’t make the same mistakes :) ↩