Why Technical Interviews Exist
"LeetCoding" Origin Story
Previously, I spoke about technical interviews. TLDR: Learn LeetCode.
If you aren’t interested in learning LeetCode (data structures and algorithms), your only alternative is a smaller company or startup, where they place greater emphasis on practical experience and personal fit.
Many people complain about the interview process for big tech, because it seems cumbersome and unrelated to daily responsibilities. When will you actually need to create a complex data structure with a highly efficient algorithm within 30 minutes?
It’s more likely that you will spend time doing code reviews, debugging, testing, refactoring, creating documentation, communicating business needs, using Google, reading literature, utilizing existing libraries and frameworks, and so on.
One argument may be that these large companies have already built many products. Many are not looking for someone who can build more products, but instead optimize their existing ones.
But more importantly, they are not evaluating you based on knowledge of the actual algorithm, but instead filtering for specific demographics and testing for specific traits.
2. What Are the Company’s Goals?
According to the Wall Street Journal, 1 in 130 Google applicants get an offer. For comparison, 1 in 14 high school students get into Harvard.
If Google wants to hire 1,000 engineers and they receive 130,000 applications, they need to filter these somehow. (They actually get 2 million job applicants per year, but let’s just use 130,000 as an example).
Suppose 20% of the 130,000 are completely unqualified, and you discard those applications. You are left with 104,000
Now you have 104,000 candidates with more or less an identical résumé. Maybe a Bachelor’s degree in Computer Science, a few side projects, and an internship or two.
How do you reduce this number further?
You can ask DSA questions and trim 104,000 down by 90%, which is 10,400
STILL, even if you evaluated 40 candidates per day, it would take a year (260 working days) to evaluate them all. However, this is far more manageable than 104,000 which would require you to evaluate 400 candidates per day.
In other words, the competition is intense.
2.1.1. Expanding the Qualified Candidate Pool
DSA may be a niche subject, but it’s less niche than asking about, say, Haskell.
DSA is also general and uniform enough that it expands the pool of potential qualified candidates. Every first-year computer science student is exposed to data structures and algorithms early in their curriculum.
And, an interviewer who hasn’t done DSA in a long time can follow along if your train of thought is valid, so you also expand the number of potential interviewers.
If a company were to require something too specific, they would reduce their qualified candidate pool significantly. “Only applicants with n years of Java expertise can apply.” There are fantastic engineers that don’t use Java at all. Not every team in the organization will require Java, either.
And, a good engineer can pick up a different language quickly and look up the documentation on an as-needed basis because they know what they don’t know.
2.1.2. Other Evaluation Metrics Are Unreliable
References? They can lie for you.
Projects? You could’ve copy-pasted something from YouTube.
Take-Home Assignment? You can get help from someone else.
Behaviour? Anyone can say that they are hard-working.
2.1.3. An Efficient Way to Rule-Out Bad Candidates
You can give all of the candidates a timed LeetCode question to do at-home. If they don’t pass, they’re quickly eliminated from candidate pool and don’t waste the company’s time.
Could this be a concern because you could let go of a strong candidate? Yes, but it doesn’t matter. You can quickly remove many bad candidates. For every 1 good candidate that you let go, you also remove >10 bad ones.
Additionally, false positives are much higher risk than false negatives.
In other words, disqualifying a good candidate is less risky than hiring a bad candidate.
A bad hire wastes time and resources with training and team placement.
A bad hire can make your systems worse with bad code, adding problems.
A bad hire makes other engineers more inefficient by hassling them.
2.1.4. You’re In the Right Circles and Network
Do you know people in the industry that are telling you about DSA? If not, why? Are you not interested in the tech industry? Do people not like you?
Are you spending enough time on the internet to know that DSA is important?
Are you self-motivated and resourceful enough to figure out what the interview requires?
Can you do independent research and figure out how to learn DSA? If you can’t, how are you going use Google to do “research” on-the-job?
Are you in school organizations or tech meetups outside of work? If not, why are your extracurriculars not related to tech?
They need to ensure that you have zero hobbies outside of programming.
You’ll be a good slave.
2.1.5. You Can Study, Focus, Work Hard
You’ve given us a blood sacrifice to show your dedication to tech. You decided to spend several months dedicating all of your free time to study DSA, something that you will rarely do in day-to-day professional life.
In addition, you might’ve been a full-time student or employee. You know how to manage your time well to work around the clock.
You’ll be a good slave.
2.1.6. Legal Discrimination
Let’s think about the different kinds of “undesirables” we can filter out with DSA.
Unintelligent: We can’t legally give you an IQ test, but we can give you DSA problems. DSA problems test your ability to recognize patterns, just like an IQ test.
Old: You can’t learn as quickly. You might not know the best resources online because you aren’t as familiar with the internet as a 20-year old. The online discussions are confusing because the format looks weird. Good, they don’t want old people.
Poor: You couldn’t practice DSA because you had to work a job in addition to being a full-time student? You couldn’t afford the prep materials? Too bad. Your parents’ problems are your problems. If they made bad decisions with their finances, you must be a bad decision, too.
Has Family: You have children and can’t focus at home? You need to take care of elderly parents? Not our problem! They don’t matter. Your company is your family.
Neurodivergent: You can’t sit still and focus on LeetCode? You get nervous during time-constrained interviews? Have social anxiety? They don’t want to deal with your ADHD, autism, or trauma.
2.1.7. Avoiding Discrimination Lawsuits
Cultural Fit? Discriminatory.
Take-Home Assignments? Discriminatory.
Qualitative Assessment? Discriminatory.
On-Site All-Day Interview? Discriminatory.
Online, Automatic DSA Assessment? Easy.
DSA interviews are a legal IQ test. Think of the MCAT exam for medical school, LSAT exam for law school, and GMAT for business school.
The LSAT doesn’t test you on law, just logic; similarly, DSA tests you on logic.
When you solve a DSA problem, can you think about that problem in a logical, structured manner and solve it step-by-step? Or do you throw solutions like darts, hoping one will stick?
A bad candidate rushes to code and runs it immediately. This is a huge red flag because it shows that the candidate does not think before they code.
2.2.2. Considering the Whole Scope
Can the candidate think about all of the assumptions, inputs, outputs, and edge cases for the problem?
In contrast, an inexperienced, bad candidate will not consider all the factors of a particular question. The entire system could go down if, for example, an employee doesn’t consider how their function reacts differently to negative numbers or zero.
You’ll need to deal with an employee for at least forty hours per week. Communication is essential.
Can you walk me through how you think?
Are you clear and precise when you speak?
For example, do you know how to ask questions, or will our experienced engineers need to babysit you?
Does the candidate ask relevant questions? Do they know when to ask questions? If you don’t know how to clarify your assumptions, how will people know what you are talking about when you are explaining something to them?
If I give you feedback during the interview, do you pause and take time to incorporate it into your solution, or do you ignore me? If the latter, you likely won’t be a good team player.
2.2.4. Translating Thoughts to Code
When given a word problem, can you think about a solution, then turn that solution into code?
2.2.5. Clean and Efficient Code
What does your code look like? Do you have informative variable and function names? Or is your code unstructured, messy, and disorganized?
Yes, LeetCoding isn’t the best way to interview, but it’s a useful way to interview because of these reasons.
At the very least, we know exactly what we need to do in order to secure a high-paying career, which isn’t the case for the majority of professions.