Hacker News Reader

I was looking at the Meta interview guide and it says:

> Let us know if you’ve seen the problem previously

and also:

> In your tech screen, you’ll be asked to solve two problems in roughly 35 minutes. Practice coding solutions to medium and hard problems in less than 15 minutes each to help you be ready for the constraints during the interview.

The only way I could solve two problems in 35 minutes is if I've seen them before or it is a variation of a problem I've seen before.

> Let us know if you’ve seen the problem previously

Or just say “I’ve seen this one before” until they get to one you actually have seen before and ace it.

Leetcode is a joke. I’ve hired a dozen or so high quality candidates using a short 2-3 hour take-home. It shows us more than leetcode ever could. And sometimes people take it places I could have never imagined, these are people we move quickly on and they are the highest performers in the org.

people would usually ask for what the 'trick' is and you won't be able to give the correct answer if you lie like that

A lot of the kinds of questions you'd want to skip have no trick. Also, presumably, if the question is to be swapped then they will not demand a full answer before doing the swap.

I think it's stupid to try to judge if someone has seen the question before. The only time it's wrong to have seen the question before is if someone tipped you off to that specific company's questions. I think that most people are not good enough at writing reasonable questions to attempt it. For that matter they are not good at picking reasonable questions for an interview out of a collection of problems either. People often choose problems that are excessively difficult, ambiguous, or even impossible to answer.

You still need to be able to give a few sentence summary of the solution, trick or not and you will need to be able to give an answer that actually matches if you are going to say "ive seen this question before, [implying you know how to solve it]" while you actually have not and are lying.

It doesn't matter if it is 'stupid', or 'wrong', or whatever other cope you want to invent, people will do it and if your caught in a lie because you do not even know the answer to that, you've disqualified yourself immediately and potentially get blackballed as a liar.

If I've caught such an immediate lie as an interviewer, I'd be a bit relieved on some level because I now have a legit excuse to end the interview series early and go do something else and save my coworkers from doing interviews, because for most interviewers, they are chores.

>You still need to be able to give a few sentence summary of the solution, trick or not and you will need to be able to give an answer that actually matches if you are going to say "ive seen this question before, [implying you know how to solve it]" while you actually have not and are lying.

You would probably fail in an interview with me because you assume things that simply not stated. If someone says "I have seen this before" that does not imply that they know how to solve it. They might have seen the question and decided it was not worth their time, or they didn't actually solve it, or whatever. You CANNOT infer that they are lying if they follow up with "I don't know (or remember) how I (or anyone else) solved it." People have fallible memory. In a high pressure situation anyone can get mixed up, misread the question, etc. So, don't be a jerk.

>It doesn't matter if it is 'stupid', or 'wrong', or whatever other cope you want to invent, people will do it and if your caught in a lie because you do not even know the answer to that, you've disqualified yourself immediately and potentially get blackballed as a liar.

It's so trivially easy to get disqualified, that's stupid. If they really push you, you can say "Yeah I think I saw it a long time ago and I don't remember the solution. You decide if you want to switch." And that is probably the truth in most cases anyway. If someone would disqualify me over that then they're not my kind of people.

As for whether it is a "cope" to observe that these questions are counterproductive and pushed by a lot of smug and incompetent copycats, I think it is worthwhile for one's own sanity to recognize that solving leetcode questions is a separate non-work-related skill. Being good at those questions does not make you a good engineer, and vice versa. Yet, in some cases, your future may be decided by these pseudo-academic timed exercises, judged harshly by baboons.

>If I've caught such an immediate lie as an interviewer, I'd be a bit relieved on some level because I now have a legit excuse to end the interview series early and go do something else and save my coworkers from doing interviews, because for most interviewers, they are chores.

I think what you're really saying here is that you would rather hire a good liar over a non-liar, assuming they have equal leetcode skills. Because that's what you are selecting for if you don't allow people to comfortably say "I've seen it before and I don't recall the answer right now."

> using a short 2-3 hour take-home

Where in the process did you give the take home project? As a candidate, I would consider doing a take home project as the final round of an interview, but anything earlier than that and I will reject doing one. 2-3 hours is too much time to spend on one company, unless you’re confident that the company is serious about hiring.

Projects can work great for smaller companies, but are basically impossible to use at larger companies.

We do 3 rounds.

1 quick culture fit one, basically do they even like what our company does? Do they say anything offensive? If not, they continue on.

Then a 2-3 hour take home (this is self-limited on their end). Once it comes back we give a 45 minute technical round that’s focused on really high level questions about technical knowledge and about their take home specifically.

If both of those go well, they go onto the final where we ask work-background questions. Basically trying to understand how they did in recent jobs. Finally if we’re feeling good we call some references for like 2-3 minutes each and unless something comes up (you’d be surprised how often something does) they get an offer!

I think you’re right about the small/big company thing. The candidate needs to have confidence that their take-home will actually be evaluated. This can be helped by guaranteeing an interview round after the take home is done but even still I get the point that this would be hard to trust in larger companies.

This was basically my experience in college too. There was no time to understand something, and tests didn't test your understanding. If you tried to solve a proof for the first time you'd run out of time and fail. You just had to grind homework and book questions until you could shit them out in 5 minutes each.

Unfortunately, employers aren’t hiring people to “understand” anything either. They are hiring fungible human resources who can follow instructions and grid out solutions. It took me years to understand this and I don’t like it, but it’s how most of the industry works.

Growing up I was fed a false idealistic version of college by every college-educated teacher and adult, and it cost me $40000, so the betrayal in academia was felt much more strongly than work.

That's an odd complaint. The time to solve a proof for the first time is when you're doing your homework. The course work is supposed to make you practice until your brain can easily pick up the recurring patterns.

Sure, if the course is very poorly designed or the student is very unmotivated, they may end up just memorizing everything while somehow avoiding understanding anything. But in real life, when someone says "Oh I understand it, just give me thirty minutes to solve it" and others "shit them out" in 5 minutes, it's usually the shitters who are ready to advance to the next level.

> That's an odd complaint.

No it's not. I'll make it simpler. If you know the material really well but haven't memorized the problems, you will test poorly. If you memorize the problems and have no real understanding of the material, you will test well. This is obviously the opposite of what you want to test.

Here is a story about a problem in applying this approach more broadly.

A local tech recruiting company asked our Python user group to try out their new "fun" programming challenge used to evaluate and rank candidates.

We had an hour. I didn't like the problem, so ended up helping and chatting with others in the user group. Then after 45 minutes I realized there was a game theoretical best solution easily implemented using recursion and memoization.

While I was able to implement it in time, it did not win.

Further analysis later showed that the game play was too short to rank any strategy reasonably. More specifically, the winner was strongly based on player order, not strategy.

In other words, the tech recruiting company's new evaluation tool was total bunkum.

I wrote it up and let them know. I don't know what they did with that product.

In any case, it took me more than 35 minutes to solve.

> Let us know if you’ve seen the problem previously.

It was one thing to practice this for hours, and now I have to tell them, yeah I saw this problem, so given me something that I never solved, and have a 50-50 chance of win.

So working at Meta would be like, oh we need an Auth layer, but we have already seen an Auth layer being used, So lets scrape that, and build a new one, but then we are not going to look the spec or the problems from before, because we want to do the same things again.

The thing is, all these arguments can apply to any test you do during an interview. It is always under pressure, and it will always be incomplete. You will never know for sure before you actually hire the candidate.

If the interview for a coding job doesn't involve actual coding, how do you know that the candidate can code? What you may get are people who are just really good at selling themselves. Maybe a good fit for the sales department, but not so much for the technical position you are hiring for.

LeetCode is not perfect, but no test is.

As for the "memorization" aspect. You can certainly memorize solutions. But you can't just memorize every character of every solution and regurgitate it perfectly. You will need to make some generalizations, just to fit everything into your brain, and as you type it back, you will probably misremember something, and have to fix the bug or bridge the gap. Those are useful, real life coding skills.

Do not let the perfect obstruct the useful.

A FizzBuzz coding test - which is also imperfect - will weed out those who cannot code, and without the false negatives from LeetCode.

Programming is far more than writing code. Do you test their documentation skill? Their ability to work with others? To fix someone else's code? To identify and resolve ambiguities in the spec? To estimate development time?

Is the additional time needed for a LeetCode test over a FizzBuzz test worth the time taken from evaluating these other factors?

I actually never did LeetCode interviews, but I did some competitive programming, same idea.

And it tests more useful skills than FizzBuzz. I wouldn't recommend hard questions, as they usually require techniques that are not very useful for most jobs and that you have to specifically train for (ex: dynamic programming). But for easy to medium questions, in my experience, the bottleneck is usually misunderstanding the problem, and simple bugs like typos, off-by-one, reversed conditions, etc...

Understanding of the problem relates the the ability to read a spec correctly, and the ability to identify and resolve ambiguities is related. And if you can fix your own bugs, it also helps when fixing others.

Of course, it doesn't test everything, particularly not teamwork (I mean, it is similar to competitive programming, the opposite of teamwork), but it was never meant to, other parts of the interview can do that.

As for documentation, I think writing skills are important and undervalued. I mean it in the traditional sense, like writing novels. We could have candidates write essays, but like LeetCode, people will complain. I will, because I suck at this, but I understand the value. By the way, I find that LLMs help a lot for this, language models, are, after all, really good at language, especially technical writing that is more formal than creative writing. Of course, the LLM require guidance, but once it gets the technical part right, I find the writing is pretty solid.

It seems in poor taste to respond to someone specifically criticizing LeetCode questions, by using your experience in non-LeetCode evaluations.

I too did competitive programming. A team working together to prioritize from a list of programming tasks which cannot all be completed in time even by the best team is a far cry from a LeetCode interview problem.

There are different kinds of programming competitions. Some are about solving relatively easy problems individually and as fast as possible, which is most of what I did. The best candidates usually can solve all the problems and time determines the winner. Others are about solving hard problems, sometimes as a team, like in a hackathon. I was talking about the former.

I also did a mock LeetCode-style evaluation, which my company made me do as a benchmark. It was a lot like the kind of competitive programming I mentioned. But I don't count it as an experience because it was not a high-stakes, stressful situation. Note that I had no say on the recruitment process, they just asked me and other employees to do the test to see what to expect from someone of our skill levels, it also included some other, more knowledge-oriented questions.

> If the interview for a coding job doesn’t involve actual coding, how do you know that the candidate can code?

LeetCode problems seldom resemble real-life coding scenarios, which in theory is what you are supposed to be most concerned with.

Why not present them with a real problem that you actually had to solve for your business? And ask them to walk you through how they would try to solve that? Perhaps as part of a take-home assignment?

Leetcode test or nothing is a false dichotomy. Accepting it is lacking without attempting to look into alternatives doesn’t seem logical.

>You can certainly memorize solutions

You can most certainly memorize the high level steps to LC problems. In fact I would argue that this is already the status quo. You may still be able to learn how they would approach a problem this way, but if they are good at “selling themselves” they can make all that “seem” real as well.

At a certain point companies prefer employees who can memorize lots of trivial information and perform at a high level while being constantly monitored for adequate performance. Leetcode pop quizzes are excellent tests for this within an hour: POSIWID.[0] Should you work at these companies? Is this kind of employee optimal for company performance at an any given company size? I don’t have these answers.

[0] https://en.wikipedia.org/wiki/The_purpose_of_a_system_is_wha...

My POSIWID guess is reducing market liquidity and dev pay by reducing competition for staff. These companies have been caught for it before. Even though I was pretty close in getting these processes reformed at my previous big tech company and nobody hinted at that.

At this point I think it's a self perpetuating system, like medical residency sleep deprivation or 'accrediation', which incidentally makes changing hospitals a 6 month BS process for any doctor.

A certain segment of engineers voraciously and autistically defend the leetcode interview since they were selected by it and probably like competitive coding and they are exhausting to deal with. The sane reformers eventually give up and leave them to their empire of dirt since nobody gets promoted for changing these things in big tech companies.

Yes pressure affects people differently. Under stress, my communication skills and creativity improves but my mathematical thinking and problem solving abilities decline (slow down).

Creativity gets in the way of leetcode... Leetcode requires focus; you need to recall only the most relevant techniques for the problem, if you're being too creative and see too many possible solutions and you try to identify the most optimal one, it will slow you down and you will run out of time.

I tend to do better if the problems are more difficult with more time given. I'm built for solving difficult problems without hard time constraints. I'm bad at solving easy problems within limited time slots.

I don't try to add any pressure, but going on call will require some resilience from each team member.

As long as you don’t wake me at 3AM to rotate a red-black tree, or find the median of two sorted arrays we should be good

Exactly this. As someone that’s served as an oncall engineer for years now, the skills you need to operate a cluster are completely different from the things leetcode tests for.

I must remember to ask how many times those problems happen in company's code base in next interview. Or whatever they ask. And if it is more than one, ask if they have libraries for it... You know good development practises and all.

Being a smartass typically goes down well in interviews.