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

281–290 of 391 posts

Re: In defense of coding interviews

#281

Post by kansface »

lapcat wrote: post #254
koonsolo wrote: post #208

Earlier quoted context omitted.

> can easily be detected while you discuss the code being presented. That is possible of course. But if they wrote the code together, and know they will question later, you could teach the other person all the trade-offs etc. I could see myself doing that with a bad developer and get them through such an interview. > Not a great way to start a relationship imho Well, you could take the benefit of the doubt, and then…

> But firing is always such a big decision. Isn't that why managers get paid the big dollars, to make the big decisions? The whole rhetoric of the tech industry — taking risks, creative destruction, etc. — seems to completely fall apart when it comes to hiring, where everyone turns fearful and ultraconservative.

Have you ever worked with a really bad hire? Someone totally incompetent at doing the job? In my personal experience, that person completely tanks the productivity and moral of the entire team. I’ll also point out you are not doing that person any favors by hiring them and firing them one month later (if your org is even capable of doing that). Bad hires are disastrous.

Re: In defense of coding interviews

#282

Post by dlkf »

BlargMcLarg wrote: post #268
dlkf wrote: post #261

Earlier quoted context omitted.

> Do coding interviews work in the actual world in which we live in?" No, fundamentally not. I look forward to seeing you disrupt every major tech company in the world via your superior hiring strategy. > EVEN IF THE CANDIDATE CAN IN FACT PROGRAM JUST FINE. You don’t seem to have thought very hard about what employers are optimising for. Everyone realises that programming interviews produce lots of false negatives. E…

The question is whether they are actually decreasing the number of false positives. So far I've not really seen evidence of this beyond some mere anecdotes. For such a bold claim, one would expect evidence to be readily available. Which becomes even worse when realizing "false positive/true positive" is too binary of a definition for a spectrum such as job performance. And I say this as someone who's in favor of givi…

> For such a bold claim, one would expect evidence to be readily available.

The only way to provide this evidence would be to to conduct an RCT in which you hire some percentage of people who fail the test as a control group. The nascent psychologist in me loves this idea, but it seems unethical, and presumably this is why nobody does it.

But I disagree that we need ”evidence.” It’s flat out obvious. If you give your job candidates a discrete math problem orders more difficult than the usual ticket, you minimize the risk of hiring someone who can’t do the job.

Re: In defense of coding interviews

#283

Post by BeetleB »

vletal wrote: post #160
vorpalhex wrote: post #27

"Can coding interviews work in an ideal world" which is what the article seems to discuss: sure, probably, this seems like a reasonable approach to what that ideal world might look like: a really carefully chosen question and attempting to understand the process the candidate is using to comprehend their skill. "Do coding interviews work in the actual world in which we live in?" No, fundamentally not. Almost nobody i…

I've just interviewed for Google and Meta. In total I went through 8 individual coding interviews. With an exception of one, which was a bit too much like a puzzle, I think the assignments were completely fair examples of what I might experience on daily basis. Not at all tailored to people doing competition style programming, which was what I expected after being exposed to HN for years. I have to say I enjoyed both…

> I think the assignments were completely fair examples of what I might experience on daily basis.

In my experience, you have a lot more than an hour to do it in the real job. And while perhaps 1% of SW folks will deal with in on a daily basis, most will not. I certainly have gone years without needing to use graph algorithms (including even DFS/BFS). And I've needed a BST only once in a decade - and I didn't need to code it, just needed to understand the data structure and complexity to know that "binary_search" in C++ was a superior option than using a map for my use case (even though the complexity is the same).

Some context: At work I recently solved a problem where I had to build a graph (DAG), and do some queries on it mildly efficiently[1]. I did it quickly thanks to wasting time on Leetcode, but no one knew how quick, and people were impressed that I "got it done in less than a day". The reality in most SW work is that whether it takes you a day or an hour to solve this problem, the overall rate of progress will not be impacted.

[1] Mildly efficiently because for the first POC pass, I didn't memoize, and then I got lazy and decided I'd optimize it only after getting a real world data set and seeing if it was slow. It wasn't, even for a decently large data set. The reason? Business logic dictated that the max distance between two nodes did not exceed 8, so from a complexity stand point, you're not increasing the work N-fold by not memoizing, but it's just changing the constant factor.

Somehow, I suspect that in half of the FAANG interviews, had I coded this and argued that the complexity didn't change, I would not get a pass.[2]

[2] Not trying to be cynical: I did argue this for a different problem in a Google phone screen - I had been asked to write some code + data structures to handle an Manager/Report relationship, and the interviewer pointed out my data structure was less than optimal. I countered with "In most companies, the number of employees a manager has under him/her is usually bounded by a small number." Surprisingly, the interviewer gave in.

Re: In defense of coding interviews

#284

Post by kansface »

vorpalhex wrote: post #89
peterhunt wrote: post #82

Earlier quoted context omitted.

What’s the alternative?

You can just ask them to talk about code. You can ask them to compare and contrast some frameworks or languages of their choosing. You can ask them to do design tasks, or just talk about the work the company does and let them ask questions. One of the things I like to do, especially when a candidate is super anxious, is just ask them to talk about a recent project they've done that they like and why they like it.

Lots of people can talk about code but not write it. Way more in fact!

Re: In defense of coding interviews

#285

Post by ubik_ »

lapcat wrote: post #254
koonsolo wrote: post #208

Earlier quoted context omitted.

> can easily be detected while you discuss the code being presented. That is possible of course. But if they wrote the code together, and know they will question later, you could teach the other person all the trade-offs etc. I could see myself doing that with a bad developer and get them through such an interview. > Not a great way to start a relationship imho Well, you could take the benefit of the doubt, and then…

> But firing is always such a big decision. Isn't that why managers get paid the big dollars, to make the big decisions? The whole rhetoric of the tech industry — taking risks, creative destruction, etc. — seems to completely fall apart when it comes to hiring, where everyone turns fearful and ultraconservative.

This, probation time + take home assignment + discussion = I can filter out almost all the false negatives of the take at home. Give the people a choice between take home assignment and more classic code interview so you can dodge problems like shitty home-offices, strange contracts clauses but the real deal remains the probation time.

Re: In defense of coding interviews

#286

Post by BlargMcLarg »

dlkf wrote: post #282
BlargMcLarg wrote: post #268

Earlier quoted context omitted.

The question is whether they are actually decreasing the number of false positives. So far I've not really seen evidence of this beyond some mere anecdotes. For such a bold claim, one would expect evidence to be readily available. Which becomes even worse when realizing "false positive/true positive" is too binary of a definition for a spectrum such as job performance. And I say this as someone who's in favor of givi…

> For such a bold claim, one would expect evidence to be readily available. The only way to provide this evidence would be to to conduct an RCT in which you hire some percentage of people who fail the test as a control group. The nascent psychologist in me loves this idea, but it seems unethical, and presumably this is why nobody does it. But I disagree that we need ”evidence.” It’s flat out obvious. If you give your…

>If you give your job candidates a discrete math problem orders more difficult than the usual ticket, you minimize the risk of hiring someone who can’t do the job.

You're also maximizing the odds they will get bored and feel baited. With all due respect, you could have picked a better example to illustrate your point.

This is exactly why you can't make such bold claims. You're looking at this from one perspective without considering all the variables which go into the workplace equation. So far, the best correlator to job performance is giving people work corresponding to what they will be doing at the work place. For various reasons, this isn't really happening in software development, making people all to eager to grasp at proxies which they swear will do the same thing. Maybe whiteboarding is in line with the day-to-day at FAANGs, but tons of companies ask questions which are not in line with the day-to-day at all. Both vertically and horizontally. It creates dissatisfaction, burnout, bad cultures, sometimes even animosity, as if hiring managers are playing pranks on candidates.

If you're only looking at this from the perspective of "get someone who can do the job", you're going to miss the forest for the trees. As others say, the company is also being interviewed.

Re: In defense of coding interviews

#287

Post by dlkf »

fumeux_fume wrote: post #280
dlkf wrote: post #261

Earlier quoted context omitted.

> Do coding interviews work in the actual world in which we live in?" No, fundamentally not. I look forward to seeing you disrupt every major tech company in the world via your superior hiring strategy. > EVEN IF THE CANDIDATE CAN IN FACT PROGRAM JUST FINE. You don’t seem to have thought very hard about what employers are optimising for. Everyone realises that programming interviews produce lots of false negatives. E…

Maybe you're the enlightened one here or maybe you're just rationalizing an awful and lazy part of the hiring process for many companies.

If anyone actually believed this they wouldn’t complain about it on HackerNews. If it were true that Google, Microsoft, Apple, etc don’t know how to hire programmers effectively, this would be an incredibly powerful observation which you would want to keep top secret while silently beating the hiring market and building the most successful tech company of all time. We’re all waiting.

The reason people are upset by this issue is that it highlights a misalignment in the incentives of employers and job seekers. And with this I fully empathize: job hunting is hell in any industry, ours included.

But we can’t begin to have a conversation about improving the situation until we have a rudimentary understanding of what is happening today. And all these ”Google doesn’t know how to hire smart people” takes are brutally handicapping the discourse.

Re: In defense of coding interviews

#288

Post by bachmitre »

In my 25 years as a developer I have been sitting on both ends of a coding interview a good number of times. One thing I find coding interviews helpful for is to weed out people that apply for a specific job description (e.g. "looking for experienced python developer", who's resume shows 7 years of recent python experience, but that during a simple coding test have problems getting the syntax right.

Re: In defense of coding interviews

#289

Post by ubik_ »

ajross wrote: post #271
vorpalhex wrote: post #27

"Can coding interviews work in an ideal world" which is what the article seems to discuss: sure, probably, this seems like a reasonable approach to what that ideal world might look like: a really carefully chosen question and attempting to understand the process the candidate is using to comprehend their skill. "Do coding interviews work in the actual world in which we live in?" No, fundamentally not. Almost nobody i…

> "Do coding interviews work in the actual world in which we live in?" No, fundamentally not. See, that's just not right. I mean, we all agree there's a hard problem to solve here, right? The world is populated by engineers of widely varying skill levels. It just is. So how do you detect them? Well, the ability to bang out a correct solution on a whiteboard is a verifiably correct way to do that. It may not be optima…

And yet correlation is not causation. And a survivor bias is probably in play here. There are so many more factors contributing to the quality of FAANG work and their performance as businesses. Hell, most of them due to their monopoly-like status could easily use any hiring technique and still rake in tons of $$$. To me the streamlined / cargo cult hiring process seems much more a symptoms of the bureaucratization of these large companies than an actual key to their success.

Re: In defense of coding interviews

#290

Post by peterhunt »

maccard wrote: post #241
peterhunt wrote: post #118

Earlier quoted context omitted.

Algorithmic interviews are huge equalizers. Anyone regardless of their social skills or technical background can show their talent. I’m not talking about people who know technology generally. I’m talking about people who know different technology. The process you’ve proposed, if implemented at, say, PHP shop, will rule out plenty of great .NET developers since the interviewer won’t have the context.

Algorithmic interviews optimise for algorithmic knowledge, not on the job capability. It checks for rote learning and time spent preparing for the interview. Knowing how to implement prefix tree or a hash table shows that you've learned solutions, but not that you can write good code in a team environment. Frankly I'd take a worse engineer that worked better in a team over a 10x that ends up silo'ed in 95% of cases.

That’s not a fair characterization of how most companies (well, at least FAANG) do algorithmic interviews.

A good algorithmic interview does not test algorithm trivia. The question should be solvable with only strong structured thinking and fundamentals.

For example, the much-derided “reverse a binary tree” question (I don’t ask it but I think it’s reasonable) doesn’t really require a ton of algorithm trivia. The data structure can be explained in a few minutes and the problem definition can be made super clear and crisp.

Post reply on HN