How can I quickly weed out "copy & paste" coders?

The way to weed out programmers who cannot program is to set them a practical programming exercise as part of the screening phase or interview phase. (The latter is probably better because you can control the environment to prevent cheating.) But I don't think that is really going to address your problem. ... we have a mismash of JSON, AJAX, callbacks, ASMX, WCF and postbacks in the same project. It is clear there is no consistency or logic behind where each technology is being used. IMO, the real problem here is that your team is not doing enough internal code review, and not developing a "play book" of preferred solutions to known problems. This is partly a culture issue, partly a communication issue, and (probably) partly an issue with project deadlines. Another issue is that project typically has a long lifespan, and during that lifespan, new technologies / techniques will appear, and old ones are likely to fall out of favor. If you want to avoid a "dogs breakfast" use of technologies / techniques, you need to either: set and enforce a list of technologies / techniques that may be used per project, or invest effort in refreshing the technologies used by a project.

Hire people on 3 month probation. Fire them if they suck. If you don't INSPECT you can't EXPECT. Code reviews, audit tools. A CI server can run these automatically. Ask real questions in your interviews, as in questions from real code. Get them to write code on the whiteboard. If you are a non-technical manager, you are unqualified to judge this. If you are unqualified, get a reputable senior professional consultant to do the testing. Ask your existing people, and business competitors if they know a 100x productive person. Pay them to do the interviewing. If you want to run a hospital without a head of surgery, go right ahead.

I have spent the last few years interviewing people and finding that 90% of candidates simply cannot program. My interview technique for determining programming is to give the candidate an overly simple brief and let the candidate solve it using a marker and a whiteboard. Failure modes include: coming up with a design and then implementing something different. These candidates are rejected because they are dangerous on a team. not follow specs, write bugs etc... Not being able to invent a design. A surprising number of "experienced" candidates need a spec to include implementation design. not knowing the programming language, despite CV claiming experience. Not asking additional questions to extract fuller specifications. Not being able to explain design decisions. This one is major. If someone cannot explain why, then each time they will do it differently, and consistency is lost. The end result was I spent a lot of time interviewing, and not recruiting very often. however, the development team was very good, and had the complete respect of the entire company and it delivered!

I would suggest FizzBuzz that Jeff Atwood mentions in the post at http://www.codinghorror.com/blog/2007/02/why-cant-programmers-program.html. Write a program that prints the numbers from 1 to 100. But for multiples of three print "Fizz" instead of the number and for the multiples of five print "Buzz". For numbers which are multiples of both three and five print "FizzBuzz".

I ask three interview questions Write a linked list capable of storing some numeric type in java without importing anything from the collections framework Write code showing how you can add/remove nodes from that list Write code showing how you can get the max/min from that list I've seen people complete this in 5 minutes and seen people struggle for 30 minutes before giving up.

You cannot do this at the resume level as they essentially have infinite time to write that up, but you can do it on a phone interview if you ask a few questions which require technical insight in what they do. This gives you both the answer (good or bad) and how long time it took them to get there. When at an interview, make them write code. It is the only way you can tell if they can program for real. Make the problem simple, give them a computer with an internet connection, and the IDE you use installed, let them ask any question (except gimme-hte-codez) and watch how they work. EDIT: For post-mortem analysis it appears that PMD has a copy/paste detector to find it: http://pmd.sourceforge.net/cpd.html

Simple (1) Lock them inside a room + Free Oxygen. (2) Give them a PC with Internet connection + IDE of choice + access to Food. (3) Have wireshark or similar method of logging all inbound and outbound traffic. (4) Give him a medium assignment. (5) Examine all HTTP traffic, post assignment completion. (6) If subject has copied large chunks of source code, terminate Subject..... Edit: As makerofthings7 as pointed out, in practical terms one could do a video capture (screen capture).

If you want to "weed out" poor coders you can try for example Programmer Competency Matrix (useful but it rather doesn't apply for all possible areas - of course you can make own) or codility.com (the tasks are very good and it saves a lot of time). Generally, hiring good coders is hard and often requires many years of practice. You can start your own database of interview questions, not only asking about coding stuff but also with math, logic, not to mention motivation questions.

I would say that the problem with your candidates isn't that they can't program at all, but that they don't have a feel for using the right tool for the job. My suggestion is an essay question where they would be given high-level requirements for a new system and asked to provided an architecture and justify their component choices. But keep the FizzBuzz for the candidates who can't code at all without a browser.