[michaelchisari]

You're assuming that I would "send you" massive amounts of code. I wouldn't. I'd have a link to my github on my resume, along with a description of the projects I've worked on.

It's presumptuous that I would be asking you to do a full code review (my Appleseed project is tens of thousands of lines of code, for instance), and that I wouldn't recognize the impracticality of such a request.

I would find it problematic, then, if you responded with tests and puzzles, without any interest or questions about my code. Or if the test and puzzles couldn't be skipped once I mentioned my experience level and accomplishments. This is often what interviewers have done, and I find it to be a good indicator of a workplace I'm not interested in working in.

The best workplaces let their developers take some time to comb through the best parts and the worst parts, and have a conversation about what I've done, my goals, how I did things, etc.

[bbarthel]

Asking me to look at code on github is not that different from just sending me all the code (other than the fact that you aren't cluttering my inbox with it). What code do I look at? Why is it interesting to me? I understand your point about having a discussion about your code, but you are again asking me to find those interesting bits that are relevant to the position I want to fill. You are familiar with the code base already - it is not difficult for you in your cover letter to indicate that I might be interested in x,y,z in project foo because they demonstrate a,b,c, and I can find the code on github. Now I know what to look for, and I am very likely to go and look for it. That may lead me to explore some other things and will lead to an interesting interview. Even if I don't consider the code interesting and relevant, it still lets me ask about why YOU thought it was. If you don't point me to that, I may just flip through a couple of methods and never find anything that interests me enough to talk about it.

And for the record, I don't like "puzzles" either - even if I know the "trick" to the puzzle, sometimes my brain doesn't work right and I can't think of it after a long day of interviews. I would much prefer to be evaluated on how I work in a real environment, seeing my real code and my approach to real problems as opposed to impossible problems whose solution hinges on an obscure bit of semantic parsing in order to arrive at the solution. But as an interviewer, I don't have unlimited time to evaluate candidates so if you want me to do something, it helps to make it as easy as possible for me to do it.

In the end, I don't disagree with you, but I can understand interviewers that don't make the effort if you don't also make an effort.

[michaelchisari]

it is not difficult for you in your cover letter to indicate that I might be interested in x,y,z in project foo because they demonstrate a,b,c, and I can find the code on github.

I think it's fair to assume that after my years in the industry, that I would not simply hand you a link with no context, nor that I would be applying for a job which didn't relate to the work I had done, and I don't feel these arguments apply to the situation I presented.

But as far as I'm concerned, my preference would be to hire based on established code and real world tasks, not abstract puzzles. Not only are puzzles like these faddish, I've met too many programmers who excelled at puzzles, but were severely lacking in more mundane (but all too necessary) departments, so in terms of what kind of things I would use to weed people out, I'd do a set of real world tasks like the one I mentioned above, well before I'd ever give a list of clever puzzles to solve.

Assuming the applicant didn't contribute to open source, which would always be a huge plus in my book.