Great Startups always ask someone who is joining for a reference check. They speak to your previous managers and colleagues. There is no reason why candidates should not do the same. Many startup employees have more opportunity costs than the founders themselves.
I'm surprised by the lack of due diligence which candidates do when interviewing with us. I assume that at least a part of this is that they don't know that they can do this. And second: how to check which startups are worth working with?
Well, first off:
I, Nirant, with the power vested in me by decent human beings who care about their lives, hereby grant you the license to do reference checks at places where you will work.
That out of our way, I'll invest the rest of this post how to evaluate startup teams. I write this with an engineer's context, with early career folk in mind. The mindset should transfer to other functions, but the specific examples will not.
Given that you're reading this, I am assuming you're are a proactive person.
- Pick teams which grow on your strengths
- Pick teams which mentor proactive people
- Pick teams which take pride in promoting people who are young or from similar backgrounds as you
Go where you're a profit center, not a cost center:
For instance, if your strengths are in Natural Language Processing, you might not want to go work for a neobank. Why? Because their moats and growth come from consumer trust and regulation. Your innovation is a cog in the wheel.
When you are interviewing with a team, ask your interviewer
Have they mentored someone recently? Are they mentoring someone for the last few months?
- What are the key accomplishments of their mentees?
- What incentives (direct or indirect) do they have for mentoring others?
- Is the mentee growing enough to inspire/challenge the mentor?
Do they scale by hiring more people or up-skilling employees? What is the balance between these extremes?
- Do they promote internally? If not, ask/learn why?
- Would they back you if you want to learn something adjacaent to your skill?
- What is the state of tooling which acts as safeguards e.g. central platform, data teams, and accelerators in the ecosystem e.g. standardized API configs and deployment across all devs?
(Optional) How many engineers have quit in the last 6 months as a percentage of team size?
How do they design systems? E.g. who makes the final decision? You might not want to work for hero driven or extremely consensus driven engineering teams.
- What does their release cycle look like?
- How do they handle technical debt?
- What are the safeguards (e.g. central platform, data teams) and accelerators in the ecosystem (standardized API configs and deployment across all devs)?
Asking questions along these lines will give you a pretty fair sense of how they think about investing and growing people, as well as how they make decisions. Those are probably the Top 3 on what determines what your experience will be like with that team.
Teams which have communication failures e.g. when you talk to interviewers the company messaging is inconsistent. One person might pitch college pedigree of existing employees. While another person is pitching how meritocratic they are.
Communication failures are easiest to spot. It’s symptomatic of larger problems within the company. When you have a high temperature, you know you are unwell, but you can’t guess why. That’s fine.
If the team does not value hiring, that means the people you work with will neither be effective, nor motivated.
Some of the most common reasons behind inconsistent communication are these:
- leaders are poor communicators of their vision/roadmap
- mid-level managers are poor at executing the vision/roadmap
- they don’t have a sense of what “quality” or skills are needed to accomplish desired goals
There is a motley mix of reasons why communication can be broken. Either way, you don’t want to work with such a team.
And ohh, on startups with condescending recruiters: If someone who is supposed to invite you within the team is not 5-start hospital courteous on call - the odds that they'll be polite & professional when you join are low.
Common Myth: Need to talk to someone from exactly the same role as you.
Better: Anyone who has worked with that team, or close to that team. For instance, do not hesitate to talk about a backend engineering team's skill level from a Data Scientist or Product Manager.
Small teams enable everyone to work closely with each other and have a lot more signal about each other's competence. That means, cross-skill/cross-function bar and ability of competence is quite well understood.
Exception: Someone whose first job was the company you're doing a reference check. Most people seem to have extreme opinions about their first job, atleast till their 3rd or 4th job.
Chai Sutta Story
True Story: I was about to accept an offer from a company but on a whim, I decided to visit their office. Because I was waiting for my hiring manager to come to work, I hung around at the nearby chai sutta place.
I learnt that the CTO had quit, the Engineering Managers were on notice period and other small array of red flags which I didn't see earlier. Worse, they had no one who could mentor me on data science and my hiring manager's strengths were different from ML. I met the hiring manager, and said No. That was a close save.
The best place to learn about a company's culture is the chai-sutta place. The geekier and more engaged they're about work itself, and not bitching about work -- the better off that team is. Nothing sparks joy than joy of creation in a good team.
If not any of these, I guess it'd be a good idea to do a little bit of Linkedin, Github and Twitter stalking. If none of the devs have never done anything impressive on any of these places, the team might just not be that high caliber. I'd wager that these websites capture something like atleast ⅔rd of the top 2% talent.
Present employees in India typically avoid giving anti-referrals. I get why this happens: we like to gossip. That said, there are ways to get enough signal by asking a lot of specific questions. These work best when you've worked for some time (sorry to folks graduating this year):
- What is your typical release cycle? What are the steps? What does your developer tooling look like?
- How do you measure/assess the quality of your software? What metrics define these? What led you to pick these metrics?
- Of the people promoted in last 12 months, why do you think they were promoted?
- I saw on Linkedin that X recently quit to join company Y - do you have a guess on why that happened?
These are all very direct versions, they work for me because I am a little more direct than usual. My friends and juniors, both have used more indirect versions to great effect. The key idea is to get that information, it's less important whether you were tactful in getting it.
Well, there are no right answers to this. For some people, specially those from certain developer communities or good engineering colleges have a wide enough network. They've friends/seniors/juniors in almost every good company worth working with.
If you don't, fret not. Internet is your friend. Tweet to people, find their email id from Github commit messages. For instance, I've had great luck following advice from CTO of Shaadi.com, whom I met over Twitter. And maybe it's finally time to give that 1 free month of Linkedin Premium a try for their inMail.
I've personally had a decent modicum of success with emailing people, simply because developers don't get cold emails from other developers often enough. It's so rare that as long as I don't bungle it up, people do get back to me. Even if it's just to say "I'm busy, but let's talk next week/month".
-- That's it. I hope this quick intro helped you get started on how to evaluate and pick teams worth working with. If you have questions, please feel free to reach out to me on Twitter (or email).
Till we meet again,
Natkhat Nirant
Revised: September 2020. Original 2017 Edition lives here
Get this directly in your inbox by leaving your email id here: