> 2 - Can you really ferret out cheating? I had a grad school classmate who paid someone to do his (non-programming) take-home homework for a job interview, and he got the job. He only lasted 6 or 7 months, but it was enough to be awful for all parties involved. I don't have a great counter-solution other than ask for someone to come in to the office to do the work, and even then you can't tell if they have remote support.

Personally, I think this is where the skill of the interviewer comes in. A skilled interviewer can bust through bullshit fairly quickly. A big problem in interviewing and hiring right now is that most of the interviewers are not skilled. Thus, companies try to come up with processes and metrics that (theoretically) remove the interviewer skill from the equation. Unfortunately, this seems to be done in a horribly unscientific manner.

If only we had some sort of take-home exercise for interviewers.

I hear you on unskilled interviews.

I guess the challenge in this situation is that the whole reason for take-home work is that introverted interviewees get flustered in person. Won't this happen when the review happens?

This still seems like a better idea than "Tell me about yourself" and "How many golf balls fit in a 747?"

"Won't this happen when the review happens?"

At that point, the candidate should not be hired.

If the candidate can't communicate while writing code, and can't communicate about code already written, at some point you have to be afraid the candidate just can't communicate.

If this is a person who can communicate in any situation except an interview situation, then it's a Catch 22 where their ability to communicate in a work environment just can't be verified.

(Unless you secretly record them communicating in some other work context? Probably not a scalable approach.)

If you read the article, the second part of the interview is doing more work on top of the project, but in front of people. I've gone through interviews like that before. Do two steps on a three step kata in front on your own time, and then a 2/3 hour interview to talk about what you wrote, and add the last piece to the kata. Not very easy to fake.

Any experienced programmer that is considering a job change will spend more than a few hours on the process anyway, in due diligence. If anything, I think this is an important part of gaining experience in the field: You actually want more time around future employers, to avoid a bad fit. Going to a place just to quit in 3 months time is a waste of your own time. Investing an extra few hours, or even few days, makes a lot of sense.

Won't the same programmer who got flustered in front of a white board also get flustered explaining the code?

I'm being the devils advocate here, trying to hone in on the best way to do this. I still think work products are a much better predictor than most any other interviewing technique.

Not necessarily, they are quite different forms of communication.

Coming up with something that works, versus explaining why it works or why you did it that way after the fact.

I think it's the "thinking out loud" part before you have a solution, that can fluster a lot of introverts.

for some it's not about introversion/extroversion but simply the fact that whatever part of their brain deals with speech is the same part that deals with thinking through those kinds of problems, so they can't do both at the same time as a matter of physics.

this is to put it precisely. the reality is much messier and varied. the point is, people's brains are not wired the same. and what this means, to make a long story short, is that these interviews are not comparing apples to oranges... not even close.

[edit]oops. obviously, i meant apples to apples :D

1 - We don't expect anyone to give up this much time. I realize that it's a big ask. However, a lot of programmers we've spoken too really want this option. Anyone who does not want to is totally free to go with the (faster) regular interview. Either they let is watch them code for a short time, or they code for a longer time on their own.

2 - I can't say for sure (we're only just launching this), but I hope (and think) that talking with someone for 45-minutes about the project that they did will be enough to make sure that they actually did it themselves

Out of curiosity, what are the demographics of the people who made these suggestions?

Were they employed? Were they very desirable to companies? Were they very undesirable to companies? Did they have financial hardships? College graduates? College dropouts?

I think it's important to remember how diverse the hiring pool is, and which voices tend to be the loudest. I would argue that the advice most companies get are from very successful companies. Similarly engineers likely seek advice from very successful engineers.

Both these groups are in the minority I think, and would thus not be in the best position to dictate for the majority (strictly in terms of fulfilling individual needs that they themselves have not encountered, personally or otherwise).

Example: 10x programmer wants a hiring process that caters to 10x programmers.

Problem: Vast majority of programmers do not fall into this category, and would not benefit from such a system. Yet companies want 10xers, so they go with it anyways. Then they complain about how hard it is to hire programmers.

Less experienced programmers are definitely over represented in engineers adversely affected by stress. This could be because people get better at interviewing at they gain experience, or because the people who can't perform under interview stress drop out of the profession