Nobody is talking about lowering the bar, but of putting the bar in the right zipcode.
An extremely high bar of leetcode testing is irrelevant to the actual job, so that's an irrelevant bar.
Nobody is talking about lowering the bar, but of putting the bar in the right zipcode.
An extremely high bar of leetcode testing is irrelevant to the actual job, so that's an irrelevant bar.
You have - companies that settled on this process, who have been able to attract top tallent that has cleared this bar.
You have - employees of these companies that were able to clear the interview bar.
And then you have - people who don't work for these companies, proclaim to have no interest/ability to clear the bar, but claim to have a valid view into where the bar should be.
In the absence of other data it doesn't seem like the last group is likely to be objectively right
These questions have fuck-all to do with the actual work the happens there. Sure, you can usually find someone to tell you how much rainwater accumulates into a random bar chart, but I see as much brain-dead code at the top as anywhere else. As much great code, too, FWIW. Everywhere, the key skills that make for a successful IC are the same, and they definitely don't require implementing splay trees or skip lists from scratch and without references. 99% of the time it's shuffling bits around and using hash maps.
Honestly the people I work with who advocate the hardest for leetcode are the ones who had to grind hard and, evidently, want others to suffer too. As if a sane process would mean their own suffering was in vain.
The bar may simply be "sober enough to understand what it takes to succeed at this task", "committed enough to prepare" and "smart enough to solve them"
These attributes correlate strongly with success, I'd imagine.
Having sat on hiring committees, that's a fair summary. Most people are not very good at interviewing, because it's a weird skill, and nobody actually teaches you how to do it well. There's interview training, but it's incredibly short, and seems like half of it is about legal policy. There's ostensibly shadow interviews, but that tends to be luck of the draw on who your shadower is; most won't put in the requisite time to help coach you in conducting better interviews.
I think big companies like to pretend that leetcode interviewing scales well, without actually doing the time necessary to make it scale well.
> Right now my interview has a wash out coding exercise that is beginner oriented to get the resume liars but other than that it's all systems.
This is 100% what I've gravitated to. The longer I've interviewed people, the easier and easier the actual coding parts of my questions have become.
It's not like there aren't benefits to this process. Once you've buffed up, you're prepared for most major tech interviews. Common formats have their advantages.
That said, this format is just too expensive, and has poor predictive power.
and
// Once you've buffed up, you're prepared for most major tech interviews.
and
// has poor predictive power.
If "acquiring skill X" is broadly valuable (as you're saying in this case) then your ability to work on acquiring it is predictive of your success.
It's not predictive of the traits that mark a successful IC in my experience. I'm talking about areas like project planning, professionalism, large-scale system design, personal ownership, meticulousness, etc. Curiosity. Some of those might tangentially be covered by leetcode but I guarantee you important stuff isn't.
Everyone I've seen to fail, either via PIP or otherwise, has cracked these interviews. I've seen many fail over the years. Even worse, I've seen many whom I know would be strong performers, wash out because they got the wrong DP problem that day. Where's the benefit in a regime like this? The company loses and good candidates lose, too.
Or: "World's best banks and world's best traders have invested in subprime mortgages, they couldn't all be wrong?"
Using skin color for hiring is illegal and immoral and the government does not allow it.
Issuing sub primes is bad for business and blew up pretty quickly.
If asking programmers programming questions is "no different" from the above, which is it: illegal or bad for business?
If they were bad for business, why was it a common practice for so long? Does a business have no clue what's bad for business? Or is it just self destructive?
If "it's an established practice" argument also enconoasses things that are bad for business, and things that are immoral and illegal, maybe it's not a strong argument?
In practical terms the FAANG companies internal processes are horrible and they can’t seem to innovate at all, but as long as they continue to print money there is zero reason to risk change.
https://www.theatlantic.com/business/archive/2013/06/google-...
That's about the microsoft-era actual riddles, like "if you were reduced to the size of an ant and put in a blender, how would you get out?"
Maybe using methods that have nothing to do with the job, just don't lead to good results ?
What I said was basically "google admitted their old method didn't work, here's a link if your interested. I wouldn't be surprised if the new method doesn't work either, and we see articles about that in a few years"
The I "wouldn't be surprised" part comes from both methods actually having very little to do with the job at hand, and therefore I think they would BOTH be bad predictors of performance at that job..
No. Your previous post said they admitted their "leet code" interviews didn't work. leetcode means something specific.
Also I'd draw the opposite conclusion. Sounds like Google is "on it" in terms of evaluating what works and what doesn't. They threw out brainteasers because they didn't work. That suggests whatever they kept does work.
Can't say I agree with your 'on it' conclusion, but I guess time will tell. It took them about 15 years to get rid of the brain teasers (1998 to 2013ish from what I can tell), so if they're consistent we should hear one way or the other in 2028ish :-)
During which time the company grew from what to what?
(Actually, when I interviewed in ~2003, I didn't get any brain teasers. All of the questions where either fundamental computer science knowledge or related to the (SRE) position---although they would all be considered "leetcode" by someone without the background. I was pretty impressed.)
what does that have to do with trying to guess when the next paper might come out? I was just guessing what the publishing timeline might be :-P
But if you're running a startup (target audience of ycombinator), you'd do well to play a smarter game since you can't outspend or out-fame the FAANGs. A big part of that is to have better interviewing practices than they do.