Don't quite understand why companies ask LeetCode problems in software interviews?

Question

I am seeing so many companies ask LeetCode questions for software engineering jobs. (even for just developing website's front end).

Those questions can be very specific and not something that a typical software engineer would do even in 15 or 20 years. For example, it could be, given 10000 x 10000 slots and dividers of varying height between them, now find out a 20 x 20 region that can trap the most rain water when it rains for a long time.

And there can be 1500 different questions in the LeetCode database.

And the catch is, many programmers can write some code that can find the answer, but the problem usually has some tricks in its problem's property that, somehow you may be able to do it faster.

And researches were done for these types of problems, sometimes for months or for years, as a master or Ph.D. thesis.

But the thing is, programmers, especially programmers who develop the front end of a website, don't do it at all. Not even once in 20 years. So it is not really their real job content.

But the companies like to ask you these questions, and people who read the answers on LeetCode, they may get 5 out of 5 points for the several interview sessions and get into the company, while the person who wrote a correct solution but not the solution that took people months or years to find out before, get a 3 or 3.5 out of 5 only, and they are rejected as a candidate.

And what I found sometimes is: these engineers enter the company, and sometimes they cannot even write correct code. They know standard answers to those questions, but when seeing a real problem, they did not know how to think sometimes -- not as well as the candidates who can actually think well in the interviews.

But companies hire people using this method any way. I do not quite understand how and why it works this way?

Answer 1

I do not quite understand how and why it works this way?

One very important thing to keep in mind is that the goal of a company's hiring process is to hire qualified people, as easily as possible. That's it.

Its goal isn't to make sure that every qualified person gets an interview. The goal isn't to find that "diamond-in-the-rough" candidate, someone with a poor employment history, or who does poorly interviewing, or who forgets things while white-board coding, or who makes mistakes on a timed coding assessment, etc., but would actually succeed at the job.

As long as the jobs are being filled by good hires, the hiring process is working. Are there "false negatives", folks being rejected by the process who are qualified, and who would have succeeded at the job? Of course there are, but from the point of view of the hiring process, that is necessary. A company doesn't have the time to interview every person who applies, so it needs some way to filter applicants so that the folks who actually do get interviewed are very likely to be qualified. If they interview 5 qualified people for a role, it doesn't matter that 5 other qualified people didn't make the cut.

Note that I'm not claiming that LeetCode type questions make the best assessment of a developer, or that a company which uses them thinks that they do either. What I'm saying is that it doesn't matter one bit if these questions have zero relevance to the job. It doesn't matter that you're never going to reverse a string, or find all the prime numbers in a list; all that matters is that the company thinks that its process is working: that it is finding qualified candidates as efficiently as possible.

So if you want to apply to a company that has decided that they are going to use these tests, you have two choices: you can either practice these problems, or you can sit down unprepared and hope you get lucky.

Answer 2

But companies hire people using this method any way. I do not quite understand how and why it works this way?

Some companies do not have experienced engineers analysing the interview process. A failing on their part if they're hiring engineers, but common enough. So HR just searches for some metric to use.

Answer 3

From the point of view of an interviewer: A considerable amount can be learned about a coder's competence from watching how they attack the problem, what assumptions they make, what questions they realize they should ask, and so on. That often doesn't even require that the candidate provide a complete solution. It may feel ridiculous, but there actually is value when it's done right.

This doesn't mean all interviewers are trained to do it this way; some really are just flailing.

Answer 4

Because HR and recruiters quite often are totally detached from reality (as in: delusional of their worth) and do not know anything about IT. They look for SOME metric to measure how good people are without bothering the IT department with a trial workday or something like that.

And that means they need measurable tests. And then you add them and possibly some manager being so stupid (yes, that is the friendly version) that he does not realize that EVERY IT person I have ever met realizes those tests mean nothing - that they promptly use a totally inaccurate test.

This is seriously a case of mass delusion - a whole industry thinking they mean something when everyone doing programming knows they mean nothing.

It gets even better when then those incompetent hires do not get fired again because "it is so hard to get ANYONE from our HR department, we better work with what we have". That then means the Peter Principle is in full effect, the IT group becoming a molasse of incompetent people (as the competent ones will move on), all because HR does a wonderful job with totally non working tests.

Answer 5

Hiring is a time consuming and costly process. Many companies offload that on to recruiters and/or online tech tests.

These style tests are very well marketed.. They claim to provide companies with an almost haste free way to vet candidates, ask the right questions, find the best talent, and that's why companies use them.

If you don't like doing them or don't see how they are relevant, then say so. Ask for a different way to prove your skills. - It doesn't always work, but sometimes it does.

Those questions can be very specific and not something that a typical software engineer would do even in 15 or 20 years.

These style questions are 100% relevant to software engineering and what a "typical" software engineer should know, but completely irrelevant to a lot of niche areas within software engineering such as web development because most of the CS knowledge is abstracted away by high level languages and libraries.

Most of these style tests are focused on software engineering as a whole, not on nice areas, so a lot of companies are giving out CS tests, not web development ones.

(Rather the web development focused ones are often poorly written with a focus on irrelevant CS questions)

Some companies are starting to realise this, but it will take time for things to change.

Essentially companies just want the most economical way to find good candidates, and these style tests promise that, even if they don't provide.

Answer 6

If you have lots of candidates then spending time on each one gets very expensive. So anything that filters 500 candidates down to 10 is good for the company. It's also valuable if you can't be accused of discrimination when you removed 492 candidates. So a "leetcode" question is quite good in this respect.

You can be a good developer without being able to solve that kind of problem, but the ability gives a small hint.

Answer 7

My company does a similar style of questions and I think it is a good way to filter out developers who know how to solve a general algorithmic problem.

For example, it could be, given 10000 x 10000 slots and dividers of varying height between them, now find out a 20 x 20 region that can trap the most rain water when it rains for a long time.

Since this question is incomplete, I will make some assumptions here, but typically with a task like that you can observe the candidate doing the following steps, in about 45 minutes:

• Clarify the question and assert any assumptions made.
• Model the problem
• Come up with an algorithmic solution
• Implement it in a common programming language
• Explain the solution to peers
• React to feedback and adjust the solution

This of course assumes that the candidate works in front of the interviewers and explains their thinking process. All the points above are relevant to the day to day work of a developer.

And the catch is, many programmers can write some code that can find the answer, but the problem usually has some tricks in its problem's property that, somehow you may be able to do it faster.

Usually the "trick" in the questions we ask is something simple as sorting the input before applying the solution to turn a N^2 into an N log N solution, or something like that. A developer experienced in writing efficient code, usually can solve it or will get to the solution after some pointers.

One might argue that this problems don't come every day, but only one inefficient loop written per month, can already make your code's performance considerably worse.

So while this style of questions might not be perfect, it is pretty good in assessing a wide area of skills needed in a software engineer, and so far we have not found anything better.

Answer 8

Partly, there are historical reasons.

The archetypal question of this kind is reversing a linked list. At the time when it was first used for interviews, a lot of programming work involved slinging around pointers and linked data structures, so it was immediately relevant to the job. It was an excellent interview question: one which a competent programmer could do in their sleep, which would stump an incompetent programmer, and which could be communicated to the candidate in a few seconds.

Over the decades since, the work and the interviews diverged.

On the work side, linked data structures got wrapped into standard libraries or even into the languages themselves. Even if the language still has pointers, in most everyday use they're just opaque handles, passed around but not really rearranged in any substantial way. Actually working with pointers and linked data structures is now somewhat of a specialty.

On the interview side, the questions got more esoteric as people started cramming the usual ones, or simply by a process of elaboration.

A couple of decades later, we're at a situation that's the equivalent of interviewing bike couriers with BMX tricks; a related skill, to be sure, but not really relevant to the job.

Not much a candidate can do about that, other than practicing the BMX tricks.

Answer 9

I want to add an answer here, which is to claim, it is not like the company doesn't know what they are doing. They know exactly what they are doing: they want to hire the obedient type, not the smart type.

This kind of pattern repeats in history. 1000 years or 2000 years ago, if you can recite and memorize some ancient script or text, you become the official of the dynasty and in a way, rule other people. The people who did not bother to memorize 200,000 words of scripts, will be ruled by the people who are willing to be obedient to the Dynasty instead. Is that reasonable? Maybe not.

However, if it is not reasonable, will you do it? Will you be obedient enough to do what is unreasonable to obey us? If you obey us, we will have you rule other people. Otherwise, not. The "obeying" is the key here.

The same with education back in Hong Kong or perhaps in UK some years ago. (I am not sure about nowadays). The physics or advanced math they taught you, was not for you to understand. They tell you how to solve something, memorize some equations, for example, the length of a string, and the weight of a lead ball, and now move it 45 degree, and what is its vibration frequency? If you memorize the formula in an exam and give the answer, you get 10/10 points. Otherwise, you get 0/10 points. The ones that can get 95/100 points, gets to go to a university. (Only about 2% of the Hong Kong population could get into a university at that time, because Hong Kong at that time only had only two universities for a population of 6 million people). And when you get into a university, you will become a lead or engineer in a company and get HK$8000 a month. Otherwise, you go in with a high school diploma, and you are a "technician", and get perhaps HK$3000 a month. A lot of people could not afford to study overseas, so it was not like "oh just go to a college" like in the US. (but even in US, look at what happens when you are willing to do Leetcode or when you are not willing to regurgitate optimal solutions).

So memorizing formulas, is that reasonable? Perhaps not. But are you obedient enough to do that? Hong Kong especially had this thing about colonialism. Which is: UK wanted to rule HK (as a colony). It could not use UK people to directly rule Hong Kong people, as people would not like it. So they pay ridiculously high salary to Hong Kong people, say, when they are senior, HK$15,000 every month, so that they obey the government. And then, getting such high salary, they will in turn become the government officials and rule the people. They tend to follow orders because they don't want to lose their job and get into the private sector and perhaps earn only $11,000 per month instead. And so the key point is, the government wanted obedient people. Obedience is the key. As a result, they give you an education system that is what local people called "stuffing a peking duck" and a lot of people thought it was unreasonable, and most everybody were following that system. You see, if you obey, you will be high up in society. If you don't obey, they'd make sure you stay at the bottom.