Thursday, December 30, 2010
I'm pretty bad at answering questions on the spot unless I already know the answer (in which case I am practically no longer conscious of the good things I'm saying). I recently asked for some advice on how to get better at answering questions on the spot, particularly in situations like technical interviews, oral exams and thesis defences. The following list is a compilation of suggestions from friends on Twitter:
- Think about the questions you will be asked and research the in-between knowledge as well. Think about the big picture and interconnections between topics.
- Practice, practice, practice. Particularly practice answering the questions in various ways.
- Since inexperience might make anticipating the questions difficult, try to get your lab mates and supervisor to help. Weekly paper presentations are a good venue; you can practice answering questions on the spot and get critiqued on it.
- Toastmasters isn't just about oral skills (as in presenting well). I just learned it can help you with answering questions on the spot, too!
- Joining an improv group would give you lots of practice of thinking on your feet.
- Before speaking, visualize a list of things you want to say, then imagine yourself checking each item off as you speak.
- When appropriate, think through your answer out loud. Often those asking are interested in your way of thinking as much as your final answer. Don't be afraid to pause while you think, and try to say things that makes them nod.
- During a formal presentation, leave some content out so you know your audience will ask about it rather than unexpected aspects. Create some slides at the end to use when the questions come up.
- Brush up and be able to use terminology to sound like an expert.
- Answer with multiple options for an answer and explain why each could be correct, and conclude with "but it's a difficult problem."
- Link topic to a classic problem in a different field to demonstrate insight.
- Never say "I don't know" right away; instead, rephrase the question until you are sure what they are asking.
My next opportunity to use this advice will be my thesis proposal defence, and I am definitely glad to have such a great list!
(Huge thanks to everyone who shared in the conversation: @petitegeek, @bukephalas, @catehstn, @elcera, @anitaborg_org, @rmgard, @tsienkiewicz, @ioanauoft, @PSchammy)
Tuesday, December 21, 2010
I remember a student telling me the other week that she thought writing stories for games was easy, and wondered if there were jobs doing that. I had been giving a presentation with a professor from Carleton to high school students, and my part was all about connecting your passion to computer science. I've been thinking about that comment, and considering the fact that it may seem easy to come up with a general story, but to make it truly interactive is another thing altogether.
Mini Book I: Uncovered by B_Zedan
Most stories in games are written as a 'string of pearls.' The main structure of the story is fairly linear, but each pearl allows the player to solve puzzles, explore, and generally interact before moving on to the next chunk of the story. There are sometimes branches, but they often come back to the same junction, or aren't overly complex if they stay diverged. After all, as pointed out in this fun video about storytelling in games, designers would have an awful lot of content to create for a story with many different paths!
Despite this common form of narrative, I think games have found some interesting ways to tell their stories that might not be the same in printed word or on film. For example, I've been playing Bioshock with my husband and really enjoy its storytelling mechanisms. The game itself is fairly linear, but the insight into the world of Rapture is revealed slowly through recorded audio diaries scattered throughout. The voice acting is really well done, and getting just small tidbits of how the city fell from the mouths everyday residents is fascinating. Without cut scenes, the emotional accounts of events that have already happened or are currently happening at the time of recording allow you to use your imagination. I quickly found myself getting excited every time I saw a tape recorder lying around, ready for the taking.
As game design progresses, I think we'll start to see new twists on storytelling. (I want to say "just like we saw in film" but since I don't really know the history, I can't know if this is the case - perhaps some film buffs can enlighten me.) One of the ideas I had was a take on the "see the ending first" technique movies and TV shows often use. You would begin playing the game and making choices until suddenly you realize you just played the end. The traditional "x years earlier..." would appear on screen, and you'd start playing from the beginning. The twist would be, however, that how you played at the end would very blatantly affect how the rest of the game progresses. As a player you'd be thinking, "Oh no! Why did I do that?!" but feel helpless to change it. I haven't decided what sort of scenario this would fit well with, but I feel like it could explore some of the darker aspects of human nature since you aren't just watching how a particular event ends up happening - you see how your own actions end up being taken.
Have you seen any unusual narratives in games? Have any interesting ideas? I'd love to heard about them, so please do leave a comment!
Thursday, December 16, 2010
I did my oral defence for my comprehensive exam this morning and wanted to share what I learned, since it might help others. The details aren't important, but suffice it to say I got a conditional pass - I just need to do an implementation for my major topic.
The main thing that I wanted to express was the fact that I seemed to have a different idea of what the comprehensives were for than some of the committee members. This is by no means anyone's fault, but being aware of it might help you if your exams work in a similar way. I wrote in my previous post about the exams:
How these are run seems to differ school to school, and even more between disciplines. For our School of Computer Science, we have to choose three topics - one major and two minor - and know these topics at a fourth year undergraduate level. Then we have a two or three hour written exam on each of them, followed by a one hour oral once they are all graded. The oral is usually used to ask the student questions on areas they didn't do as well on in the written portion, making it a second chance of sorts.It seems that some expected more depth of knowledge than the broad fourth-year undergrad level. They wanted me to interconnect ideas from the books and go beyond them to draw from other knowledge. To be honest, I didn't clue into this until it was too late. I was thinking in a very structured undergrad exam kind of way, where you answer the question and that's that.
Could I have gone deeper if I had realized I needed to? Perhaps for some questions, but to be honest, I didn't prepare that way and crammed all my studying for the comps into two months, so quite possibly not. I'm also not very good at doing that on the spot - I tend to need to think about something on my own first. I always thought I was good at seeing the big picture and making connections, but maybe I need to rethink my ability to do this and find new ways of digging deeper. (What are your strategies for achieving this level of understanding?)
My advice for anyone who has yet to do their comps is to determine exactly what's expected, and maybe even confirm your impression with all of your committee members before deciding how long you want to spend preparing. That way, if you are expected to have a deeper knowledge, you can leave time to practice with implementations, thinking about connections, and reflecting.
Tuesday, December 14, 2010
I remember seeing a non-zero amount of grumbling last year when acceptance notifications for CHI came out. In particular, those who were rejected listed all kinds of reasons why the process was broken. Well, I got to join the ranks of the rejected when I got my notice the other day, but contrary to the popular reaction, I'm actually not unhappy about it.
Note: That's not to say there's nothing wrong with the process. I'm just too new to know about it. ;)
Dora looking sad by [ jon ]
You see, after we got our first reviews, I already knew we weren't going to be accepted. I wasn't even going to bother with a rebuttal. The reason was that I believed what the reviewers were saying at face value, and just figured I didn't know enough about the field or something. I figured I'd have some work ahead of me to fix it up.
One of the co-authors was more of a CHI veteran than me and knew how to interpret the reviews. Turns out that one of the problems was that we unknowingly chose an inappropriate committee and paper type, so the type of people looking at the paper were really not what we were expecting. It kind of went downhill from there. Luckily this co-author said we should indeed do a rebuttal, not because we believed it would change our chances of getting in, but because it would be a useful way to better understand what the reviewers were saying and see where to go from there.
So we did the rebuttal, and I indeed found it incredibly useful. The most valuable thing I learned was that the content wasn't necessarily even the issue - as I said, the bigger issue seemed to be the lens the reviewers were using to look at it. The resulting confidence in my own work makes me feel good about submitting an edited paper to another conference. Better still, an alt.CHI idea we'd been toying with became more clear after the rebuttal. So really, it was a double-win.
I know it's really easy to have anger be your first reaction to a rejection, or perhaps something else negative - but my advice is to try really hard to see the positive side of it. If nothing else, you will hopefully have some feedback to help make your paper better, so when it eventually does get published, citations will be more likely.
Wednesday, December 8, 2010
This week I've been very busy with my written comprehensive exams. These exams are one of the last PhD requirements I have to worry about before the thesis proposal defence. After this, I don't think I'll ever have to write an exam again (certainly not as a student, anyway).
Day 29: Studies by -Snugg-
How these are run seems to differ school to school, and even more between disciplines. For our School of Computer Science, we have to choose three topics - one major and two minor - and know these topics at a fourth year undergraduate level. Then we have a two or three hour written exam on each of them, followed by a one hour oral once they are all graded. The oral is usually used to ask the student questions on areas they didn't do as well on in the written portion, making it a second chance of sorts.
My topics are human-computer interaction, computer vision, and computer graphics. I chose graphics as my major area even though it's the area I know the least about - I figured I might as well take the opportunity to force myself to learn it! All of these topics should be handy in my research area of educational games and augmented reality.
These exams are a little different than exams in regular courses. It's much easier to prepare for an exam based on lectures you've attended because you get a good sense of what the key information is during class. For the comprehensives (or comps for short), I have to know an entire textbook or two, and guess what's important myself. This takes a lot more work, but even the process of deciding what's important helps you understand the material better, so it's not all bad.
Here's the process I've been following to prepare. I've only had one exam so far, but it went well, so it seems to be a good strategy. The two minor topic exams are open book, and the graphics one is closed book with one cheat sheet allowed.
- As I read through the textbook, I make notes on plain white sheets of paper in a binder.
- I use colourful pens to write my headings so I will be able to skim them quickly and easily.
- I periodically add page numbers to the side to make looking up more detail as easy as possible.
- To make the graphics cheat sheet, I am going through my notes and picking out the most important things to remember. During the first pass, I am not worrying about the page limit.
- I'm using LaTeX to type out my cheat sheet since there is a lot of math (especially matrices) to capture.
- Once the cheat sheet is done, I will see how long it is, and decide what information can be dropped. This will be partially based on what I think I can remember on my own.
- I'm planning on having a little "teaching session" with my husband tonight or tomorrow where I will try to explain as many of the basics to him as possible. He's done a graphics course before but doesn't remember much, making him a good candidate for this activity.