Faculty job talks: tips from the faculty

    Here, our faculty members share what they are looking for in a faculty job talk.

    Saman Amarasinghe and Deanna Montgomery (Co-instructors for MIT EECS Academic Job Search Seminar)

    A job talk should demonstrate that you will be a good researcher, a good teacher, and a good colleague. First and foremost, the talk should convey a vision that gives the audience a picture of who you are as a researcher. This vision should encompass both your past and future work. The job talk should not look like a really long conference talk or several conference talks sewn together. The audience for a job talk is usually significantly more broad than that for a conference talk. Taking this into account, your talk should both be broadly accessible to everyone in the department, and show depth.​ It is important both to give enough background and motivation that your audience will understand and care about your research, and also to clearly demonstrate your contributions to the field. A job talk need not describe all your past research or even your most recent research. Rather, it is best to highlight your most impressive contribution(s). 

    You are not only evaluated for your ability to do ground breaking research, but also your ability to teach. A good job talk is well-practiced and rehearsed but not read or recited from a script. The talk should be shorter than the time allotted, to allow plenty of time for Q&A. How you answer questions during the job talk is extremely important because it shows that you are not simply a good actor who can practice and deliver a nice talk but rather that you can also think on your feet. Treat people asking questions with respect. No matter how simple or complex the question, acknowledge the question and answer it to the best of your ability. If a question is out of scope or you don’t know the answer, it is best to say so and redirect to something you are able to speak about with confidence. If one audience member is being too disruptive (frequently interrupting with questions and comments), politely move forward, perhaps reminding them that you have to finish the talk on time and inviting them to talk to you individually later. Always keep an eye on the time.

    Hari Balakrishnan

    The others’ points are all great. 

    I’m looking for two things: 1) is the work interesting and important, and 2) is the candidate already, or likely to be, among the best in the world at something presumably related to the first question (and if so, what is that something)?

    A good storyline is important because most of your audience will be outside the area, though they will be intelligent. To paraphrase Randy, assume infinite ignorance but high intelligence.

    Randy Davis

    Assume your audience is ignorant but smart. Of course they are ignorant — they don’t know what you’re going to say. So start at the very beginning. But they are smart, so move along rapidly from the really big picture on into the specific problem you’re working on. That will show that you know the larger context of your work and importantly will bring the audience along with you (very few of them will be experienced in your thesis area).

    Another good heuristic: imagine that your talk is done and one of the audience members is on the way back to their office when they run into someone who says “I couldn’t get to that talk today; can you give me a quick summary of the important things he/she said?” A good, sharply focused answer to that question is probably three sentences long. Your task is to figure out what those three sentences are before you give your talk, then design the talk so you convey them clearly. Knowing what you want your audience to learn is one of the most important principles of giving any talk.

    Don’t assume you have to have a slam-dunk answer to every question. It’s ok to say, e.g., “No I hadn’t heard about that work. I know about X’s work in that area, but not what you mentioned. I’d like to follow up with you after the talk.”

    Beware of “isn’t this just X?” questions. That’s not a question, it’s an indirect critique, and the “just” is the dagger.  In your head imagine the question as “Is this X?” or “How does this compare with X?”  and answer it. It may be in part X, or may borrow something from X, or may be a variation on X,  or might be very different. But unless you (and your advisor) have goofed bigtime, the work should not be “just X” (at least not at the top level; down in the details you may be using a well known idea/algorithm that someone recognized, in which case the answer is “yes it is.”)

    As best you can, understand how you might be viewed by the faculty, how you might fit into their view of what they want in their department, and how you want to position yourself. If you can do this well (and it’s ok to talk to the faculty about it), the easier you’ll make it for them to see you as part of the department.

    Fredo Durand

    A job talk should have technical depth. It should make sure I understand a technical problem, why it’s hard and important, and then what is the intellectual breakthrough. Depth is more important than breadth. If you have multiple contributions, at least one of them should be given full depth, and the other ones will probably have to be summarized more heavily.  The main contribution described in depth does not need to be your latest work, just the most exciting and consequential (the main part of my own job talk had been published 5 years prior, for example). The talk should allow me to understand at least 80% of it, even if it’s far from my area. This is often in tension with the depth goal, but you have to strive to achieve both. And that’s why you can often only afford to cover a single contribution in enough depth even though you have ~45-50 minutes. Make sure you spend enough time explaining the problem and why it’s hard. It may be obvious for people from your scientific community, but you need to explain it to people with a broader set of expertise. For example, a talk by a computer architecture researcher needs to be at least 80% understandable by a faculty member who works in machine learning or computer graphics. I personally don’t expect a ton of discussion or future work, but there should be some of it, and you should be able to answer questions about what you discuss. Said differently, don’t put anything if your answer to a question is going to be something like “I don’t know, I haven’t figured out how to get started.”

    Polina Golland

    A good job talk will tell me about the big problem the candidate is working to solve, how their specific work connects to that big problem and to other areas that are related, and technical depth of the solution. I want to learn about new areas and how they connect to what I already know, and to see how the speaker is pushing the boundary of what we know or know how to do.

    Daniel Jackson

    I hope to leave a job talk with two things: first a deeper grasp of something I didn’t previously understand (which is almost everything, since most job talks are not in my field!); and second, an appreciation for why that thing matters. Because it’s really hard to assess how significant a research contribution is outside my area, I place much more weight on whether the ideas are explained in a compelling and creative way. I assume that someone who shows a deep understanding of a problem, by being able to explain it convincingly to outsiders, is capable of advancing their field. Of course, if you have impressive solutions to present, that’s even better. 

    In terms of advice for giving presentations, like some of my colleagues, I’d emphasize the importance of telling a story. Sometimes you can explain an idea in a logical sequence the way some math textbooks work. But usually it’s better to tell a story, especially if that story is personal. In terms of slides, I’d recommend eliminating as much text as you can, and rely almost entirely on diagrams and images. And here’s the most important piece of advice but the most challenging to follow: identify the thing that’s most central (and often hardest to understand) and explain it fully.

    Stefanie Mueller

    Great job talks have an overarching vision where each project contributes to accomplishing this long term goal. The vision should be unique and not something I have seen elsewhere before. Ideally I learn lots of new things in the talk. It also helps if the projects use a variety of different research approaches and technical skills to ensure that the applicant is not a one-trick pony and has the breadth of skills required to lead a research group in which students will have diverse interests and technical backgrounds. Communication skills are also very important to get the content of the talk across to the audience. I expect somebody who can give a talk confidently at an appropriate pace without running through the slides like they just want to get it over with. For the Q&A, I expect the candidate to really listen to the question, take a moment to think about the answer, and respond with an answer of appropriate length, i.e. not just two words but also not talking for 10 minutes. Do not run overtime with your talk (i.e., at MIT we start 5 minutes late, end 5 minutes early, that leaves 50 minutes for your talk including Q & A, so your talk cannot be longer than 35-40 minutes max).

    Will Oliver

    In these kinds of talks, I look for a candidate who can communicate at various levels, as stated above. I’m a Ph.D., but I’m likely not doing exactly what you are doing. So, the talk needs to be presented at the appropriate level. There can be a few slides for the true experts in the audience, but most (90%) of the talk should be accessible to an educated person outside your field. 

    I also look for a storyline. How do you, as the candidate, organize and present your work? How do you think about it and its broader context? Why is this important, and what might it lead to? How does it integrate with other areas of research? How does it connect with what you want to do at MIT?

    Ruth Rosenholtz

    I agree with pretty much everything here, and I wanted to expand on Randy’s points about answering questions. Answering questions is a great opportunity to show you’re smart and show who you are. If you don’t know about the exact work someone asked about, it’s a good time to show what you do know. “I don’t know about that work of X’s. It sounds like you’re saying they did Y, a bit like the work of Z and colleagues. That work of Z et al was a clever idea, and it’s a bit like what I did except…”

    Another point to make about the gotcha “isn’t this just X?” and similar questions: If this person is doing this to you, they probably have done it to a bunch of people in the audience. There are probably a lot of sympathetic people listening, and they mostly want to see you can handle yourself maturely. I agree with Randy that it’s best in most cases not to take it personally, to ignore the dig, and just answer the science question as best one can.

    Suvrit Sra

    Small additional correlated thoughts: Talks that conflate “depth” with “mere grinding through the technical details” are best avoided. Focus on your work that conveys high ambition and novelty, while grounding it in a broad context, and while exhibiting the depth of your individual contribution. Do keep in mind the “more is less” view, because rushing through several contributions can give the appearance that one or two key contributions are not strong enough to pull their weight.

    Vivienne Sze

    I agree with all the points above – particularly making the talk accessible to a broad audience with different expertise – I would like to walk away having learned something from the talk, even if I’m not an expert in the area. I’m interested in why the work is important (its impact and its role is the bigger context), what is/are the key insight(s) to the work (why was it difficult or how is it different from how others have done it in the past – it is important not to get stuck in the weeds here), and, if possible, what are the key principles that can potentially be applied to other domains or other works.