Don’t do interviews, do discussions • Hacker News Board

Re: Don’t do interviews, do discussions

#301

Post by pallavkaushish » Mon, Nov 08, 2021, 9:54 AM UTC

iamsb wrote: post #232

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…

> 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? It did. And even if it had not in this particular case, it will hurt the company in the long run. There is not even a shred of doubt in my mind that diversity (of thought) is the best investment that leads to succes…

I have seen the same thing happening in recruitment for marketing roles. Totally unscripted interviews often leads to suboptimal results in terms of the quality of the candidate and their fit for the role. Made this mistake firsthand before devising my own process of hiring.

And the process I follow is based on having an exhaustive list of questions covering all areas of the role but during the interview if something else comes up, I don’t mind pursuing that and going unscripted. It often helps me add more questions to my list so my list of questions keeps improving.

I’ve been following this process for last couple of years and the structured process has helped me hire some of the best people I had the privilege of working with. Also, I feel more confident that I’m hiring the right candidate. But of course, there could be an element of bias in there.

Side point - I’ve just finished a SEO hiring guide that covers my whole process of hiring an SEO person (both junior and senior roles). Will be publishing that in the next 4-5 days. If anyone is interested in purchasing a copy, my email is in the bio.

Re: Don’t do interviews, do discussions

#302

Post by angarg12 » Mon, Nov 08, 2021, 9:58 AM UTC

ryandrake wrote: post #229

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…

> 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…

Odd comment. We hate the tech interview because it doesn't fairly evaluate on the job performance of candidates, but apparently it's ok to reject them because they don't fit the interviewer's tribe.

Re: Don’t do interviews, do discussions

#303

Post by twic » Mon, Nov 08, 2021, 10:00 AM UTC

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…

I often administer a 45 minute version of this (talking about any/all past work, not necessarily side projects), as part of a half-day of interviews. We'd never be able to get into the depth you could in two hours, but we can get somewhere.

My experience has been that a lot of candidates can't even fill 45 minutes. I ask "what was the most interesting part?", "what was most technically complex?", "what would you do differently if you did it again?", and they just don't have nontrivial answers.

Re: Don’t do interviews, do discussions

#304

Post by twic » Mon, Nov 08, 2021, 10:03 AM UTC

jandrewrogers wrote: post #228

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…

The challenge with this approach as that many very competent people are not allowed to discuss their prior work in that level of detail. More practical variants of this approach use a straw man software design problem to talk to that will exercise diverse areas of experience.

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 experience so far has been at the NSA, yeah, you might want to do a side project before looking for work.

Re: Don’t do interviews, do discussions

#305

Post by angarg12 » Mon, Nov 08, 2021, 10:06 AM UTC

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'm going to go out on a limb here and say I think most candidates don't hate scripter interviews, they hate robotic interviewers that go mindlessly through a checklist.

When I train interviewers my advice is: have a script, but be happy to go off it. If interviewers keep an authentically engaged conversation, the questions will blend into the background.

Scripts helps in several fronts. They help to reduce bias, standardise calibration and practices between teams, and provide a fallback to get the interview on track. However good interviewers should keep a living conversation with candidates, and take interesting cues off script.

Re: Don’t do interviews, do discussions

#306

Post by dataengineer56 » Mon, Nov 08, 2021, 10:09 AM UTC

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…

I would immediately end my interest in a company if I was asked to do this. This is far too general a problem, which will harm the interviewer as much as it will harm the interviewee.

Contrast it to giving a candidate some slightly broken code in a framework related to the role and then asking them to a)fix it and b)implement a new feature of their choosing and document it.

The advantages of the latter approach:

* The interviewer doesn't need to prep beforehand as they already know both the problem and the codebase. This means they can ask much more interesting questions and don't have to invest significant time in reviewing a project that might be in a field in which they have no experience. This in turn leads to better discussions which in turn leads to better interviews.

* The candidate is given a much tighter problem definition and isn't required to come up with something a)novel, b)not covered by their current employer's NDAs.

* The candidate's time is respected because they can be told how long it should take them up front.

* Each candidate gets a standardised problem and so it's easier to compare between them.

When I give take-home assignments, I'm just looking to quickly confirm that someone has a working home dev environment (i.e. they don't just code inside environments that other people give to them) and that they can understand a small codebase and write clean code and document it. Everything beyond that I can find out by talking to them during the interview.

When I actually used this technique in interviews it was interesting to see how many supposed senior engineers would reply with things like "I'm getting a %JAVA_HOME NOT FOUND error, please can you fix the repo and let me know when it's ready for me to work on?".

Re: Don’t do interviews, do discussions

#307

Post by vsareto » Mon, Nov 08, 2021, 10:11 AM UTC

twic wrote: post #303

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…

I often administer a 45 minute version of this (talking about any/all past work, not necessarily side projects), as part of a half-day of interviews. We'd never be able to get into the depth you could in two hours, but we can get somewhere. My experience has been that a lot of candidates can't even fill 45 minutes. I ask "what was the most interesting part?", "what was most technically complex?", "what would you do d…

>and they just don't have nontrivial answers.

Yeah, because you can have a career where you're just gluing stuff together to make business apps for, usually, simple business problems. You're looking for craftsmen but you're interviewing plumbers.

Re: Don’t do interviews, do discussions

#308

Post by afarrell » Mon, Nov 08, 2021, 10:13 AM UTC

swiftcoder wrote: post #290

Hermitian909 wrote: post #263

Earlier quoted context omitted.

It's hard to tell if it's hysterical without knowing the Cost/Benefit for the company. How empowered are new senior hires, and how expensive is the time of the team? At larger companies senior engineers are often phenomenally expensive and at smaller companies controls over potentially business ending operations are usually minimal. A friend of mine at a FAANG recently dealt with a bad hire. Their guess was that in t…

> Their guess was that in the 6 months the bad hire was there they cost the company maybe ~5 million between wasted engineer time and delayed release schedules after people kept having to put out their fires. I've worked with one or two of those, but I've also been on interview loops that rejected candidates who went on to massively successful careers at a different FAANG. The cost of false positives is relatively ea…

There is also a cost to hiring folks via an interview process that does not clearly signal, “we have thought about it and decided you belong here.” It reduces their willingness to ask for help and admit ignorance.

Re: Don’t do interviews, do discussions

#309

Post by Jensson » Mon, Nov 08, 2021, 10:16 AM UTC

inertiatic wrote: post #300

As a person who used to take interviews, I thought discussions were the best way to figure out if someone is competent. I mean, when I ended up in a discussion with someone, I felt like I did great. I had a good time and it frequently led to an offer. As someone who's now interviewing a person or more every week (during a hiring surge), I still don't know of a better way to interview someone, but I'm not convinced th…

The problem is that "Summarise a project you have worked on in a few minutes" isn't a task you normally do at your job either, software engineers job is to care about the full picture and ensure it all works together without missing any details, making quick explanations that are fit for small talk has nothing to do with it. If the engineer is expected to talk to a lot of non-engineers then that might be a good signal, but for other more technical roles it isn't needed at all.

So your process will select for people who love to smalltalk about stuff, they will look great. But many great engineers doesn't love to smalltalk about stuff, it isn't a part of being good at the job.

Re: Don’t do interviews, do discussions

#310

Post by soneca » Mon, Nov 08, 2021, 10:18 AM UTC

cutthegrass2 wrote: post #294

yvrev wrote: post #268

Earlier quoted context omitted.

I feel like this is a pretty big ask to do for an interview, unless you happen to have it lying around already.

Yep, agree. 95% of the code I write is owned by my employer and is under NDA various other privacy / IP laws. The 5% that isn't, has no place in an interview. It's a bunch of brittle glue code automating and backing up data between my devices. "Passion projects" in my "spare time"... maybe once the kids have grown up and flown the nest... Leetcode is easy... I memorise a bunch of stuff, do the dance and pass the inte…

Isn’t the time spent memorizing leetcode similar to the time spent building a side-project?

I took a look at leetcode when I was interviewing and decided it was a waste of time for me to learn that dance. I was happy with my chances with the companies that didn’t use it in their interviews. And it worked out fine.