@U04V70XH6, what do you think about homework / mini-project to work on over 1-2 week(s)?

I think they assume that a) the candidate has "spare time" to devote to such a project unpaid and b) the candidate has a work-capable computer at home with the tech stack you expect them to use -- those are both horribly flawed assumptions and they are very discriminatory.

Pay them for homework/mini-project work. Provide them with a computer all set up for that. Then I might consider it slightly more fair.

It would certainly be nice to get paid for the time you spend. What would you consider a fair rate? For the (b) setting up a code space (Github, GitPod) would be possible. I see a homework better than a live coding session.

(the other issue with the at-home project work is that you have zero assurance that the candidate actually did the work themselves and you have zero idea of how much time and effort it took)

I am absolutely against it, to be honest. I've never made a candidate do it, I don't believe it works, and I've never had a problem with the way I hire candidates 🙂

The industry is horribly stuck on this issue. People just don't seem to be able to accept that we're doing it completely wrong.

Part of it is that we expect engineers to somehow, magically, be able to "interview people" without any training. But that's just yet another confirmation that we do not value "soft skills".

Coding is the least valuable thing we do as developers -- but interviews put a huge amount of value on it.

> (the other issue with the at-home project work is that you have zero assurance that the candidate actually did the work themselves and you have zero idea of how much time and effort it took) The follow up discussion can probe into the ownership and quality of the work. Also it is a way to see how they communicate.

(BTW, I agree that "homework (is) better than a live coding session" but that is a horribly low bar...)

> The industry is horribly stuck on this issue. People just don't seem to be able to accept that we're doing it completely wrong. Guided discussions are the way to go. > Coding is the least valuable thing we do as developers -- but interviews put a huge amount of value on it. I think this is what outsiders (non-tech stake holders) think we should be doing all day. Making computers behave the way they need to. 😅 It's a shame we as engineers perpetuate this too. 😞

We can break the cycle if we're all willing to stand firm on this. It's the hill I will gladly die on -- and I've been fighting this battle at companies for decades!

I don't have such an extensive experience with interviewing developers, but what I have seen is that having conversation about their past experience reveals much more than only asking technical questions.

I basically agree with all of this. At the same time, sometimes you need (or should) evaluate candidate's technical ability; and it depends a lot on the context. When you say: > The bare bones tech stuff: you can teach anyone that That's maybe true but it takes time, money, energy and it assumes you have other skilled people at the company that already knew this stuff. Often (at startups, for instance) you need somebody that will help you solve your problems soon after they join the company and that they will establish a solid basis for future work. If we just hire anybody that's nice to talk to and can communicate well we may waste a lot of time until they get the deep technical expertise the company needs. I mean there are jobs that really require deep technical expertise and we should be (somehow) evaluating that too... I agree that coding tests or trivia questions are poor means to achieve that; but (using a DevOps example) if somebody claims they have deep aws expertise and a couple of AWS certificates, they should be able to answer questions like "What kind of resiliency EC2 instance provides?" and if they fail that it's a warning sign (that they either lie about their expertise or it's quite out of date).

I did this job to hire people sometimes and fortunately I had the power to decide how to hire, so I used to value a conversation about topics just to check how the candidate works, how it approaches problems, talking about situations and technical aspects. It's easy to catch people that has or not the required skills. An important think about the context when I did it is that all those companies (actually two) were startups using niche technology, but I understand big co requirements in terms of filtering out the huge amount of CVs they receive when they have opened positions. It's a bit unfortunate that even small companies which are using niche technology have the same approach. I myself am now working in a big co with Java because I was able to hack the system (they didn't have a organized hiring process and I was admitted by a referral), because either way I'd look for other opportunity, because I barely tolerate such BS. (sorry for the last word but it's how I feel)

I've been working in the software engineering industry commercially since 1997 and I cannot recall any paid job I secured when there was a technical coding test involved, live or take-home. After 25 years and another recent interview with a live coding tech test (faux pairing) it seems I am destined to keep this record until I retire... I guess no-one hiring me ever looks at the 100+ hours of live coding I've done on YouTube... oh the irony I've always got the job when there was other forms of assessment. Or where we discuss what the business needs and coming to an honest evaluation as to if I would be of any value.

Thank you Sean – as someone who's found themselves forcibly on the job market it's good to hear this echoed from the hiring manager side of things

We've been trying out something for a while: "Here's a problem statement. 1 page a4 max, written description of how you'd solve the problem." The most we've had someone take on it is two hours, generally it's been at most an hour. It honestly gives a much better idea of their skills and comfort than any coding challenge we could give. Also makes the follow up interview far more interesting, much more to dig down into than a toy project. I don't think we'd use it for a junior, but from intermediate+ it seems to be working quite well. (Actually I think Sean may have been the one to mention this way back)

At the beginning of my career, I always felt that preparing for the interview (exercises, tricky questions) is a waste of time because I could spend that time learning about SD and be better at the actual job than being better at interviews. And the truth is that interview is a both-side equation, the company looks if you are good for them and you look if they are good for you. It's an important commitment and the interview process says a lot about the company. So as a candidate, I always preferred companies that do reasonable interviews, where it's more about talking with each other and where I have room to learn about them too. And good hiring process not only speaks about how the work environment looks right now but also how future teammates will be hired and chosen - and it's a big part of where the company will go and how you are going to feel there. After I had more experience and more options, I just straightforwardly asked before applying about the process and didn't apply if it was not fair on both sides (e.g. pointless coding exercises, long take-home assignments, no possibility to talk with the team before joining, etc.). And always when I had a chance to have an impact on hiring, I preferred to do a ~1h conversation - and it also like for you Sean, never failed me. Now my wife is looking for a first job in programming and it seems that over the years processes have not changed much. She still needs to search for and remember all the "tricky interview questions in language x", do a ton of coding challenges, etc. just to be hired as a web crud developer.

> I mean there are jobs that really require deep technical expertise and we should be (somehow) evaluating that too... I think that can be evaluated in a conversation far better than it can be in any kind of contrived assignment or set of questions.

I love what has been said in this thread. One thing that I would add is that it is important to include more than one person in the hiring decision, and make the panel as diverse (background, job function, etc) as possible in order to counteract personal biases.

@U04V70XH6 great post, well argued! Are you planning on publishing it as a blog post too?

@ULA8H51LP I probably should craft it into a blog post at some point...

I remember preliminary rounds of coding test I've to take in hackerrank that involves all pair shortest path problem 😞 nowadays there are bootcamps to train people for preliminary tests which is even crazier