Live data from Hacker News

In defense of coding interviews

biggestfish.substack.com

141–150 of 391 posts

Re: In defense of coding interviews

#141
post #88

Other professions handle this via professional qualifications. Architects - and please do contradict me actual architects! - are not tested on their knowledge of basic architectural concepts as part of interviewing at a firm, because that's what the professional qualification is for. You have done the test already. And here's where our industry isn't a "real" profession yet. There are plenty of qualifications one can…

That system is basically "sit through one exam when you're young". This can work fine in something that's not as detailed as coding.

The thing with software is people tend to think of it as something that needs maintenance to stay fresh, perhaps a bit like piloting an airplane.

Airplanes have logs and pilots recertify on an ongoing basis, but software doesn't work like that. Someone might have stopped coding but still have a title.

I'm not saying software actually does work like that, but I'm sure it's a view some people subscribe to.

Re: In defense of coding interviews

#142
post #56

The dirty secret is that it’s never about the coding skills. It’s about the person’s behavior, the way he/she interacts with you. It’s about the person’s culture, tabs vs space, and that kind of things. And it’s mostly about whether you like the person or not. And I think it’s fine. You mainly need to be sure that the person knows what a for loop is, other than that, most people are ok at programming. What really mat…

It is definitely about the coding skills. It is too easy to bullshit and there is a financial incentive to do so. Also many people with genunine 10 years of experience are not too good at coding.

Many people with genuine 10 years of experience do not care for stupid leetcode question they could obviously solve given some quiet and time.

The idea that everything boils down to answering some intro to programming questions quickly is absurd.

Re: In defense of coding interviews

#143

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.

Did they hire people who failed their interviews in order to see how well they did?

Re: In defense of coding interviews

#144

Earlier quoted context omitted.

> or asking obnoxious questions ("Why did you use a foreach and not a for loop?") you should be able to explain why you wrote something the way you did; that's not an absurd ask. perf characteristics of different iteration styles are often significant to the task at hand.

Your problem has gone off the rails if that level of performance difference is important.

If you can't give me the o(n) performance of the algorithm that you just wrote, this is a pretty serious red flag about your ability to understand what you are writing.

Re: In defense of coding interviews

#145
The real reason there are these coding things:

A) SWEs are shit behavioral interviewers in any other way. You are not about to chnage that even if you are google.

B) It is crucial that newcomers be hired by their peers and by their direct manager. This has solid research. People hate it when they get an hire and they hadn't a meaningful part in the decision... The new hire is more likely to fail.

A+B means it is better to have a terrible process lead by SWEs (e.g. coding interviews), than a good one lead by professional recruiters (which will fail, no matter their capabilities and methodology) (and yes, I do believe that without considering A, some non technical recuiters trained at workplace psychology will have a much better success rate without needing any technical interview. They will need someone technical to have a talk with the candidate, but definitely not to ask leetcode etc).

Re: In defense of coding interviews

#146

Earlier quoted context omitted.

Isn’t that going to result in a highly biased interview process? I suspect extroverts will do disproportionately better than introverts, and those who are comfortable in technologies the interviewer is not will do worse than those who share a similar technical background. I also think the skill cap on this sort of question is super low. (I’d put design questions in a different category though)

What process do you think introverts are going to have an equal footing at that isn't take home homework? And yes, people who know technology will do better.. in a technology interview. I suppose I could ask about gardening but that doesn't help much does it?

Sorry, but introverts can do oral exams just fine.

Re: In defense of coding interviews

#147
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.

I can tell you right now I have seen 3-4 principal “architects” who don’t know how to write simple tests and all of them were external hires. I absolutely respect any company that requires experienced hires to at a minimum understand how a hash table works. It’s embarrassing when a principal engineer can’t evaluate a simple design because they’ve been “leading” for the past few years. Finally I know at least one person who gets hired on at a principal level, immediately seeks out forward looking projects with no defined success criteria and leaves a year or two in, rinse and repeat at various companies. It’s a waste of a money (400k-500k/year) and a waste of everyone’s time who has to onboard him.

Re: In defense of coding interviews

#148
post #56

The dirty secret is that it’s never about the coding skills. It’s about the person’s behavior, the way he/she interacts with you. It’s about the person’s culture, tabs vs space, and that kind of things. And it’s mostly about whether you like the person or not. And I think it’s fine. You mainly need to be sure that the person knows what a for loop is, other than that, most people are ok at programming. What really mat…

> You mainly need to be sure that the person knows what a for loop is, other than that, most people are ok at programming.

When I'm interviewing a senior developer that will guide other juniors, they will need to prove they know more than a for loop. They will need to show they understand the underlying concepts and technologies. Else it's a no hire, tough luck.

We also fired plenty of people that weren't up to the quality we expect.

Were are you working? At some government?

Re: In defense of coding interviews

#149
post #6

It is nice to hear a defense of this style since there’s often so much complaining about it, and the tips to mitigate the downsides are useful. Personally I don’t mind a whiteboard session or two during a loop but what’s wild to me is how, especially at big companies, you’re expected to do four or five of these to get an offer. How often do these companies decide “well they understand when to use DFS and they can mer…

> you’re expected to do four or five of these to get an offer.

I agree that this is unreasonable but not for the reason that you mention.

Once you can pass this kind of interview, you can throw me 10 more and I will still pass them.

Re: In defense of coding interviews

#150

Earlier quoted context omitted.

It is definitely about the coding skills. It is too easy to bullshit and there is a financial incentive to do so. Also many people with genunine 10 years of experience are not too good at coding.

It's is also easy to bullshit a coding interview. The problems solved at interviews are just too small to verify code organization skills.

I suppose you never did any interviews yourself. You can't imagine how many people can't even do or know the basics.
Post reply on HN