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

Don’t do interviews, do discussions

thinkingthrough.substack.com

Post reply on HN
Print view View original

381–390 of 432 posts

Re: Don’t do interviews, do discussions

#381

Post by b20000 »

alistairSH wrote: post #371
b20000 wrote: post #361

Earlier quoted context omitted.

yeah, and some very competent people have no time or interest in timed coding tests and know that great software is not built that way. if you have been through a CS program you have worked on probably at least 10 projects. and then there are your personal projects. if you have any experience you can talk about at least some of these apart from the stuff under NDA. so, this approach is much better than timed coding i…

if you have been through a CS program you have worked on probably at least 10 projects That's fine for a new graduate, but many of us are decades out of college. What we did then has almost zero relevance to jobs we might seek today.

the same goes for leetcode interviews. the key difference is that you don’t need to prepare to talk about your own projects. or at least much less. and you are probably working on stuff after hours anyway.

Re: Don’t do interviews, do discussions

#382

Post by chresko »

philbert101 wrote: post #250
swman wrote: post #197

I wish I could a 2-3 hour interview where I (or the candidate) showcase one of my projects and explain the architectural details and decisions in addition to showing any cool/hairy/insane code that got the job done. We can discuss those things and see how to improve them, or laugh at the crazy solutions. Honestly how many times do I need to rehearse these dumbass algos (blah blah blah, so I'll optimize for space with…

This is pretty pretty much what I tried to achieve here https://github.com/philbert/take-home-tech-test The point is to have a conversation about a project that the candidate understands well and is passionate about rather than asking them a bunch of questions that we already know the answers to. Before the interview we review the code base and try to understand what it’s doing by the documentation provided in the re…

Red flag test. Vague, no guidance around how much time to spend, no guidance around where to focus from a technical perspective (i.e. build anything/everything), bias towards someone who already has some related code completed. Given the lack of clarity, accurately assessing one candidate vs another would be difficult. It also comes off as lazy.

Re: Don’t do interviews, do discussions

#383

Post by geodel »

efaref wrote: post #374
commandlinefan wrote: post #369

Earlier quoted context omitted.

> It's hard to tell if it's hysterical without knowing the Cost/Benefit for the company I'm always curious how people interview doctors. As bad as getting a bad programmer might potentially be, getting a bad doctor must be exponentially worse, so you'd think they'd have vetting the unqualified folks down to a science by now.

In most countries doctors and other health professionals are registered and licensed, and must submit to strict examinations. Mistakes can also be career-ending and potentially result in criminal prosecution. It's way harder to get hired as a doctor than "do a bit of leetcode on a whiteboard".

Exactly. Somehow there is this impression that software engineers are having it really hard and they face worst job requirements/interviews.

I'd imagine software/IT might be only place where people who have delivered a couple of toy sized, half-assed webapps are now experts commenting on 'engineering challenges' and 'industry trends' with profundity.

Re: Don’t do interviews, do discussions

#384

Post by philwelch »

TrackerFF wrote: post #260
Hermitian909 wrote: post #247

Earlier quoted context omitted.

As an interviewee I'd like this too, but as an interviewer I wonder if it actually has enough signal. One of the problems I've found with these kinds of conversations is that people can plausibly BS quite a bit about projects, or their role in them. Maybe I started a new compiler or something at my company but didn't have the chops for it and the project flamed out. If I lie and said that all my goals were achieved a…

There is a hysteria that's plaguing the world of tech: The fear that incompetent people might "BS" their way to a position. Everyone you talk with, has probably one or two anecdotal stories of such. "Yeah I worked with this CS grad that couldn't even write FizzBuzz" - yet we ignore the hundreds of other that do their work just fine. And this is fought with setting up ridiculous 8-part technical interviews where you'l…

The vast majority of people you actually work with are competent, sure. But the problem with interviewing is that it adversely selects for incompetent people, because competent people are more likely to have jobs and not be currently interviewing.

Re: Don’t do interviews, do discussions

#385

Post by webdood90 »

neverminder wrote: post #379
webdood90 wrote: post #376

Earlier quoted context omitted.

The bias in this approach is obvious. In your mind, you think a candidate "not shutting up" is a green flag, but the reality is you are trying to hire someone who thinks like you. There are a million reasons why this approach doesn't work. Maybe they just don't like talking that much. Maybe they don't like the technology you're discussing. Maybe they just don't care enough to have an opinion on it. None of the above…

> but the reality is you are trying to hire someone who thinks like you. Not really. If someone can present solid reasoning and argue their point well, they don't have to think like me. Three's more than one way to skin a cat. > Maybe they don't like the technology you're discussing. Maybe they just don't care enough to have an opinion on it. You mean the technology they are being hired for? Yeah, hating, not caring…

Oh, well it sounds like you're doing everything right. This also probably scales really well.

Thanks for sharing - hopefully a lot of people will use your anecdotal evidence to impact the way they hire people too!

Re: Don’t do interviews, do discussions

#386

Post by philwelch »

iamsb wrote: post #222

Having unscripted conversations is one of the best way to be swayed by unconscious bias in interviews. Even though this advice sounds awesome, I will be cautious of putting it into practice without thinking through the bias problem. I do remember reading multiple research papers on this, but unable to find them at the moment. From anecdote - In the last company I worked in London, only one team (DevOps) did not follo…

> I do remember reading multiple research papers on this, but unable to find them at the moment.

That’s too bad, because the obvious followup question is whether those papers survived the replication crisis.

Re: Don’t do interviews, do discussions

#387

Post by UncleOxidant »

I just got a development job where there was no whiteboarding, no linked list implementing, no balancing a red-black tree, etc. They just asked me to talk about some of my previous projects that interested them. Maybe things are changing. Or maybe it's as the CTO said to me "it's hard to hire people right now". At any rate, I was pretty happy with this kind of interview.

Re: Don’t do interviews, do discussions

#388

Post by Consultant32452 »

wiseowise wrote: post #252
Consultant32452 wrote: post #210

Earlier quoted context omitted.

This is almost exactly how I hold interviews, except they are usually I've found this technique to be extremely successful. It's possible I may have had some false negatives, but I've never had a false positive. Everyone I've recommended for hiring has been successful.

> I've found this technique to be extremely successful. That's just survivorship bias waiting to explode. Also, they're successful by some arbitrary metric that is applicable only to your company.

It's entirely likely I will one day hit a false positive.

I've been on the hiring team for every employer I've had for the last 15 years and have hired dozens of people.

Re: Don’t do interviews, do discussions

#389

Post by Consultant32452 »

onion2k wrote: post #227
Consultant32452 wrote: post #210

Earlier quoted context omitted.

This is almost exactly how I hold interviews, except they are usually I've found this technique to be extremely successful. It's possible I may have had some false negatives, but I've never had a false positive. Everyone I've recommended for hiring has been successful.

Everyone I've recommended for hiring has been successful. It's possible you're good at spotting good people, and rejecting bad people, but it's also possible that hiring is just easier than you think it is, and most people are capable of doing the jobs you hire for. You have no way to tell if you'd have the same result just hiring people by picking random resumes. Maybe negatives are just rare.

It's unlikely that hiring is easier than I think it is, because I think it's pretty easy. The people who think it's hard are the HN consensus and the large corporations we keep reading about coming up with these convoluted interview standards/metrics.

Re: Don’t do interviews, do discussions

#390

Post by snickerer »

Clubber wrote: post #347
snickerer wrote: post #335

Earlier quoted context omitted.

I am an interviewer for C++ job candidates in the automotive industry. I do a coding task first and a Q&A afterwards — because these are the requirements. I did many interviews. My experience is: I could skip the Q&A completely. Most candidates could answer the questions just fine after reading the Wikipedia article for 10 minutes. In the interview I can see if they already read it or not. But I don't think it matter…

>half of the candidates (with master degrees and 'years of industry experience') fail. If half the candidates with a master's degree in CS are failing your test, that should be a pretty huge red flag to you that your test might have an issue. What question are they failing?

They don't have problems with the questions. They are not able to write a simple C++. And they are applying for a C++ dev job.
Post reply on HN