What questions can I ask an interview candidate that would allow me to know whether he's a "copy-and-paste coder"?
We're finding that even when candidates answer coding questions well in an interview, once on the job they'll still tend toward copying rather than refactoring.
Anyone else have similar experiences?
I have people describe (in detail) a hard problem than they were proud of having solved. It's pretty easy to tell if they never really understood the details or simply hadn't worked through the problem themselves. Enthusiasm (sparkle even!) while describing the solution is a big plus. Gotta have a love for problem solving!
I've had this problem with candidates as well. The trick is to reduce the number of questions that only rely on definitions. You can provide them with code that needs refactoring and ask them what they would do to improve the code. This is a very open-ended question that shows how the candidate thinks.
A lot of interviewers like to ask questions where the candidate writes new code, unfortunately it is rare that developer is writing new things from scratch. Focus more on presenting existing code to the candidate and asking them to work with it to solve a problem.
Even with these questions it is possible to get a copy-and-paste coder as an interview is not necessarily how they will act in the real world.
That's my two cents.
Not that this excuses it, but one reason developers may copy and paste code is that they don't understand the code that they're working with. For example, if you hire a C# or Java developer, and put him on a Fortran system and tell him to get work accomplished, he is going to copy and paste throughout that system due to lack of understanding.
In addition that that, quality of code can play a part in this. I know of one particular system that was not allowed to be refactored, but new changes had to be introduced. The developers had to do what they had to do to get the task done in a timely manner.
Of course, both of these scenarios don't excuse copy and paste coding, but it's worth a look inside the organization to understand why this may happen.
The first step in our interview process is a 5-minute online question. We give the candidates something like "FizzBuzz" or "Recursive fibonacci" or "Find factorial of n".
We don't have any rules. Nothing about pasting, or the code needing to compile, or what language it should be in - just do it. The 5-minute timeframe forces most candidates down one of two roads - write some pseudocode (or mostly-working code), or Google it.
When we get the answer, we Google the answer. Roughly half the time, it's been copied from some site. Our expectation is that if they spent 5 minutes finding the answer on Google, it should not only compile but it should be the absolute cleanest, best example of a solution for that problem out there. About half the time, the pasted answers are utter crap. We even get a number that didn't paste the entire snippet in, missed a whole chunk!
Copy-pasters tend to be exposed when they don't have a compiler to check them. Their modus operandi is paste, compile, tweak, compile. If they just paste a solution from a web page into another web page and submit it, they have nothing telling them they need to fix it.
This has worked extremely well - no one has made it to the phone screening who shouldn't.
You could modify your approach a bit. Do your tech review and phone screen, sure, just up the challenge of your coding test. Instead of asking simple programming test questions as a pre-screen, come up with a fairly complex programming project that they can solve - something can be scrounged up pretty quickly that can be pretty much ungoogle-able. Give them time after the interview to complete it, and require that it be well document and easy to understand. Then schedule a follow-up where you discuss the solution and ask the candidate things such as "What were you thinking here?!"
Examples of the types of projects of which I am thinking:
I have two approaches, and always use both of them. They take fifteen minutes total, and I use them as the last third of an entry-level job interview.
Ask a very simple question based in theory.
"What's the last thing you wrote that you were proud of?"
We wrote a test that basically checks to see if someone knows how/why to refactor.
We created a simple mockup application (allow the user to create predefined shapes and move them around on the screen) but introduced many types of errors on purpose.
One of these was copy & paste coding (the same functionality repeated in multiple places). Another was to embed logic for each shape into the event handlers. Terrible, terrible stuff - the worst ideas we could think of.
This allows us to see whether the candidate would recognize the opportunities for improvement and which approaches they would take to solve them.
It was a take home test and the candidate could either rewrite the application or provide notes on what kinds of changes they would make.
If they are on-site, make them whiteboard something. Lets you see how they will divide-and-conquor a problem in abstract. Watch what they focus on, what they omit, ask questions as they continue, and if you want to be a little evil - change the rules halfway through.
Break out parts of it and have them write the pseudocode on the whiteboard.