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 :(.
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
> 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.
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.
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.
> 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.
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.
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.
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 :(.