[bbarthel]

Please don't ask me to review your "massive amounts of code" - I guarantee you will not come out ahead in that evaluation, if I even have time to properly evaluate it (according to Code Complete, you can properly review code in a high-level language at about 100-500 lines per hour).

If you consider the fact that:

- It is unlikely I am well-versed in the problem domain of your code,

- I am unlikely to be aware of external design constraints or coding pressures,

- I am probably going to randomly select the worst section of code to review,

- I have no context for how the code evolved

the chances that I walk away with a negative impression are high enough that it should give you pause. If I do manage to walk away with a positive impression of your code, it will be offset by the perception that you believe your time is more valuable than mine (why else would you send me a massive amount of code and ask me to review it to determine your suitability for a position) - and you still haven't answered the other big question I need answered which is whether you are a good "fit" for the team from a personality/cultural perspective.

If you really want to impress me, go ahead and send me a list of your projects and contributions and then slice a relevant sample of code from it. Describe what the problem was and how you solved it so I can understand the context. Try to make it relevant to the position, but failing that describe how you could utilize that experience in the relevant domain. Keep it small enough that I can review it in under an hour or two.

Is it a lot more work for you? Absolutely, but if you do this I guarantee you I will look at your code and will likely call you for an interview because you are demonstrating a high level of competence and professionalism while still respecting my time and needs.

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