Thread by @championswimmer

Over the last 3 years or so I have had to hire/help-to-hire a lot of senior engineers, especially in small to mid startups.

Usually it is in a role where the person would be the main pivot of the team and be responsible for a project.

A thread on what has worked 🧵👇🏼

Over the last couple of years the tech hiring market has become more and more uphill. If you're a small startup, it is super challenging today. There are funded startups who are dying off because they are unable to corner tech talent. So the challenge is very real here.

Small caveat here - these are contextualised a bit towards Android, as that's what I have mostly hired for. Although the same methods and principles I have used for things like Node/Java backend too which has worked out well.

So first of all, I do not get into DSA questions AT ALL. I do not believe good DSA skills are not needed to be a good developer, but the engineers in the market today who *like* going through a DSA process are not looking at small startups, they are aiming for FAANG.

There are ways to judge if a person has good basic understanding of core programming concepts and they will be able to come up with the correct data structure needed at the correct time. Coming back to it. But throwing a LeetCode at people, seems pointless to me for these roles.

The biggest constraint in the hiring market is that the people are many times on notice periods, shopping 5 offers, and closing the process fast is important. So being able to judge quickly is important.
Aiming for >90% correlation b/w round 1 and hire is v. imp. It is possible

How can you take a 30 min intro call, and with 90% accuracy gauge hire/not-hire in this zone ?

Some assumptions -
- this is a mid-experienced person, so 3-4 years under their belt
- this is tech-specific role, not a general SDE hire

What needs to be quickly figured out ?

- growth (how they have evolved in tech in last few yrs)
- pressure (can they get the tech team our of sticky place)
- passion (early startup tech teams should have folks who live to code, not code to live)
- process (soft skills & comm)

Growth:
make no mistake but 2 people working on the same tech, in the same org, for same amt of time could have had orders of magnitude difference in growth, so this is important to judge. past record is usually a strong indicator of future performance in this.

Some questions I definitely ask to figure this out (using real examples so Android specific)

Q. In last 4-5 years which new Android APIs came out you have loved and hated ?

Q. Which architecture/design pattern you had most trouble grasping in your early days ?

Q. If I asked you to make a TodoList app, how'd you have made it 4 years back, how'll you make it today ?

Q. What are some things you like working with Kotlin (vs Java), and any things you hate ?

The idea is simple - have they grown and can they narrate their growth ?

The new Android APIs question itself probably has a >80% correlation to hire/no-hire.

If you're working with this tech for 4 years, and
a) have not kept up-to-date with new developments
b) do not have any strong opinions about them
You really haven't grown.

Pressure:
For this kind of role, getting out of pressure scenarios is an important skill to have. Mind you though you'll find people who have spent 4-5 years at work and haven't yet ever had an opportunity itself to experience pressure, and overcome it.

Some questions I prefer to ask around this

Q. When was the biggest live-production issue you faced ? How did you go about firefighting it ?

Q. Which is the most irritating bug you have come across till now ?

Side note: If you're 3+ yrs exp you should have good war stories

Passion:
Work Life balance is important and personal mental-health is for individuals to find out their own 'zen' for. But what is important is that the pillar around which a small tech team is formed has to be a person who loves the craft.

Judging passion is simple - mostly through the interview you get the vibe, when you've talked with enough people in tech, to get a broad understanding of how passionate they are about their craft.

But some questions go a long to validate this.

Q. What books/blogs/experts in your field you follow ?

Q. How do you stay up-to-date with the latest APIs and libraries ?

Q. Have you explored some adjacent tech stacks ? (For Android folks - RN, Flutter, iOS dev), what pros and cons you saw in them ?

Q. Is there any particular boiler plate you've written over and over and thought of turning into a small personal reusable library for yourself or your team ?

Github profiles are a strong indicator of this too - projects someone has done purely to learn more, if any exists.

P.S. When I say irritating bug - I mean hard to debug, difficult to reproduce, and took a lot of time to find solution or workaround to.

Once growth, passion and pressure are judged for, the biggest mistake I used to do early on, was not focus on process.
No I put a lot of emphasis on understanding that.

Apart from a hire/no-hire call, understand how a person works helps figure where to put them.

If someone ticks all the above boxes, but still doesn't check the process box well, you'll eventually need to pair them up with a EM/TPM/PM who has better processes, and then in a small team, that starts messier.
Process faults rear their head much longer down the line.

Q. What the lifecycle of a feature where you work? From thinking of product, to building and shipping it, who does what ? Which parts you play.

Q. In your team's current process, which part you love the most, which part you hate ?

Q. If you had to lay down a process from scratch, freedom to pick any project management tool, testing, release strategy, and assign key responsibilities to stakeholders like PM, QA, Analyst, Engineers - how'll you go about it ?

Q. How do you do PR reviews ? When you disagree on low-level design, how do you share the feedback, what happens if the feedback is acknowledged but not accepted ?

Q. For a larger product feature, how do you spec out the HLD ? Who all need to be involved in that discussion?

Q. Consider I am your current manager, and we are about to do an appraisal. What are some of your recents achievements and what are your improvement opportunities ? Try to convince me that you deserve a raise as well, based on last few months work

Remember this is the intro call, you wouldn't want to exceed 1 hr on this, aim for 30, wrap in 45.

So we are not going super deep into any thing. Ofcourse if this round is a yes, we need to follow up with at least 1 validation of tech skills (take home project etc).

I am not getting into how to do the deep tech-eval in this thread, maybe for another time (and it is very domain/tech specific too).

Wanted to jot down some of my recent learnings, most of this framework has been built upon a lot of trial and error, and 200+ interviews.

You cannot take this framework and apply directly and get to reduce your hiring process length by half or so immediately.

My initial goal was to first tweak the 1st round without changing anything else, to achieve that >90% or >95% round1 to hire correlation.

Once that point is reached, a confidence builds up in the process, and then the later stages can be cut a bit, number of rounds can be reduced.

Also you know better the 'agenda' of round 2, if you plot a SWOT for these 4 traits (growth, pressure, passion, process)

Sometimes I might feel it is a

growth ✅
pressure ❓
passion ✅
process ✅

after round 1, then I know that the agenda of round 2 is to test more about the pressure side. If no war stories exist, then give a contrived example of pressure scenario and find out etc.