Communications of the ACM
How to Attend an Academic Conference
Here's a collection of miscellaneous tips for young CS researchers attending conferences for the first time. Do you have any additional tips for the younger generation? Leave them in the comments!
Read the conference program ahead of time. Make notes on which talks sound interesting, and remind yourself to go to them. Sometimes I put entries on my calendar, sometimes I just mark up the conference schedule.
Make a list of who you want to meet. The main reason to go to conferences IMO is to expand your professional network. If you're unclear on networking, read Networking on the Network. You will want to meet grad students who are doing work in your area, senior faculty who are lifetime experts in your area, industry researchers who have internships in your area, and everything in between. A network is something you will use throughout your professional career. After grad school you'll mine your network to find job opportunities, to review papers, to hire your students, to give you candid feedback on your work. Your network is also the people who will help you succeed in your career by collaborating with you, nominating you for awards, and making your field more interesting. You will get to know these people for decades. So be nice.
Who should you meet? When you read through the conference program, make notes of who wrote the papers you find most interesting. If you have time, and if you can find them online, read their papers. Figure out who is the grad student and who is the professor (the web makes this easy). It's likely that the grad student knows the details of the specific work, and the professor can tell you how this specific work fits into a larger research agenda. Formulate one or two questions for each person you want to meet. Memorize their names. When you see their name badge at a conference, you will have a reason to introduce yourself to them and ask your question, and you'll sound prepared.
Ask questions at the conference. After each talk there's usually a couple minutes where the audience can ask questions. Step up to the mic, speak slowly, introduce yourself ("I'm Tessa Lau from IBM Research") and ask your question. Even if you won't be presenting a paper yourself, by asking a question you will gain visibility amongst the audience. If someone else wanted to ask the same question, they might find you after the talk and you might have an interesting conversation about it.
There are good questions and bad questions. Good questions are open-ended and let your subject talk for a while about a topic that's interesting to them. This makes you appear to be an interesting conversation partner. Bad questions have yes/no answers. After she answers the question, your subject will probably wander away to talk to someone else. Good questions are of general interest to the entire audience and help everyone understand the technical material better. Bad questions nit-pick details of their work and ask why they didn't do it your way (you can still ask these, just do it in private, not in the main session).
Practice active listening by trying to formulate at least one question for each talk, whether or not you actually ask it at the microphone. If you find yourself at lunch with the speaker, you can always use that as a conversation starter. Listen to the questions other people ask; they can teach you how scientific work is evaluated by peers (which is critical to the peer review process and for getting your own papers accepted at conferences).
Memorize your elevator pitch. An elevator pitch is a 15-second explanation of who you are, what you work on, and why it's interesting. It gets its name from the following scenario: suppose you find yourself in the hotel elevator with the most important person in your field, the person you have been wanting to meet all conference. You have 15 seconds in which to make an impression on them. What do you say? Here's mine: I manage the Smarter Web research group at IBM. We create tools that make it easier to design, use and build web applications. My own research interests are in end user programming, enabling regular people to program computers without writing code. Your goal is that by the time you leave the elevator, your target knows who you are and associates you with an interesting research area. You want to be memorable, but in a good (positive) way.
Have social lunches. Conference attendees will often form big groups to go to lunch. It's a great way to meet people in an informal setting. Try to find one of the few people you have met and ask (nicely) if you can join them for lunch. If they say no, don't take it personally; assume they are having a private working lunch where you would be bored with their technical discussion and ask someone else. If all else fails, just look for a big group of younger-looking people (probably grad students, who tend to be open to random people joining them) all wearing conference name badges and ask if you can join them. Yes, this is terrifying. Do it anyway.
Don't clump. If there are a bunch of people from your organization all attending the same conference, don't cluster with them. You can see them back home. You have to push yourself out of your comfort zone and meet the people who you only see at conferences -- that's why you're there.
Enjoy! Attending conferences is one of the best parts of being an academic researcher. You get to expand your horizons, hear about interesting ideas, and meet fascinating people. Relax and don't stress out about it.
Comments
Chandra Vellanki
I am associated with teaching students at PG level in Computer applications for the past two decades . I started doing research in the subject Service Oriented architecture . The points are very interesting and have to be executed in practice.
Displaying 1 comment