Tag Archives: academia

Approaches to the research statement

Posted on by

It’s job season again and I am revising my research statement. I was pretty happy with the last iteration of it, but as things change I might need to find a new story for my life. As I get farther along, it has become a bit harder to cram all of the things I’ve worked on into a single consistent story. There are even some grad students I know who have worked on several distinct things and they probably have the same problem. There’s a tension in the research statement between coming up with a coherent story and accurately representing your work. There are a few generic ways of handling this, it seems.

The omnibus. You can write many mini-stories, one about each of the major projects, and then have a section for “miscellaneous other papers.” This approach eschews the overarching framework idea and instead just goes for local internal consistency.

The proposal. Instead of talking about all of your work (or mentioning it), you propose one research direction and give short shrift to the rest. This has the advantage of letting you write more fully about one topic and provide sufficient context and exciting new research directions, but then again you’re mis-representing the actual balance of your research interests.

The tractatus. You develop some principles or philosophical underpinnings for your work and then try to connect everything you’ve done to these and explain your future work ideas as further developing these themes. This approach goes for consistency above all else. The advantage is coherence, and the disadvantage is that some projects may have to get strong-armed into it.

I am sure there are more varieties out there, but on the whole the research statement is a weird document — part description, part proposal. You can’t make it only about your existing work because that’s looking to the past, but you can’t make it a proposal because the reader is actually trying to learn what you are interested in.

Five career-oriented things I wish I had done more of in grad school

Posted on by

As I’ve started my nascent academic career, I’ve faced a number of new and difficult challenges, and on more than one occasion I’ve felt hoisted with my own petard. Looking back on my graduate school experience, I realized there were a number of things which I could have done more that would have made things easier now.

  1. Write more grants. I came in to grad school with a NDSEG fellowship and then my advisor was well-funded. I had a blesséd life (especially compared to those in other departments). I should have gotten a bit more on the ball helping to write grants, even if it was just for the experience. Reading a proposal (or many) really gives a sense of what the document is about. More importantly, it’s a grant in your field and that’s something that you can’t really get out of one of those panels on grantsmanship that are pitched to a broad audience. Learning the process early has two benefits : it demystifies the strategy space in terms of writing, and it gives a good sense of what kind of things make sense and are “fundable.” I wrote little dribs and drabs of proposals here and there but it wasn’t until my postdoc that I really got to see and work on a full proposal.
  2. Do an internship. : It’s sad to say, but I never did an internship while in grad school. This was a real mistake. As an engineer it’s important to learn what is going on in “real” engineering but more importantly, as a engineering theorist it’s important to understand what’s going to be important in the future. Some of that you can do by watching the news and trends, but having a visceral sense of the challenges in making a real object is an important perspective. On the more practical side, it gives you more contacts in industry and the more people you know, the more ideas you can integrate.
  3. Constantly tell stories. : Part of this is for grant writing, but it’s a more general skill that is important for the job market and interacting with your colleagues, 99% of whom will be outside your area. This is a skill that is hard to develop in graduate school because we spend our time in our labs talking to other graduate students who are not that far away from us in terms of intellectual background. This kind of story-telling is often cast as “be able to talk to the general public” or “explain your research to a crowd that includes information theorists and device physicists.” Part of being able to tell a story about your research is being able to tell it in someone else’s language, which means understanding a bit about how people in other fields think. How would you explain your research to an anthropologist? I did practice explaining to other people, but I wish I had practiced more.
  4. Find a community. : I do a lot of work that falls between fields or on the corners of fields, so I’ve bounced around a bit. The last time I applied for jobs I had interviews wearing a networks hat, a signal processing hat, and an information theorist hat. Finding a community can have a positive or negative connotation. On the one hand, it’s dumb that people care so much about labels : “oh, he’s a machine learning guy,” or “oh, he’s a signal processing guy.” On the other hand, cultivating professional relationships with a research community is valuable because those are the people who will remember you when your name comes up.
  5. Write the journal version first. People always say this. I think Lalitha told me this in 2005 at my first conference. Of course it’s a good idea. And it’s a slippery slope if you let it slide for one paper… 5 years later you realize you have 4 nascent journal papers with nice full stories but not enough time to do the last bit of research or flesh out the results a bit more. Not every conference paper is (or should be) a journal-worthy idea. But the goal is to tell bigger stories than 4 page ICASSP paper, and it’s important to keep that bigger picture in mind. I wish I had done more work contextualizing some of the things I worked on so I could come back to them and expand on them later. Instead I have a lot of weird half-baked ideas in old PDFs sitting around on my hard drive.

On conference schwag

Posted on by

When I moved to Chicago I realized I had a ton of conference bags. I was lucky enough to have a large closet in San Diego, and they kind of piled up in a back corner, from various ISITs and so on. I gave a few to Goodwill, but I have no idea if they will get used. I was recently talking to folks who work in public health and they were shocked that we get these “nice” bags at conferences — they get water bottles. Computer science conferences give out shirts. Why do we get bags? It’s kind of a pet peeve of mine, for a number of reasons.

How much do these bags cost? I should find this out, but I imagine a full messenger bag with laptop sleeve (c.f. ISIT 2012) isn’t cheap, and that cost gets directly transferred to registration fees. It probably only works out to 20 bucks but still…

Why don’t we get pens and paper? Most of the time you get a bag, a USB stick with the proceedings, the program booklet… and that’s it. I was shocked at SPCOM in Bangalore that they gave us a spiral notebook (handy!) and a pen (and really nice one at that) on *top* of the bag (which is pretty nice, as backpacks go).

Don’t people already have bags? You’re traveling halfway around the world with your laptop. You must have some sort of bag that you use already — why do you need another one? How are you going to fit it into your luggage?

Of course, after thinking of these complaints it turns out my ISIT 2012 bag has been a lifesaver — my apartment was robbed and they took all of my computers and electronics and carried them off in my bag, so having a ready replacement sure was handy. Furthermore, I use the tote bags (ISIT 2007-2009) all the time for groceries or going to the gym or the beach, so those are great.

What kind of schwag would you prefer? I use my IPSN 2005 mug all the time at work for tea…

Postdoc job openings

Posted on by

Some people have told me about postdoctoral position openings that are opening up, and I figured I’d repost some of them here as they come along. Of course, there are other places to post announcements, but I find that postdoc opportunities are a bit harder to advertise/hear about. I think a lot of systems EE people applying for academic positions right out of grad school tend to put off applying for postdocs until they hear back about their faculty interviews — I’d tend to say this is a mistake:

  • If your graduation date may be a little flexible, pinging someone early on (e.g. in the fall) about possible postdoc opportunities can be a good plan. NSF grant deadlines are in the fall, and so they could write a postdoc position into a current proposal.
  • Of course you’re going to apply for faculty positions, and the people you’re talking to about postdoc positions know that. However, if you get to May and haven’t talked to anyone about postdoc options, you may find that those positions have filled up.
  • Don’t think of a postdoc as a “fallback plan” (akin to a “safety school”) — it’s an opportunity and a chance to make a strategic decision. Do you want to switch areas or learn about something new? Do you want to dig deeper into things you’ve already been working on? Do you want a springboard to get a job in a specific country? Do you want to build closer ties to industry? Do you want closer mentorship?

I went to a panel at Allerton once on “whether you should do a postdoc” starring (among other people) Aaron Wagner and Todd Coleman, I believe. Everyone was very enthusiastic about doing a postdoc. Everyone on the panel had faculty positions lined up for after their postdoc and deferred their start date to do that postdoc. This is the best of all possible worlds but is pretty unusual, so don’t count on it.

This is all dodging the issue of whether or not you should even do a postdoc. That might be a topic for a different post (or a debate for the comments) — I know people have strong feelings on both sides. I tend to think our system is broken or veering into brokenness.

However, more information is more power, so if you have a postdoc announcement (details are helpful) and want me to post it here, please do send it my way. You can also try to post to the IT Society website.

Recommended iPad apps for technical academics

Posted on by

I have an iPad now (hooray research funds) and I’ve been trying to figure out how to make it more useful for me research-wise. Here are some apps I’ve found, but I would love recommendations on others that are useful for academics who do math-y stuff.

OmniFocus is a task management app — it’s a little heavy-featured and expensive, but I’ve been using it to help myself reorganize (and sync) when on planes and the like.

iAnnotate PDF is a PDF annotation tool that syncs to Dropbox (among other things). I now drop the papers I have to review in to a folder there and then read and mark them up. Given that my review load has doubled recently, being able to make notes without printing is nice. I think it will get even better once I get a stylus.

In terms of media, IEEE Spectrum is available, as is Communications magazine (but not Signal Processing).

I use Prompt to SSH into machines on the few times that I need to do that from the iPad. It has saved my butt once or twice.

PDF Presenter is supposed to be nice for doing slides, but I haven’t used it yet.

There’s an old post on LaTeX for the iPad, but nothing really looked that appealing.

Anyone else have some recommendations?

More advice on giving talks

Posted on by

I’d like to point out Alex Dimakis’s great post from last week on how to give a great ISIT talk (or any talk, really) and to put in a few bits more about a replicable process for writing talks that might help out students trying to write their first (or second, or third…) talk. As with any form of writing or communication, an unclear talk is usually the product of unclear thought on the part of the presenter. There’s no shortage of advice out there on how to give talks, but I figured I’d write down a process that I use to help streamline the process.

Before I get into the list, I have to issue a disclaimer : it’s not that I think I am super-great at giving talks. I am pretty good at critiquing talks to death, however. It must be the theater critic in me. What I have done is write down a process that has worked for me…

  1. Who is your audience? This is the place to start. If you are giving a talk at a conference, you may have a sense of what the interests of the audience are, but that is only part of it. Do you want your talk to be accessible to only faculty in your sub-area? (Hint : NO). Graduate students? If so, how much background should they have? Most of your talk should be accessible to a certain group — identify that group and target the bulk of the material to them. If you are giving a job talk it’s a different group from a conference or a specialized workshop.
  2. What do you want them to know? You have to be able to summarize what you want to say in one sentence. It’s not going to encapsulate everything, but it should be what you want your target audience to learn from your talk. Write this down and think about it. It’s not easy to summarize your work in a sound bite.
  3. Outlining the talk. Make an outline of the talk that contains one sentence per slide. Each slide should have a single main point that you can write down before adding any content to the slide. Read the sentences in order. It should be a story — does the story flow well? Does it make sense? Do you really need a table of contents slide for a 20 minute talk?
  4. Filling it in. For each sentence, think about how best to explain that point. Pictures are great, loads of equations are not. How can you, in a minute or two, make that point while talking, and what do you need visually to help emphasize that point? This is like storyboarding for a film.
  5. Balancing the content. Now that you have a plan for each slide, check to see that it’s balanced. Too many slides with text will fatigue people. Too many slides with just pictures may lead to confusion.
  6. Fill it in. Fill in the text and make the figures. This will take time, but since you have the sentence on each slide and the plan you should be able to think clearly through what you need to put down on each slide.
  7. Practice. Practice giving the talk once, out loud (not just in your head). You will find mistakes on the slides. Fix those mistakes. Practice again to find more mistakes. You might discover that the story doesn’t flow as well as you thought so you have to go back and retweak things. But always keep in mind the story.
  8. Presentation = Invitation. People say a talk is an invitation to read your paper, but that is not really true, I think. Chances are that more than half the audience will not read your paper anyway, but you still need to teach them something. Of the remaining half, most may skim your paper in the proceedings; you have to make that process easier for them. For the hardcore few who will really spend time reading your paper (because they are reviewing it), you want them to be excited by that prospect.
  9. Planning for contingencies. People get derailed about things like having backup slides with all the details of the proofs. Making backup slides, which are seen 1% of the time, takes away time from making the main presentation, which is seen 100% of the time. Focus on making the main presentation good.

Collaborative paper filtering?

Posted on by

At ISIT 2012, there were posters up for a site called ShareRI.org: Share Research Ideas, an initiative of a student at UIUC named Quan Geng. It’s a platform for posting and discussing papers — sort of like creating a mini-forum around ArXiV posts. It seems to be just starting out now, but I figured I would post the link to see if others take it up. I imagine as things scale up it might run into similar problems as Wikipedia with trolling etc, but it’s an interesting idea which has come up before in discussions with the IT Society Online Committee, for example.

Advice on giving talks

Posted on by

We are at ISIT and I realize I am going over the same points multiple times with my students, so I thought of summarizing everything here.

How to give a better ISIT Talk.

1. Take your talks very seriously.

Do practice runs. Many of them. Your only hope for academia is by giving great talks. Give a practice talk to your friends. In the middle of your talk pause and quiz them: ok, did you get why alpha and beta are not independent? (hint: they did not).
If they did not, it is your problem not their problem.

2. They do not remember what alpha is.

In most talks, your audience does not understand what the notation is, what the problem is, or why they should care. Think of yourself: how often do you sleep or suffer through talks without even knowing what the problem is?
Do not treat your audience like that.

It is a typical scene when the presenter is focusing on a minor technical issue for ten minutes when 90% of the audience does not even know what exactly the problem is, or care.

One important exception is when your audience works on the same problem. Typically only a small part of your talk should be focused on these experts (see also 13).

3. Do a multi-resolution talk.

A useful guideline is: for an 18 minute talk, 7-9 minutes should go on explaining the formulation of your problem and why should anybody care. 5-6 minutes on explaining *what* the solution is and 4 minutes or so, on the actual painful technical stuff. The first part should be aimed at a first year grad student level. The second at a senior grad student in the general ISIT area and the last part to the expert working on related problems. If fewer than 90% of your audience are checking email in the last part of your talk, consider that a success.

4. Try to make things simple, not difficult.

It is a common mistake for starting grad students to think that their work is too simple. For that reason they will not mention known things (like explaining that ML decoding for the erasure channel consists of solving linear equations, because they fear this is too simple and well known).
Always mention the basic foundations while you try to explain something non-trivial. Your goal is not to sound smart but rather to have your audience walk out knowing something more.

Even when your audience hears things they already know, they get a warm fuzzy feeling, they do not think you are dumb.

5. Add redundancy, repeat a lot in words.

Do not say ‘We try to minimize d(k)’.
Say `we try to minimize the degree d which as I mentioned, is a function of the number of symbols k’. Repeat things all the time: Summarize what you will talk about, and in conclusions say the main points again.

6. Go back to basic concepts in words, repeat definitions.

Try to mention the basic mathematical components not the jargon you have introduced. Do not not say ‘Therefore, the code is MSR-optimal‘ but ‘Therefore, the code minimizes the repair communication (what we call MSR optimal)‘. Try to reduce your statements back to fundamental things like probabilities, graphs, rank of matrices, etc whenever possible. Do not just define some alpha jargon in the first slide and talk about that damn alpha throughout your talk.

7. Never go over time.

I have often seen even experienced speakers getting a warning that they have 3 minutes and still trying to go through their ten last slides. When you are running out of time, the goal is not to talk faster.

Say something like ‘Unfortunately or fortunately for you, I do not have time to go into the proof so I will have to skip it. The main ingredient involves analyzing random matchings which is done through Hall’s theorem and union bounds. Please talk to me offline if you are interested…”
Then, go through your conclusions slowly, repeating your main points.
This is another example of multi-resolution: you explain the techniques at a high level first. Even if you had time, you would still first have to give a one sentence high level description and then get into the the details.

8. Draw attention to important slides.

People are probably checking the Euro final when you are at slide 4, explaining what your problem is all about. Wake them up and give a notification that this is the one slide they do not want to miss. Do this right before the critical points.

9. Every slide should have one simple message.

After you make your slides ask yourself: what is the goal of this slide, I just want to explain this part. Iteratively try to simplify your slides into smaller and smaller messages. It is easier for your audience to grasp one packet of information at a time. Do not have derivations on slides (especially for an 18 minute talk), unless there is one very simple trick you really want to show. Showing math does not make you look smarter.

10. Be minimalist.

Every word on your slides, every symbol or equation you put up there dilutes the attention of your audience. Look at each bullet/slide and ask, do I really need this part or can I remove it?

11. Be excited.

Vary the tone of your voice, it may wake up somebody. You need to entertain and perform. Think: if you are not excited with your results why should anybody else be?

12. Cite people.

When somebody has related prior work, cite them on your slide. That has the benefit of waking them up when they see or hear their name.

As Rota says: `Everyone in the audience has come to listen to your lecture with the secret hope of hearing their work mentioned.‘

13. Connect to what your audience cares about.

This is non-trivial and requires experience. If you are giving a talk in a fountain codes session, you do not have to spend ten minutes defining things your audience knows already. Still define it quickly to make sure everybody is on the same page on notation. Knowing how to be at the right resolution for your audience becomes easier in time.

14. Prepare your logistics.

Know the room (go there before), know who your session chair is, have your macbook projector dongle, pre-load your slides on a USB. Bring your charger, disconnect from the internet (fun Skype messages pop-up during talks). If you are using a different machine, test your Powerpoint slides (hint: they look completely different).

15. Talk to people afterwards.

Talk to people about their work and your work. Remember that this is a professional networking event. Do not hang out with your friends, you have plenty of time for that after you go back home. Networking with other students and faculty is very important, in my case I learn more by talking to people offline than in talks.

16. Engineering theory is essentially story-telling.

Our papers and talks are essentially story-telling: Here is a model for a wireless channel, here is a proof about this model. A good story has an intellectual message that will hopefully help people think about a real engineering problem in a cleaner way.
The other aspect of our job is creating algorithms that are hopefully useful in real systems. Think: what is your story and how will you present it in your talk.

17. Read the brilliant Ten Lessons I Wish I Had Been Taught by Gian-Carlo Rota.

Linkage

Posted on by

The NIPS deadline is coming up, so I’ve been a bit harried. However, there are many cool things out there on the internet…

IIT Kanpur wants to open an office in the US to recruit faculty.

Via my father, don’t you wonder where the center of mass of a pizza slice is? This is more of an issue for those New York-style fans — in Chicago the deep dish is a little more stable.

A fascinating post from the NY Times about ephemeral islands which appear and disappear as sea levels shift.

Via BK, a musical film about coffee. It’s part of the Jazz Dance Film Fest, which promises to be my undoing, productivity-wise.

An interesting article on the Dalit movement in Maharashtra.