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

241–250 of 432 posts

Re: Don’t do interviews, do discussions

#241

Post by josephg »

dclowd9901 wrote: post #234
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…

Research shows more diverse teams deliver better results. You’re asking something that can’t be proven though: is this thing that is occurring better than the thing that didn’t occur. We can’t know the answer to that.

> Research shows more diverse teams deliver better results.

FYI, there's plenty of nuance in the research that people like to gloss over. My understanding is that diversity of background / experience improves team performance. But having a diversity of values amongst your team decreases performance.

For example, if you form a diverse team where some people care about profits above all else, and other people care more about doing good in the world, the team will become less effective. Its really hard to use this research when hiring because a lot of values questions (like "who did you vote for?") are somewhere between creepy and illegal to ask.

Source: I used to work with someone who had a PhD in psychometric assessment. People saying "diversity=good" was one of her bug bears. I haven't read the research myself.

Re: Don’t do interviews, do discussions

#242

Post by weq »

smsm42 wrote: post #204
geoduck14 wrote: post #91

Earlier quoted context omitted.

>I've finally reached a point in my career where I have a great paying job and like it well enough, and really don't give a shit what interviewers think. I've interviewed people who have resched this point. It makes for a chill interview. In some cases, the interviewee is overly "chill" and is bored with the challenges described in the job. I prefer to hire people who are EXCITED about the challenges they will face i…

EXCITED may be a bit overdoing it. I'm a geek, have been all my life. I've been programming since I was 13 yo. I still love what I am doing. But I am not automatically EXCITED about everything. I like my job, I care about my craft, and without false modesty, I do my job quite well. But you can't expect me be jumping all over myself at the chance of doing what I've been doing for 30+ years. I'm not a puppy anymore. Th…

Just cause your not excited about every single problem, doesnt mean you are not excited. I a few years under you but would describe myself the same but also as never working a day in my life cause its a passion I had b4 the exchange of money. making computers do sht is only bettered by growing older and seeing them do more sht then we ever thought possible.

Re: Don’t do interviews, do discussions

#243

Post by lordnacho »

Consultant32452 wrote: post #210
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 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.

Same here. I've never had a dud in terms of ability when doing a technical chat interview. People who don't know how things work will hit a wall in this format, it's not actually that easy to BS what your thoughts on the CPP memory model are.

The fear of BSers seems to be what holds people back from this approach though, and I can see that it wouldn't work for certain non technical fields.

Re: Don’t do interviews, do discussions

#244

Post by gamzer »

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…

How is diversity of thought measured?

Re: Don’t do interviews, do discussions

#245

Post by Hermitian909 »

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…

At least in SV, not having the support staff to fully insulate engineers from these kinds of conversations is the norm, not the exception. If you are a run of the mill senior engineer at the highest paying companies in the the area you're expected to be able to have these conversations. My experience is that exceptions are only made for people who are true technical wizards.

Re: Don’t do interviews, do discussions

#247

Post by Hermitian909 »

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…

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 and all the hard technical challenges were overcome, how can you tell?

Or maybe the project did succeed but someone else came up with the idea and led the efforts. I was there for the technical discussions and grilled the lead on why he made the choices he did, so now I can answer your questions and sound like I know what I'm talking about.

Software engineers can make a lot of money, the incentives to game the interview process are high and people attempt it often...

Re: Don’t do interviews, do discussions

#248

Post by christkv »

I usually would do three things. One show me or tell me about some code you are proud off, some code you are not proud off and what your learned from it and finally teach me something interesting that can be code or something else.

I’m looking for confidence, ability to accept making mistakes and improving and finally the ability to convey information in a teachable fashion.

Re: Don’t do interviews, do discussions

#249

Post by Jensson »

Hermitian909 wrote: post #247
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…

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…

Yeah, any member of a team that isn't completely clueless will be able to convincingly claim that all of the achievements done by the team was achieved by the person alone.

Re: Don’t do interviews, do discussions

#250

Post by philbert101 »

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 readme. During the interview we get the candidate to demo the project and any questions that came up in our code review we ask at the stage of execution in the project demo. The interview lasts for 2 hours and we’ve had several rounds of candidates put through this process.

Both we as interviewers and the feedback from candidates has been very positive. The interview ends up being a day-to-day normal experience within the team and this really helps us to gauge the team fit. I think this helps to hire people that compliment and expand our skill set rather than hire people who are basically ourselves.

Post reply on HN