My Y Combinator Interview

The recent spate of postmortem posts by prospective Y Combinator applicants has got me thinking of my interview experience. In May 2005, my lifelong friend Emmett Shear and I were seniors at Yale. We were working on a website during school called (a domain we purchased for $250, a big investment for us at the time). Our plan for Kiko was to build the world's first AJAX calendar web application, although at the time many of those terms hadn't been coined yet and we just described it as a web calendar with an Outlook style interface. We had big plans for the site: millions of users, possible partnerships with big web mail clients, and a plan to monetize through an advertising system for events (we'd see where you weren't planning anything on your calendar and show you an ad for a concert or movie). I remember that we'd have pipe dream discussions about possibly selling the site to Yahoo, Microsoft or Google eventually, even though we had no idea how that happened in practice.

Six weeks or so before graduation, just when we were wondering what we'd do with the company when we graduated, a friend of Emmett's forwarded an email that had been sent to the CS department list about a new program called the Summer Founders Program started by Paul Graham, Trevor Blackwell, and Robert Morris through a new firm called Y Combinator. This "Y Combinator" was offering to fund your startup company if you applied and were accepted -- all you had to do was move to Boston for the summer. Seemed like a good deal to us!

The application was a list of questions about things you'd built, your backgrounds, your business and what you planned on building (basically what it is today, although no video and no hacker news username requirement). If I recall correctly we sent it in as a txt file attached to our email. Emmett was excited to apply because he knew of Paul Graham through his essays and Robert Morris through the Morris worm, but I had no idea who they were. We answered the questions together with a third cofounder (who dropped out a few days later) that night in the computer lab, and sent it in. Here is our application below (typos were in the version we sent in):


Please list your company's name, url (if any) and a phone number (preferably a cell phone).

Kiko,, XXX-XXX-XXXX (Emmett's cell)


Please list the founders, one per line, with age; year, school, degree, and subject for each degree; slashdot id; email address; and url.  Put unfinished degrees in parens.  List the main contact first. Put asterisks before any who won't come to Cambridge.

Justin Kan; 21; (B.A. Physics & Philosophy, Yale University, 2005);

Emmett Shear; 21; (B.S. Computer Science, Yale University, 2005); 602422;

*Matthew Fong; 22; (B.A. Ethics, Politics and Economics, Yale University, 2005) (B.S. Mathematics, Yale University, 2005);


Tell us in one or two sentences something about each founder that shows he or she is an "animal," in the sense described in How to Start a Startup.

When it was first released, Matt played Warcraft III until he was the number one ranked player on the Eastern ladder.

Emmett only learned to program when he was 16 and picked up a C++ tutorial. He did nothing but program, sleep, and eat for the next 6 days.

Justin once played a 45 minute half of a rugby match before realizing he had a nosebleed from being struck in the face.


Tell us in one or two sentences something about each founder that shows a high level of ability.

Justin is graduating with distinction in Physics and Philosophy.

Emmett graduated from the Transition School at the University of Washington at age 14, which exists to allow students to finish highschool in a single year.

Matt scored a four on the Putnam.


For founders who are hackers: what cool things have you built? (Extra points for urls of demos or screenshots.)

Emmett: A gravity-control device for plants, revolving them slowly on one axis to cancel earth-gravity and quickly on another to simulate desired gravity.

No pictures; was unfortunately destroyed immediately after completion by bored soccer players kicking it.

Justin: Wrote a 3D planetary body motion simulation program with some friends in high school. Another wrote a simple keystroke logging program I used to detect unsolicited use of my personal computer. Coolest thing ever built, however, were a pair of "snow bowls" built with brother: metal bowls attached to snowboard boots that can be used to slide precariously down a snow covered slope. We were trying to invent a new snow sport.


How long have you known one another and how did you meet?

Justin and Emmett met in the second grade and have been friends since. Justin and Matt have been roommates for three years in college.


What is your company going to make?

An AJAX internet calendar app that will allow users to easily organize and coordinate groups.


If your project is software, what OS(es) and language(s) will you use, and why?

Back-end: Linux + Postgre SQL + Java

Interface: Javascript + DHTML


If you've already started working on it, how long have you been working and how many lines of code (if applicable) have you written?

We have been planning the software and business strategy for about five months, and have around 7000 lines of code written thus far.


If you have an online demo, what's the url?  (Big extra points for this.)

This prototype only supports one way data transfer from server to client.




How long will it take before you have a prototype?  A beta?  A version 1 you can charge for?

We hope to have a more complete prototype finished within the next month.

A beta version should be ready sometime during the mid-summer. We plan on releasing version 1 in September.


How will you partition the work this summer; who will work on what?

Emmett is in charge of writing the database and java servlet that handles data transfer to clients. Justin is in charge of writing the majority of the interface.

Matt is responsible for developing the advertising system and doing administrative tasks.


If you already have a business plan, what's the url?  (Don't send us your business plan.  Put it on a server and tell us the url. Ascii text preferred.  Don't password protect it.)


How will you make money?  Who will your customers be, how many are there, and how will they hear about you?

We will have two separate customer bases, users and advertisers. Users will be able to maintain a free calendar and be encouraged to enter user data into a social network info page. Advertisers will then be able to purchase unobtrusive time/context relevent ads that will appear next to user calendars based on keyword matches in the user's data. Advertisements can be drag-and-dropped onto the user calendars as appointments.

Our plan is to initially launch our product at a university (probably Yale), where we will promote it by word-of-mouth and hopefully by getting tie-ins with official sites. It is our intention that users will spread the product virally. We believe that the total market size for electronic planners is quite substantial; the number of regular Microsoft Outlook users was estimated at roughly 35 million, and we believe even more people would be interested in a free internet-accessible calendar.


Will you do price discrimination?

Yes. We plan on implementing an auction system for buying advertising keywords.


Who are your competitors, and who might become competitors?  Who do you fear most?

MSN Calendar (part of hotmail) and Yahoo! Calendar are our most obvious direct competitors. Should Google release a calendar along the lines of Gmail, they would be the competitor we would fear most by far.

Indirectly, we also compete with other media which provide event advertisment.


Who will lose most if you succeed?  (This need not be a competitor; TV networks have been hurt by email.)

Yahoo! and MSN. We forsee a situation analagous to what has happened with internet email: an AJAX product, Gmail, succeeded in quickly capturing a large portion of the market, by providing better features and performance.


Which companies, in order, are most likely to buy you?





What do you know about your business that other companies in it just don't get?

1. Javascript-intensive web applications backed by databases are inherently superior to current server-side solutions, because they can provide a superior user experience.

2. The simplest sign-up procedure is the best sign-up procedure.

3. Social networks have an abundance of data which they should be using to display context relevant advertising. 


What's new about what you're doing?

1. The first javascript-intensive web calendar.

2. The first software calendar with social network features.

3. The first web site to sell drag-and-drop, time-based advertising.


Why would it be hard for someone else to duplicate?

The product, like all social network products, has an inherently sticky user experience and we will have first-mover advantage.

Furthermore, we are applying for a patent on the advertising approach we believe will make the software profitable.


Have you made any discoveries you consider patentable?

As mentioned above, we believe that drag-and-drop advertising is patentable as a business method (or at least a time-based version is).


What might go wrong?  (This is a test of imagination, not confidence.)

Google might crush us like ants by releasing a superior product tomorrow, supported by their vastly superior backend systems.

Alternatively, Google might be ignoring this market because it is not actually a product anyone except us desires to use - though we doubt this is the case.


If you're already incorporated, when were you?  Who are the shareholders and what percent of the company do each own?  If you've had funding, how much, at what valuation(s)?

We aren't yet incorporated, but we formed an LLC in October of 2004. The company is divided into thirds. We have yet to recieve funding.


If you're not incorporated yet, please list the percent of the company you plan to give each founder, and anyone else you plan to give stock to.  (This question is more for you than us.)


If you'll have expenses beyond the living costs of your founders, Internet access, server rental, etc., what will they be?



Describe, in one sentence each, any companies any of you have started before.  If they failed, why?  (We consider failed companies valuable experience too.)


If you could trade a 100% chance of $1 million for a 10% chance of a larger amount, how large would it have to be? Answer for each founder.  (There is no right answer.)

Emmett: Much, much more. $1 million is enough to start my company, right now - which is my top priority.

Justin: $20 million, with sums larger than 100k I am increasingly risk averse.

Matt: It depends; were I to have a project which required a minimum of $9 million, I would take the risk.


If your startup seems at the end of the summer to have a good chance of making you rich, which of the founders would be likely to commit to continue working on it full time over the next couple years?

Emmett and Justin. Matt has signed on with Goldman-Sachs because they are sponsoring his visa to stay in the United States.


Which of the founders would still want to be working for this company in 10 years, if it were successful, and which would rather sell out earlier and do something else?  (Again, no right answer.)

Justin: I want to be doing something interesting and creative. If the online calendar industry is still a changing business world ten years from now, then I would want to be running Kiko.

Emmett: I would rather sell out earlier and be doing something else - I have plans to revolutionize education in the next 20 years, and I'd hate to miss them.

Matt: Sell out. I would like to use the money to start my own venture firm.


Are any of the founders covered by noncompetes or intellectual property agreements that overlap with your project?  Will any be under consulting contracts this summer?



Was any of your code written by someone who is not one of your founders?  If so, how can you safely use it?  (Open source is ok of course.)



Will any of the founders have other jobs, responsibilities, or consulting work this summer?

Matt will be working for Goldman Sachs.


Tell us something surprising or amusing that one of you has discovered, and who discovered it. (The answer need not be remotely related to your project.)

Emmett and Justin won a competition in high school to design an experiment for flight on a NASA shuttle. The experiment was basically to compare the patterns copper ions formed when we ran a current through cupric sulfate on the ground and in microgravity. We discovered lots of things during the process, most notably: the hard part of the project was reducing glare in the camera, Goop (a brand of glue) will hold together anything, and never let a NASA engineer tell you your experiment will break during shuttle take-off, as the most surprising things will hold together. 


What else would you have asked if you were us?

Justin: What is your favorite book?

Emmett: What is your current longest term goal?


We emailed it in, and then went back to work. In the interim, we had a conversation with Matt along the lines of "You are actually taking a full time job and we want to pursue this" and went our separate ways on the best terms. After a few days, we received the following email back from Paul:


From: *****@****.org

Date: 30 Mar 2005 05:00:32 -0000

Subject: Summer Founders Application


Cc: list not shown <recipient>

Thanks for applying to the Summer Founders Program.  We're reading the applications now and should have the first round of decisions in a couple days.

We found the applications fell into three categories: promising, unpromising, and promising people with an unpromising idea.  Your group was in the latter.  We're willing to sit down with groups in this category and work out an idea that might make money, but only if they want to, of course.  So would you please let us know whether you are:

a) determined to pursue your current idea

b) willing to consider modified versions of your idea


c) willing to work on any good idea, even totally unrelated

Please don't take this personally.  It's very common for a group of founders to go through one bad idea before hitting the bullseye on the second try.  We did.  Even Bill Gates and Paul Allen did. (Their first company was called Traf-o-data.  It did not make as much money as Microsoft.)


Paul Graham and Trevor Blackwell


At this point we didn't know what to think. We had spent the last five months working on Kiko, and thought it was a good idea. At the same time, we seemed promising -- alright! We wrote a short response back that said we'd consider modified versions of the idea. A few days later we received this:


---------- Forwarded message ----------

From: Summer Founder <> (Hotmail!!)

Date: Apr 3, 2005 10:23 AM

Subject: SFP time slot



Hi Emmett,

Your assigned time slot to meet with Y Combinator about the Summer Founders Program is 10:30 am on Sunday, April 10. Directions to 135 Garden Street are on our site and there is parking available if you are driving.

At this stage we believe you are technically capable, so we plan to spend the allotted 40 minutes discussing your idea. We don't want you to give a presentation, but please come prepared talk about:

1)      Why your idea is something that people will want

2)      How you will sell it to customers

3)      How you will do this better than your competitors

Please reply to this email to confirm that you plan to come to Cambridge and that the designated time works. Feel free to email me at **** with any other questions that you have. We look forward to seeing you next weekend!



Awesome! We had a chance to pitch. Now, all we had to do was figure out how to get up to Boston in a week. I booked the La Quinta Inn in Somerville since it seemed relatively close on Mapquest (yes, Mapquest. Also, it wasn't close). The next Saturday, Emmett and I took the train up to Boston from New Haven. We were very, very nervous. After we got to the hotel, we stayed up until 3 AM hacking at our demo (we had outlook style appointment dragging working, but wanted to be able to show dragging and advertised event onto your calendar from a sidebar and having everything except for the available times you could place it on blacked out). We finally got it working, then passed out from exhaustion.

The next morning, we realized that the La Quinta Inn was not only in the ghetto, but wasn't anywhere near Y Combinator. Frantic that we'd be late for our 10:30 interview, we grabbed a cab (we were broke college students), and made 135 Garden St with only 5 minutes to spare. We got out of the cab and wondered whether we were in the right place when Jessica came out and greeted us. Because I couldn't really do it justice describing what Y Combinator's original Cambridge office was like, I'll just embed a video of it (it's for sale):



It's been over five years since the interview, and honestly I've forgotten a lot of what happened. Aaron Swartz wrote a summary of his interview that I think is pretty similar to what happened to us. Some things I do remember:

  • We were interviewed by Robert, Paul, Trevor and Jessica. I was pretty intimidated and but Jessica did an amazing job of making us feel at ease.
  • Emmett did most of the talking. To be honest I was pretty shitty programmer at the time (still am!), and felt super ill at ease discussing technology (not any more!).
  • Trevor pressed a lot on whether Javascript was suitable to build 90% of our app in -- Emmett insisted that Gmail was a good example of something you could build if you considered the browser a fat client capable of running complex javascript apps.
  • I think the fact that we had a demo that sort of worked of an Outlook like calendar interface on the web sold us way more than they expected, and at the end of the day was probably the only reason we got in.

I think the interview lasted around the 40 minutes promised. Afterwards, they told us they would call us that night and Jessica showed us out. We walked from Garden St to Harvard Square (about a ten minute walk), and spent the rest of the afternoon walking around Cambridge ostensibly looking for a place we'd like to live (we ended up living in Roxbury, which is horrible). Around 6 PM that night, Emmett and I were in a bookstore in Harvard Square reading comic books and killing time. Emmett went next door to use the bathroom of a restaurant when he got a call on his cell phone. He answered it outside while I blissfully read on, unawares. On the phone, Paul told him: "We'd like to fund you, we'll give you 12k for 4% of your company," and after a short conversation Emmett ran back in the book store to let me know. 

We were ecstatic. I'm not exaggerating when I say we were literally jumping for joy outside the book store. While it might not seem a lot for anyone who has actually started a company before, from our perspective we were college kids from a school with no culture of entrepreneurship who had just received the external validation that our company was worth 300k! Someone actually thought this was a good idea and we should pursue it!

Over the last five years I've talked to a lot of YC candidates before their interviews. Many made it, learned, and a few even succeeded past my wildest expectations. When asked today I tell people that getting into Y Combinator was a turning point in my life. Without it, I don't believe we would have really pursued our startup -- both of us had decent job offers at the end of college that we ended up turning down after the summer. In fact, I'd probably be a wage slave at a consulting firm chained to a desk, only allowed to see sunlight walking between the car and a client's office.

Today's YC applicants are much more savvy than Emmett and I were, and I doubt we'd make it into the program today (that's how you know you've joined a good club!). This cycle I've received more requests for YC interview advice than I have for any previous cycle. I think that speaks to how YC's prestige and model have grown (and the popularity of the Social Network, which has made my non-startup friends come out of the woodwork with startup ideas in droves).

To all those fledgling companies that just got funding for Winter 2011, congrats. Go forth and in five years write your own nostalgic YC story.


Thanks to my cofounder Emmett for reading this. For those who don't know, after Kiko we both went on to start with Kyle and Michael (also YC funded). We're the biggest live video site right now and are working on some secret ideas that will be even bigger (shh!). If you believe me you should check out our job openings. If you're looking for a Christmas gift for someone special, check out the waterproof blazer my friend Kristen and I invented.

Measuring startup success by head count is toxic

Since founding my first startup five years ago, my cofounders and I have made many mistakes based on many mistakenly-held beliefs. Most of those were avoidable and we had some of the smartest people in the Valley telling us we were wrong at the time (despite that, we went ahead and made those mistakes anyways). However, I've been recently thinking about one particularly toxic mistaken belief that no one forewarned us of: that greater head count means greater company success.

I believe this idea is deeply ingrained in founder mentality. The first question that someone interested in your startup asks you is always "What does your company do?" The second question is "How many people do you have?" In the age of get big, then monetize we use head count as a proxy for revenues and success (or, as a proxy for another fake success metric, fundraising). As we grew's own head count, I used to be proud of the looks of awe I'd get from other startup founders when I told them we had "25, no 30" employees! And I would act in exactly the same way to my friends with 50 person companies (all those people must be executing on something, right?). As far as I knew, we were emulating the giants. After all, the goal is to become a Google or Facebook, and they have lots of people, right?

Wrong. As we've learned perhaps the hardest way possible, adding to the team has a heavy cost and should be done as a last resort, not as a first one. Here is why adding more people is expensive:

  • People are expensive. People have to eat, and good programmers want to do significantly more than just food on the table (iPads and gourmet coffee addictions aren't cheap!). The recent compensation arms race between Google and Facebook highlights how expensive it can be to retain key employees, and even though your startup probably isn't paying millions per engineer, personnel costs are usually upwards of 40% of your expenses.
  • More people means greater diffusion of responsibility. When the team was six people, it was clear that if something was broken (something technical or otherwise) there weren't a lot of people available to fix it. As your team grows, it is easier for people to shrug their shoulders and think "that's someone else's job," especially if you don't have clear job responsibilities. Which brings me to,
  • More people require greater management overhead. This is comes in the form of more managers, and more requirements for clearly defined goals and responsibilities. This can often be problematic for a startup, because often times when you are achieving product / market fit, you don't know what your goals are, and the company management is too busy to outline clear responsibilities for early employees.
  • More people require greater communications overhead. This means more meetings, and more people who need to be kept in the loop on a project. When we passed around 12 people, we found it necessary to start doing weekly meetings where we reported what was going on in different sides of the company, because otherwise the left hand didn't know what the right hand was doing. As Fred Brooks outlined in The Mythical Man-Month, group intercommunication increases geometrically with team members.
  • It is easier for your company to become politicized. When you have a 5 person company, it is clear that everyone is working on something critical to your success. When you have a 1000 person company, not so much. The line between the two isn't a step function, and somewhere along the line it becomes important for employees to start thinking of how they can demonstrate their value in an organization. Along with that comes empire building, title jockeying and the founders having to figure out how to counter balance these things.
  • It is very hard to hire talented, hard working, and loyal team members. Joel Spolsky neatly outlined how good programmers are probably not applying to work for you; they are probably already working at a cushy job with high upside at Google Facebook. People I respect have told me the best practical success rate of adding people that work out is around 50%, and after five years in startups I finally believe them. That means that if you're killing it in hiring, for every one person you add you are adding someone not so great who you will have to deal with later.
  • It is harder to pivot. People don't like change. Greater numbers of people means greater institutional momentum. Many team members who were hired to play a specific role have a vested interest in that role remaining critical to the company (even if it might not be). If you want to change that direction, you're going to have a lot of momentum to fight against.
  • Learning to manage has a cost for founders. When you are two people dreaming in a garage you don't even think of the practical day to day of organizing a large group of people. It took a long time for us (who had no experience managing teams before starting the company) to figure out how to get a company of 20-30 to work together towards a common cause, and that was after countless mistakes and guidance from more experienced managers. Today I'm acutely aware that we will face challenges between 50-100 that will be very difficult, and I look towards them in anticipation with confidence (knowing that we'll only get that large now if absolutely necessary) and dread (that there will be pain and it is unavoidable).

If you equate head count to success it is easy to get trapped into becoming a somewhat bigger company with less chance of actually being successful. When you are, it is very difficult and painful to reverse. This should be avoided at all costs, and that starts with eradicating from your mind the belief that more people == more successful startup. There is a legendary Bill Gates quote about software: "Measuring programming progress by lines of code is like measuring aircraft building progress by weight." The same is true of head count.

So what *are* good metrics for a successful startup? That depends heavily on your strategy. Revenue per employee comes to mind. For startups trying to go big, I like Facebook's measurement of users per engineer. But whatever you land on, make sure it is something that is core to your business.

At we like to say we're a small company trying to act like an even smaller company. Remember, managing a large team can be a pain in the ass for founders and isn't necessarily something to be racing towards with open arms. When you started your company, was it your dream to spend your days as a bureaucrat, managing conflicting agendas, creating "processes" and running meetings? Of course not. You wanted to create something that people love, that someone will pay you for, and to do it in a culture that you want to be part of. Where in that road map does it say you have to figure out how to organize and pay hundreds of people?


Thanks to my cofounders Kyle and Emmett for editing my essay (five years of writing only business communication hasn't helped any). If you want an awesome job, has finally figured out our path and has some critical needs for mobile product managers and engineers.

A really bad idea for a startup

Here is a really bad idea for a startup I've had for a while: for your health care.

This would be a consumer website where you would give them your health insurance provider and plan, and they would give you analytics and information about your usage, how to maximize your health care ("It's time to spend your vision allowance again!"), and how much your true health care costs would be (or would likely be) for different doctor visits and procedures.

This would be a huge boon to consumers because:
  • Health care plans are completely opaque: what is covered and when is in a thick book that is sent to you every year (this service as a 3rd party could tell you over the web in simple terms)
  • Often you don't know how much various health care services are going to cost until you've already consumed them (this service could shed light on that by having specific pricing data and also aggregate data on how much other users of the service have paid for services)
  • It is easy to forget when you are eligible / due certain regular services (this service could send you reminders)
I initially conceived of this service because I found dealing with health insurance super frustrating when trying to get some physical therapy for a minor shoulder injury (it was unclear what services were covered, what my deductible was, how many visits to certain specialists, etc). I heard similar horror stories from friends of people ending up paying 2x what they expected for surgery, various coverages changing, and on and on. It seems in many cases that doctors just bill an arbitrary amount, and insurance just seems to cover an arbitrary amount, with consumers often not knowing what they are paying in advance. This is insanity; what other industry or market operates this way?

In fact, dealing with insurance is such a gigantic, otherworldly pain in the ass several friends of mine and I have gone to doctors who don't take insurance and have just paid out of pocket. While I am fairly well off, it is clear that this option is not affordable for most Americans. The fact that as a Yale graduate I'm still not smart enough to figure out how to make use of my health insurance benefits either means I'm completely retarded or the system has gone horribly awry. Anyone who could bring transparency to insurance would be doing America a favor.

And yet, this is a horrible idea, because:
  • Getting the data would be a royal pain in the ass. Can you imagine trying to parse the benefits for each plan for each insurer in every state every year? Let alone translate them into some sort of computing rules?
  • If you built the minimum viable product, you'd probably be violating HIPAA. There are all sorts of laws regarding data storage for health care third parties. You'd probably be illegal.
  • People only need your service several times a year -- getting them to come back would probably be difficult
  • Unlike Mint, which could monetize on pre-existent CPA offers from banks and other financial product vendors, those don't really exist online now for health insurance, as most people's insurance is tied to their jobs and they don't have mobility (in a bizarre and archaic throwback to the forties, when wages were frozen and employers could primarily differentiate based on benefit packages).
Perhaps someone will eventually solve these hurdles and figure out how to provide value to consumers here. Or, more likely, the barriers to gathering the data and regulatory nightmare are prohibitive to innovation and nothing will happen.