Monthly Archives: February 2014

The Art of Pitching

Did you know that it takes no more than 7 seconds before people makes up their mind about someone after meeting them?

A pitch can be a crucial tool in convincing people that you’re worth talking to. A good pitch can make the difference between getting funding for your project or not. A fantastic pitch can give you the job you’ve always been dreaming about.

What would you do if you had a minute to tell Bill Gates about your idea?

The Art of Pitching

At this week’s Wednesday talk Ramsey spoke about how to give a pitch.

A pitch consists of three elements; the hook, the power of three and wrap up. If conveyed correctly, they will together draw the attention of the listener, make the listener interested and ideally change the listeners opinion about something.

The hook

The hook is the most important part of your talk. Remember, you only have 7 seconds to grab someones attention, so it’s crucial that your first two sentences are clear and concise. Further, you want the listener to be amazed or interested straight away. The hook can be one of the following:

  • Surprising statistic – a large number can often have an impressive effect. Did you know  that 100 hours of video are uploaded to YouTube every minute?
  • Fact – According to recent surveys, Facebook is the most engaging website on the Internet.
  • Bold statement – My social network will change the way we communicate with each other.

The power of three

After you’ve got the attention of the listener it’s time to convey your ideas. The trick here is to do it in exactly three strong statements (1-2 is often not convincing enough and 4-5 bores the listener).

Steve Jobs applying the rule of three during the presentation of the iPhone

Steve Jobs applying the rule of three during the presentation of the iPhone

When Steve Jobs introduced the iPhone he explained how:

  1. The iPhone had all the entertaining features of the iPod
  2. The iPhone was a “smart” phone
  3. The iPhone was great a internet communication tool

People can only remember three arguments in their head, so using more than that will not make your pitch more convincing.

Wrap up

At this point you should have got the listener really interested and it’s time to finish your pitch. There are three common ways to do this:

  • Call to action – you want the user to do something, e.g. “Sign up today!”
  • Link to hook – remind the listener why what you just said is important
  • Leading question – make the user even more interested, e.g. “What do you do to protect your website from hackers?”

Trying it out

After Ramsey’s talk we got the opportunity to try to make a pitch. We were split into three groups and got 15 minutes to prepare and plan it. A person from each group was then chosen to perform the pitch in front of everyone.

Katie was first to perform a pitch for (a social network started by Jake, Jeppe and Sam). She started the hook by asking the audience “How many in here have joined Facebook groups such as ‘Overheard in Cambridge’?” – (most of the audience raises their hands) – “The reason why you and 13.000 other students have, is that nearby content is often the funniest and most relevant”. She then gave three reasons why Localgag can do a better job than Facebook and finished by encouraging everyone to join the site.

Why Queens’ college is the best

Did you know that Queens’ graduates have made over £400 million within the last year? Radu started his group’s pitch with this impressive fact and then continued to explain why Queens’ is a great place to be in three short statements. He then wrapped up by telling everyone to follow the Queens’ Computer Science blog.

Why you should do a part III (Master’s degree)

Sid was doing the last pitch of the evening trying to convince the audience to do part III of the Computer Science degree. His three convincing points were:

  1. The Master degree is easier because you have less lectures
  2. The Master degree is more fun because you study more interesting topics
  3. The Master degree is exciting because you get closer to the real researchers (including exciting descriptions about one of the lecture’s sword collections!)

After the pitches we went to the Buttery for a Computer Science formal dinner.

Part 1B Group Projects

Amidst the heap (no pun intended?) of theoretical courses and pedantic worksets, there is no thought more pleasing to a Cambridge CompSci than that of being let loose into the real world to develop games and applications, all the while getting actual class credit for it. Such is the purpose of the second year (1B) group projects. However, as we were informed this week – group projects are also roller-coaster rides of happiness and debugging – often lessons in team-work, crisis management and effective leadership.

Every second year student at Cambridge is assigned to a group (of five or six students) with an industrial mentor. Each group must then spend the term developing a functional application based on their specific project brief (and consequently present it with all the fanfare of PowerPoint and WordArt).

Presented below are short summaries of the various projects Queens’ students undertook this year. Each description is followed by their learnings over the course of the term and a quick piece of advice for future CompScis.

1. Jake

Jake’s team was handed project “Sound Garden”. Their task was to automatically generate “pleasant” music based on the movement of people inside a botanical garden. This music was to follow certain rules decided by the path people followed and be implemented using “regular grammars”. If you find yourself asking the question “What do regular languages have to do with music?” – congratulations, you share at least one thing in common with Jake.


Eventually, the “regular grammar” part of the project was removed so as to allow a greater focus on user-experience. They’re now trying to use low energy Bluetooth sensors and a swanky Android app to calculate proximity to various points in the garden (thus tracking the path a user takes) and generating funky music.


– Focus on pitching to the client – tell a story

– User experience is the key to a successful application

2. Sam and Eduard

This team was to implement the “Transport Game”. In a city like Cambridge, we’re increasingly faced with problems of traffic and pollution, calling for the implementation of a “congestion” charge/tax to motivate citizens to use public transport more and their cars less.

However, what is the actual cost of such a move on my daily journey from Queens’ to the Computer Lab (if I could drive anything more than a bicycle, that is)?

Screen Shot 2014-02-24 at 12.02.56 am

We thus have the idea of a transport game/application. A user can simply open an interactive map and plot his or her daily route. You can then save/edit/delete routes and estimate a total running cost for the journey – fuel, congestion charges, time etc. One can then compare this to the cost of using public transport and voila, you can find the most cost effective way home.

All of this, of course, requires a great front-end (think Google Maps plus displaying custom information on traffic, routes etc) and a very efficient back-end (calculating optimal routes, costs, dealing with loads of requests).

We thus have:


– Split the team so that the back-end and front-end implementations can carry on (almost) in parallel while each solve their own technical/logistical problems.

– If you have expensive computations (routes), break your problem down; for example, they decided to store common travel routes by diving Cambridge into zones.

3. Andi

Some projects seem straightforward at first glance but soon present a whole load of difficulties – Andi’s is one of these.

His project involved a “Recipe Curator” – simply put, as a user, I can upload, download, find, read or edit recipes. “Ha, Easy!”, you say? Well, Andi decided to do all of this along with a “Suggested Recipes” feature. Essentially, the user could type out things like “I want a dish with eggs that cooks in 30 minutes” and the website should immediately pop up the hundred best omelets recipes it finds.

This uses a large amount of NLP (natural language processing) – a really cool branch of Computer Science.

What else did Andi Learn?

Many, Many Lessons

– Andi warns that every member of a team has different sets of skills – learn to use each member effectively. That may include changing your language of choice to include all teammates, or allowing some to do more of the presentation work (very important, mind you) and others to code more.

– Be prepared for the worst; sometimes people have to stop work because of personal emergencies – learn to stay calm and deal with it.

– In the words of Andi “A person who doesn’t work is not one who doesn’t want to work”.

4. Mistral and Jeppe

We now have our final team – dealing with “Abandonment Prediction”. Jeppe and Mistral were faced with the uber-cool task of analysing users on an e-commerce site and determining the probability of a particular user actually buying something. If they were want to exit, this algorithm should be able to predict it, allowing the site to display all sorts of discounts and offers.

But how do you write this kind of oracle?

Well, Jeppe and Mistral decided to build probabilities using historic site data – i.e. given the current path of the user (eg. homepage -> Justin Bieber CD -> Advertisement), find the most similar (“closest”) path from all your data and use that result as the predicted result in this case.

But that again leads us to the question of measuring distances between paths. Their idea was to represent each path in their data by a string of characters (eg. I for index page, P for product) and then compare that to the string of the current path. They further improved this by using weighted averages, caching results etc.

What does all this mean?

Loads of Lessons

– “Good architecture saves you time” – Mistral (who nonetheless doesn’t seem to believe in this himself, using Ruby for everything) soon realized that an SQL database is not fast enough and decided to load the files directly into the Java Servlet.

– Generating a probability makes for great Math but horrible user-experience; you need to pull this math into great JQuery styled windows for the demos/presentations.

– Further Java practicals are useful!

– Sockets are hugely problematic to work with

– Make sure your algorithm works well for on different data sets

Jeppe ended his presentation by boldly claiming that his algorithm predicted correctly in 98 percent of all cases (what he failed to mention, of course, is that 97% of users abandon shopping in the first place).

The coding contest

In our most recent Wednesday evening session, James ran a 1 hour problem solving challenge which the 1st-3rd years tackled in teams of 3. The language of choice was Java, and the goal was to get a flavour for the types of questions sometimes used in job interviews for coding positions.

You can check out the questions here:   challenge

Be warned though: these are pretty tough, and only a few teams found elegant solutions to any of the problems. A copy of the slides outlining some solutions is here: solutions. A full solution to the “Knights” problem is here, but obviously this is far more complicated than anything you would encounter in most interviews.

The winning team amassed a whopping 93 points (out of 120), claiming the grand prize of 3 creme eggs per team member.

Dr Rice was less fortunate: his solution to question 1 earned a commendable 18 points, but in a bizarre turn of events his second solution was given -18 points, leaving his tally at 0 for the evening. Better luck next time.

Singleton design pattern vs dependency injection

I was chatting to the first years today about design patterns in the Object-Oriented Programming course. One of the thing I mentioned was how that the standard Java Singleton pattern is often not a nice solution because it gets in the way of testing.

Dependency injection is an alternative strategy which is motivated nicely in the Google Guice project.

There is also a nice tech talk on this and design for test by Miško Hevery (see his blog on testing):

Learning a software development process with Lego

What is the best way of learning how to develop software in a limited amount of time? If you answered “duh, developing software,” then you would be wrong. In Queens’ we would like to add more fun and creativity into learning so, we held an extended Wednesday Computer Science meeting playing with Legos and eating cookies to learn a form of Agile software development methodology called Scrum.

Our evening started with Dr Stephen Cummins’ talk on what Scrum is. Briefly, it is an incremental development model that leads to production of high quality software with small development cycles. It embraces Agile manifesto and puts special emphasis on “individuals and interactions over processes and tools” motto. After the introduction we tried to simulate the development method we had just heard about with a special task, building Lego campus of the future!

I am sure you can imagine the enthusiasm we had to play with Legos at that very moment. Sadly, I was given the role of the client and the rest were divided into 4 groups that I contract my work to. Each group appointed a member as their scrum master, who is responsible for facilitating communication within and outside the group. This involves communicating with the client, facilitating decisions within the group to what to achieve in the given development cycle, fetching Legos, etc. After groups are formed we went into the negotiation phase, where each group give propositions on what they think should be in the future campus and how much time they think it would take. In Scrum, collection of those ideas is called the product backlog. My job was to prioritize these proposals and tell what I am willing to pay for that particular item in cookies. I was a bit of a self-indulgent client I guess given that I offered 15 cookies for a statue of myself. Other buildings I found important include a local Starbucks, Quidditch stadium, town hall, student bar, pizza delivery drone, Bitcoin bank and a super computer.

After the negotiation was over, each team picked items that they committed to finish in a sprint and other items they wanted to work on over several sprints as a bonus. Then the clock started ticking for the groups! In three minutes they managed to come up with half finished Lego constructions. One problem was that none of them thought of asking the client what they would want to see, which is the main principle behind Scrum. The process went on for four more sprints and the competition between the groups was furious despite working in the same imaginary company. Over sprints many projects were rejected and others rewarded with cookies. In each sprint they tried to incorporate my opinions into their design as they realised that was the key to cookies.

Overall it was a great experienced full of cookies, Legos and of course the company of fellow computer scientists. We did not only hear what Scrum was about but were also able to experience and internalize it. As a personal remark, I can already see how it affects my interaction with the client in my group project as I try to ask them what they want and how they want it as much as I can rather then going and doing what I think is right.

Here are some photos from the event,

Busy group

One of the teams working on a garden.

One of the teams working on a garden.

A happy client!

A happy client!

My statue worth of 15 cookies!

My statue worth of 15 cookies!