Open letter to interested research students


I welcome people interested in game theory and mechanism design, who also have some programming proficiency (this is a non-essential requirement), to my group. The end-goal is always to get a good-quality research output -- either in the form of a published research paper or survey or demo/software tool -- which is peer-reviewed/deployed in practice. For the technical part of any project, the basic requirement will be math proficiency and the knowledge of an introductory course like CS711 (offered at IIT Kanpur, so the course number may be different elsewhere. The videolectures are available here; hence, you can self-train).


Typically, the workflow in my group follows the following steps:

  1. Broad sketches: After an initial discussion on what problems you have thought of, some broad sketch of a problem will be given along with some related reading material. It is expected that you go over them carefully and summarize your initial literature survey.
  2. Idea development: The reading material is given with a purpose of expanding on it. It is not merely a bunch of information you should know, but it should help you get a direction to the problem we want to solve. Very often this will need more searching -- use Google Scholar with titles of the given papers and do their forward citation check (linked via "cited by", i.e., the other works that cited this paper) -- and find more relevant reading materials. This process will help you identify the most relevant 2-3 papers for the problem. This is a non-trivial and time-consuming step, but is greatly rewarding and significantly reduces the work during the rest of the project.
  3. Action: Once the most relevant papers are identified, the goal will be to improve those results. If it is a theory paper, then the goal is to prove some new results/theorems. If it is an experiment-oriented paper, then the goal is to design better experiment and show experimental improvement over the current results. This part is again not as straightforward as it is written. Most of the times, the first and easiest approaches from the previous works won't fit our problem and therefore one needs to think about how to modify both the problem and solution meaningfully so that they fit each other without compromising the goal. This and previous step are typically a cyclic process until your results converge.
  4. Wrapping up: Final writing up of the project and send for peer review. When the reviews come back (particularly when improvements are suggested), work on the writeup, upgrade, and send again for peer review. This process continues until no improvements are suggested.

What I expect from you

  • Do the homework. I'll expect that the steps 1 and 2 of the above workflow will primarily be driven by you.
  • Have patience. No good work gets done without patience. You need to spend time with the problem to solve it. It's very unlikely that the first attempt will work. If the first attempt doesn't work out in the ideal way you expected, e.g., a new result within a week/month, have time to introspect and rework. If the project is left midway, it is a significant waste of my time. The progress is difficult to match as a different student has to start from stratch with my efforts repeated. Statistics show that a large number of students leave the project between the steps 2 and 3 above. This is not to dissuade you in any way, rather to give you a complete picture so that you can estimate how much time and effort you can commit for a project with me. If done efficiently, these tasks (spread across 2-3 months) do not take more than 15-20 hours of work per week (roughly two days). However, publishing your work takes time and the suggestions given by the reviewers need to be worked on, and I'd like to have you onboard the project until it gets published.
  • Understand that research is NOT an assignment. There are no set of questions that you solve and get the grade. No, the fundamental difference between assignment and research is that for the assignment, the answers are known and the questions lead you in a feedforward manner to the answer, while for research, the answers are NOT known, and therefore, often researchers take a reasonable path, more often than not, fail, come back, correct the question, and try again -- this feedback loop is sometimes long, unless one is really lucky. So, if you take research as an assignment and don't stay prepared for correcting the things done in the project earlier, that may not work out.
  • Remember. Easy work is hardly good, and good work is hardly easy.

What you can expect from me

  • Guidance. I'm ready to help you in all the steps in the workflow (with more emphasis on 3 and 4). Depending on the problem, the efforts may vary, but this will be an advisory role. You need to work actively on the project, find new results, run experiments etc. I'll certainly help you in fine-tuning the approach to get the results and writing things formally. However, that is possible only when a tangible work is done and you are patient enough to pursue it till completion.
  • Regular interaction. I generally have regular meetings (physical or virtual) with my advisees to discuss the progress of the problem. We discuss the difficulties and brainstorm new ideas.
  • Fun activities. Travel and food :-) For more details, see the group page.

What to write in the email

If this workplan sounds good and you can commit to it, only then we can get started. Send me an email with references to papers that you have read and what problem you plan to work on (this is part of step 1). How your plan of approach is different from what you have read in the literature? Try to keep the email short -- roughly within 200 words.

If you have read this far, thank you! Please mention this (last)name (spelled correctly) in your subject line to indicate that. Just in case you are curious what that lastname is, you should Google it with the query 'that lastname + theorem'.