[11thEarlOfMar]

We do it in reverse. In the first 2 hour interview, candidates learn our tech from 2 or 3 engineers. We then send them home with a set of coding tasks that are all relevant to what we do. As in functions of utilities that we actually would need to write, as opposed to puzzles. They choose one of 6 tasks, write ~100 lines of code, then come back for the next 2 hour interview and lead a code review of the code they wrote. This approach allows them to take the same time and care they would if working for us, rather than putting them in an unnatural state of coding at a white board in front of one to n scowling veterans.

Engineers who are capable can clearly explain their coding choices and their style is evident. If they've borrowed too liberally or had someone else write it for them, it becomes apparent pretty quickly because they can't clearly explain the code they supposedly wrote.

This is a fairly new approach for us, but so far, the candidates have appreciated it and the team reports that this approach gives them a good sense of the candidates ability.

[lj3]

So, based on the new information presented in the article that people who can talk clearly about code can also write code, are you likely to change your interview practices to omit the take home task and ask the candidate to talk about code that somebody else wrote? It would be faster, easier and according to the data in TFA just as accurate, yes?

[11thEarlOfMar]

Do you have data that shows how fast and easy the take home test approach is so I can compare? I only have anecdotal data.

I do give candidates the option of the take home vs. white boarding. So far (it's admittedly still a pretty small sample) they've all opted for the take home. However, we'll take a look at this approach as well.

[lj3]

> Do you have data that shows how fast and easy the take home test approach is so I can compare? I only have anecdotal data.

I'm not aware of any solid data around take home tests. All I can give is yet more anecdotal data, which is that they take a lot of time on both ends. So much time, in fact, that I've had several interviews where the interviewer never looked at the test code I was required to send in. Whether they work or not is irrelevant if nobody ever looks at the code.

[11thEarlOfMar]

I see. The take home assignment is not a test or exam, per se. It's code sample that responds to one of 6 coding tasks. We expect something around ~100 lines, typically in C. The candidate leads a code review of their code by the team when they return for the second 2 hour interview. The code review usually takes about 45 minutes. The remaining 1:15 is 1-1 interviews. So we can assure candidates that someone reviews the take home assignment as they lead that review.

[cakedoggie]

Who doesn't love homework, especially as an adult.

No thanks.

[dando]

Is it really that bad? An onsite interview takes the full day anyway.

[cakedoggie]

Yes, it is. What other job asks you to do homework outside of programming?