This blog is for hiring managers, HR professionals, and startup founders looking to recruit the best tech talent.
At the end of this blog, you should be able to design and optimize your team's tech hiring process. A good process gets the best talent at the best rates, quickly.
Motivation
The average cost of hiring is more than two months' salary for a given position. This can be broken into three major parts:
(i)Breakdown of average hiring costs for technical professionals.
- Interviewing costs
- Shortlisting candidates - 23%
- Interviewing costs - 16%
- Joining costs
- Time taken to join - 8%
- Candidate leaves before joining - 10%
- Onboarding costs
- Background verification - 3%
- Training candidates - 40%
As you can see, these costs cascade. Interviews take 23 + 16 = 39% of the resources required to train one candidate!
Hence, small improvements in the interviewing process lead to significant savings (and long-term revenue) for the company. Investing at the start of the pipeline will give us the maximum returns.
What is a good interview process?
The effectiveness of an interviewing process is measured using false positives and false negatives.
A false positive means the hired candidate is unfit for the role. A false negative means the rejected candidate was fit for the role.
In large organizations, the cost of hiring a false positive is much higher than rejecting a false negative.
But the same is not true for startups! Your pipeline of candidates is limited, and you want to select the most capable person for a role.
At InterviewReady, we research techniques to hire the best software engineering professionals. Below are a set of rules to optimize your hiring.
Rule 1: Ask questions relevant to the role.
Question: Design a centralized logging system for microservices that handles a million requests per second.
Problem:
-
The question tests competencies irrelevant to the given job role.
-
The candidate may not be familiar with microservices.
-
There are open-source solutions that solve this problem already.
Better Question: If you had three machines with hourly log files, how would you trace a request using a request ID?
This question forces a candidate to think in practical terms. There is no "sword of scalability" hanging over their heads while they design a functional system.
You can also evaluate their communication skills and thought processes as they ask you clarifying questions. Coming up with variations of the above question is also easy.
Most importantly, the candidate can demonstrate skills like problem-solving, requirement gathering, design, coding, and testing to an extent relevant to the job. You are more likely to end up with a true positive.
Rule 2: Ask questions that are grounded in reality.
Question: You have a set of islands in the middle of an ocean. Your job is to find the minimum cost of ferrying customers from one island to another.
Problem: Islands? Ferries? What about customers who want discounts? What about ports that only work during the day?
Ah well, none of that matters. The question is intended to test your algorithmic skills.
Better Question: You have a set of users and topics. Build a newsfeed for each user based on their friendships and topic followings.
Don't build a word salad of islands and ferries. Pick a real-world problem, simplify it, and ask.
Rule 3: Look for a practical solution.
Question: Design a service that can sort large files with limited memory.
Problem: Firstly, Rule 1. And second, don't expect the candidate to write 300 lines of code to handle all edge cases.
You are not going to have a rigorous implementation in 45 minutes.
Better Question: Could you explain how large files are sorted in distributed systems with limited memory?
This question makes it clear that you only care about the algorithm and pseudocode for this question. It also clarifies that they needn't dive deep into esoteric details like Big Endian and Little Endian formats.
Rule 4: Do not expect on-the-spot inventions.
Question: Can you find the median of an array in O(N) time?
Problem: If a candidate doesn't know the answer to this question, they cannot come across it during the interview. You are now testing the candidate for prior knowledge (or a Nobel Prize in physics).
Better Question: How would you report the peak, median, and 95th percentile latencies in your system?
This question gives the candidate more room to think, and come up with creative solutions to the same problem. It also helps them think faster because of Rule 2.
Rule 5: Scope your questions to be manageable.
Question: Design an e-commerce website like Amazon.
Problem: The reason most candidates and interviewers would fail this question is because it's ambiguous.
Most of the discussion will be around clarifications and estimations. The detailing of components will be arbitrary, and the interviewer will likely be impressed by someone who thinks like them.
Instead of selecting the best candidate, we now have a new mason for our echo chamber.
Better Question: Design the delivery tracking of an e-commerce website like Amazon.
The problem is now more manageable. The candidate will likely dive deep into notification and tracking systems, instead of order management and payments.
At the end of the interview, you will have scratched the surface of one complex system, which is better than most interview endings.
Rule 6: Test multiple competencies.
Process: The candidate is asked to find the optimal solution to a problem. They are then asked to code a solution.
Problem: We haven't evaluated the candidate's competencies of resourcefulness, collaboration, or coding. We have hyperfocused on problem-solving, which may not be the only competency relevant to the given role.
Better Process: The candidate is asked to a solution to a problem. They are then asked to code the solution.
Their coding skills were evaluated this way. You may ask them how they would test this code, evaluating another set of competencies
After coding, the candidate can verbally explain how to optimize their algorithm further. This process will likely end with a more holistic view of the candidate's capabilities.
Rule 7: Don't guess motives. Clarify.
Assessment: The candidate asked if working from home is possible for the given role. I think the candidate is keen to have a work-from-home role.
Problem: The conclusion may be incorrect. The candidate may be trying to make small talk, they may have a counter-interest (they like working from the office), or they may want to know how the team functions, etc...
Better Assessment: Ask them why! If you have a concern, ask more. You don't want to lose or hire someone without clarifying their intentions.
It will cost you a few more minutes, but the investment will be well worth it.
Conclusion:
Interviews are lab environments. With simulated problems, no access to StackOverflow, no team collaboration, and little scope for mistakes.
In such an environment, it is difficult to measure a candidate's relevant workplace capabilities.
Also, the hiring process of large organizations with planet-level scale does not extend to startups or SMEs. We must align our interview process with our product and organizational goals.
With this in mind, we put forward the seven rules of technical interviewing:
- 1. Ask questions that are relevant to the role.
- 2. Ask questions that are grounded in reality.
- 3. Look for a practical solution.
- 4. Do not expect on-the-spot inventions.
- 5. Scope your questions to be manageable.
- 6. Test multiple competencies.
- 7. Don't guess motives - Clarify.
We hope you get the best hires, at the best rates!
Thank you for reading. If you are looking for technical preparation courses around system design or behavioral interviewing, we offer the best ones here at InterviewReady.