Blog

Episode 4: David Lieb of Bump

Guest: David Lieb, CEO and co-founder of Bump
Producer/host: Arman Suleimenov
Mountain View, CA
December 8, 2011

Bump is one of the most popular free iOS apps of all time (more than 65 million downloads, 7th in US, 3rd in Japan). Bump is the mobile application which lets two smartphones to share contact information / schedules / photos / app recommendations / etc. by simply bumping phones together. After the recent partnership with PayPal, you now can exchange money using Bump. Bump is funded by Y Combinator, Sequoia Capital, Andreessen Horowitz, SV Angel, Ron Conway, Ram Shriram and the others.

Questions addressed in this interview:

• What is Bump?
• The origins of the idea for Bump
• How to start a startup: 2 ways startups are formed
• YCombinator experience: launching before applying
• Make something people want
• How did Bump look like on the YC demo day?
• Challenges of the network effects product: from the risk to the asset
• Thoughts on NFC (Near Field Communication)
• Closest pair problem from Computational Geometry
• Retention rate and usage across different features
• Countries where Bump is big: US, UK, Japan
• Reasons why Bump is the 3rd most downloaded mobile app of all time in Japan
• Stats: the total number of downloads, the number of active users in the last 3 days
• The key lesson learned as the first time entrepreneur
• Technology stack: Objective-C, Java; C and Python on cloud servers
• Hiring at Bump
• Applications built on top of Bump API
• 5 whys: underneath any technical problem lies the human problem
• Viral engine growth at Bump
• Blogs and books: Paul Graham’s essays, TechCrunch, Ben Horowitz’s blog; ‘The Facebook Effect’, ‘Emotional Intelligence’, ‘Steve Jobs’
• The vision for Bump

Click here to see the other episodes of Princeton Startup TV.

Episode 3: Adam Goldstein of Hipmunk

Guest: Adam Goldstein, CEO and co-founder of Hipmunk
Host: Arman Suleimenov
Date: December 8, 2011
Location: San Francisco, CA
Princeton Entrepreneurship Club

Hipmunk is the flight and hotel search engine which presents flight results as the visual timeline, sorts flights by agony, searches for hotels in the areas with many points of interests, and provides Amtrak train routes among other things. Time magazine named Hipmunk as one of the 50 best websites of 2011. The founders are Adam Goldstein and Steve Huffman (co-founder of reddit.com). Investors include SV Angel, Paul Buchheit (creator of Gmail), Matt Mullenweg (founder of WordPress) and Ashton Kutcher.

Questions discussed:

• How / when did you come up with an idea for Hipmunk?
• What was the process when coming up with the name?
• YCombinator experience
• ITA as the source content for search
• Is the main power of Hipmunk an outstanding user interface?
• Gantt charts for flights
• Hipmunk’s technology stack
• Why companies like Southwest don’t provide their fares to the flight search sites?
• Hipmunk as the multitransport search engine
• Hotel search around points of interest
• What Hipmunk was like when launched?
• What are the plans for improving the service?
• How does feature prioritization work at the Hipmunk team?
• Key lessons learned
• Favorite blogs and books
• Patents as the defensive mechanism from big companies which crush startups
• Any plans to own the booking part of the equation?
• What’s your vision for travel planning space and Hipmunk specifically?

Click here to see the other episodes of Princeton Startup TV.

Episode 2: Vinicius Vacanti of Yipit

Guest of the show: Vinicius Vacanti, CEO and co-founder of Yipit
Host: Arman Suleimenov
Date: December 2, 2011
Location: New York City, NY
TigerTreks / Princeton Entrepreneurship Club

The topics discussed:
- Yipit – daily deals aggregator
- 8 projects before stumbling upon the idea for Yipit: unhub.com, 140it.com
- The Lean Startup methodology by Steve Blank, Eric Ries
- 3 blogs to read: ‘Both sides of the table’ (Mark Suster), ‘AVC.com’ (Fred Wilson), ‘Techmeme.com’
- Actionable metrics
- The difference of yipit.com with 8coupons.com
- On the danger of new ideas: uninformed optimism, informed pessimism, crisis of meaning followed by crash & burn vs informed optimism
- Threewords.me by Mark Bao
- From the project to the company: what happened before an idea and now?
- How does Yipit make money?
- The vision for Yipit and the local commerce in general
- The constant iteration
- Web frameworks. What’s better: Python + Django or Ruby on Rails?
- The challenges associated with aggregating deals from 800 different sites

P/S: Vin has a great blog – ‘How to Make It as a First-Time Entrepreneur‘. I have been reading it for about a year, highly recommended!

Click here to see the other episodes of Princeton Startup TV.

The future of education

(originally posted on http://www.dailyprincetonian.com/)

For centuries, the university system has flourished as the primary means by which knowledge is transmitted from one generation to the next. The university’s advantage over alternatives has been its incomparable access to resources, not only in its libraries of texts and artifacts, but also in its collection of scholars, whose method of instruction has proved over the years superior to self-tutelage by the bookshelf.

But the rise of the Internet threatens such advantages as distribution of the world’s information approaches a liminal point of democratization.

Let there be no doubt: We are experiencing a revolution in the way that society transmits knowledge, and it is occurring at the margins of our education system — far, far away from ivory towers and college greens. And yet, despite all the reasons to prepare for coming winds of change, Princeton and other institutions face an inevitable paradigm shift with stunning indifference.

Paradigm, meet Sebastian Thrun. Until recently, Thrun was a tenured professor at Stanford — that is until Thrun realized that he could teach well beyond the scale of a classroom by moving his courses online. After 160,000 students enrolled in his digital version of Stanford’s CS 221: Introduction to Artificial Intelligence, Thrun decided to leave his tenured post at Stanford to found a new online university called Udacity. With good reason, Thrun says he believes that the platform of the web has become more powerful and more effective than any podium that Stanford could provide. The example Thrun sets is clear: Instructors with stature — even those without it — no longer need universities as a means of distribution. The web provides all that is necessary to educate at scale.

Imagine what would happen if even some of the nation’s top educators in the sciences — the subjective nature of the liberal arts do not seem at all scalable — should turn away from their classrooms and move to an online platform as Thrun has done. A student in the sciences could conceivably achieve an education of similar quality to one offered by Princeton, Stanford and MIT for a fraction of the cost.

So in an evolving landscape where traditional brick-and-mortar institutions are no longer unique for distributing technical education universities will have to figure out how to get better or risk some varying degree of irrelevance. The truth is the quality of instruction hasn’t really changed over the past 50 years. There have been only negligible improvements because the organization of information and mode in which it is transmitted has barely changed.

So I’m calling for an overhaul for the University’s software solutions (which is the modern mode of organizing information).

Let’s start by replacing Blackboard with something less ancient and clumsy. I suggest CourseKit, an elegant course management solution that can facilitate class discussions and store class resources seamlessly.

But we have to think bigger than just improving communication inside of classes.

The revolution at the margins underscores what scales and what doesn’t. Information transmission scales. Community doesn’t. No online campus seems capable of building a dedicated and vibrant community of scholars. That is our greatest strength, and our embrace of technology will be best implemented when we leverage it. In that regard, I suggest the creation of a collective project that organizes in one place the intellectual output of this University.

Imagine one destination where every Princetonian’s research was accessible. Imagine a news feed for the published work of Princetonians. Imagine every syllabus, every document of lecture notes for all of our classes accessible in one place, with links to their resources available to everyone in the University community. And beyond that, a place where students can publish class work that is deemed exemplary. It would be an intranet for our collective scholarly products.

As a senior, I’m tempted by the deflating thoughts that 32 classes weren’t enough — the bitter regret of an academic career in its twilight. A system like the one I’ve described would have given me — and could continue to do so for those who have graduated — Wikipedia-type access to the University’s resources despite the practical constraints of course registration.

I bemoan the state of technology in the University not because I want Princeton or other institutions to become the democratic platform that Thrun is making on Udacity. Rather, I’m frustrated by the sorry state of our information resources — poorly organized and face-palmingly constricted. The organization of information matters and is crucial, even tautological, to the evolving paradigm of the modern university — one that looks, even from far away, more like Thrun than us.

Princeton Startup TV Episode 1

Princeton Startup TV: Episode 1 with Mick Hagen, founder of Zinch and Undrip

Guest of the show: Mick Hagen
Host: Arman Suleimenov
San Francisco, CA. Nov 4, 2011
From Princeton Entrepreneurship Club

‘Princeton Startups’ is the podcast where we talk about startups and entrepreneurship. Questions discussed in this episode:
- Zinch – LinkedIn for high school students
- What were the initial challenges?
- Early years of the company
- The art of launch
- Joining a startup vs creating one
- Undrip – filtering Twitter / Facebook stream
- Long-term stealth mode approach vs ‘launch as soon as possible’ approach: art.sy, spotify
- The Lean Startup: actionable metrics, Minimum Viable Product, Build-Measure-Learn loop, pivot

Click here to see the other episodes of Princeton Startup TV.

Seed Stage Startup Accelerators

Top Seed Stage Tech Accelerators in the US

Y Combinator
TechStars
Dreamit Ventures
500 Startups
Excelerate Labs
LaunchBox
AlphaLab
Capital Factory
Betaspring
Brandery

Top Seed Stage Tech Accelerators in Europe

Seedcamp
StartupBootcamp
Springboard

Comprehensive Lists of Startup Accelerator Programs

List by Robert Shedd that includes global seed-stage startup accelerators, social entrepreneurship accelerators, and university affiliated startup accelerators.

Comprehensive Map of US and Canada Seed Stage Tech Accelerators

Credit: Casey Allen

“These are ONLY accelerators (not incubators*) and ONLY tech. *What’s the difference between an incubator and an accelerator? See http://qr.ae/9cID

What The Colors Mean:

• Yellow = Private: Dominant driver behind the accelerator and its funding is a private group with private funds, almost always self funded by successful ex-entrepreneurs.
• Red = VC/Angel Group
• Purple = University
• Green = Corporate
• Teal = Government
• Blue = Hybrid Approach: A combination of stakeholder groups with pooled resources.”

View U.S. and Canada Seed Stage Tech Accelerators in a larger map

Entrepreneurial Courses Offered at Princeton for Spring 2011

ELE 491: High-Tech Entrepreneurship
EGR 495: Special Topics in Entrepreneurship
COS 333: Advanced Programming Techniques
COS 448: Innovating Across Tech, Biz, & Mkts
ORF 401: Electronic Commerce
ENV 324: Environmental Entrepreneurship
SOC 409: Critical Approaches to Human Computer Interaction

Don’t write on the whiteboard

(originally posted on www.jperla.com/blog/)

I recently interviewed at a major technology company. I won’t mention the name because, honestly, I can’t remember whether I signed an NDA, much less how strong it was.

I did well. Mostly because of luck. I normally step over myself when I interview. I guess I’ve improved over the years. Here are a few tips to ace your own interview.

1. Don’t write on the whiteboard

When I interviewed at Palantir around 5 years ago, I had a lot of trouble with this. Yes, I knew next to nothing about computer science then, but I should have been able to answer many of those questions. For example, Palantir asked me to write an API for a hash table, and I forgot set key and get key, the most basic operations. The alien situation of the whiteboard contributed to my nervousness. I didn’t get an offer from Palantir.

Most people think you have to write on the whiteboard. Steve Yegge recommends that you practice writing code on a whiteboard and even buy and bring your own marker to the interview. That’s pretty extreme and truly conveys the capriciousness of modern-day tech interviewing.

The interviewer started by asking me to code up a simple recursive calculation, using any language I wanted. “I dont like to write on whiteboards,” I said. “It feels unnatural and distracting. I’d prefer to write on paper.” “Okay,” he shrugged.

The interviewers don’t care. Use paper.

2. Bring your own paper and pen

So I asked for some paper and a pen. But there was no paper around, only some post-it notes. My mistake.

You should always have paper and pen anyway to write down ideas. On the subway, in line for movie tickets. Or you can keep a few sheets of paper with your resume and folder you brought to the interview (you did that, right?). Moleskines are excellent notebooks.

Some of the best programmers figure out the high-level overview on paper before they write a single line of new code.

3. Use Python

Even if you are a C++ systems guru. Even if you only know how to use Eclipse to program Java. Learn Python and use it during your interview. Python’s philosophy is very simple and consistent. It’s largely composed of a subset of the ideas in Java and C++. 80% of Python is based around the dictionary (HashMap). It will take you a few days to learn and not much longer to master.

You will waste a lot of time writing string manipulation code and initialization code that you can do in one line of Python. Get to the algorithm.

All I had was a post-it note, a tiny amount of space. So I wrote down the algorithm in Python line-by-line on the post-it note.

4. Write short algorithms, then make them half as long, then make them shorter, then ask an expert how they would make it even shorter

Five minutes later, I had my algorithm. It took up less than a few lines. He looked at it, yea, that looks correct. “Normally people write it in Java and it takes them a while and it takes up a lot more space on the whiteboard. They spend a lot of time manipulating the input string.”

Since my first interview at Palantir, I had done a lot of practice problems.

The highest value problems I know of are on Project Euler. The site posts a sequence of problems of increasing difficulty which you have to solve with increasing efficiency. To become a great hacker, just do those problems in order (in Python!). Then take your solution and do it in half the lines. Now, read more of the Python docs (maybe read about generators and list comprehensions and decorators) and make it even shorter. Finally, look at the solutions posted on the Project Euler site. Stand in awe of the 1-line solutions. Weep in joy over the solutions of the guy who answered the problems using just pen and paper and his brain.

The highest value courses I took are algorithms and advanced algorithms courses. I was lucky enough to study under Robert Tarjan. But I also did every problem in CLRS, the standard (and very well-written) algorithms textbook.

If you do all that, you won’t be nervous at your big interview. You’ll be bored.

5. Write tests on your own code, sometimes

I say sometimes instead of always because, first, it is impossible to test every case. 100% test coverage is a myth. Any non-trivial program is going to have too many edge cases to check, computationally. You need to test the high-value parts. You need to test the parts that you keep breaking.

Finally, as you finish, the interviewer will look at your code and ask you to write tests for it. So, pre-empt him and describe the tests that you would write yourself. Write edge case tests. Run the tests in your mind. Does your algorithm work? Remember, the interviewer will ask you to do this anyway, so just do it yourself and you will be one step ahead and score well.

The highest value book I read which taught me practical programming techniques isProgramming Pearls. It also teaches you the importance of tests and how to write them in a pain-free way. Read this book, it’s very short.

He asked me to write tests for my code, find corner cases. He then asked me 3 other problems. They were Dan Tunkelang type problems. He ran out of problems and there were 15 minutes left. “Normally there’s not enough time to ask more than 1 or 2″, he said. So we just talked about VMs for 15 minutes. He taught me a lot about virtual machines. This brings up lesson 6:

6. Understand what you don’t know, why you don’t know it, have an interest in it

Read random Wikipedia articles. You don’t have to understand it all, just know enough to be able to ask someone who is knowledgeable. Usually, they can teach you a lot from the seed of what you read. But you need that seed, that germ of interest.

This will make your questions good and your conversations interesting. People like to talk about themselves. Always carry some knowledge and some ignorance as fuel for them talk about themselves and teach you. The interviewer will leave with a positive impression of you.

Don’t just read blogs. Read research papers published by successful company. Read Google’s MapReduce, GFS, and BigTable papers. Read Yahoo’s Hadoop and PNUTS papers. Read Amazon’s Dynamo paper. Big companies have big systems, and they will expect at least some familiarity with how they work. These papers are hard. If you have no systems experience, it may take you a day to read through a single one. In the end, you will understand not just how these systems work, but how to think about these systems and design one yourself.

7. Use esoteric tricks you know, teach the interviewer

You’re not supposed to use libraries in these coding exercises. But if you know something cool, just use it. In the worst case, the interviewer will tell you to rewrite it. In the best case, he will be interested and ask more questions about it. You will teach him.

I taught the next interviewer about the memoization decorator in Python. Memoization takes a complicated dynamic programming problem and makes it blazingly fast. He asked me to solve a problem. I wrote an O(N^2) algorithm, then made it O(N) with just one more line of code on my post-it note (still no paper).

I taught him about how I often write a file-backed cached version of @memoized that writes to a file so that I can persist the quick results between runs from the shell. He’s a C++ guy, so I taught him about Python decorators as well.

8. Think how you think, go with it.

Studies on creativity have shown that if you tell people to be more creative, they end up less creative. If you split two painters up and tell them that the most creative person wins a prize, the paintings will be boring or the same. People forced into creativity think in the same way.

So, don’t think outside the box. Just think how you think to the extreme. Go with it.

The third interviewer asked me to design a game API. He wanted a low-level design, but I misunderstood, so I started adding artificial intelligence features that would suggest moves for you to make. I wasn’t sure what he was asking, and I kind of tried to clarify, but then I just went with it. My main interest is AI and machine learning. He was impressed by the originality, and I eventually answered his original questions too. You can usually tell when someone is being genuinely sincere by the manner in which they go out of their way to tell you, versus when they are just mouthing the words. He honestly implored, “it was really great talking to you.”

9. Give reasons for your opinions, not just opinions

I asked the next interviewer how much he liked mobile development and he said he liked it. I was learning iPhone development. I played with Android too, but I told him I found the XML for UI distasteful. He asked, “Why?” I said you always want to put as much as you can into code because it gives you power. For example, you want to create and manage a repetitive UI element in code to avoid repetition. Avoiding repetition is the whole point of good coding.

He said that Android has a solution for the repetition in the form of XML templates or something. “Oh, I didn’t know that,” I said. I thought about it more. “Yea,” I observed, “the solution to the problem of XML, in enterprise, is often more XML.” He chortled.

At a previous interview, a CTO was looking for an employee #1. He was just leaving Google to start a new startup, and he asked me what my thoughts were about Amazon Web Services. I said, “they’re good.”

I didn’t realize that he did not have much experience with them (having been at Google), and wanted some real constructive feedback. I didn’t realize that he was testing to see my experience and familiarity with AWS. More importantly, he was testing my reasoning ability and judgment. I have been running an EC2 instance continuously to run this blog for the past 5 years. It scales well and is very simple. I’ve used nearly every single one of their technologies since they came out. I invest all of my savings in Amazon because I know this technology will net them billions of dollars. I should have said this. Instead, all I said was “they’re good.”

10. Interview the interviewer

The last interviewer asked me some simple questions that reminded me of a harder problem I had in one of the companies I started. So I asked him how he would solve my problem.

I was trying to find the phrases in a document that correspond to scientific terms in order to link them to Wikipedia automatically. The vocabulary is composed of words and sequences of words like “DNA”, “p53ase”, “phospholipid bilayer”, and “congenital determined myoglasia peptide”. Documents are research papers, which can be long. There are a lot of terms (a hundred thousand biological terms, and many more if we include other sciences). How would you find and label all of the phrases in a document efficiently and what is the big-O running time?

He got the O(vocabulary size * document size) algorithm pretty easily, but I told him that there is an O(document size) solution. Can you solve it? Try it out. It’s a fun, practical problem.

I pushed him a little bit but he didn’t get it. I interviewed the interviewer and stumped him (although I’m sure he would get it if he thought about it longer).

11. Mention your projects and passions first

After finishing up all of the problems in 40 minutes, I had 5 minutes left with the last interviewer. I started telling him about my minimalist python web framework and he said, “That’s so interesting, that’s what we should have been talking about instead of going over these questions.”

I got the offer this time, but I would much rather do a PhD instead. I want to learn how to push the boundaries of knowledge, not just apply what I learned in these books.