Here's Why Engineering Interviews Are Not Stupid
(3 Min Read) What signal are tech companies looking for technical interview.
"Substring match. Really? Are you saying FAANG companies are hiring me to implement a substring match?"
"I don't know why they ask for trees/graphs in interviews; you will never use that at work."
"They asked me to implement a backtracking algorithm, and I have never heard anyone in tech companies implement one."
"Binary search. You have to be kidding. Why would I implement them when I can import a lib?"
There are other similar quip responses on the stupidity of technical engineering interviews across the web. And IMO, they are setting a bad reputation for engineering interviews.
I don't particularly care about people's opinions on technical interviews. But I do care about this negative tone it sets. Because it's deterring future engineers from interviewing. And when engineers do interviews, they do it in bad taste.
I have been in the tech industry for ~15 years and have built many complex systems (if I say so myself). One thing I have observed time and again is that complex problems are easily solved when boiled down to fundamental data structures.
Now many will say, "Duh, that's obvious," and yet they'll fail to connect interview questions to complex systems we build as engineers in big-tech.
Let me help with that:
Substring match: Any text-based abuse, violation detection system deployed at Twitter, Meta, Reddit, and News websites, etc. are doing some form of substring match at scale.
Trees/graphs: Any data modeling project can be viewed as a tree/graph. Trie used for a substring match is a tree. DAG is a graph. All extensive data systems and AI is a form of tree/graphs problems.
Backtracking: Anyone working on ML/AI modeling uses some form of backtracking.
Many examples of such data structures are used to solve everyday problems. While they are not directly implemented, complex problems always break down to them.
At this point, many should be convinced that asking about basic data structures in technical engineering interviews is good. But we haven't answered why companies ask these questions. Let's dig in.
What Signals are Technical Engineering Interviews Trying to collect?
That a candidate can identify basic data structures and independently, implement a solution for the given problem.
Let's break down the highlighted parts:
Basic data structure knowledge: This is the foundation. Does the candidate have skills for the job function? Without foundational knowledge, both candidate and company are at a loss.
Implement a solution: In addition to basic knowledge, companies want to check if candidates can apply the said knowledge. Knowledge is useless unless it's put to use. And candidates who practice putting their knowledge to use are the ones who can implement the solution.
Independent: In big tech, you will always have colleagues to help with complex problems, given you can solve simple problems independently. Engineers in tech companies are not incentivized to handhold junior engineers. And thus, being able to work on problems independently is a must.
Often when a candidate fails an interview, one of the three attributes is either missing or not at companies expectation level.
While few candidates can identify the gaps and fix the problem, many are quick to blame the question, the interviewer, the company, the limited time, etc. The candidates in the latter category form a negative opinion of technical interviews. But as they are the most vocal, we end up with an echo chamber of wrong opinions.
I would like to call out an exception. Analytics puzzles asked in the technical interviews are indeed stupid.
In summary, I hope this post helps clarify why technical engineering interviews are not stupid and what they are trying to identify.
If you like this post, you may find my other posts on engineering interviews interesting.