81–90 of 127 posts
Better advice: Leetcode is easy as shit. Suck up your pride and be good at it. You’ll rake in money getting companies to fight over you. I had a $670k offer that’s appreciated to $1m/yr. The company I joined didn’t ask LC, but it still mentally prepared me for the questions I got.
You are absolutely right from your angle, but this is the perfect example of why the process is wrong. Nobody should be using something as trivial as leetcode to choose people they are willing to pay $1M.
> One of the recurring themes is the "leet code" interviews What makes these "shitty" interviews? They're very simple and they test for your ability to write code. They set the bar clearly and you have the ability to study for them with ease. Solve 200 of these problems once in your life and you'll never have an issue again. You'll breeze through all of these interviews. Compared to the alternative, where people ask…
It's a small portion of the interview, the majority of which is asking them to talk about problems, technologies, strategies, etc., but the easy question (not fizzbuzz, but also not a DP question) makes sure they actually know how to code. My general issue with leet code interviews is that once I get nervous, my brain stops being able to come up with clever solutions to problems, and if a problem seems hard, this only compounds.
When you give someone an "easy" question, they loosen up and can actually start thinking creatively. You can see how they think it through, verify their solutions, and talk to you about requirements and approaches. As opposed to giving them a hard problem and watching the amygdala do its thing for an hour.
Earlier quoted context omitted.
What a strangely adversarial comment. In my experience, I can gather more information about a candidate's ability in just 15 minutes talking 1 on 1 with them rather than hours of Leetcode busywork. Funneling candidates through an annoying, needlessly rigid, and blatantly time consuming process is not a good thing, and probably leads to perfectly qualified people being denied; a system that optimizes for 'signals' tha…
So in those 15 minutes, how do you know this person is able to write good code? How do you know they are not just riding on the success of their former colleagues, and bullshitting you with high level responses they heard their colleages talk about? How many people did you interview and hire? Just asking since I interview and hire a lot of people, and find it very hard to asses someones capabilities.
In those few LC questions, how do I know the person can write good, maintainable, reliable software with a team of engineers and didn't just learn for the test?
Yes, interviews are hard. Assessing a persons capabilities is a difficult job.
Earlier quoted context omitted.
I get your point, but if every good/senior developer stopped accepting "shitty interviews" the companies would be forced to change their methods and you would be surrounded by better engineers instead of people who studied a bit to go through a 5 hour interview.
> people who studied a bit Most of the population couldn't do 200 leetcode problems if they were given two months full time one on one tuition and told they'd get $100,000 in cash at the end. That would probably hold true even if you restricted it to college graduates and definitely would for high school graduates. Most people are really, really bad at mathematical thinking. It's more than just a bit of study.
Earlier quoted context omitted.
Still, it's not like any other field of engineering has something equivalent to leetcode. You don't make someone with a civil engineering degree and a resume of bridge building go up to a whiteboard and work out an irrelevant physics problem like it's undergrad again. You don't have an M.D. talk you through a hypothetical surgery. Only in computer science is there this metagame that you have to dedicate unpaid time t…
I've done an EE "leetcode" phone interview with a non-technical HR person asking scripted problems. Didn't get to a real interview, then they foolishly called me back a year later where I just told them not again. This is for a company in the hinterlands of Oregon where you're making a sacrifice to work for the only viable employer in the area.
Better advice: Leetcode is easy as shit. Suck up your pride and be good at it. You’ll rake in money getting companies to fight over you. I had a $670k offer that’s appreciated to $1m/yr. The company I joined didn’t ask LC, but it still mentally prepared me for the questions I got.
You are absolutely right from your angle, but this is the perfect example of why the process is wrong. Nobody should be using something as trivial as leetcode to choose people they are willing to pay $1M.
There’s a class of delusional people who think a GitHub profile is sufficient. Outside of a minority of technical influencers that is absolutely wrong and unreasonable.
Earlier quoted context omitted.
I get your point, but if every good/senior developer stopped accepting "shitty interviews" the companies would be forced to change their methods and you would be surrounded by better engineers instead of people who studied a bit to go through a 5 hour interview.
> people who studied a bit Most of the population couldn't do 200 leetcode problems if they were given two months full time one on one tuition and told they'd get $100,000 in cash at the end. That would probably hold true even if you restricted it to college graduates and definitely would for high school graduates. Most people are really, really bad at mathematical thinking. It's more than just a bit of study.
Most of the population are not programmers.
For someone who already knows a PL or 2, the picture is very different: There are maybe 32-50 questions that get repeated in almost every "code puzzle"-style interview. Which ones these are is actively monitored and curated in several communities.
A person intelligent enough to know a PL, can simply memorize these questions. "Learning for the test" is a standard, and successful, strategy to game predictable test environments. We see it in educational systems using standardized multiple choice tests, why would it be different in bad code interviews?
In interview design there are a lot of trade offs. Coding something quick within an hour? "It's too time constrained." Take home interview question? "It takes way too long for the busy professional who already has a job, and plus, even if we time constrain it, they'll put way more time in. Or they'll cheat with friends." Ask to see previous code? "Many good candidates do not do open source and couldn't tell us what t…
I can't give you enough upvotes. I also do a lot of interviews and hire people, and it's just very hard. Plus, you only know the false positives, but never the false negatives. And I also think that a lot of people who never interview candidates don't realize how many of them can't even code the most basic stuff.
But companies won't do this! Bloody Google of all places had me do a code interview in a Google doc!. Imagine my horror as I am fighting indentation issues while trying to come up with the lc hard solution he asked in 45 mins.
I personally like these questions a lot and I've used them in the past when I was tasked with hiring people because it basically boils down to a few things. One is that people who have a good grasp on algorithms, math or academic problems generally are pretty smart, and you can teach them practical coding skills very quickly while the reverse isn't true. so it's sort of like a IQ test. Secondly it rewards people who…
You should not be trying to approximate an IQ test (and leetcode does exactly this).
While I agree in principle, the average developer is not going to have released and maintained an open source project. Let alone one that is used. Let alone one that is widely used. People in your position should rightfully do that, you have all the leverage. Other people not so much, especially new graduates. I agree that having tasks that simulate the real environment is the goal but we also work in an industry tha…
Making commits to FOSS a general requirement in interviews would exclude a whole lot of highly skilled and experienced engineers, limit the chances of beginners, and lead to loads and loads of BS open source projects that exist solely to fatten resumes.