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.
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.
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.
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."
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.
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.
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.
> 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.