Hacker News Reader

Comment by GuB-42 | Hacker News Reader

What do you mean by "can't do these leetcode problems if my life depended on it".

Because there is a difference between writing FizzBuzz and solving one of those dynamic programming problems that are so common in competitive programming. For the former, I am surprised you can even work without being able to to this, for the latter, you pretty much need special training that is not very useful in most professional settings.

I never took a leetcode style interview so I don't know what is generally expected. If you are expected to do hard problems, it doesn't test much besides your leetcode skills. But easy problems look like a pretty good filter, assuming the stress of the interview isn't blocking you, which is another problem.

View on HN

FizzBuzz != leetcode. You are correct - easy problems are a good filter. After starting with one company I started sitting in on phone screens and candidate interviews and I was shocked at what a lot of applicants didn't know. Actually helped me with my imposter syndrome. I walked away from several interviews feeling like maybe I did know a thing or two!

IME the challenge is that all leet code problems seem easy once you know the answer, in particular because the code itself is often very simple. And so many of the interviewers claiming a candidate cannot do "easy" problems are off-base. This usually stems from not knowing the history of the underlying data structure or algorithm. Interviewers take for granted the things they know, especially once they've asked similar questions a few times.

IMHO I believe the right approach is to either ask from a standard bucket of questions that require preparation and advertise which ones to candidates, or not ask them at all. Asking "only a few really easy ones" is becoming a red flag to me.

It reminds me of the "Jewish problems". Math problems that look simple, with a simple solution, but are actually really hard. It was used in the Soviet Union to deny access to universities for "undesirable" people like Jews. They were given these "simple" tests and their failure was used to justify their rejection.

> a standard bucket of questions that require preparation and advertise which ones to candidates

And what are you testing than? Whether someone can memorize things?

Even though I'm not good at memorizing things every second monkey out there is.

Actually, people relying mostly on memorization for "problem solving" aren't very intelligent in my experience.

Especially in software development you don't want people who can mostly only reproduce things once learned by heart!

No two problem instances are exactly the same. It's all about the context! What is the recommended text-book solution in one case could be the most stupid thing you could probably do in another superficially "similar" case. You want people being able to recognize the difference and act accordingly.

(Of course you need some amount of drones in every company. Especially when your company is big. Not everything needs highly skilled and highly intelligent employees. Also there is only a given amount of adequate people available at all. If you're big you can't be too picky if you want to hire enough staff in a reasonable time frame. But those are problems of really large organizations).

I agree that leetcode easies are good filters.

But what if too many people pass those filters?

Then we move onto mediums.

But what if too many people solve those?

And that is how we reached the current state of interviews.

Reply on news.ycombinator.com