This content originally appeared on Level Up Coding - Medium and was authored by Michael Faber
A pragmatic look at why organizations hire the way they do.
There is a lot of discourse about including leetcode style questions, design style questions, and take-home assignments in software engineering hiring processes. I’m going to dissect the pros and cons of these three things and unpack why organizations might choose to do them.
Hiring Process Goals
First, a little bit about the Binary Classification of interview outcomes. An interview ultimately boils down to one of four possible outcomes.
- True Positive: You hire the candidate, and they succeed in their new role.
- True Negative: You don’t hire the candidate, and they wouldn’t have succeeded in their new role.
- False Positive: You hire the candidate, and they do not succeed in their new role.
- False Negative: You don’t hire the candidate, and they would have succeeded in their new role.
I’ll be using these terms throughout the article.
Naturally, the goal is to create a process that maximizes the number of true positives and true negatives, and minimizes the number of false positives and false negatives. This is how employers think about their hiring processes. They also have to determine whether they want to prioritize eliminating false positives or prioritize eliminating false negatives.
For a large organization that may gets hundreds of applicants for every software engineering role they post on job boards, they will likely choose to optimize against false positives. False negatives are unfortunate, but their applicant pool is so large they won’t have to wait long for a true positive to come along. They likely see this as the lesser of two evils.
For a small organization that may only get a handful of applicants for every software engineering role they post on job boards, they will likely choose to optimize against false negatives. False positives are unfortunate, but hiring a candidate that underperforms or needs more guidance than originally anticipated is okay when the alternative is that the role remains unfilled for months. They likely see this as the lesser of two evils as well.
LeetCode Style Questions
The Good
LeetCode style questions increase the speed of the feedback loop. The candidate either finds the optimized solution or they don’t. If they don’t, the organization can move on early. This optimizes against false positives.
Performance in LeetCode style questions does correlate with technical competency more than a lot of software engineers are willing to accept. If you’re capable of understanding and solving a sophisticated question like “inverting a binary tree,” it’s a quick and efficient indicator that you’re capable of digesting a problem like “how to manage state in a React application.”
The Bad
Smaller organizations have begun emulating the hiring processes of FAANG* companies, without really thinking about why FAANG companies choose to and can hire that way.
This creates angst because candidates feel like this is an unnecessary amount of vetting for a role that doesn’t require the same skill level and doesn’t have the same compensation.
* When I write FAANG, I mean the companies in the acronym, along with any other elite technology organization or unicorn startup.
The Ugly
LeetCode style questions asked in interviews can be so difficult and so far from the day to day of an actual software engineer, the truth is candidates need to study them.
Asking very difficult LeetCode style question favors candidates who have a lot of time to prepare for them outside of their job and familial commitments. Diversity and inclusion can take a hit here. At best, they’re missing out on the feedback and insight that can come from people who don’t fall in that camp. At worst, it impacts equal opportunity.
Design Style Questions
The Good
Design style questions decrease the speed of the feedback loop. The questions are open ended, so the candidate has an opportunity to talk about what they know. This optimizes against false negatives.
They are a decent measure of a candidate’s understanding of software and software development, and candidates don’t really need to study for them.
The Bad
Without the binary of solved or unsolved, they defend against false positives poorly because a candidate can invent a response good enough to satisfy an interviewer. A candidate may not understand how to implement the design they’re describing, the consequences of it, etc.
The Ugly
Asking candidates sophisticated design style questions when they are applying to entry level positions is unfair, especially if their experience is limited to a computer science undergraduate degree and possibly an internship. I don’t think this is a huge problem though.
Take Home Assignments
The Good
With a take home assignment, a candidate is given requirements, a period of time, and access to all of their developer tools to build something to submit or demo to the organization they’re applying for. This is probably the closest thing to real software engineering an organization can include in their hiring process.
The Bad
This defends against false positives poorly. There’s no way to know for sure that a candidate didn’t sit down with their friend(s) to build the take home assignment (not necessarily a bad thing, depending on how you look at it — this still emulates real software engineering).
The Ugly
Doing 6 hours of uncompensated work for the possibility of employment is perceived as unfair by candidates.
Organizations might even use take home assignments as an opportunity to get jobseekers to do work for them for free — which is incredibly unethical.
Conclusion
Organizations use certain hiring practices because they’re trying to be pragmatic about hiring. They analyze the possible outcomes of an interview, and what outcome they want to optimize for or against.
LeetCode style questions, design style questions, and take home assignments all have their pros and cons. What works for one organization might not work for another organization.
Thank you for reading! If you disagree or think I missed something, please leave a comment! I’d love to hear about it!
Let’s Talk About the Software Engineering Hiring Processes was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by Michael Faber
Michael Faber | Sciencx (2022-02-13T22:32:37+00:00) Let’s Talk About the Software Engineering Hiring Processes. Retrieved from https://www.scien.cx/2022/02/13/lets-talk-about-the-software-engineering-hiring-processes/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.