Why interviewing in tech is broken (and the direction it is going)

Written on February 28th, 2021 by Jonathan Tsang

I think interviewing is a largely broken system that is very poorly optimized from both a technical (engineer) and non-technical (recruiter) standpoint. After applying/interviewing for 4 years straight I have some opinions on tech interviews. The fallacy is that the most qualified and most intelligent person is hired but that is rarely the case. I would like to think that I am going up against other candidates in a person against person battle of skills and who can handle pressure, but that simply isn’t true. It is more subjective due to the human nature of assessing interviews, and it is flawed on asking simple algorithm questions, it is based on faith that a person who can present themselves in an interview can work as a software engineer in that team. All those things are not respective of the job, but unfortunately there is no great alternative at this point. The Googles and Facebooks have technical bars so the industry copied it and followed suit.

Equating it to regular jobs, it hinges more on WHO you know rather than what you know. And the referrals can go a long way or straight up be duds. Sometimes job hunting and interviewing just feels like blindly throwing darts at a dartboard.

Problems of interviewing (summarized)

technical recruitment and resume screening is a broken process
the most technical/best/smartest person doesn’t always get hired
memorizing coding questions is a bad practice that still works
the level of perfection expected usually causes false negatives/positives
interviewing is hardly a fair process

The Problems

Recruiters screening

Where do I start. Non-technical recruiters often have no idea what projects or experience mean on a resume. How do they know who to pick? (This is AFTER your resume has been passed through an filtering software)

Technical recruiters supposedly have a little more insight, but even then how many times do you think they check if you full-stack web app posted on your github was not just a copy and paste from some other repo? (which unfortunately has been a real story from /r/uwaterloo) Or that you didn’t just put a bunch of buzzwords to pass through the resume screening software. (Which is actually a valid way of trying to get picked) Those may be overly cynical takes but it’d be easy to create false-positives on a resume for the sake of impressing recruiters. The line between embellishment and exaggeration can often be blurred. In an industry like tech with a lot of different technical skills beyond just “coding”, it isn’t a surprise if you feel screened out in cases where you feel extremely-qualified and vice versa.

The next “easy” cutaway is looking at companies you interned at and basing a person’s worth on that. There are a multitude of issues here. How do you equate impact or actual technical competency from looking at their job/job description. An example of this is a thought process along the lines of “xyz interned at Google, they surely must be a reputable engineer. They passed their technical bar and did an internship there.” We are forced to extrapolate data based on this experience but it doesn’t tell the whole story. We have very little context into how they were hired (were they asked some easy question or something they saw before?) and we have little context in their internship other than what they wrote about it. (did they perform poorly? Were they unable to work in a team setting?)

This is more of a gripe with recruiters not doing their research but I recently had someone on LinkedIn messaged me this:

Hey John,
your internship at Linkedin caught my eye.
We at <COMPANY> are ex-Googlers and ex-Amazon engineers, working on AI powered search to own local shopping.We’re funded and growing.
Nike CF Sephora Ulta are our customers.
I’m looking for super smart engineers like yourself to join our team.

I’m not sure how much more general you can get. He only mentions my LinkedIn internship and then talks about his company. He mentions ex-Googlers and ex-Amazon employees and a fairly vague company description. It probably is a copy-and-pasted headhunt message but this shows the lack of depth into candidate research recruiters sometimes do. If I asked what they liked about my internship at LinkedIn, or why they reached out to me, I’m not sure I’d get a well-thought out answer. They cannot tell my actual impact from just glancing briefly at my LinkedIn profile.

I could go on and on about recruiter and recruitment practices but it can be boiled down to a few statements. A lot of times they have no idea who to look for, who is right for the role, or what makes a good engineer. (You could make the case only software engineer managers can really do those things, but their time is usually spent managing software projects not searching for prospective candidates)

Memorizing questions, question banks, etc.

Sites like leetcode got popular by posting specific lists of questions companies would ask and people then memorizing those specific questions. This always frustrated me because questions like “reversing a linked list” is really dumb but I got asked it 3-4 times. I’ve been asked “coin change” 4-5 times, “kth largest number” 5-6 times, “2d-islands” or some variant 3-4 times, etc.

I did not go out and attempt to memorize these questions. There is a lack of creativity and actual gauging of algorithmic ability in interviews (especially at companies that aren’t big N size). Making questions that test problem solving skills, data-structures and algorithms, and making it the right difficulty is hard. Imagine you make a great question, only for it to be leaked on Glassdoor, Leetcode, or any other derivative. The once novel algorithmic test has now been turned into public domain knowledge. (for those willing to read the questions)

A lot of companies ask textbook questions in interviews hoping to litmus test candidates on this, and feel pressured due to big tech companies following same procedures. (A few are moving away from this, but more on that later). In reality a good startup or smaller-sized company should tailor questions to their business, therefore making questions weed out people who are not interested and also get a much more focused group of people rather than people who know the “Top 100 most common interview questions”.

If everyone is going out and memorizing questions on how to find cycles in linked lists, two sum, and largest contiguous subarray why should companies ask this? They are just playing a game of “what do you know from leetcode” and “what have your studied previously”. It in turn has become to the stages of doing research in the “currently asked questions” and “most updated questions from the question bank” for the highest level of solving success.

I have always said that people should learn the techniques of how to use various data structures and algorithms (arrays, linked lists, trees, graph traversals, sliding window, dynamic programming) and apply them to solve the problems. If you learn the fundamentals you should be able to apply them to different problems

I used to dislike the notion of asking dynamic programming in an interview but lately I’ve had a change of opinion. Dynamic programming questions are hinged on implementation. You cannot implement a dynamic programming question WITHOUT understanding the recurrence relation (which often is not TOO complicated unless the interviewer picks a fiendish problem on purpose). If you memorized a recurrence relation for a question and you don’t actually understand what the question is asking it is evident when you need to explain what is going on. (For the simple DP questions, you may get away with this, but in this day and age people should not even be asking coin change.)

People memorizing questions to pass the bar creates a situation where you potentially have a “leetcoder” joining your team. Great at memorizing niche problems like “how to create a bst from preorder traversal” or “inverting a binary tree” but can they code your web app? Might be a yikes situation depending on their actual aptitude to learn, willingness to work in a team, and ability to grow as a software engineer. In the best case, they practiced and studied knowing that they need to pass the algorithms section to pass the interview.

I always felt it was weird how KMP string matching was a technical report paper in 1970, but it is now expected in some interviews to write it out. If it took extremely smart computer scientists time to create it, why would I regurgitate something I memorized purely for the sake of memorizing it. This is in the same vein of “memorized purely for sake of recall in an interview”.

Asking trivia

Some companies may ask (technical) trivia questions like “what is a decorator in python” or “what are some issues with multithreading in python”. For frequent users of the language this may be fine, but if you mainly work in a different language, tech stack, or even frontend/backend/ios/etc. side of the product these are largely unknown.

This is a personal gripe because I don’t have the greatest memory for things I don’t use frequently so I dislike trivia. I don’t know the exact number for doing a chmod on a file to make it read only. If I did a 4 second google search I could find it out. If I did it often enough I would know off the top of my head. I barely even chmod files, and I don’t do it regularly enough to know the exact bits that are set.

There is a lot of trivia that I do know by virtue of general use. I got asked about “difference in public, private, and protected in objects”, I got asked about “eventual consistency and strict consistency”, etc. Some stuff was from university classes, some was just from using it often enough. If I don’t know a trivia question, like 99% of people, I would go google it and find the answer. Memorizing the trivia would save that time, but in all honesty I am not a huge hash-table lookup that memorizes every bit of information I receive.

Expecting perfection in interviews

Something that I don’t like is that perfection is expected in answers for solving technical interviews. Personally, I have never passed an interview where I did not code a problem (or in the case of multiple rounds, every round) to 100% perfection. Even places where I coded to 100% perfection they would still say no. It transcends perfection in cases, failure or really mediocrity in most cases aren’t tolerated.

One place I got asked 2sum (trivial), 3sum (harder but still trivial), and 4sum (n^3 is trivial. Looking back ok it isn’t even that hard. But interviewer didn’t nudge me in that direction). Since I didn’t solve all 3 questions optimally in 45 minutes I got rejected. That’s tight constraints. I’ve found you need perfection a lot of times in all facets.

It is disappointing because in my opinion someone who gets stuck but prevails and solves it in the end, or is solving organically (as opposed to memorizing a question and having it be perfect on the first try) is more valuable in my opinion, but it is extremely devalued in the interview. If I had a candidate who solved it with struggles on their own in 25 minutes versus someone who coded it perfectly in 10 minutes, at face value you want the person who did it perfectly. My argument is that struggling is a natural step in solving questions because everyday coding is met with unlimited struggles with various constraints (speed of delivery versus depth of implementation, dependency issues, navigating tech debt, etc.) and NO ONE is always perfect.

For an easy question sometimes it should be solved in a short time frame, but I am generalizing it to the point that a real solving experience is more valuable for an interviewer than some quick perfect solve of something (they may have seen beforehand).

Explaining code to interviewer (and making sure they understand)

If an interviewer asks me a question in an interview, I hope they understand the question. (This has unfortunately not always been the case. I have had to argue about heapify runtimes previous)

I try my best to outline my algorithm to make sure the interviewer is on the same page as me. What I deem as important is the understanding that the interviewer knows what I am doing. For one, they are writing my interview notes and feedback so for them to understand is paramount.

In the off chance they don’t understand what is going on, or don’t understand my thought process I try to explain it to them the best I can without losing lots of time.

Due to unavoidable social barriers sometimes people just don’t connect socially. Sometimes, you can think of concepts and code in ways that they don’t think of (or isn’t as natural for their coding style). Some interviewers demand you solve a problem THEIR way. Any other way is suboptimal (when it may not be) or is not acceptable (which is also dumb). When this occurs you are stuck. You are forced to do it THEIR way because they are the interviewer.

Some interviewers want you to succeed and help you…some really want you to suffer

The majority of interviewers I have interacted with were very polite, understanding, and willing to help when I got stuck.

On the off-chance, sometimes interviewers were flat-out terrible. I’ve had ones berate my code, ask me why I was putting comments to explain “production code” (in the interview I perceive it as “interview code” so I will put comments for extra clarity), eating loudly during the interview, make fun of my hobbies etc. If these are the people interviewing me and writing feedback on me, how am I even supposed to show them my skills and what I coded?

This stems from the fact that a lot of interviewers are engineers first and not really “interviewers”. Most of the time your evaluations are on the projects you do and the code you write. Interviewing and hiring can often be an afterthought for some due to the lack of real recognition in their role. It is a little disappointing this occurs since hiring for the company is pretty important (in some cases you may work with this person).

Not really that fair of a system

I am not going to touch on this in depth but the system is not fair and probably rigged against you. You often say “____ got an interview/offer and I didn’t. I’m much more qualified”. Whether or not if that is actually true recruiters make mistakes in who they choose. I’ve seen it happen both ways.

What really needs to be thought about is who are the people a company is trying to hire? Do they want the most qualified candidates or do they want a person with a diverse life story? Are they in 3rd year and above? (Looking at age), or even if they contain visa sponsorship to work in that country (Looking to save money from visa sponsorship). Some places may ask information like this and choose based on criteria like this. They often ask it in online applications.

Parity

There really is no parity in job hunting so people will do what they deem as necessary. Here are some scenarios that you may come across:

Is lying about your accomplishments on your resume (putting different companies or roles) okay since everyone else embellishes their resumes?
Is it cheating on a code challenge if the code was posted on leetcode?
Is memorizing all of a company’s questions using leetcode premium before your interview fair? All I had to do was pay for leetcode premium to see the questions
Can I google the coding question they asked me DURING the interview? They can’t see me if it is virtual. (BIG yikes)

These are huge grey areas people face and there is little to no boundaries other than people’s morals. When software engineer positions and internships are so coveted some people are willing to do whatever it takes to get those jobs. The competition is present in any profession but here so much money is at stake for many people.

The Future of Interviewing

Where I think interviewing is going. Hopefully in a positive direction, but there is still a lot to fix in the very broken process.

Previous landscape

A few years ago the questions being asked at Big N companies are now widely known. Questions have risen in difficulty. No longer does Google ask brainteasers. Topics like dynamic programming are more commonstay. Lesser known topics are being more common like sliding window, prefix sum, disjoint sets, monoqueues, segment trees, etc. (some of the latter ones not so much but we shall see in the future) It is hard to predict what is to come, but I think places like India where the competition is much higher, a lot more people are competing for less positions (compared to US), and talent pool is much higher is going to cause question difficulty to skyrocket.

System Design

I think the future of tech interviews lies in system design questions. They are less memoizable with leetcode and other dedicated problem sites. I think leetcode questions may be obsolete in a few years due to the bar being that “people just memorize questions”. It has come to the point where you just read CTCI (cracking the coding interview) and hope a big name overlaps a question with one you saw in the book.

System design (which even I have areas to improve on it) encompasses object-orientated design, real-world distributed system constraints, and a lot more fluidity for thought from backend and frontend. I think the negative aspect is that it pushes more towards generalists that need to be familiar with all facets, but also means you need to understand how your API webhook fits into the giant landscape of the product. There are negatives and positives to basing cs knowledge on system design more and more. (which becomes more prevalent as your move upwards).

Final Thoughts

These are just my thoughts after doing interviews for a few years. I still fail lots of interviews. These are some key things to remember:

The criteria that companies ask is not standardized. If you fail somewhere just remember there are lots of other places.
Interviewing like life is sometimes daunting, depressing, and tiring. You just need to keep trying to find a place that is a good match for you.

Evermore