Suggested Talking Points
This isn't meant to be a script you have to follow, just some points
you may want to cover. Please try to talk about a specific project--maybe emphasizing the methods of your sub-discipline--rather than overly general advice.
- Who are you? (name, stage in program, anything else you think is relevant)
- What group are you in?
- Research project (preferably one of your first that you led and one that you carried through to some later stage, e.g. publication). It would be great to emphasize things that are unique to the working style of your group or discipline
- Briefly what is the technical problem?
- How did you decide to work on it? (advisor, paper reading, evolution from prior project)
- What did you do to get started?
- How did you plan out your project? (no plan, decided on the paper from the start, etc.)
- Work style of your group/discipline? (how are projects split up? Do you work alone? How do you put things together)
- Is there an "average" day of work? What is it?
- Is there a cycle? (e.g. code something, run simulations, check data, code something else, etc.)
- Any setbacks to your project? How did you approach them?
- Finishing a project
- How did you know you were done?
- Are there metrics of success in your field? How do you convey success? (e.g. simulation, user studies, proofs, etc.)
- What are the targets in your discipline for publishing (conferences? which ones? etc.)
- Writing papers.
- Who writes?
- What was the process of writing of like?
- Did it get in the first time? If not, what did you have to do to make it work?
- Authorship order
- How do you roll this into the next project? (or is it a one-off)
- Lessons
- Most important lessons
- Any strategies you would suggest for dealing with any of the above?
- What would you have done differently
- Advice to someone going into your sub-discipline (i.e. what would you tell someone going into architecture?)
- Other Stuff
Last updated: Jan. 3, 2007