Jotting few thoughts on interviewing tech leads. I’m involved only in tech leads hiring (not consultants, designers and others), hence this won’t be applicable for all roles.
We haven’t hired a single tech lead since I started interviewing (~ an year). Since we seem to have an high bar for hiring tech leads I’m cumulating my thoughts on the current process and ideas to improve.
Step 1 – HR filters resumes and requests for slots
Step 2 – Round 1 interview. Feedback is passed to HR with a forward or reject decision. If forward proceed to Step 3 else reject the candidate and inform.
Step 3 – Round 2 interview. Feedback is passed to HR with a forward or reject decision. If forward proceed to Step 3 else reject the candidate and inform.
Step 4 – Round 3. Repeat.
Step 5 – Hire.
Repository of interviews
Currently there’s no way to know why candidates are hired or rejected in any of the rounds. This is because information isn’t shared across the board uniformly. Decisions are passed bottom-up. For example: round 1 – accept, round 2 – reject. Interviewer in round 2 gets the information from round 1 interviewer but not the other way. This is the case since several months. This is limiting since interviewers do not know what to look for.
Creating a repository of interviews helps us track the reasons why a candidate is a) rejected: technically flawed, bad fit (what does it mean?), didn’t turn up, pricy for the skills etc. or b) accepted: good fit, technically sound, can manage people well etc. It also allows us to share a central repository of questions.
1 hr interviews aren’t sufficient
One hour interviews are not nearly enough to gauge a person’s skill. One could argue that the reason we’ve multiple rounds of interviews. Without visibility into what (and in what level of detail) the candidate was previously questioned on we risk repeating ourselves for the same candidate and for other candidates.
To save ourselves the trouble there’s an excel template that intends to capture the interview. The result is a quantified document that doesn’t come close to capturing everything from the conversation. It doesn’t capture the description of an interesting project the candidate worked on. Rarely do I get the chance to touch the breadth in Python, JavaScript, projects, responsibilities, situations, databases, architectural choices. Mostly I get a chance to go deeper in at most two technologies.
The alternative could be a supporting sheet that captures more discussion details.
Compensate
We should set a high bar for candidates with longer duration of tasks thereby giving both parties better chance to judge the opportunity at hand. Compensate the candidate for their time and effort.
Note – This content is intended only for Gramener colleagues, thoughts are time and space bound. Posts cannot be reproduced anywhere.
Thrilled to read this, Bhanu!
I’ll work with Sundeep to create a repository of interviews and populate it with recent history.
Would love your thoughts on a few things:
– What do you think of assigning small projects that they work on? These may be paid or not. They may be done independently or collaboratively with us.
– Is a video recording of the interview (with permission) helpful? I recognize that most people won’t go through the full video. But will it give them a feel for the candidate, and plan what to look for?
– What preparation must an interviewer go through? How can we learn from each other on efficient preparation? A checklist, perhaps?
Will be glad to hear others’ comments too.
Thanks Anand!
1. Definitely the way to go. I was hired the same way although I had the benefit of time, not everyone might have it.
2. That’s a good idea, a video with timestamps for specific questions like how we currently do for podcasts will be useful.
3. Generally I prepare a set of questions beforehand from our workflow and after reviewing their resume. We can have a recommended list of questions for all interviewers derived from the interview repository.
Encouraging to read, Bhanu. What you ask for is what I would like to bring in, a balance between how much information to capture, make it accessible and structure it. My though is to pick items in this order – existing information made accessible via reporting, put tools in place to have more information available to anyone required via Web App. Reduce the manual hand shakes we go thru today.
noted Sundeep, do let me know if and how I can help