Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In defense of coding interviews

biggestfish.substack.com

Post reply on HN
Print view View original

31–40 of 391 posts

Re: In defense of coding interviews

#31

Post by ilikehurdles »

ma2rten wrote: post #20
tombert wrote: post #13

I used to defend coding interviews, until I had an interview about a month ago, and the leetcode questions came off as kind of insulting. I have a decade of experience, working as a senior and staff engineer at megacorporations, have experience as a research scientist, am in a PhD program for computer science research, but lets just double check that I know how to use a hash table.

But many senior candidates actually can’t code anymore. Also, typically the point of these questions is to see if the candidate can solve a novel problem not if they can use a hash table.

OK. What novel problem is the senior engineer solving using a hash table in a coding interview?

Re: In defense of coding interviews

#33

Post by vorpalhex »

adam_arthur wrote: post #9
xkqd wrote: post #7

Earlier quoted context omitted.

Not for nothing but we have plenty of slow coders that are “low volume” but some of the most diligent and edge case counting engineer’s I’ve ever met. Even then, if the business doesn’t depend on everyone working like a banshee, my team may as well take their time. Even as their manager it’s not my job to lead a death march.

Most growth companies have an endless bucket of work. Somebody who produces 2x at same quality of work is worth 2x the other person, fairly objectively. It's common to find people who produce up to 10x the average. Anyone in a startup or growth oriented company is smart to optimize for these people. The most proficient and fast coders often write higher quality code too, in my experience. People who over index on com…

How do you actually measure 2x or 10x workload while keeping quality the same?

It's _very_ easy to measure how fast it takes a ticket to go from "in progress" to "done" but measuring whether code has bugs, or leads to downtime or is just impossible to parse is a different problem.

If you never need code to be readable or documented I can write it quite quickly. If you want something other humans can have a hope of maintaining, that might take a bit.

Re: In defense of coding interviews

#35

Post by zach_garwood »

ma2rten wrote: post #20
tombert wrote: post #13

I used to defend coding interviews, until I had an interview about a month ago, and the leetcode questions came off as kind of insulting. I have a decade of experience, working as a senior and staff engineer at megacorporations, have experience as a research scientist, am in a PhD program for computer science research, but lets just double check that I know how to use a hash table.

But many senior candidates actually can’t code anymore. Also, typically the point of these questions is to see if the candidate can solve a novel problem not if they can use a hash table.

Ya know, I've heard this repeatedly over the past 15 years, but I've never actually encountered this mythical "senior programmer who can't code." Never worked with one. Never interviewed one. Never met one at a meetup. I think it's just a boogeyman used to frighten hiring managers.

Re: In defense of coding interviews

#36

Post by andreygrehov »

I used to hate leetcode-style coding interviews, but now I don't. The reason for this is a comment from a Google engineer. That comment changed my mind. In that comment they explained the motivation behind asking these type of questions and it all finally clicked for me.

Corporations are not testing your knowledge of algorithms per se. While that knowledge is obviously important, what's more important is how dedicated you are when it comes to reaching a goal. Essentially, they are testing your will power. You know the rules. Can you achieve success and not give up in the middle of the road by skipping, say, Dynamic Programming? They could've tested your level of dedication by asking to bake some fancy cake, but throwing CS-related questions just makes much more sense.

That reasoning completely changed my perspective about algo-heavy coding interviews.

Re: In defense of coding interviews

#38

Post by nowherebeen »

andreygrehov wrote: post #23
esoterae wrote: post #16

Please provide proof that a coding interview makes a statistically significant effect on predicting success in a position, all other things being equal.

If I'm not mistaken, Google has a paper on this, in which there is a statistical confirmation of coding interviews being a predictor of success.

3 problems I can see with this

a) Its like saying a Tobacco company has a paper saying smoking is healthy

b) Google measures things that matter to them. The operate on a scale that 99% of companies aren't. Their predictor of success only applies to companies of their scale.

c) What is their definition of success? And how does it apply to smaller companies less than 1000 employees?

Re: In defense of coding interviews

#39

Post by jussij »

adam_arthur wrote: post #2

The best coding interviews for 90% of tech jobs are ones that are heavy on coding and light on theory. Very few jobs are particularly well served by somebody with strong theoretical foundations, while most are well served by somebody who can pump out high quality code quickly. Yet most companies interview as if they are inventing novel storage/processing mechanisms. Theory is important to understand which tools to le…

> I've had plenty of people crush the theory portion of the interview and be poor performers on the job (slow coding, low volume output)

I think the reason for that observation relates to why these interview tests are generally a waste of time.

Based on the tests that I've seen, they are 'recall lots of useless information' tests. That means it's actually possible to study for these interview tests (if you have the desire) and if you can ace the test by just spending time memorizing answers.

However, 'slow coding' has very little to do with coding and everything to do with problem solving. You only learn how to problem solve through lived experience and many people never learn that skill.

These interview tests generally fail only because they're not actually testing for the skills needed to do the job.

Re: In defense of coding interviews

#40

Post by lapcat »

One reason I'm self-employed now is to avoid this whole flaming hoop audition game. Thankfully my customers don't want to test me. At this point I'm tired of arguing against coding interviews, because the same arguments have already been repeated ad nauseam, and the linked article doesn't seem to me to add anything new. I just don't want to hear about any "talent shortage", because too many programmers are being systematically excluded out of fear of the dreaded "false positive".
Post reply on HN