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

351–360 of 432 posts

Re: Don’t do interviews, do discussions

#351

Post by xyzelement »

Jensson wrote: post #195
xyzelement wrote: post #84

Earlier quoted context omitted.

> I don't think that you can use one as a reliable predictor of the other. It's pretty hard to claim that there's no signal from this kind of interview. Candidate A: was able to have a conversation with me, asked good questions, explained their thinking well, was easy to follow, etc. Candidate B: seemed to not understand what I was saying/asking, his answers were rambling and incoherent, and unless I led the conversa…

All else being equal on paper, the better their social skills the worse all their other skills will be since otherwise the guy with social skills would have had a way stronger career than the guy without and then they wouldn't be equal on paper. The problem is the halo effect here. Candidate A has likely gotten preferential treatment throughout their entire life thanks to his social skills, possibly all the achieveme…

> gotten preferential treatment throughout their entire life thanks to his social skills

First, I am talking about communication skills, the ability to receive and present information.

Second, this skills can be practiced and developed, it's not something you have or don't have. I assume that the person who is presenting well, does it because they put effort into it.

Third, I don't get this "all else equal" thing. I don't have access to their rankings from their old boss, nor do I have reason to expect their old jobs required the same thing my role does. Maybe their boss "did their talking" for them. Maybe someone gave them a spec and they just implemented it without any back and forth. But that wouldn't fly here.

Re: Don’t do interviews, do discussions

#353

Post by jfengel »

kovac wrote: post #231
jfengel wrote: post #60

Earlier quoted context omitted.

The problem with "decent at programming" is that it's often only a fraction of the job. You rarely get formal specifications and clear orders. Nearly everything involves discussion of the user's needs or eliciting the circumstances of a bug. Real programming is very little like they teach in school and even less like coding competition. Being good at programming is great, and mandatory, but if you can't also have a c…

This right here is the kind of company any self-respecting engineer shouldn't join unless they are transparent about the fact that they have issues with their processes/don't have people to deal with these issues that they need your help. If they have a whole arsenal of project managers, architects, product managers, engineering managers, business/product analysts and still give this kind of lousy excuse, I'd probabl…

Project managers, product managers, etc. are still human beings. They can insulate you from the users themselves, but they still rarely turn everything into formally specified requirements. The job still involves a lot of discussions with co-workers, managers, etc. about exactly what it is that needs to be done.

It even shows up in the code. Code will one day be read by another human being, for maintenance, and maintainable code is often more important than mere correctness.

Re: Don’t do interviews, do discussions

#354

Post by nostrebored »

sokoloff wrote: post #349
nostrebored wrote: post #330

Earlier quoted context omitted.

This is dramatically more complicated than it actually is. It does come back to competencies and structures. For instance, at AWS, this boils down to wide technical competencies and leadership principles. Of the nearly 100 interviews I did at AWS, I probably never had two that were very close, just due to people’s resumes, prior experience, and breadth of interests. But, if you wanted to ask the recruiting team to ad…

I wonder how much of the last point is a high tolerance for false negatives? If a candidate is that close to a no-hire, maybe a rational choice is to say “No, you’re welcome to re-apply in N months.”

It was always cited as a legal risk.

Stripe handled this by having an extra interview baked in by default. People who were viewed as no risk hires didn’t have to do it, but the default was an extra interview to cover risks. Because it wasn’t an aberration, it wasn’t giving a candidate preferential treatment.

I honestly think it’s one of the smartest interview loops I’ve seen. I think they are one of the few large companies gambling a bit on the false positive side of things to shave off false negative points. And honestly, I was impressed with the people I interacted with at stripe more than AWS. They’re doing something right.

Re: Don’t do interviews, do discussions

#355

Post by iamsb »

gamzer wrote: post #285
iamsb wrote: post #274

Earlier quoted context omitted.

Lack of diversity of thought is easy to spot IMO. Bigger point is - you should ensure your processes are setup to at least try to achieve the kind of diversity you would like to achieve. Those processes may still fail, just like anything else.

I honestly don’t comprehend this answer. You mentioned unconscious bias in interviews: > Having unscripted conversations is one of the best way to be swayed by unconscious bias in interviews. Yet, lack of diversity of thought is “easy to spot”. Without being swayed by unconscious biases?

You are taking diversity of thought comment, which I mentioned as an attribute of a team and trying to apply to an interview, which is not what I intended. Your interview processes need to ensure that you do not hire based on biases, so that you will have a diverse team.

Also interview processes are not just interviewer protecting against his/her bias, but also against bias of interviewee which seems to be somehow lost in these discussions.

Re: Don’t do interviews, do discussions

#356

Post by neverminder »

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…

You can make it even more generic than that. A rather simple at first glance, but discussion provoking question: "What do you like and what do you dislike about the Technology X?". A good candidate who has experience with the said Technology X would not shut up on this subject. A bad one however will struggle. This is of course provided that you are hiring for some specific stack.

Re: Don’t do interviews, do discussions

#357

Post by nostrebored »

nostrebored wrote: post #330
csydas wrote: post #319

Earlier quoted context omitted.

Sure: https://www.eeoc.gov/employers/small-business/3-im-recruitin... Screen applications consistently. Apply the same standards to everyone applying for the same position. Effectively, you should have the exact same criterion for all candidates for the same position and avoid "on the fly" questions/too heavily customizing it. The legal discussion on all of this has basically boiled down to that you must ensure you'r…

This is dramatically more complicated than it actually is. It does come back to competencies and structures. For instance, at AWS, this boils down to wide technical competencies and leadership principles. Of the nearly 100 interviews I did at AWS, I probably never had two that were very close, just due to people’s resumes, prior experience, and breadth of interests. But, if you wanted to ask the recruiting team to ad…

Reading this again, it was more confrontational than I wanted it to be and lacked details about why I think super structured interviews are a bad idea.

Some of the best candidates I’ve been involved with hiring have been compelling for reasons you’d never get to in a very structured way.

For instance, a candidate who was just out of university. They were very shy about technical topics, and their tech depth wasn’t great. They went to a university in Africa that I knew taught people more stuff that was wrong than right, and they were starting at a disadvantage. To get him out of his shell I asked about things he’d done outside of academics. He told me that he had not done much because he was very busy. Busy with what?

Oh, just starting a real estate investing side business with his family where he’d been responsible for their international expansion into the UK. With no finance background, he’d spent his time understanding the financial, legal and tax implications of their expansion and successfully launched in his third year of university.

And I’d done a bit of finance so we talked about concepts there and he was able to walk me through complex topics in simple terms.

My job for that interview was judging bias for action, curiosity, and diving deep into metrics. He couldn’t show that for tech because he went to a horrible university and had been very busy with other extra circulars.

He apologized to me for spending so much time talking about non tech subjects. And here is the problem: people who are bad at interviewing are punished by rigid processes. There’s a lot of data to show that women and immigrants from certain backgrounds are more reserved on average. You have to be a much better interviewer to pull off a structured interview that lets these candidates shine.

Re: Don’t do interviews, do discussions

#358

Post by cj »

david_allison wrote: post #341
cj wrote: post #332

Earlier quoted context omitted.

> 95% of the code I write is owned by my employer and is under NDA various other privacy / IP laws. True, but would your employer care (if they found out) if you copy/pasted a small portion of code that’s not considered critical IP (like util functions, and an integration syncing records from your backend the Salesforce, or something tangential to the business outside the core product) May technically be breaking you…

> True, but would your employer care (if they found out) if you copy/pasted a small portion of code that’s not considered critical IP What? Yes. I expect I'd be in prison for a few years. Your interview approach selects for people who don't follow their NDAs Sergey Aleynikov went to prison over copying GPL code.

As mentioned in my original comment, if someone isn’t comfortable showing me the source code I simply ask for them to describe how it works, challenges in building it, how they built it, etc.

Re: Don’t do interviews, do discussions

#359

Post by iamsb »

rimliu wrote: post #337
ryandrake wrote: post #229

Earlier quoted context omitted.

> In the last company I worked in London, only one team (DevOps) did not follow scripted interviews. It was the least diverse team, not just in terms of representation, but in terms of diversity of thought. Did this result in poorer job performance for the DevOps team, or any other negative business results that were specific to that team? If not, who’s to say which interviewing method was better or worse? As an inte…

I wonder when will diversity require to also be skill-wise: like it is required to have someone on your team who cannot code at all, just for the sake of bringing "different perspective".

Aren't most teams already fairly multi-disciplinary comprised of product managers, UI/UX, and other skill sets?

Re: Don’t do interviews, do discussions

#360

Post by b20000 »

nostrebored wrote: post #326
twic wrote: post #304

Earlier quoted context omitted.

I do experience-based interviewing, and i have never encountered this problem. The great majority of the time, people are able to talk about anything. Sometimes, there are sensitive parts of prior work, but a candidate can just talk around those bits and focus on the rest. Even if someone had been working somewhere super-secret, if they aren't a junior, they have other experience to talk about. If all your career exp…

I’ve worked at some large companies and would say this is wrong. I can’t talk about most of my best examples because they’re still roadmap items.

it is not less wrong than timed leetcode BS interviews
Post reply on HN