How to turn down an offer

If you are incredibly lucky at some point in your life, you will be blessed with the choice of multiple opportunities, of which you can only accept one. This might be for graduate school, an internship, or a full-time job. This post is how to decline such an offer with grace and poise.

Why is this important to do? Getting an offer in front of someone can be an enormous amount of work, and often requires the stars to align (particularly thinking about faculty job offers). There’s at least one person (and likely multiple people) highly invested in your accepting, professionally and emotionally. Maybe they went out of their way to answer your questions and help you make a decision. And behind the scenes, a lot might have gone on. They could have fought on your behalf and done a lot of work to make that offer come through. The goal is to communicate your decision to these people in a polite and thoughtful way. Besides being a kind thing to do, these individuals are also likely to continue to be relevant in your research career, so best to not leave them with a bad feeling about you.

The worst thing to do: ghost your contacts. That is, after you receive an offer, ignore any and all messages from your contacts and hope they get the picture. They eventually will, but this is quite rude. 

Perhaps par for the course: officially decline the offer, by clicking a button in a system, or emailing the person who sent you the offer (e.g., the department chair, the HR rep, etc.). This may be sufficient, but given the context above, I would recommend a bit more. Imagine you were highly invested in a candidate, you really went out of your way to try to convince them to come, and you learned about their decision only through an impersonal online system, where a field changed to “offer declined.”

A general principle: the more warmth and kindness someone shows you, the more you should give them in return. This principle holds much more broadly than the present context.

Correspondingly, try to identify all the people who you think spent a lot of time/energy/emotions on you and/or would have been excited to see you accept the offer. In the context of a faculty job, this could include the department chair, the host for your visit, and members of the group you’d be joining. If you’re not sure about someone, it doesn’t hurt to include them. And send them a kind email, thanking them, telling them you’re declining the offer, and, if it has been decided, what you’ll be doing instead. In a pinch, even a one sentence email thanking them for their time but you’ve decided to pursue other opportunities is better than nothing. One tricky point is whether to include a reason: if you can do it in a non-offensive way that leaves the door open for further interactions, go for it (e.g., don’t tell them that the people there bored you to tears with their research). If you can’t, feel free to leave it blank. The recipients understand you can only pursue one opportunity, and will appreciate you telling them personally. Sending such emails will of course take some time, but it’s a lower order term compared to the time invested by both parties to reach this point, so it’s worth doing. You can send just one email to all such individuals at an institution, though if you feel like you had a closer connection with someone, you can send them a separate personal message. 

The above may feel difficult to some. After all, sending someone negative news is never pleasant, and one may prefer to just avoid it. But as you progress in your career, uncomfortable situations like this will arise again and again, so it’s worth developing the skills to handle them.

Acknowledgments
Thanks to Bailey Kacsmar, Sandeep Silwal, Adam Smith, and Thomas Steinke for comments on this blog post.

Guest Post: Margins of My Dissertation : Life Lessons that My PhD Taught Me

This is a guest post by Chhavi Yadav — a personal and thoughtful retrospective on her PhD experience and lessons learned therein. Also posted on her own blog.

I expected a spark of joy upon graduating from my PhD. Instead, there was stillness. A quiet that didn’t celebrate the finish, but asked: What did all of this truly mean? Was it just about writing papers, answering reviewer comments, and collecting citations? Or had this long, often messy journey transformed me in deeper, more personal ways? Once the noise quieted, reflection surfaced. Not just on my research, but on who I had become in the process.

The answers, I realized, lived not in the main chapters of my dissertation, but in the margins — those blank spaces that don’t carry equations or arguments — but carry what truly changed. The breakdowns, the risings, the softening, the unlearning, the relearning, the pauses, the unexpected kindness. These reflections became this piece. This isn’t a success story or a guide to academic glory. It’s a deeply personal account of growth, written for anyone who’s been through—or is about to begin—the long haul of a PhD. 

Are we forgetting the human behind the author? Do I recommend doing a PhD? What parts of me did it sharpen and what did it soften? What did I have to unlearn and relearn? Read on to find out.

Kindness is Not a Footnote — It’s a Foundation

I’d heard that “words can heal,” but it wasn’t until I sat across from people on hard days—mine and theirs—that I understood how powerful gentle words can be. Not hollow flattery, not surface-level positivity, but real, sincere warm words. Many think that to be taken seriously, one must be harsh and emotionless. But some of the most thoughtful and intellectually rigorous people I’ve met are also deeply kind. And yes, many of them are men, despite the stereotype that emotional warmth is a feminine trait. I’ve learned that choosing compassion doesn’t diminish your intellect, it deepens it. Kindness doesn’t take away rigor, it humanizes it. You don’t need to be harsh to be right and you don’t need to wound to make a point.

A kind word after a failed submission that soothes an aching heart, a moment of listening during burnout, the simple act of checking in — these don’t show up in your CV, but they’re what keep people going. Especially newcomers, who’re still building their sense of self and in professions where people suffer silently and often feel alone.

The Human Behind the Author

Guilty as charged, the naive me used to subconsciously judge others—and myself—by citation counts and the shine of CVs. But slowly, I saw how misguided—and frankly, how pitiable and almost inhumane—this mindset was. Even the most decorated scholars are just people. There can be brilliant minds who can leave one feeling cold, and soft-spoken researchers whose presence can bring warmth and ease. What matters to me now is the character of the person. How do we treats others. Do we listen. Do we uplift. Do we rise after falling. This shift feels even more urgent today, when paper acceptances are often random, culture is fueled by hype, and visibility can overshadow thoughtful work. Tying worth to these moving targets is a guaranteed path to exhaustion as one will always be chasing. Now, I care utmost about the human behind the author. Everything else is secondary.

Becoming THE Author

There was a time when I did research to prove something, I cannot pinpoint exactly what I was trying to prove, perhaps seeking validation as a serious researcher?? Nevermind, that part of me feels distant now. I started working not to prove anything, but to discover what I actually wanted to say. And slowly, I moved towards becoming THE author — not just of papers, but of my own questions, voice and direction. I still care deeply about research, but I do it with a different intent : to feel at peace and for clarity. Because these questions keep tugging at me, and answering them feels meaningful, even when no one is watching. This resonance is far more grounding I must say.

Keep Moving—You Never Know When It Clicks

One of the most profound lessons of my PhD is: things shift when you keep moving. There were months when nothing worked, when rejections piled up, writing stalled, or I doubted the point of it all. But something always changed when I stayed in motion. An idea clicked. Stuff clarified. Help arrived unexpectedly. It didn’t mean pushing relentlessly or ignoring rest, it meant not abandoning everything completely. So much of progress is not about brilliance, but about staying in the game just long enough for the tide to turn.

Confusion, I’ve learned, isn’t a sign to stop. It’s a sign to lean in. There’s a quote I’ve come to live by: If you feel lost, study harder. If you feel behind, move with discipline. If you feel unsure, create something anyway. Clarity comes through motion and self-authority is earned in small, quiet ways.

Real Friends, Real Breaks, Real Joy

One of the most unexpected lessons of this journey was about rest and friendship. Burnout doesn’t knock politely—it arrives unannounced. The only way I survived was by building rhythms of recovery: real vacations, long walks, weekend hikes, moving my body, eating food I enjoyed, talking to people I like. Some of my best thinking didn’t happen at my desk—it happened while traveling, laughing, swimming, or just being deeply present with life. And through this, I found my people. Friends who were honest and real. Who celebrated my wins and held me during losses. Who reminded me that I am more than my research — why limit yourself to research anyway when you could be soooooo much more??

Do I Recommend doing a PhD?

Only if you know it’s going to break you—and rebuild you—in ways you didn’t expect. If you come in with a romantic and rozy idea of research, it will shatter extremely quickly. But if you’re curious, willing to unlearn, and open to being reshaped by failure and growth—it can be profound. Just don’t go in expecting only answers. You’ll come out with better questions.

So yes, my PhD didn’t just teach me how to publish, present or argue a thesis. It taught me how to be a better human. One who is gentler, wiser, and a little more peaceful. These are the margins of my dissertation and they hold more than any chapter ever could.

Theory Jobs 2025

The Theory community has a tradition of a crowdsourced spreadsheet of sharing who has accepted which jobs, previously hosted by Grigory Yaroslavtsev and Lance Fortnow.

Past years have been slightly chaotic, due to the sheet being an anonymous free-for-all in terms of edits. This year, you can report jobs accepted via this form (which is still anonymous), and view the results on this sheet. If you feel a change needs to be made to the results reported in the form, please email me or fill out this other form (also anonymous, unless you choose to identify yourself).

The rules, from past years, are as follows:

  • You are welcome to add yourself, or people your department has hired.
  • Hires should be connected to theoretical computer science, broadly defined.
  • Only add jobs that you are absolutely sure have been offered and accepted. This is not the place for speculation and rumors. Please, be particularly careful when adding senior hires (people who already have an academic or industrial job) — end dates of their current positions might be still in the future.

To keep this list focused around theory (and particularly theoretical computer science), mild curation will be applied: individuals should have publications at theory-centric conferences such as STOC, FOCS, SODA, ICALP, STACS, COLT, CRYPTO, CCC, ITCS, etc. If you don’t meet this criterion, but still identify as a theorist/theoretician (at least partially), please email me (ideally, with a sentence or two of explanation) at g@csail.mit.edu and I’ll include you, no further questions asked.

Tips on How to Connect at Academic Conferences

I was a kinda awkward teenager. If you are a CS researcher reading this post, then chances are, you were too. How to navigate social situations and make friends is not always intuitive, and has to be learnt. This is particularly true at a conference, where the event is short (just a few days) and the number of people may be intimidatingly large (in the thousands of people). So I wrote this post to give some pointers on how I might go about socially navigating such events, particularly as a newcomer.

I hope to do the following two things:

  • Convince you that connecting with other researchers in your area is worthwhile; and
  • Give concrete advice on how to connect with people at conferences.

Throughout this post, I use the term “connect.” You can think of it as meaning something in the space of “befriend,” “make acquaintance,” “develop a rapport,” or “establish commonalities.” The meaning of the term has been somewhat cheapened by professional connotations and, e.g., LinkedIn. 

Finally, this post is primarily written with large-scale machine learning conferences (e.g., NeurIPS, ICML, ICLR) in mind. Vibes and strategies may differ at other styles of conferences. For example, theoretical computer science conferences don’t usually have poster sessions. And at a smaller conference, depending on how fitting the topic is, you might have an easier or harder time finding someone you can connect with. So your mileage may vary, but I think the overarching principles remain sound across a variety of conferences (and social settings more generally). 

Why connect with other researchers?

Primarily: because it’s fun! For better or worse, researchers often tend to be friends with other researchers. This is perhaps unsurprising, as we befriend people with whom we have something in common, and research tends to be a large part of researchers’ lives. I have made many friends through the research world, who I look forward to seeing every time I go to a conference or workshop. It is generally fun to have friends all around the world: case in point, I started drafting this post while waiting for a researcher friend to arrive, as we were going sightseeing in Hong Kong. I talk daily with many friends from the research community, who are based in a variety of locations, on a plethora of different topics (research and non-research related). 

Secondarily, it can be useful for professional reasons. People don’t generally enter and leave the research community multiple times: the people you will meet at conferences may be your professional colleagues for your entire career. You will read each other’s papers. You will do service together. You will meet again and again at conferences. You may even go to each other’s 65th birthday parties (a common academic tradition). So it can be worthwhile to meet and connect with the relevant people early on. It will give you some familiarity of who’s doing work in your research area and facilitate more natural interactions with them in the future.

This is not (directly) a guide on how to “network.” Networking connotes a primarily professional motive: for example, you’re seeking to find a job, or to feel important because you’re interacting with (supposedly) important people. I just like making friends and connecting with other human beings. Part of why I do research is because of the community. It feels good to be part of something bigger than just myself. I find it a bit off-putting and transparent when people are interacting to network while pretending to be trying to connect. Nonetheless, like I said, connecting with people can be professionally valuable.

How to connect with other researchers?

Now that we’ve established that it’s worthwhile to connect with people, how do you do it? Note that the advice I’ll give here is fairly general purpose (broadly speaking, “find things you have in common”) but specialized for academic settings.

Connecting at the conference

Easy mode: find a socially capable senior mentor in your area (e.g., your advisor) and tag along with them. They will know people, they will know the people you should know, and they probably have enough confidence and social capital to be able to introduce you to relevant people. I have done this for some of my students and mentees before. A caricature of such an interaction: “Hey [student X], remember we read this paper by [student Y] together, let’s go check out their poster! Hey [student Y], good to see you again after [conference Z], this is my student [student X]. Can you tell us about your work? (…conversation about their work…) [Student X] has some interesting results on [topic W] that you’ve been working on, maybe you two can schedule some time to chat later?”

But maybe your advisor couldn’t attend the conference, or they’re busy, and you’re left to fend for yourself. What can you do? Again: try your best to find things you have in common. 

The most natural commonality: research interests. This can manifest in a few different ways. Suppose you see someone whose paper you have read. If you’ve done related work in the area, even better. You can literally walk up to them and say “Hey, you’re [person X], right? My name is [person Y]. I read your paper on [topic W] and thought it was really cool!” You can then ask more questions — maybe something about their paper, whether they’re still working on that problem, etc. You might also tell them about your work in the area. 

Note that this type of interaction will work much better for folks at (or below) your seniority rather than above. For example, it would be very memorable and validating for a junior grad student to hear that someone else read and liked their paper, whereas this might be more common for senior researchers. This is OK. Your goal here is to make friends (likely to be people of comparable seniority), and not “network” with “celebrities.” Besides, there is probably more scientific and professional value to connecting with people at a similar seniority to you, as they will be your contemporaries throughout your career.

Another approach for connecting with people is discovering mutual friends. Perhaps you and the other person have a mutual co-author. Maybe they’ve hung out with your advisor before. If you can mention this in a natural way, it could build an instant connection and some rapport. I’m advocating for, e.g., if you have a suspicion that the person is close with your advisor,  “Hey, I’m [person X], and I’m advised by [person Y]” and see if they know each other. This is more natural than, e.g., “I know [people A, B, and C]. Do you know any of these people?” (though if you have a suspicion they do know someone, e.g., they’re in the same group, that could be less awkward). Mutual friends will generally not be obvious in advance, so a bit of trial and error may be needed. 

This strategy could be described using a loaded term: “name dropping.” Indeed, it is a type of name dropping. But that term usually implies the goal of impressing someone with how famous your advisor is or what elite school you go to. Don’t try to do that. It will only make people like you less. Our goal is to make friends. We’re name dropping to connect with people, not to impress people.

Courtesy Marika Swanberg, here are some other helpful icebreakers and conversation topics:

  • “Hi, I don’t think we’ve met,” if it’s the first time you’re meeting someone. This will generally lead them to introducing themselves, which can be less intimidating than introducing yourself to someone else. In the case you have met before, then they’ll tell you where, and that’s another easy start to the conversation.
  • “Are there any sessions/posters you’re looking forward to this afternoon?” This has a dual purpose. You’ll learn more about them and what they’re interested in. And second, if their research is adjacent to yours, you’ll get some information about what work in the field has got the attention of others. 

When to connect?

We’ve talked about strategies to connect with people. But when do you do it? 

Coffee breaks are, in one sense, the ideal time: the whole point is to grab snacks and socialize. In theory, people are happy to be approached and to talk to people. On the other hand, I know from first-hand experience it can be quite intimidating, especially if you don’t know anyone yet. In practice, you’ll see people talking in small groups like they’re best friends, and it feels like everyone already knows each other (hint: in many cases, they just met within the last day or two). You can squeeze into most such circles and people will generally be courteous and make space for you. Again, this can be scary if you’re not a social butterfly (and if you’re a CS researcher reading this post, you probably aren’t), especially since you have to work your way into the conversation after that point. Slightly easier is to join a group with someone you already know somehow (e.g., co-author, mentor, advisor, someone you already met at the conference) — you don’t have to know them well, even a brief chat at a poster earlier makes it feel a lot less awkward. As a general throughline of this entire post, “friends beget more friends.” But again, this still leaves open how to approach someone for the first time. 

Poster sessions can be a better time to approach people. If someone is presenting their poster, they want to be approached, and you should do so. The caveat is that they are also likely to be busy, with other people wanting to learn about their work, and you should be mindful to not take up too much time. You can build up some rapport with them, and then schedule some time to meet with them later. You may also find people you want to talk to wandering around the poster session (e.g., in the area with posters related to your research). This may actually be the ideal way to approach someone. It has all the social benefits of the coffee break (people want to talk to people), but without some of the drawbacks (people are less likely to be entrenched in conversation groups).

You can also chat with people during conference talks! I don’t mean literally in a talk (that’s just rude), but in the hallway, simultaneous to when talks are going on (sometimes called “the hallway track”). When you first go to a conference, you might think that your job is to attend literally every talk. This can be exhausting and you might not get much out of it. Some senior researchers I know are able to appreciate one or two talks per day, but not much more. Don’t be afraid to skip talks if something else interesting is going on (like a good hallway conversation with someone you’re really getting along with). 

Another common strategy is to email people ahead of the conference, asking if they’ll be there and if they want to meet. This can be tricky, since you might not know who’s at the conference, and even if they are, they might not be so organized as to have planned out their entire schedule. Again, you should try to email people who you’re most likely to have a real connection with, and not just for the sake of networking. 

Conference lunch can have a unique dynamic. If the conference is catered, don’t be shy and sit at a table with literally anyone. This is easier than breaking into conversation circles, because everyone needs to sit on a chair and eat food. If people have to go out for lunch, you’ll usually see groups forming in the lobby. It is not weird to ask to join a random group, even if you don’t know anyone, though once again, you’ll probably feel more comfortable if you do. These groups often merge with others, and then eventually split when you can’t find a place that can seat everyone. Tagging along with a senior mentor can also be very helpful. As an advanced tip: I would suggest trying to eat meals with different groups of people throughout a conference. After finding one group, it’s very easy to just stick with them the whole conference. And if this is your first conference and you’re able to do that, that’s great! But if you can step outside your comfort zone, you might benefit from meeting even more people. 

There are times when you should not approach people at a conference. If they seem in a hurry and walking somewhere. If they’re in a call or a research meeting. If they’re feeding their child. Use your judgement if people look focused or busy with a task — but don’t mistake this with being busy socializing, because that’s a signal that they’re in the socializing headspace.

What next?

After you’ve connected with someone, what do you do next? At the conference itself, there might be plans for the evenings (e.g., dinner) or sightseeing before/after the conference (or even skipping days of the conference itself). It’s easy enough to ask questions like “What are you doing for dinner?” or “Did you have any plans to do stuff in the area?” Either they don’t, and they might be happy to plan something with you, or they do have plans, and might invite you along (if it’s not something small/exclusive). You might end up in a group chat on WhatsApp etc., which will facilitate other conference socializing. There’s often a person or two who takes the lead by suggesting plans — you will naturally find that person. Advanced tip: be that person. People like to do things but don’t always like to organize/lead things, so they appreciate such a person.

Remember that these connections can last beyond the conference, and potentially even a lifetime. If you had a good research conversation with someone, you can send them an email to talk more about it afterwards, potentially starting a collaboration. If you’re traveling through the city where they’re based, you could meet and grab coffee or a meal. You can even ask if you can give a research talk to their group/department. 

Some caveats

This document is written by someone who considers himself relatively extroverted and is already established in the community. I tried to put myself in the shoes of someone who differs in both aspects, but let me caveat the advice I give above.

To address an elephant in the room: many people will be at the conference trying to network. This is not inherently a bad thing, it may be something you are interested in doing as well (though as mentioned before, this is not directly the guide for that). There are however some negative consequences. Interactions with others can feel “fake” or transactional, especially if people network under the guise of connecting. You may feel like you’re being judged constantly, on things ranging from your institutional affiliation to your race or gender. Unfortunately, these elements are present to some degree at pretty much every conference. It can be quite mentally and emotionally draining, and naturally make you want to retreat. But in the context of this post, people who are fake, transactional, elitist, or judging: they’re not really people you want to connect with anyway. If you find yourself in an interaction that’s draining your energy or otherwise making you feel bad, politely excuse yourself and find yourself a way to recover, which may involve hanging out with your closest friends at the conference (co-authors, mentors, colleagues) or decompressing by yourself.

On that note, even absent awkward interactions, conferences can be extremely tiring. There’s a lot of stuff going on, with a huge number of people. On top of this, you might have jet lag. You don’t have to succumb to your FOMO, and it’s perfectly normal to take some time for yourself. This is probably not your last conference, you don’t have to do absolutely everything the first time. I usually try to book accommodation as close to the venue as possible in case I need to take a breather.

You might think that you are not suited for socializing at a conference because you are an awkward CS nerd. But you are at a CS conference: pretty much everyone is an awkward CS nerd. Stated differently, most people are in the same boat that you are, at a big event with lots of people they don’t know, but cautiously eager to talk to people. So don’t think you’re the odd one out who doesn’t belong: we’re all drawn together by our mutual research interests, so everyone belongs.

Other perspectives

While I was drafting this post, someone shared the following article “New in ML: A Guide for Navigating the ML Conference Scene,” by Khimya Khetarpal and Cheng Soon Ong. This is a fantastic guide for a bunch of things you can do at a machine learning conference. It is more professionally-focused than (and thus complementary to) my post. Some folks I talked to found it a bit stress-inducing, so take it more as a collection of suggestions and advice, rather than a must-do guide for a conference. You might vibe more with the strategies in that post (and this one) if you are a Type A personality.

On that note, remember that everyone experiences and enjoys a conference differently! Some people really like interacting with people, others prefer to keep to themselves. Some folks get a lot out of conference talks, while others are spent after just a talk or two. And obviously, everyone has different strategies on how to socialize and connect with people. What I suggest in this guide might not vibe with you. It might even make you think twice about going to a conference! But if that’s the case for you, ignore everything I wrote, go to the conference, and tell me what worked for you. Send me an email! Your strategies or suggestions might even end up in this post (with attribution).

Acknowledgements

Thanks to Antti Honkela, Sandeep Silwal, Adam Smith, Thomas Steinke, Marika Swanberg, Jonathan Ullman for comments and feedback on this post.

Guest Post: Advice for Faculty and Industry Interviews

The following is a guest post by Abhradeep Guha Thakurta, on differences between the interview process for faculty and industry research positions in computer science. What follows is his post, and I’ll add a bit of my own perspective at the end.


By Abhradeep Guha Thakurta

My background

I have spent significant time both in industry and academia, and have been on hiring/interviewing panels on numerous occasions in both. I have noticed striking yet subtle differences in the expectations of the interviewers which tend to make considerable differences in the outcome. In the following, I tried to summarize (in my opinion) a few of the critical differences. These thoughts initially originated from a chat thread with a few of my colleagues, which I translated into a more stand-alone document on the advice of Prof. Gautam Kamath.

To bring some credibility to the points I raise, here is my professional background: I have been in the following industry research labs: Microsoft Research (post-doc), Yahoo Labs, Apple, Google Research – Brain Team, and Google DeepMind. Additionally, I have been a tenure-track faculty at the UC Santa Cruz Computer Science and Engineering Department. I have more than 50+ publications, 10+ patents, and 700K+ worth of NSF Grants as PI.

In the following, I will contrast the academic and industry research interviews.

Disclaimer: These are all my personal opinions, and may grossly underestimate the nuances in the process.

Interviews in academia

  1. Qualities on which a candidate is judged: The interviews in academia typically judge a candidate on the following two aspects.
  • Research: The candidate is judged on whether the candidate does interesting research which the peers will appreciate. What appreciation means here are a) Can the colleagues at the university write papers/grants with the candidate, and b) Will hiring this person bring repute to the university. (a) mainly translates to NSF/NIH style grants with dollar amounts associated, and (b) mainly translates to how many top quality research papers the person produces.
  • Teaching: It is a very important part of hiring. Can the candidate articulate their research (to students). This thoroughly should come out from the job talk. The candidate has to articulate the importance of their research to folks who are completely out of domain expertise. As a result, in academia bombing a job talk is mostly the end of the world.
  1. Research statement and teaching statements: They are super lengthy. Most people do not read it. What hiring folks do is skim over it. I got brilliant advice from a mentor of mine, who said “If you want anything to be read by the hiring committee, write it in the first page, and write it in bold. Do not waste space to introduce your research area. Since, if someone does not know your area, they are anyway not going to fight for you.
  2. Job-talk vs 1:1 interviews: Job talk plays a crucial role in the interview process, possibly much more than the 1:1s. The purpose of the talk is to demonstrate three things simultaneously: a) Can the candidate teach, b) Can the candidate explain the research to faculty in allied areas, and c) Does the research have real substance. (a) is judged by whether the talk (at least a half of it) is understandable to a first-year grad student. (b) is judged by conversations during the talk with colleagues from allied areas. Again the objective here is to figure out whether the candidate can articulate their research to a NSF panel to get grants. Finally, (c) is judged by one expert in the area, which typically is the candidate’s host.
    1:1’s are fluid, and the candidate is mostly judged subjectively. However, even under subjectivity, it is necessary that the candidate creates a synergy with at least two senior colleagues who would fight for the candidate in the hiring committee meeting.  One uncomfortable fact is that because of the subjectivity, this is where most of the variance in the hiring process comes from. It is almost impossible to optimize for it beyond getting a few of the basics right. For example, doing research on the interviewer (including asking folks about the personality), being polite and respectful, and trying to relate the research to the interviewer’s work in a genuine way.
  1. Timing for application: Mostly synchronized. Happens at the end of the year, with interviews in Jan to April.
  2.  Repute of the candidate: The hiring has a strong correlation with the repute of the candidate, and how famous the letter writers (and of course what they have written :slightly_smiling_face:). Best letters are the ones which make comparison statements. (E.g., The candidate is comparable to researcher A, who the writer has mentored over the years.) Telling a candidate is a great person is not super important.

Interviews in industry research labs

  1. Qualities on which a candidate is judged: The interviews in industry labs typically judge a candidate on the following aspect.
  • Research: The hiring team wants to see the depth of the candidate’s research and not the breadth. The candidate will be mostly talking to domain experts from very aligned areas of the candidate. The job talk is of a very different flavor than academic one. The best industry job talk is the one that focuses on one problem and goes arbitrarily deep into it.
    • Uncomfortable fact 1: Industry job talks are just conversation starters. Unless the candidate manages to annoy an interviewer present in the talk, it does not count much even if the candidate semi-bombs the talk.
    • Uncomfortable fact 2: Most industry labs interviews nowadays have a coding component (LeetCode type or otherwise). If the candidate fails in those, the chances of getting an offer is fairly low, even if the candidate is stellar researchwise. The reason is labs typically want folks who are generally strong, and can pivot to different areas as needed, and basic general purpose skills are mandatory requirements.
  1. Research statements: Many research labs require research statements and letters of references. They are much less valued in the industry than in academia. In many places they are there for legacy reasons, since the nature of research labs have changed significantly over the years. Of course, a bad letter of reference strongly counts against the candidate.
  2. Job-talk vs 1:1 interviews: In industry job talks are conversation starters, and the focus of the job talk is much narrower. Unlike academic job talks, the sole purpose of the talk for the candidate is to demonstrate the depth of research, which can “wow” an expert in the field. Talking about a problem at great depth is more advantageous than demonstrating breadth. Think of giving an invited talk at a workshop only attended by experts in the field. If a candidate is preparing a job talk both for academia and industry, it is worth preparing two different talks. 
    1:1 interviews are much more structured than academia. There are usually two sets of interviews. One that figures out research depth, and the other that figures out actual hands-on experience with coding (extending from LeetCode to PyTorch debugging.) Research interviews typically are general conversations on research, with a specific problem to be solved at the end (usually in the last 15 mins). Getting a satisfactory answer to this question decides the result of that interview. Coding interviews are standard with correct/incorrect answers. So, there is no subjectivity. Also, they hold a much higher value than a research interview. In both research and coding interviews it is usually safe to be grounded, and not making broad statements. The interviewers that are assigned to Ph.D.’s or post-docs are usually senior people, who can easily tease apart truth from fake.

3. Repute of the candidate: While the repute of the candidate may be important towards securing an interview. It hardly has any impact on the outcome of the interviews. Mostly the outcome depends on the performance of the candidate in the interviews. One crucial aspect of industry research interviews is how the candidate interacts with engineers in the group and in the rest of the organization. Meaning, does the candidate have the appetite and skill to sit down and solve a problem end-to-end, or will just provide high-level advice.

4. Timing: Industry lab hiring happens all the time, mainly based on the requirements. However, once an offer is received it can be delayed pretty much. The reason is both parties (the candidate and the company) know that the employment is at-will. So, it does not make sense for someone to come and leave in a few months with monetary damages to the company. Rather it is best to give the candidate time to choose. There are of course exceptions.

5. Post-doc versus full-time: There is not much of a difference in the industry in terms of job description. Of course one is term limited, no stocks, and lesser pay. If one is looking for an industry post-doc, it is sometimes worth taking a full-time position, and deferring the decision to later.


I (Gautam Kamath) will add some of my own commentary on the academic side of things, given my experience as an assistant professor of computer science at the University of Waterloo in Canada.

I agree with most of what Abhradeep wrote. I diverge slightly when it comes to judging a candidate’s research. To remind, the two conditions that he talked about were the following: a) can the colleagues at the university write papers/grants with the candidate, and b) will hiring this person bring repute to the university. In my experience, the former has not been very important. I personally have never heard discussion on whether a candidate would be able to win grants. This is likely due to a combination of a) being at a Canadian university rather than a US university, and b) being in a computer science department inside a school of mathematics, rather than a computer science and engineering department inside a school of engineering. We also don’t explicitly look for collaborators. On the contrary, if a candidate’s expertise is too similar to others in the department, this may be a reason to pass them over. While collaboration is of course welcome, in the end, faculty are expected to lead their own independent research program. Overall, our goal is to identify and recruit researchers doing field-leading research.


Abhradeep also comments that, in letters, “telling a candidate is a great person is not super important.” I agree, but for me personally, it is valuable that a candidate is a great person. That is to say, besides hiring a researcher, you are also hiring someone who might be your colleague for the next 50 years. I would prefer to hire someone who is willing to help out around the department or group, chime in with their expertise at times when it is needed, and generally work towards making their departmental community a better place. This is always a lower order term compared to research, but being a great person can make me extra excited about a candidate. And certainly, on the other hand, if a candidate has a negative reputation about their personality, this can outweigh the merits of their research.

Foundations of Responsible Computing Job Market Profiles 2024

Adam Smith, Jon Ullman, and I compiled a collection of profiles of “FORC-y” people on the faculty job market this season. FORC stands for foundations of responsible computing, which means “mathematical research in computation and society writ large”, including work on private data analysis, fairness, robustness, and mathematical approaches bridging computer science, law, and ethics. We had 29 people who chose to participate, check them out!

You can find the PDF with profiles here.

Guest Post: ISAAC’24 in Sydney: Registration deadline soon!

Clément Canonne asked to pass along the following registration info for ISAAC 2024, which will be in Sydney in early December. I was lucky to visit Sydney in July 2017 for ICML, and it was one of the most fun conference trips I’ve had! (Painfully long flight from Boston aside…) Definitely attend if you can!



The registration for the 35th International Symposium on Algorithms and Computation (ISAAC 2024), to be held in Sydney (Australia) on December 8-11, is open for only a few more weeks!
Besides the conference itself, the registration includes lunches as well as a ticket to the conference banquet: https://www.trybooking.com/events/landing/1249687
Registrations are open until November 29, AoE:
Student: AUD 480 (~USD 325)
Regular: AUD 960 (~USD 650)
(Note: There will be no on-site registration.)
For more details, see https://sites.google.com/view/isaac2024/registration?authuser=0
Looking forward to seeing you at ISAAC in Sydney!

Principles for Planning an Academic Workshop

Workshops are my favourite type of academic meeting. Smaller than conferences, more focused on a particular area of interest, and featuring the latest results. Planning a workshop can be a challenging endeavour. As an organizer, it is hard to foresee what makes for a good experience for the audience. I have co-organized a number of workshops of different shapes and sizes (e.g., 1, 2, 3, 4, 5), and put a lot of thought into what makes for the best audience experience. I will share some of my thoughts and opinions on how to plan an effective and enjoyable workshop.

This post will focus on single-day workshops with a combination of invited talks and contributed papers, which in particular are common at machine learning conferences. However, the same basic principles should still hold for other formats, e.g., week-long workshops.

Principles

Let’s start from the basics. What are the goals of an academic workshop? Why are we even doing this? Here are some reasons, listed in roughly decreasing order of importance.

  • Facilitating meaningful interactions between participants. While somewhat abstract, this is by far the most important goal of any workshop. Connections between individuals lead to sharing of ideas, new collaborations, and help develop a sense of community. Through a combination of these factors, I find myself most fulfilled and inspired after a workshop with a lot of individual or small group interactions. While the importance of the first two factors may be self-explanatory, I really want to emphasize the last one. Research can be lonely, and it helps to recognize that you’re part of something bigger than yourself, and that someone else actually cares about the same things you do. Some ways to facilitate interactions include breaks, poster sessions, breakout groups, and social events.
  • Sharing the latest work in the area. Research moves fast. By the time things are published in conferences, the work and ideas may be a year (or more) old. Participants can learn what others are actually working on right now, and those with work-in-progress can get thoughtful feedback from experts in the field. This is typically done via poster presentations and contributed talks.
  • Highlighting significant lines of research in the field, and next directions. Research areas can be broad, and it is easy to myopically focus on one’s smaller sub-area. It is important to “zoom out” and see what’s been going on elsewhere in the field. This is typically done via invited plenary talks.

Based on these principles, from most to least important, the schedule should feature breaks, poster sessions, contributed talks, and invited talks. However, I’ve noticed workshop organizers often prioritize these in the opposite order.

Concrete Suggestions

Here are some suggestions when planning the schedule for your own workshop.

  • Have plenty of breaks. Workshops can be tiring, and few have the endurance to maintain their attention for hours at a time. Have plenty of breaks to keep people fresh. This also gives people the opportunity to mingle and discuss the ideas presented so far. If your workshop is part of a bigger conference featuring set coffee breaks, make sure to sync with those breaks.
  • Schedule for lunch. Everyone needs to go for lunch. If your workshop has lunch provided on-site, an hour should be enough time. If folks have to leave the venue, budget at least 90 minutes. If you leave less time, you risk the poor post-lunch presenter(s) having no audience. And it should go without saying, but do not schedule other things overlapping lunch (except maybe something social, see below).
  • Poster sessions are the most valuable part of any workshop. At pretty much every event I’ve gone to, the poster session has been the most enriching part of the program. Make sure it is scheduled at a time when the most people will attend. If there are many posters, consider having multiple disjoint sessions. I’ve found that 90 minutes is a sweet spot for the length of a poster session. And if you have control over the logistics, make sure the posters are well spaced and easy to gather around. If poster sessions are too crowded or difficult to navigate, people will do something else instead.
  • Throw in some social events. While you’ve got everyone in one place, consider scheduling some non-technical components. One favourite of mine is the “junior-senior lunch”: organize so that a “senior” person (i.e., someone with a permanent job) go for lunch with a group of “junior” people (i.e., students and postdocs). This mixes people who might not otherwise interact, and gives the opportunity for senior folks to share some valuable mentorship with the juniors. Another idea is to organize an optional and informal post-workshop outing for food, drinks, etc.: a great chance to casually unwind after a long day.
  • Encourage intellectual diversity. When curating the program, make sure you represent a variety of different perspectives and topics. For example, when planning the talks for TPDP 2022, we made sure to have a mix of theory and practice, academics and industry, etc. The audience shouldn’t leave the workshop with the impression that only one sub-area is important.
  • Prompt your invited speakers. Invited speakers are often established researchers, who have broad research agendas, a deep understanding of a sub-area of the field, and meta-perspectives that go beyond a single paper. Thus, it’s a bit disappointing if an invited speaker just chooses to focus narrowly on their most recent paper. Try to guide them to think bigger, potentially speaking about a collection of works, or a research direction that they think is particularly interesting or important. This distinguishes them from any contributed/spotlight talks, which are more focused on a single work.
  • Accept generously, spotlight judiciously. Space restrictions aside, there is little harm to accepting many papers as posters. As long as the results are relevant to the theme of the workshop, seem sound/correct, have at least something new/interesting, and don’t “do harm” (say, the paper is clearly misleading or poorly framed), I tend towards acceptance. That said, time on the schedule is at a premium (see the final point in this list), so be conservative when choosing which submissions to spotlight with a talk. Try to select things that you believe “everyone must know.” Otherwise, the interested parties can connect during the poster session. Another benefit to fewer spotlight talks is that the talks can be longer: many find it difficult to get something meaningful out of very short lightning talks, and the rapid switching is very tiring.
  • Dialogue is better than monologue. Many people enjoy and get a lot more out of interactivity. It can get boring and hard to follow if one just sits around all day watching a bunch of talks (invited or contributed). Instead, consider ways to have participants engage on technical topics one-on-one or in small groups. The obvious way to do this is via poster sessions, but be creative! Other options include breakout groups or open problem sessions.
  • Fewer invited talks. Invited talks take up a lot of time. It is common to schedule these for at least 30 minutes, and having multiple such talks adds up fast. At the same time, workshop organizers are often incentivized into inviting tons of big-name speakers: it may help your workshop get accepted, and attract attendees to your workshop. But this backs you into a corner after you have to design a schedule around them. Consider having only a small number of invited speakers (I think two to three per day is ideal). This features some big picture talks and attracts an audience, while still leaving space for more interactive exchange of ideas. I consider a full day of invited speakers to be a missed opportunity: the vast majority of attendees would end up not saying a single word.
  • Less is more. More generally, the most common pitfall is succumbing to the urge to cram everything into a single day. Many organizers first commit to all the incredible content they want to host, and only after do they figure out what can actually fit in the schedule. These two steps need to be done simultaneously. Otherwise, the schedule becomes far too packed, and the day becomes a marathon of back-to-back talks with few or no breaks. It’s important to remember that things will also inevitably fall behind schedule, so leave some breathing room to keep things comfortable for the attendees and less stressful for the organizers. I once attended a workshop intended as a “mixer” between two groups, where the organizers stuffed the schedule to be way too full. I left the workshop without the chance to talk to anyone from the other group!

For a concrete example of what I think was a well-scheduled workshop, take a look at TPDP 2022. We had frequent breaks, multiple long poster sessions, and “only” six spotlight talks and two invited talks. This might seem like a sparse program, but it gave lots of room for people to interact, and the talks were all high quality and long enough for people to really get something out of. If I could change anything, I would have tried to coordinate junior-senior groups for the lunch break, and organize a social outing after the workshop. But folks at the time were quite cautious about COVID, so we decided against it.

Acknowledgments. Thanks to Ferdinando Fioretto, Thomas Steinke, and Florian Tramèr for comments and feedback on previous versions of this post.

Guest post: COLT 2022 Call for Open Problems

The tireless Clément Canonne is the open problem chair for COLT 2022. He asked to share this call for open problems. Please submit your best!


The 35th Annual Conference on Learning Theory (COLT 2022), to be held in London on July 2-5 and remotely, will follow in the footsteps of previous editions and feature an Open Problems session, where attendees can present their open problems and suggest them to the learning community — and possibly offer prizes for their resolution! (After all, a little incentive goes a long way…)

The deadline to submit an open problem has been extended to Monday June 20, 4pm PDT. If you have any nagging question or stubborn problem, please submit them!

More information and CfP: https://learningtheory.org/colt2022/cfp.html#openproblems

How to Ask for a Letter of Recommendation

The end of the year is approaching at an alarming rate, which means that many students will require letters of recommendations for graduate school or jobs. These letters are written by more senior academics and researchers at the busiest time of the year, when they’re handling other responsibilities like research, teaching, grant writing, and reviewing, and may be writing a dozen letters on top of it all. The purpose of this post is to guide applicants on how to ask for a letter of recommendation, simultaneously strengthening the applicant’s package, and making the letter writing process as painless as possible for their writers. Feel free to share this with anyone applying for grad school or jobs. If someone is asking you for a letter, you could share this post with them, so they know what you need.

Note that this document is written by a computer scientist and intended for applications to computer science things, and may or may not carry over to other fields.

Whom to ask

Ask people who know you and your work well. Ideally people who you’ve worked on research with. Their words will carry the most influence for whatever position you’re applying to. On the other hand, if you don’t have a letter from someone you did a major research project with (especially when applying for grad school), this is a red flag. Aim to have at least one such letter. While grad school applications typically solicit three letters of recommendation, very few people have all focused on research (I personally had two, from co-advisors on one project).

Some have suggested having someone “at arm’s length” is beneficial for faculty applications (and anything that comes later, including awards and fellowships), in order to show that your work is known more broadly in the community. 

Letters from people who did nothing more than teach you a course are typically valued much less than research-based letters. Nonetheless, most grad school applicants will have at least one or two such letters, since it is rare to have the opportunity to do research projects with three different advisors. If you must, try to request letters from people who you left an impression on, or otherwise had meaningful interactions with. Try to avoid letters from people who can do nothing more than repeat information on your CV/transcript: these letters are often very short and uninformative, and as with any such letter, are unlikely to help your case (and may even hurt it).

When to ask

Please ask well in advance. As a rough rule of thumb, by late October is reasonable for “standard” deadlines which are in December, which is common for CS grad school, postdoc, and faculty applications. You might have to ask earlier if there are earlier deadlines (which is the case for some postdoc applications), but give at least a 6 week lead time. Try to mention the earliest deadline in your email request.

Asking early also benefits the applicant. You should have a solid picture about these key details of your application well in advance.

I may still agree to write a letter for you even after the end of October, but chances decrease the longer you wait. On the other hand, I am more likely to agree to late requests if I know you very well or we have worked together very closely. However, I would still be annoyed, and you probably want to avoid annoying your allies in this process.

How many places to apply?

A common pitfall I’ve observed: people apply for only a few positions, with the justification that they “don’t want to waste their letter writers time.” Don’t do this. 99% of the time and effort goes into writing the letter, it’s easy submit to arbitrarily many places. Be selfish: once they have agreed to write a letter, they’ve committed to supporting you, and you should put your own preferences first. And think of what’s a better use of their time: if you apply to 2 places and get 0 offers, or if you apply to 30 places and get an offer that you accept?

What to provide

You should give your letter writers as much information as possible. They might not use all of it, but it is good to have on hand when they are inevitably writing letters at 4 AM the day before after the deadline. I’m writing this as a catch-all list, so some points might not be relevant for the position you’re applying to. Say, when you’re applying for faculty positions, they don’t need to know your undergraduate grades. The goal is to give your writers the gist of who you’re trying to market yourself as, so they can support your story as best they can.

This doesn’t all need to be provided when you first ask, but please share it as early as possible. Make it as easy to find as you can. For example, a single email with everything as an attachment, and a clear title to the email such as “X’s application materials”. You could also share a link to a Dropbox or Google Drive folder with all the materials. This has the benefit that you can include preliminary versions of your materials, and update them as you refine them.

Mandatory:

  • A shared spreadsheet with a list of all the places you’re applying to, the deadlines, any special instructions for letter submission, and a space to mark when the letter is submitted.
  • Your research statement/statement of purpose
  • Your CV

Optional but recommended:

  • Anything else that the application asks you for, e.g. your cover letter, teaching statement,  diversity statement, transcript.
  • Who else is writing letters for you, and what your relationship to them is.
  • A brief summary of the work you’ve done or the contributions you’ve made with the recommender, to refresh their memory.

The last one is helpful since I like to know what “role” I’m playing. Am I your lead letter writer who people will look to first? Or am I the third letter, mostly confirming what other people already know? There may also be some unique perspective I can give, based on who your other reviewers are.

Finally, be sure to waive your right to view the letter when requesting it. I personally will not write a letter if this right has not been waived (and I would also be annoyed to receive such a request). It’s also not to your advantage to have such a letter, since a reader wouldn’t be able to trust what the writer wrote.

Some additional tips, which may be helpful for slightly older readers of this post (e.g., junior faculty):

  • Consider providing an “annotated bibliography.” This isn’t a well-defined object, but I have a document describing (in plain English) some of my most important works and their significance/impact.
  • If you ask the same person for a letter multiple times, they will probably update their previous letter. Consequently, it is helpful if you provide them with materials that highlight (e.g., in colour) the differences with the previous materials.

Afterwards?

To the best of my knowledge, it is not customary in Computer Science to send gifts to your letter writers. You should just thank them genuinely, and pass on the favour when you are in a similar position of power.

What if…

It has been brought to my attention that, unfortunately, many letter writers ask the applicant for either a draft or full letter, which they simply sign. I could write a whole post on this topic, but in short, I consider this unacceptable behaviour from the perspective of the letter writer, and I urge them to rethink this practice. 

But what should the applicant do when put in this position? It helps if you can see what typical academic recommendation letters look like, since they have a certain tone, but access to such letters is generally out of the reach of most applicants. My recommendation is to be positive (now is not the time for modesty), but don’t lie (these things can follow you around for longer than you might think). Try to make the first paragraph a brief summary that conveys the overall sentiment of the letter. In subsequent paragraphs, you should describe the research you worked on with the letter writer (don’t assume the reader is highly familiar with the topic, but be succinct in terms of background), as well as your specific contributions to the project. Include anecdotes, if appropriate. This may be awkward, but you have been put into an awkward position.

Statement of Purpose?

You probably haven’t written anything like a Statement of Purpose before. Here’s two resources (1, 2), by Boaz Barak and Yisong Yue, where they describe what goes into a Statement of Purpose. Naama Ben-David‘s statement is used as an example.

Acknowledgments

Thanks to Anand Sarwate, Thomas Steinke, and Jon Ullman for helpful comments.

Design a site like this with WordPress.com
Get started