Want to ace your Y Combinator interview? Be relentlessly empathetic | Hacker News Reader

Want to ace your Y Combinator interview? Be relentlessly empathetic

blog.perfectaudience.com

117 pointsbrandnewlow30 comments

Another alum here, good list of questions. As was stated, the key to doing well at the interview is insight. This can't be overstated. Show them something you understand about your users, market or technology that gets them thinking.

The actual questions will vary based on the type of team you are. I.e. a couple undergrad dorm-room hackers with a prototype, a team that's spent time in the industry they are trying to disrupt, a team that's developed some real technology, or a team with a product that has traction.

But whatever questions you get, demonstrate genuine insight, not marketing speak or cliches. And have a decent answer to every possible question. The partners have spent only minutes with your application, and you've spent anywhere from weeks to months to years on your idea, so this should not be that hard. If you do this, they will get themselves excited and you're pretty much in at that point.

Better yet: be relentlessly empathetic, create something people want (need/can't live with it, etc), whether you are interview with YC or not.

This is great stuff Brad, and I'd say it's just as important in the day-to-day happenings of your early stage startup, rather than just to ace a Y Combinator interview.

I love your advice about having at least 1 person dedicated to learning about/listening to users all the time. This is so key from my experience thus far with matchist (http://matchist.com/talent).

With an early stage startup, it's not about the code at all - it's 100% about the users.

These are crucial: How much better is your solution? Why would they switch to your solution?

Switching costs are often underestimated and it's hard to come up with a solid answer for this in many businesses. And even if you do have people who would switch, it's hard to get the distribution to implement a way of getting those users who want to switch.

"Did you know Airbnb thought the “breakfast” in Airbed & Breakfast was a crucial part of their product experience at one time?"

I did not! Interesting.

There's a screenshot I've seen from an early version of Airbnb where the listing page was divided into thirds, with a photo of the apartment, a photo of the host, and a photo of the breakfast (!!) all the same size. They really thought a good breakfast was important for listing your unit.

To be honest, a good looking picture of eggs benedict could probably convince me to stay with you.

In early days of Airbnb, they were entering market with bigger competitors like HomeAway and Couchserfing. In those days their breakfast service was one of the biggest differentiators. They focused on small niche of the market. Once they outgrew that niche, they dropped the breakfast option. It makes nice narrative, when Brian Chesky says how naive they were in the beginning to insist on breakfast. But actually it was well executed entrance into a market - focus on small niche, until you have product market fit and then drop the features that prevent from extending from that niche.

> These are crucial: How much better is your solution? Why would they switch to your solution?

And also: is there actually a problem?

Because without a REAL problem for your users, it doesn't matter how good your solution is.

Agreed. That question could be added to the list. The problem though is that question rarely gets an honest answer from the startup founder. The founder HAS to say yes. It's best for the questioner to ask these other questions and then make a judgement on this one in the background.

Yeah, I don't know whether they would ask that. It's definitely something that entrepreneurs need to ask themselves though. I see too many people running around the Valley like chickens with their heads cut off, getting excited over solutions without a problem. Both technical guys who are so excited about the shiny product they're making and non-technical guys who are convinced that their "vision" is correct. As a technical guy, I don't write a single line of code until I have confirmed that there are actually people with a problem who will pay me for what I'm hawking.

How would this work out in a scenario where the customers are a subset of the users. Say, a restaurant menu service that provides restaurants with enhanced menus for their clients. The customers are the restaurants and restaurant owners. But the users include the clients who actually use the menus and may have their own interests and considerations. You may revenue-share with the restaurants, but the customers are still the restaurants. Now there may be questions on this list, where the customers' interests and pain are at odds with their clients' interests and pain. What happens when the customer is an enterprise level business, and you can't speak to them daily or weekly or maybe even monthly?

The restaurant is the user in that situation because they're paying you money. A lot of B2B businesses are like this. The user questions are particularly important for vetting these sorts of businesses precisely BECAUSE the user situation is so convoluted.

My company sells advertising and the equation is similar to your situation. Our customers are marketers who use our tools to launch retargeting campaigns that serve ads to their own visitors. Our products have to interact with those visitors in a way that creates value for the business, but our actual customer is the marketer and we need to know his/her needs inside and out.

The "and you can't speak to them daily or weekly or even monthly" is one of the biggest barriers to entry into many very lucrative B2B spaces. One of the reasons why it took us so long to launch our product, http://perfectaudience.com, after finishing YC was because our initial product was aimed at enterprises we had domain knowledge of (newspapers), and when that didn't pan out and we had to build a product that went direct to advertisers, we had to go out and gain a ton of new domain knowledge from a customer type we weren't familiar with at the time.

B2B businesses are awesome and hugely lucrative if you can build something lots and lots of businesses want. But building something lots and lots of businesses want is a lot harder than building something lots and lots of consumers want because you're much less likely to have shared experiences with those enterprises than with consumers.

Thanks for the post. Interviewing on Sunday.

I've been trying to figure out how much time I might be able to get to explain what we do before the first interruption. 15 seconds? 10? Basically, I get a verbal twitter post, right?

"I get a verbal twitter post, right?"

That's a good way to look at it.

Thanks. Any chance you want to mock interview me?

We build software that stops law firms from overcharging our customers.

nwenzel edgesolutions.com

Ha. As a company that's had six figure law bills we've negotiated back to mid 5s thanks to careful documentation on our part, this tool sounds compelling. A real problem.

I hope the interview goes well, but I'm all tapped out this weekend. I wrote this piece as my contirbution to helping the folks I don't have time to talk to one-on-one!

Not just Brian. Brian and Joe Gebbia both flew to NYC every week.

Where was Nate?

Probably writing code.

So to ace your YC interview one must be empathetic and focus on the user. This is also the advice to give to somebody that wants to deliver a great product, I don't like to think in terms of what to do to get more investors and VC funding instead of thinking of delivering a great product. If you focus on the product and the user, the funding will come but that is not the goal.

I would love to see an actual tear-down question list from the man himself, or Gary, or Paul, or Jessica.

For now, I've printed this list of questions to hang in my office. :)

Glad you found it helpful!

This is essentially the 'Genchi Genbutsu' (http://en.wikipedia.org/wiki/Genchi_Genbutsu) principle. You need to get off your butt and figure out what your customers want (although not necessarily what they say they want).

Great advice! Small typo, "relentless resourceful" should be "relentlessly resourceful", shouldn't it?

Fixed!

Awesome post. Thanks Brad!

are you actually empathetic if someone has to tell you to be empathetic?

I think a lot of it comes down to focus. You have tons of code to work on, maybe family and/or a full time job, etc... It's easy to forget that customer email represents a real person at the other end.

"I'VE GOT PEOPLE SKILLS"

Want to ace anything in life, charm your way through everyday conversations and problems and more? Be relentlessly empathetic.

Reply on news.ycombinator.com