How to screen PhD/intern applicants: (1) pick your favorite SIGGRAPH/CVPR/UIST papers, (2) reproduce them, (3) ping me when you are done. https://t.co/DCDn2rrMO4
— Li-Yi Wei (@liyiwei) May 28, 2018
May 28, 2018
How to screen PhD/intern applicants
April 15, 2018
More about choosing graduate programs
Recently several people asked me about choosing graduate programs. I answered about this before, but some specific cases might still help.
Q: Choose a program that offers financial support over one that does not.
This is certainly a sensible decision, especially if you are cash strapped, even though that is not what I did (see below).
Q: Choose a MS program that is more likely to lead to the PhD program of the same school/department.
In general yes, if you can find a good adviser whom you can convince to take you as a PhD student by doing good research with him or her.
Q: Choose between a school/adviser good at a direction or a methodology
These are different. For example, you might be interested in computer graphics (direction) and want to apply machine learning (methodology) in some way. Should you choose a professor in computer graphics who knows a bit (but not much) about machine learning, or a machine learning expert who is not really doing computer graphics?
Always pick the one who is better at identifying the problems (directions) than the one who is better at suggesting solutions (methods). Solving a wrong problem (unimportant, too easy, too difficult, too crowded, etc.) can completely derail your research career. In contrast, you can find domain experts to collaborate after identifying a good direction.
[I will add more when I receive more questions.]
When I made my decision more than 20 years ago, it was pretty easy: I wanted to go to a top school in the Bay Area, so I basically had only two choices. And I heard from one around Christmas but not another one until the next April or May. What was more difficult is that I only got scholarships from schools in the east coast, and my family preferred me to go there.
February 18, 2018
The most useful faculty advice I have ever received
From Peter Shirley if I remember correctly:
Do not perform too well on tasks that I do not enjoy so that they would not get assigned to me in the future.
🙂
January 1, 2018
Bean-counting
This has been a widely discussed topic, but when it comes to academic publishing, focus on quality over quantity.
Take my PhD adviser as an example. At this moment, he has “only” 27 journal papers and 40 conference papers according to dblp, but nearly 40000 citations, including 10+ papers with 1000+ citations, according to Google scholar.
In comparison, there are people around his seniority and in our fields (for calibration) with roughly 10-times publications but only one-tenth of citations.
(Citation is one of the mostly commonly used measure for quality/impact, but others are possible, such as products.)
He once told me that the best timing to publish papers is when people beg us to do so (using Brain Curless’ first SIGGRAPH paper as an example). That is probably too extreme, but publishing low quality papers not only wastes our time (it is better to go out and play) but also dilutes our reputation.
November 1, 2017
Simplification
“Everything should be made as simple as possible, but not simpler.” – Einstein
When facing a seemly daunting, difficult, or complex problem, a good strategy is to simplify (in the sense of mesh simplification) the scenario as much as possible, during which the thought process can bring great clarify and insight.
July 18, 2017
Picking research problems
This is the most important stage of conducting research. I do not claim to know the answer, and my experience is limited to specific fields in CS, but (as before) I write this down to get feedbacks and to save the trouble of repeating myself.
Listen to people facing real problems instead of trusting the future work sections in research papers. If there are good (to elaborate) users or product people around you, ask what they need.
Identify concrete problems first, before thinking about other parts like idea novelty, algorithm framework, etc. (Look for hammers after nails.)
If we can find a trivial solution for an important problem, great, solve it, and quickly move on to something else.
This beats the alternative of coming up with a fancy method that does not solve anything.
The problem should fit our interest and expertise well enough, so that we have sufficient willingness and capability to address it.
If the problem is not sufficiently clear or convincing, the research project is probably a waste of time.
If the solution to the problem is not clear or convincing at the beginning, it is not only quite normal but also a potential sign that the problem is sufficiently non-trivial.
March 8, 2017
I almost dropped out of my PhD study
I joined the Stanford computer graphics lab in 1996 summer after passing the entrance test of porting the light field viewer from SGI to PC. When Pat Hanrahan gave his (last ?) SIGGRAPH talk, I was hiding on stage behind him, doing some live demos while trying not to screw up.
After that, I had no idea what I was supposed to do, so I attempted at least 20 different projects. At some point I almost dropped out to join a certain startup (well if I did I probably could retire by now, but who knows). Fortunately, my advisor, Marc Levoy, was very supportive. Eventually I took courses taught by Robert Gray and David Heeger, whose TSVQ and texture synthesis works inspired me to do a course project. I wrote it up and submitted my first single-authored paper to SIGGRAPH 1999, with scathing reviews, mostly because I did not know how to write yet. I took a writing class, and with the help of my adviser, submitted it again next year which eventually became my first SIGGRAPH paper, in 2000, 4 years after I started my PhD program.
For PhD candidates concerned about not publishing enough in their first, second, or even third year, I hope my experience can help you chill out.
I doubt how many of you could have done worse than I did during the initial period.
Granted, your situation might be different from mine (e.g. some degree program is only 4 years and your adviser might not be as cool as mine), but I want to let you know that your PhD study is likely the only period in your life that you can literally try anything you like without the real consequences of failure. So have fun, and you can learn something from everything you have tried, as I did from these 20+ projects.
March 7, 2017
Testing and debugging code
This post is meant for newbies.
Basically, your code should be highly modular, consisting of well-designed classes and functions. Then, unit test each module. This is much easier than trying to debug a large system, or a monolithic piece of code.
I debug almost entirely based on intuition, and never relied on any low level tools like tracers, even when I was a beginner.
For the ray tracing exercise, if you start with the Shirley series, the code should already be modular and incremental. After you finish that, you should have better foundation to design modular code for the ray tracing book by Glassner et al.
Feel free to ask specific questions (e.g. via the comments field of this post), and I will answer by updating and improving this post.
January 18, 2017
Paper length
The obsession with paper length is a legacy of printed proceedings.
What matters most is readability.
I would rather spend 1 hour reading a 20-page paper than 2 hours reading a 10-page paper.
Then follows file size: the smaller the better for storage and transmission.