A while ago I had been co-lecturing a small group of OI students with Richard. I was impressed how he could just take over any talk on anything, and he said:
A professor is someone who can talk on any topic for 90 minutes.
Well, although I have no idea if I want to (or can) become a professor, talking skill is definitely something useful to learn, as I increasingly recognize its importance.
Recently, I had the opportunity to pitch my works to quite a few people (well, that’s actually a lot of people conditioning on that I am so introvert and most of my interactions are limited within a few people). So I decide to write down some experiment notes for future reference.
After some reflective thinking, I categorized my experience as following:
- Talking with technical engineers in the same field.
- Talking with technical engineers.
- Talking with people who do not do engineering themselves.
Interestingly, my experience is that talking to people in the second category is the hardest.
Talking with people who do not do engineering
A while ago I talked to two startup founders who used to do engineering, but have since transitioned to management roles. It seems like they are most interested in the product side of the story, i.e., the impact of my work on the end product and the end users. They are also interested in the high level technical ideas, but they are happy to overlook any technical detail that they cannot immediately understand.
So it seems to me the important things for such talks is to highlight the motivation and the end results, i.e., convince the audience that my stuffs are practically useful. The high level “how it works” explanation more serves as a method to clear their doubts: they want just enough technical ideas for them to perceive the work and the results as “reasonable”, but not any more detailed than that.
There is one interesting failure to note. During one of the talks, I mentioned my dynamic language JIT constructor idea, and get asked: “The most dominant dynamic language is Javascript and is already well-optimized. Every other language is decading in the market. Why do you want to optimize for dying languages?” I apparently didn’t anticipate this question, and I have never paid attention to the market occupation rate of the langauges. So I had to go hand-waving and say that there are still many existing use cases, and it’s unlikely that they will die out any soon. If I had researched a bit about the market occupation rate, I would have known that his argument on the language market is simply incorrect and produced a better answer.
So another lesson is that since their focuses and views are different from technical engineers, they may ask unexpected questions. But I don’t see a good solution to handle such situations in general.
Talking with technical engineers in the same field
It seems to me these talks are the only cases that I should really elaborate what I did. So probably there’s not much strategy here: all I should do is to introduce the motivation and the results, then elaborate my idea as clearly as possible, and take feedback.
One thing that surprised me is that during a presentation to Google Dart team, a slide containing the assembly my compiler generated attracted a lot of attention. They are actually looking into the assembly to get a better idea on what I did. Not sure how general it is, but it seems like I might have underestimated how much technical detail the audience is willing to dive into.
Talking with technical engineers outside the field
This is where most of the failures come from. If I were to summarize, I feel the main reason is that they want to understand how my stuff precisely works from end to end, but the background differences make explanation difficult and confusion easy.
The biggest failure was in one job interview in which I tried to explain to the interviewer some data structure research I did. I tried to introduce my algorithm by first explaining how x-fast trie (which my algorithm is based on) works. The outcome is clear: the interviewer was completely confused and asked more and more questions, and I didn’t even get into the novel things I did before time run out.
A few smaller failures also happened during the other interviews for that job. The situations were pretty similar. The interviewer gets interested at some particular detail of how my stuffs work, I explained but only to make them confused, and I wasn’t able to make them understand before time runs out. I was also a bit skeptical on how much they really understood what I tried to convey. It’s likely that they are confused much earlier than they speak out that they couldn’t understand something.
But unlike the people doing management, engineers won’t be satisfied by only knowing the motivation and the results (this is why such failures only happen when talking to engineers). So it seems to me the lessons are the following:
- Be very detailed in terms of the problem and the assumptions, i.e., make it very clear on what I have in hand, what I am trying to solve and what I am assuming. A seemingly-obvious assumption could be not obvious at all for someone with a different background.
- But, stay away from all technical details. Explain everything in high level. It’s probably even worth to explain everything by analogy. If they ask about technical details, probably the best answer is to just say it’s going to take too long to explain, and try to answer the question using an analogue.
- Get a good estimation on how much time is needed to explain a certain thing in a certain level of detail. For example, it might take 60 minutes to make a normal engineer understand x-fast trie, so doing this in an interview is doomed to be disastrous.
A few other failures
Once I tried to convince Richard that a Halide-like approach might be helpful to implement some of his crazy algorithms. It didn’t end up well because I didn’t know Halide that well and I had to think while talking, which turns out to be amazingly hard. In general, I feel it very hard to think about any logical stuffs while talking, so probably it’s best to avoid that.
Another stupid failure happened in a poster session. I underestimated the weather and trembled in the wind as a result. The lesson is clear.
Summary
It seems that the common parts above is about the right level of technical details. It is beneficial to present in detail when the audience are people in the same field. However, it seems like in other cases, getting into technical detail is a major source of failures, and should be avoided as much as possible. However, obviously, this is only the conclusion drawn from a few experiences.