[implmentor]

Not OP, but I would love to share some: I relate strongly to the anxiety induced descriptions in OPs text and thus try to avoid these when I interview devs as an engineering manager. Of all the candidates I have interviewed over the years I have never done a live coding interview because it is essentially worthless for me as an interviewer and only serves to discards potentially very clever people whose thought process does not work this way.

Instead I try to find an isolated problem/task we have in our backlog that the candidate should try to implement on their own time, so I can review what kind of solution they will actually deliver once hired. We then go through the solution with them and do a code review as they would go through if they got hired. You then see both the problem-solving skills as well as how they take feedback.

I would recommend checking out DuckDuckGo's excellent "How we hire" guide[0] which describes some of the best hiring process I have come across (albeit it may be too extensive to do in full for some companies).

[0] https://duckduckgo.com/assets/hiring/how_we_hire.pdf

[koonsolo]

So how do you know they did it on their own? Spouse is a developer, helps them out, explains everything. Then on the job there is no spouse, and it all goes to shit. Not saying this would be every time, but you might come across one of these.

We have an initial Hacker Rank 'filter', that if you don't pass that, we don't even do an interview. A few weeks ago we interviewed someone who passed that filter very well. But in the interview, it was really below par. Not even the basics were understood. So I'm very skeptical about these kinds of homework where they could get help.

What I currently do is go through a very simple coding example that I wrote (very generic). Then we go through the code and I ask questions like "can you explain what this line is doing", or "If I move this line over here, is the behavior still the same", etc. Some bugs are in there and I ask what is going wrong and how to solve them.

Not ideal, but the problem is that nothing really is :(.

[beebeepka]

I think this person has a better idea because your spouse scenario, while realistic, can easily be detected while you discuss the code being presented.

You may have good intentions but what do you equates to "I don't trust you, bro/sis". Not a great way to start a relationship imho

[koonsolo]

> can easily be detected while you discuss the code being presented.

That is possible of course. But if they wrote the code together, and know they will question later, you could teach the other person all the trade-offs etc. I could see myself doing that with a bad developer and get them through such an interview.

> Not a great way to start a relationship imho

Well, you could take the benefit of the doubt, and then when it seems they did cheat, just fire them. But firing is always such a big decision.

It's a difficult problem.

[lapcat]

> But firing is always such a big decision.

Isn't that why managers get paid the big dollars, to make the big decisions?

The whole rhetoric of the tech industry — taking risks, creative destruction, etc. — seems to completely fall apart when it comes to hiring, where everyone turns fearful and ultraconservative.

[kansface]

Have you ever worked with a really bad hire? Someone totally incompetent at doing the job? In my personal experience, that person completely tanks the productivity and moral of the entire team. I’ll also point out you are not doing that person any favors by hiring them and firing them one month later (if your org is even capable of doing that). Bad hires are disastrous.

[lapcat]

> In my personal experience, that person completely tanks the productivity and moral of the entire team.

A bad manager completely tanks the productivity and morale of the entire team too. And you can't fire your boss, you can only quit your job.

> I’ll also point out you are not doing that person any favors by hiring them and firing them one month later (if your org is even capable of doing that).

Not sure how it's relevant whether you're doing the incompetent person a favor or not? Hiring isn't about favors, it's an exchange of money for work. If there's no useful work, then the money has to stop.

> Bad hires are disastrous.

Seems a bit overstated to me. Do you have any examples of companies put out of business by a bad programmer hire?

Coders come and go. Is it a "disaster" if your best coder leaves for another job? We're treating hiring as if it were like marriage and divorce, but it's not. When you hire someone, it's not "til death do us part". Breakups are expected.

Too many companies make hiring much more difficult than it needs to be. They overthink it, and also waste way too much time on it. Find someone who seems right for the job, and hire them. If they don't work out, get rid of them and hire someone else. You might get unlucky at times with a bad hire, but you might also get lucky with an unexpectedly great hire. If you can't correct your mistakes quickly, that's a problem with your company's culture, not a problem with job candidates. I would argue that it's not a bad hire that demoralizes a team but rather a bad company culture that's incapable of correcting mistakes.

[ubik_]

This, probation time + take home assignment + discussion = I can filter out almost all the false negatives of the take at home. Give the people a choice between take home assignment and more classic code interview so you can dodge problems like shitty home-offices, strange contracts clauses but the real deal remains the probation time.

[lapcat]

> Not saying this would be every time

How often would you say it ever happens? This feels like a rather extreme level of paranoia.

[maccard]

> Instead I try to find an isolated problem/task we have in our backlog that the candidate should try to implement on their own time,

And in this case you're eliminating people who aren't willing and/or able to spend time preparing for your interview process. One of my previous jobs had a clause in the contract that all my programming work belonged to my employer; is your company going to sign a waiver that says they take responsibility if a previous employer sues? Doesn't matter whether or not it's enforceable or not.

What if you use that solution in production, do you compensate for their time in helping solve the problem like you would if the task was assigned to you?

Also, you're not really setting a level playing field here. How do you gauge a candidates experience/seniority versus the other 10 candidates you hired if you're not asking them the same questions or looking for the same things. Maybe I've solved that bug in my current job.

All this is to say that this doesn't "just fix" hiring - I don't know if it's any better or worse than giving people on-site tests, but you're at the very least trading one set of problems for another.

[Apocryphon]

It might not "just fix" hiring, but at least it doesn't blinding accept the status quo and attempt to engineer an alternative that can then be evaluated. We are supposed to be scientists, are we not?