[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.

[robertlagrant]

You're answering in a vacuum. The previous poster is saying that just hiring easily with a view to firing if they're bad is destructive. Talking about managers is irrelevant to this. It's not one or the other.

[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.