How can I quickly weed out “copy & paste” coders? [closed]

Question

I need a way to filter out resumes of folks who just copy-and-paste code then hope it works, and check it in if it does. All this happens without having an understanding (or care) to understand the rest of the code in the system.

Sure I know that copying and pasting code is part of learning a new object, control, etc... but how can one tell if that accounts for 70% (or more) of their development career?

I've come across some senior level guys perhaps whose skills are so outdated or irrelevant for the project, that all they do is google, copy-then-paste some code without thinking about the solution as a whole. As a result 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.

In the worst case, this type of developer creates security issues and vectors for attack.

Question

How would you recommend I filter out people who have a poor programming background? Can I do it at the resume level? If not, how do I do this during the interview.

Answer 1

I've come across some senior level guys perhaps whose skills are so outdated or irrelevant for the project, that all they do is google, copy-then-paste some code without thinking about the solution as a whole. As a result 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.

I don't think the skills of your developers are the problem. Your problem lies elsewhere, perhaps a team leader or architect who doesn't have the self-confidence to "encourage" better coding disciplines, or a management team that doesn't understand the importance of managing technical debt, and doesn't give their developers the time and resources to do so. Does your company hold code reviews?

Leadership may be the problem, not copy-paste developers.

Answer 2

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.

Answer 3

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.

Answer 4

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!

Answer 5

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

Answer 6

I ask three interview questions

1. Write a linked list capable of storing some numeric type in java without importing anything from the collections framework
2. Write code showing how you can add/remove nodes from that list
3. 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.

Answer 7

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

Answer 8

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

Answer 9

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.

Answer 10

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.