Undergraduate Research

Required background

Before you plan to sign up for a research project with me, please check if you have the right background by answering the following questions:
  1. Are you familiar with database systems ? Have you ever installed and/or managed Postgress or MySQL or some commercial database system ? Do you have a good understanding of the query processor ? If you answer 'yes' to all questions then: 3 points.
  2. Do you know well the following: XQuery, XPath, XSLT ? By "well" I mean that you have written and run some small program in all these languages, and are confident you can learn easily whatever you don't know. 5 points
  3. Do you know how to write a small context-free parser, and/or how to use YACC/LEX ? 3 points
  4. Are you confortable with both Windows and Linux (or Unix) ? 2 point
  5. Do you know well three of the following four languages: Java, C++, C#, ML (or OCAML) ? 3 points
  6. Basic automata theory and regular expressions. You should know how to construct a nondeterministic automaton from a regular expression, and how to construct a deterministc automaton from a nondeterministic one. 2 points.
  7. Probability theory. You should know what a conditional probability is, and what the formula P(X|Y) = P(X and Y)/P(Y) means. 2 points
If you get 15 points or more then you have the right background to do a research project with me.

The research

I usually have 4 to 5 ongoing research projects with graduate students, at any moment in time. If you decide to do research with me, then I will assign you to one of these existing projects, based on how well your interests match the given project. What follows depends a lot from case to case, but a typical scenario can be like this:
  1. The exploratory phase While this is the most fun part of any research project, the fun part is inaccessible to someone who has never done research before. Honestly, the exploratory research is done by me and my graduate students (you are welcome to participate in all discussions, if you'd like, but you may not appreciate them). Instead, you will be asked to help implementing some component of the project. This is not a typical software development, as you may have seen in a company, simply because the project is not specified yet and evolves as we progress during our research. Some people feel frustrated by the fact that they don't understand the problem well, and that there are no clear specifications and deadlines. Despite the apparent confusion, there is rime and reason to the research project, but is almost never understood by the undergraduate student. While I try to spend between 30' and 1h per week with each undergraduate student, we usually end up discussing basics, instead of focusing on the exploratory part of the research project.

    Some (most ?) of the undergrad students do not get past this chaotic stage: some do not have the right background (hence the reason for the test above), others simply get frustrated by what appeared to be an ill-managed development project.

  2. The creative phase If you survive the first stage, you will end up having developed -- and along the way specified -- a component that was quite unclear in the beginning. Now you and I will discuss what we have done, understand the problem better, know why it's hard, and which obvious techniques work and which not. In this stage we start doing the creative part: find better techniques to solve this problem. Now it starts getting fun for you.
  3. Paper writeup phase If second phase is successful too (and keep in mind that intelligence and hard work are not enough: some luck is needed in any research project), then we will write a research paper and submit it to a workshop or conference. I put lots of hours of work when I co-author a paper, and I expect you to do the same during this period. There is a hard deadline for the workshop or conference, and I always start writing late. As the paper finally starts getting into shape, we may realize that the implementation and/or the experiments that we have do not support well the story we say in the paper. This means that you need to do serious code changes in very short amounts of time. Be prepared to spend nights and weekends before the deadline.
  4. The Reward Days after the paper is submitted and you recovered from the exhaustion, you may want to lay back, relax, and read the paper describing your own work. This is the moment of your reward: you will be suprised to read about a very exciting problem, which others have tried to solve in the past, without getting too far, and about a very clever solution, which is your own. :)