Hiring programmers in India

Basic segmentation is key

This post is in beta.

This post is specific to hiring for hands-on programming roles. Your txn rate, org size, tech stack and market isn’t my txn rate, org size, tech stack and market. YMMV.

Hiring enough programmers to support a rapidly growing software product business is very hard in India.

Founders and operators I talk to all report challenges across the hiring lifecycle, from atrocious conversion rates, to candidates who accept offers but don’t join, to candidates who join, but can’t code.

My thesis is that we prematurely fine-grain our segmentation and try to hire a Backend Golang Tech Lead with Experience In Fintech, or a Full Stack Node.js Ninja… and miss the forest for the trees.

I believe the hiring ecosystem creates roles that ignore how programmers work in the real world to build software.

I believe that the recruiter ecosystem is incentivised to drive hiring managers in tech toward ever finer and ever less meaningful segments.

I believe that the segments that matter most to successfully hiring programmers in India never factor into most hiring strategies.

These simple, foundational segments are the focus of this post. Let’s sort out our pipeline for the most basic segmentation first, and then we can talk about hiring devops devs, ruby rockstars and golang gods.

Laying foundations

Let’s lay out the broad strokes that shape the India tech hiring market. There are two axes that affect everything.

Signal vs Noise

The majority of applicants to programming roles in India can’t code.

Love vs Hate

The majority of applicants to programming roles in India hate coding.

This gives us the 2x2 grid you see above. There are 3 useful segments — let’s label them as follows:

1. Loves Coding, Can Code: Segment Yes
2. Hates Coding, Can Code: Segment Maybe
3. Hates Coding, Can’t Code: Segment No
4. Loves coding, Can’t code: This is pretty unlikely, no? :)

For more history on these segments, please take a moment to catch up on ‘Modern Indian Careers’ and ‘We don’t care about tech in India.’

Org implications by segment

Segment No

Any hiring process should filter out Segment No, because (self evidently) they can’t do the job they’re being hired for.

Software product companies that mostly hire Nos will consistently fail to ship software.

Segment Maybe

Segment Maybe candidates may be able to do the job well, but are also going to do their utmost to avoid all parts of the job that involve coding.

Organisations that are predominantly Segment Maybe present rather unique management challenges. Software product companies that hire mostly Segment Maybe will exhibit a cultural disdain for actual programming work. Hands-on coding roles will be at the bottom of the organisational food chain. Growth paths will involve moving away from coding roles, usually into people management. Tech debt will be rampant and poorly managed, and be a severe impediment to scaling the system to serve more customers.

When faced with the rapid growth that successful software products experience, such organisations run the risk of folding under the pressure. This usually manifests as lost business due to highly visible production issues and downtimes, an abrasive high-pressure work culture and extremely high employee churn rates among delivery roles like engineering, design and product management.

Segment Yes

Segment Yes is easily the most productive and impactful developer on the market, but is as much a management challenge as Segment Maybe (though for entirely different reasons). Folks in Segment Yes are extremely scarce on the market, and consequently, expensive.

Most Segment Yes candidates I’ve met are self-taught and don’t have a formal CS degree. Those that do are still self taught, because that’s the state of our education system — but that’s a story for another day.

It is very hard to design and operationalise an interview process that can distinguish between Segment Yes and Segment Maybe candidates, especially for mid and senior roles.

Segment Yes teams scale really well until you reach a headcount of 80–100 and start needing to actively people manage teams, because building up effective people management capabilities to sustain increasing headcount can be truly challenging.

Starting Segmentation

Segment Yes programmers have differing needs and preferences based on their area of specialisation, and it’s important to understand them as a prerequisite to sourcing and hiring them.

In order to operationalise this as a hiring process, it’s important to build up a clear profile of what Segment Yes programmers look like for your industry.

Getting started

Here’s a simple set of questions to get you started toward this goal.

1. Identify programming domains: What kinds of programming problems are you solving for? Be wary of sticking exclusively to how recruiters, job postings and the hiring market in general defines roles and skills — they’re usually uselessly ambiguous or just plain wrong. Take the time to find people who have worked in these domains and talk to them to understand the work better. Don’t talk just to the devs — also talk to PMs, designers and other functions in that industry. Build up your own job definitions based on this research, then map them to popular roles in the market. There is no consultant I have come across in the India market who can help you with this — you have to just do it yourself.
2. Model skill ladders: Who are the best programmers in the world in that domain according to industry opinion? What external attributes does the industry flag as indicators of capability? What is a reasonable expectation in terms of output from junior, mid and senior programmers?
3. Size the market: How many programmers of the kind you need are available in your key hiring markets at junior, mid and senior levels?
4. Understand diversity: How diverse is the candidate pool across skill levels?
5. Understand pricing: What does compensation look like across the markets you’re hiring in, across skill levels? Is the comp growth linear or non-linear as seniority increases? Don’t forget to keep a broad definition of compensation (cost of living etc. etc.), and to factor in freelancers, because in some markets many of the best devs gravitate toward consulting rather than employment.

Building Trust

Once you understand the market, you need to figure out how to trust the individual. It’s important to establish more nuanced sources of transitive trust than simply academic pedigree or prior employers because otherwise you end up with predominantly Segment Maybe candidates.

1. Find sources of accreditation: In almost every other profession your origin story is your college and degree. Here colleges and degrees alone create a woefully biased picture. A process that exclusively looks at college and degree will reject all the programmers who learned to code outside of college — which is often the majority of the candidates in Segment Yes.
2. Understand the origin story: To build a pipeline of candidates, understand the channels that helped good programmers in their journey and are therefore great ‘places’ to source. Learning to code is hard, and there are certain common channels that people who succeed would have followed. It could very well be a specific college or degree, but it could equally well be a local programming meetup group, an open source project, a government grant, a programming competition or a corporate program like Google Summer of Code that is the driving force in creating more programmers in that area of specialisation. Figuring out where they come from is essential to building a hiring pipeline.

The picture you will build up as you answer these questions will allow you to both position your hiring brand as well as design acquisition processes that will be far far more effective in converting.

Sourcing and Operations

Once you have your profiles for Segments Yes, Maybe and No for your industry sorted, our challenge is to use them to address the firehose of incoming applications. Start by listing out key signals for each, then organise these into filter/select signals.

Filter signals tell you that a candidate does not meet the minimum level of skills needed for the role. If a candidate can’t code, for example, then even hygiene criteria aren’t met and the candidate should be rejected. Filter signals are best used to identify and reject Segment No candidates.

Select signals tell you that a candidate possesses the desired level of skills and the right motivation for the role. Select signals can be used to distinguish between Segment Maybe and Yes candidates.

List the Filter and Select signals that you are looking for in each stage of the hiring process, from resume sourcing to initial calls to face-to-face interviews.

Design these signals into the questions in your interview loop — I’m personally a fan of the Kahneman approach — and you are good to go.

Scaling Operations is Hard

I’ve built tech hiring pipelines several times over now, and the one thing I’ve consistently underestimated is the rigour needed to scale operations so that candidate experience is sustained. What works at 5 hires per month won’t work at 10, let alone 100.

A simple example was feedback for candidates. This is something that happened naturally when hiring at < 5 engineers per month — interviewers would routinely engage the candidate and give them feedback at the end of the hiring process, irrespective of outcome. As we scaled to ~10 hires per month, then ~50 hires per month, the original system simply broke down and candidates stopped getting feedback, often even when they asked.

Scaling operations is a first class problem. Treat it as such.

Win the Fence Sitters

There are always lots of Maybes who can be converted to Yeses with the right opportunities, work environment and mentoring support.

A lot of people end up hating coding simply because done wrong, it is just another impossible, frustrating job with deadlines and a pissed-off boss attached.

Done right, building software can be a deeply rewarding process, and can convert many Segment Maybes to Segment Yes.

In Conclusion

Recruiting programmers in India comes with many challenges, but the most common pitfalls stem from a tendency to hire candidates who can’t code, or hate coding, or both. This is because of gaps in segmentation of the hiring market at a foundational level.

Building these segments out requires 101 product management techniques — building out personas and researching the signals that tell different personas apart, and then designing the interview loop based on this research.