Earlier quoted context omitted.
The problem is that it might have been true at some point but now there are resources to “learn” for interviews, so currently you will get people willing to grind. Nobody happy with their pay and job is going to grind leetcode. They could just ignore leetcode and ask puzzle problems instead to test ability.
Honestly, being "willing to grind" might be a good thing to target if it's a good proxy for being willing to do the work . However, I agree with the general sentiment that almost nobody is doing the research to ensure their interview process selects for the things they actually want.
Interviews in the Age of AI: Ditch Leetcode – Try Code Reviews Instead
51–60 of 286 posts
Re: Interviews in the Age of AI: Ditch Leetcode – Try Code Reviews Instead
#52People are forgetting why companies these days do Leetcode in the first place. The initial reason why we have Leetcode today is that Google originally determined through their interview research that the smartest candidates were the ones who were best at algorithms. Google wanted to hire the smartest people, not necessarily the best coders, so that’s why their interviews were mostly algorithmic. Of course everyone st…
It’s just a proxy measure for IQ really. They could have handed out Ravens matrices and got better outcomes prediction.
Re: Interviews in the Age of AI: Ditch Leetcode – Try Code Reviews Instead
#53Re: Interviews in the Age of AI: Ditch Leetcode – Try Code Reviews Instead
#54Earlier quoted context omitted.
> runtime complexity has literally never once come up in my life There are definitely different types of programming jobs, but for some contrast: I have never had a job where runtime complexity did not come up as a significant factor somewhat frequently. It really comes down to what you’re doing, but at a certain scale or size of problem you really do need to know about algorithms, data structures, and runtime comple…
In my experience the biggest bottlenecks are in the network. Most optimizations are also very very low hanging fruit because the original code was written by a moron
Re: Interviews in the Age of AI: Ditch Leetcode – Try Code Reviews Instead
#55Earlier quoted context omitted.
There is research into how an interview should be done to find who will be a good or bad employee. Most companies (not just our industry!) don't appear to have even looked at it. (I'm not sure how useful the research is for real world hiring)
Links?
Re: Interviews in the Age of AI: Ditch Leetcode – Try Code Reviews Instead
#56The candidate wouldn't have to figure out what the code does, because there would be a PR description and/or walkthrough video explaining the code.
There wouldn't be any bugs to find, because code reviews aren't a great way to find bugs. The bugs are found by automated and manual tests.
There would be no stylistic feedback to give. The linter already enforced everything enforceable, leaving only things that are a waste of time to fight about.
There's no point in giving architectural feedback, as the architecture was already socialized and agreed upon before the code was written.
Now on to what code reviews are good for. The changeset is probably a small piece of a bigger picture, because the code is being shipped incrementally. The candidate has no comprehension of the bigger picture to weigh in on downstream issues.
The candidate has no broader understanding of the codebase in general, to suggest reusing an existing pattern, or avoiding a common pitfall with a private API.
The candidate can be well-versed in the OSS framework, and suggest better ways to write some particular boilerplate, or avoid a framework pitfall.
I fear an interview structured like this says more about the company than the candidate. If your company's development lifecycle is mature, there's not much a candidate can weigh in on.
The most useful case that jumps out to me is gaining an understanding of the candidate's familiarity with a framework. A contrived diff falling into lots of common pitfalls could cover more ground than having them write something in the framework. But having them write something in the framework shows you a lot more than just their awareness of pitfalls, so I'm not convinced this is better still.
Re: Interviews in the Age of AI: Ditch Leetcode – Try Code Reviews Instead
#57I'm a CTO for a small software studio. We've used mini projects and code reviews in our interview process for years, and it works great. The code review is a great way to explore a candidate's ability to code, and also to communicate their decisions about a piece of code. In the "age of AI", I'm not sure we'll ditch the mini projects. I think testing a candidate's ability to _use_ AI to generate code is an important…
Would you allow employees to subcontract and outsource their work?
No, but I do encourage them to use the best tools possible. :-)
Re: Interviews in the Age of AI: Ditch Leetcode – Try Code Reviews Instead
#58Earlier quoted context omitted.
It’s just a proxy measure for IQ really. They could have handed out Ravens matrices and got better outcomes prediction.
I assure you, they would if they could, but its illegal.
Re: Interviews in the Age of AI: Ditch Leetcode – Try Code Reviews Instead
#59Earlier quoted context omitted.
Would you allow employees to subcontract and outsource their work?
> Would you allow employees to subcontract and outsource their work? No, but I do encourage them to use the best tools possible. :-)
Re: Interviews in the Age of AI: Ditch Leetcode – Try Code Reviews Instead
#60I'm a CTO for a small software studio. We've used mini projects and code reviews in our interview process for years, and it works great. The code review is a great way to explore a candidate's ability to code, and also to communicate their decisions about a piece of code. In the "age of AI", I'm not sure we'll ditch the mini projects. I think testing a candidate's ability to _use_ AI to generate code is an important…
Would you allow employees to subcontract and outsource their work?