How to Interview Developers For Your Tech Startup

Startup founders are often reluctant about introducing newer people. They are quite fearful about losing the startup culture. In a way, these fears aren’t unjustified. Newer people not only bring financial burden. They also bring the need to streamline processes. A lot of rulebook writing, space renting and goodies purchasing has to happen even before the first non-founding member is brought on board.

Months go by in this no-hire phase. Once the cash infusion begins, pressure begins to mount from the investors’ side. The magical words like Upscaling and Growth hacking get thrown around the company walls a million times a day.

99 out of 100 times, hiring happens as a result of this hush. No wonder, 99% startup fails — many of them because of misfit implementors hired by confused founders.

While no one can depict a secret formula of what makes an ideal hiring strategy, breaking up hiring into carefully executed steps and avoiding common pitfalls can bring the best available tech talent inside your office.

I already covered how to shortlist candidates for an interview over here:

This post serves as second in the series of startup hiring. Here I will cover how to interview candidates to maximize your chances of hiring success.

#1-It’s Not About You, It’s About Them:

Many founders fall into the trap of singing praises of their great startup vision. In doing so, they often expect the candidate to sing in unison. When he/she fails to do so, blacklisting follows.

Many a time, the candidate himself makes up his mind not to join, even before he exits the premises. I know, because I was that candidate — more than once. I wrote about this mistake in detail, over here:

A developers’ passion for how you want to revolutionize industry X or even his passion for industry X, has very little to do with how he will code to make your solutions better. You don’t need ex-WWE champions to code the wrestling streaming app. For that matter, even the slightest interest in wrestling isn’t required. Don’t even smirk if they are completely inert to any sports talk.

You should nail them about what streaming projects they worked on, though. Even if you are not a competent coder yourself, do some primary research online about the core technical concepts that your ideal coder must know. Throw those terms around. If they don’t take the bait, lead them slowly but surely to the heart of your product where their expertise is needed.

Ask them what problems they solved, ask them how they solved it, ask them how they feel before, after and during that solution process. Ask about their motivations in subtle ways, ask about their turn-offs, do all of them without being judgemental.

Do not dwell on your stories, struggles, and roadmaps unless they specifically ask for it.

Make it about them, not you, and you have already started winning.

#2-Stop Being Judgemental (And Announce It Beforehand):

Do not judge them for their choices. Judge them for the rationale behind their choices.

A lot of startup founders / CTOs have preconceived notions about choices of tech, workflow process, and tools. They ask their candidates about theirs in the interviews, and irrespective of their answers, they attempt to enforce their own beliefs. They start proclaiming how their choices are the only way to make things work, and candidates must love those choices if they want to join.

It is as if they were in search of a platform to do so for ages, and the candidate has descended from heaven just to provide them that. During such an interview atmosphere, no ideas/strategies can come.

Your good candidates will start fearing this might happen during project meetings too if they are hired. Your bad candidates will begin praising your choices to check those boxes that you were trying to cross.

During an interview, your goal is to bring the maximum out of a candidate. Let them open up beyond their school-talk, family background, and hobbies. Let them speak on which framework or library they love, and what made them love it. Make them talk about what project/component/workflow tool they hated, and what was their reasoning.

Most importantly, before making your first question about an opinionated choice, make it clear to them that they will not be judged for those choices, but the rationale behind those choices.

If they love SCM over GIT, fine. But if your team is already comfortable with GIT, you have the right to ask whether they will be comfortable learning GIT soon enough. After all, you need to work together and need to agree on things that must be shared in a work environment.

#3-Do Not Stress Test:

Great products are designed in discussions and created in solitude.

In a time when the mental health of a tech employee is an asset, many startup founders still want to stress test their candidates during an interview.

They believe that unless a candidate can write gargantuan pieces of code during a 3-hour session in front of them, he is useless. They want to monitor how he writes, what references he takes from Google et al when he erases, what bugs he faces and so on.

While observing these factors is justified on a personal level, making it a matter of monitoring is completely absurd. No company makes their coders code under constant monitoring. Yes, there is a thing called peer coding, but it is embraced by programmers’ mutual choices. It must never become a gatekeeper to your organization.

This practice is inspired by leading tech organizations, especially FAAMG. It stemmed from the fact that because their products were used by millions every day, they needed developers to deal with building and tweaking data structures and algorithms. Unless your startup is constantly innovating core software libraries, you may not have to work at that level of software building. Even if you have to do such work, such stress tests may be redundant in onsite/online interviews. You should have screened candidates with relevant Github portfolio to know they are competent enough to write such code. If you failed to see it there, you will not succeed in seeing it in your interview room.

If you have to perform that much forceful evaluation during an in-person interview, it indicates a problem in your previous hiring stage: CV scanning. You must already have evaluated their portfolio and made certain assumptions. In-person/online meetings should only serve towards confirming those assumptions.

Instead of code interviews, you could ask them to explain their approaches on a whiteboard. Ask them to use symbols: blocks to represent data structures, arrows to represent an algorithmic process, flow chart to demonstrate a decision tree.

Make the interview routine more liberal. Minimize their commute by reducing interview rounds, or conduct some of them online. Allow them to leave the chamber in-between‚ or leave them alone for some time. Do not enforce any need to socialize by inviting them for lunch. Make coffee and snacks immediately available. Make them feel at home. At the end of the day, that is what a startup culture is all about.

Always remember: Great products are designed in discussions and created in solitude. Solitude is every coder’s necessity. Do not take away a great coders’ solitude, even during interviews.

Conclusion:

When you invite someone for an interview, having studied their portfolio, your choices are already made. In-person interviews are intended to confirm your choices.

But more than that, they are an opportunity to build connections.

Being a startup founder, you are in for a long-lasting journey. Your developer candidates are not just your potential recruits. They may cross your paths more than you imagine.

Make a lifelong impact while interviewing them. Your present or future brand might depend upon it.