logo

Indie Hackers

Get inspired! Real stories, advice, and revenue numbers from the founders of profitable businesses ⚡ by @csallen and @channingallen at @stripe Get inspired! Real stories, advice, and revenue numbers from the founders of profitable businesses ⚡ by @csallen and @channingallen at @stripe

Transcribed podcasts: 277
Time transcribed: 11d 5h 6m 45s

This graph shows how many times the word ______ has been mentioned throughout the history of the program.

What's up everybody, this is Cortland from NDHackers.com, where I talk to the founders
of profitable internet businesses, and I ask them to share the behind-the-scenes stories
from how they got started and how they've grown their companies, so that the rest of
us can learn from their experiences.
Today, I'm talking to Vivek Ravisankar, who's the CEO of a company called HackerRank, whose
mission is really to make the process of getting a job as a programmer a lot more fun and enjoyable,
something that I can personally get behind because it's pretty terrible.
Now, HackerRank is, unlike most of the people that I talk to, a VC-funded company that has
raised millions of dollars, but Vivek and his partner went through a very similar story
to what you will go through as an NDHacker, starting any sort of business.
They spent years really just trying to find the right business model, the right product
that customers would like, and pivoting their way over and over and over again into what
eventually became a successful product.
There's a lot to learn from hearing Vivek's story and from listening to the advice that
he has to share.
So with that, let's get into the episode.
I'm here today with Vivek Ravisankar, the co-founder and CEO of HackerRank.
Vivek, how's it going?
Good, how are you?
I'm doing excellent.
Thanks for taking the time to come on the show.
I realize you're a very busy guy, but HackerRank is a fascinating company, and I'm really
excited to have you on because I think that there's a lot that people can learn from your
story.
Absolutely.
No anxiety to be here.
I've been following indie hackers for a while, so thank you for inviting me.
So for people who don't know, HackerRank is really a marketplace.
For developers, it helps you practice via coding challenges.
You can see how you stack up against other developers, and it also helps you find jobs
at companies that are hiring developers.
And for companies, it's the opposite.
It helps companies find talented developers, screen them using custom sets of tests and
challenges, and even interview them remotely.
Is that an accurate description of HackerRank?
Yeah, I should probably take this and put it on our pitch deck.
Yeah, that's pretty accurate.
That's how HackerRank works.
Yeah.
Cool.
And how big is HackerRank?
I asked just because it gives listeners some context and helps them better understand your
story.
And even if you don't share your revenue numbers publicly, I think other metrics can be telling.
Sure.
So from a community size we have, we're getting close to 3 million developers who are
who have at least attempted one challenge on our site.
And we have over 1,000 paying customers across different industries.
Stripe is one of our customers who we signed up recently from the internet software companies
to financial services like Goldman Sachs and retail, Best Buy.
So we have customers across the globe, so that's the scale we're looking at.
Awesome.
I mentioned that HackerRank was a marketplace earlier, where you're really connecting two
different groups of people.
Customers on one hand and companies on the other.
And the challenge here is that no marketplace is useful to one group unless you've already
got lots of people using you from the other group.
So you can't exactly help companies hire developers if you don't have developers on your site.
And it ends up being this really difficult chicken and egg problem.
So whenever I have somebody on the podcast who's got a marketplace, I like to ask, which
side has been the most challenging for you to grow over the years?
And how did you juggle this chicken and egg problem and sort of seesaw your way to where
you are now?
Yeah, it's a good question.
I don't know if I have the perfect framework or a generic framework to how to solve a chicken
and egg problem.
But the way that we did, and we didn't think of this very deeply, we figured, OK, if you
have a software and go and sell to companies because they already are interviewing a lot
of developers and it's a very inefficient process.
So just to give you a little bit of background about me, I used to work at Amazon before
this as a developer.
And I did a lot of technical interviews.
I think at one point of time when we did the math, we were doing about 100 phone screens
to get one offer.
So it was a crazy amount of time in terms of hours spent and the efficiency or lack thereof.
And that's what helped us, OK, let's go ahead and build a product that can help companies
optimize their whole recruiting process and make it way more efficient.
So that's what we got started.
And then as companies started to sign up and developers started to appreciate this mode
of evaluation because you didn't necessarily have to be in the top, you didn't have to
go to a top school or you didn't have to have the greatest pedigree in order for you to
get an interview at all of these different companies because you need to show your skills.
And resumes actually don't do a really good job in showing skills.
So developers appreciated companies that are adopting.
And then what started as, OK, let's just put up a fun little site where we can just have
a few challenges as for practice ended up growing this large community.
So frankly, we've actually never spent, or I wouldn't like to say never, but we have
probably spent very, very, very, very little.
And in the order of less than maybe $10,000 over the lifetime of Hacker Rank on trying
to acquire developers to join the community.
So it's largely been organic and word of mouth.
That's super impressive.
All your effort really is going to getting companies on the platform and not developers.
That's correct, yeah.
We have a standard go-to-market model for companies and what we are starting to see
as effects of the developer communities, as more and more developers come in practice,
they are also starting to see, OK, this sounds fun.
Let me go ahead and ask my company if they're interested to use this method of evaluating
developers for our own company.
So that also acts as a way for us to continue to grow our company base.
And I like that you mentioned that Hacker Rank is fun.
You're one of the few companies that I've had on the podcast where I've actually used
your product before having you on the podcast.
So I use ConvertKit now with indie hackers.
After I talked to Nathan Barry, I started using MeetEdgar after I talked to Laura Roter.
But besides you, I think only Zapier is the only other product that I've used.
And that's because Hacker Rank is pretty fun.
I've always been an entrepreneur.
I've never even wanted to apply for a job.
But I thought it would be fun one day to sit down on Hacker Rank and take challenges just
to see where I stack up.
And I'm a competitive person, so maybe I'm projecting a little bit.
But I think it's just inherently fun to see where you rank and to see how good you are
compared to other programmers.
Was it your goal from the outset to create a website that was fun?
Did you initially want to create something that was competitive for programmers?
Or did you take kind of a windy path to get to where you are now?
I think at the core of it, I wanted the whole job interview process.
I still wanted to be way more transparent and way more medic-based.
And I felt the existence of it was not fully solid.
It's still very stressful, and it's not fun.
Nobody thinks of going to an interview as a fun thing to do.
In fact, you're almost scared, I need to write my right code on the whiteboard.
And I need to practice all of these things.
I still feel the whole process of applying to a job and practicing and honing your skills
should be fun at the core level.
Have you solved it?
No.
But that's the path that we are on.
So at some level, I think it was deeply rooted in us that we wanted to make this as a fun
place for developers to do it.
That's such a cool mission because there's almost nothing fun about applying for jobs.
And I've sort of based my entire career as a developer around never having to do that.
Yeah, yeah, it is a bit stressful for multiple reasons.
One is, you know, most of the application process seems to be like a black hole.
If you apply to a company, are you sure you're going to hear back from them?
Did it even reach them?
And if it all reached and you got an interview call, are you sure what they're going to be
asking?
What are the tools that they're going to give?
And frankly, I think one of the companies that have done well, and I'm not saying this
because I'm on this podcast, is Stripe.
I think Stripe, they've done a really good job of, I think there was a PDF that they
publish on, here is what you can expect in the interview, here are the different skills
that we can evaluate on, and you know what, bring your own laptop and go ahead and code
it on that to make it comfortable.
So I think that's the direction, that's the direction and right way of moving towards
a better interview process.
Yeah, I hope so, because like you said, it's stressful, when I see developers preparing
for interviews, the number one thing that they seem to be feeling is just stress and
worry and anxiety.
You know, am I going to be good enough?
Am I going to get in?
A lot of bitterness when they aren't accepted.
So I hope you guys make some headway in solving that problem.
I want you to walk me through kind of the beginning story of HackerRank.
Were you worried about this particular problem in the very start, or what was your motivation
to get started?
I think, and I mentioned this a little bit earlier, so I was very annoyed at the number
of hours that I spent on interviewing, and resumes were a very poor indicator of skills,
and I knew that none of the developers in our team really wanted, really liked doing
the interview.
In fact, doing an interview was like throwing an exception in your code.
It's just right there in the calendar, and it sometimes even spoils the day.
So people used to either put the interview as the last two new items on the list or just
finish it off right at the beginning so that they have more time to go ahead and go.
So nobody liked doing interviews, but everyone wanted great developers, and resumes were
a poor indicator of skills.
So the intersection of all of this was, okay, there is a problem that needs to be solved,
so how do we go ahead and do it?
The early story or the early iteration of the product, we had a lot of failed ideas,
by the way, when we got started.
I think the first evolution of HackerRank was this product called Interview Street,
and the way that product worked was it's actually mock interviews.
So let's say you were going to interview at Amazon, you could come onto our site and attend
a mock interview with someone who's been through the interview process of Amazon or is working
at Amazon or is an ex-Amazonian to get a real understanding as to how the interview worked.
So we used to charge two, 350 rupees.
This is an Indian currency, so it won't be fair to compare to US dollars, but since the
audience is global, so I'll say it's about $10 or so, or probably less than that, and
250 rupees to the interviewer.
We used to pay the interviewer because you're conducting the mock interview and 100 rupees
goes to our pocket.
So that was our very first business model.
I still have the Excel where we project a billion dollars of revenue, and I think after
a year and a half or so, we made about $1,000.
So it was a big lesson that you can do any magic in Excel, that you can just put a formula
and just scroll it right through all the rows and you get large numbers, but it's really
hard to execute.
I think we learned a tremendous amount of lessons to that, and I don't like to blame
the market or external ones, there were a lot of things that we could have done better,
but I don't think the payment infrastructure, it's irony, something about Stripe, the payment
infrastructure in India was very poor at the time.
It was so hard to set up a bank account, set up something online, and we had to go to individual
colleges and we collect money in cash in person from all of the candidates.
What year is this?
This was 2010.
That's when we got started.
And then of course, the amount we pay for interviewers who are working at companies
like Google or Amazon or Microsoft, it wasn't really interesting.
Do I really need this and spend an hour to do it?
I'm not really sure.
So there was not a good, and it's some kind of marketplace where I don't think there was
a good supply demand match.
And we applied a white common error during this process, we got turned down.
So we then iterated to another idea where we wanted to help students who are applying
for masters.
This was sort of a tangent to our original idea because that failed.
And it's a big deal.
If you let me interrupt for just a second, why did you start with the mock interview
idea?
So we thought, okay, the way to fix this whole interview problem is to just train candidates.
I mean, there are two ways to go ahead and do it.
One is you could give the product or a solution to companies.
Or the other option is, okay, look, you can actually help candidates prepare, hey, here
is what you need to be good at.
And just like any other preparation, you can go ahead and do it.
So we didn't know which one to choose.
So we just went ahead with choosing the candidate side.
That makes a lot of sense.
Why did it take you, you said a year or a year and a half to figure out that it wasn't
going to work and that you weren't going to hit your super optimistic billion dollar revenue
target.
Yeah, so the billion dollar revenue target was definitely over the course of five to
six years.
So it would have been pretty crazy to do it over a year and a half.
But why did it?
I don't know.
I think it's probably, we just, it's really hard to know when the idea is not working.
When you think about stories like Airbnb and others, and you see that they work three years
with, I don't know, 10, 10 bookings or 20 bookings or something really tiny, and then
it suddenly grew.
That's one thing I don't think there's a perfect framework for determining when do you stop
working.
So I don't think there's a particular logic on which we stopped doing after a year and
a half.
Maybe we were just tired.
Okay.
This doesn't seem to be going anywhere.
Oh, that makes sense.
Do you remember having a conversation with your co-founder about, you know, when you
guys got to the point of being ready to pivot and ready to quit, were you guys, did you
see it in advance, you know, for a number of months or did it, was it kind of like a
sudden epiphany?
We should stop doing this.
Actually, we never really stopped doing it.
So our pivot was, okay, we'll just keep this in one tab, in a hidden tab on the website,
but we'll do something else on the homepage.
So if somebody comes to that, let's go ahead and let them go ahead and do it.
So it was not a hard pivot.
Great.
So you were describing kind of the next product that you guys started working on.
What was that like?
And what was it?
What was, again, something tangential and, by the way, I'm probably just glossing over
a ton of tiny details that we continue to do over the year and a half in terms of iteration.
First was figuring out payment.
Second was figuring out scheduling.
You know, what if the interviewer had some other meeting at that point in time?
How do you communicate that to the candidate and then figuring out the scheduling part
of it sometimes and I don't know if it still exists or not.
So it is pretty expensive to call somebody in India, especially if you don't belong to
the same state.
So in the US, it's very different.
So you can call from here to New York and there's no extra fee or extra charge compared
to you calling somebody in California.
But if you were to call out of state, it used to be pretty expensive.
So then when we used to max the candidate from one state and an interviewer in another
state, who's going to bear the phone expense?
And our margins are already tiny.
And so if you add the phone expense to it, it becomes even smaller.
So who's going to bear that?
So there were, and we continue to iterate a lot and then we found a really good audio
conference facility, which was cheap and also had wipe.
So over the course of one and a half years, it was just a series of iterations trying
to figure out what could work and figuring out how do we do the match.
And so it was not a hard pivot, it was just, okay, I don't think there's any logical iteration
that we can figure out to make this work.
And so let's try and figure out how this whole idea of connecting students who wanted to
do their master's program in the US work.
And the reason for this was, I mean, as we continue to work on the first idea, we talked
to a lot of students, we asked them what are their pain points, of course, interviewing
and getting a job was one of them.
But then if not equal, there was probably more.
And the bigger pain point was, hey, I want to go to a university in the United States
for doing a master's in computer science, and I have no idea how do I pick a school.
And it's a big, big deal in India to come here and do your master's.
And of course, the application process was intensive and expensive.
I mean, each application form, I don't know, used to be around $100 or so, which is even
pretty expensive just in the US denomination, but if you look at India, it's way more.
So then what that means is you can't apply to 10 schools, you can only apply to five
because you have a limitation on how much budget you're willing to go ahead and spend.
And if you can only apply to five, how do you choose which five?
And so we used to connect people here to students who are already doing their master's in Carnegie
Mellon, in Purdue, in MIT, in Stanford and others who can review your statement of purpose,
your resume and tell you, okay, here are the areas that you need to improve, here are the
areas that you need to get better at, and here you have a good shot of it, here you
don't have.
So that started to work pretty well in the early days, and there was a good uptick.
And after a couple of months, the traffic was almost down to zero.
It turns out that you can only apply twice a year.
So we didn't know what to do for the rest of the year.
So that also failed.
And we again applied to YC, I think, during this time.
Of course, we got turned on because we didn't have a product that was either a really good
idea or we screwed up the application process.
So that was our second pivot, yeah.
It sounds like you really now, like when you're describing what you were working on, you do
a really good job describing the problem that people had, how difficult it was for them
to apply to go to the United States and go to school and how they weren't able to apply
to as many schools as they wanted to because it was so expensive.
I think it's very smart to look at your business in terms of what people want or the problems
that they have, rather than just the features that you want to build.
Were you thinking about those things the same way back then?
Or is this kind of now that you have more knowledge as an entrepreneur, you can look
back and frame it in terms of the problem?
I think we continue to get better at that.
Even now, whenever a customer asks for, hey, I need this particular feature, I think everyone
thinks in a very, very narrow environment where, okay, I need this so that it will make
my life better.
And that's the right way.
I can't blame them for that, but we need to really understand what their problem is.
And so related to that, when we started to pivot to the Hack at Rank product, which is
our enterprise product of selling to companies where they could create their own custom challenges
to hire developers, we got much better at it because when we went and talked to different
companies and different recruiters, they really wanted us to solve, okay, I'm going to give
you a set of resumes, please write a resume parser that can tell me who the right developer
I need to interview.
So we would have ended up building a resume parser if we didn't get to the core problem.
And the core problem was I can't identify who's the right developer based on a set of
resumes.
So our solution was completely tangential, which was to build a code checker module where
people can write code, compile, and we evaluate on complexity, on correctness, and a bunch
of different parameters that we're starting to extend on and see who's really good.
So I think that was an example of where we dug deep into understanding what the real
problem was instead of just implementing, okay, here's what you need to go ahead and
do.
Yeah, that's so interesting.
And it reminds me of like the most cliche Henry Ford quote, I think, in the world where
he says, if I asked customers what they wanted, they would have told me they wanted a faster
horse, where he kind of highlights the difference between focusing on the solution and focusing
on the problem.
And when you focus on the problem, you can come up with more novel solutions that actually
do a better job solving that problem.
How much of your early development, and all these pivots and changes you were going through
early on, how much of that was driven by talking to customers and how much was driven by your
own intuition for what people would want?
I think until we got to a really strong product market fit, I think it was driven a lot by
customers.
I think once we identified and we got a really strong product market fit, especially on the
hackeryne product, it is also driven by customers, but I would say the intuition of, okay, where
should the whole market go or where is the job industry going or what is the future of
interviews going to be is a lot driven by intuition and experimentation.
So I think the balance has shifted a little.
I bet you it's a lot more fun when you can go by intuition and experimentation.
Yeah, it's fun as long as it works.
If it doesn't, then it's not good.
But yeah, if it works, then it's great.
So tell me about the early days of hackeryne, when these people were asking you for a resume
parser.
What did you guys do next?
We were never interested in building a resume parser, frankly, and I think we sat down to
write code for it, but I don't think neither of us were just bought into the problem.
What would you search for?
I mean, basically, if it's garbage in, which is if everybody's going to claim that they're
an expert, which you have to claim, why would you claim that you have a novice resume?
How can you get meaningful signals out of that when you write a parser on top of it?
So we were never really convinced about it.
And so it was back to, OK, how can we figure out how can we go to the other side?
Now, all of our thinking has been how do we train candidates, how do we prepare candidates
for interviews and all of them?
But can we flip to the other side where we can say, hey, company, here is a product that
you can use to assess developers, can we go ahead and do it?
So it was more about flipping to the other side and experimenting with it.
In terms of how we came up with the idea earlier, I think both Hari and I were competitive programmers
back in college, so it didn't take us.
And we actually wrote our code checker in college that used to power all of the different
programming contests.
So it was sort of a home territory for us, and we said, OK, let's go ahead and build
this and see if companies are interested to buy this.
It's interesting you had a background in competitive programming.
Do you think you would have thought about this idea if you didn't have that background?
It's a good question.
Sometimes I think it's a boon because it helped us get started.
Sometimes I think it's a con because I don't think the entire world of developers of clearly
the entire world of developers is not competitive programmers.
It's probably a small subset of that.
And so you need to make sure if we want to build a large developer community and make
sure that the job interview process is meta-based for developers across the globe, then we have
to get away from the competitive programming mindset a lot.
So it's both a pro and a con.
Yeah, it's difficult to navigate being a founder and building a product that's supposed to
reach many thousands or hundreds of thousands or millions of people because no matter what,
your own personal experiences are never going to be representative of what life is like
and what other people's goals are for that number of people.
Yeah, like you mentioned, I think one of your intrinsic motivation and probably your personalities
like that is to, okay, I'm going to code and see how I rank against other developers.
In fact, what we found was over 50% of developers actually just wanted to continue to improve
their skills and see how well they are doing, not even try to benchmark against how well
I'm doing with other developers in my country, my region and things.
I want to do this because I want to personally improve.
And it's a very different mindset from a competitive one, which is, and we specifically try to
ask questions or try to distinguish these two sets.
The competitive mindset is more about I need to be there in number one leaderboard.
And neither of that is right or wrong, but it's just a different mindset.
And so being a competitive programmer as a background, we'll probably need to sometimes
it's a pro, sometimes it's a con.
Yeah, totally.
People are completely different.
I work with my brother and he's, we're twins, but he's the exact opposite of me in almost
every way.
A good example is if we're playing board games, I will, for example, jump in, play a game
that I don't know how to play, lose a bunch of times and try to get better, whereas he's
more of the mindset that he won't play until he knows all the rules and has seen a bunch
of other people play so that he can, you know, come in his first game and look competent.
So it's just interesting to be a founder and to deal with the fact that you're probably,
you know, at your core, very different than most people.
And it's difficult to know what they want and how they tick, unless you actually talk
to them and spend a lot of time around them.
Yeah, yeah, yeah, yeah.
I agree.
I think, uh, go ahead.
No, I'm just, I was just trying to say both of you have a different AI training algorithms.
Yeah, we do.
But I think it gets us to a similar place in the end.
How did you find your first customer for hack and rank and beyond your first customer, your
first few customers?
It was a lot of struggle.
So we did, we did a bunch of things.
I think, I think one of them was, of course, try to ask my ex manager at Amazon, Hey, can
you go ahead and try?
Of course, Amazon was not willing to try out a product that was just built by a couple
of guys, uh, in a garage or sort of in a garage.
We really built it in Hari's, my co-founder, Hari's terrace.
So one hack that we did was we created, um, okay, I think I can, I can say this, it's
been a while.
We created a fake resume, which had the greatest credentials, right?
That your mom would be so proud of.
Uh, we, we, it had, uh, IIT is the equivalent of Stanford or an MIT in India.
So we, we put it as, okay, we went to IIT, we did, we had the highest GPA, we went to
the top schools.
Uh, I mean, we went to the top company, we worked at top companies, it was a fake resume.
And then we just put it up in all of the different job boats, right?
And so what we got was a host of inbound phone calls from recruiters because they all wanted
to hire this person.
And then whenever we used to receive the phone call and say, Hey, you know what, I, I'm not
that person.
I want to be honest.
I'm not that person.
But if you use our product, you can help find people like that.
So that's, that's one way that we used to generate demand.
And it actually worked.
I think, I think we got Zynga as our, it was one of our early customers.
And I think, uh, we had a call from one of the recruiters at Zynga who, um, who wanted
to try, try this product.
I think it was a combination of, okay, let's get a few of our friends who are working in
companies to try it out.
I think this hack worked pretty well.
And then once you had some proof points, then we, we started to get a lot of customers there.
Yeah.
That's such an ingenious hack because it really flips the equation on its head.
And instead of having to do a ridiculous amount of research and spend all the time, you know,
making outbound calls to these recruiters, you just had people calling you.
Yeah.
Which is the exact situation you want to be in.
Yeah, exactly.
Yeah, so it was, it was just a really easy way to try and do that.
Yeah.
I think oftentimes early on in a company's life and in a company's history, there are
times where you have to do things that are sort of unscalable.
And I know you went through iCombinator, so you probably heard this mantra a lot of times
from Paul Graham, do things that don't scale.
Were there any things that you guys did early on that didn't scale where you were putting
in a lot of manual effort to do something that you knew later on, you would probably
automate or outsource?
Yeah.
And I don't think that's, yeah, it's a really good article.
What I'm not sure, and I, what I'm not sure, maybe I should ask Patrick or Airbnb or Brian
Chesky from Airbnb, do you, does that stop?
You know, I think that the article was more on hey, the early stages you got to do, but
I feel sometimes even now, I know this thing is not, I'm doing things that is not going
to scale, but I have to do because something is broken.
So it's a balance.
So early on, I think one of the things that we did was we, in order for you to really
create a good programming challenge, what you needed to do was you needed to have a
concise clear problem statement, you needed to generate a bunch of test cases, and when
you choose different languages, let's say you choose C++, Java, Python, and you needed
to have good code steps, you know, you want the developer experience to be great.
So you wanted all the other the developer needed to really do was to just complete the
function and start worrying about how do I take the input?
Is it from a CDN?
Is it from a file?
Is it?
Do I need to read from read from some other API?
So what the early days of creating a question was literally, we'll go to the company and
say, you know what, I'm just going to make it super easy.
Just send a word doc, just just write down a very high level overview of what you want
to achieve in this question.
It doesn't have to be so detailed, we will do the manual work of making sure that we
we put in all the constraints, make it very clear, concise, create all the test cases,
put all the code stubs, and I think it was getting painful.
After a point of time, we, of course, had some internal tools that we built.
And and this was this was one of the things that I can remember were in the early days
where we did things that that clearly wasn't scalable.
Yeah, it's it's good that you describe it as painful, because I think a lot of people
realize that yes, doing things like this is painful for you.
But if you don't do it, then it's going to be very painful for your customers.
And when you're super early on, you can't really afford to, you know, make your customers
jump through hoops to try to use your unproven untested product that you're not even sure
if it's going to work.
Yeah, I agree.
Okay, so you found your first customers using this ingenious hack, you're doing a lot of
unscalable things.
How did you grow and mature hack rank as a product and what were some of the first changes
you made?
Again, I think it sort of depends upon it varied a lot on different phases from just
from a company perspective, I think a lot of the changes, a lot of the things that I
have to learn continue to evolve myself as a founder and CEO is the quality and the importance
that you give to the exact team.
And this is just on the company side of it and how important it is to hire the right
exact team who can help mature the company.
On the product side, specifically, I think we got to continue to improve our usability
and how do you make sure that your time to value to a customer continues to decrease
the time to value.
But as we start to go to selling to larger and larger companies, there are a lot of things
specifically that we needed to do to cater to the needs of a large enterprise company.
If you're going to sign up a company like customer like Goldman Sachs or Bloomberg or
VMware, you have to help them give the ability to deploy to a large parts of your organization,
which means whether that's integration with your existing tracking systems like Workday,
TELIO, or single sign on or teams management and all of these things which you wouldn't
have really thought.
And it's actually not even something connected to the core of your product, which is how
do you evaluate a developer really good.
You start to think about all of these things as you start to mature as an enterprise company.
So I think at different stages of the product evolution, we had to work on different things.
Yeah, it's a lot of stuff to learn and I'm curious how many people you were working with.
You've mentioned Hari, your co-founder, who you seem to have known since working on Amazon
together.
No, we went to the same college.
So we knew each other from college and we did a bunch of things together.
And for what it's worth, at least on the record, Hari is a way stronger, better hacker than
me.
Well, when did you guys first start bringing on other people besides just the two of you?
I think right after we got into Y Combinator, well, frankly, we didn't have any money before
that.
So Y Combinator was our first dollar investment really.
And yeah, so we hired our first set of developers after we got into YC.
Tell me about the story of getting into YC.
You got rejected twice, right?
And then you finally got accepted with your third idea, Hacker Inc.
I really wanted to come to the Valley.
And I think I thought, and I still think it's a magical place, at least for building companies.
The cost of living is insanely high though, but still, at least for building companies,
I think it's a pretty amazing place.
And I thought, I mean, I had multiple paths that I plotted in my mind.
One was, okay, let me try to do my master's in computer science at some college and study
there and work at a company for a couple of years and then start to do my own company
here.
Or I could continue working in Amazon and then move to Seattle or California or something
within Amazon and then try to go ahead and start a company here.
And the third one was, is there a faster path?
The first two paths were just, okay, I have to spend three, four years to then figure
out.
And there are so many different variables and so many things that could happen in the
four-year span that I didn't even know if my dream can come true.
And Y Combinator seemed to be this amazing path.
And it's a great passport for you to go ahead and start your own company.
And so I was very determined to come here and start.
And so I figured, okay, you know what?
I'm just going to keep applying until these guys say yes and fly me in.
Yeah.
That persistence seems like it really paid off.
Yeah.
It was really interesting.
That was my first trip to the US.
I think I landed on a Thursday morning or Thursday afternoon and I had my YC interview
on Friday.
And I think it was the last day of the interview because I didn't even have a visa.
And I don't know how much you know about immigration and things, but you can get a visa only after
you get an invite letter or something of that sort from Y Combinator or any conference that
you're attending.
And of course, the window of interviews was only two weeks.
So I got an invite letter on Monday and then it takes another five to seven days, five
to seven working days for the consulate to process the invite letter and get the visa.
So I had to just figure out a way how to rush that through.
And I think I flew in Thursday and I think I had the interview on a Friday.
So I was just checking my location stats on Google Analytics before we sat down and started
recording.
And something like 60, 65% of all visitors to Andy Hackers are not from the United States.
And even if you add together traffic from the US, Canada, and the UK, it's still, I
think, less than 50% of the traffic.
So if we assume that the podcast has a pretty similar ratio, then that means many thousands
of people listening in are trying to build businesses in places other than the United
States.
And you learn a lot from your experiences.
What kinds of obstacles have you run into starting and growing your business from India?
And how have you overcome those challenges?
Yeah, I think, well, I think India has changed tremendously.
I think there have been real giant winners or companies in India, like Flipkart, and
then there is Ola, there's Paytm.
I think the whole market has changed tremendously over the last four to five years.
But when we started, yes, it was pretty hard, as I said, just to figure out how do you get
people to pay on your website used to be this long process and where you had to fill hundreds
of forms to try and get an okay, instead of just having here is your JavaScript snippet,
go ahead and embed it on your code and get this up and running.
So I think it has changed a lot.
But I think the biggest thing that still remains to be seen or to be known is the talent.
And when I say talent, when I try to figure out, okay, I need this problem, we want to
scale from 20 million in revenues to 100 million ARR, and we are an enterprise SaaS company.
So how many such VPs of sales have done that and scale that exist?
And I think the odds are much higher that you will find more people here than in India
who have done that in the past and who can actually help you go ahead and do it.
So I think that problem still remains to be solved.
And I frankly don't know how you can solve it unless you actually go ahead and build
large companies.
And it's going to take a while.
I think that's the shortcut of why people try to move to Silicon Valley, because the
people who have solved problems who can help you get from point A to point B, the odds
of you finding them are higher here.
Do you think that you would still care as much about being in Silicon Valley if you
weren't a VC-funded company?
Yeah, for the talent, yes.
In terms of finding the people who can help me grow and help the companies scale, yes.
I think your journey is kind of interesting because it seemed like early on you guys weren't
really depending on funding, not until you got into YC, and you had years before that
where you were working on different things.
Yeah, well, our burn rate was really low.
We were just staying at our house.
We had free food from my mom, and all we had to be had laptops already.
All we had to really pay was for the internet.
And it's not that we didn't try.
Of course, we tried trying to raise an angel round of financing at VC.
I think we talked to a couple of VCs, but we frankly didn't deserve, I would say.
We didn't have a product that had a lot of traction or so, so I wouldn't really blame
them.
But it was also hard to raise any kind of financing in India.
Yeah.
I think back in those days, like 2010, 2011, there was sort of a bigger debate, although
it still exists today, between bootstrapped companies and VC-funded companies.
And I know that I was also applying to Y Combinator at the same time that you were.
And I, in one hand, really admired what YC was doing and really admired companies like
Facebook that were able to grow so fast, but I was also listening to these guys from Base
Camp, or I guess it was 37signals at the time, DHH and Jason Fried.
I saw them give a talk at startup school, and the message that they were delivering
was, hey, why not just charge money upfront with your products?
Why take the risk of having to raise a bunch of money and become a billion-dollar company
or bust?
Is that something that you struggled with, or were you aware of both paths?
Or were you more drawn towards fundraising from the very beginning?
I think I was drawn to Y Combinator, primarily as a way for me to get an entry into Silicon
Valley.
And of course, it's one of the most prestigious networks that you can be associated or connected
to.
But then I think, once you get into Y Combinator, all the philosophies of DHH just goes out
of the window when you start to do the demo day.
I don't think, I think it's really hard for you to imagine going to the demo day and
saying, hey, here's our traction, we're really good.
And by the way, we're not trying to raise any money.
I think, at some level, the peer pressure of, OK, who's getting the highest valuation
and who's getting funded or so forces you to go in the direction.
And I'm not trying to blame YC in any way.
But I think, once you get into YC and demo day, you start to think on that.
And once you raise your first round of financing, I've started to believe this.
You're just in that loop.
You just, I don't know if stuck is the right word, but you're just caught in that loop.
And you probably continue to raise more financings from VCs there.
Yeah, totally.
I mean, I think moving to Silicon Valley and especially joining Y Combinator is a pretty
big first step towards making that decision that that's the kind of company that you want
to be, whether you wanted to or not beforehand.
A lot of people, I think, are themselves trying to decide what they want to do with their
companies.
Do they go the fundraising route or do they try to bootstrap things and maybe grow a little
bit more slowly?
How would you say that raising money has affected your goals and your vision for hackering?
I think there are two things.
One is what comes with the money.
If you're not going to get any sort of strong advice or if you're not going to have a strong
VC or a board member who can help you think through the problems, who can help you navigate
through challenges, who can help you recruit a great team, I think that kind of money,
it's hard to debate how valuable that is.
But if the money plus the aspect of somebody who can help you navigate through the challenges
and help you be a strong partner to build a great company, I think that's very powerful.
Specifically if you're a first-time founder, if you're a first-time entrepreneur, that
can be really valuable.
Okay, so I want to get back into the story of you growing HackerRank because a lot of
time has passed between you first got into YC and where HackerRank is today.
I mean, I think you guys have grown at least 10 or 100 times since then.
Was that accurate?
Yeah.
Although the base was really small.
Yeah.
So yeah.
What kinds of things went into that?
Yeah.
I've never really looked back at that.
But I think at every stage, it was we had a very clear goal of, okay, we want to make
sure.
I think at some level, you need to identify yourselves specifically in the marketplace.
Who is your primary audience?
And I think there's a great article.
I think she was in Airbnb or she was a consultant in Airbnb.
It's a great article on how do you prioritize this?
So if you have drivers and riders, what does your company stand for and how do you lean
towards?
You of course need both the players, but how do you go ahead and do it?
So I think from early on, we were a very developer-focused company.
We of course needed to have a good balance between developers and companies, but at the
end of the day, it was more on how do we make sure that our mission is to manage every developer
to the right job.
So even in our mission statement, it is the primary thing is how do you make sure that
you can connect the developer to the right job.
So a lot of things that we did on the product side in terms of growing was consistently
based on how do we make sure that the experience of developers is great, which of course is
going to help companies a lot because if you get more signals about a developer in terms
of how they did and if you continue to enhance your editor capabilities, if you continue
to enhance the types of languages that he supported, all of these is going to help developers
which is in turn going to help companies.
So at a very core thing, we were a developer-first or developer-oriented type company where we
tried to improve a lot on the direction.
On the go-to-market side, initially, it was just a lot of trial and error where I was
the first salesperson and then the pricing model was just completely pulled out of thin
air and we didn't know what was the right kind of pricing model.
So we went ahead and pitched to a lot of companies, figured out, okay, this works, this doesn't
work.
So initially, it was just me doing a lot of sales and then we started to hire our first
few sales people and then try to get the right head of sales and continue to up-level the
team in terms of how they pitch, how do you build a very repeatable sales cycle, how do
you make sure that your message is consistent across the org.
So I think at every stage of evolution, you need a slightly different, slightly enhanced
go-to-market strategy.
So it was initially trial and error.
Even now, at some level, it's a trial and error but at least we have a clear path on
how to evolve.
So at this point, you guys are killing it.
You hit product market fit, YC is invested, you're growing like crazy and people like
what you've built.
But was there ever anything that really worried you, like an obstacle that you guys thought
you wouldn't be able to overcome or some sort of a stopping point in front of you?
I think Silicon Valley, I don't want to blame Silicon Valley but just the perception is
it gives a tremendous amount of credit for high growth and which is good.
High growth company is great but sometimes what that also means is you need to balance
that with extremely good fundamentals and good foundation.
So I think I've thought through this a lot and specifically I think somewhere between
2014 and 2015 where we were hiding like crazy, we're actually also growing like crazy in
terms of our annual recurring revenue and things.
But I always had the feeling, hey, is our foundation right?
Do we know exactly what we are selling and do we know, do we have a clear product roadmap
to support that?
Do we have the right engineering or do we have the right product folks to go ahead and
build that?
And I think I was particularly caught by this whole thing of hyper growth, you need to,
whatever it takes, you need to double your ARR year over year otherwise you're not an
interesting company at all.
And I think that bit us a bit, yeah, that bit us in 2016 and so we had to make sure
that okay, we need to have our foundations and fundamentals right and frankly the company
right now is I personally feel is in a much, much stronger, healthier state for us to go
and scale faster.
And I think that's something I admire about Stripe.
I remember in my YC class, there was brain tree that was just growing like crazy and
I remember there was an email from somebody saying, hey, brain tree is offering us $50,000
in free credits.
And I think it was Patrick or someone saying, hey, by the way, we're working on this product
called Stripe.
I think it was probably called debt payments or something and just hold on to this.
And this was 2012 or late 2011 or early 2012.
And if you just think about the growth rates, probably brain tree was growing at a much
faster rate but I think what I admire about Stripe and Patrick in a lot of interviews
is the fact that how much time he took in ensuring that the first 10 people were really
important, were really right, took about a couple of years to make sure that that foundation
was good and now you can continue to grow and scale.
I think that's a great lesson.
I felt I learned it a bit late but I think our company is in a much stronger position
state right now.
What other lessons would you say you've learned along the way?
You started off in a situation where it wasn't at all clear that you would achieve the level
of success that you've had today, that you would manage as many employees that you have
today and generate as much revenue.
What has surprised you?
What have you encountered that's much different than what you initially expected?
I think I was very naive when I started in terms of understanding what it takes to build
a company.
I kind of the assumption that, okay, I'm a developer, I can code, how you can code,
that's 70% done.
That's 30% is okay, you build a product and people go ahead and buy the product.
Because you never really, of course, coming from India and admiring Silicon Valley, you
start up admired Zuckerberg, Larry Page, Max Levchin, and now they really look like
sales faults.
They were all strong developers and, okay, they built a great product and can you get
an option and they make a lot of money, a lot of money in sales.
I think my biggest or the interesting thing is my determination or courage to do things
as being sort of a persistence or however you want to frame that has been far, far way
more tested than my intelligence or IQ to do this.
I would have never thought that if you needed to get from this point A to point B, you needed
a level of IQ for sure, but the biggest determinant is going to be, are you just determined to
do that?
It was very consistent to do that and it was really surprising.
Yeah.
It's clear just from listening to your story, I mean, we've been over it, but you got rejected
from Y Combinator twice.
You've had multiple businesses that you had high hopes for that ended up failing and yet
you kept sticking with it.
You didn't quit.
And we've mentioned Airbnb, which is like the canonical never quit, keep sticking with
your dream story, but it's in reality much harder to do.
And based on the people that I've talked to, the number one reason that companies die isn't
because the founders are untalented or because they're in a space with no customers, but
it's because people eventually quit.
They get tired of the challenge and go on to something safer.
What do you think has been the difference that's allowed you to stay motivated and what
are some tips you have for other people who might be going through rough patches?
I think at some level, I've been lucky to have a great co-founder like Hari.
So I can speak to someone openly about some of the challenges and get real advice.
You don't get that a lot.
So I do think it's important and this is probably, I'm not sure this is probably why YC is so
hell-bent on you need to have a co-founder because at these low moments when you don't
have someone whom you can talk to and exactly understand the situation you're in, it's probably
going to be painful.
The second one is likely, I have not given it that much of thought, but the second one
is likely, I really want to solve this problem.
And so there is no external motivation or anything of the sort.
I really wanted to solve this.
I still want to solve this.
And so you just have to keep going.
So it's probably not the best answer, but those two are likely the reasons.
No, I think it's a great answer.
I think it's really easy to underestimate, especially early on when you're 100% optimism
and you haven't started yet, it's really easy to underestimate how hard the hard times
will be and how important it is to have somebody to talk to you, ideally a co-founder who knows
everything that you're going through.
But at the very least, a community of founders or mentors or advisors who you can confide
in.
And I wish there was some data on it, but I would bet the companies that have multiple
founders or companies for the founder at least have some advisors end up lasting a little
bit longer than companies that are run by a solo founder who's not talking to anybody.
Yeah, I definitely think that's logically that makes a lot of sense.
And I think the whole question of determination and persistence is also not just till you
get the product market fit.
I think every year it becomes harder.
And at least one thing that I validated from others is, yes, they also say it becomes harder.
I'm not the only crazy one.
And so you have to have that level of determination to continue to go on to the next level.
So what I mean to say is it never stops.
It never ends.
So you can be the most persistent guy till you get the product market fit.
And after that, if you start losing it, it will still not lead to a large company.
So I think it never stops.
And this is probably one of the reasons I remember PG telling, not me, but some other
who's advising another person during one of the office hours, you have to choose your
idea carefully.
Because one of the things that's just going to keep you going the low times is whether
you really want that idea to come true.
And that was a very profound advice because I didn't think of it that deeply because at
that time we were in this real high, oh, we got it OIC, these customers are buying and
so on.
But it really helped me when you're going through that low rough patch.
If you're not personally super, super committed to the mission, it's going to be very hard
for you to get up and say, okay, I really want to do this.
Yeah, I think that's excellent advice.
And it's one of those things that's so easy to talk about when you're in the situation
where you have a really cool company like Hacker Inc.
Or even in my situation, I think Andy Hackers is pretty cool and I agree with the mission.
And I talked to a lot of other founders who are kind of stymied by the challenge of coming
up with an idea that not only is a viable business, but also something that they're
passionate about.
Because if you were to sort of make a Venn diagram, there's not a lot of overlap between
those two circles for a lot of people.
If you had to start from scratch right now and come up with a new idea that couldn't
be Hacker Inc. or couldn't even be in the same space, how would you go about that process?
I think the first one, I don't think I would change much about how we got to a product
market fit.
I think I would still continue to...
Firstly, I would probably choose something that I'm personally really passionate about
in terms of a problem that I really wanted to solve.
And I wouldn't change much about approaching customers, getting their feedback and iterating
a lot on that.
The things that I would be more careful is making sure that we don't do a lot of things
early on.
I do think our first product was not really an MVP.
It had a lot of different things that were going on, which is possibly one of the reasons
why we said, okay, I'm going to create questions on my own.
You just forward us the doc.
It could have been way more simpler.
So one thing I would change is we're going to do just this one thing because that's what
customers want.
That's what we're passionate about.
And we're going to do this one thing really, really, really well that everybody loves.
And I think WhatsApp is a perfect example of that.
Such a simple, simple product doesn't even require your email, doesn't even require a
signup or a login.
All you need to do is just their phone number and all you can do is just send a text.
Of course, I think now they might have broadened it more, but they didn't have audio, video,
nothing of that sort early on.
So I think that would be one thing that I would change.
The second thing is I think we were somewhat lucky in our first hires.
We hired a couple of people from our network, and the people who came on board who were
not from our network worked out incredibly well, but I think we were just lucky.
I think if I were to think through, I would put a much stronger emphasis on who we want
to be the first 10 people that we're going to hire.
I think that changes or that impacts the trajectory of the company a lot.
The third thing is I would probably try and put the core values of the company much earlier
in the life cycle, in the evolution of the company.
I think we're just actually starting to identify here are the core values, and we're going
through a very rigorous process of talking to our early employees and figuring out what
makes our company work and why are there people who are performing well and so on.
So we're going through a rigorous process, but what we are starting to really end up
is core values are just ending up like personalities of Hari and me, which I think at some level
makes sense because it's kind of the company we started.
I think I would have done that way earlier, written it down and make sure that every hire
who came in had to have to absolutely have all of these values embodied and specifically
had an interview focused on this.
I think those are some of the things that I would have changed or that I would change
if I were to start all over again.
Do you think that focusing on culture and your core values is something that clearly
something you wish you'd done earlier?
Do you think it's something that you can do before finding product market fit?
Or do you think your business really has to start working before it's something you should
prioritize?
Yeah, I wouldn't.
My recommendation would be not to do anything except just you and your co-founder till you
get product market fit.
It's hard to exactly define what that line is when you found product market fit.
Is it when you have a paying customer?
Is it when you have 10 beta customers who really love your product?
It's hard to find, but I think it's somewhat of an intuition, okay, customers are willing
to buy this and then go ahead and start to do.
I don't think you should try to over-engineer your company before product market fit.
I know we're running short on time here, so I want to wrap up with just one question,
but we've spent some time focusing in on some of the challenges of being a founder and how
regardless of how big you get, it's always going to be hard.
You're always going to be doing unscalable things and it's always going to feel like
maybe you might not make it to your goal.
What are some of the positive aspects of being a founder and what are some of the ways that
your life has changed for the better, having started a company?
I think you start to realize what you can do as a person.
I never thought I'd be able to go ahead and sell to a customer.
I'm a developer and all I did the whole of my college life at Amazon, everything would
just sit in front of a Mac and code.
I think it gives you a perspective of the things that you can do and frankly, it gives
a lot of confidence that you can go and do things that you didn't know how to do before,
which is a really good confidence that you can try and develop.
For me, having value, delivering value to customers is just my caffeine shot.
When I go and meet a customer and they talk about how great the product is and how much
they've saved time or when I talk to a developer, I was at this school, it's called the Zip
Code.
It's a coding school in Wilmington and there was this girl who walked to me after the talk
and she said, I had no background in computer science.
I worked so hard for the last six months, almost 18 hours straight coding, building
an app, working on Hackernag and I got a job at this bank and it was so great to hear that.
I think that those are some of the things that you get to experience that are the positive
side of, okay, you're adding real value to the world, to the customers.
I think those are some of the positive things that you're able to do.
I wouldn't say this is the last, it is just incredibly fun to work with a smart team.
It's a tautology, it sounds obvious and every founder will probably claim that their team
is the smartest among everyone else.
It is really good when your team tries to push you to become better and you have really
strong conversations of how to solve a problem.
It's very stimulating, it's mentally very stimulating discussions that you can have.
Yeah, it can be tremendously rewarding just to push yourself and to see how far you can
go as a founder, the things that you can learn and the skills that you can pick up that you
never would have imagined you'd be good at.
Then it kind of multiplies it when you surround yourself with other people because you built
out a team of others who are similarly skilled and who are doing the same things alongside
you.
With that, I think we'll end the episode.
It's been really great having you on, Vivek.
Can you tell listeners where they can go to find out more about you and about Hacker Rank?
Yeah, so you can go to hackerrank.com.
I do write blogs probably once every six months now.
It's decreased a lot, it's on arvivek.com and you can email me at hackerrank.com.
I'm on Twitter at arvivek, I'm not active so much on Facebook but happy to help or answer
any questions.
All right, thanks so much for coming on the show, Vivek.
Okay, thank you so much.
If you enjoyed listening to this conversation and you're looking for a way to help support
the IndieHackers podcast, then you should subscribe on iTunes and leave a quick rating
and a review.
It only takes about 30 seconds but it actually really helps get the word out and I would
personally appreciate it very much.
In addition, if you are running an internet business or if it's something that you'd like
to do in the future, you should join me and a whole bunch of other internet entrepreneurs
on the IndieHackers.com forum.
It's basically a community of like-minded individuals just giving each other feedback
and helping out with ideas and landing pages and marketing and growth and other internet
business-related topics.
That's www.indiehackers.com.
Hope to see you guys there.