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.

Sounds like you need a technology architect for your project. Somebody has to lay down the law WRT to standards used, technologies used, and move it away from the pet-idea-of-the-week.
–
quickly_nowFeb 27 '12 at 7:34

10 Answers
10

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?

that's good one. Hope it reach to as much as interviewers, recruiting managers.
–
SaarDec 9 '10 at 17:10

there seems to be a lot of consensus over this answer, but dont "senior" level guys dictate the functionality and then the implementation is left to the coders, right ? I mean the senior level guy might say "Hey, dont use a horde of technologies, just use <these two>", but still the copy paste devs are going to do copy paste ! Am I wrong ?
–
WildlingFeb 26 '12 at 7:22

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

If you're not giving a written test during the interview, you could be shooting yourself in the foot. I've had them at my last four employers and was often surprised at how simple some of the questions were. At one place, I was told that another candidate left without completing the test, crying.
–
Adrian J. MorenoNov 20 '10 at 0:17

1

I absolutely agree that a written test during the interview is the only way to be sure that your recruits really have good programming skills. But the main thrust of my answer is that developer skills alone are not sufficient to address the SO's problem.
–
Stephen CNov 20 '10 at 0:21

Got caught by the editing timer. I completely agree that standards and review are necessary. We recently published a new coding standards document and combined with some new code review processes we've had far fewer bugs make it to QA. One if my next goals is to start an internal training team.
–
Adrian J. MorenoNov 20 '10 at 0:27

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.

are you talking about experienced one? Why should one leave his job and join a place where they need 3 months to let them he/she sucks or not:) Why is there human resource?
–
SaarDec 9 '10 at 17:13

I'm talking about experienced, competent people. They're cheaper in the long run. Human resource(s) stop you getting sued for violating employment law. Originally there to do touchy-feely stuff for Henry Ford's numerical managers. True story, look it up. If you already know the person is going to work out fine, well you're better at this than me. The person will change jobs because you're so great to work for, there's a great work environment, and after probation they get a fat bonus. If they're made redundant as a permanent, your company pays out an extra three months. Something like that
–
Tim WilliscroftDec 10 '10 at 0:16

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!

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

-1. FizzBuzz detects total idiots. To do copy & paste coding, you can't be a total idiot.
–
back2dosNov 20 '10 at 18:34

@back2dos - You should already weed out the "total idiots" by the time you get to a face to face interview. FizzBuzz makes somebody think about the problem and how to best solve it. It isn't difficult so it should expose those who copy & paste, since those who copy & paste don't learn the "why" behind things.
–
JettiNov 21 '10 at 3:01

3

+1. FizzBuzz detects more that total idiots. It also detects people who compensate a lack of technical skills by above-par social skills. Those people have a good chance of passing a first screening test. E.g. they may very well hold legitimate degrees.
–
MSaltersNov 23 '10 at 14:32

1

Well, you ask ME fizzbuzz and I walk away immediately. :) IMO in junior category it's not really useful, as you will train the guys anyway, and in senior category it's useless+offensive. you should be able to tall smart+get-thngs-done people by other means. Coding on the spot-like questions are IME indication of weasel farm companies. If I'm actually interested in coding skills of someone I give a code review question. And get all the relevant answers without frustration.
–
Balog PalJun 1 '13 at 17:46

The first requirement should be more specific. java.util.LinkedList l = new java.util.LinkedList() doesn't import anything, but certainly uses the built-in collections.
–
Barry BrownNov 20 '10 at 2:38

This is a fair question especially for recent graduates. If you paid any attention or spent any time programming at all this should nearly be trivial. I assume it doesn't have to be exact, but close enough.
–
Bryan HarringtonNov 20 '10 at 5:30

3

@Bryan, no one has tried that yet. And I really don't care if the answer is 100% correct. Only that they understand the problem and are able to approach it in a competent way. The most common problem is one where add/remove wouldn't work at the head or tail of the list. I've recommended people be hired based on their reaction to me pointing this out.
–
salNov 20 '10 at 16:02

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.

I agreed with you until "...and the IDE you use." Coders are particular about our work environments, and not likely to be familiar with $random-IDE. I've been coding for over 20 years, and I'd waste the first 10 minutes trying to figure out how to work an IDE if you threw one at me. I use an editor (bluefish when doing webby things, emacs for everything else), and command line tools for everything else (revision control, compiling when needed, etc.). I don't use debuggers at all. I was taught that if you need a debugger you're doing it wrong: that's what debug code is for!
–
HedgeMageNov 21 '10 at 19:44

@HedgeMage, I did not say they had to use it... Seeing how a person handles that situation is very telling. Will notepad+javac suffice? Does he download and install NetBeans? Will he ask how to do X in your IDE, hack a bit and ask for Y and Z?
–
user1249Nov 21 '10 at 19:48

@HedgeMage, debug code is great if you can determine ahead all possible things you might need to know. Debuggers are nice in cases where you need to see answers to questions in order to determine the next question, which with debug code requires a new binary and restart and go to the location again.
–
user1249Nov 21 '10 at 20:50

1

@Thorbjørn: Granted, my bills have been paid by work in interpreted languages for the past few years, but even back in my C coding days, I dismissed the debugger in favor of good debug code. Perhaps it's just a prejudice on my part: I went to college with a whole lot of people who never learned how to code per se -- they just slapped something together then fixed whatever the debugger screamed about until it "kinda" worked. I can't stand that kind of slipshod coding. I didn't mean to imply that debuggers are evil, just that they and other IDE features don't belong in all workflows.
–
HedgeMageNov 22 '10 at 1:23

@HedgeMage, I agree on the "beat it until it works" approach for debugging is not good, but concluding that debuggers are bad is perhaps a little too broad a aconclusion.
–
user1249Nov 22 '10 at 6:50

@Thorbjørn: Not as messy as them shooting themselves in the foot, after copying large chunks of source code.
–
Joe DDec 6 '10 at 19:12

Those who fail to use the internet to their advantage are locked in yesterday's modes. I ALWAYS assume their are some good examples out there for me to look at no matter how trivial the question. I don't copy and paste, I look at good examples and apply the best technique. I'm a full-stack programmer which means I'm a generalist and not a specialist and rely on the rest of the world. Clearly sinful !
–
junkyFeb 27 '12 at 1:01

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.